Howdy. >if people could >validate/refute/comment on/etc. any or all of the items below I'd greatly >appreciate it.
don't know much but I'd be happy to ;) >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.) as I noted in an earlier message, there seem to be a number of ways to get at the raw XML. Another way is with this type of method: public Element[] myMethod(MessageContext msgC, Vector elems) I would still like to know where the acceptable method signatures are enumerated... >2. You need to roll your own de/serialization to get to/from object space if >using doc style; That is, if you want to get to/from object space at all. Consider the situation where the SOAP message is used to submit an XML document that is meant as an XML document, not as a data structure to be manipulated in Java code. That's what I'm interested in for the stuff I'm doing. We are going to be passing XML documents representing a chunk of data from our database, but as far as my server software is concerned, the whole payload is one DOM tree that is never anything more than a DOM tree to me in memory. >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?? a doc style service can handle a standard rpc request from the client because the service gets the whole SOAP body to play with. It can then extract whatever elements it wants from the rpc request, using DOM rather than letting Axis automatically deserialize it. Then it can craft its own response (following the rpc standard) and send it back to the client. The client needn't know that the service was a message service. >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? I think the point is that you don't always want to treat everything as a programmatic object. There are other uses for SOAP, and exchanging XML information is a great example. For instance, a client passes the service an XML document as the SOAP body. The service applies an XSL transform that converts the data to an SVG chart and returns it to the client. Okay, that was a ridiculous example, but the point is that XML is fun and there are a lot of applications of SOAP that don't *want* to translate everything to object space. >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.... If your goal is to expose methods that can be invoked remotely, stick with RPC. That's what RPC is designed for. If, on the other hand, you want to pass arbitrary XML data back and forth, use a document service. Andrew
