Re: Three patterns using the ruleset "Message Triggers Fault"

+1 to robust-in-only
+1 to robust-out-only

I think "message triggers fault" is a more sensible fault rule than "fault 
replaces message" in general.


At 11:49 AM 10/8/2003 -0400, Amelia A. Lewis wrote:

>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

-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Thursday, 9 October 2003 02:42:17 UTC