• Why use a product like ABLE?
• ABLE goes beyond expert systems

Introduction

The purpose of this article is to get you up and running as quickly as possible with the ABLE Toolkit from IBM. ABLE stands for Agent Building and Learning Environment, and quite simply, this toolkit lets you add artificial intelligence functionality into your Java applications. 

I think the value of this article is its simple introduction to a difficult subject. I found that getting started with ABLE was a painful and laborious process, but I also think it doesn't have to be that way. For me the biggest problem was a lack of good, organized documentation, especially a good introduction for newbies. Hopefully once you finish this tutorial you'll be in a much better position to tackle ABLE than I was, and you'll be able to work through the rest of the ABLE documentation, and the many examples that come with it. 

Why use a product like ABLE?

The basic premise for using a tool like ABLE goes along these lines:

• Many business applications are driven by business rules.
• As a developer, it often seems like business rules are the most illogical, overly complicated approach to a problem that can be imagined.
• Business rules tend to be procedural, but we like our code to be object-oriented.
• When dealing with a domain expert who is providing the business rules, it's nice if they can sit with you during the coding process and see the implementation of those rules in a language they can understand.

Given these statements, how does ABLE help? For me - and just focusing on ABLE's Expert System capabilities at the moment - ABLE lets you extract these complex business rules out of your application and into one or more separate ``rules files''. This lets you keep your code as simple and object-oriented as it can be, while extracting the complicated rules out into separate files where they can be modified outside of the application.

Here's an example of how this works. Let's first assume that I've written an anti-spam application. Second, let's assume that I've extracted the rules out of the application that are used to determine whether a piece of mail is spam. Now, suppose that I've been using the application for a while, and the smarter I get about this problem, the more rules I come up with for getting rid of spam. If I wrote the application the old-school way and embedded the business rules into the Java code, I would have to change, recompile, and redistribute the code for every business logic change. However, using a tool like ABLE, I can put the rules into a separate file outside my Java code. This simplifies my Java code, simplifies my changes, and also simplifies my testing and distribution. Now, if it makes those processes easier for me, think about what it's like when I'm distributing my code to 1,000 other users(!). In cases like this it's much easier to distribute a rules file to all these users than it is to have to send them new Java code all the time.

This becomes very nice because my Java code doesn't have to care about the details of whether an email is perceived as spam or not. All I have to do is let my rules tell the Java program ``Yes, this is spam'', or ``No, this is not spam''. When your rules are well-encapsulated like this, an expert system is a really cool thing.

ABLE goes beyond expert systems

Although the focus of this article is going to be on the expert systems capabilities of ABLE, the toolkit really goes beyond this simple capability by offering other pluggable rules engines and even a graphical development environment. I won't get into further details on these right now, but I'll provide a quick introduction to these other tools at the end of this paper.