Ky Van Ha
Internet gives us the possibility to deal with a large set of distributed
data. All data must be handled before they can provide the useful
information to users. By using intelligent agents, we can make the job
easier and more effective than the traditional ways.
In this paper, we describe a multi-agent stock-market system that consists of several agents in an agent society called the Yin-Yang system. The Yin-Yang system is a “Plug and Run” system that is developed at Østfold College Agent Lab. We follow an idea of the very old Chinese philosophy, Taoism: Tao (nothing) begets one, one begets two, two begets three and three begets everything. The Yin-Yang system begins with “nothing” and then a plug, HIO_kvh_Manager, that is connected to “nothing”, is started. One or several domains can plug into that plug to create an agent society. In that society, any agent can run or use the other agents in different domains at different locations.
I.2.11 [artificial intelligence]: distributed artificial intelligence-multi-agent systems.
Design, Framework, Implementation.
Multi-agent systems, Global computing.
The concept of an agent has become important in both Artificial Intelligence and mainstream computer science. The advent of multi-agent systems has brought together many disciplines in an effort to build distributed, intelligent, and robust applications. Many of our traditional ways of thinking about and designing software do not fit the multi-agent paradigm. Over the past few years, there have been several attempts at creating tools and methodologies for building such systems [2, 4, 5, 7, 10, 11]. Unfortunately, many of the tools focused on specific agent architectures with specific constraints. The IMPACT architecture  that is developed at the University of Maryland is an effort to provide an infrastructure that supports multi-agent interactions and a mechanism to “agentize” a software program in a heterogeneous environment. However, its complexity may hinder the practical the use of the system. We do not believe that the system can be used outside the Maryland society. In a paper in 1999 , the authors point out: “Our evaluation has highlighted the fact that not much discernible progress has been made post 1994, perhaps because researchers have failed to address the practical issues surrounding the development, deployment and utilization of industrial-strength production systems that use the technology”. Nowadays, there is no one who does not know about agents. Everyone talks about agents; however, the situation does not seem better. In order that the agent technology can be used by everyone, at everywhere, we need a system like a web portal or a grid infrastructure  that makes it easy for users to create agents and plug them in the system and let the other run them, use them. The Yin-Yang system  is such a portal system. Like a web portal that provides transparent and ease-of-use interface to a complex set of web pages and has led to the explosive growth of the web, our framework provides a generic and simple interface that makes it easy to include several agents in the society at anytime online. Our agent society is scalable as required by any society. We do not put too many constraints to the domains or agents. One domain can leave or joint to the organization at anytime. There is the same with the agents in the society, they can leave or joint the society, as they want to; it does not change the society much. The detailed architecture and implementation is reported in  and will be published somewhere. In this paper, we concentrate on a typical application developed in the Yin-Yang system, a multi-agent stock-market system.
The remainder of the paper is organized as follows. Section 2 outlines the development of the concept agent and multi-agent system; how the others understand agents and how we understand them. Section 3 gives overviews of some technologies like jdbc and jini that can be used in an agent system. Section 4 discusses the agent communication language KQML. We describe the multi-agent stock market system in section 5 and make a conclusion in section 6.
All most previous and popular definitions of agent in the AI community are based on agent’s behavior [2, 4, 11]. There is no single universally accepted definition of agents; however, almost all authors accept that an agent can have some of the following properties:
Some other characteristics as reactive, adaptive, intelligent, learnable, mobility, etc. are also mentioned. In essence, the concept of an agent can be summed up by the following definition :
“An agent is a computational entity which:-
Some authors concentrate on some characteristics of agents; the result is that agents are classified in several categories: autonomous agents, intelligent agents, mobile agents, multi-agent systems, etc.
The Impact (Interactive Maryland Platform for Agents Collaborating Together)  has another definition; it bases on the agent’s structure but not on the agent’s behavior. In Impact, “agentization” of a software program corresponds to augmenting the program’s code with “wrapping” code that gives it its structure. However, agentizing a program is not enough. In a distributed, independently evolving software environment, agents still need to know what other agents lurk in the environment, and they might wish to advertise their presence and the services they offer. So, any infrastructure that supports Multiagent interactions and applications must provide a basic set of services that other agents can access.
We follow this structural approach; however our agents are very different from ones in the Impact system. In the Impact system, an agent can have one or more services. The service name consists of a verb and a noun, for example, “provide: information” is a service in the Impact system. In contrast to the Impact system, our agent has one and only one service, “doWork”. What service it does is presented in its name. For example, “domainInfo”, “agentRegister”, “meetingScheduler” are the agents in the Yin-Yang system. Make it short; an agent in our system is a software program that implements the “Agent” interface. Each agent in the Yin-Yang system has a status and a service. In our system, “agentization” of a software program is wrapping it in the doWork method. It is very easy and very simple. And the simple is beautiful. We should think simple, program simple, and live simple.
Each agent in our agent society must have one of the following statuses:
An agent can have another status, “private”. In this case, we just make it private by not implementing the Agent interface, and therefore, the status is empty. Thus, agents in our agent society are “everything” in the Taoism philosophy.
In order that our agents can work together they must be placed in a
domain. This can be done in runtime when the domain is plugged in an
organization in the Yin-Yang world of our agent society . When agents are
located in a domain, they become public and can be used by other agents in
the same or different domains (see figure 1). Communication protocol is
transparent in the Yin-Yang system. Each domain in the agent society has
responsibility to register its own agents and announce to the world the
services it has by providing an agent service, for example, “domainInfo” so
that the other domains, other agents can get the services they want to use
or co-work with. If a domain knows that there is already that service in
another domain, it can just use that service and do not need to create its
own agent that does the same job.
Figure 1: Agents in the Yin-Yang system
In order to implement our agents, some technologies like Java, Jini, Jdbc, Xml, etc. can be used. We will mention some of them in the next section.
In this section, we would like to give a short overview over some technologies we used in our agent society framework. The Yin-Yang system is implemented by using Java. Some technologies we would like to mention here are Jini, Jdbc, and Xml.
The Jini architecture provides an infrastructure for defining, advertising, and finding services in a network. Services are defined by one or more Java language interfaces and/or classes . Because the Jini architecture is defined in terms of the Java programming language, it is platform independent. It is a useful framework for building scalable, robust, and distributed systems. Services in a Jini community can be both software and hardware; software and hardware components are transparent under the name of services.
A Jini community contains of three main components:
Figure 2 illustrates the interaction between the components.
Figure 2: The Jini architecture
An agent in our system is not a Jini service. It does not register itself to the Jini lookup service. It may be or may be not a Jini Client. It can run other agents without searching for the services; it does not need agents’ interfaces to run them. Really, agents in our system do not have own interfaces as required in a Jini community. However, our agent can search for one or more Jini services and use them.
Information is very important in any system. Internet gives us the possibility to deal with a large set of distributed data. All data must be handled before they can provide the useful information to users. Useful agents must have the capability to access heterogeneous data sources, filter all useful data and save them for that the other agents can use them.
Jdbc (Java Database Connectivity) provides an interface that let Java programs to connect to and then manipulate data stored in SQL (Structured query language) database servers . To act as an intermediary between JDBC and DBMS (Database Management System), four different types of Jdbc drivers have been created:
In the core of Jdbc API, there is a class, called DriverManager that manages all Jdbc implementations one work with. DriverManager has the responsibility for making the connection with a driver. When we have a Connection, a Sql Statement can be made and performed. If the Statement is a Query, the result will be stored in the class ResultSet.
Figure 3 shows the communication between an application and Jdbc API.
Figure 3: The use of Jdbc API in an application
We use Jdbc-Odbc to store our agent information in the domains. Each domain has a local database. It is the domain that has the responsibility for registering, updating, or deleting the agent information in its own database. In order to make it easy and comfortable for users, we provide an agent, “agentRegister”, that is in the domain HIO_kvh_Donau, where the agent can be downloaded and run in the local domain. The details about how one can run an agent at a domain from another domain can be found in .
In our system, Jdbc is not only the technology we use to handle the filtered information. We can also use a text file, or an Xml file to store the useful information.
Xml, the eXstensible Markup Language, is not actually a language in its own right. It is a metalanguage used to construct other languages. Xml is used to create structured, self-describing documents that conform to a set of rules created for each specific language. Like HTML (HyperText Markup Language), XML encloses data in tags, but there are significant differences between them. First, XML tags relate to the meaning of the enclosed text, whereas HTML tags specify how to display the enclosed text. The second major difference between XML and HTML is that XML is extensible. With XML, you can write your own tags to describe the content in a particular type of document. That, you cannot do with HTML .
Let us look at an example that shows an agent list in a domain with the name, description and usage of all agents in that domain:
<name> plotData </name>
<description>plot a data file (y-coord). Status: download
<usage>input: the name of the data file (mandatory),
xmin, xmax (option)
<agent> . . . </agent>
Another aspect of XML’s extensibility is that you can create a file, called a schema, to describe the structure of a particular type of XML document. For example, you can write a schema for the agentList in the above example, agentList.dtd:
<!ELEMENT agentList (agent) +>
<!ELEMENT agent (name, description, usage) >
<!ELEMENT name (#PCDATA) >
<!ELEMENT description (#PCDATA) >
<!ELEMENT usage (#PCDATA) >
DTD is the Document Type Definition schema language and is an integral
part of the XML 1.0 specification. A schema gives XML data its portability.
For example, given the agentList DTD, a parser will know the structure and
type of content for any XML document based on that DTD.
The new version of Java APIs provides classes/interfaces to handle XML, making it easier to use XML from the Java programming language. XML documents, when parsed, are presented as a hierarchical tree structure in memory. This structure is called the XML Document Object Model (DOM). It contains the document’s elements, attributes, content, etc. XML was designed to be a live, dynamic technology, a programmer can modify the contents of the tree structure, which essentially allows the programmer to add data, remove data, query for data, etc. in a manner similar to manipulating a database.
In our agent society, XML can be used as an alternative to Sql database. Really, XML, Database, and File systems, all are transparent in our system. There are always one or more agents that work with data and provide the requested information to users. In order that agents can talk together, they must accept a communication language. The most popular agent communication language is KQML and will be discussed in the next section.
The most difficult challenge for any multiagent system is the communication and cooperation between agents. How agents can communicate and understand with each other; how they can work together cooperatively to accomplish complex goals are the questions must be answered in any agent society. A multiagent cannot work without an agent communication language. This perspective on interoperability in today’s computing environment has been the foundation of the approach of the Knowledge Sharing Effort (KSE) consortium. The KSE is a consortium to develop conventions facilitating sharing and reuse of knowledge-based systems. Its goals is to define, develop, and test infrastructure and supporting technology, to enable participants to build a larger systems with greater functionality than could be achieved alone. For agents to interact and interoperate effectively requires three fundamental and distinct components :
The External Interfaces Group (EIG) is one of the four groups in KSE consortium. The scope of the EIG is the runtime interaction between knowledge-based systems and other modules. The EIG has developed a language, the Knowledge Query and Manipulation Language (KQML), which we use in our agent society.
The KQML language is divided into three layers:
The syntax of KQML is based on a balanced-parenthesis list. The initial element of the list is the performative; the remaining elements are the performative’s arguments as keyword/value pairs. Here is an example of a KQML message:
:content (SELECT * from Stockdata WHERE ticker = ‘TEL’)
In our system, agents can communicate each other by sending a KQML message as parameter.
In this section we shall describe a multiagent system for a stock market. Such a system can be implemented with or without agent technology. However, it is very easy and more effective if we use agent technology. We shall illustrate how such a system can integrate in the Yin-Yang framework.
The strategy is very simple. From one or more domains in our agent society, we send several agents out on the Internet. Each agent will find information about a specific stock in the Oslo stock market, for example “telenorAgent”, “statoilAgent, “tandbergAgent”, etc. They will then store the useful information in its own local database; data is updated in a specific time interval, for example 3, 5 minutes. These agents are hidden ones with the “private” status; they run all the time at the local domains where they are located. They sleep at night, and Saturday and Sunday; they get data and filter information from the Oslo stock market each five minutes every day from 10 o’clock when the market is opened to 19 o’clock when the market is closed. Because they have the “private” status, the other agents cannot run them. Therefore, the domains that own them must have other agents to provide the information to users or other agents. These agents, says, “telenorStock”, “statoilStock”, “tandbergStock”, etc. access the local database and provide the information after requests from users or other agents. They have the “not movable” status; thus, you can run them on the local domain from everywhere in the agent society. When you have data, you can make several applications to present them. Figure 4 shows the result of the tandbergStock in the domain “HIO_kvh_Oracle”. The “tandbergAgent” and “tandbergStock” are two agents that are located at the “HIO_kvh_Brage”.
Figure 4: the “tandbergStock”
The domain “HIO_kvh_Vista” provides another agent, called “stockAgent”, which has the “download” status.
Figure 5: the “telenorStock”
The agent allows users to download the code and run it on the local
machine. The agent provides a graphical user interface that displays the
stock that you want to follow up. The display will automatically update for
each five minutes as shown the figure 5. The first row is the information
that the agent received yesterday, when the market is closed.
Users can easily make several applications with stock data; they can make a graph to illustrate the changing of stock in real-time with the help of the agents “telenorStock”, “statoilStock”, etc. One can easily to get information about any stock at the Oslo stock market at any time.
Figure 6: stock market application
In this paper, we give a very simple example on how we can make a real world application in the context of the Yin-Yang framework, the multiagent stock market system. We could easily to extend the system to handle any stock in any stock market such as NYSE, NASDAQ, etc. The negotiation mechanism in the Yin-Yang system provides us the way to extend the stock market system to support directly and automatically buy/sell stock via stock markets.
We would like to thank our students, Kjartan Haugen and Carl-Erik Herheim, who provide us the figures 2, 3, and 6 in this paper.
 Armstrong, Eric. The Java Web Services Tutorial. Sun 2002.
 Bradshaw, J.M., Ed. Software Agents. MIT Press, 1997.
 Finin, T., Labrou, Y., and Mayfield, J. KQML as an agent communication language. In .
 S. Green, et al., Software Agents: A Review. Technical Report. Trinity College. Dublin, Ireland. May 1997
 Hyacinth, S. Nwana, and Divine, T.Ndumu. A Perspective on Software Agents Research. In Knowledge Engineering Review, 14:2 (125-142). Cambridge University Press, 1999
 Ian Foster and Carl Kesselman, Ed. The Grid: Blueprint for a New Computing Infrastructure. Morgan Kaufman Publishers, Inc, 1999
 Katia Sycara, et al. The RETSINA MAS Infrastructure. Autonomous Agents and Multi-Agent Systems, vol.7, no. ½, Kluwer Academic Publishers 2003, 29-48.
 Ken Arnold. The Jini Architecture: Dynamic Services in a flexible network. In Conference on Design Automation, ACM June 1999
 Ky Van Ha, An Agent-Based Framework for Global Computing
 Subrahmanian, V.S., et al. Heterogeneous Agent Systems. MIT Press, 2000.
 M.J Wooldridge and N.R. Jennings. Intelligent Agents: Theory and Practice. In Knowledge Engineering Review, 10(2), 1995
 Andrew Yang, James Linn, David Quadrato. Developing Integrated Web and Database applications using Java Applets and JDBC Drivers. SIGSCE 98 Atlanta GA USA
Copyright ©1998 - 2003 Høgskolen i Østfold. Last update: 11.11.03, Tore Petter Engen.