Having known that the Charles' service is available, A application developer, ... At the sever side, we design a web portal as the intermediate between the.
A Grid-Based Application Delivery Toolkit for Ubiquitous Computing Baiyan Li, Ruonan Rao, Minglu Li, and Jinyuan You Department of Computer Science and Engineering, Shanghai Jiao Tong University, Shanghai 200030, China {li-by,rao-ruonan,li-ml,you-jy}@cs.sjtu.edu.cn
Abstract. In this paper we introduce a toolkit that is designed for distributing and launching applications in grid environments. The toolkit is an important part of Shanghai-Grid, an OGSA compatible grid computing environment being under construction for the large-scale collaboration and information sharing. The primary goal of the toolkit is to provide a facility for delivering the grid-based applications to various digital devices so that even a user of the mobile device can access the powerful grid services. Our toolkit has fully implemented the Java Network Launching Protocol 1.0. It also includes a bundle of APIs that support the grid-based applications.
1
Introduction
In the past few years, grid computing [1,2,3,4,5,6] and ubiquitous [6,7,8] computing have received much attention. The grid computing addresses the problems of large-scale distributed computation, massive data processing, and dynamic collaborations. It enables us to tackle the problems that require an enormous amount of computing power and resources. Generally speaking, the grid computing mainly focuses on the resource-intensive computing paradigm. On the other hand, the ubiquitous computing (also known as pervasive computing [6]) is about distributed computing devices in the physical world, such as personal devices, wearable computers, devices embedded in everyday objects and sensors in the environment. The ubiquitous computing is usually characterized by low processor speed, small memory size, limited disk capability, and poor bandwidth. In other words, it is a resource-constrained computing paradigm. The grid computing and the ubiquitous computing usually focus on different subjects. However, a strong demand for the coalescence of the two computing paradigms, which aims at “transform the puniest mobile device into the computing giant”, has emerged [7,8]. Let us try to illustrate this demand through a vivid scenario as following: A policeman, say Bob, caught a suspect in the locale of a crime. The suspect, however, refuses to disclose his identity. So Bob takes out a PDA with a camera from his pocket, and takes a mug shot for the suspect. Immediately, a program within the PDA send the data of suspect’s photo to a center where a grid service, say suspect-face-recognizing, is served. After a while, L.T. Yang et al. (Eds.): EUC 2004, LNCS 3207, pp. 1034–1043, 2004. c Springer-Verlag Berlin Heidelberg 2004
A Grid-Based Application Delivery Toolkit for Ubiquitous Computing
1035
a reply message emerges on the screen of Bob’s PDA: “This photo belongs to Charles, an exconvict · · ·”. Having seen this, Bob turns around to the suspect: “Mr. Charles, you are arrested now, you · · ·”. As shown in above scenario, the techniques of grid computing may significantly enhance the ability of mobile device in dealing with the task that requires strong computing power and enormous amount of resources. In fact, there are quite a large number of applications that are similar to our scenario in the world, for example, the natural language translation, speech recognition, and augmented reality [8]. So it is a natural idea that some techniques and tools shall be developed to combine the two computing paradigms. These techniques and tools may enable a user of mobile devices to access grid services transparently at anytime and anywhere. There are several approaches available through which a mobile digital device can use the powerful services provided by grids. The alternative approaches a device may adopt depend heavily on its computing power. – – – –
Short Message Service (SMS) Embedded Module Embedded Browser Network Launching
The SMS can be used to send and receive text messages to and from mobile telephones. Since most mobile phones support SMS, it seems to be an attractive approach. But this approach is only feasible for some grid services that accept and return simple messages. The second approach requires producers to develop software modules as the client of a fixed set of grid services, and ship them to customers along with the mobile device. But users are unable to update or remove the module dynamically. For the third approach, a user of the mobile digital device can access grid services through a embedded Internet browser. This approach has a medium requirement for the computing abilities of the mobile digital device. However, a embed browser is not always convenient for users, and usually is unable to make a full use of the capabilities of the mobile device. For final approach, a client environment should be implemented in the mobile digital device. Through the environment a user can download a grid-based application to the device and launch it. If the user no longer need the application anymore, he can remove it easily. In addition, the downloaded applications can also be updated automatically. This approach has a high requirement for the computing power of the mobile digital device. But it provides the designers of grid-based applications a opportunity to partition computing tasks between the mobile devices and the other part of the grid reasonably. In this paper, we are concerned with the final approach, and focus on a toolkit we have developed as a part of the Shanghai-Grid project [9,10]. The toolkit, called Grid-based Application Delivery Toolkit (GADT), is designed for distributing and launching grid-based applications in grid environments. We will give a comprehensive introduction to the toolkit from its motivation to its implementation details.
1036
B. Li et al.
The rest of this paper is organized as follows. In Section 2, we introduce the backgrounds on Shanghai-Grid. In Section 3, we describe the functionalities, design, infrastructure, and software modules of GADT. In Section 4, we introduce some important issues related to the implementation of GADT. Finally, we give the conclusion of this paper and the future works in Section 5.
2
Backgrouds
Shanghai-Grid, founded in July 2003, is a significant project for researches on large-scale collaboration and information sharing [9]. The primary goal the project is to establish infrastructures for grid-based applications and develop system software for the information grid. This project will act in accordance with Open Grid Services Architecture (OGSA) [3] and other de facto industry standards, and adopt the up-to-date research results of some related grant fundamental research projects, such as, NHPCE, CNGrid, ChinaGrid, etc [9]. In the underway project, we use an application, the Traffic Information System (TIS), to evaluate and test our works. According to the design, TIS will run in the grid computing environment (GCE) [13] of Shanghai-Grid. It will collect the real-time information of traffic jam from the taxis scattered around the Shanghai city. The TIS will process the huge traffic information in real-time and give on-demand suggestions to the drivers who are seeking their best routes to their destinations. On these backgrounds, the GADT is required to provide a mechanism for some java-enabled mobile devices to access grid services. To avoid the case-bycase design pattern, we adopt a open Web-centric provisioning protocol, Java Network Launching Protocol (JNLP) [11] as the core of the toolkit. However, JNLP doesn’t address any issue related to the grid. So we have to add some necessary components to support grid-based applications in our implementation. The major capabilities and features of our toolkit are listed as follows: – Fully implement the JNLP specification and APIs – Support the Java-enabled, Internet-accessible, resource-constrained portable devices – Provide tools to wrap, maintain and publish the grid-based as well as nongrid-based applications – Provide APIs for accounting and user management – Provide APIs for grid-based applications to access grid services In this paper, we regard the grid-based application as applications that need the support of some grid services to complete their jobs. A grid-based application usually consists of many grid services and software modules scattered around the Internet. So the distribution of a grid-based application can be done by just delivering some parts of the application to the place where it is used.
A Grid-Based Application Delivery Toolkit for Ubiquitous Computing
3
1037
Grid-Based Application Delivery Toolkit
Our toolkit is situated at the middleware layer in the architecture of ShanghaiGrid. It acts as a tool that glues the distributed parts of a grid-based application together in a GCE. Since the JNLP protocol is the core of GADT, we introduce the protocol firstly.
3.1
JNLP Protocol
The JNLP is a Web-centric provisioning protocol and application environment for the Java 2 Technology-based applications. An application implementing this specification is called a JNLP Client. The JNLP Client can launch applications on a client system from resources hosted across the Internet. The main concepts of JNLP is the Web-centric application model with no installation phase, which provides transparent and incremental downloading of an application. The JNLP specification describes how to package an application and deliver it over the Internet. The core of the JNLP technology is the JNLP file. A JNLP file is an XML document with an application descriptor. It specifies the JAR files the application consists of, the Java 2 platform it requires, optional packages that it depends on, its name and other display information, its runtime parameters and system properties, etc. We now give a sample JNLP file as following: traffic Info Query Shanghai-Grid Research Center The above JNLP file describes an application with the title of “Traffic Information Query”. The application includes a JAR file and an ICON file, which can be located at the directory of “http://www.shanghai-grid.com/app/traffic-jam/”. The name of the application’s main-class is “ com.shanghaigrid.taffic.Infoquery”. It can be launched online or offline on the platform J2SE version 1.4 or higher.
1038
B. Li et al.
The Java Network Launching Protocol has following features: – No installation phase: A user needs not to install an application explicitly. Instead, a JNLP Client simply download and cache the resources of the application. – Transparent update: A JNLP Client can check the currently cached resources against the versions hosted on the Web Server and transparently download newer versions. – Incremental update: The JNLP Client only needs to download the resources that have been changed when an application is updated. This feature can significantly reduce the amount of data that needs to be downloaded when upgrading to a new version of an application. – Incremental download: A JNLP Client does not need to download an entire application before it is launched. JNLP allows the developer to specify what resources are needed before an application is launched (eager), and what resources can be downloaded later (lazy). Furthermore, JNLP provides an API so the application can check whether a resource should be downloaded or not. – Offline support: A JNLP Client can launch an application offline if a sufficient set of resources are cached locally. However, most applications deployed using JNLP are expected to be Web-centric, i.e., they will typically connect back to a Web server or database to retrieve their state. Hence, many applications will only work online. The application developer specifies if offline operation is supported, and what resources are needed locally to launch the application offline. Obviously, the JNLP protocol provides several useful features such as the lazy download for resource-constrained mobile digital devices. Our toolkit has fully implemented the JNLP protocol. However, in order to provide users a usable tool and support grid-enabled applications, we have to add many additional components that are not originally required by the JNLP protocol to our implementation. 3.2
Architecture
The infrastructure topology of GADT is illustrated in Fig. 1 (the GApp in the figure refers to an abbreviation of “Grid-based Application”). The whole system consists of the JNLP Clients, the Grid-based Application Delivery Server (GADS), Web Servers, and the Grid Service Server. All of those facilities are connected by the Internet. In general, any digital device that acts as a JNLP Client must be Internet-accessible as well as Java-enabled. Such a device may be a desktop PC, a laptop PC, a packet PC, a PDA, or even a mobile phone. We now use a scenario to describe the use of GADT in a GCE as following: 1. A service provider, say Charles, owns many high-performance supercomputers and databases that store the address information of all the firms in the city where he lives. In order to share those resources with others, he creates a
A Grid-Based Application Delivery Toolkit for Ubiquitous Computing
PC PDA Mobile Phone Etc.
Internet
re plo Ex Download Request
Grid-based Application Delivery System
GApp GApp GApp
Publish Web Server
Grid-based Application Delivery Server
Downloaded Application
Browser
1039
Grid-based Application Delivery System
App Grid Services Access GApp
GApp
Grid Service Server Grid Service Server Grid Service Server
Fig. 1. The infrastructure topology of GADT
2.
3.
4. 5. 6.
telephone number query service using those resources. The service is implemented as a Grid Service, denoted TelephoneNumberQueryService. Charles then publishes the service using UDDI [3] or GIIS/GRIS [12] mechanisms. Having known that the Charles’ service is available, A application developer, say Bob, develop a JNLP-enabled application using Java Language to access the service. Bob’s software provides user a friendly interface for telephone number querying. Then Bob publishes the application on his homepage using GADT. A user, who wants to know the telephone number of some company, say Alice, found Bob’s application when she was browsing Bob’s web using her PDA. After she clicked the icon that represents the application, her JNLP-enabled PDA automatically starts to download and launch the application. After the application is launched, Alice inputs the company name and pushes the submit button on the screen of her PDA. Bob’s application access Charles’ service with the support of GADT, and return the result of the query to Alice’s PDA. After a while, Alice’s desired telephone number emerges on the screen of her PDA.
The Internet Browser in the JNLP-enabled devices is a very useful tool for GADT. If the JNLP file (MIME type: application/x-java-JNLP-file) is bound with GADT, the JNLP Client will start automatically when a user clicks on a hyperlink associated with a JNLP file on Web pages. In addition, the Browser also provides the server side an opportunity to transparently recognize the type of the client device. This can be done by analyzing the content of User-Agent field in the HTTP head. For example, when a user uses IE5.0 to browse a Web page on Windows 2000, the content of User-Agent field in corresponding HTTP head
1040
B. Li et al.
will contain: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0). However, the Browser is not absolutely necessarily for GADT. At the client side, we have a Application Manager that is designed for the management of applications (see Fig. 3). Using the Application Manager, a user can easily add, remove, update and launch applications. So the GADT provides users a flexible approach to customize the functions of their digital devices. Another key issue at the client side should be addressed is how to support various APIs in JNLP Client of GADT. These APIs play a important role in the enforcement of the security and grid services access. For example, the security APIs can be used to verify whether a JAR file is signed by a trusted application provider. There are two ways to install APIs in the JNLP Client. The core APIs such as the security APIs, should be shipped along with the distribution of the JNLP Client. The other APIs can be downloaded along with specific applications as shared libraries. To do so, one must specify those libraries in JNLP files of some applications. This design allows GADT to customize and tailor the supported APIs in accordance with the computing power of specific digital devices. At the sever side, we design a web portal as the intermediate between the JNLP Client and the Delivery Server. The web portal is implemented using JSPs Java Beans and Servlets. Through the portal, a developer can wrap an application and upload it to GADS; the JNLP Client can download an application or check its states on the server, and so on. The Delivery Server is the central part of GADT at server side. It provides the major services for delivering applications in GADS with the support of low level services such as database services and file services. In particularly, we have designed several APIs to access external systems such as the accounting system and user management system, which are not included in our toolkit. 3.3
Software Modules
The major modules of GADT and their interactions between each other at both client and server sides are shown in Fig. 2. At the client side, we have implemented following software modules: – – – – – – – – –
Application Manager Cache Manager Version Manager License Manager Download Manager Runtime Environment JNLP Service API Security API Grid Service Access APIs
The Application Manager is used to manage all applications cached in the client environment. It provides an interface to the application users to maintain cached applications. The Version Manager is responsible for the version control and update decision while the Licence Manager judges whether a user has the rights to
A Grid-Based Application Delivery Toolkit for Ubiquitous Computing
Grid-Enabled JNLP Client
Version Manager
License Manager
Application Manager
GApp
Grid-based Application Delivery Server
Download Manager
App
User Management API
GApp
Other Systems
Delivery Server
Accounting API
Web Portal
Runtime Environement
Application Management Server
Cache Manager
Security API
JNLP Service API
Wireless Message API
1041
J2ME Web Service API
File Service API
Database Server
File Server
Operating System Java Virtual Machine
(JVM)
Hardware
Data
Fig. 2. The software modules and their interactions in GADT
use a downloaded application by querying the GADS. The functions of Download Manager is to download files from the server, cache them in local memory with the help of Cache Manger. The Security API and the Grid Access APIs are not included in the standard JNLP. The former can be used to establish secure channels between the client and the server, and the latter enables the grid-based applications to access grid services. Currently, our toolkit supports the standard Wireless Message API and JSME Web Service API as the Grid Service Access APIs for access to external resources. The major software modules of GADT deployed at the server side can be described as following: – Application Management Server (AMS). The AMS manages all the applications that have been uploaded and stored on the GADS. – Web Portal. The Web Portal provides the interface through which the user or applications can interact with the GADS. – Delivery Server. The Delivery Server processes all the requests for the applications stored on the GADS – User Management and Accounting APIs. The APIs provide a mechanism to access external systems that provide the services of user management and charging. – File Service API and File Server. The File Service API allow developers to use various kind of File servers. The File Server provides the low level file services. – Database Server. The Database Server provides the low level data storage services. In GADS, it is used to store the description information of applications.
1042
B. Li et al.
Fig. 3. A GUI interface of GADT running on PersonalJava emulator 3.0
4
Implementation Issues
The diversity of the portable digital devices leads to multiple java platforms and standards. The platforms and toolkits includes the Java 2 Micro Edition (J2ME), Java Wireless Toolkit, Personal Java, Embedded Java, Java Card, KVM, CLDC, CDC, and MIDP. So it is a very hard task to make our toolkit suitable for too many mobile devices. The JNLP Client we have implemented is called ”Grid Start”. Our implementation supports grid-enabled applications as well as normal JNLP applications. In Fig. 3, we show a GUI interface of Grid Start 1.0 running on the PersonalJava emulator 3.0. The application launching may be the most complicated works in course of the GADT development. We has implemented a new Classloader so that we can load resources dynamically. The Grid Service Access API we have implemented mainly provide two capabilities: (1) access to remote SOAP/XML based web services (2) parsing XML data. It is defined as a subset of the JAX-RPC 1.1 specification that is appropriate for the J2ME platform, where the JAX-RPC is a Java API for interacting with SOAP based web services. The security is still a very important issue for GADT. According to the JNLP specification, an untrusted environment like sandbox and two trusted environments can be implemented. In our full implementation of JNLP, we support the three security modes. However, for most mobile devices, only a trusted environment is can be used according to our experiences.
5
Conclusion and Future Work
In this paper, we introduce a toolkit that is designed for delivering grid-based applications over the Internet. We describe its motivation, backgrounds, design, and implementation issues. The toolkit provide the users of portable device a
A Grid-Based Application Delivery Toolkit for Ubiquitous Computing
1043
flexible way to access grid services. So it fulfils the idea of “transform the puniest mobile device into the computing giant” in a sense. By now, we have finished the software testing of the toolkit on platforms PersonalJava emulation environment 3.0 and J2ME Wireless Toolkit 2.1. In the next phrase, we will develop some sample applications, and continue to test the toolkit on more hardware/software platforms. Acknowledgements. This work is supported by 973 project (No.2002CB312002) of China, ChinaGrid Program of MOE of China, and grand project of the Science and Technology Commission of Shanghai Municipality (No. 03dz15027).
References 1. Foster, I., Kesselman, C.(eds.).: The Grid: Blueprint for a New Computing Infrastructure. Morgan Kaufmann (1999) 2. Foster, I., Kesselman, C., Tuecke S.: The Anatomy of the Grid: Enabling Scalable Virtual Organizations. International Journal of High Performance Computing Application, 15(3) (2001) 200–222 3. Tuecke, S., Czajkowski, K.,Foster, I., Frey, J. Graham, S., Kesselman, C., Vanderbilt, P.: Grid Service Specification. Global Grid Forum (2003) 4. Foster, I., kesselman, C.: Globus: A Metacomputing Infrastructure Toolkit. International Journal of Supercomputer Applications, 11(2) (1997) 115–128 5. Mark, B., Rajkumar, B., Domenico, L.: Grids and Grid Technologies for Wide-Area Distributed Computing. Journal of Software: Practice and Experience, 32(15) (2002) 1437–1466 6. Weiser, M.: The Computer for the 21st Century. Scientific American (1991) 7. Satyanarayanan M.: Pervasive Computing: Vision and Challenges, IEEE Communications (2001) 10–17 8. Balan, R.K, Satyanarayanan, M., Park, S., Okoshi, T.: Tactics-Based Remote Execution for Mobile Computing, Proceedings of the 1st USENIX International Conference on Mobile Systems, Applications, and Services (MobiSys), San Francisco, California, USA, (2003) 9. Minglu, L., Hui, L., Changjun, J., Weiqin, T., Aoying, Z., Yadong, G., Hao, Z., Shui, J., Ruonan, R., Jian C., Qianni, D., Qi, Q., Wei, J.: ShanghaiGrid in Action: The First Stage Projects towards Digital City and City Grid, LNCS 3032. SpringerVerlag Heidelberg (2004) 616–623 10. Ruonan, R., Baiyan, L., Minglu, L., Jinyuan, Y.: The Delivery and Accounting Middleware in the Shanghai-Grid, LNCS. 3032, Springer-Verlag Heidelberg (2004) 786–793 11. Ren´e, W., S.: Java Network Launching Protocol and API Specification, Sun Microsystems (2001) 12. Foster, I., Kesselman, C., Nick, J., Tuecke, S.: Grid Services for Distributed Systems Integration. IEEE Computer 35(6) (2002) 37–46 13. Fox, G., Pierce, M., Gannon, D., Thomas, M.: Overview of Grid Computing Environments. Global Grid Forum (2003)
