Download DOC

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
Text
Input
Text
Output
Image
Input
Image
Output
Video
Input
Video
Output
Sound
Input
Sound
Output
Figure 1: System architecture.
Example
Keyboard, scanner
Display, printer
Camera, scanner
Display, printer
Video camera
Display, projector
Microphone
Loud speaker, headphone
Figure 2: Structure of Config module.
The application 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,
1
2
A Wapplet module intending to control another module.
A Wapplet module.being controlled
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, H>. 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)).
Now WB travels to H2. The module database on H1 changes WB’s IP address entry (WMI<WB, H2>), while
the module database on H2 creates a new entry WMI<WB, H2>. At the same time, the module database on H2
stores WB object in its WMI (Figure 4(b)).
Figure 4: LTMI’s mechanism of local method invocations.
Figure 5: Algorithm to avoid invocation misses.
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<WA, H1> to WMI<WA, H2> and WMI<WB, H1> to WMI<WB, H3>. At the
same time, the module database on H2 updates WMI entry (WMI<WA, H2>), and that on H3 also changes
WMI entry (WMI<WB, H3>).
Now WA remotely invokes WB. WA invokes the invoke(WB-N, MB, V) method (Figure 5(b)), but the 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.
Figure 6: Module migration mechanism.
To address this issue, we improved the module database as follows. When a caching miss occurs on a certain
Fi on the host obtains the controller’s IP address from Wapplet module ID of W , and
host, the module database
A
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<W, H1> to WMI<W, H2> (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<W, H2> to
WMI<W, H3>), as Figure 6(c) shows.
3.3 Device Independent APIs
Device independent APIs provide application programmers with eight interfaces to control service 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).
Figure 7: Examples of device independent APIs.
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.
Table 2: Experimental Environments.
CPU
Memory
OS
Host A
Intel StrongARM 32bit-RISC 206MHz
64MB
Familiar Linux ver 0.4
Host B
AMD Arthlon 600MHz
128MB
FreeBSD 4.3 Release
PROCESSING TIME(msec)
25000
20000
Java RMI
15000
LTMI
10000
Direct
5000
0
0
400
800
1200
1600
2000
SIZE OF ARGUMENT(Kbyte)
Figure 8: The results of the processing time in local method
invocations (Java RMI, LTMI, and direct method invocation).
PROCESSING TIME (msec)
0.7
0.6
0.5
0.4
LT MI
0.3
Direct
0.2
0.1
0
0
400
800
1200
1600
2000
SIZE OF ARGUMENT S (Kbyte)
Figure 9:
invocation.
Comparison between LTMI and direct method
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.
PROCESSING TIME(msec)
14000
12000
10000
8000
Java RMI
6000
LTMI
4000
2000
0
0
400
800
1200
1600
2000
SIZE OF ARGUMENT(byte)
Figure 10: The results of the processing time in remote method
invocations (Java RMI and LTMI).
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.