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
