Re: [Axis2] XML views and flexible/efficient databindg [Re: [Axis2] Can OM with differed building really be so effective in Axis2?

[Aleksander Slominski <as...@cs.indiana.edu>]

Mark D. Hansen wrote:

>But a POJO <--> XML binding is essential for business applications that interoperate via web services standards (i.e., SOAP, XML, WSDL). 
>
i do not agree. if you have POJO you should use RMI if all you services 
are Java or CORBA if you can assure that everybody get the same IDL that 
is under central control and changes can be controlled and updates 
rolled out.

that will work way better then using XML as serialization format ...

> I agree that it is awkward.
>
XML schemas and WSDL should be crafted first so only appropriate level 
of coupling is required and Web Services peers can interact independent 
form programming language, and in particular independent if they use 
POJO, data bindings or just work with XML directly.

message medium contract  (XML, SOAP, and WSDL/XS/...) should be the 
essential for business applications - of course that is theory but in 
practice ...

>    And there are always going to be lots of different ways that people do it (e.g., JAXB, Castor, XmlBeans, custom mappings, etc).
>  
>
i would add JiBX as it seems to be the most complete of all those 
mappings. JAXB Castor and Xmlbeans are not POJO - there is lot of stuff 
inside those "POJOs" they generate  ... (BTW: i think JAXB does not even 
generate POJO as it generates interfaces and not classes ...)

>IMO, the java binding should NOT be part of core Axis2 (or any SOAP processing engine) - because you don't want to force users to pick a specific binding.  A binding should be a "plug-in".  You can have a plug-in for JAXB, JAX-RPC 1.1, Castor, XmlBeans, etc.
>  
>
i agree

>Axis2 needs a clear boundary between SOAP processing (AXIOM for speed) and Web Service invocation (which requires memory intensive java binding).
>  
>
yes

>This approach requires that you create an API for the java binding plug-in.  A shortcoming of Axis 1.x is that the SAX-based java binding mechanism is deeply intertwined with the SOAP handling mechanism.  Axis2 needs a clean separation of SOAP handling (i.e, header processing) from the java binding that is required for web service invocation.
>  
>
i do not see that this separation ca work. headers needs data binding 
(even DOM or SAAJ can be called databinding as they provide java view on 
XML and many more may be needed...)

>The components of such a plug-in binding API primarily would include: type mapping registry, [de]serialization (binding) context, [de]serializers, and a deployment mechanism for POJOs (that allows you to specify the binding to use).
>  
>
i am very uncomfortable with lossy conversions - unless yo have 
extremely reach mapping metadata you loose infoset in XML->Java 
conversion and when doing Java->XML you may be no longer able to 
construct XML required in contract (XML Schema etc.)

moreover some handlers may need to access XML Infoset even even after 
data binding(s) were executed

>The [de]serializer API needs to be something really simple like:
>
>public XmlObject serialize(Object obj, BindingContext ctx)
>public Object deserialize(XmlObject xojb, BindingContext ctx)
>
>In the above, I use the XmlBeans interface XmlObject as the universal representation of an underlying XML instance.  I like XmlBeans in this role because it is easy to work with.  It can give you DOM like access if the [de]serialization mechanism that you want to port to Axis2 is DOM oriented and it can give you SAX like access to use with SAX based [de]serializers.
>  
>
>I can't comment on what the impact on performance would be of inserting XmlBeans in between AXIOM and the java binding framework.  I assume that it could be a problem.
>  
>
i suspect that too ;-) especially that Xmlbeans is like dual tree: XML 
infoset  + Java binding

>Of course, going from XML --> POJO via any deserializer requires pulling the entire XML into memory. 
>
actually it does not require it if you have deserializer that can read 
from XML event stream (SAX, XmlPull, StAX, etc) for example:

public Object deserialize(XmlPullParser pp, BindingContext ctx)

which i think is already more or less provided by JiBX AFAIK

> So, if the ultimate web service deployed on Axis2 (the business application) requires a POJO, there is no way to avoid brining the entire XML instance into memory.  We just need to make sure that we aren't doing it more than once.
>  
>
it is possible to avoid but that lends itself to use of XML as 
"inefficient serialization" format (the way i used it in SOAP RMI) - 
clunky but works

>So perhaps the Axis2 engine should be designed so that the java binding is handled by a separate pool of threads from the AXIOM-based handler chain?  Users who really care a lot about server performance could configure it so that seperate CPUs handle SOAP processing (high volume) vs. java binding (memory intensive).
>  
>
actually clustering AXIS2 engines would be much more efficient in case 
when services are relatively contained and stateless

>These are just some thoughts.  I'm actually putting some of this stuff (independent of Axis2) into a book, along with a "toy implementation" of a java binding "plug-in" framework for JAX-RPC.  So, I would appreciate any feedback from you gurus out there!
>
>  
>
interesting.

alek


>
>  
>
>>-----Original Message-----
>>    
>>
>
>  
>
>>as of data binding: i have less and less conviction that 
>>creating pure 
>>Java objects (POJO) from XML is a good idea - XML is *not* 
>>POJO and if 
>>you have only POJO you need to maintain (somehow automatic?) very 
>>complicated mappings to reconstruct XML from POJO during 
>>serialization 
>>(i think JiBX attempts to do that).
>>    
>>
>
>  
>


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