Design Patterns in CEP – The instance Life Cycle

Much has been written on CEP design patterns. You can find two very good whitepapers on the subject on the Complex Event Processing website. These whitepapers and various blogs very clearly and succinctly describe a number of use-cases that show how CEP engines with their complex pattern detection and temporal awareness can be used effectively to derive real business value from streaming data sources. However, in reading these documents and contrasting them to my own experiences with Apama CEP applications they miss a very real and fundamental design pattern. That of instance life cycle management. I see Complex Event Processing as much more than pattern detection but as the need for pattern detection and the expression of business logic executing within a managed life cycle context.

What I mean by the instance life cycle is the need to invoke multiple application instances upon receipt of specific control events or the detection of event patterns. The execution context and the application instance that runs within it define a unit of work. The life time of instances is driven directly by the application's semantics. Instances might have a long or short life span. There are three basic traits of the instance life cycle; creation, modification and deletion. Creation is simply the need to establish a new object instance and context for its execution. Modification is the need to support dynamic changes to the operational state (i.e. runtime parameters). Lastly, is support for terminating a running instance – either abruptly or gracefully. The instance life cycle can be managed by various means - other parts of an application or from a user's dashboard. Interfaces to create new, modify existing or delete instances, given adequate security privileges should be present. The runtime environment of the CEP engine should provide a means to establish and manage these application instances.

To be a bit more definitive, instances can represent many differing aspects of an application. In the Algo Trading world 'instances' generally refer to running trading strategies. The basic template of a strategy is to take a set of input parameters during creation. For example, an Arbitrage strategy might take two instrument names and a Bollinger Band range as input. Modifying the running strategy might be the ability to increase or decrease the Band range. Deleting the strategy would cause it to either complete or cancel any outstanding orders its managing and then terminate. Given this example, executing multiple concurrent instances of the Arbitrage strategy should be a straight forward task and the CEP engine should provide the corresponding language semantics to make this a simple task.

Instances are not limited to this top-level construct of a strategy. They could represent many things in a CEP engine. Using another finance example, a CEP application designed for best execution of client orders would represent each client or parent order as an instance. Each subsequent child order also represents a managed instance with its own life cycle. For a CEP application monitoring a manufacturing environment, instances might represent parts moving through a production process from raw material to finished goods. A managed instance could represent a mortgage application as it flows through qualification in a BAM application within a bank.

In some respects I'm not identifying a revelation or an idea all that new. Commercial applications of all sorts incorporate the notion of instance life cycle management. It's a classic design pattern that is provided in some form in both development languages and application frameworks (i.e. AppServers). The point I'm attempting to identify is that one should be wary of getting enamored with the uniqueness of CEP. It's not just about design patterns for filtering and enrichment but also incorporating classic and traditional constructs for application design and implementation. In the traditional languages such as java and C++ the instance design pattern can take numerous forms. It can be as simple as the new operator. Thus an instance can be represented as a new object instance of a class. An instance could take the form a thread via CreateThread or in the old-school Unix mentality, an instance can be a forked process. Granted all of these are not equivalent, there are pros and cons in using them for life cycle management. Furthermore, frameworks such as J2EE application servers provide their own instance management schemes to make the application development task of instance management easier. CEP engines that are implemented using an embedded model, specifically those that run within the context of a host language (i.e. java) and/or infrastructure (i.e. AppServer) can leverage these inherent lifecycle instance management capabilities.

Other languages have managed to leverage the best of these options to create safer more scalable instance management. Apama's MonitorScript event processing language (EPL) supports an application threading model via a spawn operator. Each instance is referred to as an mThread. From this core capability in the EPL, the life cycle design pattern is built. The spawn operator allows Apama CEP applications to be built and designed to leverage the best of thread-based concurrent programming (simpler coding model, code isolation and encapsulation, etc.) without the worry of all the complex uses that surround the use of system threads (thrashing, non-deterministic scheduling, poor portability, poor scalability). mThreads in MonitorScript guarantee predictable behavior, are fully deterministic, fully portable and massively scalable. This capability is not adjunct to the Apama platform. It's a core capability inherent in the language and heavily leveraged by many of the supporting development and runtime tools.

CEP platforms that narrowly define the paradigm of event stream processing as a language for filtering and enrichment leave many very important aspects of application management undefined and as such challenging to implement. The uniqueness and the benefits of CEP are clearly evident in the many documented design patterns. However, CEP cannot ignore the mature aspects of traditional application design such as instance life cycle management.