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