Event Models in Distributed Event Based Systems

Introduction

Applications are regularly developed by composing functionality encapsulated in units of computation. Depending on the type of system these units of computation, components for short, include modules, classes, and programs. The functionality provided by components can be composed by procedural abstraction and implicit invocation (Garlan & Shaw, 1994; Dingel et al., 1998; Notkin et al., 1993). When composing functionality by procedural abstraction, also referred to as explicit invocation, names that identify a component are statically bound to the component implementing the functionality. This is the case of a function in one module invoking another function in another module, or a program in one computer using a Remote Procedure Call (RPC) to invoke functionality implemented by a different program on another computer. In contrast, when composing functionality by implicit invocation, a component announces an event. This event announcement triggers the invocation of functionality implemented by another component. The component announcing the event may or may not be required to know the name nor location of the component triggered by the event.

Distributed Event Based Systems (DEBSs) are implicit invocation systems (IISs) comprised of distributed components that interact with each other using events only. Events are generated by components called publishers. Components interested in the events that have been generated, are called subscribers. A subscriber is notified when an event of interest to the component is generated by a publisher.

The term event model is used in the area of IISs research to characterize two different things. For some researchers, the event model of a system determines the support that the system provides for structuring event data (Rozsnyai et al., 2007). Here, we take a more general approach, similar to that of Garlan and Scott (1993), and Meier and Cahill (2005). We consider the event model to determine the application-level view that a developer must have in order to develop an event-based application or component. Hence, the event model determines how events are defined, how they are announced to other components, how components manifest their interest in events, and how events are delivered to interested components.

The event model found in DEBSs is frequently referred to as publish/subscribe (Eugster et al., 2003). The term publish/subscribe is quite generic and applies, not only to DEBSs, but to any IIS where components invoke a subscribe operation to manifest their interest on events, and a publish operation to announce events. Since the event model of a system goes beyond the actual mechanism used to announce and subscribe to events, we refrain from using the term publish/subscribe, and refer to the event model found in DEBSs, generically, as the DEBS event model.

In this chapter we identify and characterize the features of the DEBS event model, compare the DEBS event model to event models found in other IISs, and illustrate the variations that exist within different DEBSs. The identified features elicit the key aspects that need to be supported by software engineering methodologies, structuring and modularization constructs for DEBSs. Hence, the DEBS event model here presented can be used to validate the support provided by existent software engineering methodologies for the developments of applications in DEBSs, or it can be used as the starting requirement for new proposals.