Re: WS-Addr issues

In fact the WS-I basic profile states that the wire signature (name of 
the child of soap:body) must be unique for each operation assigned to 
the same port.

Tom Rutt

Mark Little wrote:

>+1
>
>And to answer your question about interoperability: I'd say that if
>wsa:Action was optional then either a) the end points need to negotiate
>before hand that there will be a wsa:Action sent, or b) the wsa:Action is
>for performance optimizations and the same information *must* be encoded in
>the body anyway.
>
>Mark.
>
>----
>Mark Little,
>Chief Architect,
>Arjuna Technologies Ltd.
>
>www.arjuna.com
>
>----- Original Message -----
>From: "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>
>To: "Francisco Curbera" <curbera@us.ibm.com>; "Mark Little"
><mark.little@arjuna.com>
>Cc: <public-ws-addressing@w3.org>
>Sent: Thursday, November 04, 2004 3:02 PM
>Subject: RE: WS-Addr issues
>
>
>  
>
>>Dear Paco,
>>
>>    
>>
>>>The idea that the intent of the message is *always* embedded in the
>>>      
>>>
>>body
>>    
>>
>>>of
>>>the message smells like SOAP-RPC in sheep clothes to me. I am not
>>>      
>>>
>>saying
>>    
>>
>>>that will never be the case, but you need to allow for the case in
>>>      
>>>
>>which
>>    
>>
>>>the same document type is used in different interactions - for
>>>      
>>>
>>example, a
>>    
>>
>>>customerInfo document could be sent as input to both an "update" and a
>>>"create" operations.This "document centric" model is actually very
>>>frequent
>>>(it is no uncommon in CICS applications for example). To support this
>>>model
>>>you need either an Action header or something functionally equivalent.
>>>
>>>      
>>>
>>I can see this argument. However, if one has designed a service to
>>expose an RPC-like interface, it won't matter whether the RPC
>>information is split between the header and the body; it'll still be
>>RPC. It's just that wsa:action would expose the RPC dispatching
>>mechanism in the header instead of the body.
>>
>>An exchange that uses messages like the one bellow is still
>>document-centric but leaves all the dispatching and processing decisions
>>to the end-recipient (the service logic) and it doesn't require the
>>inspection of headers.
>>
>><soap:Envelope>
>>  <soap:Header>
>>    ...
>>  </soap:Header>
>>  <soap:Body>
>>    <CustomerInfo>
>>      <CustomerId>1234</CustomerId>
>>      <CustomerName>Paco</CustomerName>
>>    </CustomerInfo>
>>  </soap:Body>
>></soapEnvelope>
>>
>>In this example, the service logic could infer that since a customer id
>>is provided, this is a request to update the information and not to
>>create a new one. However, I see your point that there may be situations
>>where you would need that additional information. I see two possible
>>alternative ways to record that information while staying within a
>>document-centric view of the world...
>>
>>Since WS-I imposes (I think) a single child element per soap:Body, then
>>one could have different child elements of the same document type.
>>
>><xsd:element name="CustomerInfoUpdateRequest"
>>type="customer:CustomerInfo" />
>><xsd:element name="CustomerInfoCreateRequest"
>>type="customer:CustomerInfo" />
>>
>>Alternatively the information is encoded in the document itself. I think
>>this simulates the way business forms work in real life.
>>
>><CustomerInformationDocument>
>>  <CustomerNew>true</CustomerNew>
>>  <CustomerName>Savas</CustomerName>
>></CustomerInformationDocument>
>>
>>
>>So, why not make wsa:action optional to allow for all possible
>>scenarios? But then the problems with having wsa:action optional would
>>be interoperability and complexity of the specification. What would the
>>lack of a wsa:action header mean for a service that expects it?
>>
>>Just few more thoughts
>>
>>Best regards,
>>.savas.
>>
>>
>>    
>>
>
>
>  
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Friday, 5 November 2004 06:24:27 UTC