FYI, we are using woostox in Axis2 (http://woodstox.codehaus.org/) as the stax parser.
-- dims On 1/12/06, Frank Budinsky <[EMAIL PROTECTED]> wrote: > Raymond, > > Since SDO 2 is trying to encapsulate (hide) EMF in its implementation, I > suppose this is a proposal for the SDO 2 project. Maybe it would be even > better to provide these more generally in the EMF project at Eclipse and > then we just provide access to them through SDO 2. Have you discussed this > with the EMF team at Eclipse? > > I thought that SDO/EMF <--> DOM was already working. What problems did you > find? > > I also thought SAX --> SDO should already work ... just not the other > direction. Isn't that right? > > Regardless of where we implement these functions, we'd need someone to > write them ... any volunteers? > > One thing that I'm wondering about is where does the StAX implementation > come from. I thought it wasn't going to available until JDK 1.6? > > Frank. > > "Raymond Feng" <[EMAIL PROTECTED]> wrote on 01/11/2006 08:17:36 PM: > > > 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.93 driver 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 > > > -- Davanum Srinivas : http://wso2.com/blogs/
