[omniORB] omniEvents 2.6.0,
Event Channel federation & type filtering.
Alex Tingle
alex.tingle at bronermetals.com
Mon Oct 11 12:16:26 BST 2004
Janet,
Janet Tvedt <tvedt at noao.edu> wrote:
> Sorry. I guess I didn't understand this point from the original
> message:
>
>>> o Event channels can be configured to only pass on events of a
>>> particular CORBA type. Combined with channel federation, this
>>> allows Consumers to choose which type of events to receive.
Well it's a simpler approach than CosNotification, but still quite
powerful. Say you have two message types, struct A & struct B. You have
suppliers that generate both types, but consumers that accept only a
single type.
With omniEvents, you would set up three EventChannels, federated as
follows:
A,B suppliers
. . . . . . . .
|
|A,B
V
+-------------+
| Channel 1 |
| (no filter) |
+-------------+
| | |
A,B| | |A,B
V | V
+-------------+ | +-------------+
| Channel 2 | | | Channel 3 |
| filters A | | | filters B |
+-------------+ | +-------------+
| | |
A| |A,B |B
V V V
. . . . . . . . . . . . . .
consumers consumers consumers
of A of A&B of B
Set up by:
% eventc -n Channel1
% eventc -n Channel2 -t IDL:A:1.0
% eventc -n Channel3 -t IDL:B:1.0
% eventf corbaname::#Channel1 corbaname::#Channel2
% eventf corbaname::#Channel1 corbaname::#Channel3
So consumers that want just A-type messages connect to channel 2, while
consumers that want both A&B-type messages can connect to channel 1.
Obviously the downside of this filtering is the latency added by the
extra 'hop'. This can be kept to a minimum by creating all of the
channels in the same event service process, so that the extra 'hop' is
all performed by direct calls rather than on the wire. Throughput
should be unaffected by the extra hop.
-Alex Tingle
--
Dammit Jim, I'm a programmer... not a mind reader!
More information about the omniORB-list
mailing list