Document/RPC -- real differences .... was Re: style="document" rulz!

[Adam Jack <aj...@openbiz.biz>]

Sorry guys, I think my last posting (on RPC being easier) was noise borne of
frustration [see next] which I should have channeled more productively. I
suspect a Document verses RPC argument will still be raging in years to
come, and I suspect the answer is simple --- both have their place --- I
merely knee jerked to the defense of RPC based off a bad afternoon w/ AXIS
and Document style, and what I felt was a sweeping generalization.

To what matters:

I switched to AXIS from SOAP 2.2 in part to gain interoperability w/
.Net --- a stated goal of AXIS. I've picked up SOAP encoding simplicity, I
don't need to solve that problem any more, but it seems that the problem has
moved. AXIS likes RPC style, and .Net defaults to Document style (even for
IMHO RPC type things).

I was fighting AXIS [which I beleive has reasonably limited DII support for
Document style, even though I've read the AdminClient, read stubs generated
by WSDL2Java, and have now *once* made it work] especially in respect to
building documents to match the types specified in the WSDL. Now AXIS is
doing lots of wonderful things, and I am sure it is somebody elses pervue to
convert XSD schemas to/from DOM, but it sure would be nice to have the one
stop shop, like one gets with AXIS for RPC. Something that helps me build
the simple document (especially when it is simple) and call, almost like I
was calling RPC.

Personally, I start to question what Document style over SOAP gives over
Document's sent over HTTP [or other] it is a thin pipe, but I am sure
greater experts will explain plug-in points for security/signing/transport
abstrations, etc. I am sure there may be a benefit, but it starts to get a
bit fuzzy for me.

That said, if AXIS [as a client as well as server] is to be interoperable
with .Net then I feel there needs to be some more work put in to the DII
aspects of AXIS, a tighter integration of the types/XSD in the WSDL w/ the
AXIS APIs, and so forth. If not that -- then at least a slightly enhanced
API (so I don't have to use StringBufferInputSteam, a deprecated class, but
a Reader or other) to work w/ my various flavours of XML/data.

Note: I know it is all time and commitment. I am getting more and more
familair w/ AXIS, and perhaps I can help here, but for now [as I am still
getting inside the AXIS code] I can give feedback as I find it. (Hopefully a
bit more considered than the previous knee jerk.)

P.S. If anybody knows why I am gettign the RPCBodyElement return (in the
other other posting, and I merely assume bug) please let me know. For now
I'll do what AdminClient does, I'll cast it to SOAPBodyElement, do a
toString() to extract the XML, then re-parse & process.

regards,

Adam