axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark D. Hansen" <>
Subject RE: [Axis2] design direction related to Java/XML binding
Date Fri, 28 Jan 2005 10:50:13 GMT
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 []
> Sent: Friday, January 28, 2005 4:22 AM
> To:
> 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 
> ( 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=""> 
> >  <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

View raw message