I don't know of any place where WS-I BP requires support for
rpc/literal, only that it allows it. It seems clear that this form is
likely to die out quickly, since it has major disadvantages as opposed
to doc/literal (particularly that it can't be validated) and no
substantial advantages.
- Dennis
--
Dennis M. Sosnoski
Enterprise Java, XML, and Web Services
Training and Consulting
http://www.sosnoski.com
Redmond, WA 425.885.7197
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?
>
>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
>>
>>
>>
>>
>
>
>
---------------------------------------------------------------------
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