Re: WS-Addr issues

On Nov 4, 2004, at 10:50 AM, Francisco Curbera wrote:
>
> Action is not part of the EPR; I guess you mean make it an optional 
> message
> header.

Exactly.

>  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.
>
I'd argue that specifying the same information in multiple places 
complicates things...

Marc.

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

Received on Thursday, 4 November 2004 16:23:52 UTC