Authors
Todd Papaioannou and John Edwards
MSI Research Institute
Department of Manufacturing Engineering
Loughborough University
Loughborough
Leicestershire LE11 3TU
UK
Published at the Agent Based Manufacturing workshop, part of Autonomous Agents '98
The flexible integration of a range of disparate IT applications is a key requirement for today’s global enterprises. The virtual enterprise, formed by a collection of collaborating companies for short term, high return, one off projects provides perhaps the most extreme example of this need. It is unlikely that any collaborators in a virtual enterprise will have similar networks or software, but the requirement exists for them to inter-operate.
This paper proposes the notion that Mobile Agent Technology can be a significant aid to enterprise agility, particularly where distribution of information is a feature, as in virtual enterprises. The implications of using Java and its facilities for database connectivity (JDBC) together with mobile agent environments are discussed before a model to fulfil the requirements of the manufacturing Sales/Order process is proposed. The model used in the process has been produced with data collected from an industrial case study.
The subsequent decomposition of the Agent types involved reveals an abstract pattern for database query using agent technology. Finally, the tools required by an enterprise wishing to utilise agent technology are discussed.
Keywords Mobile Agents, Virtual Enterprises, System Integration.
Access to an organisation’s store of information is a critical factor in developing business systems. Whether client/server applications or monolithic host-based systems, the information stored in an organisation’s database is its lifeblood. The ability to effectively manage, manipulate, and distribute this information was once viewed as a provider of competitive advantage [10]. Today it is simply a base requirement for corporate existence within the global market place.
Globalisation and the advances in Information Technology (IT) systems have led to the emergence of the Virtual Enterprise [1]. This type of enterprise is made up of a number of co-operating companies who are generally physically distributed but work together to meet some market demand. As the operations of the enterprise are distributed geographically, then the information systems that support them must be capable of distributed operation[9]. Typically, these relationships are short-term collaborations on one off, high return projects where time to becoming effective in the market is of the essence. Management of information remains a base requirement of these virtual enterprises, who are therefore charged with the integration of several separate IT systems to form an operational system in as short a time as possible. Key to this integration is access to a variety of database systems.
Internet technology has proved to be effective for connecting a mix of different types of computers and computer networks, while also providing location independence to information. Further, analysts predict that the next five years will see the evolutionary convergence of the Internet, Intranets and traditional IT models such as client/server and peer to peer [1]. It would thus appear to be an appropriate approach for addressing the problems of integrating different IT systems to support a virtual enterprise. However a serious problem with this technology remains.
The saturation of network bandwidth, especially when part of the network in question is the Internet, means that remote database access as required by the virtual enterprise model could mean ineffective IT support for the business. As well as data timeliness, factors such as, data integrity and security are also a concern when dealing with the Internet. Mobile Agent technology is able to overcome this set of problems through local interaction[2]. It is equally applicable to the problem of geographically distributed information sources, since mobile agent systems are inherently distributed.
Having first discussed the implications of Java and its facilities for database connectivity (known as JDBC), this paper proposes an agent-based model for supporting the Sales/Order process within a virtual enterprise. This process is based around the access and manipulation of information generally stored in databases. The system decomposition identifies several key agent types within this model. Subsequent analysis of one of these leads to the derivation of an abstract pattern for database query using agent technology.
The agents discussed in this paper can be classified in line with Franklin and Graesser [11] as goal oriented, communicative, and mobile i.e.:
In order for these agents to exist within a system or to themselves form a system they require a framework for implementation and execution. This is known as the agent environment.
It can be argued that Java has become the de facto language for writing mobile agent environments. Systems using it include Aglets [4], Voyager [5], Mole [6], JATLite [7] and Concordia [8]. The use of this platform neutral language provides the portability demanded by the mobile agent paradigm. As long as there is a Java Virtual Machine for each platform type in the system, any agent environment written in Java will have the potential to take advantage of the facilities or legacy systems on that platform. This platform neutrality forms a good basis for enterprises requiring system agility, or wishing to form virtual enterprises, although accessing legacy systems is of course still a considerable problem. The recent availability of facilities for database access via the Java JDBC interfaces has improved conditions for legacy systems access.
Java 1.1 introduced the JDBC Application Programming Interface (API); a set of classes and programming interfaces for executing Structured Query Language (SQL) statements which are modelled loosely on Microsoft’s Open Database Connectivity (ODBC) standard. JDBC allows Java programs to access ODBC compliant databases in pure Java, without using C++ stubs, which makes it possible for developers to write database applications using a pure Java API. JDBC is a ‘low-level’ interface allowing developers to invoke SQL commands directly and providing a base upon which to build higher level interfaces and tools.
The JDBC package provides two useful utilities: the JDBC driver manager, and the JDBC-ODBC bridge. The driver manager simply connects a Java application to the correct database driver. This driver could be a pure Java driver, or via the bridge, an existing ODBC driver can be used as a JDBC driver. The bridge is essentially a method for allowing access to old database systems, or ones that will never have a pure JDBC driver written for them.
The different types of JDBC driver fall into four recognised categories as shown below in Table 1.
Driver Category |
All Java? |
Net Protocol |
1 - JDBC-ODBC Bridge |
No |
Direct |
2 - Native API as basis |
No |
Direct |
3 - JDBC - Net |
Yes |
Requires Connector |
4 - Native protocol as basis |
Yes |
Direct |
Table 1 Driver categories [3]
Direct access to ODBC from a Java program has previously been achieved by using the JDBC-ODBC bridge supplied free as part of the standard Java Developers Kit (JDK). However, there are several key issues that JDBC addresses with respect to ODBC access with Java that provide incentives for using the pure Java approach:
ODBC uses a C interface, and calls from Java to native C code produce drawbacks in security and portability
There are language differences between C and Java e.g. Java does not use pointers, whereas ODBC uses them extensively
When using ODBC the driver manager and drivers must be installed manually on every client machine. If the driver is to be portable and secure on all Java platforms then the driver must be written solely in Java.
In addition, one of the major advantages of mobile agent technology is server flexibility [2]. With a pure Java JDBC driver it is possible to serialise and encapsulate the driver within a mobile agent and dispatch it to a remote server, where it can be automatically installed and loaded. This could have advantages for enterprise integration where changes to a remote database server can be achieved with a single agent. In fact an agent could be given an itinerary and tasked with updating a whole set of remote servers if, for example, a bug was found in the current implementation.
Since mobile agent technology is being proposed by the authors as an integration tool, and the majority of agent environments are written in Java, it too must be capable of utilising these technologies. In consequence, JDBC plays a pivotal role in the proposed pattern for a generic query agent.
The scenario upon which the applications work in this paper is based was derived from data collected during an in depth case study of a specialist vacuum component manufacturer based in the UK. The simplified model used in this paper only describes the Sales/Order process. Other processes like Purchasing and Manufacturing are not addressed in this paper but are likely to be the subject of future work.
An order is placed with the company by a customer. This generates a Sales Order, which has a Product ID associated with it. A query can now be made to the Stock Database requesting allocation of the full product, or subparts if assembly is still required. Successful completion returns the allocation to the sales order with a possible delivery date. If the order can not be supplied, it is possible to generate a Bill of materials (BOM) from the Product ID. Encapsulated within the BOM are details of all the subparts (if any) of the product. A subsequent query is then made to the database requesting allocation of raw materials to manufacture any or all of the subparts not fulfilled. This allocation is then associated with a newly generated Works Order, which is subsequently dispatched to the production scheduler.
In the Sales/Order model, identified in the case study, there are four key component types; stock, sales orders, BOMs and works orders. The proposed agent architecture reflects this real world model but concentrates on the sales and ordering process, requiring three different agent types, one mobile and two static. It is understood that there will also be a need to generate new agents for Purchase Orders or internal Works Orders, when an ordered product is not currently in stock.
The model is based on the scenario faced by the vacuum component manufacturer. Sales outlets are distributed around the world, whilst the central stock warehouse and manufacturing plants are based in the UK. The company has a requirement to add new sales agents to their existing network and possibly new storehouses. For this to be achieved there is a need for an agile and flexible IT system. This model could equally be applied to the sales order process within a virtual enterprise.
An order is placed by a customer; the Sales agent then generates an Order agent that is dispatched to the StockControl agent and requests the fulfilment of its order by passing over an Order object. The StockControl agent queries the stock database to see if enough products are in stock. If there are enough products, the agent then returns a DeliveryDate object to the Order agent which itself returns to its parent Sales agent. If there are not enough products in stock to satisfy the order, the StockControl agent uses the Product ID encapsulated in the order object and queries the BOM database for a list of subparts or raw materials required.
This is then encapsulated within a WorksOrder agent and dispatched whilst the Order agent returns with a DeliveryDate object containing a standard delivery date. If there are not enough raw materials in stock, the StockControl agent generates a PurchaseOrder agent that encapsulates details of all the required materials.
The three key agent types identified are Sales Agents, Order Agents and StockControl Agents. These are discussed in the following section.
Sales Agents are static, Graphical User Interface (GUI) based agents that are responsible for generating Order Agents and dispatching them to the StockControl Agent. These could be resident in a very slim client for a bank of sales persons working on terminals or NetPCs, or even hosted in a laptop for a travelling sales person. They must be capable of keeping track of all current orders that have been placed.
Order Agents are mobile, encapsulating a single order per agent; they are responsible for completion of the Sales/Order process for that order. Valid outcomes could be reporting a delivery date for the product to the Sales Agent, or reporting an allocation for materials and an internal works order number. Order Agents require no interaction with a human operator and so have no GUI.
The StockControl Agent is static, with no GUI. It is responsible for handling all requests for products, parts, or materials, and thus must interface to the stock control database. If the current stock levels are unable to satisfy an order, it must be able to use the encapsulated Product ID to derive the Bill of Materials. How this is achieved would depend on the existing IT system. The BOM's may be kept in a separate database, or be part of the same legacy system. There will also be a need to generate new agents for Purchase Orders or internal Works Orders, when the ordered product is not currently in stock.
When generating StockControl agents which could unify the variety of database systems which could be expected within a virtual enterprise it became apparent that some of the required features of these agents were particular to each database, whilst others were generic to all StockControl agents. In considering this problem the use of a common 'Database Query Agent' was conceived which could be used as a base pattern for all StockControl agents in the system. The advantage of such a technique is the consistency and reusability inherent in using a pattern from which to build agents that are more complex. Indeed, during derivation of the query agent it became apparent that its use could be much wider than this application and it could claim to be generic. The generic Database Query Agent is discussed in the following section.
By taking a modular approach to the design of the Query Agent and using established OO principles, the authors have derived an effective and reusable agent pattern that helps to provide the flexible and extensible infrastructure required by agent system designers. The Query Agent can be decomposed into several key components, as shown in Figure 3.
This must include mechanisms for dispatching, retrieving, shutting down and restarting agents in a suitable host. Most of this functionality is available through the host environment or by subclassing from abstract classes provided by the particular agent environment used in the system implementation. For example, in the authors' implementation using the Aglets Workbench it is usual to extend the abstract Aglet class, and then provide implementation specific details if required.
Figure 3 The Query Agent pattern and examples of DataHandler modules
The Identifier plays an essential role in system security. Whilst it is usual for mobile agents to have the need to carry an Identifier, static agents must also be able to prove their credentials. A key role of the StockControl Agent is to generate PurchaseOrder Agents and WorksOrder Agents in order to fulfil unsatisfied orders. Part of the Identifier is handed to these child agents, as proof of is origin on dispatch to another host.
As distributed computing becomes more prevalent, the number of methods of communication seems to increase. In some examples, simple String matching is sufficient for communication. This can be seen in basic Aglet examples. However the problem of achieving semantic level communication between agents, recognised as both highly advantageous but difficult to achieve, is the subject of much research. The use of KIF and KQML [12] is typical of the more advanced approaches that are being proposed. To handle this variety of communication methods, the proposed pattern includes a Communications Package structured such that it can be interchanged by the designer at will with respect to the system requirements. Its role is to receive the incoming communication from arriving or querying agents and translate this into a format the Business Logic Unit or Database Handler can understand.
In the Sales/Order scenario when an Order Agent is dispatched by the Sales Agent, it encapsulates an Order object. On arrival at the StockControl agent, it is tasked with attempting to fulfil the encapsulated order. This in itself requires some simple rule based logic. Since all the Order agents will require this same logic it is clear that it is better suited to being part of the StockControl agent. By simply handing over the order object and awaiting an answer, the size of the Order agent is kept small, reducing network traffic.
If facilities for autonomy or intelligence were required by the agent they would be implemented in the business logic unit.
The Database Handler deals with all the details of connecting to a database, retrieving information, updating the database, or even switching databases transparently to the requesting agent. It works in tandem with the business logic unit to fulfil the request of the Order agent.
Figure 3 shows the benefits of adopting a modular approach to the design of the Query Agent. The examples shown address a large percentage of the real world situations and the methods currently being employed in the use of databases within an enterprise. The modular Database Handler can easily be interchanged for whatever the situation requires.
In the case where a virtual enterprise, that is already running a mobile agent system, requires a new collaborator, accessing the new information contained within their databases requires only the production of a new Database Handler. If their IT system is sufficiently advanced this could be as easy as linking a JDBC-ODBC bridge to their middle tier, and providing a host for the agent. Very different from the bespoke solutions prevalent until very recently.
In the authors' experience, it is the connection of the Data Handler to a new database, and the required configuration that poses the main problems to software engineer.
For the implementation of the StockControl agent and its resident DataHandler a mock database was created using Microsoft Access. Its contents were based on a products and materials list obtained during the case study. This database was then made globally accessible using the dbAnyWhere server available from Symantec. The mobile agent environment used to develop and test the implementation was the Aglets Workbench, and the StockControl agent was hosted within the Tahitti server supplied with the Aglet package. It was decided that the best way to access the database was to use the driver supplied by Symantec and the JDBC-ODBC Bridge. The implementation was also tested using the native ODBC support present in the Win32 platforms.
In the construction of the Sales/Order agent architecture, it became apparent that to the untrained the hardest part of setting up a StockControl agent was in making the connection, via the DataHandler, to the database. Whilst on the surface a relatively simple task, there are several variables that must be set correctly, and a number of JDBC interfaces that must be used accurately. This can be achieved by continual tweaking of the parameters in an ASCII file, but this can soon became extremely tedious.
To alleviate the problems this caused the DataConnector tool was produced to automate some of the tasks.
The DataConnector Tool is a simple Java program, with a basic UI that allows the user to insert the relevant parameters for connection to a data source. The validity of these parameters can then be tested, and if need be, adjusted and tested again using the refresh, update and test facilities. Once a satisfactory connection has been made, the data can be saved as a serialised java class file.
The functionality of the DataConnector was achieved very simply by linking a UI to two simple java classes. The use of this tool decreased the time taken to set up a new DataHandler, and allows a set of files to be built up containing the connection configuration information.
The biggest advantage in using this tool is the ability to test connections to a database and server across the network, or even the Internet. If a virtual enterprise were to decide to use mobile agent technology as a tool for rapid integration, it is likely that one of the collaborators (or their systems administrator) will have some prior experience in using the technology. The DataConnector tool allows a single administrator to test all the required database connections between the relevant systems, and produce a set of connection information files that can be forwarded to the respective sites. Moreover, if the agent environments and servers have already been set up, a Messenger agent could deliver the files, and the DataHandlers could be completed and initialised automatically. The light weight nature of a connection information file means that continued use of the agent system would allow an administrator to build up a set of predefined files for various configurations which would accelerate the speed with which new collaborators or data sources could be added in the future, increasing the system agility of the enterprise.
This paper proposes the notion that mobile agent technology can be a significant aid in the rapid formation of the information systems that support virtual enterprises. The adoption of Java as the de facto language for mobile agent environments, and its database connection capabilities provided by the JDBC interfaces, ensures mobile agents are fully capable of integrating with legacy and ODBC complaint data sources.
A model generated from a case study identifies three key types of agents required in the Sales/Order process. The authors propose a pattern for database query using agent technology, and a tool to aid rapid integration of existing data sources.
Implementation based upon this pattern has provided flexibility additional to that inherent to the agent paradigm.
The authors thank the EPSRC for their continued support of the work.
[1] Ball et al, 1997, "Enterprise Enablement for Java Applications", XDB Systems.
[2] P.E.Clements, T.Papaioannou, J.Edwards, 1997, "Aglets: Enabling the Virtual Enterprise", Published and Presented at ME-SELA '97. p425, ISBN 1 86058 066 1. Available at http://luckyspc.lboro.ac.uk/Docs/Papers/Mesela97.html.
[3] Hamilton et al, 1997, "JDBC Database Access with Java", Addison Wesley.
[4] http://www.trl.ibm.co.jp/aglets/.
[5] http://www.objectspace.com/voyager/.
[6] http://www.genmagic.com/html/agent_overview.html.
[7] http://www.informatik.uni-stuttgart.de/ipvr/vs/projekte/mole.html.
[8] http://www.meitca.com/HSL/Projects/Concordia.
[12] Finin, T., Labrou, Y., Mayfield, J., 1997, "KQML as an agent communication language", MIT Press, Cambridge, to appear. Available at http://www.csee.umbc.edu/kqml/papers/.