The clear separation between the technical environment (Rule Studio) and the business user environment (Rule Team Server) arose from ILOG’s experience with actual BRMS implementation projects. In general developers prefer to maintain software artifacts within a standard source code control system such as ClearCase or CVS. Business users prefer a tailored environment which supports rule versioning, history, and other BRMS features. Within Rule Studio, all artifacts are maintained as files within the Eclipse workspace, and so can be managed via a source code control system. Within the Rule Team Server environment, rules and rule metadata are persisted within a Rule Repository implemented in a RDBMS. Synchronization between these environments is initiated from Rule Studio and is bi-directional: New/modified artifacts can be “Published” from Rule Studio to Rule Team Server, for example new rule vocabulary elements or rule templates. New/modified business rules can be “Updated” from Rule Team server to Rule Studio The Synchronization process is supported by a Synchronization perspective within the Eclipse environment, allowing selective viewing and validation of synchronization operations. Executable rulesets can be deployed to a target Rule Execution Server (RES) environment from either Rule Studio or Rule Team Server (with appropriate permission levels). Deployment can be a “hot-deploy”, where the ruleset is updated immediately within the RES, or it can be a staged deployment where executable rulesets are first persisted in an archive within a file system, and then later deployed to the RES. Developer View Projects are file-based One copy per developer SCC used for Version Management, Content Sharing, Conflict Resolution Primary Worksite is Eclipse-based Rule Studio (Java Development, Rule Modeling, Rule Authoring, Deployment, Test Execution) Business User View Projects are repository based All users work on common copy Repository handles Versioning and Multi-User Concurrency Rule Team Server is Primary Worksite (Authoring, Querying / Reporting, Management) Synchronization Between Rule Studio and Rule Team Server Initiated / Controlled by Rule Studio Use Cases Initial Rule Team Server project creation Update from Team Server to Rule Studio Commit from Rule Studio to Team Server Copy/merge from one Team Server repository to another
Rule Studio is an Eclipse-based environment dedicated mostly for the Developers and rule authors having some deeper technical skills. From Studio, Developers are able to create rule applications including some rule authoring, project sharing, debugging and testing, as well as to set up the business user environment in the Rule Team Server.
A Ruleflow allows breaking up rule execution into a set of “ruletasks” with defined transitions between ruletasks. Transitions can be conditional. There are two main reasons for segmenting rule execution in this way: It can make rule authoring more straightforward if it is known that the subset of rules in one task will be executed before or after the subset of rules in another task. For example, an upstream ruletask can define some intermediate concepts which are then referenced in downstream ruletasks. Performance: while a given ruletask is executing, only the specific rules in that ruletask are evaluated by the rule engine for possible execution, reducing computational effort. Business Object Models are the basis for creating a Rule Vocabulary, which provides the building blocks for rule authoring by business users. Rule Templates are partially-completed business rules. Portions of the template can be “frozen” such that they can’t be modified by rule authors. This enables both control and ease of use.
JRules supports 4 primary types of graphical rule editors: Natural Language Guided Editor Point-and-click on tokens within predefined rule templates and select from dropdown lists of readable phrases Decision Tables View/edit groups of rules in a tabular form Decision Trees View/edit groups of rules with a graphical flowchart-style decision tree editor Text Editor Type the text of rules with “Intellirule” context-sensitive assistance
Rule Studio is an Eclipse-based environment dedicated mostly for the Developers and rule authors having some deeper technical skills. From Studio, Developers are able to create rule applications including some rule authoring, project sharing, debugging and testing, as well as to set up the business user environment in the Rule Team Server.
The Rule Execution Server (RES) environment consists of: An Execution Unit (XU) packaged as a J2EE Connector Architecture (JCA) resource adapter. A JMX-compliant management stack including an out-of-the-box RES Console web application A set of execution components which form the interface to the Execution Unit Stateless/Stateful Session EJBs JMS Messaging endpoints (MDBs) Web Service interface Plain Old Java Object (POJO) interface The RES can be deployed in J2EE or J2SE mode: J2EE mode: leverages the app server for resource pooling, transaction awareness, security, clustering J2SE mode: RES deployed as a set of embedded Java classes within an application Both J2EE and J2SE mode support hot-deployment of rulesets, management/monitoring via JMX, ruleset pooling J2SE mode is primarily used for rule execution within a J2SE application, within a Web/Servlet container such as Tomcat, or within a non-standard J2EE app server for which JRules does not supply out-of-the-box J2EE deployment archives. Rules are deployed from the Rule Management environment to a Rule Execution Server (RES) environment in executable chunks called “Rulesets”. Rulesets are named and versioned components which are the entry points for rule execution. Each Ruleset has well-defined set of input and output parameters which can be primitive data types or complex objects. Applications execute rules by referencing the appropriate deployed Ruleset by name, passing in the defined input parameter data and receiving the defined output parameter data as a response. For deployment, Rulesets are grouped into bundles called RuleApps which are logical groupings of rulesets that typically share underlying objects models. RuleApps can be deployed from either Rule Studio or Rule Team Server. A deployed RuleApp is persisted in the RES environment either in a RDBMS or as a set of files in the file system. Deployed RuleApps and Rulesets can be inspected and managed via the JMX-compliant management stack. RuleApp deployment can be automated via out-of-the-box Ant tasks or via JMS APIs. Also, RuleApps can be exported/imported as archive bundles (*.jar files).
Rule Studio is an Eclipse-based environment dedicated mostly for the Developers and rule authors having some deeper technical skills. From Studio, Developers are able to create rule applications including some rule authoring, project sharing, debugging and testing, as well as to set up the business user environment in the Rule Team Server.
ILOG rule engine leverage multiple algorithm to execute rules. At the engine API, the client code, insert object in working memory, fire rules, and get results. The method calls are synchronous. The rule set execution can be tailored by a rule flow, which can be seen as a business process, with tasks that are only group of rule and directives to execute them. The RETE algorithm is used to infer new facts and reevaluate the rule candidate for execution.
Rule Team Server (RTS) includes the concept of roles and permissions, defining what user roles have create/read/update/delete permissions on various rule project elements. Users and roles are managed by the host J2EE application server, while rule project security is managed within RTS by users with RTS administrator rights. For a given rule repository any number of “baselines” can be defined, which are snapshots at a point in time. Baselines can be used for comparison and rollback. Executable rulesets can be deployed to target execution environments, either as a “hot-deploy” directly to a running Rule Execution Server or as a staged deployment in which an intermediate ruleset archive file is generated. The Rule Execution Server provides a JMX-compliant management and monitoring interface allowing use of standard J2EE monitoring tools such as Tivoli. JRules includes an out-of-the-box RES Console application for managing and monitoring ruleset execution. *** CAN iLOG RUN IN WebSphere Portal Server??
JRules provides a tight integration with WPS via the following components: ILOG JRules SCA Component : A standard SCA deployment that complements IBM's framework. The SCA component allows an Integration Developer to access a decision service without any detailed knowledge of ILOG JRules. The SCA component is a façade interface to the underlying JRules Rule Execution Server components. ILOG JRules WID plug-in : A plug-in for WebSphere Integration Developer that generates an SCA component from ILOG JRules artifacts. ILOG JRules CEI Event Source : Enables an integrated audit trail through CEI. The JRules rule execution component is able to send information to a CEI Server from where applications can subscribe to particular types of events or query historical event information. Event information can be coarse-grained, such as when a particular ruleset was executed, to fine-grained, such as which specific rules fired within the execution of a ruleset and how data objects were modified as a result of rule execution.
The JRules WID plug-in generates an SCA component from a JRules RuleApp, the SCA component contains a strongly-typed ruleset execution operation for each Ruleset within the RuleApp. Rulesets within JRules have a well-defined input/output signature that is used to generate the corresponding ruleset execution signature within the SCA component. Once the SCA component is created, and integration developer can invoke rulesets from within a WPS process without requiring knowledge about the underlying business rule implementation.