[DR304], [R502], [DR058], [DR025], [DR028], [DR067] and "message patterns"

I agree with Alex Ceponkus that there may be problems in the wording of
DR304, R502, DR058, DR025, DR028, DR067.

These requirements include such phrases as: “one-way or event …
interactions,” “publish-subscribe,” “multicast.” It’s not clear whether all
these phrases refer to the same or different things. These requirements also
make use of terms like “interaction pattern” and “message pattern” without
defining them.

I think the specification ought to define a single term “message pattern”
and then list the instances of message pattern that will not be precluded by
the specification.

Here’s a strawman proposal for a definition of the term “message pattern.”

The term “message pattern” can be defined by providing characteristics in 3
dimensions:

Dimension 1
Synchronous/asynchronous

Dimension 2
One-way/two-way

Dimension 3
One-to-one/one-to-many

From these dimensions, we can construct the following matrix:

Synchronous
	One-way
		One-to-one	Undefined
		One-to-many	Undefined
	Two-way
		One-to-one	Defined (Synchronous RPC)
		One-to-many	Undefined
Asynchronous
	One-way
		One-to-one	Defined (like CORBA oneway)
		One-to-many	Defined (multicast, publish-subscribe)
	Two-way
		One-to-one	Defined (Asynchronous RPC)
		One-to-many	Undefined

NOTE: By convention, all one-way patterns are treated by definition as
asynchronous. The point is that it makes no sense to draw the sync/async
distinction for one-way patterns.

If a position in the above matrix is marked as “Undefined,” it means my
feeble mind cannot imagine a messaging pattern with the specified
characteristics. If a position in the matrix is marked as “Defined,” it
means I can imagine a messaging pattern with the specified characteristics
and I’ve supplied the common name(s) for such a pattern.  In my opinion, the
XP specification should not preclude the use of XP with the messaging
patterns marked as “defined” above.

So, specific changes I would recommend for the spec would be to define a
taxonomy of message patterns in the terminology section [1] and then include
one (and only one) requirement with the following wording:

<requirement>
The XP specification should not preclude the use of the following popular
messaging patterns (which are defined in the terminology section):

-- Synchronous, two-way, one-to-one
-- Asynchronous, one-way, one-to-one
-- Asynchronous, one-way, one-to-many
-- Asynchronous, two-way, one-to-one
</requirement>

Frank DeRose
TIBCO Software Inc.
3165 Porter Dr
Palo Alto, CA 94303
650-846-5570 (vox)
650-846-1267 (fax)
frankd@tibco.com
www.tibco.com

[1] http://www.w3.org/2000/xp/Group/xp-terms-01

Requirements under discussion
DR 304
The XML protocol MUST facilitate the creation of simple applications. Simple
applications are those with simple message exchange patterns: one-way or
event, synchronous, or two-way request response interactions. The
specification will make such simple exchange applications as easy as
possible to create and use.

R502
The specification developed by the Working Group must support either
directly or via well defined extension mechanisms different messaging
patterns and scenarios. The specification will directly support One-way and
Request-response patterns as part of permanently and intermittently
connected scenarios. The specification will not preclude the development of
other patterns at either the application or transport layers. Examples of
such patterns may include Publish-subscribe or Multicast delivery. All
patterns and scenarios will be described by relevant use cases.

DR025
Is multicast a requirement?
Issue (i.025.01):
This is a duplicate.

DR028
Multicast should be supported (not inventing multicast solutions)
Issue (i.028.01):
Duplicate.

DR058
Shall support multiple interaction patterns (e.g. request/response, RPC,
point-to-point, publish/subscribe).

DR067
other interaction patterns.

Received on Wednesday, 6 December 2000 18:23:04 UTC