SOA and BRMS
In the mean time coming back to our purchase Order sample, I will take the architect's hat, and outline the deployment of BRMS within a SOA approach.
SOA has proven to be a great technology to make enterprises more agile. With their ability to separate business logic from its implementation, BRMS adds more capabilities to the SOA. SOA is a progressive architectural style for creating and using business tasks that are packaged as services. The main goal of these services is to expose loose coupled business functions to facilitate deployment, combination, and reuse within different applications. SOA supports the integration of heterogeneous systems, as soon as they are exposed over the internet using standard protocols like HTTP, XML, unified interface definition (WSDL).
Every business has rules, and business users want complete control and visibility over these rules. A BRMS decouples an application's business logic from its data access and from its flow control. Decision logic is exposed behind decision services which support some business task. Such services are ValidateCustomer, ValidatePurchaseOrder, CheckCreditHistory… Using BRMS those service delegates the processing to a rule set deployed within a Rule Engine. Those rule engine can be managed using a rule execution server which provides the pooling mechanism, rule set management and execution monitoring functions.
A business application leveraging MDM, BPEL and BRMS may look like
The SOA is organized in a set of business services used by the business application logic. This business application layer is modeled using use cases diagram or business process map, and may be implemented using BPEL orchestration, and/or a standard Model View Control web application. The business services leverage lower level services, which I packaged in a technical service layer. They support lower granularity service like accessing business objects (DAO for Creating Reading Updating Deleting data), master data like product definition, enumerated domain value, sub process flows, web services and rule execution server. In this logical view of the architecture I do not need to expose the Enterprise Service Bus which may need to be used as a communication layer between the application logic and the business services.
In fact this diagram even if it outlines one application, can be applied for multiple applications. The business and technical services can be reused to support other business cases.
Rule developer creates the rule projects structure, the data model used by the rules, the rule execution flow, prototypes some rules, and then gives the hand to the business analysts to complete the rule authoring activity. Business Analysts use the web based interface to manage the full life cycle of the rule. Rules are persisted in a rule repository. The deployment of a rule set can be done without stopping the core application, and can be controlled within the Monitoring and Control environment of the production platform. Using a BRMS the IT staff and business analyst can work closer together as they are using the same high level language to write business rule, they understand the rule flow, so the long term maintenance of the application is greatly enhance.
Within a SOA the BRMS is bringing an effective and efficient mechanism to manage the decision logic of any business application. The architect needs to design the decision service so they can be reusable, then the rule architect needs to design the rule execution flow to take into account some specificities of context of execution. Rule set reuse may infer some tests on the context of the caller. This context is exposed to the rule engine as a fact in the working memory, and the rule flow can have some initial tasks to test and apply different branching according to the state of this context.
I will dig into code detail later.
Comments