Re: WS-Addr issues

Hi Paco. Yes, I understand and have implemented a couple of systems with
WS-Addr (hence my opinion that we should not make it mandatory is based on
experience of its relative usefulness in the environments we've considered).
However, the fact is that it is part of a "WS-Address", however you want to
put it. It may not be part of the EPR per se, but it is part of the logical
address.

As I've said before, I can entirely understand why you might want it in
*some* situations, but I can't see why it's needed in *all* situations. And
it just stands out as a strange thing to have in a specification that is
supposed to be about addressing. I always expected WS-Addressing to be about
how to get a message to an endpoint, not how that endpoint should then
behave when it received the message, i.e., dispatch that message.

Mark.

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

www.arjuna.com


> Mark,
>
> The Action is value is not part of the address (the EPR). Action is
> provided as a MIH to enable endpoints to appropriately act on received
> messages, by consistently looking at one message property - as opposed to
> having to randomly inspect transport artifacts or ad-hoc fields within the
> message body.
>
> Paco
>
>
>
>
>                       "Mark Little"
>                       <mark.little@arjuna.com>        To:       "Harm
Smit" <hsmit@easyconnect.fr>, "'Savas Parastatidis'"
>                       Sent by:
<Savas.Parastatidis@newcastle.ac.uk>, Francisco Curbera/Watson/IBM@IBMUS
>                       public-ws-addressing-req        cc:
<public-ws-addressing@w3.org>
>                       uest@w3.org                     Subject:  Re:
WS-Addr issues
>
>
>                       11/04/2004 10:39 AM
>
>
>
>
>
>
> OK, let's try to put this into some kind of perspective. Is WS-Addressing
> about "addressing" or "dispatching"? I'd assume from the name that it's
the
> former. In which case, why embed an opcode into an address? I've had
> experience with a wide range of RPC mechanisms over the past 20+ years and
> they always make the distinction between an address (e.g., host/port pair,
> URI) and the ultimate dispatching mechanism (e.g., opcode or string).
>
> What we seem to have with wsa:Action is some strange merging of dispatch
> and
> addressing into a single entity. I (and I think Savas) aren't saying that
> we
> can't see the requirement for wsa:Action; only that it doesn't belong in a
> specification that is about addressing. Why not WS-Dispatch, or WS-RPC
> instead.
>
> Mark.
>
> ----
> Mark Little,
> Chief Architect,
> Arjuna Technologies Ltd.
>
> www.arjuna.com
>
> ----- Original Message -----
> From: "Harm Smit" <hsmit@easyconnect.fr>
> To: "'Savas Parastatidis'" <Savas.Parastatidis@newcastle.ac.uk>;
> "'Francisco
> Curbera'" <curbera@us.ibm.com>; "'Mark Little'" <mark.little@arjuna.com>
> Cc: <public-ws-addressing@w3.org>
> Sent: Thursday, November 04, 2004 3:29 PM
> Subject: RE: WS-Addr issues
>
>
> > Savas,
> >
> > Why are you complicating the issue?
> > What is being demonstrated here is that in document mode, you can't
> > unambiguously infer the opcode from the soap:Body.
> > So, in fact, the SOAP message can be viewed as a command of which
> > wsa:action is the opcode and the  soap:Body the operand.
> > What's wrong with this and why would you try to find some convoluted
> > solution to make the wsa:action optional?
> >
> > Harm Smit.
> >
> >
> > > -----Original Message-----
> > > From: public-ws-addressing-request@w3.org
> > > [mailto:public-ws-addressing-request@w3.org] On Behalf Of
> > > Savas Parastatidis
> > > Sent: jeudi 4 novembre 2004 16:02
> > > To: Francisco Curbera; Mark Little
> > > Cc: public-ws-addressing@w3.org
> > > 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 17:30:45 UTC