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