Application Scenarios Supported

Scenario 1
An application creates a mediator object as a notification service with a generic interface for event registration and notification. OrbixTalk [10] and the TINA notification service can be constructed this way in COBEA. This scenario is not well supported by either the CORBA Event Service or the Cambridge Event Paradigm, in the latter a composite event server would be used for this purpose. Examples of such scenarios can be found in [10, 13, 21].

Scenario 2
An application defines its own typed interfaces for events which can be supported by the class library implemented for the primitives in COBEA. The applications supported by the Cambridge Event Paradigm can all be constructed this way in COBEA. This scenario is not well supported by the CORBA Event Service, and not supported at all by the TINA notification service in which an intermediate server is enforced. Examples of the scenario can be found in [3, 11].

Scenario 3
An application defines its own proxy for typed events without inheriting from the generic TypedProxy interface. The CORBA typed event channel can support this scenario but no provision for registration of events is available. Furthermore, three steps must be carried out for connection to a CORBA event channel: (1) get an object reference for a factory which returns the reference to the proxies; (2) get an object reference for the supplier/consumer proxy; (3) connect to the proxy. It is much simpler to connect to the mediator than to the event channel.