I rarely disagree with Ismael, but I think his latest piece, in which he argues that a BPMS is the "right" way to build a Complex Event Processing (CEP) platform, is a little off base. All first-tier BPMS platforms today, not just those based on BPEL, can listen for events to instantiate a process, resume a waiting process, or interrupt a running activity. I don't think that has anything to do with CEP, which is about correlating events from multiple streams and applying rules to detect patterns of interest, e.g. suspicious or fraudulent activity. In a BPMS, such capabilities are similar to those found in the BAM component, which correlate process events to aggregate KPIs and apply rules to detect performance problems. But even vendors that offer both BPMS and CEP, such as IBM or TIBCO, employ a special purpose engine for CEP, not the BPMS. That's because CEP does not mean "good" everyday event processing, but special capabilities needed to look for rare (and complex) correlations among events in extremely high speed message streams. You can combine CEP with BPMS, e.g. to take action on a "hit", but to suggest that the type of event processing needed in CEP is the same as needed for ordinary process orchestration is incorrect.