RE: WS-Addr issues

> -----Original Message-----
> From: Mark Little [mailto:mark.little@arjuna.com] 
> Sent: jeudi 4 novembre 2004 16:40
> 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.
 
> 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 16:30:32 UTC