Re: rpc-literal and document-literal

[Sam <by...@Phreaker.net>]

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
> >
> >

Does SoapEncoding compliant with WSDL ?

[Ricky Ho <ri...@cisco.com>]

In WSDL, every complex type is described in XML-Schema.  So if you have a 
"Customer" who has an "Address", the XML schema will look as the following ...

<complexType name="Customer">
	<sequence>
		<element name="name" type="xsd:string"/>
		<element name="addr" type="tns:Address"/>
	</sequence>
</complexType>

<complexType name="Address">
	<sequence>
		<element name="street" type="xsd:string"/>
		<element name="city" type="xsd:string"/>
	</sequence>
</complexType>


However, if you pass a "Customer" object as a parameter in a SOAP request, 
the "soap-encoding" will encode the parameter into ...

<multiRef id="id0" xsi:type="Customer">
	<name>....</name>
	<addr href="#id1"/>
</multiRef>
<multiRef id="id1" xsi:type="Address">
	<street>....</street>
	<city>....</city>
</multiRef>


Therefore, the XML after encoding is using a "href" but the WSDL is saying 
that the Address should be embedded into the Customer.  So it seems SOAP 
encoding and WSDL is inconsistent.

It seems to me there is a fundamental mismatch between XML schema and SOAP 
encoding.  XML schema doesn't have a very limited concept of reference 
(id/idref is typeless), complex object will mainly be embedded into another 
complex object.  However, SOAP encoding almost use reference 
exclusively.  Complex object will has a "href" into another complex object.

It seems to me that the problem can be solved if we ....
1) Add a "typed reference" concept in XML-schema.
2) Schema validation can traverse across the "href"

Comments and thoughts ??

Best regards,
Ricky

A different spin, when does rpc-literal better than rpc-soapEncoded ?

[Ricky Ho <ri...@cisco.com>]

Just a different spin, under what scenario should "rpc-literal" be better 
used over "rpc-soapEncoded" ?

Rds, Ricky

Re: rpc-literal and document-literal

[Ricky Ho <ri...@cisco.com>]

Eric,

1) In "rpc/lit", you are exposing a Java method that only has one or more 
"Element" as input parameters and only one "Element" class as return 
value.  You only need to define the schema of your parameters and return 
value.  But you don't need to define the schema of the whole SOAP body 
because the method name and parameter name will "automatically" be included.

2) In "doc/lit", you are exposing a Java method that only has one "Element" 
as input parameter and only one "Element" class as return value.  The 
method name and parameter name will NOT be included, and the single input 
parameter will appear as the direct child of the SOAP body.  Therefore, you 
need to define the schema for the whole SOAP body.

I agree with you that "rpc/lit" has a better reuse of schema 
definition.  It also has a tighter coupling with the method signature.

Best regards,
Ricky

At 03:06 PM 8/23/2002 -0700, Eric Rajkovic wrote:
>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
> > > >
> > > >

Re: rpc-literal and document-literal

[Eric Rajkovic <er...@oracle.com>]

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
> > >
> > >