RE: WS-Addr issues

+1.  

Arguing against action is like arguing against HTTP operations.  Having
one spot for Action will give all WS-A applications a much simpler
processing model and enable a doc/literal world.

Separately, can we pick better subject lines and focus the conversation
a bit?  I think this thread is on mandatory Action.  I expect we are
going to debate every single component's mandatory/optional nature and
separating them would help a lot.

Dave

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Francisco Curbera
> Sent: Thursday, November 04, 2004 6:26 AM
> To: Mark Little
> Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
> Subject: Re: WS-Addr issues
> 
> 
> 
> 
> 
> 
> 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.
> 
> Paco
> 
> 
> 
> 
> 
>                       "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
>                       uest@w3.org
> 
> 
>                       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.
> 
> ----
> 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
>

Received on Thursday, 4 November 2004 16:40:37 UTC