What are the core differences between WSO2 Stream Processor and WSO2 Complex Event Processor?
WSO2 SP can do everything that WSO2 CEP can do. WSO2 SP also has some addtional features as explained in the following table.
| Attribute | Sub Attribute | WSO2 Complex Event Processor | WSO2 Stream Processor |
|---|---|---|---|
| General | Siddhi Version | WSO2 CEP is powered by Siddhi 3.x. | WSO2 SP is powered by Siddhi 4.x. This version is more stable than Siddhi 3.x with improved performance and bug fixes. |
| WSO2 Carbon Version | WSO2 CEP is based on WSO2 Carbon 4.x. | WSO2 SP is based on WSO2 Carbon 5.x, and therefore it is more lightweight. | |
| Working in containerized environments. | WSO2 CEP encounters certain challenges when working in containerized environments. | WSO2 SP is designed to be container friendly and can carry out native distributed processing. | |
| Configuration | The main configurations (i.e., configurations that define parts of the event flow such as collecting information, processing logic and publishing results etc.) are done in seperate files/UIs. | All the configurations related to an event flow are contained within a single Siddhi application. For more information about configuring the evnt flow in a single file, see Creating a Siddhi Application. | |
| Incremental Analysis | WSO2 CEP focuses mainly on real-time processing and does not perform time series aggregations. | WSO2 SP uses the incremental analysis capabilities of Siddhi 4.x to perform time series aggregations without having to integrate with third pary platforms such as Apache Spark. Incremental analysis smoothly federates real-time analytics with batch analytics by allowing both forms of analytics to be done in the same message flow. For more information, see Incremental Analysis. | |
| Distributed Deployment | Scalability | WSO2 CEP is less scalable compared to WSO2 SP due to its limitted container-friendliness. | WSO2 SP is highly scalable with its container friendliness. |
| Distributed Architecture | The distributed architecture of WSO2 CEP is based on Apache Storm. | The distributed architecture of WSO2 SP is based on Kafka. As a result, the distributed deployment of WSO2 SP is more fault tolerant and it supports exactly-once processing. For more information about distributed deployment of SP, see the Deployment Guide. | |
| Multi Data Center Deployment | WSO2 CEP does not have built-in support for multi data center deployment. | WSO2 SP has built-in support for multi data center deployment. For more information about multi data center deployment, see Multi Datacenter High Availability Deployment. | |
| Tooling | Query editing | WSO2 CEP Management Console has a UI that supports only query editing. | WSO2 SP offers a richer query editing tool that also supports auto completion, event simulation and debugging for Siddhi queries and more. For more information, see Understanding the Development Environment. |
| Status monitoring | WSO2 CEP has Carbon metric support to view only JVM analytics. | The Status Dashboard of WSO2 SP allows you to monitor your SP deployment with a complete set of statistics related to performance, resource consumption etc., of Siddhi applications and JVM. For more information, see Monitoring Stream Processor. | |
| Business Ruls | WSO2 CEP does not include a feature to allow business users to create rules out of business templates. | WSO2 SP allows you to create business rules from templates. For more information, see Working with Business Rules. |
Can we detect events that have not occured using Siddhi?
This can be achieved via Siddhi. The not <condition> for <time period> key word tin Siddhi allows you to detect the non-occurrence of events.
For more information about this key word, see Siddhi Query Guide - Logical Patterns.
For a demonstration of how non-occuring events can be detected in a real world user scenario, see Correlating Events for Complex Event Processing - User Scenario 2.