2. Basic Idea of Wapplet Framework

1. INTRODUCTION In the ubiquitous computing environment, various kinds of networked devices can be used in coordination with each other. Accordingly, the function of each device can be reinforced by other devices, when they are coordinated properly. Let us assume, for example, that a user executes a music playing application on a computer with poor sound-output performance. The user can still enjoy the music play application comfortably, if some high-performance sound output device can be activated in coordination with the user’s computer.

For such coordination, the following three functions are necessary: device lookup, device coordination, and switching of devices under operation. We have already designed and implemented ASAMA (Adaptive Service Availability MAnagement) for device lookup [1]. For the other functions, Wapplet framework was designed [2], although it has not yet been implemented. In addition, the validity of the design needs to be confirmed.

This paper describes how to realize device coordination and device switching based on the Wapplet framework. The implementation proposed in this paper is characterized by three features. The first feature is that the locations (e.g. IP addresses) of networked devices are concealed from application programmers and end-users; they can use the networked devices without considering the location of the devices. The second feature is that, in the present implementation, the device switching is achieved by code migration. This enables application programs to adapt to changes in available networked devices caused by users’ movement. Additionally, this also makes pre-installation of all applications on networked devices unnecessary. The third feature is that our framework provides device-independent application programming interfaces (APIs) that define interfaces to networked devices. These APIs eliminate the necessity to change device control programs for every device.

The rest of this paper is structured as follows. Section 2 describes the basic idea of the Wapplet framework and compares it with work reported so far. In Section 3, our implementation of the Wapplet framework, especially device coordination mechanism, is explained in detail. In Section 4, we evaluate the processing time of location-transparent method invocation in a real network. Finally, we summarize this paper and state future work in Section 5.

2. BASIC IDEA OF WAPPLET FRAMEWORK This section discusses requirements of an application framework for the ubiquitous computing environment, and then describes conventional work related to this paper. We also introduce the architecture of the Wapplet framework in this section.

2.1 Requirement Analysis Requirements of the Wapplet framework are as follows: (a) support for object-migration, (b) location transparent method invocation, and (c) abstraction of device specifics. Object migration is necessary in the ubiquitous computing environment because it is impractical to pre-install all applications on networked devices. Thus, applications should be composed of multiple mobile modules. Location transparent method invocations like RPC (Remote Procedure Call) help application programmers in coordinating networked devices. To realize abstraction of device specifics, the framework needs to provide device independent Application Programming Interfaces (APIs) that define interfaces to networked devices, which eliminates the need to change device control programs for every appliance.

2.2 Related Work We present previous work related to this paper, namely Hive and MetaSpace, and then discuss whether these two related work can achieve our requirements. 2.2.1 Hive Hive [3] is an agent based application framework to realize coordination among networked devices. Java RMI enables Hive agents to cooperate with each other and to migrate into machines. The Hive architecture is similar to that of our Wapplet framework in control mechanism of networked devices. Hive agents does not directly control networked devices, but control them using shadow objects. Shadow objects are interfaces encapsulating local resources of networked devices. Therefore application programmers can easily build device-independent agents.

However, Hive does not meet our requirements due to two problems. One is that Hive supports only 1-hop migration of mobile agents. It means that application programs can not adapt to changes in available networked devices caused by users’ movement. The other problem is that application programmers need to obtain new network addresses of Hive agents when they travel to another machine. This is because Java RMI does not completely encapsulate network addresses of mobile objects from application programmers.

2.2.2 MetaSpace Application programmers can easily build distributed applications by using MetaSpace [4], since it supports device coordination and migration of mobile objects. The device coordination system in MetaSpace realizes the location transparent method invocation by extending Java RMI. Accordingly, application programmers do not need to be aware of IP addresses of mobile objects. In addition, Java RMI enables the migration system in MetaSpace to transport mobile objects to another machine.

Although MetaSpace realized our requirement (b), it does not accomplish other requirements, (a) and (c). The migration system in MetaSpace, as that in Hive, supports only 1-hop migration of mobile objects. Moreover, MetaSpace does not define device independent interfaces to networked devices. This forces application programmers to consider specifics of networked devices and ways of controlling them.

2.3 System Architecture of Wapplet Framework We explain the terminology of the Wapplet framework, and then describe its design in detail.

2.3.1 Terminology Before describing each of the systems in the Wapplet framework in detail, we summarize the terminology of the Wapplet framework.  Controllers: Controllers are users’ terminals including PDAs (Personal Digital Assistants), wearable computers, notebook computers and cellular phones. They are equipped with IEEE802.11b standardized devices or Bluetooth devices to communicate with and control surrounding devices.  Service Providers: Service providers are networked devices that provide users with input/output facilities of media data. Service providers are classified into eight groups by media types. These media types are text, image, video, and sound input/output (Table 1).

2.3.2 System Design We designed the Wapplet framework that satisfies the above requirements. Figure 1 illustrates the architecture of the Wapplet framework. In the Wapplet framework, Mission system [5] works as an interface between end-users and applications. The Mission systems on controllers initialize and activate applications cooperating with the Wapplet communication base. The Wapplet communication base is an application runtime that provides device coordination, device switching and device independent APIs for application programmers. Unlike Mission system, the Wapplet communication base runs on both controllers and service providers. Table1: Service Provider Types.

Types of Service Providers Example T h Text Input Keyboard, scanner e Text Output Display, printer Image Input Camera, scanner a p Image Output Display, printer p Video Input Video camera l Video Output Display, projector i Sound Input Microphone c Sound Output Loud speaker, headphone

Figure 2: Structure of Config module.

Figure 1: System architecture. ation style of the Wapplet framework is different from that of conventional ones. An application in the Wapplet framework, Wapplet, consists of multiple Wapplet modules and one Config module. The Wapplet module is a mobile object, and bound to a certain service provider type (shown in Table 1). The module controls service providers using our device independent APIs.

The Config module is an XML file that maps each Wapplet module to service provider types. This module provides the Mission system on a controller with the information of service providers that Wapplet modules utilize. This enables the Mission system to ask directory services such as ASAMA to search for necessary service providers. Figure 2 shows the description of the Config module.

In the next section, we describe how to realize device coordination, device switching and device independent APIs, and explain the mechanisms of these functions.

3. IMPLEMENTATION This section presents our implementation of the Wapplet framework. In this implementation, we implemented the Wapplet communication base that supports device coordination, device switching by module migration, and APIs to control networked devices. All systems were built on FreeBSD 4.2RELEASE with Java 1.2.2. 3.1 Location Transparent Method Invocation Location Transparent method invocation (LTMI) means that a master module1 can invoke slave module2 without being aware of the location of the slave. We first describe our approach to the location transparency, and then present the mechanism of LTMI.

3.1.1 Approach to Location Transparency The RPC (Remote Procedure Call) such as Java RMI and Sun RPC is an effective way of device coordination, since it enables application programmers to easily invoke remote methods of mobile objects. In the RPC, a client program and a server program do not directly communicate with each other. A stub module automatically produced by the RPC systems on the client host forwards the message from the client to a skeleton module on the server host. The client program only invokes the stub module on the local host, since the stub module processes the network layer instead of the client program.

However, most RPC systems require application programmers or end users to inform client programs of servers’ location (e.g. IP addresses). It is impractical to do such an action every time when they coordinate networked devices.

Therefore, we developed a “module database” which stores Wapplet module information (WMI) and works on every networked device (controllers and service providers). A module database on a controller keeps all information of Wapplet modules managed by the controller. On the other hand, a module database on a service provider manages only information of Wapplet modules stored in the service provider. The module databases on a controller and a service provider updates the WMI entries, when new Wapplet modules are created or migrate to the service provider.

The module database maps Wapplet modules to their locations, like WMI. W represents the ID of a Wapplet module and H is a network address of the module. In our implementation, W is defined as Figure 3 shows. The Mission system automatically produces a serial number of the Wapplet module, when this module is created at the first time.

Figure 3: Wapplet module ID that is uniquely identified in the Internet.

3.1.2 Mechanism of Location Transparent Method Invocation Our LTMI system automatically determines the way of method invocations: local or remote. Figure

4 illustrates the LTMI mechanism with an example where a master module, WA, controls a slave

module WB. Suppose the following event: WA invokes WB through the local method invocation, WA

moves from H1 to H2, and WA invokes WB again.

WA invokes an invoke(WB-N, MB, V) method that is implemented in WA’s super class. MB-N is a

name of MB, MB represents a method name of WB, and V is values of M’s arguments. After the

invoke method is called, the LTMI system on H1 searches the module database on H1 for WB’s IP

address. Since WB’s IP address returned from the module database is the same address as that of

WA, the LTMI system on H1 directly invokes WB by the Java’s reflection facility (Figure 4(a)).

1 A Wapplet module intending to control another module. 2 A Wapplet module.being controlled Figure 4: LTMI’s mechanism of local method invocations.

Figure 5: Algorithm to avoid invocation misses.

Now WB travels to H2. The module database on H1 changes WB’s IP address entry (WMI

H2>), while the module database on H2 creates a new entry WMI. At the same time, the module database on H2 stores WB object in its WMI (Figure 4(b)).

Now WA invokes WB’s method, MB, again. As in local method invocation, WA invokes the invoke(WB-N, MB, V) method, and then the LTMI system on H1 obtains WB’s new IP address H2 from the local module database. After that, the LTMI system on H1 forwards an executing command of invoke(WB-N, MB, V) method to the LTMI system on H2. H2’s LTMI system invokes

MB by Java’s reflection facility (Figure 4(c)). Consequently, WA can control WB without being aware of WB’s location.

3.1.3 Algorithm to Avoid Invocation Miss

Figure 5 shows a more complex case. Suppose now that WA on H1 migrates to H2, and WB on H1 travels to H3. WA remotely controls WB.

As Figure 5(a) illustrates, WA and WB on H1 migrate to H2 and H3 respectively. The module database on H1 modifies WMI entries: WMI to WMI and WMI to

WMI. At the same time, the module database on H2 updates WMI entry (WMI

H2>), and that on H3 also changes WMI entry (WMI).

Now WA remotely invokes WB. WA invokes the invoke(WB-N, MB, V) method (Figure 5(b)), but the Figure 6: Module migration mechanism.

Fi LTMI system on H2 can not obtain the information WB’s new IP address from the local module database. This is because the module database on H2 does not keep WMI entry for WB.

To address this issue, we improved the module database as follows. When a caching miss occurs on a certain host, the module database on the host obtains the controller’s IP address from Wapplet module ID of WA, and then updates WMI entry for WB by inquiring the controller’s module database (Figure 5(c)). After this operation is finished, the LTMI system on H2 forwards an executing command of invoke(WB-N, MB, V) method to that on H3. H3’s LTMI system invokes MB by using Java’s reflection facility (Figure 5(d)).

3.2 Module Migration System Module migration system transports Wapplet modules to another machine by Java’s serialization mechanism. This migration system supports multi hop migration of Wapplet modules, which enables users to dynamically change networked devices that they utilize. It is important for the module migration to transport class files of Wapplet modules, together with their objects. The reason is that some networked devices can not load transferred Wapplet modules on their memories without the class files. Therefore, our module migration system supports a network class loader that can obtain class files in remote hosts.

Figure 6 shows the mechanism of the module migration. Suppose now that a Wapplet module, W, migrates from H1 to H2, and then travels to H3: H1 is a controller, and both H2 and H3 are service providers. Figure 6(a) illustrates the initial condition of this case. The module migration system on

H1 transports W by using a goModule(W, H2) method. This method enables users to transport Wapplet modules by using Java’s socket libraries. After the migration is finished, module databases on both H1 and H2 modify WMI entries from WMI to WMI (Figure 6(b)).

Now W moves to the other machine, H3. The module migration system on H1 commands the module migration system on H2 to invoke its goModule(W, H3) method. H2’s module migration system transports W to H3, and then each of the modules databases on H2 and H3 modifies WMI entries (WMI to WMI), as Figure 6(c) shows.

3.3 Device Independent APIs Device independent APIs provide application programmers with eight interfaces to control service Figure 7: Examples of device independent APIs. providers: text, image, video, and sound interfaces for both input and output. These interfaces define methods to control service providers. Figure 7(a) shows an example of the interface for audio output. Application programmers do not need to build libraries to control service providers, but only create Wapplet modules utilizing these interfaces as shown in Figure 7(b).

On the other hand, to control service providers, service provider administrators must build a driver program which implements one of the APIs (Figure 7(c)), and then bind the driver program to the Wapplet communication base on a service provider. When a Wapplet module moves to a certain service provider, the daemon program of the Wapplet communication base automatically links the APIs utilized in the Wapplet module to appropriate driver programs of the service provider. Java’s polymorphism allows this dynamic linking. Consequently, device control APIs becomes independent of service providers’ specifics and device control programs.

4. PERFORMANCE ANALYSIS To evaluate the efficiency of LTMI, we measured the processing time of LTMI in comparison with Java RMI in this section.

4.1 Evaluation Scenario Table 2 describes the experimental machines. Host A is equipped with a wireless communication device based on IEEE802.11b, and host B can communicate by 100Mbps-Ehternet. In this evaluation, the following scenario is supposed: a Wapplet module on the host A invokes a local method, and then a Wapplet module on host A invokes a remote method of a Wapplet module on host B. In these invocations, we changed the size of arguments from 0 byte (no argument) up to 2 M bytes. 14000 T ) c e a s 12000Host A Host B ) m c ( 25000 e

CPU E Intel StrongARM 32bit-RISC 206MHz AMD Arthlon 600MHz b s 10000 M m I (

Memory T 64MB 128MB E l 20000

M 8000 G OS I Familiar Linux ver 0.4 FreeBSDJava 4.3 RMI Release T N e I G S 150006000 JavaLTMI RMI N S I LTMI E S C S 100004000 Direct E O C R O P 2000

R 5000 P 0 00.7 0 0 400400 800800 120012001600160020002000 )

c 0.6 e s SIZE OF ARGUMENT(Kbyte) m

( 0.5 SIZE OF ARGUMENT(byte) E M I 0.4

FigureT 10: The results of the processing time inLT MI remote Figure 8: The results of the processing time in local G

N 0.3 Direct methodI invocations (Java RMI and LTMI).

methodS invocations (Java RMI, LTMI, and direct method S

invocation).C O

R 0.1 P 0 0 400 800 1200 1600 2000

SIZE OF ARGUMENT S (Kbyte) Figure 9: Comparison between LTMI and direct method invocation.

2: Experimental Environments.

4.2 Results Figure 8 shows a comparison of the local method invocations between Java RMI, LTMI and direct method invocation (ordinary method invocation in Java). This graph shows us that the local method invocation using Java RMI is not efficient, since its processing time increases proportionately to the size of arguments. This is because Java RMI always copies arguments from a stub program to a server program. The LTMI’s processing time is flat, since LTMI is call-by- reference in local method invocation. The processing time of direct method invocation is also constant value. However, the graph in Figure 9 shows us that LTMI is inferior to direct method invocation in the processing time. LTMI should determine which invocations (local or remote) is needed, and then search for the appropriate method. This operation will increase the overhead of the processing time.

The other evaluation, the measurement of processing time taken in remote method invocations is shown in Figure 10. The graph compares LTMI with Java RMI. We found that there is little difference between the two, and LTMI is inferior to Java RMI in processing time at several points. However, it is not a fatal problem, because the wireless connection fluctuates the processing time of remote method invocations. The results show that LTMI is superior to Java RMI in local method invocations, and the processing time in LTMI’s remote method invocation is equal to that in Java RMI.

5. CONCLUSIONS AND FUTURE WORK We presented the design and implementation of the Wapplet framework, an application framework for ubiquitous computing environment that provides application programmers with device coordination, device switching, and device independent APIs. In our current implementation, LTMI supports device coordination, and can dynamically switch local and remote method invocations cooperating with module databases. Moreover, module migration realized device switching by Java’s serialization and socket libraries. As for the APIs, we divided the APIs into two parts: interfaces and driver programs, which enables application programmers to easily control service providers without building device dependent programs. Additionally, to evaluate the efficiency of LTMI, we measured the processing time of LTMI and Java RMI in both local and remote method invocations. In this evaluation, we found that LTMI is superior to Java RMI in the processing time of method invocations.

In the future, we are planning to extend the Wapplet communication base in multiple ways. First, we will implement a security manager to protect controllers and service providers from malicious Wapplet modules. Second, we will extend LTMI to solve programming semantics problem. As section 4 described, Wapplets can run contrary to expectations of application programmers, which increases their debugging labor in building Wapplets. Finally, we will build Config generator tools to simplify the process of creating Config modules.

6. REFERENCES [1] Tomohiro Nagata, Nobuhiko Nishio and Hideyuki Tokuda, ``Adaptive Service Availability Management Mechanism for Wearable Network Computing'', IWNA2001, IEEE. [2] Takeshi Iwamoto, Nobuhiko Nishio and Hideyuki Tokuda, ``An Application Framework for Wearable Network Computing'', IWNA2001, IEEE. [3] Nelson Minar, Matthew Gray, Oliver Roup, Raffi Krikorian, and Pattie Maes, ``Hive: Distributed Agents for Networking Things'', ASA/MA99(1999) [4] Hiroshi Fujimura, Jin Nakazawa, Tadashi Okoshi, and Hideyuki Tokuda, ``Design and Inplementation of Dynamic Distributed Software Toolkit 'MetaSpace' '', SIGOS Notes No.81 pp.119-124, 1999 IPSJ. [5] Takeshi Iwamoto, Nobuhiko Nishio and Hideyuki Tokuda, ``Mission Mechanism for Wearable Computer'', Computer System Symposium Vol.99, No.16 pp.41-48, 1999, IPSJ.