W3C home > Mailing lists > Public > public-ws-desc-meps@w3.org > June 2003

Re: Pattern 2 variants

From: David Booth <dbooth@w3.org>
Date: Mon, 23 Jun 2003 02:13:31 -0400
Message-Id: <5.1.0.14.2.20030622231931.02652118@localhost>
To: "Amelia A. Lewis" <alewis@tibco.com>, public-ws-desc-meps@w3.org

(Comments inline below)

At 12:55 PM 6/17/2003 -0400, Amelia A. Lewis wrote:
. . .
>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.

I think I agree with you here.  However, if we talk about "same channel 
communication" we'll need to be much clearer about what we mean.  In the 
context of a unicast, bi-directional transport protocol like TCP, I think I 
understand what you intend.  However, I don't know what is meant by "same 
channel communication" in the context of broadcast communications.  For 
example, if a reply message is broadcast on the radio frequency as the 
request message was received, is that "on the same channel"?  How does the 
original client requester know that it should listen to the response and 
act on it, when some other receiving client may do so also?

Constraining the reply to be "on the same channel" as the request seems to 
me to be placing a transport-specific constraint on the pattern, rather 
than keeping the patterns transport-independent.  In other words, it is 
starting to talk about HOW messages will be delivered, rather than simply 
talking about WHO will receive them.  At the abstract (WSDL interface) 
level, I don't think we should do that.

>. . . [Lots of variations and discussion deleted] . . .
>Let's do a reduced list:
>
>2umci-1: unicast input, unicast output to input source

Ignoring faults, this p2e.

>2umci-2: unicast input, unicast output to unspecified destination

Ignoring faults, this is p2c, p2d and p2d1.

>2umci-3: unicast input, unicast output to source not the same as input

I cannot imagine that the WG would want to adopt such a pattern, but if we 
wanted to describe it, it would be (ignoring faults) exactly the same as 
p2c, p2d and p2d1, with the further constraint that A != B.

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

Ignoring faults, this is p2a.

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

I've added this to meps-vs-iops[1] as pattern p2umci-7.

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

Ignoring faults, this is p2.


-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273
Received on Monday, 23 June 2003 02:29:31 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Friday, 25 March 2005 11:17:39 GMT