On the world wide event processing network

In a recent post on the complexevents site, David Luckham and Roy Schulte write about "complex event processing and the future of business decisions".   There are some examples, and some analysis of the current market, but I would like to write about a single sentence in this article: " In the early days of the Internet, some communication experts remarked that there was theoretically only one network in the world, although some segments (subnets) hadn’t be connected into the whole yet. A similar thing can now be said about EPNs: there is theoretically only one EPN in the world, although some stove-pipes are not yet tied in – and some never will be".    

This draws similarity between the WWW and the world of events.   In the WWW we view the sites as the nodes in the graphs and links as edges.  Typically we draw EPN as event processing agents in the nodes, and event streams as edges, but maybe to draw the analogy with the WWW, we need to switch the role, make events as the nodes, and agents as links that create other events, we also can add other types of causality relations among events as edges in the graph.    The idea that all events (raw or derived) in the universe are conceptually linked within a single network has been mentioned in David Luckham's idea on "holistic event processing" .   This can be thought as active addition to the WWW,  and will make the world situation aware.       This will require standardization in several levels - both the semantic and interoperability aspects.    

More on the layered approach of the event-driven world

I have been asked by several people to write in more detail about what I meant  by the layered approach, so I thought it should be better illustrated in an architecture diagram (converting it to picture did not result in high quality, somehow).  The rationale behind it that event processing became pervasive in use, with both event processing products, and "build your own solution".    In the same way that application servers based on standards like J2EE contributed to building of certain type of web-based enterprise applications,  an application server for event-based applications is required to provide services from various types: from context service, adapters to sensor and mobile platforms, dashboard, management services, meta-data service and more.   The second layer is the agent layer which provide both directory of agents and tools to build your own agent.  The application is the third layer.   This architecture can provide independence, and ability to get best of breed in both services and functionality components from different sources, and combinations of "build" and "buy".

Standards are of course the key to make it happen.  

Evented API

I have written in the beginning of this year about the fact that standard APIs is now an emerging trend,  and about the benefit of having standard API for event processing.  No standard yet but I came across "evented API specification" developed by Kynetx.   While the terminology is not entirely consistent with the terminology I am using, it is interesting to review such works, and advance into standard APIs in this area. 

On event processing related standards

One of the items in the EPTS charter talked about incubating standards related to event processing.   When EPTS was established, three years ago, the general opinion was that it was still premature to deal with standards.
Recently, there have been two developments related to standards:

1. The event processing manifesto work includes a chapter that surveyed related standards and recommended some action items.   It has been presented within the EPTS virtual symposium last month by Paul Vincent.
2. OMG has renewed its call to express interest in work towards a standard on Event meta-modeling and profile  (in essence:  event structure).

Today, a vote request was sent to all EPTS members to answer two questions:  whether EPTS should establish a work-group to view standards in a strategic way, and whether EPTS should support/play a role in the OMG standard.   


Standards have a potential to give a big push to the area (this has happened in other areas);  the grand challenge presented in the event processing manifesto, the "event fabric" in an internet scale requires the existence of standards as a prerequisite,  however there need to be a shorter term business motivation to make it fly.

Decisions in smarter systems

Arlington., Virginia,  Hayatt Hotel

I am here for the OMG technical meeting.      I have participated in (part of) the decision modeling day organized by Paul Vincent and Christian De Sainte Marie.  Their ultimate goal is to get to a standard on decision modeling, and they have issued proposal for RFP on that issue.  A good survey of that day can be found in James Taylor's Blog.  I sat near James, and he is blogging in real-time.    James himself gave an interesting keynote on the 
importance of decisions  


James concentrated on operational decisions and said in many of the organizations the role of computerized systems is to provide data (in various ways) to manual decision makers when they ask for it.    The smarter systems have larger portion of automated decisions, they are active rather than passive - determine when a decision is needed, and the decisions are measurable with quantitative metrics, so they can be evaluated.  


While James did not talk explicitly about event processing,  it is obvious that it has a significant role in his vision, it has several roles:

1.  determine when a decision is needed
2.  the automated decision itself is often context dependent and  the context can be determined by event processing context mechanism (temporal, spatial, event history related...)
3. the decision itself may depend on event pattern
4. Last but not least -- the extension of event processing to proactive computing coupling with the metric that measures the decision's result can trigger decision to mitigate undesired predicted deviation from the result,(I discussed this one with James during the reception in the evening).  

The EPTS virtual symposium - tomorrow.   A lot of logistics to get it running! 

On event processing as a technology and as a business

Philip Howard, an analyst who covers event processing for several years now, has posted a blog entitled: what's happening with event processing, observing that event processing is getting integrated with other areas such as: BPM, data integration and more. This is not a new phenomenon; in the EPIA book, we mention that among the event processing trends is moving from standalone to integrated even embedded, and this trend is evident with the evolution of event processing as a start-up universe, to having bigger software vendors as dominant forces. However - will event processing as technology going to disappear? I don't think so. There is common functionality among event processing utilization in various industries, applications, and hosting technologies, in all of them there are functions of filtering, event transformation, aggregation, pattern detection, and routing. It is not cost-effective to re-invent the wheel for each individual use (although there are variations). This is a similar situation to databases; database can be used for various reasons, and also be embedded with various other technologies and products (e.g. application servers, BPM, system management products, messaging systems - all use databases), while there are also variations, it is not the case that each of these areas develop database technology in an ad-hoc fashion. Thus, I see event processing continuing to evolve as a technology, and having both research and development activities that build generic event processing tools. From the business point of view, there will always be some niche for event processing stand-alone applications, but as Philip writes, most of the market will indeed be in the integrated area, this fact already reflects on the event processing technology in terms of need for standards, interoperability features, and ability to have embeddable collection of building blocks and components. More about this - later.

On event processing standards

One of the Dagstuhl follow-up will be to have action items in advancing standards in the event processing world. One of the topics discussed in Dagstuhl was standards, The team working on it was moderated by Paul Vincent, who already blogged about it. While I'll write more about it when the final report will be ready, here are some initial thoughts:

1. It seems that in the era where the vendor community is now dominated by bigger companies, the atmosphere for standards become more friendly.
2. For other communities - standards have been critical success factor, e.g. web services.
3. Somebody mentioned the immortal Stonbraker's phrase about SQL being "intergalactic data speak", we need the "intergalactic event speak" - and it is not an extension to SQL.
4. There are different standardization issues -- event representation, meta-modelling, event processing language; as well as extensions to many existing standards possible.
5. The language standardization will be trickiest - due to the variety of languages styles exist, here I think that we'll better start with a language at the PIM (platform independent model) level. In the EPIA book we provided one that can serve as a starting point.

I believe that standards is one of the important ways to go forward, and will write more about it when we'll have the Dagstuhl final report.

On small vendors, big vendors - individual view and industry-wide view

If you want to have a pet animal, you might prefer the little kitten over the big dog; if yo want to have somebody to guard your house, a big dog might be more effective, there also people who prefer big dogs as pets, a matter of personal taste.

Marc Adler responded to my previous post about consolidation and pure play in the EP market. Since Marc is in blog reduction mode, I will not be insulted if he'll not react to this posting, but I would like to provide further perspective.

There is nothing in Marc's response that I don't agree with, in fact when I have been 30 years younger (having 30 kg less from today, and this is after I've reduced 21 kg in the recent year).

I have worked in the IT shop of the Israeli Air-Force, I have been working with a new product that was called DB/1 and later renamed as Sapiens, at that time positioned as application generator for data-driven programming (there has been evolution in positioning over the years as well), it was a product in its beginning, I have done the first project with this product on the premises of the product developers, went with them to lunches, and went to their family weddings and funerals, thus, I got excellent service for them, could ask to add features, when there was any bug or problem I know exactly who is the responsible developer and could call him, or even invite him to solve it in our site. This has worked well since I had good personal contacts with them, but moreover, at that time the number of customers they had could be counted on the fingers of a single hand, and they could provide much attention to every customer. As said, for me, it was the ideal product to work with, and I fought some of my colleagues and superiors who thought that this is a too big risk for the Air-Force to depend on them in critical application, which was of course true. I guess that Marc had somewhat similar experience with Coral8 in his previous work; I also feel sympathy to the claim that big corporates have an inclination to come to customers with more people than the customer expects to see, and has less intimate atmosphere with customers, this was always been true.

Fast forward 30 years, I have somewhat different perspective on the universe; it was somehow surprising for me to find myself being hired by a big corporate, from an employee's point of view there are pros and cons to be employed by a big corporate, there is a nice posting on this topic.

People whose small companies are acquired by big corporates sometime dislike the culture of big corporates and move on, sometime they adjust, I know stories of both types, it is not black or white.

My perspective now is more on the macro level and looking at the question of: Is the current wave of consolidation good or bad in general for the event processing area, its assimilation into main-stream computing, and the ability of play a significant role in current and future enterprise computing?

My own view is that the market moves to the right direction. As I believe that the larger market is not in stand-alone event processing applications, but as a pervasive technology embedded in enterprise computing in general, there is some benefit to companies like - IBM, Oracle, TIBCO, Sybase, Software AG, and now we also see that Progress Software is making event processing as part of a more general platform. Some applications may not need it, but many others do, and getting event processing in the mainstream enterprise software infrastructure, can be done through owners of such existing infrastructure.

One other potential benefit that I see is that with a market that is more dominated by bigger vendors there is stronger probability to get to standards. Standards is one of the signs of maturity for an area (e.g databases, web services), and will be vital to get event processing into the mainstream. We started to discuss standards in the pre-EPTS meetings in 2006, and at that time the dominant startup companies were very much against it, since they both did not see the value for themselves, and also feared that standards will distract their limited resources. Bigger companies have more standard oriented culture, and experience in other areas of how to do it right. I think that the current developments in the market provides a good opportunity to raise the standards issue again, and this will be one of the topics planned to be discussed in the upcoming Dagstuhl seminar on event processing. I'll write more about standards follows the conclusion of the Dagstuhl seminar.

Back to the original theme --- there are times in life in which one prefers small cats, and other times that one prefers big dogs. Small cats may be more cute and pleasant, but in this phase in my life I am going to hunt, and big dog will probably be more effective for that task.

On event processing components exchange

I haven't blogged for a while, hectic week is ending (our working week is Sunday - Thursday, so this is the evening of the last working day!). Meanwhile I have noticed that Streambase has declared "component exchange program", looking closer, this includes a collection of stuff, starting from Twitter adapter, and even including the Streambase implementation to our "Fast Flower Delivery" example. Very good idea. Now, the challenge is to have a global components exchange that is not specific to a single vendor. In my previous posting I have written about event processing building blocks, and having a building block exchange is the ultimate way to implement this idea, everybody will be able to mix and match building blocks. The inhibitor is the lack of standard. Let's say that I want to use two of the exchange components, and that one should send events to the other, then of course they need to agree on how event is being represented, writing adapters for each pair of components is not very appealing. Furthermore, if one develops an application out of various programmable components, one would want them to be speak the same language. So -- having an exchange around a single product is nice, having an exchange in the industry level will be even nicer. More -later.

On event processing building blocks

As response to my posting about stand alone or part of a bigger picture, Marco made a comment that in the event-driven world there is an opportunity to provide building blocks that may be used in various platforms and part of multiple bigger pictures. This is a valid point, as event processing is indeed a collection of capabilities of various types -- transformation, aggregations, pattern detection and more, each of them can also be of various types --- e.g. supporting variety of aggregating functions, variety of transformation, multiple patterns etc, coupled with the fact that event-driven computing is decoupled, thus the interfaces to these components can be quite simple --- receive events and send events, can provide an opportunity to provide variety of such components, kind of plug-and-play event processing. The key, and currently main obstacle in letting it happen is standardization and current lack of standards.

• Interoperability standards are needed for standard interfaces
• Event meta-data standards are needed so that the events exchanged between components
• Languages and meta-modeling standards so people can model and program in a seamless model.

I believe that this is the right direction going forward, and it is a direction we in Haifa Research Lab are investigating; this might be the key to make event processing a pervasive technology - more about it, later.

On Zamehnof and event processing

Today, December 15th is Zamenhof's day. Zamenhof is the inventor of the Esperanto language, his idea was simple: create a universal language, with very simple grammar and spelling and no spelling and grammar exceptions. While there are several millions of Esperanto fans, it has not become the universal language, and we still speak in many languages and dialects. There are street named after Zamenhof in many of the cities in Israel, not that there are so many Esperanto speakers, but somehow famous Jewish people get priority in streets names (in Haifa Zamenhof street is near Einstein street - another famous Jewish person).

Like natural languages, in event processing we have many languages, and languages styles (when preparing the course I am teaching now I realized that there are more styles than I've realized, next class we'll discuss it in class, showing examples from all the different products participating in the EPIA book's website).

I share Zamenhof's dream to get to a universal language, but this may take time (maybe infinity), worth trying to invent the event processing Esperanto.

On event processing language standards

I found some time today to get away from the laptop (although, as usual I have a huge to-do list, with people in three continents chasing me...) and go to see the "Time Traveler's Wife" movie. The critics said that anybody who read the book will be disappointed, but although it does not fully following the book, it keeps the spirit, and rather well done.

Anyway, some of my to-dos is prepare for the 5th event processing symposium, in which I have to jump between several hats. One of my hats will be to provide the report of the language analysis workgroup which I am co-chairing with Jon Riecke from Aleri, who would not be able to come (however some Aleri representatives will be there). Going back to the original charter of the workgroup, it was intended to start discussion about event processing standards. We have not really started the discussion, however, the Trento symposium will be a good opportunity to start this discussion. I am showing now a draft of the slide I am going to show there to start the discussion;



In the top part of the chart I am bringing some memories from the database community.

So - those who are going to be in Trento, prepare for a lively discussion around this topic, I am sure that there will be a variety of opinions.

More about the language analysis workgroup - in later postings.

On EPTS working groups

Towards the year 2009, EPTS will increase its activities. Currently six working groups has been approved by a series of meetings of the EPTS steering committee extended with all the people who proposed working groups. We are going to issue soon a call for -- comments, vote and participation for the EPTS community.

First - something about the process of EPTS work. The main work will be done in working groups, the steering committee serves as a facilitator, but each working group has two co-leaders (as the proposals go now), and help the proposers devise the charter, make sure it makes sense, and meet the legal requirements (one of the properties of making EPTS as a formal organization is that there are some legal agreements between the members that need to be kept). The sec0nd phase which we are now entering is -- putting the working groups proposals in the EPTS site, in a members only section of the site, for comments, vote, and call for participation - each organizational and individual member can participate in any working group they are interested in. However, participation also means commitment for active participation. We shall hold a members' call to present all the proposals, and then the members will vote. Each negative vote will have to be augmented, and the proposal leader will answer - both objections and answers will be made public. After the members' vote, there will be final discussion in the steering committee, especially for a working groups that had objections, and final decision will be made.
The idea is to finish all this process in early January and launch the working groups for 2009.
EPTS members will get further instructions; the participation in the working group is restricted to EPTS members only, for legal reasons; however, everybody can become EPTS member (organizational member or individual member - see instructions in the EPTS website.

The six working groups that will be presented are:

(1). Glossary: We have issued version 1.1 of the glossary, but the work has not ended; this is a living document and a moving target, as the event processing area is in a relatively young age as a discipline. An agreed upon glossary is important to have common language, and has been successfully done in other disciplines.

(2). Use Cases: This working group continues from 2008 and had devised a template for the analysis of use cases, the idea is to survey a significant amount of use cases in order to classify event processing applications.

(3). Meta-modelling: OMG has issue RFPs for meta-modeling standards that have relations to event processing, in specific: Event Metamodel and Agent Metamodeland Profile.
EPTS still needs to determine about its status of engagement with OMG, according to it this can be either official response to the RFP, or input to OMG. In any event, EPTS has been recognized by OMG (and referenced in the RFP itself), and was asked to provide input. The working group will attempt to provide unified response of the EPTS community. Note that this is the pattern we are pursuing in general - EPTS will not become a standard development organization, but will assist existing organizations to develop EP related standards.

(4). Reference Architecture: In the early days of the pre-EPTS, there has been some work to collect and compare reference architectures of various vendors. We are now returning to deal with refernce architectures, this time in the form of an EPTS Working Group. This working group will propose one or more reference architectures for various cases (consistent with the evolving classification in the use cases workgroup and the evolving glossary).

(5). Interoperability Analysis: This working group will engage in study of requirements and mechanisms for interoperability - both between event processing products of various vendors, and between event processing products and various producer and consumers of event processing.
After the study, the working group will recommend to the EPTS community about next phases
(e.g. creation of additional standards, revision of current standards etc...).

(6). Languages Analysis: This working group will engage in study of existing event processing languages (both from products and from the literature) to devise (in a semantic level) a set of functions that is being used. After the study, the working group will recommend to the EPTS community about next phases (e.g. creation of a single language standard or creation of N variations for various languages or creation of a meta-lanaguage standard...).

I am personally will co-chair the languages analysis one (an area that I spent a lot of time on recently), and will follow, all others.

More working groups may be launched, however, I surveyed only those approved so far to continue to the next phase.

I believe that at the end of 2009 with the results of these working groups report, we'll advance the understanding of the event processing discipline, and will have a clear road-map for related standards...

Enough for now -- more later.

On Occurrence time: a footnote to the UAL fiasco

As a past Dungeon Master the word crawler always reminds me about the "carrion crawler", a monster you can see in the picture above, but recently a combination of the allmighty Google crawler, and automatic trading programs based on event processing has caused a fiasco that crashed the stock of United Airlines, some of the blogs have referred to it: Brenda Michelson in her Blog have talked about the butterfly that lead to the computer glitch. Mark Palmer thinks that news should be regulated (some people I know who were borne in countries were news are indeed regulated shiver to hear the idea that news - of any type - should be regulated).

I will not go back to the story, but as a footnote - two issues come to mind - event validation and the issue of occurraece time. So I'll write today about occurance time since it is easier...

The works in the temporal area are talking about several time dimensions - the bi-temporal model talks about: transaction time -- the time that a fact is recorded, and valid time -- the time interval in which the fact is valid. In event processing we also look at a bi-temporal time similar to this: detection time -- the time that the message that represents the event was detected by the processing system, and occurence time -- the time which the event happened in reality (occurrence time can be considered as the starting point of a valid time that ends when the event becomes irrelevant, but let's get it out of the scope and concentrate in occurrence time).

Some of the implementation of event processing base the order of event on the detection time, some support occurance time, and some base the built-in temporal capabilities based on detection time, and enable defining times as an an attribute, but then the temporal operators have to be hand-coded as regular predicate.

One of the common fallacies is that detection time is good enough as a metrics for temporal operations on event (e.g. trends), first - event from the past can suddenly pop up out of the blue (I know a person who has an habit to catch-up in Email every two weeks or so, and answer to the Email before realizing that there has been a whole thread of Emails that make answering the original Email quite obsolete), second - the order may not be kept even if the delay from the occurance time to the detection time is very small. The order of medical exams may not be consistent with the order of results reaching, and knowing the real order may be important for the differential diagnosis.

Thinking about standard structures for events -- I would think that having "standard header" with some mandatory properties for each event - is a good candidate for having standard (I am less optimistic about standards for the content of the event), and in the header - the occurrence

time should be a mandatory.

Occurrence time has some inherent issues associated with it - but I'll discuss it another time.

On Event Processing Description Language

This is a logo of the UK Geologists celebrated their 15o anniversary. I have more modest accomplishment, the Blog dashboard claims that this is my 150th entry into this Blog, that have started almost a year ago (in the one year anniversary, I'll look for some statistics about it)..

In one of the first postings to this Blog I have talked about meta-language for describing event processing behavior as a possible candidate for first standard. Recently, I have been working further on this idea, and soon I'll be able to start talking more about the details (those who heard my tutorial in DEBS 2008 could get a sneak preview. The language is a semantic language whose roots are coming from two directions: the "outside in" direction and the "inside out" direction.

The "outside in" direction is a result of requirement survey that has been done internally in IBM in nine industries, by interviewing IBM domain experts (such as industry CTOs) and in some industries also selected customers. The "inside out" direction is a result of looking at existing event processing languages (both from products and from academic projects) and try to find the union (but also learn something from the interaction), we are now in the process of doing the "inside out" part, while the goal is not to compare language, but to learn from them - it is still interesting to look at different languages and at different assumptions that are reflected in features in the language (example: if the language assumes that the input is a time series, then counting events is equivalent to creating fixed time interval, while in other cases where events arrive in a sporadic/chaotic way these concepts are totally orthogonal). One interesting question is the "effective" expressive power of languages, which is somewhat different from the theoretical expressive power, since - given a specific requirements, with some (or a lot of..) hacking, sometimes adding code, one can achieve this goal, so in comparing language one should use a subjective goal -- how easy to express it / is it a natural language to express it / can a typical developer understand determine how to express it ? maybe it can be translated to a quantitative measures -- length of solution, development time etc...

While the "pattern detection" is certainly the most challenging part of the meta-language, it is by no means the only part - it also includes sections around: event definition, transformation, enrichment etc.. This work also entails various interesting topics to report in this Blog -- more later.

On Event Pattern Semantics

Today is Passover, while I am far from being religious, there are several traditions we keep, one of them is to have a family dinner in Passover-eve, and reading (at least part of) the Haggadah, so I've looked at the internet to find some fancy Haggadah in English, and here is the result.

The call for EPTS founding members
is also progressing - by now more than 20 compnies either signed or indicated that they are in internal approval process, and intend to sign as EPTS members, in addition to about 20 individual members. We excpect this number to grow towards the deadline, and call anybody who has not joined and wish to contribute to the emerging EP community to join.

Moving to today's topic: Tom Puzak has posted on the CEP interest group a message about nine features the CEP engine should have. This discussion is useful, since there is no agreed upon "CEP manifesto", a definition what are the functions that should be supported by "CEP engines", and we are going to need one, sooner or later.

Since I am working on a tutorial for the DEBS conference which will talk about event pattern semantics as a major theme, here is a sneak preview about the type of semantic decisions that are needed, this is in addition to the semantics of the specific pattern (conjunction, disjunction, absernce, sequence...).

1. In which context this particular pattern is relevant. Context can be temporal (within working hours, 1 hour from the power break), spatial (within the headquarter building), semantic (only for platinum customers or state-oriented ( while it is rainining) - or combinations of all the various dimensions (I have written before about the notion of context).

2. Is an event participate in the same pattern in a single context or in multiple contexts ? this can happen when there there is overlap among contexts.

3. Is the action / notification about the fact that the pattern has been detected should execute immediately or in a deferred mode (example: at the end of the temporal context).

4. Within a context - is the pattern existential (i.e. we are looking for a single pattern per context) or can there be multiple instances >

5. Using quantifiers on synonims - Taking the example from Tom Puzak's message: we are looking for a message of A, B within 60 secondes (temporal context), and the actual flowing events are: A1 A2 B1 A3 B2 B3 - we may want the cartesian product, but typically this is not what we really wish - thus, we can use quantifiers to select among the A and B events. Quantifiers can be according to order - firts, last, each or according to content of attributes (or both).

6. Can a single event particpate in more than one pattern within the same context ?

7. Should newer synonim kill older sysnonims ?

This are just titles - and in the DEBS tutorial I'll explain each with examples and show how they impact the pattern detection behavior.

Bottom line -- tune up the semantics of a pattern consists of several decisions, if these decisions are not supported in the language, and the application does not conform with the default, results in hacking around... more - later.

Call for EPTS founding members

After some delays (getting everything through legal procedures in multiple big companies...) we are starting to prepare for the official launch of EPTS that has existed informally in the last couple of years. The founding steering committee consists of representatives of -

Coral8, Gartner, IBM, Oracle, Progress, Streambase, TIBCO and Professor David Luckham as an individual member, in the future members of the steering committee will be elected, so both company members and individual members can be elected; We are now issuing a "call for founding members", which means that any company, or individual person, that will sign the membership agreement by May 9, will be included in the list of founding members that will be mentioned in the press release notifying the launch. Here is the call - you may have already received it through other channel.

Call for EPTS Founding Members

EPTS - the Event Processing Technical Society - is going to be officially launched in late May or early June (exact date – TBD)
The EPTS goals are to:
Increase awareness (promote mindshare) about event processing, including understanding what its value is, producing a common glossary, and highlighting the current state of best practices,
Collaborate with various standards organizations making sure all standard efforts are in sync (EPTS will not become a standards organization)
Help establish Event Processing as an academic discipline
EPTS has existed as an informal group for the last two years, holding three Event Processing Symposiums to date; for details see: meeting 1, meeting 2, meeting 3

We invite participation of all vendors, individual participants (academic people, independent consultants, and employees of non-member organizations), and customers who would like to contribute to the evolution of the event processing area. There is no participation fee, but all members (organizational and individual members) must sign the EPTS Members Agreement.
EPTS activities will be performed through workgroups, and periodic general meetings. Examples of current workgroup tasks include glossary creation, use cases analysis, event processing meta-modeling, the study of event formats, and event processing academic education.
Benefits to members include the ability to identify new requirements or topics for discussion, lead or participate in workgroups and other community activities, being listed and potentially quoted in official announcements and press releases, and the ability to be elected to the EPTS Steering Committee,
Please respond immediately by email to Opher Etzion

If you are interested in becoming a founding member.
If you are able to sign the membership agreement by May 9th, 2008, you'll have the opportunity to appear in the list of founding members in the launch press release.
In order to join, please take the following actions:
1. Print the EPTS Member Agreement document

2. Sign (for individual member) or have an authorized representative of your company sign (for a company member) two hardcopies of the agreement. Keep one for your files. You will need to produce this copy if the EPTS Steering Committee ever makes a request for it at some point in the future.
3. Fax one copy to:
Attention: Mike Kaiser
Fax #: 1-845-489-9958
4. Courier the second hard copy signature to the following address for EPTS archival purposes:
IBM Corporation
Attn: Mike Kaiser (JGWA/062/M313)
3039 Cornwallis Rd.
Research Triangle Park, NC 27709
Phone: 919-254-7605
Note: Along with this hardcopy, please include the name, e-mail and phone contact information of the PR person that EPTS should coordinate with for the launch press release.

My OMG talk

The picture is of Washington DC, as seen from the Arlington side. Two weeks ago in the OMG meeting in Arlington I gave a talk on EPTS and EP standards, the talk has been now posted on the OMG site, so you can download it from there. In the next few days we'll advertise the call for participation for EPTS, towards its official launch - stay tuned.

More on Standards and Event Processing

I have written about standards before a few months ago, and nothing seems to have happened since that time. As I was asked to talk in the OMG meeting in March about the role of standards in EP, I'll have to devise a more detailed view - but I still think that standards is one of the key issues we should invest in. In my opinion the most important standard is the language standard, the EPL - which should standard as a meta-language. There is an intention to start working on it later this year. Other areas - interoperability, modeling, various standards for event structure (header, payload). The importance of standards stem from various perspectives.

1. The customer's perspective -- the main competitor of EP COTS is hard-coding the functionality within a regular programming, and making EP as a non-issue. One of the claims of enterprises is that their developers know how to program in standard languages, and they will not invest in teaching them proprietary languages. While not everybody take this approach, the industry does not like proprietary. There is an effort to make Stream SQL language - but since it does not cover the entire market (even not most of it) - this is not enough.
2. The ability to draw incremental knowledge -- as an example, work in the academia on query optimization around SQL has helped the entire industry. Concentrating around a single language can serve as a focus and have the knowledge be incremental instead of disiributed.
3. When moving to the "platform" oriented EP, instead of the "engine" oriented of the first generation, a platform will be able to include various implementations - agents that are based on various technologies/engines... thus, various technologies need to inter-operate, but also be part of the same application, and we don't want the application be built in a mix of languages...

more -later.

Hype vs. value -- a constructive view

Besides free advertising to an e-book, the illustration above - together with the title indicates that I am going to write something constructive - in the previous posting on "bitter pills" I have provoked the evil spirits and got sick with a flu, so with some almost sleepless nights, I have been too tired to Blog -- today is much better - so back in business. There are several people complaining about -- we need to get from hype to more impact on business, something is lacking today etc --- all true ! I also said that we need to take a constructive view - not only complain, but see what should be done. So here is an initial attempt to do it, actually nothing new here, just listing some observations done by various people:

1. More packaged applications based on EP technology should be constructed -- the model of using an EP tool as an application development tool covers only small part of the potential market, since, in the end of the day, business executives are interested in applications and not in technology.
2. Enable business users (non-IT developers) to control the behavior (e.g. define, modify, compose patterns/rules), since agility is an important expectation of the customers
3. Learn how to articulate the business vale -- yes we all know "threats and opportunities" but this is somewhat too abstract for the decision makers -- the business value is also not unique, there are various types of applications with different business values, and explaining the right one is crucial - more thoughts about the various types of business values -- in one of the next postings.
4. Advance on standards -- customers don't like proprietary.

Of course - this is only the initial list, not even talking about advances in technology, to start the discussion - more later.