Java开发网 - a new domain for java developement----Rule Engine

Topic: a new domain for java developement----Rule Engine

1.a new domain for java developement----Rule Engine

Posted by: tier3
Posted on: 2002-09-11 09:12

http://www.jcp.org/jsr/detail/094.prt

Printed: Sep 10, 2002
From: http://www.jcp.org/jsr/detail/094.prt

Standard Format

--------------------------------------------------------------------------------

JSRs: Java Specification Requests

Detail

JSR 94
JavaTM Rule Engine API

This specification defines a Java runtime API for rule engines.

Specification Lead
Alex Toussaint
BEA Systems

Expert Group
Art Technology Group Inc.(ATG) BEA Systems
Blaze Software Fujitsu Limited
IBM ILOG
Oracle Silverstream Software
Unisys

Private Expert Group homepage

Status
Public Review 11 Sep, 2002
Community Draft Ballot 19 Feb, 2002
Community Review 19 Feb, 2002
Expert Group Formation 19 Dec, 2000
JSR Review Ballot 27 Nov, 2000

Java Community Process version in use: 2.1

Please direct your comments on this JSR to jsr-94-comments@jcp.org

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 Big Smile

oug Dew

E-Mail Address:ddew@bea.com

Telephone Number:+1 720 565 6543

Fax Number:+1 720 565 6501

Specification Lead Big Smile

oug 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.





Introduction | JSRs | What's New | Participation
JCP Procedures | Press & Success | Community Resources

Site sponsored and powered by Sun Microsystems
Copyright © 1995-2002. All Rights Reserved.
Terms of Use. Privacy Policy.