The only problem with decoupling the SOAP processing layer from the Javahi Jon,
data binding layer is the implications such an approach has on "intermediary
node" processing. Almost every SOAP stack I've seen implements "SOAP
intermediary nodes" as some sort of interceptor (Axis handlers, JAX-RPC
handlers, .Net WSE filters, Glue filters).
i agree. and that is the reason why one need to be careful about choice of intermediary representation of messages passed in pipeline.
The problems is that intermediary nodes can change the content of the SOAPthis all is fine and can be made to work with flexible use of XML Infoset (based on my experience) until you get to the last part: the requirement of DOM - DOM3 may finally provide mechanisms for customizations so that may be how this will be done in future (still making DOM even more complicated ...)
envelope, plain and simple. This really complicates that SOAP XML data
binding issue. Intermediary node implementations need access to the SOAP
header information at the very least... any type of security processing
(Web Services Security XML Signatures or XML Encryption, for example)
requires access to the entire envelope, typically as a DOM.
Case in point: the WSS4J Axis handlers HAVE to marshall/unmarshall to DOMwhy, o why, there is no SOAP:Footer to allow signatures be computed in streaming fashion?
Level 2, given that the WSS4J XML-Security toolkit of choice (Apache
XML-Security) operates on DOM Document instances. This flies in the face of
Axis' SAX based data binding approach.
Seems to me that a) intermediary nodes are very significant when you'reyes. that is why you want to pass around XML Infoset based documents representing SOAP messages (DOM or something more lightweight). it seems that streaming is lost cause and trying to make SOAP/XML streaming was not considered important enough to guarantee any support in all WS* standards. i can say this based on my lost battle to maintain streaming in XSOAP (or how i started to love document/literal approach ...) i gave up on streaming and by making everything document based implementing all kind of WS-* became much easier.
dealing with the SOAP processing model and b) they could potentially have
their own unique data binding requirements in addition to the data binding
approach the actual service implementation uses.
still i think about possibility of doing a lazy XML infoset tree that would allow to bypass tree creation and access XML stream for not yet parsed parts of XML stream (XmlPullNode is proof of concept of such approach in XPP2).
I'm very anxious to see how the JAX-RPC 2.0 JAXB 2.0 marriage handles thiswe will see :) however based on decisions such as to make SAAJ require DOM i would not put my hopes too high ...
problem.
anyway i do not think that it matters that much. we should not forget that XML and SOAP is about what goes on the wire and how this gets produced is of secondary importance IMHO ...
best,
alek
-----Original Message----- From: Jim Murphy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 2:21 PM To: [EMAIL PROTECTED] Subject: Re: XmlBeans and Axis? [Re: Doc/Literal support in axis
I favor the approach this suggests:
Make the SOAP stack an XML delivery and minimal SOAP processing engine and leave XML<->Java type translation to another layer. Chose Castor, XmlBeans, JAXB 1.0, 2.0 whatever. The choice is dictated by how I want to work witht he XML recognizing that the XML is really what I'm working with!
Jim Murphy Mindreef, Inc.
Aleksander Slominski wrote:
Dennis Sosnoski wrote:
Long term it's clear that real data binding support needs to behi,
integrated into the SOAP framework. JAX-RPC 2.0 has the stated
intention of doing this using JAXB 2.0. Right now you can kind of do
this with Castor in Axis, if you're willing to go through enough
trouble (I've just spent 3 days getting an Axis-Castor example to work
properly, as opposed to less than a day using the hideously complex
JAX-RPC RI for doc/lit, less than a day with Axis rpc/enc (even though
I had to try three different versions of Axis to find one that
worked), and less than a day with Axis doc/lit (again requiring trying
three different versions of Axis before finding a - different - one
that worked). The current Castor in Axis support is basically just
grafted in, to, so you pay a high price in performance.
do you know if anybody tried to add support for XmlBeans (http://xml.apache.org/xmlbeans/) to AXIS?
we have XmlBeans integrated in WS/XSUL (aka XSOAP4) which is document style based in its core so it needs some kind of data binding. XmlBeans works very well in this capacity as it has a very extensive support for XML Schemas (AFAIK there is nothing open source that has better support ...).
thanks,
alek
-- The best way to predict the future is to invent it - Alan Kay
