Pattern five

Heylas,

In very belated fulfillment of my action item, herewith some discussion
of pattern five (the "notification" pattern, in WSDL 1.1 terms).

Pattern five is described, in the current part two of the current spec,
as a single message, in the direction OUT, using the fault-generation
ruleset "no faults".  Note that, under the circumstances, using "fault
replaces message" would be exactly equivalent: the first message can
never be a fault, and there is no second (or later) message to replace,
so the same no-fault effect would be achieved with that ruleset.

Given the definition, there are potentially two recognizable patterns,
which are in the mep task force document as the generic pattern 5, and
the more specific pattern 5a.  It is also possible to specify a pattern
5b, which mandates (rather than leaving undefined) the multicast nature
of the OUT message.

Pattern 5a specializes pattern 5 by making it clear that the message is
unicast.  There can only be a single node receiving the OUT message.

A proposed pattern 5b would specialize pattern 5 for pub/sub systems, by
making it clear that the message is multicast.  There may be one, zero,
or many receivers.

Unlike pattern two, where the concept of participant identity was a very
fruitful tool in combination with the designation of whether a
particular message was unicast or multicast, participant identity is
rather immaterial here.  There can only ever be one message in the
pattern.  It might be interesting to the service (or to other
participants) to know who received the message, but that is only
possible in pattern 5a.  So a less powerful form of participant identity
might be in effect here: are participants known or not?  This is very
strongly associated with the unicast versus multicast distinction,
however, so it may not actually be very interesting.

If a different fault generation pattern, specifically
message-triggers-fault, is used instead (call it pattern 5f, for
'fault'), then we get, again, two basic specializations of interest,
again based on the unicast versus multicast distinction:

5f1: unicast; a fault is returned if the receiving node detects the
need.

5f2: multicast: each receiving node may return a fault.

This helps demonstrate the value of the fault-generation ruleset over
the specification of individual faults: with OUT, iFAULT* it is not
clear *how many* faults each node might send.  The fault-generation
ruleset helps make it clear that each node may only fault once, so the
cardinality of the possible faults MUST be associated with the
cardinality of receivers.  Note that using the older regex language, 5f1
is OUT, iFault?, and 5f2 is OUT, iFault* (but 5a and 5b are both OUT). 
Once again, there is a seemingly less-powerful form of node
identification going on, but it seems best expressed in the fault
ruleset, rather than otherwise.

Hope that helps.  I should have tried to organize a bit better, I think.
 Useful note, though is that for single-message patterns, it appears
that the concept of participant identity isn't very valuable, but the
unicast versus multicast distinction remains interesting.

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

Received on Friday, 18 July 2003 16:58:45 UTC