Three patterns using the ruleset "Message Triggers Fault"

In (delayed) fulfillment of an action item from last week's
teleconference, I present three proposed patterns that use the fault
ruleset "Message Triggers Fault".

First, the patterns.  You will see that there is nothing but cut and
paste,
here, with changes to IDs and to the fault rule, except for out-in,
where
the second message is made optional.  This is supplied as
xmlspec-formatted;
WG members shouldn't find it difficult.

Following the three patterns, there are brief paragraphs suggesting use
cases, which are proposed as the kinds of things that might be of value
in
part two (for all patterns).

Finally, there is a section of discussion, which includes notes on
implementation and the value of the patterns as perceived by yours
truly.

<div2 id="robust-in-only"><head>In-Only</head>
<p>This pattern consists of exactly one message as follows:</p>
<olist>
  <item><p>message:</p>
    <ulist>
      <item><p>indicated by a Message Reference component whose
{messageReference} 
is 'A' and {direction} is 'in'</p></item>
      <item><p>received from some node N</p></item>
    </ulist>
  </item>
</olist>
<p>This pattern uses the rule "Message Triggers Fault".</p>
<p>An operation using this message pattern has a {pattern} property with
the value '&wsdl-ns;/robust-in-only'.</p>
</div2>

<div2 id="robust-out-only"><head>Out-Only</head>
<p>This pattern consists of exactly one message as follows:</p>
<olist>
  <item><p>message:</p>
    <ulist>
      <item><p>indicated by a Message Reference component whose
{messageReference} 
is 'A' and {direction} is 'out'</p></item>
      <item><p>sent to some node N</p></item>
    </ulist>
  </item>
</olist>
<p>This pattern uses the rule "Message Triggers Fault".</p>
<p>An operation using this message pattern has a {pattern} property with
the value '&wsdl-ns;/robust-out-only'.</p>
</div2>

<div2 id="asynch-out-in"><head>Out-In</head>
<p>This pattern consists of one or two messages, in order, as
follows:</p>
<olist>
  <item><p>A message:</p>
    <ulist>
      <item><p>indicated by a Message Reference component whose
{messageReference} 
is 'A' and {direction}  is 'out'</p></item>
      <item><p>sent to some node N</p></item>
    </ulist>
  </item>
  <item><p>An optional message:</p>
    <ulist>
      <item><p>indicated by a Message Reference component whose
{messageReference} 
is 'B' and {direction} is 'in'</p></item>
      <item><p>sent from node N</p></item>
    </ulist>
  </item>
</olist>
<p>This pattern uses the rule "Message Triggers Fault".</p>
<p>An operation using this message pattern has a {pattern} property with
the value '&wsdl-ns;/asynch-out-in'.</p>
</div2>

Use Cases

robust-in-only: may be used in both synchronous client/server and
asynchronous (messaging, publish/subscribe) contexts, where the service
is
willing to provide problem reporting in production.

robust-out-only: may be used in both synchronous client/server (probably
as
server-to-server) and asynchronous (messaging, publish/subscribe)
contexts,
where the service regularly needs problem reporting in production.  This
pattern is perhaps the single most commonly-encountered pattern in
publish/subscribe.

asynch-out-in: primarily for use in messaging or publish/subscribe
systems,
particularly where use is made of multicast.  Each of the potentially
responding nodes may choose to ignore the output message.  In this case,
use
of the fault rule "message triggers fault" makes it difficult to use in
typical synchronous protocol context.

Discussion

I've used the term "robust" in describing out-only and in-only, which
some
may care to take issue with.  The ability to report errors is the
greatest
addition to these patterns, though, so it seems at least arguable.

"Robust" in-only and out-only might be of interest to the classic web
services folks who are driving the process over HTTP.  Neither is easily
treated as RPC (RPC typically binds only to request/response), but both
can
be quite useful in increasing the robustness of services that need
one-way
messaging.

The effect of "message triggers fault" in these scenarios is something
of a
"unix-like" result: if the message succeeds, there is no response.  If
there
is a problem with the message, then an error is presented.

The HTTP binding returns a 200 on success, with an empty body, or the
appropriate HTTP error code plus a soap message on fault (this
corresponds
with current WS-I BP recommendations on the WSDL 1.1 one-way, which
returns
200 or 202 with an empty body).

In multicast bindings of the out-only style, the service may, in fact,
receive multiple faults.  The binding, in this case, returns nothing
(not a
success code and empty body, but nothing at all) on success.  As noted
in
the patterns task force, the fact that some other node may fault is of
no
consequence to each of the listening nodes, so the multicast-ness is not
represented in the pattern, but is known only from the binding.

Both of these patterns also offer value to the higher-level
choreography/workflow/process languages currently in development. 
Because
they can be bound even within the client/server paradigm, they could
potentially reduce the number of paths in the flow or process (by
allowing
the errors to simply percolate back).

Use of message-triggers-fault with out-in can be reproduced (albeit
without
the implied message correlation of a single pattern) by using the robust
versions of out-only and in-only.  It's possible that pub/sub systems
would
prefer to do this, and use higher-level choreography-style languages to
indicate the correlations.

Here's an example of the pattern: a bidding service.  Out (multicast):
please bid on this item.  Receivers may ignore, respond, or fault.  On
receipt of a response (presumably a bid, given that there are other
channels
for "no bid" and "no good auction"), the service may fault ("bad bid").

Hope this helps to ground the discussion.

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

Received on Wednesday, 8 October 2003 11:49:52 UTC