![[INET 2000]](/web/20160103040835im_/http://www.isoc.org/inet2000/cdproceedings/inet00sm.gif)
![[ Up ]](/web/20160103040835im_/http://www.isoc.org/inet2000/cdproceedings/up.gif)
![[Prev]](/web/20160103040835im_/http://www.isoc.org/inet2000/cdproceedings/prev.gif)
![[Next]](/web/20160103040835im_/http://www.isoc.org/inet2000/cdproceedings/next.gif)
The current electronic markets require highly flexible and dynamical computer systems. For example, a supply chain management system, which creates added value by combining and utilizing various information in a network, covers both the Internet and intranets. This makes it difficult for systems to work efficiently if they are designed statically and inflexibly. Moreover, since new business models are continually being developed, quick reconfiguration and dynamical modification are critical in designing the systems.
This paper proposes a way of creating such systems by integrating agent migration, distributed objects, and multi-threading. These are implemented in a network programming language called Mobidget.
The current Internet and intranets contain so many pieces of useful information that many people are trying to create new value by combining and utilizing them. A typical example is a supply chain management system. It collects, combines, and analyzes a huge amount of data involving the amount of stocks and materials, schedules of manufacturing plants, and predictions of future orders from multiple companies, and then makes new manufacturing plans that span remote factories.
Such systems utilize both the Internet and intranets because a lot of data exists on corporate intranets, and companies are connected to each other via the Internet. However, communication environments differ greatly between the Internet and intranets. Generally, the Internet is rather slow and unreliable compared to an intranet, where various access controls are required. Additionally, accessibility depends on the properties of the data itself. Some data is permitted to be cached while other data might require significant transaction management to be accessed. Some is public and freely accessible, while other data might require significant authentication. Consequently, if a system design allows access to such data without considering the variety of environments, its working efficiency or fault tolerance might be degraded.
Moreover, the ways in which data is combined and used on such a system are dynamically changing. With the increasing speed of changes in the business world today, systems should be able to incorporate the logic of new business models into themselves as quickly and easily as possible, since new business models are continually being created and they require the systems to treat new types of data and new methods of processing it.
Therefore, systems such as supply chain management should be able to access data in various environments easily and efficiently, and be able to change their logic flexibly. In this paper, we propose a platform that makes it possible to build such systems.
After first reviewing existing approaches and describing our approach, which integrates agent migration, distributed objects, and multi-threading, we describe a network programming language, called Mobidget, which implements the integration. Finally, we describe a supply chain management system written in Mobidget as an example application.
Many approaches have been applied to building systems that flexibly control their data access (Figure1).
The first approach is to make a system with a centralized server, to which all companies send copies of data stored on their intranets. The formats are fixed initially when the system is designed. Then each company sends the server its data along the designed formats, and it is all combined and processed at the server. The merit of this approach is that the system does not have to take care of the variety of network environments because it runs at the single server. On the other hand, when users want to incorporate a new business model into the existing systems, it takes a lot of time to adapt to new the model, because they have to change not only the centralized server but also components of the system residing in each company. Moreover, in open E-Business environments, where various companies dynamically join and leave a supply chain, it is difficult for the system to adapt to such dynamic changes.
The next approach is to use distributed object platforms such as CORBA. In this approach, the system can adapt to open E-business environments easily, since the only things that are fixed beforehand are the method interfaces, while method contents can be redesigned as and when required. However, the performance and reliability of the system might be low when the communication frequency is high, since such systems must communicate via the Internet every time they need access to data.
The third approach is to use a mobile agent, which brings data and programs, travels around a network, and gathers data. In this approach, it can reduce the number of communications since the agent sends programs to a remote site where they access and process data. Moreover, it can easily incorporate new business models and adapt to the open E-business environments, since the system can send the logic for processing information. However, as agent migration requires expensive data communication, the performance of the system might be worse than in other approaches if they are used on a fast and reliable network. Moreover, it is hard to access data that exists on different sites concurrently because a mobile agent needs to move over servers sequentially.
Therefore, it is hard to build flexible and efficient systems easily using existing approaches. Then, this paper proposes integrating agent migration and distributed objects in a transparent manner, each of which might be conducted by means of multi-threaded execution.
Because system openness is important, our platform is based on agent migration and distributed objects, which already have high flexibility, and we solve their efficiency problems and improve the ease with which the platform can build systems. Specifically, the platform has alternatives of agent migration and distributed objects according to the environments, and supports multi-threading with these functions. These three functions are systematically integrated so that each function can be used without any restrictions.
If we have alternatives of migration and distributed objects, the efficiency of communications in a system can be improved, since agent migration is suitable for situations where data is accessed many times or where a system wants to be strong against a communication failure while processing, and distributed objects are suitable in the opposite situations. However, it is difficult to select the best one at the design stage if the data in the system has various levels of accessibility and are changed dynamically. The proposed platform not only provides all of these functions, but also permits them to be combined in a system, in which agent migration keeps the network-transparency of distributed object completely. When a program accesses remote data via this platform, it can change their inter-computer communication method automatically; if it executes agent migration before accessing data, then agent migration is used, otherwise distributed objects are used (Figure 2). This platform will enable the system to be designed without considering the variety of environments at the design stage, and to be adapted to the environment when it runs.
Multi-threaded functions are important in distributed systems: the system performance might worsen if it collects a lot of data sequentially from multiple remote hosts. Moreover, remote invocation in distributed object systems requires some threads, and multi-threading make it easy to describe processes that have parallelism. Therefore, agent migration and distributed object functions should be able to be used with multiple threads. However, it is generally not so easy to embed complicated synchronization between multiple threads. If multi-threading is designed without due consideration, it will soon cause deadlock. Therefore, we integrate those communication functions and multi-threading to minimize conflict to other threads. For example, since agent migration keeps the whole contexts of a process including multiple threads, concurrent states of their execution does not have any impact. This platform will make it possible for programmers to use multiple threads in distributed environments as if they were a single computer.
The integration make it possible for designers of distributed systems to easily build systems that have both the flexibility of agent migration and distributed objects and efficiency by choosing these functions according to the environment and by using parallel execution based on using multiple threads.
We plan to achieve this integration in a system in which programs are executed on a virtual machine (VM) (Figure 3). Agent migration serializes a process, transfers it, and reproduces it on another computer. A remote object accessing in a distributed object sends a request to the remote computer, creates a new thread there, makes the thread to execute the request, and receives the result from the remote.
Though the functions of agent migration, distributed objects, and multi-threading are not difficult to achieve and have already been extensively implemented, there are two difficult problems in their integration: agent migration in the case of multiple threads and uninterrupted communication for distributed objects during agent migration.
These problems and our solution are described in the following.
Since agent migration serializes and transfers the execution context of a process, the transferred data must be a snapshot of a process so that processing can be resumed without any conflict at a remote site. Therefore, if a thread invokes the agent migration method in a process that has multiple threads, other threads in the process must be safely suspended at that time. However, since there is always the possibility of the process receiving requests from the outside and of some threads executing some machine-dependent functions whose executing status cannot be serialized, it is insufficient to simply call functions to suspend other threads.
We solve this problem by introducing "Caution," a manager of communications and multi-threading in the VM. Programmers no longer need to describe any special synchronization in order to use agent migration with multiple threads because Caution automatically maintains it.
"Caution" consists of the process status and a manager of communications and multiple threads that is controlled by the status.
A process can have three states:
When of all the threads in a process are executing machine-independent functions, the status of the process is NORMAL.
When a thread tries to execute agent migration, the state of the process becomes CAUTION_SET. In this state, all access to the process from outside is prohibited and all of the threads running in the process are requested to stop. A thread that has received a stop request is interrupted at a safe point where it can be serialized, which point is detected by VM. Once all the threads have stopped, the process is serialized and transferred. After it has successfully finished, the original process and the threads are deleted. On the other hand, if it fails, the state of the process is set to NORMAL and all interrupted threads continue their execution.
If the state is CAUTION_SET when a communication function attempts access from outside of the process, the function waits until agent migration has finished.
On the other hand, a thread that is executing machine-dependent functions cannot migrate, since the execution states of machine-dependent functions cannot be resumed on another computer. In order to prohibit migration, the status of the process becomes CAUTION_DISABLED while native functions are executing. If any threads try to call agent migration while the state of the process is CAUTION_DISABLED, it must wait until the state becomes NORMAL.
Figure 4 shows these statuses and behavior.
The use of Caution enables an agent to migrate safely even if it has multiple threads and a safe point for migration has not been specified in their programs.
Since both agent migration and distributed objects are available at the same time and they can work under multi-threaded environments, it is possible that while a thread is accessing a remote object, another thread could execute agent migration to the caller or callee process. Though it is a possible implementation in which agent migration is prohibited while a process is accessing a remote object, it raises the drawback of preventing agent migration for a long time if a process of the remote object access takes a long time -- for example, if it is asleep or suspended on the remote site. It also makes it difficult to describe a program that receives a request from another process, migrates to another computer and processes something there, and returns to the original computer to present the result. To avoid such a restriction, which reduces platform flexibility, the status of communication between processes is managed by VM and messages are delivered properly when agent migration occurs.
Messages for distributed objects are passed between caller and callee threads, and every thread has a name to be identified for message delivery and ownership of objects. First, these threads have an identical name because they must be treated as the same thread for the purposes of managing the ownership.
If a process that has received a remote method call is made to migrate, a thread that is executing a remote method call is simply transferred to the destination host with information about its caller, resumes its execution there, and sends a message containing the execution result to the caller thread after it finishes calling (Figure 5).
If a process with some threads executing a remote method call to another process is made to migrate, the caller threads are transferred to the destination host and they start to wait for result messages there. At the same time, the communication function of the original host saves information about messages for which the caller thread was waiting and the location to which the caller thread has migrated. After that, when a callee thread sends an execution result message, the function in the original host delivers it to the callee thread on the destination host by using the saved information, and then the migrated thread receives the message and continues its execution (Figure 6).
On the other hand, when the callee thread also executes a remote method call, the remote method call holds multi-steps. In this case, multiple threads corresponding to each process are created with the identical thread name. This means that there are many threads with the same name on a network.
If any process with such threads migrates to another host, the communication function must deliver messages for the threads that have moved to the target host. But if some of those processes migrate to the same computer, there might be some threads with the same name waiting for result messages on one computer. In such a situation, the communication function might get confused trying to deliver messages to the correct thread (Figure 7).
The communication function deals with such a situation by managing multiple threads having the same name with a two-dimensional matrix: one axis represents a multi-step remote method call, and the other axis represents multi-hop agent migration (Figure 8). The represented functions are those involving some kind of duplication of the thread. When those functions create new thread, they set a new ID to the thread according to the matrix as well as the common name, which makes it possible to distinguish such threads when the VM delivers messages.
In this way, the communication function makes it possible to deliver messages correctly and continue executing the agent without any conflict, even if a multi-step remote method call and multi-hop agent migration occur.
We are developing a network programming language called Mobidget [1], a platform that implements the integration of agent migration, distributed objects, and multi-threading. Mobidget is a programming language for describing processes for networks, not for computers. Its syntax is similar to Java [2] and has been extended to enable it to describe distributed processes easily. It utilizes both agent migration and distributed object space, each of which might be conducted by means of multi-threaded execution.
Like Java, Mobidget consists of a bytecode compiler and a VM. The compiler is almost similar to an ordinary Java compiler except that it can also handle the small amount of additional syntax, which represents remote method calls, unique to Mobidget. Almost all the characteristic functions of Mobidget are achieved through the VM.
The Mobidget VM is an environment for executing Mobidget programs. It has a bytecode interpreter and Mobidget-specific mechanisms for object management, thread management, and communication functions.
Distributed objects are managed by the VM, which can hold remote reference objects that are proxies to objects in other processes. Accesses to remote references such as field access, method call, and synchronization, are automatically replaced by a communication to another process by the interpreter, in which the status of the communication is managed by communication functions as described above. Remote references are automatically created and updated by the VM. It does not need any special class, such as a stub class.
VM also has a thread serialization function that can save the states of a thread such as being suspended, sleeping, or waiting for synchronization, as well as the Caution function, which makes multi-threaded agent migration available. When programs invoke a native method, VM deals with a machine-dependent function, and prohibits agent migration until it has finished invoking.
The thread system uses an OS thread system with a wrapper for caution management, because we want to switch threads even in a user-defined native method. Each OS thread executes an interpreter in parallel and checks the status of a process periodically so that it can stop its execution safely when a Caution occurs.
This section describes an example of applying Mobidget to a supply chain management system. It shows that the integration makes it easy to build a system that combines various data via both the Internet and intranets.
Figure 9 shows a target system. There are some companies connected by the Internet and each of them has some types of information on its own intranet. Some data must be accessed many times and some only a few times. Some data may be cached and some requires significant transaction management. When companies communicate with each other, security checking and encryption are required.
System requirements are to collect data from each company, analyze it, make production and purchasing schedules, and order material. In addition, when customers order unusual amounts of a product, this interrupts the usual work; so it must make the schedules reactive.
The system has a manager agent, which travels around the companies and collects data and makes proper schedules.
The manager agent has two threads. The main thread checks logistics data, makes schedules, and so on; the other, which is a daemon, periodically checks the status of an order.
The manager agent reduces the number of expensive communication events over the Internet by using agent migration. When it enters the intranet, it spreads out over multiple hosts and works in parallel by distributed objects and multi-threading. After it completes all the jobs on an intranet, it shrinks to one host and migrates to the next company via the Internet. In the intranet, the manager agent migrates to the host that has most frequently accessed the data in the intranet and it accesses other information by remote object accessing. However, if there is information that needs transaction management, the manager agent migrates to the hosts where that information exists even if its access frequency is low.
At the same time, the daemon thread independently sleeps for a while, then wakes up and checks the status of an order, and interrupts the main thread if that status satisfies some condition. When it accesses the order status, it uses remote object accessing whether or not that status exists in the same company because the communication frequency is very low.
If the manager agent cannot decide the most suitable host statically because the frequencies of each item of data on the intranet are variable, all that the manager agent has to do is change the host to which it migrates dynamically. Since agent migration and distributed objects are integrated, all that happens is that some communications are changed from agent migration to remote object accessing automatically.
The main thread does not have to consider the activity of the daemon thread when it executes agent migration, because the daemon thread can continue its execution during the migration whatever the status of the daemon thread is at that time.
As described above, Mobidget makes it possible to build flexible systems that can easily work efficiently.
There are many mobile agent platforms built on Java: Aglets [3], Mole [4], Concordia [7], and so on. Though they can use both agent migration and Java RMI for distributed objects, they cannot keep threads states while migrating because Java does not support thread serialization. That is why it is not so easy to describe a system with those platforms.
Sumatra [5] is an agent migration platform that uses a modified Java VM, which has thread serialization. Since Java has RMI and thread libraries, all functions for agent migration, distributed objects, and multi-threading are available on such a platform. However, it is hard to use those functions at the same time because they are not designed for their combination.
Voyager [6], a system that integrates agent migration and distributed objects, can use these two functions simultaneously, but it cannot support multi-threaded migration because it is built on Java.
As far as we know, any other systems that integrate all functions systematically are not found.
On the other hand, we have found a problem in our approach. It is robustness. This platform automatically executes a remote object accessing according to locations of a process and data, which does not need any special description such as an interface declaration. Because of this feature, the compiler cannot detect the place where remote accessing might be done when it reads a source code. This means that it also cannot detect the place where exception handlers for the communication failure should be written. Though programmers, who know the place exactly, can write the exception handler, it would be better if the compiler could check missing handlers, as Java can. We have not found a useful solution for this problem.
This paper describes that integrating agent migration, distributed objects, and multi-threading are useful for building distributed systems that span both the Internet and intranets, such as supply chain management systems. This integration has been implemented in a network programming language Mobidget. In addition, the paper discusses an example in which Mobidget is applied to a supply chain management system, which shows that integration makes it possible to build such systems easily with flexibility and efficiency.
Mobidget has already been implemented and is available on Win32 and Solaris. In the future, we will improve the performance of the interpreter, and apply it to actual supply chain management systems.
The authors would like to thank Dr. Satoshi Goto, Dr. Shiro Sakata, and Dr. Nobuhiko Koike of the R&D Group at NEC Corporation for their encouragement and advice.