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

Re: i029 Disallowing Faults

From: Doug Davis <dug@us.ibm.com>
Date: Thu, 11 Nov 2004 18:44:39 -0500
To: public-ws-addressing@w3.org
Message-ID: <OF2B474B2D.E4061CB2-ON85256F49.007B7ACD-85256F49.00826E89@us.ibm.com>
Harris,
  Are you suggesting that if a sender wants to 'fire and forget' then it 
shouldn't use 
WS-A at all?  If so, I believe this would preclude it from using any
other WS-* spec that might build on top of WS-A also, which seems a bit 
limiting.
-Doug




Harris Reynolds <hreynolds@webmethods.com> 
Sent by: public-ws-addressing-request@w3.org
11/11/2004 05:23 PM

To
public-ws-addressing@w3.org
cc

Subject
i029  Disallowing Faults







I am starting discussion of an issue raised earlier by Doug Davis.  This 
is
the description from the issues list: 

"wsa:FaultTo "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
sender really say that it doesn't want ANY fault messages at all but still
be allowed to specify a wsa:From?"

This is essentially asking for a "fire and forget" MEP that will never
receive a reply even under fault conditions.  I am struggling with whether
this condition actually falls within the scope of WS-A. 

>From my perspective WS-A has the most to offer by enabling the following
three things:

1) True Asynchronous Messaging
2) Transport Independent Addressing and
3) Stateful Service Interactions (session mgmt via ref props)

An application that wants to send a message and never worry about a
response, including a fault, can easily do so today without WS-A.

Thoughts from others?  Doug?

~harris

------------------------------ 
Harris Reynolds 
webMethods, Inc. 
http://www.webmethods.com/ 
------------------------------
Received on Thursday, 11 November 2004 23:45:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:59 GMT