The features and facets of the Agent Building and Learning Environment (ABLE)

Document options Document options requiring JavaScript are not displayed Rate this page Help us improve this content

Level: Introductory

Mark Meyer (geeky2@gte.net), Software Developer, TravelClick Inc.

06 Oct 2004

Learn about the major features and facets of the Agent Building and Learning Environment (ABLE), including the ABLE architecture and how to manipulate data beans, rule beans, and learning beans to be used in a wide variety of applications. After reading this article, you should have a solid understanding of the basic ABLE elements and be prepared to work with each of these elements represented as examples in the ABLE Examples Project.

Introduction

The Agent Building and Learning Environment is a Java language-based framework, component library, and productivity toolkit for building intelligent agents using machine learning and reasoning. The ABLE architecture uses JavaBeans components to provide reusable software components that can be manipulated in visual editors.

ABLE's component library includes data beans to read and write data to files and databases, machine learning beans, and a ruleset bean for scripting or inferencing. The ruleset bean's definition language bears a strong resemblance to the Java language, making a first-time ABLE rules developer feel right at home.

The bean components are used to construct intelligent agents that do specific functions. Agents are active, persistent software components that perceive, reason, act, and communicate. ABLE's agent library includes agents for prediction, classification, and clustering.

The ABLE architecture provides data exchange between beans using event listeners, or with shared arrays called data buffers. Hybrid agents can be constructed using combinations of machine learning and ruleset beans. ABLE includes a platform for distributed agents based on FIPA 98, an implementation that provides services for security, persistence, and life cycle management.

The ABLE package also provides the builder tools ABLE RuleSet editor and the ABLE Agent editor to help with developing and debugging ABLE rulesets and agents. Many examples are distributed to show the uses of the various agents and features of the rule language. Documentation includes an API-level JavaDoc, a tutorial for using the Swing-based editors, and a reference for the rule language.

When IBM® announced its Autonomic computing initiative, it designated four core technologies, which include ABLE, for use in complex analysis.

• autonomic computing
• business rules
• data mining uses such as classification, clustering, and prediction
• diagnostics
• planning
• policy management
• resource balancing
• software management and installation

Boxes within boxes within boxes

It's important to understand fundamental architectural concepts in ABLE. All ABLE beans implement the AbleBean interface. All ABLE agents implement the AbleAgent interface. The AbleAgent interface is a sub-interface of AbleBean. This means there is a reflexive relationship between an ABLE bean and an ABLE agent. The practical outcome of this reflexive relationship is that all ABLE agents are, in effect, an ABLE bean, allowing ABLE agents to act as containers for other ABLE agents, creating a box within a box within a box scenario.

For the sake of brevity and consistency, when referring to an ABLE agent, I'll use the term AbleAgent. When referring to an ABLE bean, I'll use AbleBean.

Back to top

Beans and agents

The ABLE architecture is based on the concept of AbleAgents and AbleBeans, as shown in Figure 1.

AbleBeans are the basic building blocks, and AbleAgents can contain AbleBeans and are themselves AbleBeans. ABLE ships with 14 core AbleBeans, which can be divided into three broad classifications:

• Data beans
• Rule beans
• Learning beans

Back to top

Data beans

The core beans can be added to an agent, and data passes between the beans and agent in one of three ways: data buffer, event listener, or property change listener. Data or buffer connections between ABLE beans typically define the path of data within an ABLE agent. All AbleBeans have a data flow state, which is either ON or OFF.

AbleBeans can have multiple input data flow connections, but only one input connection can be active at a time. When data flow for one input is turned ON, any other inputs are turned OFF. This is a useful feature for switching inputs from one source to another when teaching learning beans. An AbleBean can pass data through multiple output connections at one time.

AbleBeans can also exchange data with event listener connections, but, more commonly, event connections are used as a way to provide data to an agent. Events can be processed synchronously or asynchronously, and the asynchronous thread can also be used as a timer with a sleep interval. Events can:

• Be used in conversations
• Embed actions
• Include reply-to data
• Be used as transactions

Some beans and agents transmit property change events -- a third way in which data can be passed to listening objects.

All AbleBeans can be serialized, enabling them to be saved and restored as needed or to be used by the ABLE agent platform, which is based on RMI. Table 1 shows data-related AbleBeans.

Table 1. Data-related AbleBeans

Rule engine types

Before discussing the second and third categories of AbleBeans (rule beans and learning beans), I'll briefly cover the rule engine types supported by the ABLE architecture. Knowing about rule engines should pave the way for you to make the leap to rule and learning beans.

Generally, a rule engine simply processes a collection of rules, of which the simplest form is conditional if/then. ABLE provides rule engines that use simple procedural control, and chaining engines that perform inferencing. An inference engine is any program that infers new facts from known facts based on a set of inference rules. Inference rules can be simple or very complex. To explain what an inference rule is, I’ll use one of the classic "rules of inference for propositions" named modus ponens, or law of detachment. Modus ponens can be stated as:

p -> q
p
--
q

Using natural language the above can be stated as:

If (p implies q) = true and p = true 
then q is true

The If clause is often called the left-hand side or antecedent clause, and the then clause is the right-hand side action, or consequent clause. If the antecedent clause is true, the rule is said to fire, meaning the consequent clause is to be processed.

All rule engines derive new facts or outcomes given a known set of facts or inputs. However, rule engines come in several flavors, and a specific type of engine might be more suitable for a given type of problem. ABLE supplies several different styles of rule engines:

Procedural

Process rules from top to bottom just as a Java method does, or have rule priorities assigned to determine the process sequence

Forward chaining inferencing

Have specialized strategies for selecting the sequence in which rules are evaluated and fired, and continues to process the rules until no more rules can fire

Backward chaining inferencing

Also has specialized strategies for selecting rules for processing, but processes rules to find one or more ways to obtain a value for a specified goal variable. After the goal is met, processing ends regardless of whether all rules have been evaluated.

ABLE supports ten different rule engines, as shown in Table 2, which range from simple procedural if/then/else scripting and decision trees, to inference engines that do backward or forward chaining, to inference engines that also use predicate logic, fuzzy logic, and pattern matching within working memory. The newest engines are specific to planning and policy applications. The simpler rule formats are supported by most engines, but some engines are so specialized that they have their own rule syntax. Rulesets that use the simpler engines can readily convert to the more powerful engines without major changes. ABLE is also designed so you can provide your own rules engine.

Table 2. Rule engines

Procedural rule engines

The procedural engines support the simpler rules and provide an easy way to start placing logic external to an application program (a major reason to use rules). This allows changes to be made by non-programmers, and without recompiling.

Decision tree

The simplest of rule engines, it has a procedural control strategy that ends processing after the first rule fires. Decision trees are often used in business rules and problem escalation scenarios, such as what you might find in a Help Desk environment.

Policy

Evaluates preconditions before taking an action and has a specialized rule syntax and semantics tailored to policy management. Uses rule priority and sequence to control the order in which rules fire.

Script

A simple procedural control strategy, processing the rules once in the sequence they appear

Inferencing rule engines

The inferencing engines support specialized control strategies, specialized rule formats, and scale to large numbers of rules and objects. ABLE's design lets you grow from the simple procedural engines to true inferencing engines when you need that capability.

Backward chaining

This inference technique uses a goal-driven approach to prove a goal by recursively breaking it down into sub-goals and trying to prove these, learning new facts until the goal is reached. In backward chaining, the goal must be defined before processing rules -- it needs to know what it needs to know!

Forward chaining

This inference engine uses a data-driven approach to derive new facts from a set of known facts. New facts might trigger new rules whose conditions match the new data. These rules then perform their actions. The actions might trigger more rules, or some of the same rules again. Forward chaining repeatedly processes a set of if/then rules until no more rules can fire.

Fuzzy logic

Allows variables to take on a range of values with varying degrees of truth, and defines the mathematical method of combining those variables in expressions to calculate the truth value for a clause. Fuzzy rules are evaluated in parallel, and will fire once at the most in a forward chaining manner.

Pattern match

The PatternMatch engine is a forward chaining engine that uses working memory to store facts and state information. Within the rule actions, facts in working memory are changed, added, and removed as needed. Rules continue to fire until no rule evaluates as true. Rules are selected for evaluation based on priority, then the number of facts in their antecedent clause with sequence as a tie-breaker.

Pattern match with Rete’ network

The PatternMatchRete’ engine is similar to PatternMatch, but also constructs a Rete’ network that caches partial matches. This improves performance in rulesets with many rules and variables.

Planning

A special-purpose engine used to both plan a sequence of actions to achieve specific goals, and to execute the resulting plan. This engine uses predicates to represent states, and uses Java class hierarchies to reason about types.

Predicate

A backward chaining engine that infers facts needed to reach a specific goal, and uses predicate logic in prolog-style rules. Unlike the other backchaining engine provided by ABLE, it can provide multiple solutions when more than one are feasible.

Back to top

ABLE rules

With its built-in rule language (ARL), ABLE lets you create rules to be processed by a rules engine. Using rules lets you separate business rules and policies from programming logic. Changes don't need to be compiled, and don't need to be made by programmers. Now you're ready to explore how ABLE represents rules as they are used within the context of a given engine.

In Data beans I touched briefly on rules and facts. The more formal definition of an ABLE rule is a declarative statement or knowledge expression. ABLE's most common representation of a rule is the if-then rule. Listing 3 shows an example taken from the Animal.arl example file that ships with ABLE.

: If (swims == "no" and color == "black")
		result = "panther";

To aid in grouping individual rules into manageable chunks, ABLE introduces the concept of a rule block. Each rule block has an associated rule engine that interprets the rules in that block. This lets you mix multiple engines, both procedural script and inferencing, such as forward and backward chaining. Unlike what you might be used to in a procedural programming language such as C, a given rule engine implements its own process control strategy. You cannot predict the order in which rules are fired without understanding that control strategy. Rule blocks are otherwise similar to Java methods, capable of using parameters and returning results.

At a higher level, ABLE uses the concept of a ruleset, which is encapsulated by the AbleBean class AbleRuleSet. A ruleset can contain individual rule specifications, rule blocks, and even data. It can

• Embed data beans directly in the ruleset to read and write data
• Receive data from another bean's outputbuffer or from an event
• Send data to another bean's inputbuffer or send events to other listeners

Listing 4 shows the HelloWorld ruleset used to seed new rulesets. Note the rule block process that uses the Script rule engine:

ruleset RuleSet_0 {
  variables {
    String helloWorld = new String("Able rules!");  } 
  inputs{};
  outputs{};
  void process() using Script {
    Rule0: println(helloWorld);
  }
}

As mentioned, rule files (designated with a .arl extension) such as Animal.arl are really text files with Java language-like syntax. However, ABLE gives you a second option of defining your rules, ruleblocks, and rulesets as XML documents conforming to the ABLE ruleset XML schema definition. Rulesets can also be created and modified using the AbleRuleSet API. Like all AbleBeans, your ABLE rule sets can be serialized as a JavaBean component.

Table 3. AbleRuleSet

ARL has more function than I can describe in this introductory article. A large selection of example rulesets are provided, and you can explore the AbleRecommendations.arl ruleset (available in Resources), which is an example created for an upcoming developerWorks article. Other Able Rule Language features are:

Inner classes

Patterned after Java inner classes, but more similar to a C language struct

Rule priorities

A rule modifier used to determine rule firing sequence

Rule metadata

Can preclude a rule from evaluation using time periods and Boolean expressions

Expressions

A way to define a complex or frequently used clause as a simpler, natural language-like expression that is similar to an inline method, allows the expression to exist in only one place, and makes the rules that use it more readable

Templates

Used to generate both rulesets and rules from a pattern

Object Constraint Language (OCL) Collections

Manipulate groups of objects with behaviors and terminology defined by the Object Management Group. See the ABLE Rule Language User's Guide and Reference (shown in Resources) for details.

Back to top

Learning beans can be fun

Can you express all the rules you need for your application under all the conditions possible? If you have the knowledge, explicitly defined rules make decisions clearcut. Unfortunately, relying exclusively on a rule-based mechanism can result in a brittle and inflexible reasoning environment. Do you have data about your customers, processes, and products, but are overwhelmed by the amount, complexity, and difficulty expressing the relationships between data values?

This is where neural networks (embodied by specific ABLE learning beans) come into play. A neural network is an attempt to model the human brain and its cognitive ability using a machine. In contrast to rules, neural networks adapt or learn from inputs, but the learned knowledge is often difficult to make explicit. The developers of ABLE incorporated the ability to seamlessly mix symbolic rule-based reasoning with sub-symbolic neural network and other machine learning algorithms. Mixing these two reasoning techniques lets an application reason symbolically using rules when possible, and use a data-driven approach that includes historical data in decisions.

So, how do you know when to leverage the capabilities of a learning bean? If you have a strong need for the application to be autonomous and adaptive, then a learning bean is the ticket. Another criteria to use in determining if an AbleRuleSet or a learning bean is needed is to judge how easily your system can be mapped to a known set of rules, goals, and data. If this task becomes unwieldy and you have the data needed to train a learning bean, then one of the ABLE learning beans will probably serve your needs.

Another application for learning beans is data mining. ABLE data beans and learning beans have been combined to create neural classification, neural clustering, and neural prediction agents that can be used for lightweight data mining tasks.

ABLE ships with seven learning beans, as shown in Table 4.

Table 4. Learning beans

Back to top

ABLE and the Autonomic Management Engine (AME)

In the article Use autonomic computing for problem determination, ABLE and the AME are used to monitor the viability of a link between a DB2® server and a Web application residing on an IBM WebSphere® server. Considering the importance of some Web-related applications to the revenue-generating opportunities of a company, making fast and accurate decisions (when something fails) is not only practical, it can be mission critical!

In the article, ABLE provides the reasoning capabilities while the AME provides the backdrop for event monitoring, filtering, and aggregation. The ABLE Script and PatternMatch rule engines are used to process ABLE RuleSets when the AME detects a problem. The end result is an autonomic manager capable of performing proactive root-cause analysis for problem determination within seconds of its appearance. This is a far cry from the more standard approach taken when something fails. In a more traditional environment, a simple heart beat mechanism is employed at various locations in the system. If that heart beat ceases, an e-mail is sent to an operations Help Desk, which might not respond to the issue in a timely manner.

Back to top

ABLE and IBM WebSphere Portal

In Version 5.0 of WebSphere Portal, the installation mechanism was redesigned. One change was the inclusion and use of ABLE's predicate inferencing engine to do dependency checking for all the disparate operating systems on which WebSphere Portal installs. The rulesets used by the WebSphere Portal installation define over 300 predicates and use more than 550 rules. The improvements in the installation procedures reduced the install time from days to hours. Listing 5 shows one of the prolog-style rules used in this application.

LINX: get_disc_WAS_current_loc_and_versions("LIN", List_) :-
  get_disc_WAS_loc_and_versions("LIN", AList_),
  product(Product_),
  current_loc_and_versions(Product_, AList_, TList_),
  remove_WPCPR_was_instances(TList_, List_),
  cut()

Back to top

ABLE and OS/400

In the i5/OS operating system, IBM Support uses an agent application to analyze communication trace failures. It uses ABLE's asynchronous processing and its fuzzy inference engine to detect a dozen common TCP/IP failures such as denial of service attacks, slow transmissions, and fragmentation. By defining fuzzy variables with fuzzy sets with appropriate semantics, the rules for classifying the type of failure are very naturally expressed, as in Listing 6.

ReceivedMTUFrag3: if (receivedMTUFragmentationPacketPercentage is
likely and recvFrames is few) then MTUFragmentationReceiveConfidence 
is unlikely;

The i5/OS also ships an agent management console built on top of ABLE, and includes a sample agent for time management.

Back to top

ABLE development tools

This section is not meant to be an exhaustive discussion on how to use the ABLE editors; it only introduces you to the various editor tools that ship with ABLE. Using these tools is very intuitive, but if you have problems, the HTML documentation that ships with ABLE is helpful.

I won't cover all of the editors because the Swing-based Agent editor is currently more functional than the Eclipse-based Agent editor plug in, so almost everyone opts to use the Swing-based Agent editor.

The Eclipse-based RuleSet editor is superior to the Swing-based RuleSet editor, and therefore, is used by most developers. If you're simultaneously developing Java classes and rulesets, it's easier to use the Eclipse ruleset editor because changes to your Java classes are loaded when you parse your ruleset changes.

There is a current effort to rework the Eclipse-based Agent editor. When available, the revamped Eclipse-based Agent editor will be for Eclipse 3.0.

Swing-based Agent editor for ABLE

ABLE ships with a Swing-based Agent editor that comes packed in the \bin directory created by the ABLE install process. If you're in a non-UNIX environment, use the \bin\runnit.bat file to invoke the Agent Editor. If you are in a UNIX environment execute the \bin\runnit.sh file. The Swing-based Agent editor is discussed in several of the tutorials in the HTML documentation.

The ABLE distribution also ships with runplatform.bat, runplatform.sh and startplatform.bat, and startplatform.sh files. The startplatform.bat and startplatform.sh command files start a daemon process for platform agent services based on the FIPA98 specification. The runplatform.bat and runplatform.sh scripts do almost the same thing as runnit.bat and runnit.sh, but causes some platform-dependant agents to appear on additional tabs in the Swing-based Agent editor.

The Swing-based Agent editor for ABLE, after opening the animal.ser example, is shown in Figure 2.

Eclipse-based RuleSet editor for ABLE

Back to top

Downloading ABLE

Downloading ABLE is easy. Everything you need is accessible from IBM alphaWorks Agent Building and Learning Environment, as shown in Figure 4. After you've navigated to the ABLE download page, you see six available archive files. Two of the archive files are in Tar format, and the other four are in Zip format. Regardless of which archive format you choose, each format is multiplatform.

Back to top

Installing the ABLE example project in Eclipse

The Eclipse distribution provides an example plug in, which can be set up as follows:

1. Copy ableexamplessrc.zip from the eclipse/plugins/com.ibm.able.examples directory to the eclipse/plugins/com.ibm.able.ui.ruleeditor directory. This avoids an ABLE 2.1.0 bug.
2. Go to New > Examples > Able and select the able examples project
3. To set the project source and output directories, open the project properties page and go to the Java Build Path. For able 2.2.0, enter src as the source folder. If you're not using Websphere Studio Application Developer Version 5.1, exclude the **/templates/ directory because that depends on Application Developer's com.ibm.etools.webservice package. Append \bin to the output path. Your project source should look similar to Figure 5 for ABLE 2.1.0.
   Figure 5. Java build path
   
   
4. Add external JAR files by extending the ECLIPSE_HOME variable to include the JAR files as shown in Figure 6.
   Figure 6. Adding JAR files
   
   
5. Press OK, and the example project should compile cleanly

Back to top

ABLE examples in Swing

In the Swing versions of ABLE, examples are provided in the examples subdirectory. In both cases, these directories include examples\datafiles used by many of the examples, examples\agents, examples\neural for learning bean examples, and example\rules, which includes dozens of rulesets and example code showing how to deploy applications.

Back to top

Conclusion

ABLE's architecture gives it the ability to assemble agents using components from many disciplines. Only a few implementations are described in this article, but those components let you use ABLE in a wide variety of applications. I covered the major facets of ABLE, including data beans, rule beans, learning beans, rule engines and agents. I also gave a quick tour of development tools that ship with ABLE.

Now your own internal neural network should be spinning wildly with all sorts of ideas on how ABLE can help you in your development tasks. So get "assimilated" into the ABLE collective and dive into the documentation -- resistance is futile and ABLE is great fun!

Back to top

Acknowledgements

The author would like to thank the ABLE research team, ableinfo@us.ibm.com, for their support.

About the author

		Mark Meyer is a software developer with TravelClick Inc. (www.TravelClick.net). Mark works in Java, Delphi and Perl. When Mark is not coding or doing homework - he is evangelizing Process Engineering, UML and Patterns to anyone who will listen. Mark still has not recovered from the series finale of The X-files. He is often seen on his roof (pointing at the sky) with his two daughters Paige and Kirsten - (The Truth is Out There). Mark can be reached at Geeky2@gte.net.

Rate this page

Please take a moment to complete this form to help us better serve you. Did the information help you to achieve your goal? Yes No Don't know   Please provide us with comments to help improve this page:   How useful is the information? 1 2 3 4 5 Not useful Extremely useful

Share this.... Digg this story del.icio.us Slashdot it!

Back to top