axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark D. Hansen" <khook...@yahoo.com>
Subject RE: XML views and flexible/efficient databindg [Re: [Axis2] Can OM with differed building really be so effective in Axis2?
Date Tue, 05 Apr 2005 13:15:10 GMT
But a POJO <--> XML binding is essential for business applications that interoperate
via web services standards (i.e., SOAP, XML, WSDL).  I agree that it is awkward.    And there
are always going to be lots of different ways that people do it (e.g., JAXB, Castor, XmlBeans,
custom mappings, etc).

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.

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

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.

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).

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.

Of course, going from XML --> POJO via any deserializer requires pulling the entire XML
into memory.  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.

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).

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!

-- Mark



> -----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).

Mime
View raw message