Re: WS-Addr issues

+1

And to answer your question about interoperability: I'd say that if
wsa:Action was optional then either a) the end points need to negotiate
before hand that there will be a wsa:Action sent, or b) the wsa:Action is
for performance optimizations and the same information *must* be encoded in
the body anyway.

Mark.

----
Mark Little,
Chief Architect,
Arjuna Technologies Ltd.

www.arjuna.com

----- Original Message -----
From: "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>
To: "Francisco Curbera" <curbera@us.ibm.com>; "Mark Little"
<mark.little@arjuna.com>
Cc: <public-ws-addressing@w3.org>
Sent: Thursday, November 04, 2004 3:02 PM
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 15:35:09 UTC