Agents

This chapter points out the importance of agents and describes how an active database management system can be used for their implementation.

Jude-Agents

In general an Agent is a software component able to perceive its environment and react to it. In the case of Jude the environment is the knowledge-base, that ``defines the vocabulary with which queries and assertions are exchanged among agents.`` [Gruber 1993]

Jude-Agents are components written in Java programming language and running on the client side. Java was chosen because it is portable, is widely supported and has powerful libraries. Example of Jude-Agent actions are updates of the knowledge-base, updates of the user interface, e-mail notification and so on.. In particular viewers and editors are two special class of Jude-Agents with the scope to display and edit objects defined in the knowledge-base.

Using observer pattern[Gamma 1995] terminology, a Jude-Agents is an observer of one or more objects defined in the knowledge-base. The observer is notified from the active-database-system (called change-manager in observer pattern) whenever one of his subjects (the observed objects) undergoes a change in state. A knowledge-base object changes its state when a transaction assert or retract some base or derived facts having the object as argument. The change-manager advise the Jude-Agentwith a message containing all changed base and derived facts involving the Jude-Agent subjects.

This type of notification message permits Jude-Agents to known the occurred changes and react in accordance. In fact often an Agent is interested not at current status of knowledge-base but at occurred changes. For example when the displayed object of a viewer change, the change notification can be used from the viewer to update the user interface analyzing only the changes and not starting from scratch. Suppose also to have an agent that must advise an user with an e-mail of new added chemical documents. In this case is sufficient to subscribe the agent to changes regarding the type of chemical documents, and whenever a new document is added or removed from this type the agent is advised with a message containing precisely the added or removed documents.

Another application of Jude-Agents is in the field of database-replication. Subjects are all the base facts that are asserted or retracted and the Jude-Object maintain update a replicated database.

Active Database Systems

In Jude the DDBMS XSB is transformed into an active-database and acts as a change-manager. According to [Dayal 1994]:

``Conventional database systems are passive: they only execute queries or transactions explicitly submitted by a user or an application program. For many applications, however, it is important to monitor situations of interest, and to trigger a timely response when the situations occur. For example, an inventory control system needs to monitor the quantity in stock of items in the inventory database, so that when the quantity in stock of some item falls below a threshold, a reordering activity may be initiated. This behavior could be implemented over a passive database system in one of two ways, neither of which is satisfactory. First, the semantics of condition checking could be embedded in every program that updates the inventory database, but this is a poor approach from the software engineering perspective. Alternatively, an application program can be written to poll the database periodically to check for relevant conditions. However, if the polling frequency is too high, this can be inefficient, and if the polling frequency is too low, conditions may not be detected in a timely manner.

An active database system, in contrast, is a database system that monitors situations of interest, and when they occur, triggers an appropriate response in a timely manner. The desired behavior is expressed in production rules (also called event-condition-action rules), which are defined and stored in the database.''

Active-database system are focused on production-rules that often have this form:

on event

if condition

then action;

The behavior of a production rule is described in [Dayal 1994]:

``When the triggering event occurs, the condition is evaluated against the database; if the condition is satisfied, the action is executed. Rules are defined and stored in the database, and evaluated by database system, subject to authorization, concurrency, control, and recovery.''

Production rules have a behavior conforming to agent definition: ``a thing able to perceive its environment and react to it''. However Jude-Agents differ a lot from production rules. From a physical point of view a production rule resides on the database, while a Jude-Agent runs on the client side, outside the server database. A production rule cannot execute complex actions because their actions are expressed in a simple language and they use the server resources, on the contrary Jude-Agents can benefit from full power of Java and does not stress the server database because they use the client resources. In fact Jude-Agents are used also to manage user interface.

The main difference between the two mechanisms is that production rules are used to express directly the semantic of the knowledge-base, on the contrary Jude-Agents are used to implement user facilities. Production rules have a low latency activation time because they are directly activated and executed from the server database. They must interact together in a timely manner because they are the mechanism that maintain consistent and update the knowledge-base. On the contrary in Jude this role is played by deductive rules. Jude-Agents require a complex protocol in order to be actived. This does not disturb so much because they are used as front-end between the system knowledge-base and the user.

According [Ceri 1994] production-rules interact together in complex way and their result is hard to predict. On the contrary deductive rules are very readable and comprehensible because they have a simple and predictable interaction schema. At a first look production-rules seem an elegant mechanisms because the event and condition part is clear to understand due to its declarative nature. The problems is in the action part having an imperative nature and in the possibility that rules trigger one another indefinitely. In general ``it is an undecidable problem to determine in advance whether rules are guaranteed to terminate, although conservative algorithms have been proposed that warn the rule programmer when looping is possible.''[Dayal 1994]

[Ceri 1994] describes a useful method that translates a set of deductive rules into a set of equivalent production rules. In Jude this method is adapted at the scope to discover all base and derived facts changed at the end of a transaction. In this way XSB acts like an active database system because notify agents of changes in a timely manner, but without using production-rules for knowledge representation.

How Jude-Agents Access the Knowledge-Base

Jude-agents are written in Java that is an object-oriented language, so the more coherent way to read and modify data on knowledge-base is using an object-oriented style. An Object-Oriented database is: [Meyer 1997]

``A repository of persistent objects, permitting their storage and retrieval on the basis of object-oriented concepts, and supporting database properties such as concurrent access, locking and transactions.''

In order to permit this the Simple-Logic Compiler creates a Java class, descending from LogicalContent, for each type specified in the knowledge-base. Logical-Content is a wrapper between the relation-based world and the object-oriented world and vice versa. Doing so each object on the knowledge base has a corresponding object on the Java client side having a proper interface and methods to read, assert and retract facts regarding it. This is permitted by the object-oriented nature of knowledge-base. The conversion process follows this simple rules :

1. Knowledge-base types are converted to Java interfaces
2. Knowledge-base relation-declaration having an object of type T as subject (first argument) is converted into a method-declaration for type T in Java

For example this Simple-Logic source code :

assert person is_direct_subtype_of party;

assert person is_direct_subtype_of animal;

 

declare relation person has_name string;

declare relation person has_birthday date;

declare relation person ha_age number at_date date;

can be translated into the following Java interface:

public interface Person extends Party,Animal {

   public Collection get_hasName();

   public void assert_hasName(String name);

   public void retract_hasName(String name);

   public Collection get_hasBirthday();

   public void assert_hasBirthday(Date birthday);

   public void retract_hasBirthday(Date birthday);

   public Collection get_hasAge_atDate();

   public void assert_hasAge_atDate(Integer age, Date date);

   public void retract_hasAge_atDate(Integer age, Date date);

}

According to self-documentation principle described in [Meyer 1997], also the comments on knowledge-base are translate into Java comments.

Every Agent views a knowledge-base object as a normal Java object. This object redirect all the requests to local cache of facts. This permits lower response time and reduce the load on server. The cache contains only used facts about managed objects. This permits a better usage of client resources..

Impedance Mismatch Problem

The knowledge-base is relation-based, instead Java is a pure object-oriented imperative programming language. This situation lead to an impedance mismatch problem as described in [Banchilhon]:

``Relational systems are well suited for the ad hoc query mode but not for application development. Application development requires communication between a relational query language and a programming language. These two types of languages do not mix well: they have different type systems, they have different computational models, relational systems are set-at-a-time while programming languages are record-at-a-time."

In literature there are many solutions. The usage of pure declarative languages or pure object oriented databases in all phase of application development are the two extreme solutions; but the Jude scope is to combine peaceful the two worlds.

The presence of an object-oriented structure both in knowledge-base and in Java remove the mismatch caused by different type system. However the set-at-a-time nature of knowledge-base does not fit well into record-at-time nature of Java objects. For example the Java method ``get_hasName()'' instead of returning a String as commonly expected, returns a Collection of String.

So the impedance mismatch problem is only half-solved, but it is an acceptable compromise in the wait that declarative and high level languages will fills the gap with current imperative languages and should be used also to specify Jude-Agent actions.

Jude-Agent Actions

Actions involving the update of knowledge-base should be represented as invocation of SimpleLogic actions. See section for more details. Pay attention to not overuse agents to specify transaction on the knowledge-base, because in this case you are using agents as a replacement for production rules.

All other actions as sending e-mails, updating user interface, printing etc. can be implemented using directly the Java language. Java is a language with a good set of libraries and is well suited for this type of tasks.

Conclusion

Agents are a way to separate the logic of the application, represented from the knowledge-base on the server, from user facilities, represented from agents running on the client side, as suggested by all design guidelines.

From a developer point of view, agents split a complex system into a collection of cooperating and loosely coupled components (agents). This increases re-usability and decrease errors contrary to a big chunk of tightly coupled code. The difficult task of agents interaction is accomplished by Change-manager. It informs agents of knowledge-base changes involved from other agents. Thanks to it agents does not need to interact each other but they must only deal with knowledge-base changes.

From a user point of view agents are services to use. They could behave like secretary remembering appointment to user, suggesting important things to him etc. Agents could be applications for viewing and editing of some documents. Every different user functionality of an application can be managed from a particular Jude-Agent.

The section takes in consideration the benefit of declarative over imperative paradigm. At this point we must concede that there are fields where an imperative implementation is a better solution than a declarative one. Imperative languages as C,C++, Java, Python are widely used and they have a rich set of libraries and development tools. Up to date they are the right tool to use for tasks as GUI implementation, sending e-mails, launch print process etc. Jude uses an imperative language only to specify actions of Jude-Agents.