Ant I agree. It seems to me that Tuscany should create the SOAP body and Axis2 should do the rest. Then we would re-use a lot of existing code.
Paul On 1/13/06, ant elder <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > -- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com
