Talk:Event stream processing

• Note that some products have been put in the external links - have removed them (as they are equally inappropriate there). —Preceding unsigned comment added by 61.68.29.130 (talk) 22:19, 1 November 2008 (UTC)[reply]

It's not clear what the difference is between this and

ESP and CEP should not be merged. Event stream processing has it roots in data stream processing and CEP roots are toward more complex debugging and simulations in distributed systems. See http:// tibcoblogs.com/cep for a good emerging explaination of this. Snaggydog 15:35, 6 May 2007 (UTC)[reply]

I do not agree that these referenced (tibcoblog) discussions help to make the case against merging these two articles. I support the merge proposal. Chris Loosley 18:17, 14 August 2007 (UTC)[reply]

Agreed, however I propose that Event Stream Processing is a subset of Complex Event Processing, so this should not suggest merge but mapping? —The preceding

Sounds fine. (BTW, kindly sign your posts - use four ~'s) Ronnotel 04:16, 25 November 2006 (UTC)[reply]

I believe CEP and ESP are closely related and that the articles should be merged, but they are industry terms, and the industry uses both terms, and it is not clear (or agreed) what exactly the difference is between the two terms. Equally, it is not agreed if one is a subset of the other as they both appear to be capable of solving the same problems - just different models/implementations of the same problem resulting in similar solutions. If the articles are merged, both terms will (most likely) apply to the article equally. Maybe it's possible to create a 3rd page calles "CEP/ESP" and have the other terms link to the new page?

CEP and ESP should not be merged. 24.255.127.4 07:30, 8 December 2006 (UTC)[reply]

If this was a vote, then great - we'd know your position. But it's a discussion. Would you care to elaborate on why you believe CEP and ESP should not be merged? Thank you.

I think it would be much easier to compare the two if they were merged. As it is, you have to go back and forth to try to see what's different about them. My $0.02. Ronnotel 02:44, 9 December 2006 (UTC)[reply]

Made a new subsection below to comment on this. --Sigma 7 01:51, 10 March 2007 (UTC)[reply]

<post> I'm more familiar with some products in this space than others. Personally, I see ESP as a class of, or one specific type of complex events processing. I'd say as a general rule ESP has been specifically focused on business/situation activity monitoring as opposed to proactive operations and management. In my experience ESP is generally focused on data that is generally perceived to be in motion - either data on topics, queues, subjects, or channels, etc. Many of the engines have the ability to retain this information in their memory and/or cache (which is persisted in some cases) for purposes of aggregating information across time (or some other boundary) but the data is persisted in the cache of the ESP engine as opposed to going back to an end point application - as compared to or possibly contrasted to something like Enterprise Information Integration (EII) which essentially goes back to the end point application to retrieve data.

personally I see CEP is combining these two disciplines. As as example, you may want to specially recognize a customer's loyalty by watching for customers that have more than 3 transactions within a given time period - say a month. This is not a BI problem because you want to identify and connect with the customer at the POS not some later point in time via mail, email, etc. Here's where it gets complicated though - I don't just want to recognize the third occurrence/transaction with the customer but I now want to go retrieve more detail about the customer so that I can determine if this is a fantastic customer, a great customer or merely a good customer which should be factored in to how I as a company treat this situation. So, I'd really like to go retrieve information about this specific customer and potentially even get their transaction history so I can not only determine how to treat them given their affinity but potentially even determine what specific types of things are most likely to appeal to them given their history. The type of model would be desired for cross-sell and up-sell. I don't want to be out there just asking my customer's, "would you like fries with that" but be much more specific about what type of offer I'd like to provide for them.

Sorry for the long post but to me these are problems that are beyond the complexity that ESPs are designed for and are an example of why whether combined or not it is important to distinguish the differences between event stream processing and complex event processing. my $0.04 </post> —The preceding

Content of Event-driven architecture

On a related note to the merge, Event-driven architecture seems to give a slight difference between the two (although I did rename it from Stream Event Processing.) Either this means that the two articles are different enough that they should not be merged, or there's writing styles in other articles that treats them as seperate topics.
Clearing things up in this article may make the decision to merge slightly easier. While I'm not an expert on this topic, I suspect there's a slight difference, between the two that could be expanded on. --Sigma 7 01:51, 10 March 2007 (UTC)[reply]

ESP SHOULD GO AWAY AND I HELPED CREATE THE PROBLEM!!!You are completely correct in my opinion; these should be merged. And I say this from the perpsective of the software vendor that popularized and caused the confusion in the first place. I'm the general manager of the Progress Apama software division and we coined the term "event stream processing" in April of 2005 when we acquired Apama for $30M - we didn't like the term "complex event processing" and decided to make up another term. Yes, stream processing, and data stream processing have been used as terms in academia, but we made up the term ESP as a synonym for CEP. Some on this list will argue that there are subtle, technical differences, but, being in the center of this quagmire of a debate, I think they should be merged, and that ESP should basically go away!

- Mark Palmer, General Manager, Progress Apama, [email protected]

I find this argument convincing, because it shows how Progress software has been using the ESP terminology, and accounts for the overlap in the way people understand the meanings of the two terms. I therefore support the merge, to reflect actual usage.

However, evidence suggests that Progress only thought they had "coined" the terminology "event stream processing" in 2005. In fact, in November 2004, the paper Dataflow Networks for Event Stream Processing by R. Manohar and K. Mani Chandy was presented at the conference on Parallel and Distributed Computing and Systems (see item 439-202 in the Applications track). Chris Loosley 18:17, 14 August 2007 (UTC)[reply]

I too find Mark's argument valid. If the details are so "subtle" as to be impossible to explain, or impossible to convince your peers, then realistically there are no differences. Let's kill ESP.

Bardcom 21:28, 26 August 2007 (UTC)[reply

]

Category:Event (computing)

There are various disconnected merger proposals relating to articles in this category. I think it would be better to focus on tidying up the whole category. --RichardVeryard 08:27, 27 August 2007 (UTC)[reply]

• You'd be a brave person to try. This industry (event processing) is still embryonic and there are many polarized views that don't exactly merge yet. I believe that any merger right now will be contentious. Perhaps as the market matures, this task will simplify.
  Bardcom 21:40, 29 August 2007 (UTC)[reply
  ]

I dont think much would be served by merging ESP and CEP entries. This field is still growing and the entries will probably change over time. - David Luckham —Preceding unsigned comment added by Topfatcat (talk • contribs) 00:34, 29 September 2007 (UTC)[reply]

Before adding vendor links to this page, please refer to [Complex Event Processing Talk] page first, as this topic is currently being discussed.