axis-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Vardeman <andr...@iastate.edu>
Subject Re: The low-down on rpc vs. doc within Axis
Date Tue, 23 Apr 2002 22:28:26 GMT
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



Mime
View raw message