Pattern 2 variants

Heylas,

Per my action item, here are a number of possible variants on pattern
two, using a number of different possible additional criteria.

The following criteria have been excluded:

1) direction
2) cardinality
3) sequence
4) fault generation ruleset

All of these are used in the (current) definition of pattern two, which
has one input message followed by one output message, using "Fault
replaces message" (which means that the output message may be replaced
by a fault).

Note that this differs slightly from the current MEPs vs. IOPs document,
which also treats the destination of or source of a fault as a variable.
 Using fault-replaces-message, there is no need to separately represent
faults (messages after the first may be faults instead; this makes
patterns p2a, p2c, and p2d "illegal", and unifies the red arrow with the
dotted-black arrow in p2b).

Based on that definition, we can begin to vary a number of
characteristics:

1) conservation of messages (unicast versus multicast)
2) counterparty ("client") identity
3) same-channel communications

Conservation of messages is defined as: "For any one message that is
sent by one node, one message is received by one node."  This is also
commonly called "unicast" (as opposed to broadcast and multicast).

There are 4 possible pattern specializations possible using the unicast
versus multicast distinction:

2um-1: unicast input, unicast output
2um-2: unicast input, multicast output
2um-3: multicast input, unicast output
2um-4: multicast input, multicast output

2um-1 appears, at first glance, to be classic request/response, but in
fact the output message is *not* constrained to be returned to the
sender of the input message.

2um-2 is approximately the pattern presented by Martin Gudgin and
Jeffrey Schlimmer at the face-to-face in Cambridge, under the title "an
interesting pattern".  A single message arrives at the service; the
response is multicast to listening subscribers, which may or may not
include the original sender (in fact, there may be no listeners at all).
 This is also more or less pattern 2b as presented in the IOPs versus
MEPs document.

2um-3 has not been suggested before, to my knowledge.  One might argue
that certain discovery protocols have approximately this pattern.  The
implication is that there may be more than one service listening on the
same address, and that each service may respond.  Again, there is no
requirement that the response be returned to the sender of the request
message.

2um-4 is much the same as 2um-3, with some of the characteristics of
2um-2: there may be no services listening, and there may be no
subscribers listening to the services, and in general the identity of
participants is very unclear.

Summary: as a technique for refining the expectations of clients, the
unicast versus multicast distinction (conservation of messages) isn't
very powerful.  Although it provides additional information (other
listeners may receive a message versus only one listener will), that
information isn't sufficient.  It is not possible to identify a classic
request/response pattern using only this additional distinction (we'll
return to it below, though).

Additional note: from the point of view of the *service*, 2um-3 is
equivalent to 2um-1, 2um-4 to 2um-2.  The distinction is only
interesting from the point of view of the counterparty, which expects
different numbers of responses (counterparty cardinality) depending upon
how many services may be listening/responding.

Counterparty identity may be defined as specifying the identities of the
participants in a pattern which are not the service.  Note that these
participants may be services (in their own WSDLs), but in the context of
the pattern, they are the non-service participant or participants. 
Specification of counterparty identity supplies two distinctions: a)
participants MUST be the same, and b) participants MAY NOT be the same. 
It does not seem useful to specify that participants MUST NOT be the
same.  Nonetheless, we'll do so, just for kicks.

These distinctions generate three specializations of pattern 2:

2ci-1: input message source identical to output message destination
2ci-2: input message source possibly not identical to output message
destination
2ci-3: input message source must be different from output message
destination

2ci-1 again looks awfully like classic request/response, and includes
it.  It specifies, after all, that the requester gets the response back.
 Depending upon how strictly this is defined, it may include only
request/response (if strict identity is required, then the only way that
multiple recipients could receive the response would be if they all
somehow communally sent the request), or may allow greater flexibility
*but* force the response to be returned to the requester.

2ci-2 permits the "bounce" or "third-party" request/response (as in
email, when a request sent from a particular address may produce a
response that is sent to the "registered" email address instead), as
well as classic request/response (it does not rule out that the
requester be the response target).  Multiple recipients are easily
possible.  What it doesn't provide is good expectations for the client:
will I/won't I receive a message?  In response to mine, or in response
to someone else?

2ci-3 is a bit of an odd duck.  It makes it quite easy to distinguish
between the case of classic request/response (2ci-1) and the
bounce/third-party request/response, or between classic and Gudge's
"interesting pattern".  However, while the requirement makes programming
easier, it is not quite clear what common networking paradigm it models,
if any.

Summary: counterparty identity, especially if strictly interpreted, is
adequate to distinguish classic request/response from "other" forms of
input/output, but does not provide enough information for tool builders
to easily distinguish between those other variations.  It would be
interesting to apply it to other multiple-message patterns.

Same-channel communications is easily described, but may not apply well
outside of connection-oriented protocols such as HTTP.  It mandates that
messages after the first in a pattern must use the same "channel" as the
first message.  This is easily comprehended with respect to HTTP (the
message must be returned over the open connection), less easy with SMTP
(is 'same channel' the From: header or the envelope sender?), and quite
difficult with multicast or store-and-forward technologies (should the
response go to the same target address as the request?  the same
newsgroup?).  It tends to disallow unicast responses to multicast
requests.

Same-channel communications provides two pattern specializations: must
be same-channel, may not be.  Must not be is probably out of scope.

2sc-1: input message opens channel down which output message is returned
2sc-2: input message and output message may use different channels

2sc-1 is very clearly classic request/response, when a
connection-oriented protocol is in use.  However, it produces
complications if, for instance, a multicast protocol is used: then the
response may be required to be multicast to the same original target
address, rather than being unicast to a reply-to address included in the
request message.

2sc-2 resolves back to pattern two; it doesn't specify anything
additional.

Summary: same-channel communications may be too closely tied to idioms
of connection-oriented protocols to have general applicability. 
However, it is perfectly capable of distinguishing classic
request/response from the generality of pattern two.

For our next trick, let's try combining two of the interesting
distinctions: conservation of messages and counterparty identity.  We've
already defined them.  So we can just multiply them, and get a round
dozen possibilities:

2umci-1: unicast input, unicast output to input source
2umci-2: unicast input, unicast output to unspecified destination
2umci-3: unicast input, unicast output to source not the same as input

2umci-4: unicast input, multicast output including input source (for
strict definition of identity, this isn't allowed at all)
2umci-5: unicast input, multicast output to any number of listeners,
possibly including input source
2umci-6: unicast input, multicast output to any number of listeners
*excluding* the input source

2umci-7: multicast input, unicast output to input source
2umci-8: multicast input, unicast output to unspecified destination (may
be input source, may not)
2umci-9: multicast input, unicast output to someone other than the input
source

2umci-10: multicast input, multicast output including input source
("same channel"?)
2umci-11: multicast input, multicast output which may or may not include
input source
2umci-12: multicast input, multicast output which must not include input
source

Time to reduce the field.  Moving backwards: 2umci-12 is very difficult
to guarantee, in most multicast environments, so should probably be
discarded.  For all practical purposes, 2umci-11 and 2umci-10 are
identical (from both the counterparty and the service point of view). 
The same problem of exclusion applies to 2umci-6, and 2umci-5 and
2umci-4 are functionally identical (using the loose definition of
counterparty identity.

Recall that multicast inputs are of interest primarily to the
counterparty, not the service, because the multicast makes a difference
in the number of outputs to be predicted.  In combination with
counterparty identity, this makes 2umci-9 fairly pointless.  Call it
one-way, insofar as the client is concerned.  2umci-7 and 2umci-8 have
one characteristic in common: unpredictable number of outputs.  It is
difficult, though, to justify 2umci-8 (yes, a lot of these are odd, but
that one's odder than most).

First tentative conclusion: combining the unicast/multicast distinction
with counterparty identity produces more interesting results when
everything is unicast.  Let's do a reduced list:

2umci-1: unicast input, unicast output to input source
2umci-2: unicast input, unicast output to unspecified destination
2umci-3: unicast input, unicast output to source not the same as input

2umci-45: unicast input, multicast output may include the input source

2umci-7: multicast input, unicast output to input source

2umci-1011: multicast input, multicast output may include the input
source

2umci-1 is otherwise known as classic request/response.  2umci-2 MAY be
the bounce/third-party; 2umci-3 MUST be third-party.  For both of the
latter, further information remains required: how is the target address
of the response message established?  Can the counterparty determine
what it is?  Is it valid to leave this to the application?

There is another interesting identity in 2umci-45 and 2umci-1011; the
input source has established itself as a subscriber to some multicast
medium, and presumably is ready to process any response messages
whatsoever (discarding the ones it isn't interested in, probably). 
Note, though, that multicasting responses to requests is not
particularly common (it is more likely that a request will be multicast,
and responses will be unicast to the sender, whose address is specified
in the request message).  The programming pattern of the client for
2umci-45 and 2umci-1011 is also the same for 2umci-7; the difference is
that the client in 2umci-7 *knows* that received messages will be
relevant to its own requests.

Okay, out of steam for now.  Hope that this is useful to folks thinking
about things; sorry about the length.  Commentary welcomed.

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

Received on Tuesday, 17 June 2003 12:54:36 UTC