Hi, Ant. SOAP DataBinding is one of the areas we would like to explore to see if it fits into the dynamic nature of Tuscany WebService invocations. I'm not sure if you have noticed that we do have some early prototypes for Axis 1.x Serializer/Deserializer. They are in the "org.apache.tuscany.binding.axis.encoding.impl" package.
Thanks, Raymond ----- Original Message ----- From: "ant elder" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, January 13, 2006 2:49 AM Subject: Re: AXIS2 integration (SDO<-->AXIOM and more...) Would an alternative be to have closer integration btw Tuscany and Axis2? >From the brief look I've had at the Tuscany code it seems like it really has its own completely separate SOAP engine. It builds the SOAP envelope on its own and passes that to Axis just for QOS and transport things. So could an alternative be to create an Axis2 data binding for SDO's and let Axis2 handle the constructing of the SOAP envelope? That way Tuscany wouldn't have to worry about all usual issues like rpc/enc, SOAP 1.1/1.2, attachments, MTOM etc. ...ant On 1/12/06, Raymond Feng <[EMAIL PROTECTED]> wrote: > > I would like to start the disucssion on AXIS2 integration for Tuscany. > > I started to prototype the AXIS2 support for Tuscany web service binding. > Following the similar approach as we do for Axis 1.x, the key enabling > factor is the serialization/deserialization from SDO to AXIOM and vice > versa. Generally speaking, it's all about the transformations between > different XML bindings for the same data. Please see the attached the > diagram for some examples. > > As the default data model for Tuscany, SDO DataObject is used to represent > the input/output/fault message for web services. (Later on, it could be > pluggable.) > > In Axis 1.x, the SOAP envelope is a DOM-based model. > > Serialization: SDO --> DOM (SOAP) > Deserialization: DOM --> SDO > > Due to some issues of the DOM support in the SDO 1.0 implementation, we > made some workarounds in the current code base. So the real path may look > like this: > > Serialization: SDO --> String --> SOAP > Deserialization: SOAP --> String --> SAX --> SDO > > In Axis 2, SOAP messages are modeled using AXIOM (AXis Object Model) which > is an XML object model working on StAX (Streaming API for XML) parsing > optimized for SOAP 1.1/1.2 Messages. The ideal path should be: > > Serialization: SDO --> StAX --> SOAP (AXIOM) > Deserialization: SOAP (AXIOM) --> StAX --> SDO > > The StAX support is not there yet in the current SDO implementation. So I > took a hacky way and managed to make this path work with the Axis2 0.93driver for the outbound Web Service call. > > Serialization: SDO --> AXIOM (by the special XMLSaveImpl which creates > AXIOM attributes/elements/text in a similar way as DOM) > Deserialization: AXIOM --> StAX --> StAX2SAXAdapter --> SAX --> SDO > > Now it becomes desirable to have a set of flexible SDO2 > serializer/deserializers (or XMLResource in the SDO/EMF term) as follows: > > SAX: Generate SAX events from DataObject and load DataObject from SAX > events > Stax: Implement StAX XMLStreamReader for a given DataObject and load > DataObject from XMLStreamReader (potentially can support lazy-loading of > DataObject?) > DOM: Create DOM tree from DataObject and load DataObject from DOM > > IMHO, these utilities will not only benifit the SDO/Axis integration, but > also the transformation between SDO and other models like JAXB and XMLBeans. > > Ideas? Opinions? > > Thanks, > Raymond > >
