local-underground wrote:
Makes sense thanks.
I am just really looking forward to the code generator succesfully spitting out
Java
Beans with Axis2 ;)
With one of my SOAP projects, I decided I am not going to integrate into Axis2
until I
can get Java Beans generated from my WSDL. There are just too many complex
types to
attempt to go in an create elements with attributes, nesting, etc. If WSDL
changes, I
would be really hosed recreating beans by hand.
In my personal opinion, Java Bean generation is essential. There are many of
us out
there that have depended on abstracting from SOAP details even from
manupulating XML in
the request. To integrate into Axis2, folks are not going to want to take on
too much of
a burden getting up to speed with OM, although it appears that can be avoided
entirely.
XML beans does abstract away a lot of the document, while still leaving
you with a lossless mapping to and from XML. There are some of us
(myself included) who believe that the JAXRPC mapping system has mislead
people into using SOAP in a flawed way, because of the fundamental
mismatch between XSD-typed-SOAP-Messages and java object graphs.
One problem with classic JAXRPC and indeed classic SOAP is section-5
encoding. It's soap specific, not as powerful as XSD (for better or
worse), but has some features (references) that make it hard to map
directly to the XSD typesystem. Maybe we need something like XmlBeans
for rpc/enc datatypes, say Section5Beans, which is somehow independent
of the SOAP stack itself.
-steve
