RE: WS-Addr issues

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Mark Little
> Sent: jeudi 4 novembre 2004 18:22
> To: Harm Smit; 'Savas Parastatidis'; 'Francisco Curbera'
> Cc: public-ws-addressing@w3.org
> Subject: 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.

Of course not. I wasn't saying wsa:action has anything to do with
asynchrony, my remark was related to your RPC perspective and intended
to point out that the discussion about WS-Addressing should not be
narrowly restricted to addressing, just because of its name.
 
> 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 18:01:35 UTC