Posted by: tomdebevoise

Lexicon Enterprise, A leading provider of open source business rules management and business process management software is headquartered in Alexandria Virginia, Announces an Eclipse plugin for OpenLexicon See ww.lexiconenterprise.com
OpenLexicon is an open source business rules management system. Unlike other OpenSource Business Rules system, OpenLexicon uses a ‘code-free’ approach to business rules. OpenLexicon offers an innovative approach to publishing rules as a WebService. The eclipse plugin create WSDL’s and data types (.XSD’s) in the eclipse project of your choice. Again, without code.
OpenLexicon is an open-source business rules and business process management tool released under a modified Mozilla Software License. See ww.openlexicon.org
Lexicon Enterprise, Inc.

Posted by: mmouries

The specification for the Java Rule Engine API (JSR 94), developed through the Java Community Process (JCP) program, defines a Java runtime API for rule engines by providing a simple API to access a rule engine from a Java Platform.

Reading Dr. Qusay H. Mahmoud ’s article is a must if you want to integrate a rule-engine with a vendor-neutral Java interface.

Read the full article here:

http://java.sun.com/developer/technicalArticles/J2SE/JavaRule.html?feed=JSC

Posted by: Admin

Benoy Jose writes a nice overview article on the general structure of the JSR-94 API and its goals.

The most frustrating part of a project is change and the sad reality is that change is inevitable. I cannot think of any project that was built the way it was originally designed without any changes made to the original. The problem of change becomes more evident in complex projects involving a lot of business logic, which keeps changing based on external circumstances. Sometimes the business rules have changed even before the project goes into production causing untold, mass rework to accommodate the changes. A good example is the insurance industry, new laws or market economics force changes, which cannot be foreseen and planned for during design. The solution for a dynamic environment like the above is to have a rules engine. Rule engines allow the business users to change rules without affecting the overall running of an application. The rules are defined separately from the application, and the logic to deal with the rules is built in during design. The rule engine takes care of applying the rules and the associated actions on the rules.

Read the full article here: http://javaboutique.internet.com/tutorials/rules_engine/

Posted by: mazamaman

Bob Orchard is the author of FuzzyJess, the Java-based, fuzzy logic API extension to Jess, and a veteran of many expert systems projects. In this interview, he discusses the state of artificial intelligence (AI), expert systems (ES), and the richness of possibilities for Java developers to utilize his tools for building fuzzy rule-based expert systems.

You can read my article in DevX about Bob here:

For insight about Jess, see my earlier interview with Jess’s creator Dr. Ernest Friedman-Hill of Sandia National Labs: Jess Inventor Opines About Rule Engines and Java

Feedback and ratings from javarules.org members would be most appreciated!
Jason Morris,
Morris Technical Solutions.

Posted by: Admin

In a follow up to Manoj Kochhar’s great JSR-94 TODO list, Daniel Selman (JSR-94 Specification Lead and a fellow editor at javarules.org) writes some notes on where he thinks JSR-94 should go next.

Get involved, comment, criticize, influence!

What do you think the JCP should be doing to make using rules and rule engines easier for Java programmers@f3

Anyone with rule engine experience (user, implementor etc.) is very welcome to provide their perspective. The easiest way to register interest is to send an email with SUBSCRIBE in the subject line to javax.rules-request [@] javarules.org.

This article attempts to distill some of my current thoughts on
the evoution of JSR-94 the Java Rule Engine API. A picture is worth 1,000 words,
so here is some of the text below summarized in a diagram.

The Name!


The easiest thing to change about JSR-94 is the name. It has always
troubled me that “Java Rule Engine API”, while accurate, has a 0%
adoption rate. I suppose the JRE acronym is well and truly taken! I propose that
the next JSR should be called the “Java Rules Service” in the hope that
JRS will be adopted as the acronym, and we can move away from referring
to the standard by its JSR number. We would therefore be working on JRS
2.0.

The Problems


Basically, the specification is very loose. Defining a bunch of
interfaces and exceptions to invoke a black-box “rule engine” is not
particularly helpful. Of course much the same could be said for the JCA
specification, however there more detail is provided for
integrating with security, transaction, threading, deployment models
etc. JSR-94 barely defines what a rule engine is (this is a contentious
topic!) and can of course therefore not enter into the details of how
rules are constructed or manipulated, the effects of invoking rules,
binding of rules to the Java language or many other interesting topics.

Lack of a Standard Language


In my opinion the root problem is not the lack of a
standard rule
language, it is the lack of a standard execution semantic for rule
engines. Once a standard execution semantic exists (or perhaps indeed
multiple semantics for different types of engines), any number of rule
languages can be relatively easily created on top: XML-based languages
for interchange, Java-like languages
for programmers (or Java bindings), natural-language like formats for
business people etcetera. I should point out here that I am not particularly comfortable with using the term semantic in this context, so don’t hesitate to propose a better alternative!

The enabling technology required for rule language standardization is a
“virtual machine specification” for rule engines. This Virtual Rule Engine Specification (VRES) would be the
foundation upon which standard languages would sit and would ensure
that an “if xxx then yyy”
on one engine would execute the same way on
another engine. This is the point of a standard language in my view. In
addition I feel that a standard language should be defined by the
competent bodies, such as OASIS or the W3C for example. It is of course
interesting to note that the JCP has accepted the JSR for the Groovy
scripting language.

This is obviously a very ambitious goal but without such an effort I
cannot see how we can tackle the core of this hard problem. Java
has the JVM specification (and indeed multiple languages run on the
JVM), .NET has the ECMA/ISO-standards, C/C++ has ANSI etc. For
reference the ANSI standard for C is 500+ pages.

It would be interesting to debate how the VRES would in fact relate to Java. There may be demand for a
platform-neutral description, and then a binding to the Java language.

Vendor Implementations


There are now a number of implementation of JSR-94 (ILOG, Fair Isaac,
Drools, Jess, rules4j, YasuTech, Computer Associates etc.). My
impression from using a couple of them however is that interoperability
is probably of modest value. It would be very interesting to get all
the providers of compliant implementations into one room for a day to
compare and contrast the functionality of the implementations and the
ability to swap in and out implementations. It would also be a good
forum to share knowledge on the common, but unstandardized, features of
rule engines. I know that the SyncML and WedDAV groups do this for example, with
apparent success.

Lack of J2EE Support


The specification does not define a binding to J2EE, or provide any
management support for the rule engine. In my opinion, of the existing
J2EE artifacts a JCA Resource Adapter is the most suitable for
deploying a rule engine. By nature this can be a connected (stateful)
pooled interaction, and the specification defines contracts for
security,
transactions, pooling, deployment model etc. In my view the most
natural binding to J2EE is therefore the definition of a set of JCA CCI
level methods for a rule engine, and Stateful and Stateless EJBs. JCA
allows rule engines to be deployed as
Application Server scoped resources, rather than embedded within
individual stove-piped applications (an important benefit of the
business rules approach). Perhaps vendors might also choose to skip the
JCA option entirely, deploying just stateless and stateful EJBs. It
would also be interesting to consider a standard JSP tag library for
invoking a rule engine from the web-tier.

Standardized JMX MBeans would also be very useful to expose the management
model of the rule engine to management and performance monitoring tools.

It is also clear however that a lighter weight J2SE only API has value
(particularly for batch applications and Servlet containers), and that rule engine vendors
with limited interest in full-J2EE support should have the liberty to
implement just the J2SE APIs.

Next Steps


Step 1: Start to debate the next steps and open up the Expert
Group. Anyone with rule engine experience (user, implementor etc.) is very
welcome to provide their perspective. The easiest way to register
interest is to send an email with SUBSCRIBE in the subject line to
javax.rules-request [@] javarules.org.


Step 2: Hold a multi-day meeting. The meeting would allow the
group of experts to brainstorm together, look at other
implementations, talk about common problems, refine the process issues
for the JSR etc.


Step 3: Draft a JCP submission that sets out the goals for the JSR, if the expert group have a shared vision for evolution.

Credits


Thanks to the JSR-94 Expert Group, Manoj Kochhar and many others for their insightful observations. I’ve benefited greatly from their words of wisdom. Any opinions (and errors!) that remain are of course my own…

Posted by: Admin

The JCP has posted the final release of JSR-94 (“Java Rule Engine API”) to the web. The reference implementation (a Jess wrapper), Test Compatability Kit, specification document, API and JavaDoc are now available for download.

Posted by: manoj

The rule engine specification has been around for some months now with vendors gradually climbing on board to achieve compliance. The specification itself is a good first attempt to help define standard contracts for software that means many different things in the IT industry.

In this article I will discuss 18 features that I would like to see in the next version of the specification. All of these features are an attempt to help achieve the current goals of the JSR94 specification itself.

The list comes from my own recent experiences working with customers in the telecom, finance and retail industries. The projects had common themes of needing the ability to rapidly add new products or new criteria to a system and the desire of these real-time enterprises to respond rapidly to changing business environments.


Desirable Features For The New JSR94 Specification

The order below is not meant to be indicative of any priority:

1. The majority of customers want portable rules and rulesets. This means a standard rules language with standard semantics. Vendors should compete on features such as scalability, performance, tools etc. Customers should be able to switch between rule engines relatively easily with no changes to rules or the calling client code.

2. The ability to store rules in a persistent storage of the customer?‚?€™s choosing. This may be a relational database, an LDAP server, an XML database, an object database, a file system or something completely different. The Service Data Objects specification is aimed at this exact same requirement and mandating the use of this object-based API would allow portable storage and administration of rules.

3. Under certain conditions, we do not want certain rules within a ruleset to fire. A rule firing may depend on the results of rules with a higher salience. One could argue that this logic should reside in the rule itself but this would then tie the individual rules together. This logic should remain as a separate orthogonal aspect. I?‚?€™d also like to be able to execute a rule ?‚?€?instead of?‚?€? another rule ?‚?€“ similar to the way ?‚?€?instead of?‚?€? triggers work in Oracle and SQL Server databases.

4. Monitoring and management hooks into the rule engine. There are no standardised APIs for obtaining performance and tracing information. In particular, for before and after rule execution and ruleset execution.

5. Greater management and monitoring of the rule engine environment. Instrumentation could be enhanced by making rules, rulesets and other JSR94 objects into MBeans. This would also allow for a standard administration console for rule engines, and a standard deployment mechanism for a rules environment including the registration of rule execution sets.

6. The ability to specify the type of rule engine (forward chaining, backward chaining etc.).

7. The ability to configure the rule engine to use different algorithms for evaluation. Not all rule-engine applications require a refiring of rules once a fact has changed.

8. Compile-time validity of rules should be standardised and mandatory. Some rule engines allows you to write Java expressions in the XML descriptor for a ruleset. This is evaluated at run-time by the rule engine rather than at compile time. This may cause compile-time errors to occur at run-time. An analogy here is the precompiliation of JSPs option that application server vendors provide. Something standardised and similar for rule descriptors would be welcome.

9. The fact that my client code has to know that it is a J2EE application or a J2SE application that is being called has a bad smell about it. I?‚?€™d prefer if a client-side adapter could be loaded via an IoC pattern. The adapter would take care of the J2SE/J2EE specifics and provide a unified API.

10. The ability to specify JSR94 objects in UML. A UML profile for JSR94 defined objects would allow JSR94 objects to be modelled and documented in a standard fashion. Extensions to this include allowing rule logic to be specified in OCL and allowing relationships between objects and other UML artifacts to be constrained by JSR94 rules and rulesets.

11. Following on from the above point, products and criteria are often attached to rule execution sets. It would be useful to be able to model and generate rules and associate them with objects. UML is the current standard notation and a UML profile for rule engines would allow for rule engine objects to be defined in UML and then generated into code. This would increase productivity of rule development and maintenance and help achieve a good level of documentation. I have seen a number of projects where modelling rulesets and rules before implementing them has helped achieved a more flexible system closely aligned to the business needs. There is no reason why business rule development cannot be model driven.

12. Pluggable security model for ruleset execution and rule administration. Sometimes you want to execute and manage rulesets depending on the user?‚?€™s role. JAAS was recently added to the 1.4 J2SDK and would be a good fit.

13. The use of a RuleContext object to allow vendor-specific and application-specific properties to be passed around the rule engine. The RuleContext should also allow access to the working memory of the current session.

14. Higher-level business rules. There is normally a many-to-one or a many-to-many mapping of rules within a rule engine to business rules, mapping rules or presentation rules. This is currently constrained by the fact that there is no standard way that rulesets can contain other rulesets or rules. One feature I?‚?€™d like to see in the standardization of this is use of the composite pattern that would allow a better grouping where by a ruleset could contain rules and other rulesets. This would allow the definition of business-level groupings of logic.

15. Meta-data improvements. Think of the JDBC meta-data API and the power that it offers. JDBC, JDO, EJB, TopLink and Hibernate all make use of this API. Something similar for a rule engine would allow workflow engines, presentation frameworks, object-relational mapping frameworks etc. to build something similar on top of a rule engine.

16. The ability to execute a set of rules as if I was winding the clock back to a date in the past is a common business requirement as is the ability to report on what rules where executed for what products at a certain point in the past. This time-variance functionality is very useful particularly for industries that are heavily regulated or that need to back-date for example an order or a trade.

17. Testing a rule, a ruleset and a descriptor outside of the rule engine would increase developer productivity. The ability to use well-known mock objects to achieve this is desirable.

18. By their nature, rulesets and rules are read-mostly objects. A standard way to load-on-startup, refresh and lazily load these objects would help the run-time performance of a rule engine whilst ensuring portability.

Conclusion

As the Enterprise Java platform has matured, customers have started to demand higher-level services such as rule engines and workflow products be standardised around common API?‚?€™s with common semantics.

The first version of JSR94 specification was an attempt to bring consensus and standardisation within the vendor community. This has been difficult in an environment where the term ?‚?€?rule engine?‚?€? has many different meanings. The specification is now ready for its next-step and vendors will need to play-ball or be pushed to the side in order for the goals of the specification to be met.

The views I express in this article are my own vision of where I would like to see the JSR94 specification go to in its next release.

About the author

Manoj Kochhar is a freelance Java developer and architect. He has been working with Java since 1995 and architected one of the world’s first commercial large scale Java applications in 1995 whilst working for Oracle. He has been caught by the Java fever ever since. You can reach Manoj at m@joxo.co.uk. He lives and works in London, England.

Posted by: dbarnett

As of Drools 2.0-beta-17, Drools (http://drools.org) is a fully JSR-94 compliant rule engine, according to self-certification done using JSR-94 TCK v1.1.

For instructions on how to run Drools under the JSR-94 Technology Compatibility Kit (TCK) and determine for yourself just how compliant Drools is, please see the Drools JSR-94 TCK Tutorial located on the Drools website.

Posted by: admin

What is it?

JSR-94 – “The Java Rule Engine API” – is a standard defined through the Java Community Process. It describes a set of simple interfaces for interacting with a rule engine using the Java programming language. The interfaces encompass simple execution, some metadata functionality and administration functionality such as deployment.

The standard is very high-level and does not define the semantics of execution or a rule language. If you are looking for an analogy you could consider it to be somewhere in between Java Connector Architecture CCI and JDBC.

To join the discussion list please send an email to javax.rules-request [at] javarules.org with SUBSCRIBE in the subject line.

Specification

• Read the specification
• Download the specification from the JCP.