HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML

Over the last two decades rules have become an increasingly important part of the information technology landscape. In fact, deductive rules have been applied to databases since the inception of SQL and form the basis of policy management and decision making at most corporations. However, the rules are changing. A newer reactive rules solution based on events, conditions, and action (ECA) has come to the foreground.

In addition, the rise of the Java runtime and development environment from a niche solution to prime time is also changing the rules of the information technology landscape. With Java as the core technology for embedded and enterprise applications, rules are an ideal means for businesses to harness the power of the language for a competitive advantage.

This article examines both types of rules, deductive and reactive, shows when and how to apply them, and explains how rules can work together to provide a more effective semantic integration solution. It also examines the different uses of rules and applies rule technology to J2ME for desktop applications and J2EE for enterprise applications.

This article looks at the use of rules for managing personal workflow, business transactions, and Web content in J2ME, J2EE, and JSP environments, respectively. It also covers the application of rules to B2B, customer relationship management (CRM), and supply chain management (SCM) applications.

An Overview of Rules
According to the authoritative business report, GUIDE Business Rule Project (1995), a business rule is "a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business."

As rules have become an increasingly important aspect of the management of the IT landscape, this article examines the need for rules using a financial services example and looking at the different rules and how they can be applied to business-critical events in financial services. In the past, application builders have embedded the fundamental business-processing rules directly into application code. This led to an explosion of new applications when applications became too unwieldy and inflexible to meet business needs. It also led to an increase in maintenance as applications were modified to incorporate the necessary changes. This is more apparent in financial services where regulatory requirements and the personalization necessary to keep or gain market share are critical business factors.

Many systems have been written and rewritten trying to keep up with the changes. Business requirements are changing faster than applications can be created and/or modified. Rules offer a way of encapsulating the business semantics and promoting them to the surface in the same way that databases enabled the separation of data from an application. The first attempts at doing this date back to E.F. Codd, the founder of relational databases.

Capturing the semantics, or gaining an understanding of what is really going on in terms business people can understand, is one of the challenges to rules-based solutions. Rules are not only for computers, people also use them for heuristic decision making. Many a trader monitors events from a desk, taking in news stories, price changes, trading behavior, current position, and even credit exposure information, then uses it to decide whether to buy or sell a particular financial instrument. The layman may think the decision is based on a "thumb-in-the-air" approach, but it's not. Experience and judgment are valuable assets in today's trading environments. No rule system can replace this, but it should be able to support it.

Managing events, bringing them together, and actively supporting the people who make the decisions is the primary goal of rules-based solutions. Rules enable us to capture the business semantics embedded in applications to support the decision-making processes in an organization. Businesses need to remain flexible so that the IT infrastructure can support complex real-time decision making.

Two Kinds of Rules - Deductive and Reactive
The deductive rule approach, which uses forward and backward reasoning, has been around for the last 20 years and was born from the artificial intelligence (AI) community. Deduction (or inferencing) is a means of deducing facts from an existing knowledge base. Unification is a technique that's commonly used to infer or deduce facts. A typical example follows:

  • Rule: A preferred customer is one who has spent more than $10,000 in the last month.
  • Fact: John Doe spent $11,000 last month.

    From the fact and the rule it's possible to deduce that John Doe is indeed a preferred customer. Another, more complex goal-oriented example is shown below:

  • Rule: x is the grandfather of z.
  • Implication: x is the father of y and y is the father of z.
  • Fact: Joe is the father of John.
  • Fact: John is the father of Fred.

    This form of reasoning is based on rules, implications, and facts. It's goal-oriented, allowing us to deduce that "Joe is the grandfather of Fred" by using unification over the rules, implications, and facts that exist in the knowledge base. This technique is one in which you attempt to prove conclusions. It allows reasoning to take place over unbound variables, which the ECA rules aren't well suited for.

    The Rete algorithm is one of the best-known algorithms for doing this. It builds up a treelike structure for the knowledge base and deduces facts efficiently (or proves conclusions) by evaluating only what is necessary. This saves enormous processing time and memory by targeting only those parts of the "tree" that need to be reevaluated against a conclusion. Typical systems based on this technique are Nisus Inc.'s Nisus rules engine, iLOG's JRules, and Brokat's Advisor/J.

    Reactive or ECA rules have been around for a shorter time; however, their heritage is in the definition of Sequel2 (from the article "Implementation of a Structured English Query Language," by Morton M. Astrahan and Donald D. Chamberlin) and their triggers are in programming language exception handling as far back as PL/1. In the 1990s, ECA rules were a fundamental component in active databases, and more recently in the semantic integration that underpins B2B and Web services.

    ECA rules are well suited to event-centric problems, which deal with change and how to manage it. In a database trigger, they might look for a deletion of a tuple from a department table, and as a consequence, delete all employees. In a more complex active database example they might look for the deletion of the same department tuple, but seek guidance on whether this is meant to be a department name change, transfer, or a downsizing based on departmental pruning. In the simple trigger case, the semantics of the deletion can't be modeled, but they can in the active database example.

    In the late 1990s, ECA rules started to leave the confines of the database transaction world and exist as agents of system-to-system workflow. In this context they've been used as rule agents to police business change. The rules help consolidate business events into business transactions and monitor business events to enable an enterprise to react in a more ad-hoc fashion, capturing some of the business heuristics that underpin modern business decision making.

    An example of a business transaction in a financial services setting is shown below:

    ON NewTrade EVENT FOLLOWED BY A SettledTrade EVENT WITHIN 5 MINS

    CONDITION NewTrade.id MATCHES SettledTrade.id AND
    NewTrade.amount EQUALS SettledTrade.amount
    ACTION PUBLISH "Trade settled fully"

    CONDITION NewTrade.id MATCHES SettledTrade.id AND
    NewTrade.amount GREATER SettledTrade.amount
    ACTION PUBLISH "Partial settlement"

    ON TimeOutException EVENT OF A SettledTrade
    ACTION PUBLISH "Trade failed to settle in time"

    In this example the rule is composed of a target event, the NewTrade, and followed by an event, the SettledTrade. The rule states that when a NewTrade and a matching SettledTrade are found and the amounts match for the two events, the trade is said to be fully settled. If, however, the amounts don't match, the trade is said to be partially settled. And if no matching SettledTrade event is found within 5 minutes, the trade is considered to have failed to settle in time. This is a fairly typical business-transaction monitor process that matches orders to confirmations, and models time relationships to do so. This same example is shown graphically in Figure 1.

    Figure 1
    Figure  1:

    ON NewTrade EVENT FOLLOWED BY AN ExposureChange EVENT WITHIN 30 MINS
    CONDITION NewTrade.longName EQUALS "Barclays Bank" AND
    ExposureChange.country.longName EQUALS "Guatemala" AND
    ExposureChange.limit/0.9 LESSTHAN ExposureChange.limit-
    ExposureChange.remaining
    ACTION CALL RiskMgmtSystem.Embargo("Mexico")

    A monitoring rule with flexible teeth is also shown. This rule looks for NewTrade events followed by ExposureChange events from a risk system. If the trade is for "Barclays Bank," the country of origin is "Guatemala," and only 10% of the allowable limit is left, all trades to "Mexico" are embargoed. Why would we want to do this? Simply, it's the management of the unpredictable that is one of the many benefits of ECA rules. It's the ability to juxtapose situations (in the form of events and conditions) and act on them (in the form of actions) that's critical to the ability of a business to react. This is what provides a competitive edge to the decision making within an organization. It allows the systems to support the users rather than force them to change their habits to work with the systems. An example of an ECA system that provides the basis for reactive rule specification in RuleML is SpiritSoft's SpiritIntellect.

    Rules and Java
    Java, especially with J2EE, has breathed new life into rules technology. Since last year two new Java Community Process (JCP) initiatives have started, JSR 87 and JSR 94, both of which have rules as their central component. As the shift has moved to Web services over a semantic Web, we've seen the rise of RuleML from W3C, the most mature of the rules initiatives. The fundamental reason for this is a drive to capture business semantics and to increase the scope for personalization. In both cases the initiatives are predicated on a desire to achieve a more semantic form of business integration in a B2B Web services context.

    The role of Java should not be underestimated. The ability to call Java code from within rules has led to a more fundamental integration story for rules technology. The role played by technologies such as EJB application servers, JSP, the JMS API, and XML have all contributed to the rise of rule-based technology as businesses look to differentiate their offerings. This has led the way in promoting personalization of offerings to customers through EJB and JSP technology, which allows users to be in control of policy decisions as they relate to applications at the user interface and business workflow levels.

    Since rules in a Java environment have been the focus for the last 12 months, we'll look at how rules can be used in different Java platforms with different Java technologies. Rules engines, along with many other systems, have suffered from integration problems with their surrounding environment. Java has made it possible for rules to dynamically call out to Java methods to incorporate flexibility into a system that has been lacking. To enable smoother and more cost-effective integration, the Java programming model and supporting environment makes it possible to introspect Java objects and classes while a program is running. This achieves a more dynamic integration between rules and Java, particularly if the rules engine or framework is written in Java.

    Rules and J2ME
    In a world where we're always connected, we need to ensure predictable results. By definition, a mobile environment inherently includes variability of the network and has limited bandwidth. New paradigms are required for transacting business that deals with decoupled, shareable business-transaction contexts and enables adaptable applications to be constructed.

    PocketWorkflow allows the user to configure mobile applications to be both adaptable - graying out options as changes to the effective Quality of Service (QoS) occurs - and transactional - by providing on-the-fly business transaction delegation. To do this, PocketWorkflow uses ECA rules to provide a framework for adaptability and for business transaction delegation, and uses deductive rules to deduce overall context while sifting through e-mail, voice, and other information sources.

    The marriage of deductive and ECA rules in this domain shows that each plays an important part in the overall solution. Taking advantage of the data-centric model of deductive rules applied over a knowledge base, it's possible and cost-effective to deduce short-term context, which can act as a filter to increase relevance to mobile devices and ensure that they're not swamped with irrelevant information. Leveraging the event-centric model of ECA rules, it's possible to provide user-centric, flexible PocketWorkflow to manage applications' adaptability to a changing environment and the business transactions that they participate in.

    Rules and J2EE
    In the world of J2EE, rules have been increasingly used to personalize applications. It has addressed two solution spaces to date, and with the advent of Web services, a new set of requirements arises.

    Existing requirements relate to validation and verification of data entry (e.g., orders) and the management of integrity constraints within EJB application servers. Newer, Web services-related requirements need to be met to ensure declarative privacy and digital rights management. Both of these are topics that have received much attention at W3C under Web services and the semantic Web.

    An architectural view of J2EE technology and rules is shown in Figure 2.

    Figure 2
    Figure  2:

    This architecture positions rules with respect to the requirements they need to meet and the technologies as they are today.

    Rules and JSP
    Rules have a natural role to play in JSP-based solutions. Being closer to the front of the application, they play an important role managing validation and verification issues as they relate to order entry and what you should be seeing. Validation and verification of order entry is best done nearer the user to prevent spurious server-related bottlenecks. Such validation and verification is best served if it can be flexible and personalized. Using a rule-based solution enables this to be done in a cost-effective manner.

    Ensuring the integrity of a form is something that deductive rules systems have long been used to. Once the form is filled in, ECA rules play a role in managing the business transaction. Further requirements that underpin what you might see can be driven through deductive rules and their ability to police digital right management and infer what you can see. In this role they play a key part in ensuring that the dynamically generated HTML pages are the correct ones, and that you see what you're entitled to see and nothing else.

    Rules and EJB
    Rules applied to an application server have been a hot topic for at least two JavaOne Conferences. Indeed, many users of EJB technology are using rules to add flexible integrity constraints through a specialized form of transaction-coupled ECA rules. Deductive rules are used to manage policy issues as they relate to what you can and cannot see, and the ECA rules further augment this by enabling the user of the technology to express how things should happen in a personalized context. In this way, a deductive rule might allow an application to understand who is a platinum, gold, silver, or bronze customer based on their service-level agreement, and supply this information to an ECA rule that determines which internal components are to be activated (e.g., maybe no credit checking is done for a platinum customer, maybe limited credit checking is done for gold, and so on).

    These policy decisions make the difference between services that are okay and those that are responsive to customer demands. They enable applications to be built that are flexible enough to take advantage of changing business models and therefore meet changing business requirements.

    Rules and JMS
    JMS is not an obvious place for rules to play a part. If we step back and look at workflow in the early 1990s, many of the workflow products that had their genesis at that time used asynchronous messaging techniques to act as a distribution channel for workflow events. In the early days of IBM's Flowmark (now MQWorkflow), an internal asynchronous messaging bus did all that MQSeries did. So JMS and event management as it relates to managing business events cries out for event-centric rule mechanisms to describe and manage the flow of events as they relate to business transactions and business processes.

    Event-centric rules are a natural way to express process flow between applications, services, and components. In a JMS context they provide a way to express process flow that's decoupled from the underlying application services. They extend and complement what can be achieved within a JSP and EJB environment by providing a distributed and highly scalable way to manage business transactions and sophisticated flexible monitoring facilities.

    Standards and Rules
    In this section we look at rules in the context of a number of standards initiatives. We cover JSR87 and the agent services initiative, JSR94 and the Java rules initiative, and the work in W3C.org on RuleML and the semantic Web.

    Agent Services and Rules
    Like many of the JSR initiatives, JSR87 defines a set of objects and service interfaces. In the case of JSR87, these are to support the deployment and operation of autonomous communicative agents based on the Foundation for Intelligent Physical Agents (FIPA) abstract architecture. This, in turn, is influenced by the work of Darpa Agent Modeling Language (DAML), which has been a major part of the semantic Web initiative at W3C.

    Agents that can be discovered and are flexible and personal have given rise to rules-based flexibility. It's in this field that JSR87 is important and in particular its relationship to FIPA, DAML, the semantic Web, and RuleML. This is discussed later in the article.

    JSR94 - Rules and Enterprise Java
    JSR94 defines a Java runtime API for rules engines. The API prescribes a set of fundamental rule-engine operations. This set is based on the assumption that most clients will need to execute a basic multistep rule-engine cycle that consists of parsing rules, adding objects to an engine, firing rules, and getting resultant objects from the engine. It doesn't separate rule types (deductive and ECA), assuming some variant of a Rete model of rule computation. It also doesn't look at defining a common rule language. Rather it looks at a partial mapping to a Rete-based rule framework to define a common parsing API for rule sets so that they may be shared.

    The work of W3C on RuleML goes substantially further. However, JSR94 is the only JSR that's been initiated to deal with rules, albeit a subset of the rule space. It's interesting to note that JSR94 refers to business rules from IBM and was the work of Benjamin Grosof, one of the key players in RuleML.

    RuleML and Java-Based Rules
    Rules for the Web have become a mainstream topic and have been identified as a design issue for the semantic Web since its inception. RuleML is an open initiative that seeks to work toward an XML-based markup language that permits Web-based rule storage, interchange, retrieval, and firing/application. It's the only rule standards initiative to deal with deductive and reactive rules within the same framework. It openly seeks to leverage reactive and deductive power to provide a more meaningful interchange of rules-based technology, which is necessary to power the next generation of Web services and semantic Web applications.

    Being a W3C initiative provides a language-neutral approach that's likely to lead to wider ranging results than one that's tied to Java. The incorporation of reactive rules through an ECA-like rule definition provides this initiative with a wider canvas than just deductive-based solutions. Having both types of rules under the same umbrella may lead to more interesting and pervasive solutions.

    Rules for the Semantic Web and Web Services
    Rules are a fundamental currency in managing Web services. For the first time Web services have dealt with the flow of control between components (or services) that's required to achieve some goal. In a business context this maps to a business transaction. This flow can be defined by a choreographed set of events, and the control and flexibility can be expressed using ECA rules and enhanced using deductive rules. This enables service choreography to take advantage of the natural event-centric model of ECA rules and the data-centric model of deductive rules to declaratively express conditions (e.g., are you a preferred customer?).

    The semantic Web work of W3C is highly relevant to all of this. Indeed, Tim Berners-Lee, director of the W3C, has gone on record saying, "Web services are an actualization of the semantic Web." To this end, much of the work on DAML, RDF, and RuleML has a high degree of relevance to Web services, and it's likely that Web services will be the first user of the technology that underpins the semantic Web. It's our belief that RuleML and RDF-like semantic decoration will enable better service discovery and personalization to take place. This in turn will lead to a new generation of Web-based application solutions.

    Summary
    What I've shown is that there are fundamentally two types of application areas in which rules have a major role: data-centric and event-centric. I've illustrated that deductive rules are well suited to data-centric problems and ECA rules to event-centric problems. I've examined the different deployments of rules from J2ME to J2EE, and looked more closely at how the different rule models add value. I've given a précis of current standards-based work, looking at the JSR initiatives for agents and rules, introducing RuleML, and tying them together around Web services and the semantic Web.

    The rules that we discussed relate to personalization based on standard license agreements with services that can impact what you see, what you do, and how you do it. These are all critical to the success of any B2B solution, SCM offering, or ERP initiative. All these business domains require value-added flexibility to enable their systems to meet the needs of the enterprise and the multiplicity of roles within it.

    References
    1. Snell, J. (2001). "The Web Services Insider, Part 2: A Summary of the W3C Web Services Workshop." April. www-106.ibm.com/developerworks/webservices/library/ws-ref2/?dwzone=webservices
    2. GUIDE Business Rule Project, Final Report, Nov 6, 1995.
    3. Tombros, D. (1999). An Event- and Repository-Based Component Framework for Workflow System Architecture. PhD Thesis, University of Zurich, November.
    4. Astrahan, M.M., and Chamberlin, D.D. (1975). "Implementation of a Structured English Query Language." Comm. ACM 18:10, pp 580-587.
    5. Forgy, C.L. (1982). "Rete: A Fast Algorithm for the Many Pattern/Many Object." Pattern Match Problem. Artificial Intelligence. pp 17-37.
    6. Ross-Talbot, S., Brown, G., et al. (1998). "Building Globally Adaptive Systems." ObjectExpo, Europe. November.
    7. Ross-Talbot, S. (1998). Object Databases in Practice. Prentice Hall.
    8. RuleML: www.dfki.uni-kl.de/ruleml/
    9. Codd, E.F. (1979). "Extending the Database Relational Model to Capture More Meaning." ACM Transactions on Database Systems 4. pp 397-434.
    10. Fritschi, H., Gatziu, S., and Dittrich, K.R. (1997). "FRAMBOISE: An Approach to Construct Active Database Mechanisms." Technical Report 97.04, Department of Computer Science, University of Zurich. ftp://ftp.ifi.unizh.ch/pub/techreports/TR-97/ifi-97.04.ps.gz
    11. Hsu, M., Ladin, R., and McCarthy, D. (1988). "An Execution Model for Active Data Base Management Systems." Third International Conference on Data and Knowledge Bases, June.
    12. Business Rules for Electronic Commerce: www.research.ibm.com/rules/home.html

    Author Bio
    Steve Ross-Talbot is CTO and principal founder of SpiritSoft. He holds the position of honorary research fellow at Napier University, Edinburgh, Scotland, having published work ranging from query optimization to advanced ECA-rule architectures. [email protected]

    All Rights Reserved
    Copyright ©  2004 SYS-CON Media, Inc.
      E-mail: [email protected]

    Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.