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: domain of ajith.ranabahu@gmail.com
 designates 64.233.170.197 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=QbjVwPNqCHUMc1JfRwq2uEIgg/YaW4FkOKzkgyIfCIBBYeJuCF4fdKPZtGHnXKvXKMXpR4rBMZ2vUFm8FvGlfNTJTVr3xaU9gYYEHkkwtrRf69ejzJsKJK+RQ4BlMB8g/+16C2VfXOCspix+tfSS1460ao6UTUMoXtolPz9KS9g=
Message-ID: <430947EE.20108@gmail.com>
Date: Mon, 22 Aug 2005 09:35:10 +0600
From: Ajith Ranabahu <ajith.ranabahu@gmail.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
MIME-Version: 1.0
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] Databinding API issues
References: <43057D69.2050508@sosnoski.com>
In-Reply-To: <43057D69.2050508@sosnoski.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
>