Re: WS-Addr issues

Action is not part of the EPR; I guess you mean make it an optional message
header. Still, I guess your point is like the one about recognizing that
the <To> information may be carried by the transport: you do agree it must
be there but you argue it may be found in many different places (body,
SOAPAction, etc...). I would still disagree, however: this just makes
everything much more complicated than is really needed.

Paco



                                                                                                                                               
                      Marc Hadley                                                                                                              
                      <Marc.Hadley@Sun.COM>           To:       Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>                        
                      Sent by:                        cc:       Francisco Curbera/Watson/IBM@IBMUS, public-ws-addressing@w3.org, Mark Little   
                      public-ws-addressing-req         <mark.little@arjuna.com>                                                                
                      uest@w3.org                     Subject:  Re: WS-Addr issues                                                             
                                                                                                                                               
                                                                                                                                               
                      11/04/2004 10:27 AM                                                                                                      
                                                                                                                                               





I agree with the desire to make action an optional part of an EPR. This
would echo the resolution made by the XMLP WG [1] a couple of years ago
wrt SOAPAction (now the action parameter of the application/soap+xml
media type).

If a service mints an EPR that contains a URI then a consumer of that
service would be expected to provide it, if a service mints an EPR
without a URI then it would be omitted. This way services can be the
arbiter of what information they require in messages they receive.

I see no value in mandating the inclusion of action in EPRs for
services that make no use of it.

Marc.

[1] http://www.w3.org/2000/xp/Group/xmlp-issues#x95

On Nov 4, 2004, at 10:02 AM, Savas Parastatidis wrote:

>
> 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.
>
>
>
---
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Thursday, 4 November 2004 15:51:24 UTC