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