axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <as...@cs.indiana.edu>
Subject Re: [Axis2] design direction related to Java/XML binding
Date Sun, 30 Jan 2005 19:43:41 GMT
Mark D. Hansen wrote:

>Cool.  I will look at M1.  Is there anonymous CVS access to the source or do only the
committers have access to source at this point?
>  
>
you can use svn to do anon checkout - there are some instructions here
http://wiki.apache.org/ws/FrontPage/Axis2

you can browse repository:
http://svn.apache.org/repos/asf/webservices/axis/trunk/java/dev/scratch/prototype2/

and in it the worst case we can send you tarball :)

alek

>  
>
>>-----Original Message-----
>>From: Sanjiva Weerawarana [mailto:sanjiva@opensource.lk]
>>Sent: Saturday, January 29, 2005 6:09 AM
>>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
>>>>
>>>>        
>>>>
>>>      
>>>
>
>  
>


-- 
The best way to predict the future is to invent it - Alan Kay


Mime
View raw message