Hi Mark, You're absolutely right .. and Axis2 will support the model you're asking for. In particular, it does not assume that Java/XML binding is a core part of the engine that the user must use. This is probably one of the most fundamental changes in Axis2 vs. Axis1.
We're working to get a milestone 1 drop out soon. It would be great if you could look at that and give your thoughts. Bye, Sanjiva. ----- Original Message ----- From: "Mark D. Hansen" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Friday, January 28, 2005 4:50 PM Subject: RE: [Axis2] design direction related to Java/XML binding > 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 > > > >
