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. 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. 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 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. 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. Thanks, Mark
