axis2 data-binding
DESCRIPTION
Axis2 Data-binding. Thoughts …. Major changes from Axis 1.x. Investigate the possibility of using data binding tools…XmlBeans, JAXB, Castor… Focus on doc/lit (Hi Glen... ) RPC lit/enc will be layered on top of doc/lit. “Java” Objects. Entities involved. - PowerPoint PPT PresentationTRANSCRIPT
Axis2 Data-binding
Thoughts…
Major changes from Axis 1.x
• Investigate the possibility of using data binding tools…XmlBeans, JAXB, Castor…
• Focus on doc/lit (Hi Glen... )
• RPC lit/enc will be layered on top of doc/lit
Entities involved
“Java” Objects
XML
AXIOM
DOM
StAX or SAX
StAX or SAX
StAX
Generated code (specific to data-binding framework used)
Issues…
• It is desirable to support many data binding tools
• Different tools use very different marshalling/unmarshalling mechanisms– Shall we standardize on JAXB?...
• The data-binding tool, generated code and service implementation are tightly coupled
• So… to change the tool means to regenerate code…
Issues (cont.)
XML Schema Interfaces
Implementation classes
Is it possible to decouple these?
Anyone of aware of type substitution is JAXB?
Issues…
• In the case of RPC lit or enc we shall transform the schema specified in WSDL before passing it on to the data binding framework
• This will not allow the use of multi-refs on outgoing messages…
• However, if it is really important (ahh…) we can tweak the StAX parser/OM to handle it on behalf of the data-binding framework on incoming messages… do we need this???
At the moment…
• We have a WSDL2Java toy that works for WSDL 1.x & Doc/lit ONLY…
• Can generate SEI, Stubs & Skeletons using XMLBeans…
• The tool uses Schema Object Model of XMLBeans… hence cannot plug-in other data-binding tools
Plans for the future…
• Do what we have done for XMLBeans for JAXB, Castor etc…
• Identify a generic architecture where tools are pluggable…
• Support for RPC encoded/literal based on the strategy of schema transformation…
Thanks…