This chapter is from the book
This chapter is from the book
This chapter is from the book
Variability in CEP Architectures
The core CEP process (Figure 3-1) is always the same: Some event is sensed, it is analyzed in the context of some reference data to determine whether something of business interest has occurred, and some decision is made about what the nature of the response ought to be. Yet despite the fact that the core process is always the same, there are many different architectures for complex-event processing. Why?
)
Figure 3-1: Core CEP Process
There are two dominant reasons for the variability in CEP architectures: the handling of reference data and the partitioning of functionality.
Handling Reference Data
The first area of variability centers around the relationship between the reference data and the events being analyzed: Does the stream of events alter the reference data that is used to interpret subsequent events? Applications in which the stream of events does not alter the reference data are relatively straightforward. The primary challenge in these applications is obtaining access to the reference data, which almost always originates elsewhere, and making access to the data efficient during the analysis and response activities.
On the other hand, applications in which the stream of events modifies the reference data are much more complicated. The portion of the reference data that represents the history of prior events does not have a system of record, at least without additional design. If it is unacceptable to lose this historical data when systems are shut down or fail, then the CEP solution must now include a system of record for the historical data. The system of record requires careful and clever design to ensure that it can handle the stream of data changes efficiently and robustly—and still make the data efficiently accessible to the analysis and response activities (Figure 3-2).
)
Figure 3-2: Persisting Historical Data
Partitioning Functionality
The other area of variability lies in the many ways in which the CEP functionality can be partitioned and assigned to different components. The basic partitioning found in CEP solutions is shown in Figure 3-3.
)
Figure 3-3: Basic CEP Functional Partitioning
Generally, the events driving the process are the observable actions of a participant (human or system) in some business process. Most of these participants do not announce their activities, at least to components not engaged in that business process. For this reason, CEP solutions generally have one or more components dedicated to sensing these actions and announcing their observations.
The techniques used for these observations are the same ones traditionally used in application integration. These techniques, and the products that support them, are detailed in TIBCO™ Architecture Fundamentals.1 The relevant observation here, however, is that the products used for sensing are, for the most part, not the products used for CEP analysis and response. Thus the participant that does the sensing is generally not the participant doing the analysis and response.
As a side note, one of the hallmarks of the event-enabled enterprise is that its architecture includes the types of components necessary to sense and announce actions and the types of components necessary to analyze and respond to those announcements.
In many cases, the volume of events handled by many CEP solutions makes it impractical to have one component handle all of the events and perform all of the analysis and response processing. Once this point is reached, there are a variety of ways in which performance can be increased. One is to simply deploy multiple instances of the component performing the analysis and response. This is a straightforward approach if the reference data is not updated when events occur. But when the reference data is updated by events, sharing the history across multiple instances of the analysis and response components requires additional design. The design patterns for this are discussed in Chapter 14.
Another approach to scalability is to begin to partition the functionality across additional components. Figure 3-4 shows one possible partitioning in which the analysis that leads up to situation recognition is performed by one component and the determination of the required responses is performed by another. Partitioning patterns also become more complex when the analysis and response computations also update reference data. Chapter 13 discusses this and other partitionings as well as the tradeoffs that need to be considered.
)
Figure 3-4: Partitioning Situation Recognition from Response
As should be obvious by now, there are many possible functional partitionings for CEP solutions. Some lead to simple and straightforward implementations. Others require clear architectural thinking to achieve the desired behavior in a robust and highly scalable fashion.
The following sections discuss a number of CEP solution design patterns, each focused on providing a commonly required business capability. For the most part, the patterns are arranged somewhat in order of increasing complexity. The chapter concludes with a brief discussion of problems for which there may not be well-established design patterns.
For simplicity, the sensing component is not shown in these design patterns: It is assumed to be always present.