More on event processing and mobile devices

More than a year ago I have first written about event processing and mobile devices, and illustrated this picture, showing the possible roles of mobile devices as producers, consumers, front-end and dashboard carrier.   Now I am concentrating on the "EPA on mobile", which means that mobile devise (phone, tablet, smart sensor etc...) can host the actual execution engine of event processing.  One of the questions raised is why is it needed, typically people think on mobile devices as end points,  front ends, and collection points, while the actual processing is executed on a server (cloud, mobile back-end server etc...).  

There might be multiple reasons to run event processing on mobile:

First -- mobile devise may be off-line (e.g. when I am travelling abroad, wherever there is no WiFi connection, my mobile phone is in off-line, since mobile data connection is very expensive out of the country).  

Second -- there are various sensors attached to a mobile device,  whether these are the internal sensors of the devise itself, or a sensor network wired locally to a mobile devise (e.g. tablet).   In many cases events are emitted frequently, and raw events are relevant only at the local level.  Sending them to the back-end requires both communication cost, and has high toll on power consumption, which is still the weak spot of mobile devices.   

Third --- there are also privacy considerations,  such as processing events that the owner does not want to share with the rest of the universe.

Recently I have learned about some implementations done now in this area, they are hybrid implementations, certain part of the overall logic might run on a mobile device, while part might run in the back-end.

running open source event processing on mobile devices.   I guess that this will see much more of it, as the world moves to mobility, and to the Internet of Everything.    

New market research on the event processing market by Markets&Markets

It seems that there is a new comprehensive market research on the event processing market in the years 2013-2018 by Markets and Markets.  I don't have the market research itself (it is quite expensive), but the site gives some details, according to the report,  Markets&Markets forecast that  the "CEP  market"  is expected to grow from $764.5 million in 2013 to $3,322.0 million in 2018.  I wonder what this figures represent, it seems that this is beyond the accumulative sales of event processing platforms. 

They also classify the market according to the following verticals: 

BFSI: algorithmic trading, electronic transaction monitoring, dynamic pretrade analytics, data enrichment, fraud detection, governance, risk and compliance (GRC); 

Transportation and Logistics: asset management and predictive scheduling and toll system management; healthcare: self-service proactive monitoring and alerting and governance, risk and compliance (GRC); 

Telecommunication: mobile billboards, revenue assurance, network infrastructure monitoring and predictive CDR assessment; 

Retail: inventory optimization, shoplifting detection and real-time marketing and customer engagement; 

Energy and utilities: oil and gas operation management and nuclear crisis and smart grid energy management; 

Manufacturing: shop floor automation and operational failure detection, infrastructure management and supply chain optimization; 

Government, defense and aerospace: Intelligence and Security, emergency response services and geo-fencing and geospatial analysis; 

Others: includes education and research

Hope to get more insight towards this research. 

Event processing at the core of automated commerce systems

This illustration is taken from Chris Taylor's Blog, where he posted a piece entitled:  "There's a technology tsunami hitting the world of commerce".  Chris makes distinction between the hype technologies:  cloud, analytics, big data, and mobile, and claims that all of them have role in the story of commerce, however the core technologies doing the heavy lifting are: integration, managed file transfer, in-memory data, log file management, event processing and business process.

As for event processing, Chris believes it is the core, and issues the nervous system of the commerce which enables to automate it, as commerce is event driven by nature - buy and sell are events, and so are payments, fairness rules, credit decisions, fraud detection, and management of the commerce system itself. 

Note that illustration follows the 4D: detect (channel), derive (pattern detection), decide (decision), do (actions).  The "decide" part is not necessarily "IF---THEN" rules, but can also be optimization or another event driven pattern. 

Event processing with Storm-Cassandra from health market science

I came across a recent Slideshare presentation entitled "Complex Event Processing W/Cassandra". prepared by Brian O'neill and Taylor Goetz, from Healthcare Market Science.  It describes a project integrating Cassandra and Storm.   This presentation analyzes previous failures using Hadoop and C* with  aspectj.

Then it explains the architecture of the solution using Storm for the event processing part.   

Interesting presentation.  It would have been even more interesting if the presentation talked more about the actual application  (there is one slide explaining in very general terms what their products are).  

It seems that a lot is going on in the open source space.  

DEBS 2013 grand challenge was announced

DEBS 2013 grand challenge was published today.  This is one of the new items we introduced in DEBS 2011 which continues to the next generations. The idea is to publish an event processing application, view various implementation and evaluate based on announced criteria.

This time the application is around football (soccer in American English), where the input events come from sensors attached to players' shoes and hands and to the ball, and some referee events.   The events are spatiotemporal by nature. 

The goal is to calculate various statistics about players performance, ball's location etc.

Criteria -- application's performance (latency,  throughput),  while keeping correctness. 

I hope that various teams will answer this challenge and will provide interesting solutions. 

From Australia - 2013: The Year of the Internet of Things

The complexevents site by David Luckham has undergone a face-lifting and has a nice new format.

In its current feature article it links to an article from CSIRO, Australia,  entitled: "2013: The Year of the Internet of Things".   Arkady Zaslavsky from CSIRO, who deals for years in context aware computing points out several successful IoT projects in Australia -- one of them is in agriculture, using sensors to check the best conditions for certain plants, other examples are public transportation track in big cities and monitoring sporting performance.   The illustration above taken from this article compares 2010 and (predicted) 2015 quantities of  Internet data in petabytes (petabyte = 1 million gigabytes) by industries, where in 2010 most data was created by humans, and the shift is that most data on the Internet will be created by sensors.      

On IBM scientific accomplishment

This week, the annual accomplishment process of the IBM Research Division was concluded. This is a process that recognizes major impact activities in various categories: scientific, contribution to IBM products, contribution to IBM services, contribution to standards and some more.  

Within this year's process, our work on the event processing conceptual model has been recognized as a scientific accomplishments.  The criteria are: number of citations (according to Google Scholar) and support letter from senior members of the scientific community in this specific area. 

It is interesting to note that the major publication referred was the book I have written together with Peter Niblett, "Event Processing in Action".

 The interesting fact is that the book was not written as a research oriented book, but was geared towards the professional market,  yet it accumulated so far 153 citations, with the number steadily growing (when the process started the number was around 130).  

Drilling down to the citations list it is also interesting to observe that while some of the citing papers belong to the event processing community, many others come from different domains and implemented systems in the areas of power management in mobile devices from Finland, rotor-craft control from Brazil, as well as others that indicate that the material in the book had some practical impact in additional to the impact on the scientific community, which is also important, as science is being built in layers.

I have been out of the research work for about 10 years, where I kept research activity in the back sit, mainly through supervising  PhD and MSc students at the Technion.  The major project I was involved in the years 1998-2005 (AMIT), has a single major publication that is actually the summary of the PhD dissertation of Asaf Adi  (this paper also accumulated nice number of citations). 

The question whether citation number is a good metric - is another discussion, for me the actual impact (those using the work in practice) is also an encourging indication that the work is not done in vain -- more later

Event processing and mobile devices

The current big buzzwords in the IT world are: analytics,big data, cloud and mobile.   These are believed to be the most influential trends on the IT directions.  I have already written about analytics and big data in some previous post, today I'll write on the mobile universe from the point of view of event processing.  

Putting the mobile devise symbol on a drawing of an event driven architecture, we can view multiple roles:

1. Mobile device can be a producer of events -- this may be both implicit events, using the mobile devise as a sensor and tracking the location of the mobile device over time  or explicit events, where a human use mobile devise to report events (such as:  traffic jams, completion of tasks, start of the work day)
2. Mobile device can also serve as consumer of events -- subscription to either raw or derived events can be manifested within notification in form of Email, SMS, or mobile application.   It seems that most uses of mobile devises are the consumer and producer roles.    There are also some more sophisticated possible uses, discussed next.
3. One can build event processing agent logic using mobile devise, but it is more likely that the use in this case will be to use predefined templates in order to define specific instances of EPA. For example, if the application is subscription to events in my bank account, I might get a template giving me an opportunity to subscribe when my accounts reached a balance of more than X or less than Y, I received a deposit of more than Z, or that the total withdrawals for a single days are more than W.   Using the mobile device I can chose any of them and give value to the X, Y, Z, W variables.
4. A dashboard showing the real-time state considering the streaming events can be also displayed as a mobile application
5. Last but not least -- An EPA can reside on the mobile device itself,  collection data and doing some filtering or aggregation.

In a follow-up post I'll try to switch direction and look at event processing from the mobile point of view.

More - later.  

On robots for the elderly

I have always been fascinated by the potential of combination of event processing and robotics, and have written about it before, as well as followed some work in this area.   Recently I have read some material about EU project called ROBOT-ERA,  which is aimed at providing robot's support for the elderly.  Their plan is to create three type of robots for the elderly, which they call - domestic (for the room/apartment), condominium (for the bigger house/ home for the aged), and outdoor, with communication between the three types.  This system is obviously event-driven, but as many of the applications of the world it does not use COTS of event processing, but home-built solutions.    I think that while the event processing community concentrated in the COTS, it should also pay attention to help those who role their own --- I'll write more about it.

I also think that there is a huge  potential of smart systems and robots to help the elderly which sometimes the world looks to them very challenging,   Besides the EU projects there are other activities in this area in Japan, and Australia (watch this video). I assume there are others as well.  When such technology will become pervasive and affordable, it will have a significant impact on quality of life of elderly people. 

Event processing for oil and gas -- Microsoft Streaminsight presentation

A video describing some event processing applications (mainly aggregations) for the oil and gas industry with Microsoft Streaminsight has been posted.   It explains some of the principles of event driven architecture, then the "standing queries" Microsoft Streaminsight architecture and some use cases.    Another evidence that event processing can  be used for all industries.     Enjoy!

Announcing the EPTS awards

EPTS has announced on a competition to grant awards of two types:

The innovative application award, in cooperation with OMG Event Processing Community of Practice, will be awarded to an application that have used event processing in an innovative way.

The innovative principles award, will be awarded to a research contribution that had a significant impact on the state-of-the-art in event processing.

The competition is open to everybody. Deadline for nomination submissions is September 30, and the award will be given in November and will publicized in the media.

Full details about the award program can be found on the EPTS external website.

Next week in DEBS we'll hand out a flyer with the announcement and start communicating the award program

On students' projects in the event processing course

The semester has come to its end, and the event processing course in the Technion had the last meeting today; the students still has to finish the projects, and they have some time to do it, but today they have presented a preview of the project, here is a brief summary. They were given a choice to do research oriented project or implementation oriented project, those who chose implementation oriented project got some directions on the size (quantities of consumers, producers, patterns, aggregations, filters etc...), and could chose both the application they want to work on (and they'll have to test it with simulated data) and the tool they use in order to implement.

There are five teams:

• Team no. 1 -- chose to work on a research problem of interval-oriented event processing and defined a collection of operators and patterns required to support interval oriented.

The rest of the teams chose implementation projects:

• Team no. 2 -- chose to work on "smart traffic control", simulating traffic lights, traffic jams, accidents and events like concerts etc... They decided to hard-code their application in Java, since they know Java well, and it is more fun doing it this way :-).
• Team no. 3 - chose to work on "smart home" and mainly concentrate on the security aspect of home automation, they are also Java fans, but chose to use Esper in conjunction with Java.
• Team no. 4 -- chose to work on control of people who are abusing chat rooms in various ways (like using dirty words), and managing complains. They have chose to work in Streambase, and done all implementation (so far) using the graphical tool of Streambase. We again see that some people like graphical programming and some people prefer old-style imperative programming.
• Team no. 5 -- chose to work on tracking bus driver performance, both for safety issues (speed), and accuracy (skipping bus stations). They have organized late, so have not started the implementation phase yet, but they said that they wish to do the project using Apama.

The projects are due in August, and then I'll write more, if I'll have any interesting insights.

Revisiting race condition with FFD example

In the past I have written about race conditions and this triggered some responses. We recently realized that in the example we created for the EPIA book (the Fast Flower Delivery and has got already around ten different implementations, six of them can be viewed on the book's webpage, some more will be added) there is an case that if will not be handled carefully may yield wrong results due to race conditions. Here is the case:

There is an aggregate EPA per driver and day that collects assignment events for a driver and in the end of the day creates a derived event which counts the number of assignment per driver, there is a second EPA per day that collects all the drivers count at that day and calculates mean and standard deviation for the number of assignments per active drivers in that day; there is a third EPA, again per driver and day, which gets the derived events from the first two EPAs and calculate for each driver its deviation from the mean, in standard deviation units. These three EPAs are all aggregation type EPA which has some order among them, until now -- no problem. Now, the issue is that all these calculations occur at the end of the day, and have causal dependencies. If we are not careful, the first EPA calculates the count per driver at the end of the day, but until it finishes the calculation the time is say, 12:01, so the result is classified to the next day, but it is required to calculate the statistics for this day, and then if it gets into the statistics of the next day, then we get some inconsistency in the system. Obviously a naive implementation will get wrong results here. There are various ways to handle it and ensure correctness, however the main issue is whether the developer needs to be aware of it while designing the application, or the compiler that takes the definition of these EPAs and creates the actual implementation should be the one which will do the job. My opinion is that if the developer will have to take care of such things in hard coding, the life will be quite difficult, as this is only one case of race condition, and it is better that it will be transparent to the developer. This will eat the cake and have it too --- both using high level tool that makes the programming easier and lower the total cost of ownership, and fine tune the semantics in a way that require typically dedicated, and even complicated programming. More about other aspects of semantic fine tuning - later.

On new event processing course and some ways to explain what event processing is

This is the Computer Science building at the Technion; yesterday I have started to teach an event processing course there (in the previous semester I have taught in the Information Systems Engineering program, which is my academic home for many years), the course is given as an "advanced topics in computer science" course, and the students that have shown up were mostly graduate students from CS as well of EE (there are software people in EE also). Unlike the previous semester in which the students projects evolved around validating the solutions that different vendors put for the EPIA book's website, this time I would like to concentrate in the project level about the view of those building event processing platform (this is a slightly different view). The first class is always an introduction, since the students don't have a clue about what event processing is, thus I am starting with some examples about what is it used for.

Always there is somebody who asks the question -- what is new, haven't such applications done in the past also? My answer is, consistent with the answer I am giving to this question for years, event processing does not bring any new functionality to the table, it takes functions that people have done in one or other way using regular programming and make it both -- easier to use since it introduces high level abstractions (analog to the abstraction of database query against the way we did database programming in the distant past, and other abstractions), and providing platforms that can execute these abstractions using optimizations specific to these abstractions.

I am also talking about the event-driven decoupling programming vs. the more traditional request/response.

One thing that I am making sure that the students will understand is that (like databases) event processing can be used for many different purposes and is not bound to a single type of application, or single industry. I am doing it by starting with 10 examples that are quite distinct (taken from chapter 1 of the EPIA book), and concluding by trying to generalize some type of applications, using the picture below (taken from an IBM academy study a few years ago that examined what event processing applications are), this is just one of possible classifications.

This is an important thing, since there are some misconceptions around.

As I have written in a previous posting, event processing does not have a single purpose.

Creating event aggregations to check key performance indicators is certainly an application, but not the only one; likewise "detecting threats and opportunities in the event cloud" is a phrase going around (I heard it first from Roy Schulte, but I don't know if he is the copyrighter), and indeed, this is an application of event processing, but many event processing application detect neither threats or opportunities, but serve for diagnosis, or operational decisions. The message - event processing is a discipline with set of concepts, and various ways to implement these concepts that serve many purposes that need event-based computing. I Shall write more about the course as it will further develop.

On common misconceptions about event processing - the single application misconception

We start the introduction chapter for the EPIA book, by stating: Some people say that event processing is the next big thing; some people say that event processing is old hat and there is nothing really new in it. Both groups may be right to a certain extent. As with any field that is relatively new there is some fog around it: some of the fog stems from misconceptions, some from confusing messages by vendors and analysts, and some arises because of a lack of standards, a lack of agreement on terms, and a lack of understanding about some of the basic issues.

In the book we don't really talk about the misconceptions, but I think it is a good topic towards the end of 2009 to dedicate some postings towards the major misconceptions.

I'll start with misconception number 1: Event processing is a single-industry (some even say single-application) technology, and event processing software cannot generalize beyond this single industry/application.

The industry is, of course, capital markets, and the application is algorithmic trading

The diagram below is taken from the ebizQ customers survey (two years ago) about what are the business problems that they expect to solve with event processing, and the result is 9% indicated algorithmic trading.

This misconception is originated from the fact that the capital market industry has indeed been the early adopter of event processing software, and served as a proof of concept for the rest of the industries, there are indeed some vendors that focus mainly around this type of application, however, this does not show the entire picture. From the IBM experience I know of customers in various industries, most are not in the capital market area. Getting to the material collected by the EPTS use case work group (the material is on the EPTS members internal site, available to EPTS members) I find quite a lot of examples of systems working in production or being developed from variety of domains, here are some samples:

• Border security radiation detection (Eventzero)
• Mobile asset geofence (Rulecore)
• Logistic and scheduling application (Starview)
• Unauthorized use of heavy machinery (Rulecore)
• Hospital patient and asset tracking (IBM)
• Activity monitoring for taxing and fraud detection (IBM)
• Intelligent CRM in banking (TIBCO)
• EDA and asynchronous BPM in retail (TIBCO)
• Situation awareness in energy utilities (TIBCO)
• Situation awareness in airlines (TIBCO)
• Reduce cost in injection therapy (IBM)
• Next generation navigation (CITT)
• Real-time management of hazardous materials (Oracle)
• Finding anomalies in point of sales in retail stores (CA)
• Elderly behavior monitoring (U. of Munich)

These are only samples, I am familiar with variety of examples in various industries: healthcare, utilities, chemical and petroleum, insurance, security, transportation and others. In the last event processing symposium in Trento, we had one keynote address on event processing in robotics, and there are other areas as well such as smart house to monitor energy consumption in the house. While we are now in the first generation, and the utilization of event processing will increase in time, the coverage in terms of industries and applications is growing has gone far beyond algorithmic trading.

More misconceptions in subsequent postings.

On the Event-Driven Architecture book

Last in the series of 2009 event related books is the book entitled: "Event-driven architecture - How SOA enables the Real-Time Enterprise". This book was published early this year, and I actually purchased it while visiting the USA earlier this year, and while doing the other book reviews it is a good time to write about this book as well.

The book, unlike the others, does not deal with event processing, it deals with EDA as a central concept, starting with a "working definition": event-driven architecture is one that has the ability to detect events and react intelligently on them. I have some trouble to digest this definition, since in my mind, architectures don't possess abilities. Part I of the book talks about "The Theory of EDA", in which it starts with a second "working systemic definition" saying that EDA is the complete array of architectural elements, including design, planning, technology, organization, and so on, which enables the ability to disseminate event immediately to all interest parties, human or automated. So now this is a definition of architecture for event/message routing, but I already noted that this is not about event processing. Next it goes in depth about the relationships between EDA and SOA, explaining on its way what SOA is. The metaphor used throughout is a nervous system, and this is talking about enterprise nervous systems, the discussion about SOA and related concepts spans over four chapters, ending with some hints of how to calculate ROI of selecting architecture style, but the ROI discussion remains in title levels. The second part of the book goes from theory to practice, in this case they are saying that the products implementing EDA are called ESB (Enterprise Service Bus), and (rightfully) claiming that the main gap in using EDA is that people are not used to think in EDA. However, while they have a chapter called "thinking EDA", its insights of how to "think EDA" stay in a very high level area. Going from the thinking to the examples, the book discusses in big details three examples: Airline flight control, Anti-money laundering, and event-driven productivity infrastructure (under this name there is a description of a framework to connect workflows, E-mail, phone, document repositories, blogs, wikis, social networks and some other stuff).

The book ends after these four example chapters (which actually take more than 50% of the pages), without any conclusion chapter.

It seems that the examples are the essence of the book, and the previous chapters are introduction, the examples also remain in the transport level, and while in one of the example "rule engines" are mentioned as part of the architecture, the book says very little about them.

Looking at the reviews in Amazon, it has polar opinions going from 1 star to 5 starts, I guess that I am somewhere in the middle, for somebody who does not have a clue about what EDA is it provides simple non-technical explanation, and such people found it useful; however, I agree with the 1 star reviewer that it does not really making a convincing story on the sub-title promise - "How SOA enables the real-time enterprise".

This completes my book reviews. We'll see some more books in this area coming in 2010.

On Adaptive services

Chameleon is an adaptive animal, it can adapt it color to the environment. In the next few weeks my main task will be to complete a proposal for EU project that deals with adaptive services. I have (mistakenly?) agreed to coordinate a consortium that creates a proposal. We had a meeting in Trento following the EPTS event processing symposium. EU project has a benefit of getting funding for research that can explore more advanced topics then can be funded by commercial corporates, and also provide an opportunity to collaborate with some very good people both in industry and academia. The down side is that there should be much investment in the proposal, since it became extremely competitive.

The proposal is about the idea of adaptive services -- which means in plain words that the behavior of the system should be adapted to (unexpected?) events. This adaptation may require human interaction (e.g. modifying medical treatment protocols), or self-adaptation (e.g. change of emergency handling protocol on the fly). The research challenges here are in area of event processing -- having more advanced features that are beyond the state-of-the-art; adaptation, modeling and methodology of how to build such systems. More about this topic - later.

On social networks and event processing

Today I noticed that the number of my LinkedIn contacts is now a round number 0f 600, unfortunately two of these 600, Klaus Ditrtich and Shlomit Zak have passed away, but their LinkedIn records are still alive, I hope that the rest of the 598 are alive and well. I was introduced to LinkedIn 3 or 4 years ago, when I received a LinkedIn invitation from Mark Palmer, who was my first contact, and accumulated the rest of the links over the years. Part of them invited me, and part of them were invited by me, I have there classmates from high school, colleagues from all places I worked in, students I taught or supervised, some friends, and of course, the members of the event processing community. LinkedIn was my first social network, currently I even don't know exactly how many social networks I am member of, but LinkedIn is the only one that I am active in. So I'll take this opportunity to say a few things about how event processing can become part of social network platforms.

There is a lot of buzz recently about Twitter events, which is also one of the Web 2.0 family, but I'll take the LinkedIn example now, since it has some structure, which creates various event types. While there is applications that attempt to use Twitter events to get information about the stock market, in social networks the events are about individuals; some of the interesting event patterns that may be obtained about individuals:

• A person got more than 3 recommendation during the last week -- probably looking for a job now, this is an information that can be of interest for various people, such as head hunters, or enterprises seeking for employees.
• A certain amount of contacts joined a certain group -- may be an indication about a group of interest
• LinkedIn has microblogging of 14o characters like Twitter -- various things can be obtained from this microblogging.
• Postings that people make on groups may indicate something about a person.
• Level of activity in groups may also indicate something about that group.

Many other possibilities can be thought on; I foresee that event processing will be embedded in social network platforms, and maybe will be the basis of abilities to offer paid services. Some social networks send me an Email every time that somebody looks at my profile, and offer me to know the identity of this person, if I'll become a paying member, I have never tempted to do it, however, maybe the use of event processing will provide such services that will be worth paying for, but I guess that most people expect to get these kind of services for free... Can be a good exercise for students, to build such a service. That's all for today, almost midnight...

On the vision for smarter cities

The IBM Institute of Business Value has recently published its vision of smarter cities, which is part of the "Smarter Planet" vision on which I have written before. As noted before, the smarter planet vision is based on the fact that the world will be instrumented, interconnected and intelligent. Event processing is the backbone of smarter cities. As smarter cities is been labeled "system of systems", the integration and communication between the different systems is done using events, and the event processing filters, transforms and routes the event among systems. It also crates derived events from one or more systems that may be used by other systems. Event processing technologies have two roles: In the macro level, it is a glue between the systems and is part of the intelligent part of each individual system. I'll write more about some individual systems inside the system of systems. I am trying to get a smarter cities keynote talk in the 5th EPTS event processing symposium --- stay tuned, details about the symposium (Trento, September 21-23) are coming soon.

Live from DEBS 2009 - Keynote Address by John Bates

In my role as the industrial track chair of DEBS 2009, I have been asked to invite an industrial keynote speaker, and this year I chose John Bates, the General Manager of the Apama Division of Progress Software, and a person that made a transition from being a faculty member in Cambridge University, leading one of the first start-ups in this area, and now managing a division in a larger company. This was certainly a good choice; John outlined the assumptions he had as a researcher, and the confrontation between these assumptions and the reality that forced them to find a low hanging fruit, until the bigger market will be mature enough for the ideas for event processing, and they found trading in capital marketing as this low hanging fruit, and the early adopters of such technologies. However, the maturity in thinking about this area now takes it to more areas. As for John's prediction for what will happen in the event processing market in the next five years, he mentioned the following points:

• Event Processing will be used for tracking everything -- car, plane, bag, package, ship

• EDA -- will achieve wider adoption -- federating services in the enterprise, providing agile enterprise nervous system; The next wave of SOA.

• Event processing everywhere -- EP in the cloud.

• Event Processing will be part of bigger event-driven business process management market - BPM, rules, event processing are going to merge.

• Event processing will be embedded in many vertical applications.

More about further sessions in DEBS 2009 - later