Ant I'd like to help
Paul On 1/26/06, ant elder <[EMAIL PROTECTED]> wrote: > > I'd be interested in helping with this and have some time now. Raymond, a > while back you said you'd started some prototyping for this, i don't want > to > step on your toes if you're actively working it, are you? Is there > something > I can help you with or could I just dive in and start trying to get > something going? > > ...ant > > On 1/13/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > > > Paul, > > > > +1 from me. I agree that this is the right way to go with Axis2, > > implement Axsi2 databindings for the types of objects that we want to > > flow (and that includes SDOs) and let Axis2 handle the rest. We should > > start working on this as soon as our build and source tree layout > > settle, and we'll welcome any help from you and the Axis2 team to help > > us implement and integrate these databindings. > > > > -- > > Jean-Sebastien > > > > > > > > Paul Fremantle wrote: > > > 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 > > > > > > > > > > -- 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
