Roberto,
I agree that it would be very useful if there were a formal specification
of the wrapped convention. You might consider doing that in the next
JAX-RPC maintenance release.
I don't understand your reference to NIH, and I don't see how
"childishness" comes into play in this discussion. The RPC convention was a
mistake. It's a *bad* practice. It is not a convention that we should
promote or propagate.
There are lots of people at WS-I that really wanted to exclude the RPC
convention from the BP. But WS-I works by consensus, and it was a very
divisive issue. But keep in mind that the W3C XMLP Working Group decided to
make the RPC convention *optional* in SOAP 1.2. They didn't want to
*remove* it because that would make migration to SOAP 1.2 a lot more
challenging. But it sends a very strong message that you really should stop
using it.
JAX-RPC 2.0 should follow the same path. I'm assuming that JAX-RPC 2.0 will
support SOAP 1.2. Are you saying that you want to *add* a requirement to
SOAP 1.2 just for Java implementations? I strongly suggest that you don't
want to do that. In JAX-RPC 2.0, support for the RPC convention should be
optional -- matching the requirements specified by SOAP 1.2.
JAX-RPC 1.1 is a different matter. JAX-RPC defines a Java API for SOAP 1.1
-- and the API shouldn't be constrained by WS-I BP. In order to be SOAP
1.1. compliant, it must support the RPC convention. But the SOAP spec
doesn't say that it must support RPC/literal. Lots of people interpret the
SOAP 1.1 spec to require RPC/encoded, but not RPC/Literal. (Isn't
underspecification wonderful?) It was the JAX-RPC team that decided that
RPC/Literal was a requirement.
And just because the JAX-RPC team decided that RPC/Literal is a
requirement, I don't see how that necessarily imposed that requirement on
other language implementations. I'm sorry, but Sun doesn't have the market
clout to force Microsoft to support RPC/Literal. Microsoft recognizes that
the RPC convention is something that ought to go away. .NET supports
Document/Literal by default and RPC/encoded when explicitly specified. It
does not support RPC/Literal.
The situation is very simple. If you want to build interoperable Web
services, use Document/Literal. Don't use RPC/Literal.
Anne
At 10:12 AM 3/24/2004, you wrote:
>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
~~~~~~~~~~~~~~~~~~
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