Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <43096C13.7060805@sosnoski.com>
Date: Sun, 21 Aug 2005 23:09:23 -0700
From: Dennis Sosnoski <dms@sosnoski.com>
User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050322)
MIME-Version: 1.0
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] Databinding API issues
References: <43057D69.2050508@sosnoski.com> <430947EE.20108@gmail.com>
In-Reply-To: <430947EE.20108@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Ajith,

Glad to be part of the project!

I understand the virtual nature of OM. I'd like to take advantage of 
that when writing the actual serialized output, so that the OM stays 
virtual when used for the output of a databinding operation. It looks 
like this should be very easy to implement, though - I assume you're 
using the OMNode.serialize() method for actually writing out the data, 
right? Then it should be just a matter of implementing a custom 
OMElement for each data binding framework, which knows how to serialize 
out a saved data object to an XMLStreamWriter when the serialize() 
method is called.

Behind the scenes, we'd need to handle actually building an OM tree 
representation of the data from the object - but only if needed, since 
OM is virtual. This should give us the best possible performance.

The code for this should be very similar between JiBX and JAXB 2.0, so I 
should be able to implement these both at the same time (the research 
license for JAXB 2.0 gives me some concern on this, but I'd expect that 
just implementing and distributing code that uses part of the API is 
valid under the terms of the license as long as the JAXB 2.0 API is not 
itself exposed or redistributed). I'll start in modifying the JiBX input 
and output to work with XMLStreamReader and XMLStreamWriter, 
respectively, in about a week from now when I get out the JiBX 1.0 
production release. The official support for these will be in a 1.1 
build of JiBX. Once I have the basic JiBX changes in place I'll work on 
hand-crafting DatabindingSupporter classes for JiBX and JAXB 2.0.

  - Dennis

Ajith Ranabahu wrote:

> Hello Dennis,
> Glad to have you as an Axis committer and guess I should give you some 
> explanations to why there are toOM(...) and fromOM(...) methods. Seems 
> I'm a little late on answering but guess I should provide you an 
> explanation anyway :)
> The Axis2 client API depends upon OM and expects and OMElement as the 
> input to a message being sent. Hence we must have the objects 
> converted to OM represntations and vice-versa. However building the OM 
> does not mean that the whole XML stream is parsed and converted into 
> the Object tree. It's OM and OM builds the Object model when 
> absolutely necessary :). Inside the databind supporteres what happens 
> is this conversion, where the pull stream is taken from the object and 
> fed into the builder(toOM) or the pullstream is taken from the 
> OMElement and fed into the XMLBeans factory to create the Object 
> (fromOM). The streaming API gives us the chance to get the events as 
> late as possible. (There are some problems we need to fix to have this 
> running smoothely with maximum performance. For starters attemting to 
> get the events without caching throws out an error with the XBeans 
> pull stream. Perhaps the object reference needs to be explicitly 
> maintained through out the process but seems I'll have to dig deep to 
> solve it. Until then the generated stubs have a 'element.build()' 
> statement). What I wanted to stress is that OM is virtual by it's 
> nature :)
> You are absolutely right about the pull support in XMLBeans. AFAIK it 
> is the only known framework that has the capability of interefacing 
> through StAX. The best solution for doing it with other framworks I 
> guess is what Eran explained, a 'Push' builder. Push builders create 
> havoc in serialization (:)) but I guess we can make it work. To keep 
> the perf figures intact we actually made the builder hang on to the 
> object and push the events directly to the stream (through a content 
> handler) if needed. I'm not sure whether this code is still in the 
> code base but I remember well that we did something similar.
> However the generated code is architectured in such a way that the 
> databind mechanism (may it be push,pull,XMLBeans, JiBX or JAXB) has 
> nothing to do with the stubs. The seperate databind supporter is the 
> one that handles the whole thing. Theoreticaly one can modify the 
> databind supporter and customize how objects are serialized. So If we 
> figure out how to do the serialization, putting it in shouldn't be a 
> problem.
>
> Dennis Sosnoski wrote:
>
>> I took a look at the XMLBeans data binding implementation for Axis2, 
>> and have got some questions about this. For one thing, it looks like 
>> the toOM() methods actually build the OM representation of the 
>> databound objects, while I thought the idea behind Axis2 was to keep 
>> the OM virtual unless absolutely necessary (for something like signing).
>
>
>
>>
>> Also, the way in which Axis gets the data out of the databound 
>> objects is by using an XMLStreamReader. AFAIK, XMLBeans is the only 
>> framework which directly supports using a reader to get the XML 
>> representation of the objects. Most frameworks (including JiBX and 
>> JAXB 2.0) only support push-style output, where you tell the 
>> framework to serialize the XML representation to some form of output 
>> interface and it does so before returning. We could write an adapter 
>> to basically store the output from one of these frameworks and make 
>> it readable using an XMLStreamReader, but it would probably have a 
>> substantial impact on performance.
>>
>> For other data binding frameworks it's probably best to define a 
>> special type of OMElement to hold on to the object and the 
>> corresponding serializer until the serialize() method of the 
>> OMElement is called, then serialize directly to the supplied target. 
>> If we need to instead create a full OM representation, we can use a 
>> builder that implements the XMLStreamWriter interface and supply this 
>> to the binding framework as the target for the marshalling output. 
>> This does make for an all-or-nothing expansion, but this is probably 
>> the best we can do with most data binding frameworks.
>>
>> There's also the issue of how to link data binding to the MTOM 
>> support, so that a data binding framework can pass off components to 
>> be marshalled as attachments (and likewise access attachments for 
>> unmarshalling). I don't know if XMLBeans has any support for this 
>> yet, but JAXB 2.0 has it and I'll be adding it into JiBX.
>>
>>  - Dennis
>>
>
>