Skip Headers
Oracle® Fusion Middleware User's Guide for Oracle Business Rules
11g Release 1 (11.1.1.6.3)

Part Number E10228-11
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

11 Working with Decision Components in SOA Applications

This chapter discusses the Decision components that support Oracle Business Rules. It also covers how to use a Decision component as a mechanism for publishing rules and rulesets as a reusable service that can be invoked from multiple business processes.

A Decision Component is a SCA component that can be used within a composite and wired to a BPEL component. Apart from that, Decision Components are used for dynamic routing capability of Mediator and Advanced Routing Rules in Human Workflow.

This chapter includes the following sections:

11.1 Introduction to Decision Components

A Decision component is a Web service that wraps a rule session to the underlying decision function.

A Decision component consists of the following:

11.2 Working with a Decision Component

Using Oracle JDeveloper with Rules Designer these tools automatically generate all required metadata and WSDL operations. The Decision component can be integrated into an SOA composite application in the following ways:

This integration provides the following benefits:

11.2.1 Working with Decision Component Metadata

A Decision component is defined by the following files:

Typically, Oracle JDeveloper generates and maintains these files.

11.2.1.1 Decision Service Metadata (.decs) File

Every Decision component within a composite comprises one business rule metadata file. The business rule metadata file provides information about the location of the component business rule dictionary and the Decision Services exposed by the Decision component.

One Decision component might expose one or more Decision Services. For example a CreditRating Decision component might expose two services, CheckEligibility and CalculateCreditRating.In Oracle Fusion Middleware 11g Release 1 (11.1.1), the Decision Service metadata comprises the decision function name that is being exposed as a Web service. For projects that are migrated from older releases of Oracle SOA Suite, the Decision Service metadata typically has more information depending on the interaction pattern used in 10.1.3.x.

The business rule metadata file (business_rule_name.decs) defines the contract between the components involved in the interaction of the business rule with the design time and back-end Oracle Rules Engine.

This file is in the SOA Content area of the Application Navigator in Oracle JDeveloper for your SOA composite application. Table 11-1 describes the top-level elements in the Decision service .decs file.

Table 11-1 Decision Metadata File (.decs) Top-level Elements

Element Description

ruleEngineProvider

The business_rule_name.decs file ruleEngineProvider element includes details about the rule dictionary to use:

<ruleEngineProvider name="OracleRulesSDK" provider="Oracle_11.0.0.0.0">
    <repository type="SCA-Archive">
        <path>AutoLoanComposite/oracle/rules/AutoLoanRules.rules</path>
    </repository>
</ruleEngineProvider>

The repository type is set to SCA-Archive for Decision components. This indicates that the rule dictionary is located in the service component architecture archive. The path is relative and interpreted differently by the following:

  • Design time — The path is prefixed with Oramds:/. Metadata service (MDS) APIs open the rule dictionary. Therefore, the full path to the dictionary is as follows:

    Oramds:/AutoLoanComposite/oracle/rules/AutoLoanRules.rules
    
  • Runtime (business rule service engine) — The business rule service engine uses the Oracle Business Rules SDK RuleRepository API to open the rule dictionary located in MDS. The composite name prefix, for example (AutoLoanComposite) is removed from the path and the metadata manager assumes the existence of oracle/rules/AutoLoanRules.rules relative to the composite home directory.

decisionService

A Decision service is a Web service (or SOA) enabler of business rules. It is a service in the sense of a Web service, thus opening the world of business rules to service-oriented architectures (SOA). In 11g Release 1 (11.1.1.6.3), a Decision service consists of metadata and a WSDL contract for the service.

The business_rule_name.decs file decisionService element defines the metadata that describes business rules exposed as a Web service.

In general, a Decision service includes the following elements:

  • Target namespace

  • Reference to the back-end Oracle Rules Engine (this is the link to the rule dictionary). Note that OracleRulesSDK is the reference name that matches the name of the Oracle Rules Engine provider in ruleEngineProvider element.

  • Name (CreditRatingService in the following example)

  • Additional information about the dictionary name and ruleset to use

  • List of supported operations (patterns)

Apart from the operations (patterns), the parameter types (or fact types) of operations are specified (and validated later at runtime). Therefore, every Decision service exposes a strongly-typed contract.


11.2.1.2 SCA Component Type (.componentType) File

An SCA business_rule_name.componentType file is included with each Decision component. This file lists the services exposed by the business rules service component. In the following sample, two services are exposed: CreditRatingService and LoanAdvisorService.

<?xml version="1.0" encoding="UTF-8" ?>
<!-- Generated by Oracle SOA Modeler version 1.0 at [5/24/07 9:27 AM]. -->
<componentType xmlns="http://xmlns.oracle.com/sca/1.0">
  <service name="CreditRatingService">
    <interface.wsdl
interface="http://xmlns.oracle.com/creditrating/Rating#wsdl.interface(IDecisionSer
vice)"/>
  </service>
  <service name="LoanAdvisorService">
    <interface.wsdl
interface="http://xmlns.oracle.com/loanoffer/Advisor#wsdl.interface(IDecisionServi
ce)"/>
  </service>
</componentType>

11.2.1.3 Decision Component Entry in composite.xml

An entry in composite.xml is created for a decision component. For example,

<component name="OracleRules1">
     <implementation.decision src="OracleRules1.decs"/>
</component>

The business rules service engine uses the information from this implementation type to process requests for the Service Engine. From an SCA perspective, a Decision Component is a new "implementation type".

11.2.2 Working with Decision Components that Expose a Decision Function

You can use a Decision service to expose an Oracle Business Rules Decision Function as a service. A decision function is a function that is configured declaratively, without using RL Language programming that you use to call rules from a Java EE application or from a BPEL process.

Example 11-1 shows a business_rule_name.decs file decisionServices element that defines the metadata for an Oracle Business Rules Decision Function exposed as a service.

Example 11-1 decisionService for Decision Function Execution

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<decisionServices xmlns="http://xmlns.oracle.com/bpel/rules" name="PurchaseItems">
    <ruleEngineProvider name="OracleRulesSDK" provider="Oracle_11.0.0.0.0">
        <repository type="SCA-Archive">
            <path>PurchasingSampleProject/oracle/rules/com/example/PurchaseItems.rules</path>
        </repository>
    </ruleEngineProvider>
    <decisionService targetNamespace="http://xmlns.oracle.com/PurchaseItems/PurchaseItems_DecisionService_ValidatePurchasesDF" 
ruleEngineProviderReference="OracleRulesSDK" name="PurchaseItems_DecisionService_ValidatePurchasesDF">
        <catalog>PurchaseItems</catalog>
        <pattern name="CallFunctionStateless">
            <arguments>
                <call>com.example.PurchaseItems.ValidatePurchasesDF</call>
            </arguments>
        </pattern>
        <pattern name="CallFunctionStateful">
            <arguments>
                <call>com.example.PurchaseItems.ValidatePurchasesDF</call>
            </arguments>
        </pattern>
    </decisionService>
</decisionServices>

In this case, the decision function ValidatePurchasesDF itself is specified entirely in the PurchaseItems.rules file.

For more information, see, Chapter 6, "Working with Decision Functions".

11.2.3 Using Stateful Interactions with a Decision Component

To provide a stateful Decision service you create a decision function and specify that the decision function is not stateless. To do so you deselect the Stateless checkbox in a decision function.

Note the following details about stateful interactions with a decision component (also see Figure 11-2):

  • Rule sessions from the cache and those from the pool are mutually exclusive:

    • The rule session pool is for simple, stateless interactions only

    • The rule session cache keeps the state of a rule session across Decision service requests

11.2.4 What You Need to Know About Stateful Interactions with Decision Components

A Decision Component running in a Business Rules service engine supports either stateful or stateless operation. The Reset Session (stateless) checkbox in the Create Business Rules dialog provides support for these two modes of operation.

When the Reset Session (stateless) checkbox selected, this indicates stateless operation.

When Reset Session (stateless) checkbox is unselected, the underlying Oracle Business Rules object is kept in memory of the Business Rules service engine at a separate location (so that it is not given back to the Rule Session Pool when the operation is finished). Only use stateful operation if you know you need this option (some errors can occur at runtime when using stateful operation and these errors could use a significant amount of service engine memory).

When Reset Session (stateless) checkbox is unselected, a subsequent use of the Decision component reuses the cached RuleSession object, with all its state information from the callFunctionStateful invocation, and then releases it back to the Rule Session pool after the callFunctionStateless operation is finished.

11.3 Decision Service Architecture

A Decision service consists only of the service description. All other artifacts are shared within a decision component as shown in Figure 11-1.

Figure 11-1 Decision Service Architecture

Description of Figure 11-1 follows
Description of "Figure 11-1 Decision Service Architecture"

The heart of runtime is the Decision service cache, which is organized in a tree structure. Every decision component owns a subtree of that cache (depending on the composite distinguished name (DN), component, and service name). In this regard, Decision services of a decision component share the following data:

Figure 11-2 shows how both stateless and stateful rule sessions interact with the rule session pool and how stateful rule sessions interact with the stateful rule session cache during a Decision service request.

Figure 11-2 Stateless and Stateful Rule Session Usage for a Decision Service Request

Description of Figure 11-2 follows
Description of "Figure 11-2 Stateless and Stateful Rule Session Usage for a Decision Service Request"