90 likes | 257 Views
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.
E N D
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 Generated code (specific to data-binding framework used) StAX or SAX StAX or SAX DOM AXIOM StAX XML
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…
Interfaces Implementation classes Issues (cont.) XML Schema 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…