Re: WS-Addr issues

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.

----
Mark Little,
Chief Architect,
Arjuna Technologies Ltd.
 
www.arjuna.com

  ----- 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.

  Sanjiva.
    ----- 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.

    --steve
      -----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 me. 

      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? 

      thanks 
      -Doug