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