RE: [Axis2] design direction related to Java/XML binding

["Mark D. Hansen" <m....@verizon.net>]

Eran,

Thanks.  I am looking at the code now.  I assume that the right place to
look is in java/dev/scratch/prototype2 ??

I see org.apache.axis.om.OMSerializer which looks like the serialization
interface that a XML-Java binding tool would use.  And, I see the
org.apache.axis.encoding.Encoder which looks like the deserialization
interface that an XML-Java binding tool would use.  Am I understanding
the architecture correctly?

So, suppose that I create OMSerializer and Encoder wrappers for my
favorite XML-Java binding "thingy".  How do I specifiy that my service
should use these?  Said another way, how do I deploy these
[de]serializers along with my service?

-- Mark


> -----Original Message-----
> From: Eran Chinthaka [mailto:chinthaka@opensource.lk]
> Sent: Sunday, January 30, 2005 10:35 PM
> To: axis-dev@ws.apache.org
> Subject: RE: [Axis2] design direction related to Java/XML binding
> 
> 
> Hi Mark, 
> 
> Talking about a pluggable xml binding, the current Axis 2 
> architecture is
> such that, you can plug in "any" data binding tool. This is 
> supported by
> AXIOM, THE object model of Axis 2. 
> 
> AXIOM exposes itself to outside world through StAX writer and reader
> interfaces and any data binding tool can work on that. 
> 
> Well, take a look at the code and we really appreciate your comments.
> 
> Eran Chinthaka
> 
> -----Original Message-----
> From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk] 
> Sent: Saturday, January 29, 2005 5:09 PM
> To: axis-dev@ws.apache.org
> Subject: Re: [Axis2] design direction related to Java/XML binding
> 
> 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" <m....@verizon.net>
> To: <ax...@ws.apache.org>
> 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:aslom@cs.indiana.edu]
> > > Sent: Friday, January 28, 2005 4:22 AM
> > > To: axis-dev@ws.apache.org
> > > 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
> > >
> >
> >
> 
> 
> 
>