- From: Frank DeRose <frankd@tibco.com>
- Date: Wed, 6 Dec 2000 15:23:39 -0800
- To: <xml-dist-app@w3.org>
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