It's glad to see your help. I think two things need to happen to support the databinding-based integration with Axis.
1) Implement the Serializer/Deserializer for SDO DataObject based on the Axis databinding interfaces (The prototype for Axis1.3 has been in code base and I unit-tested it by modifying the generated stub. I'm also looking into the Axis2 version, i.e., StAX support for SDO). 2) The WebServiceHandler need to base on the SCDL metadata to create Axis calls dynamically with required options, set input parameters and register Serializer/Deserializer factories for the SDO classes/interfaces so that the Axis engine can deal with SDO DataObjects. I'm not sure if it's possible to register the factories against an interface such as "commonj.sdo.DataObject" or it has to be the concrete class for a given parameter. Item 2 would be a good starting point for you. I also feel it would be simpler to get this approach work for Axis 1.3 first. Any thoughts? Thanks, Raymond ----- Original Message ----- From: "ant elder" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, January 26, 2006 2:53 AM Subject: Re: AXIS2 integration (SDO<-->AXIOM and more...) 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 > > > > >
