From: Anne Thomas Manes <anne_at_manes.net>
Date: Wed, 24 Mar 2004 15:56:21 -0500

Mark,

Okay, perhaps I am confused. Perhaps you can help me understand it better.

Per SOAP 1.1 [1], the SOAP RPC Representation describes the mechanism to represent an RPC on the wire. It is defined in Section 7 of the SOAP specification (listed below). Per WSDL 1.1 [2], the WSDL RPC style attribute affects the way the SOAP Body is structured. Specifically:

"If the operation style is rpc each part is a parameter or a return value and appears inside a wrapper element within the body (following Section 7.1 of the SOAP specification). The wrapper element is named identically to the operation name and its namespace is the value of the namespace attribute. Each message part (parameter) appears under the wrapper, represented by an accessor named identically to the corresponding parameter of the call. Parts are arranged in the same order as the parameters of the call."

Okay -- so that "following Section 7.1 of the SOAP specification" tells me that you really can't disassociate the SOAP RPC Representation from the WSDL RPC style attribute.

Note that the SOAP 1.1 spec states "it is anticipated that this representation is likely to be used in combination with the encoding style defined in section 5" -- although other representations are possible.

I interpret this statement to mean that the authors expected folks to use RPC/Encoded, but it doesn't disallow other ways to encode the RPC representation, e.g. RPC/Literal.

So I'm really confused by your statement that "WS-I excludes use of the SOAP RPC convention in favor of literal use." My understanding of the WS-I BP is that it allows use of the RPC convention, but it disallows use of the SOAP Encoding style.

[1] http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383532
[2] http://www.w3.org/TR/wsdl#_soap:binding

<Soap11Excerpt>

7. Using SOAP for RPC

One of the design goals of SOAP is to encapsulate and exchange RPC calls using the extensibility and flexibility of XML. This section defines a uniform representation of remote procedure calls and responses.

Although it is anticipated that this representation is likely to be used in combination with the encoding style defined in section 5 other representations are possible. The SOAP encodingStyle attribute (see section 4.3.2) can be used to indicate the encoding style of the method call and or the response using the representation described in this section.

Using SOAP for RPC is orthogonal to the SOAP protocol binding (see section 6). In the case of using HTTP as the protocol binding, an RPC call maps naturally to an HTTP request and an RPC response maps to an HTTP response. However, using SOAP for RPC is not limited to the HTTP protocol binding.

To make a method call, the following information is needed:

• The URI of the target object
• A method name
• An optional method signature
• The parameters to the method
• Optional header data

SOAP relies on the protocol binding to provide a mechanism for carrying the URI. For example, for HTTP the request URI indicates the resource that the invocation is being made against. Other than it be a valid URI, SOAP places no restriction on the form of an address (see [4] for more information on URIs).

7.1 RPC and SOAP Body

RPC method calls and responses are both carried in the SOAP Body element (see section 4.3) using the following representation:

• A method invocation is modelled as a struct.
• The method invocation is viewed as a single struct containing an accessor for each [in] or [in/out] parameter. The struct is both named and typed identically to the method name.
• Each [in] or [in/out] parameter is viewed as an accessor, with a name corresponding to the name of the parameter and type corresponding to the type of the parameter. These appear in the same order as in the method signature.
• A method response is modelled as a struct.
• The method response is viewed as a single struct containing an accessor for the return value and each [out] or [in/out] parameter. The first accessor is the return value followed by the parameters in the same order as in the method signature.
• Each parameter accessor has a name corresponding to the name of the parameter and type corresponding to the type of the parameter. The name of the return value accessor is not significant. Likewise, the name of the struct is not significant. However, a convention is to name it after the method name with the string "Response" appended.
• A method fault is encoded using the SOAP Fault element (see section 4.4). If a protocol binding adds additional rules for fault expression, those also MUST be followed.

As noted above, method and response structs can be encoded according to the rules in section 5, or other encodings can be specified using the encodingStyle attribute (see section 4.1.1).
</Soap11Excerpt>

<WsdlExcerpt>

3.5 soap:body

The soap:body element specifies how the message parts appear inside the SOAP Body element.

The parts of a message may either be abstract type definitions, or concrete schema definitions. If abstract definitions, the types are serialized according to some set of rules defined by an encoding style. Each encoding style is identified using a list of URIs, as in the SOAP specification. Since some encoding styles such as the SOAP Encoding (http://schemas.xmlsoap.org/soap/encoding/) allow variation in the message format for a given set of abstract types, it is up to the reader of the message to understand all the format variations: "reader makes right". To avoid having to support all variations, a message may be defined concretely and then indicate it’s original encoding style (if any) as a hint. In this case, the writer of the message must conform exactly to the specified schema: "writer makes right".

The soap:body binding element provides information on how to assemble the different message parts inside the Body element of the SOAP message. The soap:body element is used in both RPC-oriented and document-oriented messages, but the style of the enclosing operation has important effects on how the Body section is structured:

• If the operation style is rpc each part is a parameter or a return value and appears inside a wrapper element within the body (following Section 7.1 of the SOAP specification). The wrapper element is named identically to the operation name and its namespace is the value of the namespace attribute. Each message part (parameter) appears under the wrapper, represented by an accessor named identically to the corresponding parameter of the call. Parts are arranged in the same order as the parameters of the call.

</WsdlExcerpt>
 




At 02:19 PM 3/24/2004, you wrote:

On Mar 24, 2004, at 8:15 AM, Anne Thomas Manes wrote:

There are lots of people at WS-I that really wanted to exclude the RPC 
convention from the BP. But WS-I works by consensus, and it was a very 
divisive issue. But keep in mind that the W3C XMLP Working Group 
decided to make the RPC convention *optional* in SOAP 1.2. They didn't 
want to *remove* it because that would make migration to SOAP 1.2 a 
lot more challenging. But it sends a very strong message that you 
really should stop using it.

JAX-RPC 2.0 should follow the same path. I'm assuming that JAX-RPC 2.0 
will support SOAP 1.2. Are you saying that you want to *add* a 
requirement to SOAP 1.2 just for Java implementations? I strongly 
suggest that you don't want to do that. In JAX-RPC 2.0, support for 
the RPC convention should be optional -- matching the requirements 
specified by SOAP 1.2.

I think you may be confusing two different things: the SOAP RPC 
Representation (including the SOAP Data Model and optionally the SOAP 
Encoding) and the WSDL RPC style. The two are somewhat independent. 
WS-I excludes use of the SOAP RPC convention in favor of literal use.

JAX-RPC 1.1 is a different matter. JAX-RPC defines a Java API for SOAP 
1.1 -- and the API shouldn't be constrained by WS-I BP. In order to be 
SOAP 1.1. compliant, it must support the RPC convention. But the SOAP 
spec doesn't say that it must support RPC/literal. Lots of people 
interpret the SOAP 1.1 spec to require RPC/encoded, but not 
RPC/Literal. (Isn't underspecification wonderful?) It was the JAX-RPC 
team that decided that RPC/Literal was a requirement.

Again, you seem to be confusing WSDL rpc/literal and the SOAP RPC 
convention. The SOAP spec doesn't say anything about WSDL and 
rpc/literal has little to do with the SOAP RPC convention.

And just because the JAX-RPC team decided that RPC/Literal is a 
requirement, I don't see how that necessarily imposed that requirement 
on other language implementations. I'm sorry, but Sun doesn't have the 
market clout to force Microsoft to support RPC/Literal. Microsoft 
recognizes that the RPC convention is something that ought to go away. 
.NET supports Document/Literal by default and  RPC/encoded when 
explicitly specified. It does not support RPC/Literal.

The WS-I basic profile defines a set of interoperability guidelines. A 
WS-I complaint WSDL description can use rpc/literal. JAX-RPC offers 
full support for the WS-I basic profile and that requires JAX-RPC to be 
able to consume any WS-I compliant WSDL. Microsoft, for some reason, 
have chosen to subset the interoperability profile by not including 
support for rpc/literal in their products but that doesn't lessen its 
value for interop with all the other vendors that have a stronger 
commitment to interoperability.

The situation is very simple. If you want to build interoperable Web 
services, use Document/Literal. Don't use RPC/Literal.

If you want to build interoperable web services you should follow the 
guidelines in the WS-I basic profile.

Marc.

At 10:12 AM 3/24/2004, you wrote:

Yes, except that nobody ever bothered writing down exactly what the
"wrapped convention" was, so different implementations used different
conventions. WSDL 2.0 will fix all that.

Since we require support for rpc/literal in JAX-RPC 1.1, I don't think
we should remove it 2.0, otherwise we'd break applications.

And truth be told, it's up to vendors that refuse to support 
rpc/literal
to explain exactly why. It's well specified and lots of people wanted 
it
badly enough to get it included in BP 1.0, so it seems childish to
"refuse" to support it. Or is it a case of Not Invented Here syndrome?

Roberto


Anne Thomas Manes wrote:

Yes -- but that's what the Wrapped convention gives you today with 
SOAP 1.1/WSDL 1.1.
JAX-RPC 2.0 should not require support for rpc/literal. Please keep 
that in mind.
At 10:37 PM 3/22/2004, you wrote:

JAX-RPC 1.1 requires support for rpc/literal. The wsdl->java tool
provided by an implementation must be able to consume any BP 1.0
conformant descriptions, including those that use the rpc/literal 
style.

The future direction, as it can be gleaned from WSDL 2.0, is that
"rpc style" is not a binding concern at all. Rather, it identifies
a set of conventions that were used in creating the schema for the
documents that are sent as message bodies.

So it's quite possible to disregard the rpc style in SOAP 1.2, i.e.
always send whole documents as message bodies, and still get
well-defined rpc signatures. The best of both worlds, really.

Roberto


Anne Thomas Manes wrote:

WS-I doesn't "require" support for RPC/Literal. It allows it, and 
it defines how to use it. The sample apps provide examples of how 
to use it properly. But there's no requirement that a Web service 
(or a Web service platform) must support the RPC style. (Note that 
WS-I conformance claims apply to service instances, descriptions, 
and registries -- not to platforms.)
The SOAP 1.2 specification stipulates that support for RPC style 
is optional. I see no reason to implement support for RPC/Literal 
at this time considering that the style adds no advantage over 
Document/Literal, and the style will go away within the next year 
or so.
Anne
At 04:08 PM 3/22/2004, you wrote:

Anne may be correct to state that document/literal is the 
preferred mode; however WS-I BP 1.0 requires support for 
rpc/literal.  Given that she stated that .Net and Axis do not 
support rpc/literal, I assume that means they do not support WS-I 
BP 1.0.  Is this true, I find that hard
to believe.  Anyone know?

Anne Thomas Manes wrote:

Steve,

One thing that causes a lot of confusion is that SOAP and WSDL 
enable a layer of abstraction between the application 
programming model (RMI-like versus JMS-like) and what actually 
goes on the wire (RPC versus Document style message formats).

Let me make this absolutely clear: you can use an RMI-style 
programming interface in Java and have it automatically marshal 
the parameters for you into a document-style message.

As far as I'm concerned, the RPC style is a mistake from the 
past -- one that we should bury and leave behind us. RPC/literal 
should be avoided even more than RPC/encoded. Most SOAP 
implementations -- including the two most popular 
implementations (.NET and Apache Axis) do not support 
RPC/literal. The RPC programming convention is optional in SOAP 
1.2. Even fewer implementations will support RPC style in the 
future.

The folks designing the JAX-RPC RI need to understand this fact. 
JAX-RPC 2.0 should be focused 100% on supporting 
document/literal. Just forget about RPC style.

A little history: when SOAP was first defined, W3C had not yet 
completed the XML Schema type system, so the SOAP authors needed 
to define their own type system. Hence SOAP encoding. Keep in 
mind, though, that SOAP encoding is not a complete type system 
-- it is horribly underspecified and is the source of many 
interoperability issues. Also -- the original intention behind 
SOAP was to create a very lightweight RPC mechanism, and it 
depended on the encoding system to marshal the data -- but that 
was before the definition of WSDL.

WSDL changed everything. WSDL fully describes the service 
interface. It provides a compiler/runtime generator everything 
it needs to marshal and unmarshal messages. There's absolutely 
no need to use the RPC convention. The RPC convention is *bad* 
because there's no schema for the message on the wire. That 
means that you can't validate the message. And RPC style 
supplies no added value over document style.

If you want to use an RMI style programming model, then you 
should use the "wrapped" convention. The "wrapped" convention 
requires that you define a wrapper element for your parameters. 
The name of the wrapper element must be the same as the 
operation name. Your <wsdl:message> defintion should contain one 
part, and this <wsdl:part> should reference the wrapper element. 
When you compile this WSDL description, it should generate an 
interface that allows you to invoke the service just like RMI.

At least that's how most JAX-RPC implementations work.

Anne

At 06:55 PM 3/19/2004, you wrote:

The question "why would you want to use rpc/encoded" is 
beginning to resonate with me.  I definitely want to avoid it, 
it has made life hard.  The "rpc" part of jax-rpc is what 
confused me.  It made me think in terms of rpc style 
operations.

It finally struck me that document / literal is what I want to 
do, I am not sure how.  I need to pass an xml document to my 
service and the service needs to return a different xml along 
with a byte [].
The document / literal style looks like it handles the xml in 
and xml out part, but I then need to find someway to make the 
byte[] an attachment.  My client uses DII and its not obvious 
to me how to implement this scenario using DII.  Am I right 
that document / literal gets me closer to what I need?


-SP


Doug's right in that if you want to use SOAP encoding, you need 
to use a
SOAP encoding array type.

Please note, though, that this is a valid schema structure, and 
this is how
you should define an array when using literal encoding.

If you can't change your schema, then you must use literal 
encoding. For
best interoperability, you should use doc/literal.

My question is why would you want to use rpc/encoded. It is 
something to avoid.

Anne

At 04:27 PM 3/19/2004, you wrote:
>Christof,
>Where did you get this WSDL from?  I am not sure it is valid. 
I am pretty
>sure that soap encoding requires the use of soap-encoded 
arrays..
There
>is no work around for this type of WSDL.
>
>Christof Strack wrote:
>
>>Hi,
>>
>>I build a web service which uses as a value type the 
following type:
>>            <xsd:complexType name="TroubleTicketValueType">
>>                <xsd:sequence>
>>                    <xsd:element name="value" 
type="xsd:string"
>> minOccurs="1" maxOccurs="unbounded"/>
>>                </xsd:sequence>
>>            </xsd:complexType>
>>When I process this with wscompile (rpc/encoded) I get an 
error message
>>that this type is not supported.
>> From the mailing list I've seen one option is to convert the 
sequence to
>> an array. This is not an option for me since the schema has 
to stay
>> fixed (compatability).
>>What other options do I have? Is it possible to use JAXB 
together with
>>JAX-RPC but still use rpc/encoded style?
>>
>>Regards Christof
>>
>>
>>
>>-------------------------------------------------------------- ---- ---
>>To unsubscribe, e-mail: users-unsubscribe@jax-rpc.dev.java.net
>>For additional commands, e-mail: 
users-help@jax-rpc.dev.java.net
>>
>
>--
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>Doug Kohlert
>
>Sun Microsystems, Inc.
>503-345-9806
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>NOTICE:  This email message is for the sole use of the intended
>recipient(s) and may contain confidential and privileged
>information.  Any unauthorized review, use, disclosure or
>distribution is prohibited.  If you are not the intended
>recipient, please contact the sender by reply email and destroy
>all copies of the original message.
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
>
>--------------------------------------------------------------- ------
>To unsubscribe, e-mail: users-unsubscribe@jax-rpc.dev.java.net
>For additional commands, e-mail: 
users-help@jax-rpc.dev.java.net

~~~~~~~~~~~~~~~~~~
Anne Thomas Manes
VP & Research Director
Burton Group


---------------------------------------------------------------- -----
To unsubscribe, e-mail: users-unsubscribe@jax-rpc.dev.java.net
For additional commands, e-mail: users-help@jax-rpc.dev.java.net


---------------------------------------------------------------- -----
To unsubscribe, e-mail: users-unsubscribe@jax-rpc.dev.java.net
For additional commands, e-mail: users-help@jax-rpc.dev.java.net

~~~~~~~~~~~~~~~~~~
Anne Thomas Manes
VP & Research Director
Burton Group

----------------------------------------------------------------- ----
To unsubscribe, e-mail: users-unsubscribe@jax-rpc.dev.java.net
For additional commands, e-mail: users-help@jax-rpc.dev.java.net

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Doug Kohlert

Sun Microsystems, Inc.
503-345-9806
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information.  Any unauthorized review, use, disclosure or
distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply email and destroy
all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



------------------------------------------------------------------ ---
To unsubscribe, e-mail: users-unsubscribe@jax-rpc.dev.java.net
For additional commands, e-mail: users-help@jax-rpc.dev.java.net

~~~~~~~~~~~~~~~~~~
Anne Thomas Manes
VP & Research Director
Burton Group
------------------------------------------------------------------- --
To unsubscribe, e-mail: users-unsubscribe@jax-rpc.dev.java.net
For additional commands, e-mail: users-help@jax-rpc.dev.java.net

-------------------------------------------------------------------- -
To unsubscribe, e-mail: users-unsubscribe@jax-rpc.dev.java.net
For additional commands, e-mail: users-help@jax-rpc.dev.java.net

~~~~~~~~~~~~~~~~~~
Anne Thomas Manes
VP & Research Director
Burton Group
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@jax-rpc.dev.java.net
For additional commands, e-mail: users-help@jax-rpc.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@jax-rpc.dev.java.net
For additional commands, e-mail: users-help@jax-rpc.dev.java.net

~~~~~~~~~~~~~~~~~~
Anne Thomas Manes
VP & Research Director
Burton Group

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@jax-rpc.dev.java.net
For additional commands, e-mail: users-help@jax-rpc.dev.java.net

---
Marc Hadley <marc.hadley at sun.com>
Web Products, Technologies and Standards, Sun Microsystems.

~~~~~~~~~~~~~~~~~~
Anne Thomas Manes
VP & Research Director
Burton Group --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@jax-rpc.dev.java.net For additional commands, e-mail: users-help@jax-rpc.dev.java.net