RE: XML views and flexible/efficient databindg

[Eran Chinthaka <ch...@opensource.lk>]

Hi Mark,

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

Even now Axis2 allows you to plugin "any" standard data binding tool. But in
the last Axis2 summit we all decided to have a small but comprehensive data
binding tool within Axis2 as well. One of our main idea was tightly
integration with Axiom and the user will not have to worry about some other
jars for data binding. 

We will be doing this thru clearly separated interface which will help Axis2
data binding tool to co-exist with other data binding tools.

We agreed AXIOM to have a data binding layer which will be very much
convenient.

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

Well, I have a problem here. If we insert XMLBeans that will be our data
binding framework. So what did u mean by saying "inserting XmlBeans in
between AXIOM and java binding framework".

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

AXIOM will make sure the Xml will be loaded to memory once and for all. But
data binding tool messes that up, we can't do anything. But AXIOM will and
is definitely like that.

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

Interesting idea ..


-- Eran Chinthaka

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