Bruce makes an interesting comment on business rules too: that “routing logic in process gateways” are not “business rules”. That doesn’t really make sense: for sure some gateways will be process-housekeeping decisions of little interest to the business user, but others will surely embed business-critical decisions. On the other hand, it has long been acknowledged that a best practice for BPM is to delegate such business decisions to a managed decision service - hence the explicit new business rule (aka decision) task in BPMN 2.0. And,in the CEP world, for tools like TIBCO BusinessEvents to invoke a decision managed by its Decision Manager tool.
The success of Service-Oriented Architecture (SOA) has created the foundation for information
and service sharing across application and organizational boundaries. Through the use of SOA,
organizations are demanding solutions that provide vast scalability, increased reusability of
business services, and greater efficiency of computing resources. More importantly,
organizations need agile architectures that can adapt to rapidly changing business requirements
without the long development cycles that are typically associated with these efforts. Event-Driven
Architecture (EDA) has emerged to provide more sophisticated capabilities that address these
dynamic environments. EDA enables business agility by empowering software engineers with
complex processing techniques to develop substantial functionality in days or weeks rather than
months or years. As a result, EDA is positioned to enhance the business value of SOA.
The purpose of this white paper is to describe the approach employed to overcome the significant
technical challenges required to design a dynamic grid computing architecture for a US
government program. The program required optimization of the overall business process while
maximizing scalability to support dramatic increases in throughput. To realize this goal, an
architecture was developed to support the dynamic placement and removal of business services
across the enterprise.
Most BREs today are deployed as “decision services”, and are used in “stateless” transactions to make “decisions” as a part of a business process. A CEP application is instead processing multiple event streams and sources over time, which requires a “stateful” rule service optimized for long running. This is an important distinction, as a stateful BRE for long-running processes needs to have failover support - the ability to cache its working memory for application restarting or distribution. And of course long-running processes need to be very particular over issues like memory handling - no memory leaks allowed!
The one, really big, difference between Complex Event Processing and traditional BRMS tools is that the former is loosely associated with EDA and decisions that are based on multiple events, whereas the latter is more associated with conventional request-reply SOA and automating decisions made in managed business processes.
I have been thinking about the response I got from David Campbell to my posting on his CEP article. In his comment David discussed the difference between using a business rules engine in CEP (Complex Event Processing) and using business rules more general
BI stands for Business Intelligence, which to some will sound suspiciously similar to Groucho’s famous comment. But in reality BI is more to do with providing the right “Business Information” to people who need it (i.e. business analysts), and there