On Mar 22, 2004, at 12:59 PM, Doug Kohlert 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?
>
WS-I only defines conformance in terms of services and artifacts (WSDL
descriptions, SOAP messages etc) not platforms or tools. This means
that a tool can claim WS-I conformance provided it allows development
of WS-I compliant services. So, e.g., you can use .Net to create a WS-I
compliant service described by an rpc/literal WSDL by rewriting the
WSDL as doc/literal and using the .Net tools on that instead. Not very
convenient, but its enough to allow a claim of conformance.
Marc.
> 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
>
>
---
Marc Hadley <marc.hadley at sun.com>
Web Products, Technologies and Standards, Sun Microsystems.
---------------------------------------------------------------------
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