There is no absolutely correct or unique way to handle events for any application system. Depending on its need and characteristic, each system can have its own implementation of the event system. Even in a particular area such as application systems built using CORBA, we could have different flavors. In this essay, I will summarize the event types and models we have encountered from the list of papers we read on CORBA and CORBA application systems. (Refer to the paper list on my progress reports.)

Two sides, usually a client and a server. The client makes a request with the server, then blocks itself until it receives a response or an exception from the server.

This model is widely used in many application systems.

• Server has to be always available to handle requests.
• Not applicable for some event situations. E.g., the client might be blocked for a very long time or forever for a conditional event such as ‘inform me if the patient’s heartbeat is over 200/min’ happens.

• Does not scale well. Since for each request, there will be a target object to handle that request and there will be one connection for each request. The server might not be able to open these many of network connections.
• Not efficient use of system resource. Since the client can do nothing but to block itself until receiving a reply. Multiple thread/process may have to be used if it needs to deal with multiple tasks.
• Not suitable for group or mass notifications.

• Simple concept and implementation.
• More secure since it is one dedicated connection.

Two sides. One side makes a request without blocking itself for response. One side provides the response. To receive response, the system uses

1. Callbacks from the other side, once or periodically.
2. Pulling, once or periodically.

Callback once from the other side and polling are two mostly seen model.

These decoupled approaches are more complicated than synchronized ones. At least one side needs to maintain the connection information, provides register and un-register interface. In order to survive from application re-starts, events and connection information should be kept in a reliable storage for persistency (system dependent). Error and exception handling tends to be more complicated as well.

In addition, the characteristics of a particular system might put some cases more complicated. For example, in order to un-register, the application needs to locate the right connection and cancel it. Some matching function needs to be used. However in CORBA, if we just use the object reference in returning and matching for simplicity, the is_equivalent function does not guarantee the right answer when comparing two object references. It could return no for situations that it could not be decided. As an alternative, the actual object needs to be returned when one side registers itself.

The decoupled system could be more flexible and more intellectual in implementation. For example, when thousands of requesting sides register for the same event notification, in synchronous case, thousands of objects on the requested side must be generated. However, in asynchronous case, the same request may be combined, and the requested side could just launch one object and send the reply to all of the requesting side.

In any systems, reliability is always versus the complexity. Since requests are decoupled and could be answered much later. Problems raise as how to handle when error situation happens, how to inform exceptions to the other side, how to handle some bad behavior of the other side, how to avoid itself getting into the hang state, etc. The solutions are purely dependent on the implementation of each system. However, reliability of a system is always in exchange of the system complexity.

Scalability varies by systems. Overall, asynchronous is better than synchronous and discontinued system pulling or callbacks is better than continuous implementation. Asynchronous is better than synchronous on that it is likely that there are less concurrent connections at a particular time, However operating system handle ability might block us for more connections because overwhelming volume of connecting request at a particular time(in polling case). Also in a poor implemented server, if it does not handle a situation correctly when the other side does not co-operate, accidentally unclosed connections will have dramatic bad effect on scalability.

Decoupled systems tend to be more breakable than coupled system. Fortunately, in CORBA, type-safe extraction of event data from the IDL any type helps one side to filter out unwanted event. However there is no way to control the request volume that one side polls or callbacks to the other side. Potentially, one side could be flooded by the other sides.

The requested side sends reply back to the sender when requests being processed or notification condition is satisfied.

.

• In the callback case, we are no longer having the concept of the‘client side’ and the ‘server side’. In order for the request initiation side to be able to accept the other side’s contact, it has to run some sort of server program. In this case, we are having peel-to-peel, and both sides are of equal thick. This is not applicable for thin client application systems.
• Any periodically callbacks is bad for the scalability.
• Even though the event-driven method (one side notifies the other side when reply is ready) is the most prompt, efficient, and economic. In the actual implementation, the event supplier side could use polling mechanism within itself in order to tell whether it is time to send the reply. In this case, lots of system resources on the requested side could be devoted for that.
• Depend on implementation, there could be a potential deadlock. For example, in our un_register (cancel request) and callback (notifying) function , if we set it to be two way CORBA call, (otherwise, we can not assure of its end-to-end reliability.) when the requested side sends a reply, the system could go into deadlock if the requesting side has just sent out an un-register request.

• Multi threading implementation is not a must. To request, the initiation side sends the request and does not block itself. To reply, the side only needs to send the initiation side a reply without waiting or blocking.
• No polling and thus no network flooding, less likely for server being flooded, and less system resource consumption.

The requesting side re-connects the requested side, and checks if the result is available.

• This floods the server and network if it polls too often or having potential long delays if it polls less frequently.
• The being polled side has to maintain a buffering for events that are not yet delivered. Consideration for buffer limits and the choice of the victim events in time of over-buffering adds complexity to the system.
• The polling side has to devote some resource for the periodically pulling. If a multi-thread system is designed, the system might be a little bit complicated.
• Polling system is bad for scalability.

• One side does not have to implement some passive server to listen to the reply and the implementation of that side could be very simple. Thin client application system could be implemented based on this model.

Three parties, an event supplier, and event consumer, and a ‘mediator’ (event channel) in between of the two. The event channel provides delivery of event data from event supplier to event consumers without requiring consumer and supplier to know each other.

There are four models of component collaboration, Canonical push, canonical pull, hybrid push/pull, and hybrid push/pull. (see Douglas column 9, figure 4). Any application system that uses the Event Channel needs to choose one from these models.

The event service specification is rather general. It lacks detailed semantics or protocol specification. The intention behind is to avoid over-constraining for all system implementations and to allow developers only implement features that are necessary. As a result, how event channel will behave and how its features (filtering, transactions, implement of persistence, realization of correlation, etc) are designed could vary from vendor to vendor. An example Douglas has given is that in OrbixTalk, the events are distributed via IP multicast which is different to the HP ORB Plus Events Service. Its distribution is based on IIOP that sequentially deliver event data to consumers.

Event channel usually has to provide the interface so that consumer and supplier can connect with the event channel. (Not necessary persistent connection). In addition, it needs to maintain supplier and consumer connection information as well as some administrative duties.

• Event consumer and producer don’t have to know who is who.

• Has a simplified consumer and supplier. In this design, part of the responsibility of both sides in our second event type is moved to the Event Channel. For example, multiple registrations, event data persistence, and filtering.

• Event channels can be hooked to another event channel through the regular event channel consumer and supplier interfaces. In some degree, this allows a combined event service (e.g. multiple conditions) to be possible. However, it has to follow a particular workflow.
• Multiple event channels could be used in between the consumer and supplier for different event types, and potentially be used for different QOS and filtering requirements. The current Event Channels however does not do any kind of filtering.
• A better group event service.
• This star design should have a better scalability than the two party design, especially if we have multiple consumers and multiple suppliers. For example, if we have m consumers and n suppliers, in the star design, the connections we need is m+n. However in the two party design, we need mn connections. In addition, the ability that event channels could be hooked up with one another also provides a good potential for scalability.

• Since this model allows pulling in some models, it does not solve any problem related with pulling. E.g. network flooding, pulling side resource cost, side being pulled being over-flooded, event buffering, discarding rules, etc.
• If event channel is hooked up with another event channel, one extra hop will be introduced.

• Event service does not require any implementation of filtering. Event channel could deliver all events from all suppliers to all consumers. It is to the consumer to discard the events they don't want. However, this will causes unnecessary waste of network and consumer source. One solution is that we can set up separate event channels for each type of events. The other solution, we could set a filter in the event channel, but this would require extra interfaces on the Event Channel Implementation that allows filters to be installed in the Event Channel. (see more discussion on filters at below.)
• Since there might be multiple consumers and suppliers with the same event channel some OS limitation and handle ability could become a drag on where the event channel is running on.
• The system is less prone to single-point-failure -- the failure of the event channel. Event channel has to be designed and implemented to be very reliable. It has to handle bad behaved supplier and consumer in order to avoid itself to hang. Depending on event model, it may provide buffering of event data and make sure the persistency of the event data

(http://lsewww.epfl.ch/~rachid/papers/ftdcs97.ps.gz)

In order to solve the event channel as the single point of failure, several ways are suggested to de-centralize the event service.

Firstly, event channels can be replicated. With event service push model, a replication copy of the event data could be produced when the event channel pushes event data to all consumers. The replicated server only needs to register itself with the event channel as a regular consumer. Not too much extra work is needed if we only require one replica server. However, group communication is needed to keep replicated event channel objects consistent if more than one replica copies are needed.

Another approach is to split one event channel to several ones based on 'duties'. For example, one event channel could be divided into two event channels, one sits close to the event consumer and one close to the event supplier, and depends on whether it handles response or request, the event channel could be further divided into more event channels.

Since CORBA Event Service does not require the event channel to do filtering, and event data could be pushed from all suppliers to all consumers. As a result, consumer could get unwanted event data and it is up to them to take only those that are useful. This is bad as it wastes the network bandwidth. If we just let consumers figure out its own event by checking whether casting IDL any to its event data successful or not, it might be inefficient for high-performance applications. Besides, it will cause a potential security leak.

One solution is to attach the filter in the event channel so that consumers only receive events that they are interested in. TAO, a real time event service developed at the University of Washington uses this model. Even though this does not require any changes in the Event Channel Specification, it does require an extra interface to be written so that filters can be installed within the event channel. In this solution, how the filter is to be implemented is totally left with each system. A suggestion has been proposed to standardize the filtering by extending the CORBA Event Service Specification to explicitly support event filtering.

The drawback of putting the filters on the event channel is that it increases the complexity of the event channel, slows down the process, while the event channel is the single point of failure of the system.

Filters can also be put at the event supplier side. The advantage is that overall, it does not send out unwanted event data, and it does not cause the single point failure. However, it can not solve the case when multiple consumers have different filtering requests. Event data will be sent out as long as one consumer requests it, to all the consumers. In addition, in this model, event supplier has to maintain all the consumer information, which is not suitable for some types of the systems. E.g. channeled (grouped) music broadcasting. The consumers might not want to identify themselves, or there are potentially large number of consumers. For the supplier, even though all it cares is just the consumer’s group identifiers instead of their own identifiers, ids must be kept in order to decide which group the consumer belongs to. This design also increases the complexity of the supplier. It has to provide interface for the consumers to ‘subscribe’ to. However, this design has been quite attractive and being adopted by event systems such as CORBA Event Architecture (CORBEA) developed at Cambridge. TAO, besides its filtering in its event channel, also defines event subscription, which eventually provides supplier-based filtering.

One general design principle about filtering is that it is important to keep filters as simple as possible at the event system support layer. (CORBA event service does not have any requirement for filtering even though some people have suggested that CORBA event service should be extended towards that direction.) Application layer is the preferred layer to apply more sophisticated filtering. Also depend on a particular event system, the tradeoff between the event traffic and the complexity of the filter implementation should be carefully considered.