ILOG JRules enables you to deploy and execute rules natively on both the Java platform (see Deployment on Java Platforms) and the.NET platform (see Deployment to .NET). This section describes the different platforms, and how they operate.
Deployment on Java Platforms
The integration scenarios for deploying a business rule application with ILOG JRules are as follows:
-
The rule engine is embedded in your J2SE application using the APIs provided, and the rules are managed in a ruleset, which must be retrieved and passed to the rule engine. In this scenario, you use ruleset deployment to deploy or update the rules. You would use this scenario if you require fine control of the rule engine through its API and you are developing your business rule application on J2SE.
The workflow for this scenario is:
-
You use Rule Execution Server to execute rulesets packaged in RuleApps in either J2SE or J2EE. In this scenario, RuleApp deployment is the main method used to deploy or update the rules. Rule Execution Server offers many services in addition to rule execution. This is the recommended scenario for a J2EE platform.
The workflow in a Rule Execution Server scenario can be:
-
Ruleset invocation in J2SE or J2EE:
-
Ruleset invocation in J2EE:
The first scenario requires some
build.xml file execution to deploy the RuleApp.
| Note |
Rule projects contain references to a Java or XSD Execution Object Model (XOM). When a ruleset archive is extracted from a rule project it only contains the XSD (dynamic) XOM. The .xom file is not required for a RuleApp using a Java XOM, as it can be inferred automatically from the classes available in the class path of your application. Java XOM objects that rules act on have to be deployed independently. To run an application that uses a Java XOM, you therefore need to deploy your RuleApp and your Java code in two separate steps. You deploy your application using standard tools such as: an IDE, Ant scripts, or an application server console.
|
After the business rule application has been deployed, business policy changes drive updates to the rules and determine an enterprise strategy for ruleset (re)deployment.
Rule Execution Server enables you to modify and manage business rules at runtime. The Rule Execution Server Console is a change management tool that can be used by system administrators, developers or business analysts to quickly and easily implement changes in business requirements. Such changes can be uploaded to the rule engine and changes can be made while the application is running.
The following table shows the possible management operations and the environment in which they can be performed:
Table Management Operations
Entity Operations |
Edited by |
|---|
RuleApp |
Create |
Rule Execution Server Console, Rule Studio, Rule Team Server, Ant Task, API. |
Modify |
Rule Execution Server Console, Rule Team Server, Ant Task, API. |
Remove |
Rule Execution Server Console, Ant Task, API. |
Get RuleApp Archive |
Rule Execution Server Console, Ant Task, API. |
Rulesets |
Create |
Rule Execution Server Console, Rule Studio, Rule Team Server, Ant Task, API. |
Modify (change ruleset archives, and properties) |
Rule Execution Server Console, Rule Team Server, Ant Task, API. |
Enable/Disable |
Rule Execution Server Console, Rule Team Server, API. |
Remove |
Rule Execution Server Console, Ant Task, API. |
Server |
Archive all RuleApps |
Rule Execution Server Console, Ant Task, API. |
| Note |
| All managed entities are versioned.
|
Deployment to .NET
ILOG JRules provides tools that enable you to run rule applications in .NET using ruleset archives developed in Rule Studio. You remap the Business Object Model (BOM) created in Rule Studio into a version that can be loaded and used in .NET. Different users can then write and manage rules using Rule Studio or Rule Team Server, in the normal way, and developers can deploy and execute the same rules natively on both the Java and .NET platforms.
The following diagram shows the workflow for deploying JRules to .NET:
The numbers in the figure correspond to the numbers in the following list:
-
In JRules, you use a rule project in Rule Studio to generate the ruleset archive containing the BOM.
-
On the .NET side, you provide a .NET Execution Object Model (XOM) as input for remapping the JRules BOM, using the BOM to XOM (B2X) Mapping tool.
-
If you want, you can generate the BOM to XOM mapping (an XML file) separately. This file can be used for reediting by the B2X Mapping tool, or as input to the Packager tool.
-
The Ruleset Archive Assembly Packager, a command-line tool, accepts as input a BOM to XOM file. Using the JRules .NET Rule Engine Assembly, it outputs a deployable .NET DLL.
-
The B2X Mapping tool outputs a deployable .NET DLL, internally calling the Ruleset Archive Assembly Packager tool for packaging. Unless you require specialized settings by the Packager tool, this provides the most direct way of generating a deployable DLL.
-
The Ruleset Archive Assembly can then be deployed as an application that embeds the .NET rule engine.
JRules provides tools, scripts and .NET assemblies to support this new deployment scenario (shown in yellow in the above diagram). They are stored in the <InstallDir>/jrules2dotnet directory and include:
-
The B2X GUI Mapping tool, which enables you to remap BOMs in ruleset archives.
-
The Ruleset Archive Assembly Packager tool, which enables you to create deployable ruleset DLLs (Ruleset Assemblies) for execution by the JRules .NET rule engine.
-
The JRules .NET Rule Engine Assembly. This contains two assemblies, and enables you to embed the engine in your .NET application. The reference documentation for this library is provided as an installer that enables you to install and view it in Visual Studio 2005.
The Java XOM that the ruleset uses must have an equivalent .NET XOM. You will need to translate it to your .NET language.
Using this feature, you can now deploy the same rules to both Java and .NET business rule applications, with native execution on both platforms using the JRules Rule Engine (native Java) and the JRules .NET Rule Engine (native C#).
Related Sections
Related Concepts
Related Tasks
Related Reference
Related Samples and Tutorials
