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).
>
> Mark, Let me add to this perspective that IMHO one of the objectives of
> WS-Addressing is to enable completely asynchronous messaging and to
> break away from RPC (or consider it as a special case, if you prefer).
> So yes, the scope is somewhat wider than just addressing.

Understood. I still don't see why wsa:Action is necessary for this. It's a
dispatching thing. It has nothing whatsoever to do with asynchronous or
synchronous interaction patterns. It would be like sticking an opcode into a
CORBA IOR and saying that made the invocation more asynchronous. It doesn't.

Mark.

>
> > 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:21:00 UTC