axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark D. Hansen" <>
Subject RE: [Axis2] XML views and flexible/efficient databindg [Re: [Axis2] Can OM with differed building really be so effective in Axis2?
Date Wed, 06 Apr 2005 18:31:40 GMT
> >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 ...

But, in many (probably most) real world scenarios not all the services are Java or CORBA.
 For example, when 2 companies merge, and they want to integrate systems, many would like
to be able to integrate Java (POJO and EJB), .NET, SAP (and other packages), CICS, etc. via
web services standards.  Furthermore, doesn't integration of services over the internet have
to be done via XML over HTTP (can you do RMI over the internet?? - i've never heard of anyone
doing it).

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

yes, in practice the services are usually around long before the message, medium, contract
have been agreed upon ...

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

yes, I need to learn more about JiBX.  Note also that even the "POJOs" generated by the Axis
1.x WSDL2Java contain a lot of "stuff".  And you are right about JAXB - it uses interfaces.
 The internals of the implemenations are far from "POJO"!

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

yes, you are right - the distinction is not Header vs. Body, but SOAP handling vs. web serivce
invocation.  And you are also right that even basic SOAP handling needs some data binding,
but isn't one goal of Axis2 to limit the data binding that goes on prior to web service invocation
as much as possible?

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

For a web service, doesn't the WSDL provide the contract (XML Schema etc.)?  The loss of information
going from XML request -> Java request -> Java response -> XML response for the purpose
of web service invocation shouldn't be a problem as long as the XML response is valid per
the WSDL contract.  The Java response -> XML response conversion is the responsibility
of some serializer that is specified (perhaps as part of a registry) as part of the web service
deployment.  If the guy deploying the web service wants to use a lossy binding, that shouldn't
be a problem as long as his serializer generates XML that is valid wrt the WSDL.  Am I missing

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

Techincally, you are right, but I think that in most scenarios the POJO that gets generated
is going to use at least as much memory as a DOM representation of the original XML.  And,
even when that is not the case, you are still going to get the performance hit becuase you
are almost always going to have to "pull" the entire XML stream through your parser once to
generate the POJO aren't you?  Maybe an exception to this is when your XML has some binary
attachment thingy on it that you are not pulling into the POJO, but other than that, I don't
see how you can do a deserialization without reading the entire XML stream.

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

How would such clustering be implemented?  Wouldn't you, for example, have one Axis2 engine
process a SOAP request up to the point where its target web services has been identified and
then hand off to another Axis2 engine to do the java binding and invoke the service?

View raw message