axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eran Chinthaka" <chinth...@opensource.lk>
Subject RE: [Axis2] design direction related to Java/XML binding
Date Mon, 31 Jan 2005 03:34:59 GMT
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.hansen23@verizon.net>
To: <axis-dev@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
> >
>
>





Mime
View raw message