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

Re: i029 Disallowing Faults

From: Mark Peel <mpeel@novell.com>
Date: Thu, 11 Nov 2004 18:38:06 -0700
Message-Id: <s193b19b.026@sinclair.provo.novell.com>
To: <public-ws-addressing@w3.org>


  And a "fire and forget" message may still want Transport Independent
Addressing.

Cheers,
MLP

Mark Peel
Web Services Infrastructure
Novell, Inc.

>>> Doug Davis <dug@us.ibm.com> 11/11/04 5:44:39 PM >>>
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 Friday, 12 November 2004 01:39:00 GMT

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