Anne,
One value rpc/literal offers over wrapped/doc/literal is that you do not have
to reverse-engineer WSDL generated with .NET to figure out how to generate your
own files.
Why should I call my part 'parameters' in the output message?
RPC/literal is in the open and WS-I has done a good job clarifying ambiguities
in the interpretation of the current specifications.
Axis's developers have also done a good job in the reverse engineering process
to second guess Microsoft's secret sauce.
Eric
Anne Thomas Manes wrote:
> But how do you validate that you have all the required parameters in the
> correct sequence?
> Also -- you wind up needing to run multiple validations (one per
> parameter) rather than just one. It's much more efficient to perform one
> validation than many.
>
> I think the main point to recognize here is that rpc/literal offers no
> inherent value over wrapped/doc/literal. Wrapped gives you the same kind
> of automatic marshalling of parameterized method invocation as
> rpc-style, yet it produces a doc/literal message. And it interoperates
> with .NET.
>
> Anne
>
> At 04:05 AM 3/23/2004, you wrote:
>
>> Thanks Anne!
>>
>> Sorry for my ignorance, but even for an intermediary - does it really
>> matter
>> that it does the validation of the entire body or of the parameters "one
>> level deeper"? If it know how to get to a SOAP body, is it too
>> difficult for
>> it to be parameterized to know how to go a level deeper and validate
>> the N
>> parameters?
>>
>> Thanks and Regards, -Rob
>>
>> > When using RPC/Literal you do not have a schema that defines the
>> contents
>> > of the <soap:Body>. Therefore you cannot validate the SOAP message
>> as it is
>> > on the wire.
>> >
>> > An RPC/Literal SOAP Body looks something like this:
>> >
>> > <soap:Body>
>> > <m:methodName xmlns:m="urn:sample">
>> > <param1>blah</param1>
>> > <param2>blah</param2>
>> > </m:methodName>
>> > </soap:Body>
>> >
>> > The RPC/Literal WSDL that describes this message looks like this:
>> >
>> > <wsdl:definitions targetNamespace="urn:sample"
>> > xmlns:tns="urn:sample" xmlns:wsdl="..." xmlns:xsd="..."
>> xmlns:soap="...">
>> > <wsdl:message name="In">
>> > <wsdl:part name="param1" type="xsd:string" />
>> > <wsdl:part name="param2" type="xsd:string" />
>> > </wsdl:message>
>> > <wsdl:portType name="samplePT">
>> > <wsdl:operation name="methodName">
>> > <wsdl:input message="tns:In"/>
>> > </wsdl:operation>
>> > </wsdl:portType>
>> > <wsdl:binding name="sampleRpcBinding" type="tns:samplePT">
>> > <soap:binding style="RPC" transport="..."/>
>> > <wsdl:operation name="methodName">
>> > <soap:operation soapaction="" />
>> > <wsdl:input>
>> > <soap:body use="literal" namespace="urn:sample" />
>> > </wsdl:input>
>> > </wsdl:operation>
>> > </wsdl:binding>
>> > ...
>> > </wsdl:definitions>
>> >
>> > Note that nowhere in this WSDL definition do we define the schema of
>> the
>> > <m:methodName> element that gets sent in the <soap:Body> of the
>> above SOAP
>> > message. The <m:methodName> element is defined on the fly using the RPC
>> > convention. It takes the local name of the element from the name
>> attribute
>> > in the operation definition (portType/operation_at_name). It grabs the
>> > qualifiying namespace name from the namespace attribute in the
>> binding's
>> > input message's <soap:body> definition
>> > (binding/operation/input/body_at_namespace). It creates a child element
>> for
>> > each message part. These child elements are unqualified elements. It
>> takes
>> > the local name from the name attribute of each part definition
>> > (message/part_at_name), and it determines the structure of these child
>> > elements from the type attribute in each part definition
>> > (message/part_at_type). Ahhh! Finally we get to some real schema
>> information.
>> > Sorry -- but that doesn't qualify as a schema that I can use to
>> validate
>> > the message.
>> >
>> > In a more realistic scenario, I might be trying to send a fairly
>> complex
>> > set of parameters, such as a purchase order and a shipping
>> instructions.
>> > And perhaps I want to validate the message to verify that the message
>> > conforms to my requirements. If I had a schema that defines the
>> message,
>> > then I can perform that validation in an intermediary -- but I'm not
>> about
>> > to ask an intermediary to dynamically figure but the proper schema
>> > structure based on the RPC convention -- I would only ask a SOAP
>> engine to
>> > do that.
>> >
>> > Anne
>> >
>> >
>> > At 06:44 PM 3/22/2004, you wrote:
>> >> On 3/22/04 10:36 AM, "Dennis Sosnoski" <dms_at_sosnoski.com> wrote:
>> >>
>> >>> 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
>> >>
>> >>
>> >> What do people mean when they say that rpc/literal can't be validated?
>> >> Surely, the parameters of a web service method are defined using
>> XML schema.
>> >> RPC/literal style puts a wrapper over these parameters to do
>> dispatching to
>> >> the right method. Once in application code you get back the
>> parameters. The
>> >> validation of schema can be done by the runtime or the application.
>> Am I
>> >> missing something?
>> >>
>> >> -Rob
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> 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