Mark D. Hansen wrote:
did you measure how "inefficient" it is? try different sizes of XML and different XML parsers and you may be surprised with results.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.
i think that it would be handy to be able to deserialize and use flexibility in of XML-Java binding for headers too.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 the performance penalty becomes visible only for large messages so if you are processing lot of small messages then supporting XMLWhy 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
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
