RE: WS-Addr issues

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. 
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.
> 
> 
>

Received on Thursday, 4 November 2004 16:09:14 UTC