Web services triggered by SAP ESP

More from the event processing vendors Blogs.  This time from SAP.  Its ESP product.   SAP event processing Blog notifies on a new feature in the product that enables a derived event to trigger WSDL that prompts the user for requesting a predefined web service.  In the EPN terminology, this WSDL is an event consumer.  There are also other products that cross the borders and provide actions as part of the event processing product.  As integration with adjacent systems is a major issue, there are already several solutions which extends event processing to the consumer side, with built-in actions. It is also useful to extend to the producer side -- the instrumentation process.  I'll write about the producer side in another post.    

Another type of proactive systems

Today I had a meeting with PhD student and her adviser to help them do sanity checks for a research idea related to event processing.    One of the ideas coming from them is actually looking at another type of proactive systems relative to what we have been looking at.   The difference stems from the fact that event producer can be of two types:  observer and creator.   An observer, e.g. sensor, observes that an event has happened and reports it, but it does not take any part in the event creation.   A creator is a producer that creates the event, and can decide whether an event is created, or in some cases can retract events.  Such a creator can be an instrumented program, BPM,  transaction system etc...

The proactive systems we have been looking at assumed that the producer is observer, thus we cannot control the creation of events but we can try to predict it, and eliminate it, or mitigate the damage it might inflict.   

Contrary, when the event producer is a creator, we can control the event.   There might be a few cases here.

One case can be that we again predict that event is going to happen since there is some causality relations with events that have already been detected, and within a certain context we don't want this event to happen,  we can then tell the producer -- if this event is being produced (again, within certain context, e.g. time window) -- don't produce the event.    Another case can be that the event is being created by a transaction system,  this event, within some context, and maybe in conjunction with other events, derives a situation that we want to eliminate.  The fact that the event is part of transaction that has not committed, gives the possibility to retract the event and eliminate it from being produced to the outside world when the transaction commits.  

The pure view of event processing puts producers and consumers outside the boundaries of the event processing system,  however, in reality there are cases where either the producers or the consumers (maybe even both) are controlled by the same logic, and thus detection of situation may impact the producers and consumers.   I think it gives rise to interesting applications.  I'll get back to this topic later.

More on the ecosystem of event processing systems

The one week school break for children ends tomorrow, and today I went with my two younger daughters to see Avatar, a very ambitious movie with a lot of advanced 3D graphics. The downside is that the film spans over 3 hours without a break -- could cut 1 hour easily, but nevertheless the graphics is very impressive, the plot is kind of paraphrase on other movies.

In my previous posting I've written about event processing functions, one of the frequently asked questions is whether event processing has a value by its own right, or as part of a larger ecosystem. Let's look at another question: DBMS software deal with update, retrieve, store, organize, backup and restore data, it also supports concurrency control, transaction management and other stuff. DBMS itself does not have value, the value is in the use of data.

In a similar way, event processing software deals with transferring, filtering, transforming, pattern matching, and situation discovering, it also provides execution control and support of some non functional properties, but the aim is to receive event process them and derive more events. The value is not in derivation of events, but in the way it is used.

In order to complete the cycle we need two other types of software: event producers that produce the raw events, and event consumers that consume the derived events and execute the actions triggered by these events -- the consumers are those who are driving the value.

The producer can be any type of software or sensors. One example of event producer I've written about in the past is the "EDA extension of CICS" that I have written about before. It is an example in which a software is instrumented to produce events. We are seeing more software of this type in the sensor area, and other areas as well.

Consumers are the part of ecosystem that utilize the events flowing from the event processing systems. I've posted before about the consumer chapter in EPIA, There are many ways to consume events, they can also be connected with other types of enterprise software: Events can drive decisions, and can serve as input to business rules; events can drive KPI (Key Performance Indicators) metrics and can be input to BAM systems, it can have various actions related to BPM systems, events can drive real-time analytics and be input to BI systems, it can post on Twitter, and update Ambient Orbs (see the posting about the EPIA chapter), or if it is part of a "smart house" it can turn off lights or control the temperature using some actuators.

Like DBMS that requires somebody to feed the data, and somebody else to use it, event processing requires its ecosystem, we'll see more of the ecosystem software both in the producer side (like the CICS example) or in the consumer side (like BAM software). More on event processing ecosystem later.