The low-down on rpc vs. doc within Axis

[Dan Silver <ds...@portera.com>]

Hi everyone -

I'm trying to understand exactly what the differences are when using rpc vs
document style within Axis.  I think I'm getting there, but if people could
validate/refute/comment on/etc. any or all of the items below I'd greatly
appreciate it.

1. A java method exposed as a doc-based service via Axis must basically
conform to the grammar:
public <Document | void> <methodName>(<Document | void>);
 (MessageContext parameter recently removed.)

2. You need to roll your own de/serialization to get to/from object space if
using doc style;

3. (Related to #1) There's currently not SAX support for dealing w/the
payload doc in the impl of a service (seems to be a to-do in
MsgProvider.java);

4. 'Doc style can handle rpc, but not vice-versa."  But if you're
representing rpc calls via messages don't you have to create your own rpc
framework??

Am I on the mark w/this?  If so, it seems that when using doc style you
can't take advantage of many/most of the great benefits of Axis.  I've read
a bunch of stuff that says that to achieve the holy grail of interop you
should stick to doc style, but if the above points are true I don't see how
it would be possible to use tools to make implementation particularly easier
on either the client or server side, since you're not insulated from the xml
layer.  There must be a lot I'm missing here ... does VS .NET generate code
that allows you to stay in object space but still use doc style?

A note of context: I'm trying to determine how to best expose the
functionality of a hosted java app via web services, and my main
compatibility concern is ensuring that .NET clients can access the services.
The rpc-based services I've prototyped thus far work great, and I really
don't want to have to switch to doc-based services....

Thx in advance,

- Dan