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.