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:[EMAIL PROTECTED] > 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:[EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> > 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:[EMAIL PROTECTED] > > > 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 > > > > > > > > > > >
