As we move further down the learning curve with SOA, we are refining the "vision" of SOA, and defining details around the core technologies that make sense as we go. A good example of this are data abstraction/services layers, such as those from Composite Software and others, that allow you to loosely couple from your core systems of record, remapping older physical schemas into something more productive for your SOA, and placing data volatility in its own domain.
Of course, there are a few more tricks similar to data abstraction you can leverage as well, including the use of rules engines within your SOA. Or, simple put, placing business rules in their own domain, making business rule creation and changes easy and also loosely coupled from the rest of your architecture.
In order to make these engines work and play well with existing SOA approaches they have "SOAfied" their rules engines, and providing development and deployment tools to make them easier to leverage within a SOA. The king of rules engines, ILOG, is
proving this point with their latest product release out this week, JRules 6.5, an offering in ILOG's business rule management system (BRMS) product line, featuring "push-button" creation and deployment of Transparent Decision Services (rule-based Web services) in service-oriented architecture (SOA) applications without additional programming. You can see the complete release here.
What's unique about this is that it's an old architecture trick within a new SOA approach, placing rules in their own environment, thus providing a mechanism for quick and easy changes, deletions, or additions to core business rules without have to change back-end service or application code, and thus providing a central location for rules processing for orchestration layers as well. This adds to the core agility theme of SOAs, allowing architects to provide configuration-oriented change-ability of business processes and business rules without having to go through development and testing cycles.
So, should your SOA employee and "SOAfied" rules engine. Here are few questions to ask:
1. Do you currently employ a rules engine? Of so, chances are your SOA should leverage the same rules engine.
2. Are you business rules constantly changing? If yes, a rules engine may be needed to provide a mechanism to change these rules without redevelopment, and loosely couple the rules from the core applications and services.
3. Are your rules complex? If yes, you may find that rules engines do a better job in defining and deploying and managing complex business rules.