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