Find JSRs
Submit this Search


Ad Banner
 
 
 
 

Summary  |  Proposal  |  Detail (Summary & Proposal)
JSRs: Java Specification Requests
JSR 94: JavaTM Rule Engine API

Stage Access Start Finish
Final Release Download page 04 Aug, 2004  
Final Approval Ballot View results 25 Nov, 2003 08 Dec, 2003
Proposed Final Draft Download page 29 Oct, 2003  
Public Review Download page 12 Aug, 2002 11 Sep, 2002
Community Draft Ballot View results 12 Feb, 2002 19 Feb, 2002
Community Review Login page 19 Dec, 2001 19 Feb, 2002
Expert Group Formation   28 Nov, 2000 19 Dec, 2000
JSR Review Ballot View results 14 Nov, 2000 27 Nov, 2000
Status: Final
JCP version in use: 2.1
Java Specification Participation Agreement version in use: 1.0


Description:
This specification defines a Java runtime API for rule engines.

Please direct comments on this JSR to the Spec Lead(s)
Team

Specification Leads
  Daniel Selman ILOG
Expert Group
  Art Technology Group Inc.(ATG) Fujitsu Limited ILOG
  Oracle

Update to the Java Specification Request (JSR)

The Spec Lead submitted the following updated version of the Original JSR on December 5, 2000.

Identification | Request | Contributions

Section 1: Identification
Initial Expert Group Membership:
(Please provide company or organization names. Note that expert group members must have signed the JSPA.)

Art Technology Group

BEA Systems

Blaze Software

ILOG

SilverStream Software

Unisys



Section 2: Request

2.1 Please describe the proposed Specification:

This specification defines a Java runtime api for rule engines.

The api prescribes a set of fundamental rule engine operations. The set of operations is based upon the assumption that most clients will need to be able to execute a basic multi-step rule engine cycle, which consists of parsing rules, adding objects to an engine, firing rules and getting resultant objects from the engine. The set of operations also supports variations of the basic cycle, particularly variations that would occur in J2EE server deployments.

A primary input to a rule engine is a collection of rules called a ruleset. The rules in a ruleset are expressed in a rule language. This specification defines generic api support for parsing rulesets, but does not define a rule language standard.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

This specification targets the J2EE and J2SE platforms.

2.3 What need of the Java community will be addressed by the proposed specification?

This specification addresses the community need to reduce the cost associated with incorporating business logic within applications and the community need to reduce the cost associated with implementing platform-level business logic tools and services.

2.4 Why isn't this need met by existing specifications?

No standard specifications exist that address this need.

Dissimilar vendor-specific api specifications exist. However, the differences between these specifications are significant enough to cause costly difficulties for application builders and platform vendors.

2.5 Please give a short description of the underlying technology or technologies:

The key underlying technology is the rule engine. A rule engine may be viewed as a sophisticated if/then statement interpreter. The if/then statements that are interpreted are called rules. The "if" portions of rules contain conditions such as "shoppingCart.totalAmount > $100". The "then" portions of rules contain actions such as "recommendDiscount(5%)". The inputs to a rule engine are a ruleset and some data objects. The outputs from a rule engine are determined by the inputs and may include the originally inputted data objects with possible modifications, new data objects and side effects such as "sendMail('Thank you for shopping')."

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

javax.rules

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No

2.8 Are there any security issues that cannot be addressed by the current security model?

No

2.9 Are there any internationalization or localization issues?

No

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No

2.11 Please describe the anticipated schedule for the development of this specification.

Community Draft submitted to PMO: October 1, 2001

Public Draft submitted to PMO: January 3, 2002

Proposed Final Draft submitted to PMO: March 4, 2002BR>


Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

[1] "RETE: a fast algorithm for the many pattern/many object pattern match problem", Artificial Intelligence, volume 19, number 1, 1982, C.L. Forgy

[2] Business Rules for Electronic Commerce: Project at IBM T.J. Watson Research

[3] Jess, The Java Expert System Shell

3.2 Explanation of how these items might be used as a starting point for the work.

[1] Provides useful background information about the RETE algorithm that is at the heart of several rule engine implementations.

[2] Provides useful background information.

[3] JESS is a rule engine and scripting environment written entirely in Sun's Java language by Ernest Friedman-Hill at Sandia National Laboratories in Livermore, CA. JESS can be licensed free of charge for academic use.

Section 4: Additional Information

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

This specification assumes the existence of a parallel effort to specify an open, xml-based rule language. There is a need for standardization at both the API and the rule language level. The RuleML initiative (http://www.dfki.uni-kl.de/ruleml/) is making important steps towards this common, but distinct, goal.








Original Java Specification Request (JSR)

(NOTE that this JSR has been updated since the original posting.

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member:BEA Systems, Inc.

Name of Contact Person:Doug Dew

E-Mail Address:ddew@bea.com

Telephone Number:+1 720 565 6543

Fax Number:+1 720 565 6501


Specification Lead:Doug Dew

E-Mail Address:ddew@bea.com

Telephone Number:+1 720 565 6543

Fax Number:+1 720 565 6501


Initial Expert Group Membership:
(Please provide company or organization names. Note that expert group members must have signed the JSPA.)

BEA Systems, Inc.

ILOG, Inc.



Section 2: Request

2.1 Please describe the proposed Specification:

This specification defines a Java runtime api for rule engines.

The api prescribes an object model and a set of fundamental rule engine operations. The object model and set of operations are based upon the assumption that most clients will need to be able to execute a basic multi-step rule engine cycle, which consists of parsing rules, adding objects to an engine, firing rules and getting resultant objects from the engine. The object model and the set of operations also support variations of the basic cycle, particularly variations that would occur in J2EE server deployments.

A primary input to a rule engine is a collection of rules called a ruleset. The rules in a ruleset are expressed in a rule language. This specification defines api support for parsing rulesets that have been authored in vendor-specific rule languages. Additionally, to help simplify the task of creating rule-authoring tools and because business-to-business exchange of rules is anticipated, this specification defines api support for parsing rulesets that have been authored in xml-based, vendor-independent rule languages.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

This specification targets the J2EE and J2SE platforms.

2.3 What need of the Java community will be addressed by the proposed specification?

This specification addresses the community need to reduce the cost associated with incorporating business logic within applications and the community need to reduce the cost associated with implementing platform-level business logic tools and services. Additionally, this specification is part of a larger effort to enable business-to-business exchange and processing of rules.

2.4 Why isn't this need met by existing specifications?

No standard specifications exist that address this need.

Dissimilar vendor-specific api specifications exist. However, the differences between these specifications are significant enough to cause costly difficulties for application builders and platform vendors.

2.5 Please give a short description of the underlying technology or technologies:

The key underlying technology is the rule engine. A rule engine may be viewed as a sophisticated if/then statement interpreter. The if/then statements that are interpreted are called rules. The "if" portions of rules contain conditions such as "shoppingCart.totalAmount > $100". The "then" portions of rules contain actions such as "recommendDiscount(5%)". The inputs to a rule engine are a ruleset and some data objects. The outputs from a rule engine are determined by the inputs and may include the originally inputted data objects with possible modifications, new data objects and side effects such as "sendMail('Thank you for shopping')."

Some rule engines are implementations of the RETE algorithm. The distinguishing feature of this algorithm is its support for efficient data object-driven rule selection.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

javax.rules

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No

2.8 Are there any security issues that cannot be addressed by the current security model?

No

2.9 Are there any internationalization or localization issues?

No

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No

2.11 Please describe the anticipated schedule for the development of this specification.

Community Draft submitted to PMO: October 1, 2001

Public Draft submitted to PMO: January 3, 2002

Proposed Final Draft submitted to PMO: March 4, 2002

(NOTE that this JSR has been updated since the original posting.



Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

[1] "RETE: a fast algorithm for the many pattern/many object pattern match problem", Artificial Intelligence, volume 19, number 1, 1982, C.L. Forgy

[2] Business Rules for Electronic Commerce: Project at IBM T.J. Watson Research

[3] Jess, The Java Expert System Shell

3.2 Explanation of how these items might be used as a starting point for the work.

[1] Provides useful background information about the RETE algorithm that is at the heart of several rule engine implementations.

[2] Provides useful background information.

[3] A Java-based, open source implementation of the RETE algorithm.

(NOTE that this JSR has been updated since the original posting.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

This specification assumes the existence of a parallel effort to specify an open, xml-based rule language. The result of this effort will be an XML Schema that will be registered at a site such as xml.org.

(NOTE that this JSR has been updated since the original posting.