|
Lab 3 |
Middleware Platforms CORBA Event Service |
|
Ablieferungstermin und erreichbare Punktzahl für diese Aufgabe, sowie Voraussetzungen für die Prüfungszulassung entnehmen Sie bitte http://sar.informatik.hu-berlin.de.
Sie sollen den Event-Channel des CORBA Event-Dienstes in C++ (vereinfacht) implementieren. Während die erste Aufgabe (Push/Push EventChannel) noch relativ einfach zu realisieren sein wird, werden Sie bei der zweiten Aufgabe (Push/Pull EventChannel) auf ein prinzipielles Problem stoßen. Bei dessen Lösung sollen Sie davon ausgehen, dass Sie keine Threads zur Verfügung haben bzw. diese nicht benutzen können, z.B. weil die von Ihnen verwendeten Bibliotheken nicht „thread-safe“ sind.
Vereinfachung: Der CORBA Event Service verwendet als Event-Datentyp „any“. Das ist zwar gut im Punkt Flexibilität, bereitet aber einige Umstände bei der programmiersprachlichen Umsetzung, besonders in C++. Sie können daher in den weiter unten aufgeführten IDL-Definitionen den Event-Typ „any“ durch „long“ ersetzen (die etwas mutigeren unter Ihnen können alternativ auch „string“ wählen).
Aufgabenstellung
Vorbereitung: Implementieren Sie eine Event-Quelle und eine Event-Senke, die über die untenstehenden IDL-Interfaces miteinander interagieren.
- Von der Event-Quelle benötigen Sie zwei Varianten: Eine, die nach dem Push-Modell funktioniert und eine, die nach dem Pull-Modell funktioniert. Analoges gilt für die Event-Senke.
- Event-Quellen würden in einem realen Beispiel sicher eine Ressource überwachen – hier genügt es, wenn sie zufällig Events generieren; z.B. zyklisch, nach Ablauf einer jeweils zufällig gewählten Zeit.
- Starten Sie je eine Event-Quelle und eine Event-Senke und testen Sie deren korrektes Zusammenspiel. Benutzen Sie dazu ein Script mit dem Namen test-source-sink.sh, dass die Testfälle automatisiert durchführt.
- Implementieren Sie einen Event-Channel, der gemäß dem Push-Modell Events
von potentiell mehreren Quellen entgegennimmt und diese, ebenfalls gemäß dem
Push-Modell, an die bei ihm registrierte Event-Senken verteilt.
- Starten Sie mehrere Event-Quellen und Event-Senken und verbinden Sie diese durch einen einzelnen Event-Channel, der die Events aller Event-Quellen zusammenfasst und jedes davon an jeder Event-Senke zustellt.
- Die Event-Senken sollten für jedes eintreffende Event eine Ausgabe erzeugen. Wählen Sie die Event-Werte so, dass Sie leicht überprüfen können, von welcher Event-Quelle es stammt und um welches Event es sich handelt (z.B. Ausgabe xxyyy könnte bedeuten: Event-Quelle xx, fortlaufend durchnummeriertes Event Nr. yyy von dieser Quelle).
- Beschreiben sie kurz mind. 3 Testfälle, die die wesentlichen Eigenschaften Ihrer Implementierung des Event-Channel auf korrektes Verhalten hin testet. Realisieren Sie die Testfälle mit Hilfe eines Scripts test-channel-push.sh, dass die Testfälle automatisiert durchführt.
- Implementieren Sie einen Event-Channel, der gemäß dem Pull-Modell Events
von den Event-Quellen entgegennimmt und diese gemäß dem Push-Modell an die
Event-Senken verteilt.
- Die Events sollen in der Reihenfolge ihres Auftretens bearbeitet werden, d.h. der Event-Channel soll nicht blockieren während er bei einer Event-Quelle mittels pull() auf ein Event warten, wenn eine andere Event-Quelle während dieser Zeit bereits ein Event liefern könnte. Bei der Realisierung dieser Aufgabe sollen Sie keine Threads verwenden!
- Beschreiben und realisieren Sie min. 3 Testfälle analog zu Aufgabe 1c. Benutzen Sie zur Realisierung ein Script mit dem Namen test-channel-pull-push.sh.
Bonus: Verändern Sie Ihre Implementation so, dass Sie einzelne Event-Quellen bzw. Event-Senken terminieren können (d.h. den sie beherbergenden Unix-Prozess mittels „kill -9“ beenden), und anschließend wieder neu starten, ohne dass die verteilte Anwendung dadurch beeinträchtigt wird.
Hinweis: Versuchen Sie, ihre Implementation einfach zu halten, z.B. indem Sie mehrere der CORBA-IDL-Interfaces durch ein einzelnes C++ -Objekt implementieren (welches dann eben mehrere IDL-Interfaces unterstützt).
Schnittstellenbeschreibung CosEvents.idl
module CosEventComm
{
exception Disconnected { };
interface PushConsumer
{
void push (in any data) raises (Disconnected);
void disconnect_push_consumer ();
};
interface PushSupplier
{
void disconnect_push_supplier();
};
interface PullSupplier
{
any pull () raises (Disconnected);
void disconnect_pull_supplier();
};
interface PullConsumer
{
void disconnect_pull_consumer();
};
};
Schnittstellenbeschreibung CosEventsAdmin.idl
// CosEventsAdmin.idl (simplified by jpr)
module CosEventChannelAdmin
{
exception AlreadyConnected {};
interface ProxyPushConsumer : CosEventComm::PushConsumer
{
void connect_push_supplier ( in CosEventComm::PushSupplier ps )
raises (AlreadyConnected);
};
interface ProxyPullSupplier : CosEventComm::PullSupplier
{
void connect_pull_consumer ( in CosEventComm::PullConsumer pc )
raises (AlreadyConnected);
};
interface ProxyPullConsumer : CosEventComm::PullConsumer
{
void connect_pull_supplier ( in CosEventComm::PullSupplier ps )
raises (AlreadyConnected);
};
interface ProxyPushSupplier : CosEventComm::PushSupplier
{
void connect_push_consumer ( in CosEventComm::PushConsumer pc )
raises (AlreadyConnected);
};
interface ConsumerAdmin
{
ProxyPushSupplier obtain_push_supplier ();
ProxyPullSupplier obtain_pull_supplier ();
};
interface SupplierAdmin
{
ProxyPushConsumer obtain_push_consumer ();
ProxyPullConsumer obtain_pull_consumer ();
};
interface EventChannel
{
ConsumerAdmin for_consumers ();
SupplierAdmin for_suppliers ();
void destroy ();
};
};
Abgabe und Bewertung
Begründen Sie Ihre Entscheidungen und beschreiben Sie aufgetretene Besonderheiten und Probleme. Benutzen Sie dafür eine HTML Datei mit dem Namen index.html. Abzugeben sind weiterhin die Quelltexte der Lösung und ein Makefile, das die Quellen mit den gängigen Werkzeugen automatisiert übersetzt. Bitte reichen Sie die geforderten Dateien in ein ZIP Archiv gepackt ein.
Material
Introduction to the CORBA Event Service
The CORBA Event Service specification defines a model of communication that allows an application to send an event that will be received by any number of objects. The model provides two approaches to initiating event communication (push and pull).
Communications using the CORBA Event Service
The CORBA Event Service introduces the concept of events to CORBA communications. An event originates at an event supplier and is transferred to any number of event consumers. An event channel mediates the transfer of events between the suppliers and consumers as follows:
1. The event channel allows consumers to register interest in events, and stores this registration information.
2. The channel accepts incoming events from suppliers.
3. The channel forwards supplier-generated events to registered consumers.
Suppliers and consumers connect to the event channel and not directly to each other (figure 1). From a supplier's perspective, the event channel appears as a single consumer; from a consumer's perspective, the event channel appears as a single supplier. In this way, the event channel decouples suppliers and consumers.
Figure 1: Suppliers and Consumers Communicating through an Event Channel
Any number of suppliers can issue events to any number of consumers using a single event channel. There is no correlation between the number of suppliers and the number of consumers, and new suppliers and consumers can be dynamically added to the system.
Figure 2: An Example Implementation of Event Propagation
Figure 2 illustrates an example implementation of event propagation in a CORBA system. In this example, suppliers are implemented as CORBA clients; the event channel and consumers are implemented as CORBA servers. An event occurs when a supplier invokes a clearly defined IDL operation on an object in the event channel application. The event channel propagates the event by invoking a similar operation on objects in each of the consumer servers. To make this possible, the event channel application stores a reference to each of the consumer objects, for example, in an internal list.
Initiating Event Communication
CORBA specifies two approaches to initiating the transfer of events between suppliers and consumers. These approaches are called the Push model and the Pull model. In the Push model, suppliers initiate the transfer of events by sending those events to consumers. In the Pull model, consumers initiate the transfer of events by requesting those events from suppliers.
The Push Model
In the Push model, a supplier generates events and actively passes them to a consumer. In this model, a consumer passively waits for events to arrive. Conceptually, suppliers in the Push model correspond to clients in normal CORBA applications, and consumers correspond to servers.
Figure 3: Push Model Suppliers and Consumers Communicating through an Event Channel
In this architecture, a supplier initiates the transfer of an event by invoking an IDL operation on an object in the event channel. The event channel invokes a similar operation on an object in each consumer that has registered with the channel.
The Pull Model
In the Pull model, a consumer actively requests that a supplier generate an event. In this model, the supplier waits for a pull request to arrive. When a pull request arrives, event data is generated by the supplier and returned to the pulling consumer. Conceptually, consumers in the Pull model correspond to clients in normal CORBA applications and suppliers correspond to servers.
Figure 4: Pull Model Suppliers and Consumers Communicating through an Event Channel
In this architecture, a consumer initiates the transfer of an event by invoking an IDL operation on an object in the event channel application. The event channel then invokes a similar operation on an object in each supplier. The event data is returned from the supplier to the event channel and then from the channel to the consumer which initiated the transfer.
Mixing the Push and Pull Models in a Single System
Because suppliers and consumers are completely decoupled by an event channel, the Push and Pull models can be mixed in a single system. For example, suppliers may connect to an event channel using the Push model, while consumers connect using the Pull model as shown in figure 5.
Figure 5: Push Model Suppliers and Pull Model Consumers in a Single System
In this case, both suppliers and consumers must participate in initiating event transfer. A supplier invokes an operation on an object in the event channel to transfer an event to the channel. A consumer then invokes another operation on an event channel object to transfer the event data from the channel. Unlike the case in which consumers connect using the Push model, the event channel takes no initiative in forwarding the event. The event channel stores events supplied by the push suppliers until some pull consumer requests an event, or until a push consumer connects to the event channel.
Für die Bilder, siehe: http://www.iona.com/support/docs/orbix/gen3/33/html/orbixevents33_pguide/intro.html
Ressourcen
-
Michi Henning, Steve Vinoski: "Advanced CORBA(R) Programming with C++" [amazon]