On Faults

I'd like to propose, probably for later consideration, that we drop the explicit characterization of faults in exchange patterns.

I believe that the inclusion of faults in the patterns simply confuses the issue.  It also potentially multiplies the number of patterns, as each different fault-handling paradigm creates a separate 'dialect' of each pattern.

There are two fairly straightforward rules that could be adopted in place of the current explicit definition.  Moreover, it might be possible, using the properties mechanism, to specify per-protocol binding or per-service, which fault-handling rule should be used.  These two rules are:

1. Any message may trigger a fault in response.
2. A fault may substitute for any message after the first in a pattern.

#2 is appropriate, for instance, for HTTP.  #1 is more likely to be encountered in asynchronous sorts of protocols.

I'd like to make this a proposal, but not as a high priority, as we are currently focusing on issues of "what is a MEP" and "MEPs versus IOPs" and "which belongs in portType/interface?".

Amy!
-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Monday, 31 March 2003 13:40:27 UTC