![]() |
|
|
|
|
|||||||
| Complex Event Processing RSS News Aggregated RSS news on CEP, ESP and EP. |
|
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Gnome Simple Stateful Music Player 1.2 (Default branch) | iBot | Software Releases - RSS News | 0 | 01-19-2008 04:30 AM |
|
|
Submit Tools | LinkBack | Thread Tools | Display Modes |
|
||||
|
Business rule execution: stateless/transactional, stateful/monitoring, or both?
vincent
Mon, 03 Mar 2008 21:30:11 +0000 TIBCO was recently invited to discuss the technology needs for a large rule-driven insurance risk management system. Interestingly, the specified requirements had nothing to do with CEP, and everything to do with traditional (stateless) business rules execution:
So why would a rule-driven CEP engine even considered for this problem? Lets take a look at some of the longer term needs of such an organization:
These don’t necessarily align best with conventional stateless rule services. 1. Business activity and business performance monitoring: direct feedback over time / time periods / regions / etc of which rules are used and which aren’t, and information on trends for different regions, policy types, take-up rates, etc. This requires monitoring large amounts of events over time, and is best done by correlating events directly in the rule engine. 2. Increased “Complex Rule Processing”: to automate more policy decisions, more rules are likely to be required on more “data”. Naturally, hitting a database with multiple transactions to get different views required for different decisions is going to be bad news for the rule server, development team, database administrators, and the database itself. Storing event-related information in situ (or transparently via a high performance distributed cache) would make complex rule processing easier to implement and (crucially) maintain. 3. Customer-centric (portfolio-based) view of policies: if a customer is acquiring overlapping policies, does the carrier want to know about it, or even let the customer know? Or if a customer has policies that have gaps, shouldn’t they/their insurance agent be informed? This again is easiest to achieve by maintaining state about the customer between transactions. So it looks like stateful rule services, for monitoring business events wider than the current transactional (stateless) context, might be useful after all. Notes: CEP can also be used in insurance to support the standard insurance carrier’s investment activities, in areas like BAM such as for documentation track ‘n trace. Source... |
||||
| Google UNIX.COM |
| Forum Sponsor | ||
|
|
| Thread Tools | |
| Display Modes | |
|
|