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