1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<!-- This document was generated using DocBuilder 3.3.3 -->
<HTML>
<HEAD>
<TITLE>Event Service</TITLE>
<SCRIPT type="text/javascript" src="../../../../doc/erlresolvelinks.js">
</SCRIPT>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#FF00FF"
ALINK="#FF0000">
<CENTER>
<A HREF="http://www.erlang.se"><IMG BORDER=0 ALT="[Ericsson AB]" SRC="min_head.gif"></A>
</CENTER>
<A NAME="3"><!-- Empty --></A>
<H2>3 Event Service</H2>
<A NAME="3.1"><!-- Empty --></A>
<H3>3.1 Overview of the CosEvent Service</H3>
<P> The Event service allows programmers to subscribe to
information channels. Suppliers can generate events without knowing the
consumer identities and the consumer can receive events without knowing
the supplier identity. Both push and pull event delivery are supported.
The Event service will queue information and processes.
<P> The CORBA Event service provides a flexible model for
asynchronous, decoupled communication between objects. This
chapter outlines communication models and the roles and
relationships of key components in the CosEvent service. It
shows a simple example on use of this service.
<A NAME="3.2"><!-- Empty --></A>
<H3>3.2 Event Service Components</H3>
<P> There are five components in the OMG CosEvent service architecture. These
are described below:
<P>
<CENTER>
<IMG ALT="e_s_components" SRC="e_s_components.gif"><BR>
<EM><A NAME="e_s_components"><!-- Empty --></A>Figure 1: Event service Components</EM>
</CENTER>
<P>
<UL>
<LI>
<STRONG>Suppliers and consumers:</STRONG> Consumers are the ultimate targets of
events generated by suppliers. Consumers and suppliers can both play active
and
passive roles. There could be two types of consumers and suppliers: push
or pull. A PushSupplier object can actively push an event to a passive
PushConsumer object. Likewise, a PullSupplier object can passively
wait for a PullConsumer object to actively pull an event from it.
</LI>
<LI>
<STRONG>EventChannel:</STRONG> The central abstraction in the CosEvent service is the
EventChannel which plays the role of a mediator between consumers and
suppliers. Consumers and suppliers register their interest with the
EventChannel. It can provide many-to-many communication. The channel
consumes events from one or more suppliers, and supplies events to one
or more consumers. An EventChannel can support consumers and suppliers
using different communication models.
</LI>
<LI>
<STRONG>ProxySuppliers and ProxyConsumers:</STRONG> ProxySuppliers act as middlemen
between consumers and the EventChannel. A ProxySupplier is similar to
a normal supplier, but includes an additional method for connecting a
consumer to the ProxySupplier. Likewise, ProxyConsumers act as
middlemen between suppliers and the EventChannel. A ProxyConsumer is
similar to a normal consumer, but includes an additional method for
connecting a supplier to the ProxyConsumer.
</LI>
<LI>
<STRONG>Supplier and consumer administrations:</STRONG> Consumer administration acts as
a factory for creating ProxySuppliers. Supplier administration acts as
a factory for creating ProxyConsumers.
</LI>
</UL>
<A NAME="3.3"><!-- Empty --></A>
<H3>3.3 Event Service Communication Models</H3>
<P> There are four general models of component collaboration in the OMG CosEvent service
architecture. The following describes these models:
(Please note that proxies are not shown in the diagrams for simplicity).
<P>
<CENTER>
<IMG ALT="e_s_models" SRC="e_s_models.gif"><BR>
<EM><A NAME="e_s_models"><!-- Empty --></A>Figure 2: Event service Communication Models</EM>
</CENTER>
<P>
<UL>
<LI>
<STRONG>The Canonical Push Model:</STRONG> The Canonical push model shown in figure 2(A) allows
the suppliers of events to initiate the transfer of event data to consumers.
In this model, suppliers are active initiators and consumers are the passive
targets of the requests. EventChannels play the role of <CODE>Notifier</CODE>.
Thus, active suppliers use EventChannels to push data to passive consumers that
have registered with the EventChannels.
</LI>
<LI>
<STRONG>The Canonical Pull Model:</STRONG>The Canonical pull model shown
in figure 2(B)
allows consumers to request events from suppliers. In this model,
Consumers are
active initiators and suppliers are the passive targets of the pull
requests.
EventChannel plays the role of <CODE>Procurer</CODE> since it procures
events
on behalf of consumers. Thus, active consumers can explicitly pull
data
from passive suppliers via the EventChannels.
</LI>
<LI>
<STRONG>The Hybrid Push/Pull Model:</STRONG> The push/pull model shown in figure 2(C) is a
hybrid that allows consumers to request events queued at an EventChannel
by suppliers. In this model, both suppliers and consumers are active
initiators of the requests. EventChannels play the role of <CODE>Queue</CODE>.
Thus, active consumers can explicitly pull data deposited by active
suppliers via the EventChannels.
</LI>
<LI>
<STRONG>The Hybrid Pull/Push Model:</STRONG> The pull/push model shown in figure 2(D) is another
hybrid that allows the channel to pull events from suppliers and push them
to consumers. In this model, suppliers are passive targets of pull requests
and consumers are passive targets of pushes. EventChannels play the role of
<CODE>Intelligent Agent</CODE>. Thus, active EventChannels can pull data from
passive suppliers and push that data to passive consumers.
</LI>
</UL>
<A NAME="3.4"><!-- Empty --></A>
<H3>3.4 A Tutorial on How to Create a Simple Service</H3>
<P> To be able to use the cosEvent application supplier and consumer objects
must be implemented, which must inherit from the appropriate interface
defined in the <STRONG>CosEventComm.idl</STRONG> specification.
<P> We start by creating an interface which inherits from the correct interface,
e.g., CosEventComm::PushConsumer. Hence, we must also implement all
operations defined in the PushConsumer interface. The IDL-file could look like:
<PRE>
#ifndef _MYCLIENT_IDL
#define _MYCLIENT_IDL
#include <CosEventComm.idl>
module myClientImpl {
interface ownInterface:CosEventComm::PushConsumer {
void ownFunctions(in any NeededArguments)
raises(OwnExceptions);
};
};
#endif
</PRE>
<P> Run the IDL compiler on this file by calling the <CODE>ic:gen/1</CODE> function.
This will produce the API named <CODE>myClientImpl_ownInterface.erl</CODE>.
After generating the API stubs and the server skeletons it is time to
implement the servers and if no special options are sent
to the IDl compiler the file name is <CODE>myClientImpl_ownInterface_impl.erl</CODE>.
<A NAME="3.5"><!-- Empty --></A>
<H3>3.5 How to Run Everything</H3>
<P> Below is a short transcript on how to run cosEvent.
<PRE>
%% Start Mnesia and Orber
mnesia:delete_schema([node()]),
mnesia:create_schema([node()]),
orber:install([node()]),
mnesia:start(),
orber:start(),
%% Install cosEvent in the IFR.
cosEventApp:install(),
%% Register the application specific Client implementations
%% in the IFR.
'oe_myClientImpl':'oe_register'(),
%% Start the cosEvent application.
cosEventApp:start(),
%% Start a channel using the default configuration
Ch = cosEventApp:start_channel(),
%% ... or use configuration parameters.
Ch = cosEventApp:start_channel([{pull_interval, 10}, {maxEvents, 50}]),
%% Retrieve a SupplierAdmin and a ConsumerAdmin.
AdminSupplier = 'CosEventChannelAdmin_EventChannel':for_suppliers(Ch),
AdminConsumer = 'CosEventChannelAdmin_EventChannel':for_consumers(Ch),
%% Use the corresponding Admin object to get access to wanted Proxies
%% Create a Push Consumer Proxy, which the Client Push Supplier will push
%% events to.
ProxyPushConsumer =
'CosEventChannelAdmin_SupplierAdmin':obtain_push_consumer(AdminSupplier),
%% Create a Push Supplier Proxy, which will push events to the registered
%% Push Consumer.
ProxyPushSupplier =
'CosEventChannelAdmin_ConsumerAdmin':obtain_push_supplier(AdminConsumer),
%% Create application Clients. We can, for example, start the Clients
%% our selves or look them up in the naming service. This is application
%% specific.
Consumer = myClientImpl_ownInterface:oe_create(),
Supplier = ...
%% Connect each Client to the corresponding Proxy.
'CosEventChannelAdmin_ProxyPushConsumer':
connect_push_supplier(ProxyPushConsumer, Supplier),
'CosEventChannelAdmin_ProxyPushSupplier':
connect_push_consumer(ProxyPushSupplier, Consumer),
</PRE>
<P> The example above, exemplifies a event system, i.e., the <STRONG>Canonical
Push Model</STRONG>, where the Supplier client in some way generates event
and pushes them to the proxy. The push supplier proxies will eventually
push the events to each Consumer client.
<CENTER>
<HR>
<SMALL>
Copyright © 1991-2006
<A HREF="http://www.erlang.se">Ericsson AB</A><BR>
</SMALL>
</CENTER>
</BODY>
</HTML>
|
