Re: WS-Addr issues

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:27:31 UTC