W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

Re: WS-Addr issues

From: Francisco Curbera <curbera@us.ibm.com>
Date: Thu, 4 Nov 2004 09:26:19 -0500
To: "Mark Little" <mark.little@arjuna.com>
Cc: public-ws-addressing@w3.org, public-ws-addressing-request@w3.org
Message-ID: <OF3CCC7140.0D516ABE-ON85256F42.004BE026-85256F42.004F50C8@us.ibm.com>

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.


                      "Mark Little"                                                                                                            
                      <mark.little@arjuna.com>        To:       "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>, <public-ws-addressing@w3.org>  
                      Sent by:                        cc:                                                                                      
                      public-ws-addressing-req        Subject:  Re: WS-Addr issues                                                             
                      11/04/2004 05:05 AM                                                                                                      

Hi Sanjiva. Although not an answer to your question, I think it's worth
bringing up generally: personally I think wsa:Action should be dropped or
made optional. Why have an "op code" (which is essentially what it is)
embedded in an address? I can see that there are optimizations that could
be made to dispatching directly on the Action rather than having to parse
the body, but surely that's an implementation specific issue? I'd be
interested in knowing how many users of WS-Addressing actually use this
versus those that ignore it.


Mark Little,
Chief Architect,
Arjuna Technologies Ltd.

----- Original Message -----
From: Sanjiva Weerawarana
To: public-ws-addressing@w3.org
Sent: Wednesday, November 03, 2004 7:42 PM
Subject: Re: WS-Addr issues

Hi Steve,

What's your view of dispatching with wsa:Action? Since those are required
to be unique that gives enough info to find the operation to dispatch
to within a service. The service itself is of course identified from
the <To> somehow.

 ----- Original Message -----
 From: Vinoski, Stephen
 To: Doug Davis
 Cc: public-ws-addressing@w3.org
 Sent: Thursday, November 04, 2004 12:58 AM
 Subject: RE: WS-Addr issues

 +1 to having a pointer to the WSDL itself in the EPR. We have found in
 working with our customers that having access to the service definition is
 critical for applications that rely on pure dynamic dispatching.

       -----Original Message-----
       From: Doug Davis [mailto:dug@us.ibm.com]
       Sent: Wednesday, November 03, 2004 11:02 AM
       To: public-ws-addressing@w3.org
       Subject: WS-Addr issues

       I might have missed a formal request for "issues" from the public
       but since it appears there is now an issues list I thought I'd make
       some suggestions on possible issues for the WG's consideration:

       issue: EPRs have WSDL bits - e.g. PortType, ServiceName.  But no
       pointer to the actual WSDL itself - why not?  W/o the WSDL do these
       values mean anything?  And if we assume the consumer of the EPR has
       the WSDL why can't we assume they know the PortType and ServiceName?
       Perhaps an example of how this would be used would clarify it for

       issue: If a response message is expected then a wsa:ReplyTo MUST be
       included.  Does the absence of a wsa:ReplyTo imply a one-way
       message?  The spec seems to come very close to saying that.  And
       does the presence of wsa:ReplyTo imply a two-way message?  My
       preference would be to have a clear statement so that upon
       inspection of the message itself a processor can know if its a
       one-way or two-way w/o having to go back to the wsdl.

       issue: wsa:FaultTo:  "This property may be absent if the sender
       cannot receive fault messages (e.g. is a one-way application
       message)."  But it also says that in the absence of wsa:FaultTo the
       wsa:ReplyTo/From may be used.  So, how does a client really say that
       it doesn't want ANY fault messages at all but still be allowed to
       specify a wsa:From?

Received on Thursday, 4 November 2004 14:27:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:06 UTC