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_at_jax-rpc.dev.java.net
>>>>>>>> >>For additional commands, e-mail:
>>>>>>>> users-help_at_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_at_jax-rpc.dev.java.net
>>>>>>>> >For additional commands, e-mail:
>>>>>>>> users-help_at_jax-rpc.dev.java.net
>>>>>>>>
>>>>>>>> ~~~~~~~~~~~~~~~~~~
>>>>>>>> Anne Thomas Manes
>>>>>>>> VP & Research Director
>>>>>>>> Burton Group
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> -----
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>>>>>> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>>>>>>
>>>>>>>>
>>>>>>>> ----------------------------------------------------------------
>>>>>>>> -----
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>>>>>> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ~~~~~~~~~~~~~~~~~~
>>>>>>> Anne Thomas Manes
>>>>>>> VP & Research Director
>>>>>>> Burton Group
>>>>>>>
>>>>>>> -----------------------------------------------------------------
>>>>>>> ----
>>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>>>>> For additional commands, e-mail: users-help_at_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_at_jax-rpc.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>>>
>>>>>
>>>>> ~~~~~~~~~~~~~~~~~~
>>>>> Anne Thomas Manes
>>>>> VP & Research Director
>>>>> Burton Group
>>>>> -------------------------------------------------------------------
>>>>> --
>>>>> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>>> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>
>>> ~~~~~~~~~~~~~~~~~~
>>> Anne Thomas Manes
>>> VP & Research Director
>>> Burton Group
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
> ~~~~~~~~~~~~~~~~~~
> Anne Thomas Manes
> VP & Research Director
> Burton Group
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
>
---
Marc Hadley <marc.hadley at sun.com>
Web Products, Technologies and Standards, Sun Microsystems.
- application/pkcs7-signature attachment: smime.p7s