[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [COAS-List] [FWD] Event system connection cases



Eric Navarro wrote:
> 
> I'm forwarding this message from Larry Hamel from Philips since it's been unable
> to be sent to the list from his account.
> 
> Thanks,
> Eric N.
> 
> <<Forwarded message>>
> y'all,
> 
> At the recent Colorado meeting, Tim and I discussed use-cases for how a
> client might subscribe (connect) to events from a COAS server.
> 
> First, consider the case where both client and server connect themselves to
> a channel that they somehow discover:
> 
>         SERVER -->  c-CHANNEL-c  <-- CLIENT
> 
>         legend:  the small "c" means that some kind of "connect()"
>                 function exists.  The "c" function is different
>                 for client or server, but allow me
>                 to generalize in this ASCII representation.
> 
>                 the <-- and --> arrows indicate a "connect" call.
> 
> Second, consider an IT management application that instigates all
> connections.  The three event players, client, server, and channel, do not
> discover each other by themselves.  Instead, all players provide connect()
> functions and depend on an omniscient manager to do the tying together:
> 
>                     MANAGER
> 
>         SERVER-c    c-CHANNEL-c    c-CLIENT
> 
>         legend:  imagine lines from the manager, making "connect" calls; the
>                   manager has references to all three players.
> 
> Third, we leave out the channel, directly connecting client and server.
> This case may appear to the client just like the first case if the server
> implements the channel API, especially if we make spoofing this API easy:
> 
>         SERVER-c  <-- CLIENT
> 
> QUESTION:  Are there other scenarios we should account for?
> 
> Later we can discuss the specific "subscribe" functions to support these
> scenarios, as well as the interfaces necessary on client and server to
> accomplish these connections.  Tim: let me know if I missed anything.
> These notes are old :-).

As you say the client sees this as the first example.  Also the server
sees it as the second example.

Another scenerio I see is the reverse of the last one:

         SERVER -->  c-CLIENT

Here the server sees it as the first scenerio and the client sees it as
the second.


One more scenerio is where a manager connects the client and server
directly together.

                    MANAGER
                  /        \
         SERVER-c            c-CLIENT

In each of these cases the client and/or server may be using their own
notification channel internally to do the actual sending/receiving of
the event.


I guess we should have been using the terms 'Supplier' and 'Consumer'.


Cheers,

Tim
begin:          vcard
fn:             Tim Brinson
n:              Brinson;Tim
org:            Protocol Systems, Inc.
adr:            8500 SW Creekside Place;;;Beaverton;Oregon;97008-7107;USA
email;internet: tim@protocol.com
title:          Systems Software Lead
tel;work:       503 526 4392
tel;fax:        503 526 4200
note:           <img src=http://aco.protocol.com/pids/tbrinson.jpg>
x-mozilla-cpt:  ;0
x-mozilla-html: TRUE
version:        2.1
end:            vcard