Re: WS-Addr issues

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 15:39:50 UTC