 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 94: JavaTM Rule Engine API
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 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: 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. |
