W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

RE: WS-Addr issues

From: Savas Parastatidis <Savas.Parastatidis@newcastle.ac.uk>
Date: Thu, 4 Nov 2004 15:02:00 -0000
Message-ID: <37E80E80B681A24B8F768D607373CA800172C804@largo.campus.ncl.ac.uk>
To: "Francisco Curbera" <curbera@us.ibm.com>, "Mark Little" <mark.little@arjuna.com>
Cc: <public-ws-addressing@w3.org>

Dear Paco,

> The idea that the intent of the message is *always* embedded in the
> of
> the message smells like SOAP-RPC in sheep clothes to me. I am not
> that will never be the case, but you need to allow for the case in
> 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.


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.


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,
Received on Thursday, 4 November 2004 15:03:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:20 UTC