Event-Driven Virtual Machine for Business Integration Middleware

Transcription

1 Event-Driven Virtual Machine for Business Integration Middleware Joachim H. Frank 1, Liangzhao Zeng 2, and Henry Chang 2 1 IBM Software Group jhfrank@us.ibm.com 2 IBM T.J. Watson Research Center {lzeng,hychang}@us.ibm.com Abstract. Business integration middleware uses a variety of programming models to enable business process automation, business activity monitoring, business object state management, service mediation, etc. Different kinds of engines have been developed in support of these programming models. At their core however, all of these engines implement the same kind of behavior: formatted messages (or events) are received, processed in the context of managed objects, and new messages are emitted. These messages can represent service invocations and responses, tracking events, notifications, or point-to-point messages between applications. The managed objects can represent process instances, state machines, monitors, or service mediations. Developing separate engines for each programming model results in redundant implementation efforts, and may even cause an "integration problem" for the integration middleware itself. To address these issues, we propose to use an event-driven virtual machine that implements the fundamental behavior of all business integration middleware as the sole execution platform, and provide compilers for higher level programming models. Conceptually, this is similar to passing from CISC to RISC architecture in CPU design: efficiently implement a small instruction set, and support higher level languages via compilers. 1 Introduction The key observation leading to this work was that event-driven systems [1] [2] [3] implement all of the key mechanisms used by integration middleware components: event/message 1 identification, correlation, updates of stateful objects, and emission. In a business integration environment, which can include components for business process automation, business activity monitoring, service mediation, and so on, events are typically transmitted over a network, for example in the SOAP [4] format. While eventdriven systems are gaining considerable momentum in both academia and industry, no unified architecture has been proposed for a generic event processor in the business integration middleware domain. Instead, different engines are developed for different high-level programming models, all of which implement the same fundamental set of operations. For example, in a business process management (BPM) system events 1 Throughout this paper we use the term "event" synonymously with "one-way message". P.P. Maglio et al. (Eds.): ICSOC 2010, LNCS 6470, pp , Springer-Verlag Berlin Heidelberg 2010

2 572 J.H. Frank, L. Zeng, and H. Chang indicating that a process should be started or an activity has completed are received, correlated, and used to update process instances. As another example, in a business activity monitoring (BAM) system, tracking events are received, correlated, and update metrics in an observer object (monitoring context). While the need for different high-level programming models in the business integration domain seems obvious, developing separate engines for each of those models results in: (i) redundant development efforts; (ii) high installation and maintenance cost for a variety of engines; and (iii) possibly additional work to "integrate the integration platform". After analyzing various business integration programming models, six fundamental capabilities emerged that they all had in common: identifying and receiving events; correlating events; creating, updating, and deleting stateful objects; and emitting events. These basic capabilities were captured in a concise machine language with six instructions. A virtual machine for this language was developed and tested with a variety of event processing applications. The main contributions of this paper are thus: A machine language for event-driven applications. We propose a machine language for event processing called ICE (for Intermediate CodE). It has six instructions that cover the fundamental spectrum of capabilities required by business integration middleware. The small instruction set facilitates building virtual machines for this language on different hardware platforms and operating systems. A componentized ICE virtual machine. We present a virtual machine for the ICE language, written in Java. It can be embedded in event-processing applications, or be at the core of a business integration hub or event processing service. Its component architecture allows to easily replace functional parts (for example, the expression evaluator or the persistence manager) which helps portability. A collection of ICE compilers. We discuss how to write ICE compilers for higher level programming models, so that business integration software written in a variety of high-level languages (processes, mediations, monitor models, etc.) can run on the same virtual machine. 2 ICE Language 2.1 Overview An ICE virtual machine ("ICE machine") provides an execution environment for processing events in the context of target objects. A target object may represent a state machine, a process execution, a stateful mediation, a monitoring context, and so on. Events are processed in an ICE machine using five basic steps: (1) Event filtering, to determine the kind of the incoming event. (2) Event correlation processing, to find target objects, and instantiate new ones if necessary. (3) Update operations, to change the state of the target objects. (4) Event emission, to send out requests, replies, alerts, etc. (5) Terminating target objects. The ICE instruction set reflects these five operations, with a sixth instruction added for conditional branching.

3 Event-Driven Virtual Machine for Business Integration Middleware Instruction Set Following a reduced instruction set paradigm (similar to the RISC philosophy in CPU design) we defined a small but fundamental set of event processing instructions. It appears that the following six instructions are necessary and sufficient to support any event-driven application: 1. onevent. An onevent statement represents an event subscription. It has a Boolean filter condition which defines the subscription criteria: events that pass the filter, and only those, will be processed by the onevent statement. The statement can nest an instruction sequence, and when an incoming event passes the filter, that sequence is executed. The nested statements can be any of the following: 2. forall. A forall statement selects target objects based on a target object type and a correlation predicate. The correlation predicate is evaluated for all target objects of the given type. It typically compares a key value in the incoming event with a field containing this key in all candidate target objects. Zero, one, or several matches can result, and the forall specifies what to do in each case. Here are some examples: create a new target object if none was found; process the event for all matching target objects; ignore the event if no target is found; raise an error if more than one target is found; etc. A forall can nest a statement sequence, which is executed once in the context of each target object. If forall statements are nested, a tree of target objects results with each nested forall contributing a new set of child nodes. 3. assign. An assign statement has a left hand side expression whose evaluation must yield a slot in the target object s data structure ( target slot ) and a right hand side expression that can depend on target object data and the current event. The target slot is updated with the result of the right-hand side, and created if it did not exist. 4. branch. A branch statement allows for conditional branching within an ICE program. It has a Boolean branch condition. If it evaluates to true the branch is taken, otherwise execution continues with the following statement. A branch may specify a positive (forward) or negative (backward) branching distance. 5. emit. An emit statement specifies that an outbound event will be sent, whose payload will be taken from a specified target slot. 6. terminate. A terminate statement specifies that the current target object (identified by the nearest enclosing forall) is to be removed from the set of objects under control of the ICE machine after the current event has been processed completely. The instruction set of the ICE machine is minimal for a virtual machine that processes events in the context of target objects: Obviously, an instruction is needed to receive and classify events (onevent) and to send them out (emit); a correlation step is required for target identification (forall); there must be instructions for target object creation (forall, implicit), update (assign), and deletion (terminate). Target object creation is covered by forall with the no correlation matches option set to create new target. Finally, a statement is needed to permit conditional logic (branching) and for a machine language, GOTO semantics seemed adequate.

4 574 J.H. Frank, L. Zeng, and H. Chang 3 ICE Machine 3.1 Component Architecture Two considerations guided our design: (i) Pluggability of Components. A modular structure as in Fig. 1 allows to vary implementation options and facilitates portability. For example, different Expression Managers can support a variety of expression languages and evaluators. Different ICE Cube Managers (persistence managers) can provide interfaces to a variety of databases. (ii) Usability in Different Environments. It should be possible to use an ICE machine as a universal event processor in a variety of environments: embedded in applications; as a stand-alone middleware component; or as an event processing service in a cloud environment. Fig. 1. ICE Machine Architecture Overview 3.2 Components As shown in Fig 1. an ICE machine has five components: program manager, event manager, cube manager, expression manager and kernel. They interact as follows: 1. The Program Manager receives ICE program segments. A program segment is the smallest unit of logic that can be deployed to or removed from an ICE machine. The program manager parses the program segments and constructs an in-memory model of the code, which the kernel will use to control execution.

5 Event-Driven Virtual Machine for Business Integration Middleware The Event Manager receives incoming events and puts them in the input bucket, from where they are consumed by the kernel. Events can be returned to the event manager if correlation processing ends with a "retry" condition (typically, when an expected target object does not yet exist) or when unrecoverable errors occur; they are then put in the retry or error bucket, respectively. Events in the retry bucket are moved back to the input bucket after some wait time. An event that has exceeded the maximum number of retries goes to the error bucket. The event manager also publishes outbound events produced by emit statements. Their further processing and routing, for example via an ESB or pub-sub infrastructure, depends on the environment in which the ICE machine operates. 3. The Cube Manager handles the creation, persistence, locking, updating, and termination of target objects. The target objects in an ICE machine are dubbed "ICE cubes" which explains the name of this component. 4. The Expression Manager is called by the kernel to evaluate filters, correlation predicates, branch conditions, and right hand sides of assigns. It is passed an expression and its evaluation context, which consists of the current event, any target objects, and any local variables. It returns the evaluation result. 5. The Kernel is the actual virtual machine. It fetches an event from the input bucket, initiates a new ICE program execution, and runs it by interpreting the ICE program. It calls the event manager, the cube manager, and the expression manager to use their services as needed. 3.3 Compilers A detailed description of ICE compiler algorithmss for the programming models commonly used in business integration would exceed the realm of this paper, but here is an outline: The simplest use case is stateless message transformation (mediation) which is translated into an ICE program with a onevent statement for each type of message to be transformed. It contains a sequence of assigns updating a local variable, and an emit to send out the content of that variable at the end. No target objects are used. A monitor model [2] [3] is compiled by mapping each event subscription to an on- Event (for filtering) followed by a forall (for correlation). The target object now represents a "monitoring context" whose fields (representing metrics) are updated by assign statements based on the content of the incoming event. Outbound events are sent via emit statements; their triggers are translated into branch statements, which skip the emit if the trigger condition is false. A business state machine is compiled by generating an onevent/forall pair for each kind of event that the state machine can process. The target objects are state machine instances. State machine start events will find no target instance, and their forall will create a new instance in an initial state. Other events, once their target object has been identified by a forall, will drive assigns that put those target instances in a new state, followed by emits for any events to be sent as part of the state transition. A business process [5] can be considered a state machine whose states are given by token placements on the process graph. Process start events create a new instance corresponding to an initial token placement. Events representing activity completions,

6 576 J.H. Frank, L. Zeng, and H. Chang or (BPMN) process events, cause transitions to new states by tokens being added and/or moved to subsequent nodes of the graph. As tokens enter nodes, outbound events may be sent representing service invocations or process event emissions. An illustration is shown in Fig. 2, where a business integration solution comprising a business process, a monitor model, and a service mediation runs on a single ICE machine after all of the higher level logic has been compiled into ICE programs. Fig. 2. Illustration of using common intermediate code (ICE) for different high-level programming models 4 Implementation Aspects Our ICE machine prototype was developed in Java. Any well-formed XML can be processed as an event. We currently have two event managers, one using JMS and one using in-memory queues. The program manager and the kernel are pure Java. The expression manager uses an XPath 2.0 [6] evaluator, and is the most performancecritical component at this time. There are two versions of the cube manager, one that holds target objects in memory and one based on Apache Cassandra [8]. Assemblies of these components into a full ICE machine are currently available as a stand-alone Java program, as a Java EE application on IBM WebSphere Application Server [7], and as an event processing stage in Apache Cassandra.

7 Event-Driven Virtual Machine for Business Integration Middleware 577 An implementation of the cube manager using an XML database is in preparation, and we expect that pushing expressions to the database will result in significant performance benefits: correlation predicates for example become queries that return the keys of matching target objects, which can benefit from indexes on those keys. The ICE machine has an external control interface, which allows to deploy and remove ICE program segments, submit events, inspect the three event buckets, browse the object store, and control the virtual machine. In the WebSphere based implementation the control interface is exposed as a REST API. This version of the ICE machine is also used in an interactive debugger for monitor models [3]. 5 Related Work We review some related event-processing systems, including active databases, complex event processing applications and event stream processors. Modern database systems support triggers as a means of reacting to certain conditions (or "events"). Triggers are part of the SQL3 standard [9] and use Event Condition Action (ECA) rules to specify their logic. However, the events in database ECA rules are limited to database state transitions. It should be noted that an ICE machine can also be considered an ECA rule engine, because ECA rules can be complied into ICE programs thus adding to the set of high-level programming models that an ICE machine can handle and affirming its role as a "universal" event processor. An ICE machine imposes no limitations on the format of the events processed (our current implementation accepts any well-formed XML). Unlike active database systems, which provide a data-centric approach to event processing, complex event processing systems [13] are usually considered middleware. They can enrich and extend the event processing semantics in active databases, and provide a collection of event operators that allow to define complex event patterns. These operators include and, or, sequence, not, periodic, etc. Note however that event patterns can also be compiled into ICE programs. For example, the complex event Event_A and Event_B would be realized as two onevent statements, with subsequent logic to register the arrival of each event in a stateful target object, and emit the "combined" event after both have arrived. Event stream processors [10] [11] [12] consider a collection of events in a time window as relations, using SQL like languages to process the event streams. Unlike traditional database systems, which assume that data is persisted first and processed later, event stream processors process events in memory, following a paradigm of "read and read only once". Event-driven systems on the other hand, including the ICE machine, focus on individual events rather than collections, and perhaps the most distinguishing feature of the ICE machine is its correlation logic, putting events in the context of target objects that persist the processing result. 6 Conclusion We have introduced an event-driven virtual machine as a universal runtime for business-integration middleware. It features a minimal instruction set and a componentized

8 578 J.H. Frank, L. Zeng, and H. Chang engine. We briefly discussed compiler algorithms for a number of programming models used in the business integration domain. Going forward, we plan to improve the performance and scalability of the ICE machine, provide improved tool support, an open testbed, and study its usability as an event-processing service in a cloud environment. References [1] Zeng, L., Lei, H., Chang, H.: Model-analysis for Business Event Processing. IBM Systems journal (2007) [2] Zeng, L., Lei, H., Dikun, M.J., Chang, H., Bhaskaran, K.: Model-Driven Business Performance Management. In: ICEBE 2005, pp (2005) [3] IBM WebSphere Business Monitor, topic/com.ibm.btools.help.monitor.doc/home/home.html [4] SOAP specification, [5] BPMN 2.0 specification, [6] XPath 2.0, [7] IBM WebSphere Application Server, [8] Apache Cassandra, [9] Kulkarni, K., Mattos, N.M., Cochrane, R.: Active database features in SQL3. In: Paton, N.W., Gries, D., Schneider, F. (eds.) Active rules in database systems. Monographs in computer science, pp Springer, Heidelberg (1999) [10] Babu, S., Widom, J.: Continuous queries over data streams. In: SIGMOD Rec. 30,3,2 [11] Fjording the Stream: An Architecture for Queries over Streaming Sensor Data. In: ICDE 2002 (2002) [12] Chandrasekaran, S., Franklin, M.J.: Streaming Queries over Streaming Data. In: VLDB 2002 (2002) [13] Luckham, D.C.: The Power of Events: an Introduction to Complex Event Proc-essing, in Distributed Enterprise Systems. Addison-Wesley Longman, Inc, Amsterdam