In fact, IT-Director’s article from two years ago confirms that there are various issues that confront the event processing community. There now seems to be common agreement that event-processing as a term should best be used to encompass both CEP and event stream processing (ESP), the latter term arguably applying to events that are not necessarily complex in themselves.
In addition to just what exactly event processing is, and whether and how it differs from operational business intelligence (BI), another vexing issue is how big the event processing market is. For those of you that might want to delve into philosophical discussions about which concept is broader (and which came first) within the alphabet soup of CEP, ESP, SOA, event driven architecture (EDA) and business activity monitoring (BAM), here is one of ZDNet’s blog posts. There is also an excellent blog post on a practical combination of SOA, EDA, and CEP, plus, you can always peruse the Event Processing blog from the horse’s mouth (it is maintained by Progress Apama staffers) .
Principles of CEP-based Systems
In plain English, CEP lands itself well to any environment that treats any business update as an “event.” Such organizations want to enable users to rapidly define event-based business rules to identify patterns indicating opportunities and threats to the business. These encapsulated rules (either as “if-then” statements or structural query language [SQL] statements) are loaded into a real-time computing (RTC) CEP engine.
The correlating engine is permanently connected to multiple event sources and destinations (with volumes of events and related data points) and offers analysis and response within an extremely low latency period. Events can be captured and preserved in time-order for a historical pattern analysis and root-cause analysis (RCA).
Given that algorithmic trading in capital markets was one of the first real-life applications of CEP, let’s translate the above general CEP principles into trading terms. The continuing digitization of financial market data and the advancement of electronic market access has created a market environment in which competitive differentiation amongst financial service firms rests with split-second algorithmic execution that can exploit minuscule and momentary advantages in price, time, and available liquidity.
To that end, a trading company will treat any market update as an “event” and will enable users to rapidly build quantitative algorithms (based on their vast experience and know-how) to identify trading opportunities and risk breaches. Germane trading rules are then loaded into a trading system that offers real-time analysis and response with a latency measured in milliseconds.
The trading system is permanently connected to a number of relevant market data sources, news-feeds, and trading venues (exchanges). Finally, events can be captured and preserved in time-order for backtesting and digital forensics analysis.
In summary, the drivers for CEP adoption are the following:
* Applications with high throughput and latency requirements. Such requirements from market trends such as higher velocity business event flows, more voluminous (and yet shorter-lived) transactions, and rapidly changing market conditions. These trends in turn pose the challenges onto customers in terms of how to detect opportunities and threats in real-time, and how to show the health of their business; and
* The need for rapid software development and customization, and increasing application complexity (temporal and/or spatial logic, real-time analytics, etc.). The customers’ challenge in this regard is how to accelerate the deployment of new capabilities.
In addition to just what exactly event processing is, and whether and how it differs from operational business intelligence (BI), another vexing issue is how big the event processing market is. For those of you that might want to delve into philosophical discussions about which concept is broader (and which came first) within the alphabet soup of CEP, ESP, SOA, event driven architecture (EDA) and business activity monitoring (BAM), here is one of ZDNet’s blog posts. There is also an excellent blog post on a practical combination of SOA, EDA, and CEP, plus, you can always peruse the Event Processing blog from the horse’s mouth (it is maintained by Progress Apama staffers) .
Principles of CEP-based Systems
In plain English, CEP lands itself well to any environment that treats any business update as an “event.” Such organizations want to enable users to rapidly define event-based business rules to identify patterns indicating opportunities and threats to the business. These encapsulated rules (either as “if-then” statements or structural query language [SQL] statements) are loaded into a real-time computing (RTC) CEP engine.
The correlating engine is permanently connected to multiple event sources and destinations (with volumes of events and related data points) and offers analysis and response within an extremely low latency period. Events can be captured and preserved in time-order for a historical pattern analysis and root-cause analysis (RCA).
Given that algorithmic trading in capital markets was one of the first real-life applications of CEP, let’s translate the above general CEP principles into trading terms. The continuing digitization of financial market data and the advancement of electronic market access has created a market environment in which competitive differentiation amongst financial service firms rests with split-second algorithmic execution that can exploit minuscule and momentary advantages in price, time, and available liquidity.
To that end, a trading company will treat any market update as an “event” and will enable users to rapidly build quantitative algorithms (based on their vast experience and know-how) to identify trading opportunities and risk breaches. Germane trading rules are then loaded into a trading system that offers real-time analysis and response with a latency measured in milliseconds.
The trading system is permanently connected to a number of relevant market data sources, news-feeds, and trading venues (exchanges). Finally, events can be captured and preserved in time-order for backtesting and digital forensics analysis.
In summary, the drivers for CEP adoption are the following:
* Applications with high throughput and latency requirements. Such requirements from market trends such as higher velocity business event flows, more voluminous (and yet shorter-lived) transactions, and rapidly changing market conditions. These trends in turn pose the challenges onto customers in terms of how to detect opportunities and threats in real-time, and how to show the health of their business; and
* The need for rapid software development and customization, and increasing application complexity (temporal and/or spatial logic, real-time analytics, etc.). The customers’ challenge in this regard is how to accelerate the deployment of new capabilities.
No comments:
Post a Comment