The important aspect of CEP that fascinates me is its ability to co-relate events or data points from different streams or from within the same data stream. To elaborate, take an example of a retail bank that has a fraud monitoring system in place. The system flags every cash transaction over $10,000 for a manual review. What this means is a large cash transaction (a deposit or withdrawal) in an account raises the anti-money laundering event from the monitoring system. Such traditional monitoring systems can easily be circumvented /exploited by simple tricks such as depositing more than one check with smaller amounts. What happens if an account holder deposits 2 checks of $6000 in a day or 5 checks of $2500 in a day? Nothing. The system can't catch it. The CEP provides a way to define rules with a time frame criterion. For example, you could specify a rule to raise a flag when some one deposits more than $10000 in cash in a 12 hour window. Get it?

Please read full article here. http://maheshgadgilsblog.blogspot.com/2012/02/complex-event-processing-beginners-view.html

At the risk of getting flamed. Saying "traditional fraud monitoring" systems can't capture this is not true. It all depends on what technology was used and who built it. Sure, many fraud detection systems can't catch it, but there's plenty that can. The federal government requires that all financial institutions watch certain accounts. This is from first hand experience. One need not use CEP to catch this type of fraud. It's just a shameless product plug.

Yes there are other ways to do this but a good CEP will externalize the rules and provide a business user friendly interface for changing the rule.  So say 6 months after deployment the rule needs to change to either mover the 100,000 over 24 hours, or more than 30 deposits in a 24 hour period.  This can be accomplished without code deployment.

Yes there are other ways to do this but a good CEP will externalize the rules and provide a business user friendly interface for changing the rule.  So say 6 months after deployment the rule needs to change to either mover the 100,000 over 24 hours, or more than 30 deposits in a 24 hour period.  This can be accomplished without code deployment.

I would suggest looking at prior art. CEP products weren't the first to externalize rules and provide business user friendly UI. For example, over the last 20 years there have been numerous types of products like decision tables, decision trees, BRMS, expert system shell, and BPM engines. Although event processing frameworks can make it easier, it isn't necessary. Before CEP products started to become popular, many companies wrote their own. Depending on which CEP engine you use, there actually is "code" being deployed. It's just the framework is compiling those queries/rules first. Some engines do runtime byte code generation. Some engines use interpreted design.

Hyping the benefits is non-sense. It all comes down to the practioner and how one uses it. I've seen plenty of efforts to externalize business rules that failed. That is regardless of the product/stack/technology chosen.

Yes there are other ways to do this but a good CEP will externalize the rules and provide a business user friendly interface for changing the rule.  So say 6 months after deployment the rule needs to change to either mover the 100,000 over 24 hours, or more than 30 deposits in a 24 hour period.  This can be accomplished without code deployment.

I would suggest looking at prior art. CEP products weren't the first to externalize rules and provide business user friendly UI. For example, over the last 20 years there have been numerous types of products like decision tables, decision trees, BRMS, expert system shell, and BPM engines. Although event processing frameworks can make it easier, it isn't necessary. Before CEP products started to become popular, many companies wrote their own. Depending on which CEP engine you use, there actually is "code" being deployed. It's just the framework is compiling those queries/rules first. Some engines do runtime byte code generation. Some engines use interpreted design.

Hyping the benefits is non-sense. It all comes down to the practioner and how one uses it. I've seen plenty of efforts to externalize business rules that failed. That is regardless of the product/stack/technology chosen.

Yes there are other ways to do this but a good CEP will externalize the rules and provide a business user friendly interface for changing the rule.  So say 6 months after deployment the rule needs to change to either mover the 100,000 over 24 hours, or more than 30 deposits in a 24 hour period.  This can be accomplished without code deployment.

I would suggest looking at prior art. CEP products weren't the first to externalize rules and provide business user friendly UI. For example, over the last 20 years there have been numerous types of products like decision tables, decision trees, BRMS, expert system shell, and BPM engines. Although event processing frameworks can make it easier, it isn't necessary. Before CEP products started to become popular, many companies wrote their own. Depending on which CEP engine you use, there actually is "code" being deployed. It's just the framework is compiling those queries/rules first. Some engines do runtime byte code generation. Some engines use interpreted design.

Hyping the benefits is non-sense. It all comes down to the practioner and how one uses it. I've seen plenty of efforts to externalize business rules that failed. That is regardless of the product/stack/technology chosen.