Thanks Alek - good points. You may well be right that the performance hit for
"parsing twice" - once into the SOAP engine, and again into the XML-Java
binding "thingy" - may not be a big performance problem except with very large
messages. I should run some performance metrics. I have just been assuming
that my "toy" architecture would not scale at all.
Actually, my interest is much less with performance than with usability in a
typical corporate (e.b., Fortune 500) infrastructure. As I tried to point out
in the "ns:MyCompanyPO" toy example below, my sense is that opening up the Axis
architecture to make a wide range of XML-Java binding "thingies" pluggable is
IMHO important in order to meet the SOA/EAI requirements of enterprise users.
Different communities of users have different preferred XML-Java binding
approaches. So, when you start looking at how practical it really is to use
web services as a technology for interoperability between these communities,
you quickly run into the problem that there is no "one size fits all" mapping
from (for example) <ns:purchaseOrder> ... </ns:purchaseOrder> <---> public
class PurchaseOrder { ... }. The web services approach to integration says
that these communities should standardize on a particular schema for
ns:purchaseOrder. But for them to do that and keep their existing
PurchaseOrder { ... } they must have flexibility to use whatever XML-Java
binding mechanism gets them to/from their prefered implementation of
PurchaseOrder { ... }
That is the main reason that I would like to see Axis2 go with a pluggable
XML-Binding approach.
-- Mark
> -----Original Message-----
> From: Aleksander Slominski [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 28, 2005 4:22 AM
> To: [email protected]
> Subject: Re: [Axis2] design direction related to Java/XML binding
>
>
> Mark D. Hansen wrote:
>
> >I recently read the JIRA AXIS-1498 discussion on pluggable
> XML transformations
> (http://issues.apache.org/jira/browse/AXIS-1498) with great interest.
> >
> >Has the team decided how this will work in Axis2? I'm
> working on a web services based SOA framework and am creating
> a "toy" mechanism to allow pluggable/portable [de]serializers
> on top of any JAX-RPC implementation. Of course, it is very
> inefficient because you first have to let the JAX-RPC
> implementation turn the XML stream in to a SAAJ SOAPElement
> (JAX-RPC API doesn't give access to the XML stream), and then
> apply the XML-Java binding mechanism (e.g., JAXB, Castor,
> XMLBeans, or whatever) to complete the deserialization into
> the desired Java object.
> >
> >
> did you measure how "inefficient" it is? try different sizes
> of XML and
> different XML parsers and you may be surprised with results.
>
> >As suggested in AXIS-1498, it seems to me that a SOAP engine
> ideally would parse just the SOAP header (so handlers can do
> their thing) and the outer elements of the SOAP Body (to
> identify the WSDL operation as in the doc/lit case where
> method name shows up as a wrapper element around the
> parameters). At this point, parsing the actual "meat" should
> be handed off to whatever XML-Java binding mechanism the user
> decides to plug in. In this manner, if I want to deploy a
> method void foo(Bar b), then the SOAP engine would handle it
> as follows:
> >
> >Incoming SOAP message looks like:
> >
> ><env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope";>
> > <env:Header>
> > ...
> > </env:Header>
> > <env:Body>
> > <n1:foo>
> > <n2:Bar>
> > ... serialization of an instance of a Bar ...
> > </n2:Bar>
> > </n2:foo>
> > </env:Body>
> ></env:Envelope>
> >
> >(1) SOAP engine parses <env:Header> and hands off to
> handlers as appropriate
> >(2) SOAP engine parses <env:Body><n1:foo>, but then hands off ...
> >(3) the parsing and deserialization of <n2:Bar> to the
> XML-Java binding mechanism deployed along with the method
> void foo(Bar b).
> >
> >In this manner, deployment of a Java method as a web service
> would allow the deployer to specify the XML-Java binding
> framework. This is similar to how custom type mappings can
> be deployed in Axis, except that it goes a step further than
> just allowing the custom specification of an Axis style
> [de]serializer, but instead enables custom specification of
> the entire XML-Java binding framework.
> >
> >
> i think that it would be handy to be able to deserialize and use
> flexibility in of XML-Java binding for headers too.
>
> >Why is this useful? Because one problem with current SOAP
> engines is that they limit the set of XML types that you can
> map your Java classes to when deploying a service. Suppose
> I've got a class named PO that I want to deploy via something
> like void processPO(PO po). Say my company has standardized
> on a particular XML representation of a PO: ns:MyCompanyPO.
> When I deploy processPO(PO po), I'd like to be able to accept
> instances of ns:MyCompanyPO without having to write a custom
> Axis deserializer to do that because, chances are that I've
> got a good deserializer for ns:MyCompanyPO that maps to the
> java class PO. It might be a custom deserializer, or JAXB,
> or Castor, or XMLBeans, or whatever. But whatever it is, I
> ought to be able to plug it in to Axis without paying a huge
> performance penalty
> >
> i think the performance penalty becomes visible only for
> large messages
> so if you are processing lot of small messages then supporting XML
> streaming infrastructure may be actually more expensive then
> just parse
> input into XML infoset optimized internal representation (this is
> simpler and Java GC is very fast to get rid of it from memory when it
> stays in short-lived heap).
>
> also when sending very big XML messages that needs to preserved then
> using signed MTOM/XOP may be by far the best option (no need to worry
> about XML namespaces/prefixes/c14n/etc nuances)
>
> > while Axis first parses ns:MyCompanyPO into its internal
> Java representation or SAX events and then translating that
> back into an XML stream that my deserializer can use.
> >
> >
> i think it is more complicated in case when you want to do security
> checks (is S:Body signed) or WS-RM (S:Body and whole
> S:Envelope may need
> to be saved until more messages arrive to create sequence).
>
> in general all streaming disappears as soon as anybody
> mentions message
> level security or reliable messaging ;-)
>
> >Another advantage of this approach relates to JAX-RPC 2.0.
> Supporting this standard should be relatively straightforward
> if Axis2 adopts the approach outlined here. Just plug in any
> JAXB 2.0 implementation as the XML-Java binding framework and
> all the type mapping and [de]serialization behavior mandated
> by the JAX-RPC 2.0 spec is done.
> >
> >Does this make sense to any of you Axis2 developers? I'd
> appreciate any feedback.
> >
> >
> it sounds good :)
>
> i am sure it would be useful for AXIS2 to have detailed examples
> (scenario + WSDL + Java code that uses classes from XML
> databinding to
> do something) and revisit how such use cases can be (or not)
> implemented
> in AXIS2.
>
> personally i am leaning towards parsing a XML message into some very
> lightweight in-memory representation (akin AXIOM) that may support
> on-demand parsing of S:Body into XML event stream that is redirected
> into XML-Java databinding "thingy" but as well databinding
> "thingy" can
> enclose existing XML Infoset tree.
>
> as support for as complete as possible XML Schemas is needed more and
> more then i like to use XMLBeans (seems to be the best of
> Castor, JAXB1,
> JaxMe, and even JAXB2 especially that the last one is only in plans)
> even though there are very limited ways to integrate with XMLBeans
> internal XML infoset representation - in some ways XMLBeans is very
> greedy as it wants to parse whole S:Envelope not just content of Body
> whereas i would like it to create a XMLBeans "view" over an
> existing XML
> infoset representation (like for S:Header headers elements or
> DOM:Element after S:Body verification).
>
> just my .02c
>
> alek
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
