Re: WS-Addr issues

Harm Smit wrote:

>Savas, 
>
>Why are you complicating the issue? 
>What is being demonstrated here is that in document mode, you can't
>unambiguously infer the opcode from the soap:Body.
>
all you need to do is have two global element definitions using a common 
type.  Each operation type would define
its own global element def, the name of that element appearing under the 
soap body serving as the name of the operation.

This is still document centric, but using the ability to have several 
elements defined with the same type, to distinguish each
operation being called upon.

This does not sound complicated to me, relying on the soap header to 
disambiguate the operation sounds more complicated.

WSDL provides solutions for this, why not just use wsdl to define your 
operations?

Tom Rutt
Fujitsu

> 
>So, in fact, the SOAP message can be viewed as a command of which
>wsa:action is the opcode and the  soap:Body the operand.   
>What's wrong with this and why would you try to find some convoluted
>solution to make the wsa:action optional? 
>
>Harm Smit.
>
>
>  
>
>>-----Original Message-----
>>From: public-ws-addressing-request@w3.org 
>>[mailto:public-ws-addressing-request@w3.org] On Behalf Of 
>>Savas Parastatidis
>>Sent: jeudi 4 novembre 2004 16:02
>>To: Francisco Curbera; Mark Little
>>Cc: public-ws-addressing@w3.org
>>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:12 UTC