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.