Excellent, looks like there's a lot of work to be done with the WS support, not just specifically with Axis2 but also with using the various other Apache WS sub projects for QOS things. Also be good having another Synapsian starting to look at Tuscany so we can start thinking about how they could use each other.
...ant On 1/27/06, Paul Fremantle <[EMAIL PROTECTED]> wrote: > > 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.0implementation, > > > 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 > >
