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