Tuesday, November 3, 2009

On the patterns collections list

Back on dealing with the EPIA book, we are now in the process of the 2/3 book review, and started to work on the last 1/3. Right now I am working on a section talking about temporal issues in event processing, but before talking about that, I still wish to get back to the previous chapter that deals with event patterns, continuing the discussion that I have started in this posting, and continued in this posting. In the book we bring a collection of patterns, these patterns are not meant to be complete, and we expect to grow the collection of patterns over time using the book's website.



The patterns collected are of several types:

  • Logical operator patterns: all, any, absence that designate conjunction, disjunction and negation event patterns.
  • Threshold oriented patterns: count of events, average/maximum/minimum of some attribute of a collection of events has some binary relationship (e.g. > ) with a given threshold.
  • Relative patterns: relative max/relative min selects the events with the minimal or maximal value for a certain attribute over a collection of events.
  • Modal patterns: sometimes, always, select a collection of patterns if a certain predicate is satisfied over all/some of the events in this collection.
  • Not select pattern: This is a second level modal pattern that selects events that were not selected by a certain patterns.
  • Sequence pattern: A temporal pattern that denotes a conjunction of event that occur within a predefined order.
  • Trend patterns: Temporal patterns that detect trend, e.g. a value of a certain attribute is consistently increasing with a context.
  • Spatial distance patterns: These are similar to the threshold patterns, but relate to the distance of events from some point in space.
  • Spatial relative patterns: This are similar to relative patterns, but relate to the relative distance of events from other events
  • Spatiotemporal patterns: This combine temporal and spatial properties, and designate direction of movement (e.g. moving consistently north, moving towards some entity).

The current full list of patterns consist of 30 patterns, and this list will probably grow. Each of the patterns is defined in the book and demonstrated using an example.

More on patterns - later.

6 comments:

Yemula Pradeep said...

Hello Mr. Etzion, Your posts are very informative. They stimulate my thinking and generate new point of view. Thanks.

Anonymous said...

Hello Mr. Etzion,

obviously only comments are welcome that praise CEP as the next wave in computing. It would be great to have examples of the use of CEP that can't be done right now with existing tools and software suites or at least much better. Strangely I can't find any. CEP seems to be more of an academic topic. Obviously this comment will not be posted as part of your censorship.

Kind regards.

Opher Etzion said...

Hello Anonymous. Typically I don't publish comments given by anonymous people, as I think people should be brave enough to make comments in their own name, and not hide under anonymous, so I call upon you to expose your identity.
The reason that I did publish your comment is twofold: unlike some other bloggers that censor comments of people who don't agree with them I believe in free speech, and I think that the whole issue of Blogging is also to discuss things with people who don't agree with you, so I am not sure where have you taken the assertion that it is obvious that I will censor your comment.

Now to answer to your comment about the fact that CEP cannot be done with existing tools, you are right, I have never claimed that there is anything the **CANNOT** be done, what I am claiming is that if you have models and abstractions that are dedicated to EP, then the development and maintainability of such systems will be more cost-effective. If you can write something in one sentence, relative to 25 SQL lines of code, or 100 Java lines of code, and in level of abstraction that is understood to semi-technical people, it is a gain. You can make the same claim -- there is nothing that cannot be done right in Assembly languages, why do we need programming languages, or taking it further, everything can be done right using Turing Machine -- why do we need anything else ?

The indication that this is not an academic discipline only is evidence by the analysts report that indicate that EP software is the most growing segment of enterprise middleware software in the last couple of years, and the many instances that I know in which customers found real benefit in using this approach.

cheers,

Opher

Hans Schmid said...

I'm brave enough to post under my own name. I didn't because I thought it's a waste of time as I posted before and didn't make it.

Please don't explain the meaning of abstractions to me. I'm well versed in functional programming and the only reason is abstraction. But if I want to make business or better money I have to know who could be the potential buyers. In your upcoming book you have this FFD (Fast Flower Delivery) scenario. In this field I'm playing against software suites like Siebel (Oracle), all the BI software suites from Oracel, SAP, and so on without any further benefit for the customer.

As you can see for me it's not all about abstraction. It's also about making money in the real world.

Maybe you know about CEP customers and how and why they use it instead of the more traditional software suites. I would like to see some examples of real-world applications.

Although I'm not fully convinced of your book I will buy it. Probably even before it will be published by means of Manning's early bird program. It's anyway the only reasonable book on CEP out there.

Kind regards,
Hans

BTW: My name "Hans Schmid" translates to "John Smith" in English. I hope my posting is now less anonymous. ;-)

Opher Etzion said...

Hello Hand Schmid. I don't know if your comment about translation to "John Smith" means that it is a pseudonym, anyway, I typically don't publish anonymous comments as a matter of principle, so if you tried in the past as anonymous, I may have filtered you out.

Now about your comment of -- how to make money out of it -- this relates to the ROI on using event processing.
Our book is dedicated to the technical aspect and does not discuss the business value in details; it may be a good idea to dedicate some of my future postings to customer oriented stories for those interested.

However, there is a new book dedicated to the business value of event processing written by Mani Chandy and Roy Schulte, called: Event Processing: Designing IT Systems for Agile Companies, see: http://www.amazon.com/Event-Processing-Designing-Systems-Companies/dp/0071633502/ref=cm_cr_pr_product_top for more details.

I have ordered this book and will post review in my Blog when it will arrive.

As for the example you bring, Oracle has its own CEP solution, besides its products on CRM (acquired from Siebel) which is an application that may use EP, and BI products, so it seems that Oracle also found value in using dedicated offering in this area.

cheers,

Opher

Hans Schmid said...

Hello Opher,

thanks for your kind replies. Hans Schmid is my real name. Not a pseudonym. :-)