RE: rpc-literal and document-literal

[th...@ascentialsoftware.com]

I am also coming late in this discussion, but I just revisited this thread
of emails after spending some time trying to understand some details of the
WSDL 1.1 specifications. I have one comment/question directly related to the
thread content and then one question that I would like to add to this
thread.

- When you say "With document/literal the routing information is part of the
data", this is not entirely true, is it? What about the SOAPAction HTTP
header? Agree that this is specific to HTTP transport, but as more transport
are and will be defined, don't you think that such mechanism will be define
in each of them to handle the routing information?

- The question that I'd like to add is related to the document-literal with
message part referencing a concrete schema definition using the type
attribute (and not the element one). Here is the corresponding extract from
the WSDL1.1 specification (end of section 3.5): 

If use is literal, then each part references a concrete schema definition
using either the element or type attribute. In the first case, the element
referenced by the part will appear directly under the Body element (for
document style bindings) or under an accessor element named after the
message part (in rpc style). In the second, the type referenced by the part
becomes the schema type of the enclosing element (Body for document style or
part accessor element for rpc style). For an example that illustrates
defining the contents of a composite Body using a type, see section 2.3.1.
The value of the encodingStyle attribute MAY be used when the use is literal
to indicate that the concrete format was derived using a particular encoding
(such as the SOAP encoding), but that only the specified variation is
supported ("writer makes right").

What I am not sure to understand is "In the second, the type referenced by
the part becomes the schema type of the enclosing element (Body for document
style ....". First, I am not sure to understand how any schema type can be
assigned to the soap:body element itself (but may be I miss-understood the
concept of schema type) and then, what does this mean if the message has
multiple parts? Which schema type is supposed to be used (actually, the
whole notion of document-literal web service when there is multiple message
parts is not very clear for me)?

Any comments will be appreciated.

Thanks

Thomas

-----Original Message-----
From: Eric Rajkovic [mailto:eric.rajkovic@oracle.com] 
Sent: Friday, August 23, 2002 6:07 PM
To: axis-user@xml.apache.org
Cc: Ted Neward
Subject: Re: rpc-literal and document-literal


One way I like to think about rpc/lit vs. doc/lit is in the design of the
schema that will be used.

With document/literal the routing information is part of the data. With
rpc/literal the operation name is embeded for me by the framework. I do not
have to craft a separate schema for each operation I have to expose.

On the wire, we can argue that both are identical and we do not need
rpc/literal as the tools can generate the wrapper elements.

A concrete example where I'll expose a service as rpc/lit instead of doc/lit
is a case where I have to expose multiple operations that use the same
schema (the classic getEmployee / getManager or select/update/insert using
Oracle XML SQL Utility -XSU).

You can find a live example of rpc/lit endpoint on OTN
(http://otn.oracle.com/ws/deptemp?WSDL).

Eric

Sam wrote:

> That sounds like the rpc v/s messaging discussion.
>
> I was taling more specifically about the encoding issue, unless youre 
> saying that doc-literal is same as messaging. Which i think is not the 
> case
>
> /s
>
> Ted Neward wrote:
> >
> > It's really more of a "Zen" thing--rpc/encoded is the act of 
> > replicating a call stack, whereas doc/literal is the act of passing 
> > messages, much in the same differentiation between RMI and JMS. In 
> > many ways, one can look at RMI and simply say, "Oh, that's easy, 
> > that's just passing an 'input' message to an endpoint, and receiving 
> > an 'output' message back." This in turn begs the question, what's 
> > the choice between RMI and JMS? Or, in short, what's the choice 
> > about between any messaging-based application, and an RPC-based one?
> >
> > A messaging-based app usually offers more in the way of 
> > flexibility--for example, a messaging-based app can do all sorts of 
> > "oneway" actions without requiring a response, and can offer 
> > store-and-forward kinds of functionality as a result. (Think of the 
> > difference between email--messaging--and a phone call--RPC. One 
> > requires only some supporting plumbing to make sure the message gets 
> > there; the other requires the same plumbing, but also that the 
> > recipient be there, ready to answer the incoming request and send back a
> > response.) The commensurate cost that goes with a messaging application
is
> > the overhead of tying "request" and "response" together--identifying
that
> > *this* response goes with *that* request five minutes ago, and so on.
(JMS
> > has some headers they reserve for precisely this purpose.)
> >
> > Ted Neward
> > {.NET || Java} Course Author & Instructor, DevelopMentor
> > (http://www.develop.com)
> > http://www.javageeks.com/tneward http://www.clrgeeks.com/tneward
> >
> > ----- Original Message -----
> > From: "Sam" <by...@Phreaker.net>
> > To: "axis" <ax...@xml.apache.org>
> > Sent: Sunday, July 21, 2002 5:16 PM
> > Subject: rpc-literal and document-literal
> >
> > > I was trying to think of the use cases where one would prefer to 
> > > use document-literal over rpc encoded and drew a blank.
> > >
> > > Can anyone highlight why an application would choose 
> > > document-literal or rpc-literal as the message format ?
> > >
> > > What would such a use case look like ?
> > >
> > >
> > > Thanks
> > > /s
> > >
> > >