[Axis2]Data binding API?

[Dennis Sosnoski <dm...@sosnoski.com>]

I recently made some changes (going into JiBX RC1) to support using JiBX 
with SOAP. These are primarily designed around what I've found was 
necessary for JibxSoap, but I'm also planning to hook into Axis2 and the 
same requirements are likely to apply there. I know the 0.9 version has 
XmlBeans support in place - has anything been done yet to define a 
general-purpose API usable with other data binding frameworks? I'm 
interested both in runtime support and code generation (so that there's 
a way for Axis to pass off a schema subset to be handled by the data 
binding framework, along with any appropriate customization parameters 
for the data binding code generation, and get back some sort of map from 
types to classes).

I'm also curious if anyone has considered how MTOM is going to work in 
combination with data binding. It seems like there'll have to be some 
way for the data binding framework to pass back information about the 
blobs to be sent as attachments, and to access the attachments when 
unmarshalling. In the case of JiBX I'm planning to add that in 1.1 with 
an internal API that allows JiBX to communicate with whatever runs the 
transport, then supply separate implementations of the transport 
interface for different usages (JibxSoap, Axis2, etc.). That aspect of 
MTOM has always seemed a bad smell to me, but since The Powers That Be 
(AKA the W3C) have decided it's the wave of the future I'll do my best 
to work with it.

  - Dennis

Re: [Axis2]Data binding API?

[Aleksander Slominski <as...@cs.indiana.edu>]

Dennis Sosnoski wrote:

> Hi Ajith,
>
> Sounds great on the data binding support! I'll check it out within the 
> next couple of weeks. JiBX currently uses XMLPull for input, but I can 
> probably implement a simple wrapper for converting between the Axis 
> StAX parser and an XMLPull API. Are you listening, 

that should be very easy - those two APIs are very similar (XmlPull is 
just much smaller providing all functionality in two interfaces and one 
factory ...)

> Alek - any comments? 

around but just insanely busy :)

> The output may be a little tougher, since that's oriented toward 
> writing directly to a stream through a custom interface; it may 
> require some post-1.0 tweaks to JiBX, but shouldn't present any major 
> problems.

i am much more concerned with supporting multiple data binding models 
and flexible pipeline to allow databinding of parts of XML message or 
not binding for parts of it at all (for example binding some header but 
not binding parts of SOAP body or binding it efficiently into int[] and 
bypassing XmlBeans that is used for other parts ...)

best,

alek ("busy")

>
> Ajith Ranabahu wrote:
>
>> Hello Dennis,
>>
>> The internals of the Databinding framework are as follows
>>
>> 1. We have something called extensions that run before the actual
>> code generator. For XMLBeans we have an extension that takes the
>> Schema element from the WSDL file and feeds it into the XB schema
>> parser. The logic of XB is completely inside the XB extension. After
>> the XB code generation, a type mapper is populated with the generated
>> types and passed on to the Axis2 code generator.
>> 2. The generated classes include something called the
>> DataBindSupporter. DataBindSupporter has 'toOM' and 'FromOM' methods
>> which accept either a generated object and or the omelement
>> respectively and does the necessary conversion. The databinding logic
>> is completely inside the databinding supporters.
>>
>> So as you can see the codegenerator is completely based on the
>> strategy of passing a schema element and getting the type map. You can
>> customize it with minimum effort. In particular have a look at the
>> XMLBeansExtension.java class in the
>> org.apache.axis2.wsdl.codegen.extension package
>>
>> As for the MTOM support we have not yet thought about it seriously (I
>> mean how it affects code generation :)). Since MTOM is solely a
>> transport time thingy (no description of it in the XSD or the WSDL) we
>> were thinking of a user switch in the tool that will generate a
>> slightly different bunch of code which optimizes the output.
>>
>> On 7/14/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>  
>>
>>> I recently made some changes (going into JiBX RC1) to support using 
>>> JiBX
>>> with SOAP. These are primarily designed around what I've found was
>>> necessary for JibxSoap, but I'm also planning to hook into Axis2 and 
>>> the
>>> same requirements are likely to apply there. I know the 0.9 version has
>>> XmlBeans support in place - has anything been done yet to define a
>>> general-purpose API usable with other data binding frameworks? I'm
>>> interested both in runtime support and code generation (so that there's
>>> a way for Axis to pass off a schema subset to be handled by the data
>>> binding framework, along with any appropriate customization parameters
>>> for the data binding code generation, and get back some sort of map 
>>> from
>>> types to classes).
>>>
>>> I'm also curious if anyone has considered how MTOM is going to work in
>>> combination with data binding. It seems like there'll have to be some
>>> way for the data binding framework to pass back information about the
>>> blobs to be sent as attachments, and to access the attachments when
>>> unmarshalling. In the case of JiBX I'm planning to add that in 1.1 with
>>> an internal API that allows JiBX to communicate with whatever runs the
>>> transport, then supply separate implementations of the transport
>>> interface for different usages (JibxSoap, Axis2, etc.). That aspect of
>>> MTOM has always seemed a bad smell to me, but since The Powers That Be
>>> (AKA the W3C) have decided it's the wave of the future I'll do my best
>>> to work with it.
>>>
>>>  - Dennis
>>>
>>>   
>>
>>
>>
>>  
>>


-- 
The best way to predict the future is to invent it - Alan Kay

Re: [Axis2]Data binding API?

[Dennis Sosnoski <dm...@sosnoski.com>]

Hi Ajith,

Sounds great on the data binding support! I'll check it out within the 
next couple of weeks. JiBX currently uses XMLPull for input, but I can 
probably implement a simple wrapper for converting between the Axis StAX 
parser and an XMLPull API. Are you listening, Alek - any comments? The 
output may be a little tougher, since that's oriented toward writing 
directly to a stream through a custom interface; it may require some 
post-1.0 tweaks to JiBX, but shouldn't present any major problems.

  - Dennis

Ajith Ranabahu wrote:

>Hello Dennis,
>
> The internals of the Databinding framework are as follows
>
> 1. We have something called extensions that run before the actual
>code generator. For XMLBeans we have an extension that takes the
>Schema element from the WSDL file and feeds it into the XB schema
>parser. The logic of XB is completely inside the XB extension. After
>the XB code generation, a type mapper is populated with the generated
>types and passed on to the Axis2 code generator.
> 2. The generated classes include something called the
>DataBindSupporter. DataBindSupporter has 'toOM' and 'FromOM' methods
>which accept either a generated object and or the omelement
>respectively and does the necessary conversion. The databinding logic
>is completely inside the databinding supporters.
> 
> So as you can see the codegenerator is completely based on the
>strategy of passing a schema element and getting the type map. You can
>customize it with minimum effort. In particular have a look at the
>XMLBeansExtension.java class in the
>org.apache.axis2.wsdl.codegen.extension package
>
>As for the MTOM support we have not yet thought about it seriously (I
>mean how it affects code generation :)). Since MTOM is solely a
>transport time thingy (no description of it in the XSD or the WSDL) we
>were thinking of a user switch in the tool that will generate a
>slightly different bunch of code which optimizes the output.
>
>On 7/14/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>  
>
>>I recently made some changes (going into JiBX RC1) to support using JiBX
>>with SOAP. These are primarily designed around what I've found was
>>necessary for JibxSoap, but I'm also planning to hook into Axis2 and the
>>same requirements are likely to apply there. I know the 0.9 version has
>>XmlBeans support in place - has anything been done yet to define a
>>general-purpose API usable with other data binding frameworks? I'm
>>interested both in runtime support and code generation (so that there's
>>a way for Axis to pass off a schema subset to be handled by the data
>>binding framework, along with any appropriate customization parameters
>>for the data binding code generation, and get back some sort of map from
>>types to classes).
>>
>>I'm also curious if anyone has considered how MTOM is going to work in
>>combination with data binding. It seems like there'll have to be some
>>way for the data binding framework to pass back information about the
>>blobs to be sent as attachments, and to access the attachments when
>>unmarshalling. In the case of JiBX I'm planning to add that in 1.1 with
>>an internal API that allows JiBX to communicate with whatever runs the
>>transport, then supply separate implementations of the transport
>>interface for different usages (JibxSoap, Axis2, etc.). That aspect of
>>MTOM has always seemed a bad smell to me, but since The Powers That Be
>>(AKA the W3C) have decided it's the wave of the future I'll do my best
>>to work with it.
>>
>>  - Dennis
>>
>>    
>>
>
>
>  
>

Re: [Axis2]Data binding API?

[Glen Daniels <gl...@thoughtcraft.com>]

Hi folks:

Please check out http://www.w3.org/TR/xml-media-types/

This document describes runtime and design time attributes to indicate 
media types for base64 (and therefore potentially optimized) content. 
When we see these annotations in schema, we should have the ability to 
default to optimized transport.

It is probably the data binding layer that does this work, but we should 
keep in in mind as we move forward.

--Glen

Re: [Axis2]Data binding API?

[Dennis Sosnoski <dm...@sosnoski.com>]

Thilina Gunarathne wrote:

> IMHO this is doable with the way Axis2 currently handles MTOM. We use 
> OMText to hold the binary data and act as the blob. There are several 
> states to OMText,  which can be set using "is Binary" and 
> "isOptimised" attributes. When OMText contains binary data (either as 
> base64 or pure binary) we set this to true. Then if those data are 
> qualified to optimise then we can set "isOptimised" to true.

The only problem with this is that it requires everything to go through 
the OM. My understanding of how things were going to work in Axis2 was 
that the OM would only be used when needed, and that in general 
deserializers would read directly from the parser and serializers would 
write directly to the output. Has this approach changed?

  - Dennis

Re: [Axis2]Data binding API?

[Thilina Gunarathne <cs...@gmail.com>]

Hi,
>data binding framework to pass back information about the
> blobs to be sent as attachments, and to access the attachments when
> unmarshalling. 
 IMHO this is doable with the way Axis2 currently handles MTOM. We use 
OMText to hold the binary data and act as the blob. There are several states 
to OMText, which can be set using "is Binary" and "isOptimised" attributes. 
When OMText contains binary data (either as base64 or pure binary) we set 
this to true. Then if those data are qualified to optimise then we can set 
"isOptimised" to true. 
 Data Binding framework can access the attachments when unmarshaling using 
these OMText objects. When there's an optimised binary attachment present, 
the infoset contains an <XOP:Include> element which we represent using 
OMText and it contains the reference to that attachment. Also it can be used 
to get the content of that attachment.
 Also when sending binary things, data binding framework can use a 
programmatically created OMText. If it is to be optimised it can set the 
"isOptimized'' attribute.
 IMO i feel MTOM is merging the transport and info set.. Even though no 
description of it is in the XSD or the WSDL, we can identify a Attachment by 
looking at the XML it self......
Also http://www.ws-i.org/Profiles/AttachmentsProfile-1.0-2004-08-24.htmldefines
some way to describe mime parts in WSDL. May be this can help us a
bit for databinding.....
 eg:
 <input>
<mime:multipartRelated>
<mime:part>
<soapbind:body part="body" use="literal"/>
</mime:part>
<mime:part>
<mime:content part="ns:bar1"/>
</mime:part>
</mime:multipartRelated>
</input>
  Thanks & Regards,
~Thilina
 

 On 7/14/05, Ajith Ranabahu <aj...@gmail.com> wrote: 
> 
> Hello Dennis,
> 
> The internals of the Databinding framework are as follows
> 
> 1. We have something called extensions that run before the actual
> code generator. For XMLBeans we have an extension that takes the
> Schema element from the WSDL file and feeds it into the XB schema
> parser. The logic of XB is completely inside the XB extension. After
> the XB code generation, a type mapper is populated with the generated
> types and passed on to the Axis2 code generator.
> 2. The generated classes include something called the
> DataBindSupporter. DataBindSupporter has 'toOM' and 'FromOM' methods
> which accept either a generated object and or the omelement
> respectively and does the necessary conversion. The databinding logic
> is completely inside the databinding supporters.
> 
> So as you can see the codegenerator is completely based on the
> strategy of passing a schema element and getting the type map. You can
> customize it with minimum effort. In particular have a look at the
> XMLBeansExtension.java class in the
> org.apache.axis2.wsdl.codegen.extension package
> 
> As for the MTOM support we have not yet thought about it seriously (I
> mean how it affects code generation :)). Since MTOM is solely a
> transport time thingy (no description of it in the XSD or the WSDL) we
> were thinking of a user switch in the tool that will generate a
> slightly different bunch of code which optimizes the output.
> 
> On 7/14/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> > I recently made some changes (going into JiBX RC1) to support using JiBX
> > with SOAP. These are primarily designed around what I've found was
> > necessary for JibxSoap, but I'm also planning to hook into Axis2 and the
> > same requirements are likely to apply there. I know the 0.9 version has
> > XmlBeans support in place - has anything been done yet to define a
> > general-purpose API usable with other data binding frameworks? I'm
> > interested both in runtime support and code generation (so that there's
> > a way for Axis to pass off a schema subset to be handled by the data
> > binding framework, along with any appropriate customization parameters
> > for the data binding code generation, and get back some sort of map from
> > types to classes).
> >
> > I'm also curious if anyone has considered how MTOM is going to work in
> > combination with data binding. It seems like there'll have to be some
> > way for the data binding framework to pass back information about the
> > blobs to be sent as attachments, and to access the attachments when
> > unmarshalling. In the case of JiBX I'm planning to add that in 1.1 with
> > an internal API that allows JiBX to communicate with whatever runs the
> > transport, then supply separate implementations of the transport
> > interface for different usages (JibxSoap, Axis2, etc.). That aspect of
> > MTOM has always seemed a bad smell to me, but since The Powers That Be
> > (AKA the W3C) have decided it's the wave of the future I'll do my best
> > to work with it.
> >
> > - Dennis
> >
> 
> 
> --
> Ajith Ranabahu
> 



-- 
"May the SourcE be with u" 
http://www.bloglines.com/blog/thilina

Re: [Axis2]Data binding API?

[Ajith Ranabahu <aj...@gmail.com>]

Hello Dennis,

 The internals of the Databinding framework are as follows

 1. We have something called extensions that run before the actual
code generator. For XMLBeans we have an extension that takes the
Schema element from the WSDL file and feeds it into the XB schema
parser. The logic of XB is completely inside the XB extension. After
the XB code generation, a type mapper is populated with the generated
types and passed on to the Axis2 code generator.
 2. The generated classes include something called the
DataBindSupporter. DataBindSupporter has 'toOM' and 'FromOM' methods
which accept either a generated object and or the omelement
respectively and does the necessary conversion. The databinding logic
is completely inside the databinding supporters.
 
 So as you can see the codegenerator is completely based on the
strategy of passing a schema element and getting the type map. You can
customize it with minimum effort. In particular have a look at the
XMLBeansExtension.java class in the
org.apache.axis2.wsdl.codegen.extension package

As for the MTOM support we have not yet thought about it seriously (I
mean how it affects code generation :)). Since MTOM is solely a
transport time thingy (no description of it in the XSD or the WSDL) we
were thinking of a user switch in the tool that will generate a
slightly different bunch of code which optimizes the output.

On 7/14/05, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> I recently made some changes (going into JiBX RC1) to support using JiBX
> with SOAP. These are primarily designed around what I've found was
> necessary for JibxSoap, but I'm also planning to hook into Axis2 and the
> same requirements are likely to apply there. I know the 0.9 version has
> XmlBeans support in place - has anything been done yet to define a
> general-purpose API usable with other data binding frameworks? I'm
> interested both in runtime support and code generation (so that there's
> a way for Axis to pass off a schema subset to be handled by the data
> binding framework, along with any appropriate customization parameters
> for the data binding code generation, and get back some sort of map from
> types to classes).
> 
> I'm also curious if anyone has considered how MTOM is going to work in
> combination with data binding. It seems like there'll have to be some
> way for the data binding framework to pass back information about the
> blobs to be sent as attachments, and to access the attachments when
> unmarshalling. In the case of JiBX I'm planning to add that in 1.1 with
> an internal API that allows JiBX to communicate with whatever runs the
> transport, then supply separate implementations of the transport
> interface for different usages (JibxSoap, Axis2, etc.). That aspect of
> MTOM has always seemed a bad smell to me, but since The Powers That Be
> (AKA the W3C) have decided it's the wave of the future I'll do my best
> to work with it.
> 
>   - Dennis
> 


-- 
Ajith Ranabahu