On terminology again - BEP and CEP

There were several postings in the last few days from my esteemed colleagues - David Luckham, Tim Bass and Pual Vincent (in his comment to Tim's posting) all referred to the term "Business Event Processing" (BEP) that has been mentioned by Sandy Carter, VP of SOA and Websphere marketing in IBM. There were several references to this term relative to CEP.

The terminology issue is sometimes confusing, so let me clarify here: as I have discussed the
*-EP phenomenon in the past, so I'll dedicate this posting to clarification.

Event Processing, in general, is bigger in scope from Complex Event Processing; CEP deals with the detection of patterns over the a collection of events ("event cloud"). Event processing starts from stateless filtering and pub/sub, advances to mediated event processing - transformation, enrichment, validation etc, then to CEP, and to IEP (Intelligent Event Processing) that adds stochastic reasoning.

BEP (Business Event Processing) is an event processing applied to business applications. To Paul Vincnet's question - are there "non business" EP - the answer is -- yes, event processing can be used for individual person in smart homes; some people also see IT system management as a "non business" application, and differentiate between business and IT. What is the relations between BEP an CEP ? BEP is thus -- the entire EP applied to business application; CEP is subset of EP. More - later.

Welcome to the AptSoft team to IBM

Burlington, Mass. - I have never been there - but I have learned from its official website that they hold town meetings which is nice. Besides town meetings, it is also the home of the AptSoft company. Today it was announced that AptSoft has gained a new home and becomes part of the IBM Websphere organization. Getting from a start-up to a big company is a big step (I have been in both types of organizations and know the difference...), and sometimes a caltural shock... it is also a big step for those who believed that IBM should be a player in the CEP space,
making the first announcement about complex event processing product with this acquisition.

While I still need more education about the AptSoft product, it seems on first impression (what I have seen in the Gartner EPS conference in their booth) that they have a thinking competible with what I posted about the fact that CEP patterns should be defined, in many cases, by a business user and not by a developer, and their thinking is geared towards this direction -- this is a good value that they bring to the table.
Meanwhile -- to Steve Lyons, David Martin and the rest of the AptSoft team - warm welcome to IBM, and happy blue-washing... see you around in the corridors of the blue giant.

On The WHEN question - in event processing

In one of the previous postings I have talked about various notions of real-time, from the example of the human event processing that I have given yesterday, it seems that there is importance in some cases to react in "hard real-time", e.g. if we'll assume that instead of human drivers the cars will be driven by a computerized system, then this system will have a lot of hard real-time constraints, especially when related to safety, based on events that received from sensors about the environment. An inheritance from active databases is the distinction between "immidate action" and "deferred action", however these are inaccurate terms-

Immediate typically means:

• As soon as possible based on best effort,

However sometimes it means :

• Hard or soft real time constraints on the latency.

Deferred may mean:

• As soon as possible after the end of some context (e.g. at the end of a time window)

But it may also means:

• Exactly in 5:00PM, Anytime between 7:00 - 9:00 PM etc..

Indeed - not all events are processed immediately, the best example is an absent pattern based on time-out, in which the fact that the event did not happen is processed at the end of the time-out .

In some cases we also want to apply event patterns to historical event - which is known as "retrospective processing"; this will be discussed in another opportunity.

Unplanned events - again

This (more or less) how my MPV car looked like at the beginning of this day, unfortuantely, it does not look like this now -- while driving in a highway, there was some traffic congestion, and the traffic slowed down, however, the driver behind me has not detected this event and proceeded to drive full speed - as a result he crashed his small car into my car, totally destroyed his car, but made also substantial damage to the back of my car. So - I had an absent event, did not make the meeting I was driving to, had to wait for police, and then almost two hours for a replacement car from the leasing company -- so wasted much of the day. Luckily for me, I have detected that with the momentum of the crash, I am approaching very quickly a track before me -- and succeeded to stop the car before getting into the track -- otherwise, I may not be sitting at home and typing now -- so people also need to process events in real-time and not in batch...

On ECA and E*C*A*

Back on the ridge - Haifa is a collection of ridges on the Carmel mountain, my residence neigborhood Ramat Begin is seen here from bird eye's view. Anyway - still have some backlog from discussions last week in the CITT conference. One notion is about ECA (Event-Condition-Action) and its role in Event Processing. A few months ago in the VLDB conference I've met

Umesh Dayal, HP Fellow and a person with inspiring work, and we had a short discussion whether the area of "active databases" we have both involved in the past has failed, Umesh was in the opinion that while it has not become mainstrem in database products, as we hoped, but the notion of ECA (that has been coined by Umesh and his colleagues in the HiPAC project) has survived and had a substantial impact in various technologies (not necessarily in the database area). ECA stands for Event - Condition - Action. ECA still has role in event processing, however, this role is more similar to the role of rules in Event Processing - and mainly used in the edge of the EPN network, where the event is being consumed, ECA rules can control the action that is being trigerred at the consumer side. Interestingly enough we can charachterize the "event processing network" itself also using the same three letters - with stars - E*C*A* , where the interpretation is:

• E* - zero or more events that a single agent see (AKA "event cloud")
• C* - zero or more contexts that the agent is associated with
• A* - zero or more agents are activated.

The EPN routes events (both input event from a producer, and derived events from the EPN agents) according to context to activate agents.

On events in flight management

I have arrived home today from my Europe business trip - 11 hours later than planned. The crash in Heathrow airport had created a mess in the airport, only one runway operated, and my flight was delayed -
and I missed the connection in Zurich, and had to take the next flight to Israel - 11 hours later.
In the last year it seems to me that more events related to flights happened relative to previous years. One of the issues in event processing is - how should we react to occurance of event. In some cases the detection of the business situation is quite complicated, and we have been discussion "complex event processing" and such, however, in other cases, the detection is very easy, the complexity is in the response. Earlier this week, when I have arrived to Heathrow airport the following event occured:

The flight arrived 20 minutess eariler;

• The slot near the gate was still occupied.

The reaction has been - send the airplane to park outside the terminal and transfer the passengers to the terminal with buse. Soundes reasonable --- yes.

However -- it seems that nobody verified that there are buses available. The end result - we sat in the airplane 45 minutes, until the buses arrived. The captain told us several times that he is pushing them to send buses, but they are not responsive....

Back to last night --- I must say that I have been in this situation before, and that Swiss airline has handled it well - took the responsibility, gave us vouchers for hotels, breaksfat, and transportation from and to the airport. I have been in a somewhat similar situation last summer, when I had to fly Delta, and missed the connection in Atlanta, Delta's agents were very unpleasent, notified us that the vouchers for hotels we got at the source of the flights are all void, and that we are on our own. After 15 attempts I found a place in Motel Six, and got there by cab. Since I already had complains about Delta before - I have notified my travel agent to scratch Delta from the lit

The Swiss attitude in much better in ny eyes - but it seems that now I'll add another rule -- try to avoid connections at the last segment of the trip (going home !). I could re-arrnage my trip to do so. This is an intelligent event processing - mitigating predicted event.

Returning to normal writing of the Blog on more techncial issues - soon.

More thoughts on Rules in the context of Event Processing

I spent today (and tomorrow) in the IBM Hursley Lab - my second home in the last couple of years, this is a picture of the "Hursley House" (well - from the back side) - a countryside English manor that serves today as place for meetings and conferences, and the office of the Lab Director - besides this building there is a complex of connected building with multiple systems for room numbering that can provide in-door navigation challenges. I'll write today about some ideas that came out from discussions in the CITT meeting earlier this week about the role of rule technology. I still hold my opinion that although it is possible to take a technology that has been developed for one purpose and "hack" it to use it to other purpose, it may not be the most natural/effective/efficient way to do. This is true for SQL as well as rules when we are talking about pattern detection in complex event processing (I am working now on tutorial on the issue of patterns). However, this does not say that rule technology does not have a place in event processing in general. Here are some places it can be used:

(1). Decision-based routing in event processing networks.

(2). Transformation of events.

(3). Validation of events.

(4). Orchestration rules.

(5). Intelligent Event Processing.

Note that different type of rules are being used for the different cases -

for routing and transformation - it is typically - if-then rules/decision trees/decision tables.

for validation - constraint oriented rules.

for orchestration - ECA rules (note that orchestration rules are in the domain of the consumer that receives an event from the event processing network and has to decide what to do with it).

for intelligent event processing - all type of rules - deductive, inductive, abductive, rules with uncertainty - can play in different cases.

More about ECA rules and event processing - soon.