On Fri, Dec 19, 2008 at 6:52 PM, <[email protected]> wrote:
> Hi, > > > > I got a question concerning the implementation of ADB and I thought I'd be > on the better place in the developer list. > > > > I cannot really understand the way ADB was implemented, I think my proposal > is better and I wonder why no one else thought about it. Probably I am > missing some points and I would be glad if you could correct me. > > > > ADB is implemented with the use of AXIOM. AXIOM is a xml framework which > only reads the content if it is needed, which I think is really good for > performance. When I now trace the way of a service generated with ADB > databinding, I see that Axis2 is first generating OMElements which are then > converted to the ADBBeans. Later, on the way back it will be the other way > round, from ADBBeans to OMElements. > Please read this article[1]. See the parse and serialize methods of the generated code. It directly reads from the xmlStream reader and writes to xmlStream writter. > > > What are the particular reasons that you didn't just extend an OMElement to > become an ADBBean. You could just create some setters and getters for the > properties to set and could stick with the internal OM-implementation. That > way the step of (de)-serializing would fall away. > ADB is a databinding framework and AXIOM is an xml info set representation. In Axis2 databinding happens after the message receiver and it builds the Xml info set at the transport level. As I understood, what you have suggested is to build an general OM Element model at the transport level and build a another OM Element model (which extends ADBBeans) at the message receiver. IMHO this is not perform better than creating ADBBean objects directly from the XmlStreamReader. thanks, Amila. > > > What am I missing out here? > > > > Thank you for any clarification! > > > > Matthias. > [1] http://wso2.org/library/2068 -- Amila Suriarachchi WSO2 Inc. blog: http://amilachinthaka.blogspot.com/
