The RPC mechanism helps programmers to develop a network application easily; programmers can replace the remote procedures with the special local pro-.
The Flying Object for an Open Distributed Environment Kentaro Oda, Shin’ichi Tazuneki, Takaichi Yoshida Department of Artificial Intelligence Kyushu Institute of Technology 680-4 Kawatsu, Iizuka 820-8502, Japan Phone: +81-948-29-7634, Facsimile: +81-948-29-7601 ken,shin,takaichi @mickey.ai.kyutech.ac.jp
Abstract We propose the flying object that adapts itself to the environment by means of the dynamic behavior change mechanism. The flying object is user-defined, first-class and abstract entity. Such properties provide independency and transparency. The flying object model establishes a unique decomposition of the flying object. In this model, the flying object consists of four objects: the delegator that encapsulates the implementation, the message handler that interprets the messages, the event handler that provides adaptation strategies and the context object that holds a state beyond the adaptation. The ability of accommodation, the openness, is one of great contributions of this model because many functions such as object migration, load balancing, distributed transaction management, the communication protocols and even adaptation strategies can be introduced by the message handler and the event handler as a plug-in module. Furthermore, a source code translation technique is introduced for automatic decomposition of the flying object as a replacement for the virtual machine customizations or low-level programming. The delegator and the context object are instantiated from the same translated class to minimize maintenance costs of classes as a result of an automatic translation. Therefore, the system organized by the flying object is best suited for the open distributed environment.
1. Introduction In a distributed object-oriented environment, objects can run concurrently on different computers connected by a network. In such application, programmers must write programs for transferring data over a network. Therefore, in order to help programmers, it is necessary to provide the higher abstract mechanism for clean distributed programming with network transparency including location trans-
parency, access transparency, migration transparency, etc. In a general way, programmers can use two methods, the remote procedure call (RPC) and the proxy object method, so as to exchange messages between objects running in such an environment. The RPC mechanism helps programmers to develop a network application easily; programmers can replace the remote procedures with the special local procedures, called stub generated by RPC generator automatically. Therefore, programmers need not to be conscious how the remote procedure call is invoked through a network. In the proxy object method, the proxy object is an intermediate that can send a message to a remote object through a network. Therefore, the object can send the message to another object even if the receiver resides in a different address space, because the message is sent to the receiver’s proxy object, which is in the same address space as the sender. Furthermore, today, the distributed computing tends to be wide spread and performed beyond the many different kinds of software/hardware architectures. Here, the open distributed environment is defined to as the environment that can accept new architectures/mechanisms to accommodate heterogeneity. Since the open distributed environment can change from time to time, it is not guaranteed assumption that existing services or languages are suited in the future. In such environment, it is necessary for the system to be adapted to accommodate both 1) evolution like software/hardware updates, and 2) changes in the execution environment like power loss, network disconnection, high computation load, etc. In order to adapt to the latter case, the system should be dynamically reconfigured. Thus, an abstraction mechanism for adaptation should be introduced for the system. In this paper, we construct the abstract mechanism that provides network transparency and adaptation. We also attempt to minimize requirements to implement the mechanism so as to make it widely accepted. Such requirements vary from low-level to high-level. For example, modify-
ing code-segments for dynamic reconfiguration is low-level requirements, replacing object management strategies like object allocation, object accessing, garbage collection for a distributed environment is higher-level requirements. Computational reflection is typically used to fulfill the latter requirements, but such full-fledged reflective language is a special; not used in common. The remainder of this paper is organized as follows: Section 2 – motivation, Section 3 – our proposed model and mechanisms, and Section 4 – source code translation and implementation. In the last sections, related work, discussions and conclusions are presented.
the protocols are suited for the future. Therefore, we considered a design policy for an open distributed environment as follows: The abstraction mechanism should not rely on a specific OS, ORB, or language. Dependencies on such systems should be minimized.
A distributed object should be provided as a first-class object. Do not enforce programmers to use special procedures to access the remote objects to provide network transparency.
2. Motivation It is necessary to provide two properties for an open distributed environment. The first is network transparency to access remote objects including replicated objects, transaction-aware objects etc. for clean distributed programming. The second is an adaptation for a changing executing environment including power loss, network disconnection, high computation load etc. Thus, we introduce an abstraction mechanism that provides these properties. The abstraction mechanism can be implemented on several levels. For this, we observed the followings: 1. Build up a new operating system, we would have to pay the high cost for it.
The overhead originated from this mechanism should be minimized.
However, to minimize dependency on underlying systems or languages is difficult because no commonly available functions could be used for the abstraction mechanism. For example, reflection supported in reflective languages is powerful and useful for constructing these mechanisms, but it is not available in other languages. The abstraction mechanism that we construct should minimize requirements. This would suggest that we have to implement the mechanism only in the framework that commonly used languages provide.
3. The Flying Object 3.1. Approach
2. To customize virtual machines for an interpreted language, customization is necessary for each virtual machine. 3. To use meta-level programming in reflective languages (like CLOS, ABCL/R), these languages are powerful but not used in common. 4. To extend ORB (Object Request Broker), we would rely on specific architecture. In addition, those architectures have a common problem – high dependency on existing systems including languages and communication protocols. For example, modification or re-design and re-implementation would be required if the underlying system is updated. Although, systems including languages, OSs, and also the communication protocols or standards should be widely accepted in an open distributed system, it is difficult to cover all systems because the implementation used in such systems would have a tendency to be built for a specific standard or a protocol. For example, the CORBA ORB would be designed for CORBA standards. This is problematic since the open distributed environment change from time to time. In other words, it is not guaranteed assumption that existing services or languages even
In this paper, we proposed an object for an open distributed environment, called the flying object. The flying object is an entity, that is user-defined, first-class and able to adapt itself to a changing executing environment. The flying object owns two major properties, network transparency for clean distributed programming, and adaptation by means of the dynamic behavior change mechanism in its executing environment. Through encapsulating, the flying object provides network transparency. To adapt the environment, the flying object decides to change its behavior rather than updating a system in offline. This adaptation is triggered by an event that gives the information about the environment change. The flying object model minimizes dependency on underlying languages or systems by introduction of both its decomposed structure and the source code translation technique. This model lies on top rather than under the language because no customization is necessary on an underlying system such as virtual machines. However, the system organized by the flying objects has no kernel, while the previous solutions would have a kernel. Instead, some runtime libraries are plugged into the flying object to include new protocols, functions, and even adaptation strategies in a modular fashion. Thus, the system organized by the flying
object provides the ability of accommodation, i.e. openness. Our model has been implemented in general object-oriented language Java without customization on virtual machines or native calls. In the programmers’ perspective, the flying object is provided as a first-class object in general objectoriented languages. The source code describing the flying object is not only written by the application programmer but also automatically translated into a new code internally by a source code translator (which is integrated to the compiler as a preprocessor) and then the flying object class is generated. Therefore, the application programmers would be able to write classes for general distributed applications in a straightforward way.
3.2. The Flying Object Model To implement the flying object, first, we should design the model for the flying object. In this model, the flying object is made to consist of four objects at runtime, even though it is logically one entity. This decomposition approach has an advantage of flexibility; the decomposed simple parts are replaceable even at runtime. We apply this advantage for adaptation and openness. Furthermore, the decomposition approach matches our demand, the minimizing requirements for wide availability, because the implementation in this approach would be closed within the framework provided by languages. However, who decomposes it? Application programmers must never decompose it because the decomposition is system side details that must be hidden. In addition, complicated coordination of parts is incurred. How to handle this? To answer these questions, we introduce the source code translation technique that enables to decompose the flying object automatically. To reduce runtime overhead, this translation is applied to the source code at compile-time. Thus, our model can completely give an illusion that the flying object serves as one entity for programmers and users. It is necessary to present the flying object as one entity, because the structure of the flying object is system side concern that must be separated from application programs. To gain maximum flexibility, the flying object is split into four objects as follows: 1. The delegator: Designated for receiving and packing all messages, which are sent to the flying object, and then forwarding them to the message handler. The event, which provides the environment change, is forwarded to the event handler. The delegator owns all methods whose name is the same as user-defined one but not the implementation. The delegator implementation is intended to forward all messages instead of user-defined implementation. The delegator also has a mechanism to change bindings of the message handler and the event handler. This mechanism is called
the dynamic behavior change. This is an object whose clients believe it as if it were the flying object. 2. The message handler: Interprets the messages received by a delegator. The message handler owns one method for receiving packed messages. For example, some message handler could have multiple threads for concurrent handling messages to enhance parallelism. Then, the flying object acts as a concurrent object. The message handlers have a lot of variety of its implementations such as remote method call, replication consistency management, distributed transaction processing support, providing information for debugging or profiling, etc. 3. The event handler: Provides strategies for adaptation. For example, object migration is one of the strategies to adapt for the high computation load environment. The event handler interprets incoming events and reconfigures the flying object structure to adapt the environment by means of the dynamic behavior change. The event handler is supplied as a plug-in module as well as the message handler. 4. The context object: Holds a state of the flying object beyond the adaptation. It has instance variables and the same methods as described in a user-defined class. The context object not only keeps a state but also provides a mechanism of serialization, which translates itself into a byte-stream representation. In this model (shown in Figure 1), the delegator receives actually the message sent to the flying object. However, from the client point of view, the delegator is really the flying object. When receiving an incoming message, the delegator packs and forwards it to the message handler. The message handler interprets the packed message and handles it. For example, a message handler can forward packed messages to a remote host. This message handler makes the flying object acting as the proxy object. Various message handlers may be considered here.
The context object The flying object
The message handler The event handler The delegator
Client view
Internal structure
Figure 1. The Flying Object Model
This decomposition of the flying object enables to change the binding to the message handler into new one during runtime. This is the dynamic behavior change mechanism. A switching of the message handler implies behavior change. For example, the behavior of concurrent objects would be replaced into the behavior of a proxy object after migration so as to ensure migration transparency. In general, the dynamic behavior change is used for adaptation. Adaptation is triggered by the event. From the client point of view, this switching is done behind the delegator in order to encapsulate the change. The event handler encapsulates complicated reconfiguration steps from others. The provision of the context object is necessary to preserve the flying object state beyond the adaptation. Thus, the clients can access the flying object uniformly regardless of its configuration. This is what we call transparency in this model.
change. The following example shows reconfiguration steps for object migration to spread computation load. Object migration has been done by means of the dynamic behavior change mechanism. Several steps are required to realize the dynamic behavior change, in the following example, from step 4 to step 9 corresponds to. The event handler controls this overall complex reconfiguration steps.
3.3. The Message Handler – a plug-in extension module
1. Receiving an event, the delegator forwards it to its event handler bound to.
All messages sent to the flying object are handled by the message handler. This implies that the flying object is under the message handler control. Therefore, the message handler can introduce various functions. For example, the flying object acting as a proxy object could allow users to be accessed regardless of its location (location/access transparency). A message handler working on consistency control introduces a replication mechanism. This provides replication transparency. Object migration, load balancing, dynamic objects allocation among several hosts, distributed transaction processing and a mechanism for both debugging and profiling would be introduced by the message handler while still holding transparency. Even though, our profiling mechanism provides little information such as the method name invoked and the time consumed during a method execution, the flying object can be profiled and debugged dynamically in spite of the system stop with no recompilation for embedding debugging information. Whereas such functions might have history that those are embedded in the system on an ad-hoc basis, the system organized by the flying objects not only can provide those functions but also can introduce them in a modular fashion.
3.4. The Dynamic Behavior Change – a mechanism for adaptation A mechanism for adaptation, the dynamic behavior change, is achieved by changing the bind to the message handler (and the context object, if needed). The adaptation is triggered by the event that gives information about execution environment change like power failure, high computation load, network disconnection etc. The monitor object is introduced in order to detect the execution environment
Assumptions: A monitor object detects high computation load, raises a corresponding event and notifies to a heavy loaded flying object. The migration takes into action from the emigrant host to the immigrant host. The former might be heavy loaded, and the latter might be idle. The service that accepts migration objects is running on the immigrant host. The following steps are done in the emigrant host except step 6.
2. An event handler makes a decision on object migration by an event. (Another event handler would take another action for it.) 3. An event handler selects an immigrant host with strategies such as selecting the lowest loaded host among the neighborhood. 4. An event handler requests to a delegator to lock a flying object in order to prevent inconsistency. Critical section begins here. A delegator tries to lock a flying object negotiating with a message handler; the message handler can detect whether the flying object is running or not. If the locking succeeds, it must be guaranteed that no message will be processed in current and in the future. This trial continues until the lock is obtained. 5. An event handler sends a context object to restart the service on the immigrant host. 6. On the immigrant host: An immigrant host accepts a context object and builds a flying object from it. A flying object starts to begin the service. 7. After sending a context object, an event handler requests for a delegator to switch another message handler that can forward the messages to an immigrant host. 8. A delegator can safely switch a message handler to another. Consequently, a local flying object would act as a proxy object for an immigrant. 9. An event handler requests to a delegator to unlock a flying object in order to handle consecutive messages. Critical section ends here.
In the above steps, the migration would be made only if the flying object is not in running state to prevent inconsistency. Thus, a migration transparency is satisfied. This example shows that the flying object tries to change itself to adapt the high-loaded environment by means of the dynamic behavior change mechanism. Here, object migration is taken into action as a result of adaptation. Another adaptation strategy can be introduced as well as the message handler.
A user program
Foo.java The delegator Instantiate Instantiatewith withnormal normaloperation, operation,the the ddefault efaultbinding bindingisisused; used;the thedefault default essage handler m message handlerisisimplicitly implicitlybound. bound.
A compiler integrated with a translator
The context object Foo.class
Using Usingthe theinstantiation instantiationbinding, binding,the thecontext context object objectisisinstantiated instantiatedby bysupplying supplyingan anNULL NULL rreference eference as asan anmessage messagehandler. handler.
4. Source Code Translation & Implementation We implement the flying object mechanism in Java without using native interfaces. The developed translator takes the Java source code as input and generates the modified source code. The translator is integrated with the compiler as a preprocessor. Thus, the flying object class is generated seamlessly in the compile time from the source codes written by programmers. Our source code translator is designed for two purposes: 1) To help the automatic decomposition. For example, the delegator needs to pack and forward all incoming messages to the message handler. The locking mechanism for the flying object is also needed. Whereas, such implementation is required but must not be written by programmers. The translator embeds such a snippet of code into the source code. 2) To reduce the cost to maintain a lot of classes. It is annoying to maintain a lot of classes such as Foo Impl.class, Foo Proxy.class, Foo Stub.class, etc. Having the same method names, the context object and the delegator can be instantiated from the same class as a result of a translation (as shown in Figure 2.) Our translator with the flying object model can be considered to unify such classes and more rich classes into one class. Therefore, our translator provides simplicity for straightforward compilation and reducing the maintenance cost. From compile-time to runtime, we can relax to determine the behavior of a class lazily. In the source code translation, the translator inserts a few statements into the beginning of each method defined in a class. As the inserted statements mean to pack the messages and forward it to the message handler, all method invocations to the flying object are delegated to the message handler bound to. There are three ways to bind the message handler: The default binding: the default message handler is bound to the delegator, if no message handler is explicitly supplied. The default message handler owns the minimum function to run the flying object. Programmers would use this default binding regardless of their knowledge.
The instantiation binding: the behavior of a flying
Figure 2. Runtime Environment object is determined when it is instantiated; the reference of the message handler is supplied as a constructor’s last parameter. The runtime library uses this binding rather than programmers.
The dynamic binding: the behavior of a flying object is changed via the event, which is raised by an execution environment change. Not only the monitor objects raise the events, user object can raise the event too. The raised event is sent to the flying object as a message by calling listenEvent() defined in the delegator. In listenEvent() method, the delegator forwards the event to the event handler. The event handler should handle such a user-defined event.
As the context object and the delegator are instantiated from the same class, this class is needed to switch two implementations at runtime. For this, our translator inserts an IF-statement in the beginning of all methods with statements meant to pack and forward. The evaluation of the IF-statement is extremely lightweight because to check whether a reference is null or not is all the task of the statement. Thus, performance degradation originated from a unified class would be ignored in spite of laziness.
5. Related Work Apertos[2] is an object-oriented reflective operating system for an open distributed environment. The framework of apertos provides object/metaobject separation. The separation of object/metaobject is similar to our decomposed structure as well as the metaobject in apertos is also similar to our message handler in terms of those would provide as system-side services. However, object migration in apertos is special because it is viewed as a basic mechanism to accommodate heterogeneity in contrast to the flying object that adapt itself to the environment by means of the dynamic behavior change. In other words, whereas the object would be migrated to adapt in apertos, the flying object reconfigures itself for adaptation. While apertos interprets object
migration in such a way that an object changes its group of metaobjects, object migration in our model is one of the solutions as a result of the adaptation. Like apertos, OS is one of the approaches to implement the abstraction mechanism mentioned above. We think it is important to be able to implement such a mechanism widely available because of openness even if the approach of OS can avoid performance degradation. Voyager[1] is a Java based distributed object technology like Java RMI, HORB, CORBA, etc. Voyager supports connectivity to other object models, several messaging services, unified name spaces, replaceable transport and even mobile agents with plain Java virtual machines. However, this does not meet our demands due to lack of adaptation. Our final goal is still far from it.
6. Discussion The flying object can be considered as follows: A higher abstract entity rather than an object because it hides what implementations are chosen and executed during runtime regardless of its client knowledge.
A higher transparent entity because the flying object would provide accessing transparency, location transparency, replication transparency and others.
An independent entity rather than an (distributed) object, which is based on the specific architecture like CORBA and DCOM because of no kernel; a set of the flying objects organizes a system.
Not only for the open distributed environment purpose, the flying object model gives other interesting applications too. We show two examples. The first is a framework for multi-agent systems. Multi-agent systems inherently need communication mechanism, and mostly need migration and security mechanisms. Our model is also well suited for multi-agent systems because of provision for openness and encapsulation of those mechanisms. The second is debugging and profiling support for software development. The debugging mechanism with our model would give little information, however, debugging and profiling can be started dynamically on demand with no recompilation. This is also helpful for monitoring object activity. In another perspective, we can interpret our model as follows:
The model corresponds to a delegation model because the delegator passes the messages to the message handler, which has a responsibility of handling all messages. The difference between two models is that in
our model, all messages are sent to the message handler whereas in the traditional model, messages are selectively delegated to the parent object (in conventional prototype languages.)
The abstraction mechanism that the flying object owns can be interpreted to meta-level architecture in terms of computational reflection. We can say that the system is reflective if its computational process is customizable within the same language or framework. Thus, the system organized by the flying objects can be called a reflective system and its architecture can be called metalevel architecture.
7. Conclusions and Future Work We proposed the flying object that is a user-defined, firstclass, independent, transparent and abstract entity for the open distributed environment. The abstraction mechanism, which provides network transparency and adaptation is incorporated into the flying object as a built-in mechanism. The message handler can introduce many functions such as remote method call, distributed transaction support, debugging or profiling mechanism. The event handler can introduce adaptation strategies like object migration, object suspending and object evolution. These functions and strategies are accepted as a modular fashion rather than on ad-hoc basis. Furthermore, the source code translation technique is introduced for automatic decomposition of the flying object as a replacement for the virtual machine customizations or low-level programming. The flying object consists of four objects, the delegator that encapsulates the implementation, the message handler that interprets the messages, the event handler that provides adaptation strategies and the context object that holds a state beyond the adaptation. The delegator and the context object are instantiated from the same translated class to minimize maintenance costs of classes as a result of an automatic translation. Therefore, the system organized by the flying object is best suited for the open distributed environment. We recognized the following as a future work. The security issue originated from this model has not yet been considered such as illegal changing of the message handler. We should evaluate the performance through some experiments. More message handlers and event handlers and another language implementation of this model are necessary.
References [1] ObjectSpace. VOYAGER ORB 3.3 Developer Guide. 2000. http://www.objectspace.com/. [2] Y. Yokote. The apertos reflective operating system: Concepts and its implementation. In proceedings of OOPSLA, October 1992.
