Re: WS-Addr issues

+1

On 5 Nov 2004, at 05:36, Tom Rutt wrote:

>
>
> 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 09:05:53 UTC