Other Issues

• Dynamic Addition of New Event Types or Data
  Dynamic addition of new event types is supported by using the generic typed interfaces defined in COBEA. Dynamic attachment of application-specific data to a generic event is supported by using the parameter event_body. Any type of data may be cast into this CORBA any parameter, which has two fields: _type and _value; _type can be checked in order to get the _value correctly.
• Working with the CORBA Event Service
  COBEA may be implemented alongside, or as an extension, to the CORBA Event Service. We have chosen the former for our current approach. A better alternative might have been to extend the CORBA Event Service interfaces to incorporate the new features supported in COBEA for standardization purposes. For example, the COBEA snk interface may be defined as follows:

   
  #include CosEventComm.idl
  module BaseEvent{ 
        ...
  interface Snk:CosEventComm::PushConsumer{
   void notify(
    in EventHeader e, 
    in any data) 
   raises (NotConnected);
   void disconnec_snk();
   }; 
  
  interface Src { ... };
  };

  Also as mentioned earlier on in this paper, the pull model can easily be supported in COBEA by simply incorporating the pull interfaces of the CORBA Event Service. For example:

   
  #include CosEventComm.idl
  module BaseEvent{ 
        ...
  interface COBEAPullSupplier:
   CosEventComm::PullSupplier{}; 
        ...  
   };

• Event Naming and Locating
  In COBEA, event type names are the same as interface type names, therefore a trader can be used to handle event naming and location; an event with parameters is like a service with attributes. If consumers are concerned with the content of an event (i.e. particular values of parameters), e.g. IBM stocks and Microsoft stocks of the StockQuote event, filters must be used to receive the quote of a particular stock only; a trader is not enough here.
• Event Buffering and Logging
  It is possible for events to happen before interest has been registered. Sometimes, a consumer can not digest all the events being supplied. It is therefore useful to buffer events at suppliers or mediators. A Time-To-Live (TTL) parameter can be associated with an event instance to make sure an event will not be discarded too quickly by the supplier or the mediator. It is useful to allow the consumers to specify a TTL. For some applications, events should be logged or made persistent if they may be subject to frequent query later. For instance, a security audit server may want to monitor logins by users, and log those events as evidence in case somebody attempts to use unauthorised resources.
• Service Configuration
  We propose a hierarchical structure (i.e. a rooted acyclic graph) for organising the servers which provide an event service cooperatively. Events generation may be partitioned among the servers, thus if a server does not know about a certain event itself, it can get help from the server which knows. In Figure 6, five servers are responsible for supplying events partitioned in the event groups Gr, G1, G2, G3 and G4 respectively.

    
  Figure 6: Composite event servers involved in handling a composite event
  

• QoS
  In COBEA, a priority parameter in the event header can be used to specify the priority of an event. In addition, event queues are maintained according to priority for each event type, and events are sent FIFO within a priority. The QoS parameter in the register() operation can be used to specify speed or mode of event delivery, i.e. fast or reliable mode; the former has no guarantee of delivery of the event, while the latter is implemented on top of a reliable transport protocol, thus can guarantee reliable delivery (e.g. events are delivered at least once and in order). Events are notified in the order of occurrence within a priority. The parameter may be used in many applications, for example, in telecommunication where fault events (or alarms) have to be delivered quickly so that the fault can be identified and rectified, however, performance events can tolerate some delivery delay as they are generally analysed off line at some later time.
• Security
  In many applications, events are required to be delivered or viewed only by authorised consumers. An object system where access control is based on object or method invocation only has not sufficient support for such requirements. Event-based access control requires that access control can be carried out against each event occurrence. On the one hand, suppliers or mediators (i.e. servers) are responsible for checking if an event can be delivered to the interested consumers. On the other hand, the servers must have the right to invoke the notify() operation at the consumers. In COBEA, a consumer must supply its user/role name using the who parameter when registering events. The parameter will be validated by the server to make sure that the consumer has the right to access the particular event. In order for the supplier to invoke the notification operation at the consumer, an ORB supporting secure method invocation, as specified by the recently adopted OMG CORBA Security Standard [16], can be used. Although many events have been excluded at registration time, more access control is still required in an event-based system. To avoid computation explosion in the order of O(no. of events no. of consumers), coarse-grained access control based on object domain, event type, or method invocation only can be used as an alternative to the fine-grained control based on event occurrence. Failing this, optimised validation is still possible for access control depending on client credentials or event data only but not both.