Overview: BOM and execution object model (XOM)
The XOM is the model used to execute the rules.
You can build the XOM from different data sources: Java™, XML, COBOL, PL/I, or .NET.
The execution object model (XOM) is the model against which you run rules. It references the application objects and data, and is the base implementation of the business object model (BOM). Rule projects reference the XOM.
Through the XOM, the rule engine can access application objects and methods, which can be Java objects, XML data, or data from other sources. At run time, rules that were written against the BOM are run against the XOM.
Every BOM element (business element) must have a corresponding XOM element (execution element). The correspondence between execution elements and business elements does not need to be one-to-one. If a business element originates from an execution element, you do not need to specify an explicit mapping. If a business element does not originate from an execution element, you must specify a BOM-to-XOM mapping.
Some internal rules exist for the implicit BOM-to-XOM mapping when you generate a BOM from a XOM. For example, a BOM class is implicitly mapped to a XOM class of the same name.
Designing a BOM for a Java model
When your data model is in Java, you can generate a BOM directly from this Java Execution Object Model (XOM), see Mapping of a BOM created from a Java XOM. You can use XOM annotations to configure BOM generation, see XOM annotations. If you want to extend the BOM with business classes and methods, you can then map these business elements to XOM elements using BOM-to-XOM mapping in the BOM Editor. You have two means of specifying BOM-to-XOM mapping: extender mapping or IRL mapping, see Rule language and extender mapping. Business users can then author business rules without having to worry about the underlying data types and platform.
At deployment time, if your application is a Java or web application, then the Java XOM is packaged into the application and there are no specific deployment steps you need to take for the XOM. You package the rules and BOM-to-XOM mapping definition into a ruleset archive, which is then available to your calling application through the rule runtime, Rule Execution Server, see Overview: Deployment options.
If you do not have a Java or web calling application, either because you want to deploy to a testing server for Decision Validation Services, or because you want to expose your rules as a Hosted Transparent Decision Service (HTDS), then you must deploy the Java XOM to the Rule Execution Server database (see Deploying the XOM).
When you test and simulate rule execution, the Scenario Service Provider (SSP) accesses Rule Execution Server for execution, and Rule Execution Server retrieves the XOM from the database (see Making the XOM accessible by deploying the XOM).
When you generate a HTDS, Rule Execution Server retrieves the XOM from the database in the same way (see Downloading a HTDS WSDL file).
Designing a BOM for an XML model
When your data model is in XML, you can generate a BOM directly from this Dynamic XOM, see Overview: Dynamic execution object model (XOM) and Built-in simple types. If you want to extend the BOM with business classes and methods, you can then map these business elements to XOM elements using BOM-to-XOM mapping in the BOM Editor. You specify this mapping with IRL mapping, see Rule language and extender mapping. Business users can then author business rules without having to worry about the underlying data types and platform.
At deployment time, the Dynamic XOM and BOM-to-XOM mapping files are packaged with the rules in the ruleset archive, which is then available to your calling application through the rule runtime, Rule Execution Server.
Designing a BOM for a COBOL model
When your data model is in COBOL, you generate a COBOL XOM from a COBOL copybook. For more information, see Generating a COBOL XOM. This COBOL XOM is made of a Java project for the XOM.
You generate a BOM from the COBOL XOM. Business users can then author business rules without having to worry about the underlying data types and platform, however there are some limitations that you must be aware of (see Rule authoring for COBOL compatibility).
If you use Decision Server for z/OS® and plan to deploy your rules to zRule Execution Server for z/OS, you map business methods to COBOL XOM elements using BOM-to-XOM mapping in the BOM Editor. At deployment time, you deploy the COBOL XOM, the marshaller, and the RuleApp, which are then available to your calling application through the zRule Execution Server for z/OS runtime (see Deploying RuleApps and XOMs).
Designing a BOM for a PL/I model
When your data model is in PL/I, you generate a PL/I XOM from a PL/I include file (see Generating a PL/I XOM). This PL/I XOM is made of a Java project for the XOM.
You generate a BOM from the PL/I XOM. Business users can then author business rules without having to worry about the underlying data types and platform.
When you use Decision Server for z/OS and plan to deploy your rules to zRule Execution Server for z/OS, you map business methods to PL/I XOM elements by using BOM-to-XOM mapping in the BOM Editor. At deployment time, you deploy the PL/I XOM, the marshaller, and the RuleApp, which are then available to your calling application through the zRule Execution Server for z/OS run time (see Deploying RuleApps and XOMs).
