GJMA - 一個泛用的Java行動應用程式開發平台

全文

(1)國立交通大學資訊工程系博士論文. GJMA–一個泛用的 Java 行動應用程式開發平台 GJMA – A Generic Java Mobile Application Development Framework. 研究生：鄭明俊指導教授：袁賢銘. 教授. 中華民國九十六年六月.

(2) GJMA–一個泛用的 Java 行動應用程式開發平台 GJMA – A Generic Java Mobile Application Development Framework. 研究生：鄭明俊. Student：Ming-Chun Cheng. 指導教授：袁賢銘. Advisor：Shyan-Ming Yuan. 國立交通大學資訊工程系博士論文. A Dissertation Submitted to Department of Computer Science College of Computer Science National Chiao Tung University in partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy in. Computer Science. June 2007 Hsinchu, Taiwan, Republic of China. 中華民國九十六年六月.

(3) G J M A – 一個泛用的 J a v a 行動應用程式開發平台. 學生: 鄭明俊. 指導教授: 袁賢銘. 國立交通大學資訊工程系(研究所)博士班. 摘. 要. 使用行動裝置與無線網路的人愈來愈多，行動應用程式的需求也日益增強，但是行動裝置之間有著很大的差異，且無線網路並不穩定，裝置的差異與網路的不穩定讓開發行動應用程式變得更加困難，開發者必須面對並花費大量的時間來解決這些問題。雖然有許多的研究試圖解決這些問題，像是使用者介面調適，程式語言轉換等等，但是大多數的研究並沒有將行動裝置的計算能力與功能考慮進去，造成這些行動裝置上的資源被忽略或浪費，為了解決這個問題，本篇論文提出一個泛用的 Java 行動應用程式開發平台，稱為 GJMA，它共支援三種運算模式，分別為 BROWSER，STANDALNONE 與 MASTER-SLAVE，GJMA 可以根據行動裝置的使用者介面，計算能力與功能來選擇程式要在哪種模式下運行，使得程式可以被大部分的裝置所存取使用。換句話說，在 GJMA 上開發程式時並不需要考慮該程式要使用何種運算模式，也不需要考慮行動裝置的計算能力與使用者介面為何，所有需要的轉換都是在佈署到行動裝置上時由 GJMA 來自動完成，也就是說，寫一次程式，就可以讓不同的裝置來存取使用。在這篇論文中，有三個調適的機制將被介紹，分別為運算模式的調適機制，使用者介面的調適機制與通訊協定的調適機制。. i.

(4) GJMA – A Generic Java Mobile Application Development Framework Student: Ming-Chun Cheng. Advisors: Dr. Shyan-Ming Yuan. Department of Computer Science National Chiao Tung University ABSTRACT. Although wireless networks and mobile devices have become popular, the diversity of mobile devices and unsteadiness of wireless networks still cause software development much trouble. Mobile application developers are forced to confront these problems, and therefore spend a lot of time developing mobile applications. Although many studies on user interface adaptation and language transformation have attempted to solve the problem, most of them do not consider the computing power and functionalities of end-devices. As a result, these resources are ignored or wasted. To overcome these problems, the author proposes a generic Java mobile application development framework, named GJMA, to help developers build Java mobile applications quickly and easily. The GJMA framework can tailor an application to fit different devices according to user interface formats and the computing power and functionalities of the devices. Every application developed by GJMA can run in one of three computing modes: thin-client computing, distributed computing and fat-client computing. As a result, a mobile application developed on GJMA can enjoy the “write once, run everywhere” benefit. In addition, three adaptation mechanisms are introduced in this dissertation: computing model adaptation, user interface adaptation and network adaptation.. ii.

(5) 誌. 謝. 本篇博士論文的完成必須感謝許多人。首先感謝我的指導教授袁賢銘博士，謝謝老師多年來的指導，並感謝老師在我的求學過程中給予充分自由的發揮空間，讓我可以作不同的嘗試，學習到不同的知識並獲得各種寶貴的經驗。接著要感謝孫春在教授、陳俊穎教授以及曹孝櫟教授，舉凡論文的架構、所採用的技術、投影片的編排都給予我許多的指導。在此要特別感謝所有的校外口試委員，曾黎明教授、楊竹星教授、鄭憲宗教授與張玉山教授，在百忙之中給予我寶貴的建議，讓我可以讓本篇論文更加的完善。此外我也要感謝實驗室的各位學長，張玉山、梁凱智、何敏煌、焦信達、葉秉哲、許瑞愷、劉旨峰、蕭存喻、林獻堂，給予我許多的指導，在我遇到瓶頸時，指引我一條可行之路。這邊要特別感謝葉秉哲、邱繼弘、吳瑞祥，我們互相打氣，一起參加比賽，一起作研究，一起玩樂，一起寫論文。要不是你們，我的博士班生涯不會多采多姿，也不會充滿著歡笑。除了學長同學外也要感謝實驗室的各位學弟妹給予我的各種幫助，讓我們得以完成各種大小的計畫，藉此機會謝謝所有對實驗室付出心力的人。另外也要感謝系辦的楊秀琴小姐、俞美珠小姐、陳小翠小姐給予我的所有協助。最後將此論文獻給我的父母與一直鼓勵我支持我的老婆卓宜青，感謝你們提供我如此好的學習機會與環境。求學的過程中，需要感謝的人實在太多，希望在未來可以貢獻所學於社會上。. iii.

(6) TABLE OF CONTENTS CHINESE ABSTRACT……………………………………………………………………….i ENGLISH ABSTRACT……………………………………………………………..………..ii ACKNOWLEDGEMENT…………………………………………………………………..iii TABLE OF CONTENTS ........................................................................................................ iv LIST OF FIGURES ...............................................................................................................viii LIST OF TABLES .................................................................................................................... x LIST OF LISTINGS ................................................................................................................ xi Chapter 1 . Introduction ................................................................................................. - 1 - . 1.1. . Motivation ................................................................................................................. - 1 - . 1.2. . Objectives.................................................................................................................. - 2 - . 1.3. . Organization .............................................................................................................. - 3 - . Chapter 2 2.1. 2.1.1. . 2.1.2. . 2.1.3. . Background .................................................................................................. - 5 - Related Specifications ............................................................................................... - 5 - Thin-Client Computing ............................................................................................. - 5 - . 2.1.1.1. . Wireless Markup Language ................................................... - 6 - . 2.1.1.2. . Compact HyperText Markup Language ................................ - 6 - . 2.1.1.3. . Extensible HyperText Markup Language .............................. - 7 - . 2.1.1.4. . Markup Language Transform ................................................ - 8 - . Fat-Client Computing................................................................................................ - 8 - . 2.1.2.1. . Java ME ................................................................................. - 9 - . 2.1.2.2. . BREW.................................................................................. - 11 - . 2.1.2.3. . Symbian ............................................................................... - 11 - . 2.1.2.4. . .NET Compact Framework.................................................. - 11 - . Distributed Computing ............................................................................................ - 12 - iv.

(7) 2.2. . Related Works ......................................................................................................... - 12 - . 2.2.1. . VNC ........................................................................................................................ - 12 - . 2.2.2. . TCPTE .................................................................................................................... - 13 - . 2.2.3. . J2ME Polish ............................................................................................................ - 13 - . 2.2.4. . Nano-X .................................................................................................................... - 14 - . 2.2.5. . ART ......................................................................................................................... - 14 - . 2.3. . Chapter 3 . Java Class File Structure ......................................................................................... - 14 - . GJMA Development Framework Overview ........................................... - 16 - . 3.1. . GJMA Concepts ...................................................................................................... - 16 - . 3.2. . GJMA System Entities ............................................................................................ - 18 - . 3.2.1. . End-device (GJMAClient) ...................................................................................... - 18 - . 3.2.2. . GJMApp .................................................................................................................. - 20 - . 3.2.3. . GJMAServer ........................................................................................................... - 22 - . 3.3. . Three Running Modes in GJMA ............................................................................. - 22 - . 3.3.1. . BROWSER Mode ................................................................................................... - 24 - . 3.3.2. . STANDALONE Mode............................................................................................ - 26 - . 3.3.3. . MASTER-SLAVE Mode ........................................................................................ - 26 - . 3.3.4. . Three Running Modes Comparison ........................................................................ - 27 - . Chapter 4 4.1. . GJMA Design Issues .................................................................................. - 28 - GJMAServer Architecture ...................................................................................... - 28 - . 4.1.1. . Adaptive Transport Layer ....................................................................................... - 28 - . 4.1.2. . Message Routing Layer........................................................................................... - 30 - . 4.1.3. . Application Runtime Layer ..................................................................................... - 31 - . 4.2. . GJMAClient Architecture ....................................................................................... - 32 - . 4.3. . Initialization Process within GJMApp .................................................................... - 33 - . 4.3.1. . GJMApp in GJMAServer ....................................................................................... - 33 - . 4.3.2. . GJMApp in GJMAClient ........................................................................................ - 34 - v.

(8) 4.4. . Computing Model Adaptation Mechanism ............................................................. - 35 - . 4.4.1. . Adapt to the STANDALONE Mode ....................................................................... - 35 - . 4.4.2. . Adapt to the BROWSER Mode .............................................................................. - 36 - . 4.4.3. . Adapt to the MASTER-SLAVE Mode ................................................................... - 36 - . 4.4.4. . 4.4.3.1. . How to Intercept Invocation Actions ................................... - 39 - . 4.4.3.2. . How to Reflect Intercepted Actions .................................... - 43 - . 4.4.3.3. . How to Create Complementary Objects .............................. - 44 - . Deployment Process ................................................................................................ - 50 - . 4.5. . User Interface Adaptation Mechanism.................................................................... - 53 - . 4.6. . Network Adaptation Mechanism ............................................................................ - 55 - . Chapter 5 . GJMA Implementation Issues .................................................................. - 56 - . 5.1. . GJMAClassLoader .................................................................................................. - 56 - . 5.2. . GJMAMesg Format ................................................................................................ - 59 - . 5.2.1. . GJMAMesg for System Use ................................................................................... - 60 - . 5.2.2. . GJMAMesg for BROWSER Mode ......................................................................... - 61 - . 5.2.3. . GJMAMesg for MASTER-SLAVE Mode .............................................................. - 61 - . 5.3. . Marshalling and Unmarshalling .............................................................................. - 62 - . 5.3.1. . Marshalling ............................................................................................................. - 63 - . 5.3.2. . Unmarshalling ......................................................................................................... - 66 - . 5.4. . GJMA Preprocessor ................................................................................................ - 67 - . 5.4.1. . Generate Wrapper Class .......................................................................................... - 68 - . 5.4.2. . Convert to Method Invocation Actions ................................................................... - 74 - . 5.4.2.1. . Filed Manipulation Action ................................................... - 74 - . 5.4.2.2. . Synchronized Action ........................................................... - 75 - . 5.4.3. . Generate Code for Creating Complementary Objects............................................. - 76 - . 5.4.4. . Convert Array Type to Class Type ......................................................................... - 77 - . 5.4.5. . Insert Code for Intercepting Instance Creation ....................................................... - 78 - vi.

(9) 5.5. . GJMA Analyzer ...................................................................................................... - 81 - . 5.5.1. . Generate Proxy Class .............................................................................................. - 81 - . 5.5.2. . Generate ObjMngr Class ......................................................................................... - 82 - . Chapter 6 6.1. . 5.5.2.1. . Generate the create Method ................................................. - 83 - . 5.5.2.2. . Generate the invoke Method................................................ - 84 - . Evaluation .................................................................................................. - 85 - Programming Framework Comparison ................................................................... - 85 - . 6.1.1. . MPI Programming Framework ............................................................................... - 85 - . 6.1.2. . Java RMI Programming Framework ....................................................................... - 86 - . 6.1.3. . GJMA Programming Framework ........................................................................... - 87 - . 6.1.3.1. . Hello World ......................................................................... - 87 - . 6.1.3.2. . Web Services ....................................................................... - 88 - . 6.2. . Performance Evaluation .......................................................................................... - 91 - . 6.3. . Program Size Evaluation ......................................................................................... - 93 - . Chapter 7 . Conclusion and Future Works.................................................................. - 95 - . References........................................................................................................................... - 97 - . vii.

(10) LIST OF FIGURES Figure 1-1: Computing power requirements for client and server ........................................ - 3 Figure 2-1: Java platforms for different purposes ................................................................. - 9 Figure 2-2: A VNC2Go screenshot ...................................................................................... - 13 Figure 2-3: J2ME Polish screenshots .................................................................................. - 14 Figure 2-4: Java class file structure ..................................................................................... - 15 Figure 3-1: Three-tier architecture used in GJMA .............................................................. - 17 Figure 3-2: The decision tree for the class org.gjma.application.GJMApp......................... - 20 Figure 3-3: A GJMApp deployed to different running modes or devices. .......................... - 23 Figure 3-4: A diagram for the BROWSER mode ................................................................ - 24 Figure 3-5: A screenshot of the GJMA task manager ......................................................... - 26 Figure 3-6: A diagram for the MASTER-SLAVE mode ..................................................... - 27 Figure 4-1: The layered architecture of GJMAServer. ........................................................ - 28 Figure 4-2: The detailed architecture of GJMAServer. ....................................................... - 30 Figure 4-3. The layered architecture of GJMABrowser. ..................................................... - 33 Figure 4-4: Logical and physical object views .................................................................... - 39 Figure 4-5: Proxy design pattern ......................................................................................... - 40 Figure 4-6: The relationship between managed and un-managed class .............................. - 42 Figure 4-7: Wrapper design pattern ..................................................................................... - 43 Figure 4-8: The sequence diagram for the proxy class. ....................................................... - 43 Figure 4-9: Insert GJMAObject in the inheritance chaining ............................................... - 45 Figure 4-10: Separate two associated classes into two different hosts. ............................... - 47 Figure 4-11. The GJMApp development flow. .................................................................... - 51 Figure 4-12: A tree structure about user interface ............................................................... - 54 Figure 5-1: Class loader structures ...................................................................................... - 58 viii.

(11) Figure 5-2: Base GJMAMesg format .................................................................................. - 60 Figure 5-3: GJMAMesg format for BORWSER mode ....................................................... - 61 Figure 5-4: GJMAMesg format for the MASTER-SLAVE mode ...................................... - 62 Figure 5-5: Two phases in GJMA preprocessor .................................................................. - 67 Figure 5-6: Replace field manipulation action with SETTER/GETTER ............................ - 75 Figure 5-7: Modify codes for creating complementary object ............................................ - 77 Figure 5-8. How to intercept method invoke action ............................................................ - 81 Figure 5-9: How ObjMngr to process a received GJMAMesg ........................................... - 83 Figure 6-1: The GJMApp development flow ...................................................................... - 87 Figure 6-2: The GJMApp (Hello World) accessed by different GJMAClient..................... - 88 Figure 6-3: The GJMApp using Web services development flow....................................... - 89 Figure 6-4: The GJMApp (Web services) accessed by GJMAppStandalone. ..................... - 91 Figure 6-5: The GJMApp (Web services) accessed by WAP browser................................. - 91 Figure 6-6: Remote method invocation performance evaluation. ....................................... - 93 -. ix.

(12) LIST OF TABLES Table 2-1: Optional packages in Java ME platform ............................................................ - 10 Table 3-1: The GJMA packages .......................................................................................... - 21 Table 3-2: The comparsion table of the three running modes. ............................................ - 27 Table 4-1: The mapping table among tree element, WML and HTML ............................... - 55 Table 5-1: Methods to build the first section ....................................................................... - 65 Table 5-2: Methods to build the sections other than the first section .................................. - 65 Table 5-3: Methods to get parameter ................................................................................... - 66 Table 5-4: Examples for wrapper class naming................................................................... - 69 Table 5-5: The array class naming convention .................................................................... - 78 Table 6-1: Test environment. ............................................................................................... - 92 -. x.

(13) LIST OF LISTINGS Listing 2-1: WML page example ........................................................................................... - 6 Listing 2-2: C-HTML page example ..................................................................................... - 7 Listing 2-3: XHTML basic page example ............................................................................. - 8 Listing 3-1: Partial device profile ........................................................................................ - 19 Listing 3-2: Partial class profile .......................................................................................... - 20 Listing 3-3: Java ME MIDP codes vs. GJMApp codes ....................................................... - 21 Listing 5-1: InferaceA source code...................................................................................... - 56 Listing 5-2: ClassA source code .......................................................................................... - 56 Listing 5-3: Use the same class loader to load ClassA twice .............................................. - 57 Listing 5-4: Use two different class loaders to load ClassA twice ...................................... - 57 Listing 5-5: Use GJMAppInterface to control GJMApps ................................................... - 59 Listing 5-6: The partial source code for ActionBuilder ....................................................... - 63 Listing 5-7: A marshalling example .................................................................................... - 66 Listing 5-8: An unmarshalling example .............................................................................. - 67 Listing 5-9: The source code for test.Foo1 .......................................................................... - 70 Listing 5-10: The source code for test.Foo1’s wrapper ....................................................... - 71 Listing 5-11: The source code for test.Foo1’s wrapper after replacements ......................... - 73 Listing 5-12: The source codes for GJMA_ENTER and GJMA_LEAVE .......................... - 76 Listing 5-13: The partially source code for GJMAObject ................................................... - 80 Listing 6-1: A partial sample code for MPI. ........................................................................ - 86 Listing 6-2: A sample interface for Java RMI. .................................................................... - 86 Listing 6-3: A sample RMI server implementation. ............................................................ - 86 Listing 6-4: Hello World sample code ................................................................................. - 88 Listing 6-5: Web services sample code ............................................................................... - 90 xi.

(14) Listing 6-6: The test code template. .................................................................................... - 91 -. xii.

(15) Chapter 1 Introduction In the past decade, the number of mobile devices, such as mobile phones, PDAs, and notebooks, has increased enormously. Wireless networks, such as GRPS, UMTS, WiFi, have also become prevalent. These two factors have changed computing environments tremendously, and many new computing paradigms have been introduced, such as mobile computing [1], pervasive computing [2], and ubiquitous computing [3]. In other words, the requirements for developing mobile applications have increased, and more mobile applications have been developed for these mobile devices.. 1.1. Motivation However, there are many differences between these devices. First, they may have different executing environments. For instance, some of them comply with WAP [4], some with Java ME [5], and some with Microsoft .NET CF [6]. Second, the computing power and functionalities of these devices are diverse and they may have different hardware resources. For example, some have powerful processors, but some do not. Some are equipped with high resolution screens, but some are not. Third, these devices support different kinds of networks. These networks may have different bandwidths, latency, and reliability, and they may disconnect during use. These differences increase the complexity of developing a mobile application capable of supporting them all [7]. Developers have to face these issues, and have spent much time solving them.. Writing an application capable of supporting multiple devices is difficult. Thus, many studies and standards have tried to solve them. For example, Mobile Execution Environment (MExE [8]) defined by a 3GPP working group categorizes these devices into four execution environments, named classmark 1-4, to reduce mobile application development complexity. Different classmarks mean different execution environments. If a mobile application was -1-.

(16) developed for classmark 1, it can be run on all devices which conform to classmark 1. Consequently, before developing a mobile application, developers have to decide which classmarks the application will support. This approach makes developers focus on specific execution environments, and implies that the application cannot support devices belonging to other classmarks. To overcome this problem, many studies have been made on adaptations and attribute programming [9], including user interface adaptation [10][11][12][13][14] and programming language transformation [15][16]. They can tailor the application to fit different user interface formats or execution environments. However, most of them do not consider the computing power and functionalities of devices and these resources are ignored or wasted. For instance, some of them focus solely on user interface adaptation. Some of them sacrifice the computing power and functionalities of devices because they can only use functions which all devices support.. 1.2. Objectives The aim of this dissertation is to design and implement a generic Java mobile application (GJMA) development framework. Every application developed from GJMA is capable of tailoring itself to fit different devices or situations according to user interface formats and the computing power and functionalities of the devices. In other words, more powerful devices will do more things in GJMA.. -2-.

(17) computing power requirements for server. thin-client computing WEB, WAP, VNC. distributed computing CORBA, RMI, DCOM. fat-client computing J2ME, PJava, .NET CF. computing power requirements for client. Figure 1-1: Computing power requirements for client and server. A server supports weak devices in this study, helping them do something they cannot do. Thus, every GJMA application can be viewed as client-server computing [17]. Figure 1-1 shows the computing power requirements for three different computing paradigms derived from client-server computing, and every computing paradigm has many different state-of-the-art technologies. In thin-client computing [18], clients are only responsible for user interface, and nearly all application logic is handled by the server. In distributed computing, clients are responsible for some application logic, and other logic is handled by the server. In fat-client computing, all application logic is handled by clients themselves. These three computing paradigms have different computing power requirements for clients. By adapting an application to one of the three computing paradigms, all kinds of devices can be well supported regardless of their computing power and functionalities. In addition, a user interface adaptation mechanism and a network adaptation mechanism are proposed in this dissertation.. 1.3. Organization This rest of this dissertation is organized as follows. Chapter 2 will introduce related background about mobile application development and Java language. Chapter 3 will describe -3-.

(18) the concepts of GJMA. Chapter 4 will express the design issues and chapter 5 will discuss the implementation issues. Chapter 6 gives some evaluations and finally chapter 7 gives conclusion as well as future works.. -4-.

(19) Chapter 2 Background There are many specifications and works for mobile application developments. Moreover, some researches [19] had surveyed how to develop mobile applications. In this chapter, some important specifications and works are introduced. Also, Java class file structure is described in this chapter.. 2.1. Related Specifications There are many different specifications related to mobile application developments. They can be categorized according to which computing paradigms they used. Different computing paradigms have different way to develop an application. The most three popular computing paradigms are introduced here and they are thin-client computing, fat-client computing and distributed computing respectively. All of them are derived from client-server computing paradigms, so there is no clear boundary among them.. 2.1.1. Thin-Client Computing In thin-client computing, the bulk of business logic is processed on the corresponding server, so it can also be called server-based computing. The responsibility of clients is providing user interface only, thus the computing power requirement of clients is lower.. In this computing model, an application run on server-side can be developed by various platforms, such as Java Servlet[20], PHP[21], ASP[22] and so on. No matter what platform is used, the important is how clients interact with the server. There are many ways for clients to interact with the server and they can be categorized into two categories: standard and proprietary. Basically, clients can use built-in browsers to access the application which will use standard protocols (such as WAP and HTTP) and content formats (such as WML [23], -5-.

(20) XHTML [24] and so on). Moreover, clients can use specific programs to access the application which will use proprietary protocols (ex. NTT DoCoMo’s i-mode [25]) and content formats (ex. C-HTML [26]). In short, both browsers and specific programs run on client-side are used to render user interface and send user request to the application. The differences among them are content formats and protocols. Some specifications used to create thin-client mobile applications are given below.. 2.1.1.1. Wireless Markup Language Wireless Markup Language (WML) is the content format used in Wireless Application Protocol (WAP) and Listing 2-1 is a WML page example. Currently, almost mobile phones support WAP and they have built-in browsers capable of accessing these WML pages. An application has to output WML pages if it is designed to support WAP-enabled mobile devices. Moreover, the browsers use WAP to communicate with the server.. <?xml version="1.0"?> <!DOCTYPE wml PUBLIC "-//PHONE.COM//DTD WML 1.1//EN" "http://www.phone.com/dtd/wml11.dtd"> <wml> <card id="main" title="WML Example"> Hello World <a href="about.wml">About...</a> </card> </wml>. Listing 2-1: WML page example. 2.1.1.2. Compact HyperText Markup Language Compact HTML (C-HTML) is the content format used in NTT DoCoMo’s i-mode and Listing 2-2 is a C-HTML page example. Basically, C-HTML is a subset of the HTML markup language. In addition, C-HTML adds some features which cannot find in the HTML standard, notably the accesskeys, phone number shortcuts for links and so on. Currently, only i-mode -6-.

(21) mobile phones have browsers capable of accessing these C-HTML pages. An application has to output C-HTML pages if it is designed to support i-mode mobile phones. Moreover, the browsers use NTT DoCoMo’s proprietary protocols, ALP (HTTP) and TLP (TCP and UDP), to communicate with the server.. <html> <head><title>C-HTML Example</title></head> <body> Hello World <a href="about.chtml" accesskey="1">About...</a> </body> </html>. Listing 2-2: C-HTML page example. 2.1.1.3. Extensible HyperText Markup Language Extensible HyperText Markup language (XHTML) is a content format similar to HTML but XHTML also conform to XML [27] syntax. In XHTML family, there are two members related to mobile devices: XHTML basic [28] and XHTML mobile profile [29]. The former is designed to support devices which cannot support all XHTML dialects and it is intended to replace WML and C-HTML. Listing 2-3 is a XHTML basic example. The latter is based on XHTML basic and it adds more features for mobile phones. An application has to output XHTML pages if it is designed to support mobile phones equipped with XHTML browser. Moreover, the browsers use HTTP or WAP 2.0 to communicate with the server.. -7-.

(22) <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html> <head><title>XHTML Basic Example</title></head> <body> Hello World <a href="about.xhtml">About...</a> </body> </html>. Listing 2-3: XHTML basic page example. 2.1.1.4. Markup Language Transform There are many different content formats mentioned above and the greater part of them is markup languages. Hence, an application has to output different markup languages to serve different clients equipped with different browsers. XSLT [30] is a technology often used to convert XML data into other markup languages. Thus, an application applied Model-View-Controller pattern [31] can exploit XML document, such as UIML [32], to describe user interface and then use XSTL to convert it into the markup languages supported by the target client on demand. Besides this, there are several similar researches [33][34][35][36].. 2.1.2. Fat-Client Computing In fat-client computing, the bulk of business logic is processed on the client directly. All applications using this computing model can be executed on client without any server assistance. It implies these applications can run offline and the devices must have enough capabilities to execute the applications. This computing model is widely used. Currently, the most three popular development platforms are Java ME, BREW [37], Symbian [38], and .NET Compact Framework.. -8-.

(23) 2.1.2.1. Java ME Java is an object-oriented programming language developed by Sun Microsystems in the early 1990s. Unlike C programs are compiled to native machine codes, Java applications typically are compiled to Java bytecode which is platform independent and is run on a stack machine named Virtual Machine [39]. Nowadays, there are many different editions for Java, such as Java EE [40], Java SE [41] and Java ME for different purposes as Figure 2-1 shows. Java EE is for enterprise application, Java SE is for general application, and Java ME is for mobile application.. Figure 2-1: Java platforms for different purposes. Because of the mobile device diversity and resource constraints, Java ME architecture is combined of three parts: configurations, profiles and optional packages. It implies that it is impossible to put all codes into a resource-limited device. Thus, each combination of the three parts is optimized for the memory, processing power, and I/O capabilities for target devices. All these things make it clear that Java ME use different combinations to support diverse mobile devices well. For example, some mobile devices are equipped with Bluetooth and some are not. -9-.

(24) For devices equipped with Bluetooth, the optional package JSR [42] 82 has been included in the combination to support it. For devices which are not equipped with Bluetooth, the optional package JSR 82 is excluded in the combination to save memory. The functionalities of the three parts are described as follows: z. Each configuration provides base functionalities for particular devices with similar characteristics. Currently, there are two base configurations, CLDC and CDC, in Java ME. The full name of CLDC is “Connected Limited Device Configuration” which is designed for limited mobile devices such as cellular phones. Moreover, the full name of CDC is “Connected Device Configuration” which is designed for more capable devices such as smartphones.. z. Each profile is a set of higher level APIs. It defines the application life cycle model, the user interface, and the device specific properties.. z. Each optional package offers different functionality as Table 2-1 shows. The capabilities of Java ME can be further extended by combining various optional packages.. Table 2-1: Optional packages in Java ME platform Optional package name. Version. JSR. Java APIs for Bluetooth. 1.1. JSR 82. Content Handler API. 1.0. JSR 211. Mobile Media API. 1.2. JSR 135. Java Binding for the OpenGL® ES. 1.0. JSR 239. J2ME Web Services Specification. 1.0. JSR 172. 1.0. JSR 177. 1.0. JSR 219. 1.0. JSR 209. 1.0. JSR 66. Bluetooth, OBEX. JAXP, JAX-RPC Security and Trust Services APIs ADPU, JCRMI, PKI, CRYPTO Security JSSE, JCE, JAAS Advanced Graphics and User Interface Java 2DTM, Swing RMI. - 10 -.

(25) JDBC JavaTV. TM. API. 1.0. JSR 169. 1.1. JSR 927. Because Java is platform independent, the greater part of mobile phones is Java ME-enabled currently.. 2.1.2.2. BREW Binary Runtime Environment for Wireless (BREW) is a mobile application development platform created by Qualcomm for mobile phones. It can support GSM/GPRS, UMTS and CDMA. BREW is similar to Java ME but BREW is more powerful because the running level of BREW is lower than Java ME. In other words, BREW is more close to hardware. For example, it can access screen buffer directly.. 2.1.2.3. Symbian Symbian is an operating system for handheld devices with limited resources. It has different device classes and variants for different mobile devices, such as Series 60, Series 80, UIQ and so on. Basically, they have same basis but may have different look and feel. A Symbian application has to be written in C++ and use classes provided by Symbian libraries. Currently, a Symbian application only can be executed on Symbian OS.. 2.1.2.4. .NET Compact Framework The Microsoft .NET Compact Framework is a version of the .NET Framework that is designed to run on mobile devices. Basically, it is a subset of .NET Framework but it adds some libraries designed specifically for mobile devices. A .NET Compact Framework application can be developed in C# or Visual Basic.NET. Currently, the application only can be executed on mobile devices powered by Microsoft .NET Compact Framework.. - 11 -.

(26) 2.1.3. Distributed Computing In distributed computing, the bulk of business logic is spread on different hosts. These hosts provide different services and they cooperate with each other to complete the business logic. This computing model is widely used, such as CORBA [43], Java RMI [44], and Web services [45] are examples. Different distributed technologies have different usages [46]. Some have to write remote interface descriptions [47][48], some have to declare and implement specific interfaces [14], some exploit annotation or attribute to declare remote methods in source codes [49], and some only provide communication library to call [50]. However, for mobile application development, not all technologies is suitable for mobile application and only Web services and Java RMI [51] are two of the most popular technologies to realize distributed computing. It is worth to notice that not all mobile devices support Web services and Java RMI.. 2.2. Related Works. 2.2.1. VNC Virtual Network Computing (VNC) [52] is a remote desktop software capable of showing user interface locally (client-side) and controlling the applications remotely (server-side). At the beginning, VNC is not designed for mobile devices but there are some client implementations for mobile devices, such as VNC2Go [53] and so on. In fact, these applications run on server-side are not designed for mobile devices, so the user interface displayed on client-side may be terrible. Figure 2-2 (the figure is captured from http://www.freeutils.net/vnc2go/index.jsp) is an example and it only can display small portion of desktop at once. Moreover, VNC uses its proprietary protocol to communicate between server and client. - 12 -.

(27) Figure 2-2: A VNC2Go screenshot. 2.2.2. TCPTE The thin-client applications for limited devices (TCPTE) framework [54][55] is a development framework for mobile applications. It can execute Java application on a remote server and display their AWT interface on a local client. It combines the advantages of thin-client computing with the richness user interface and lets programmer develop mobile applications using same process and tools they typical use for desktop applications. Besides this, there are several similar researches and projects [56][57]. They can display user interface remotely also.. 2.2.3. J2ME Polish J2ME Polish [14] is based on Java ME and it is a collection of tools for developing Java ME applications. These tools include device database, preprocessor and utility classes. The device database is used to describe the capabilities of mobile devices and the preprocessor modify source codes to fit target devices according the device database. Furthermore, it provides richer and flexible user interface classes which can use CSS [58] to describe. An example is shown in Figure 2-3 (the figure is captured from http://www.j2mepolish.org/screenshots.html). There are three screenshots and they shows the same screen with different CSS. Besides, it also provides some useful features, such as remote method invocation, serialization, - 13 -.

(28) persistence and so on. These mechanisms can help developer build mobile application easier.. Figure 2-3: J2ME Polish screenshots. 2.2.4. Nano-X The Nano-X Window System (previously Microwindows) [59] is aimed at bringing the features of modern graphical windowing environments to smaller devices and platforms. Basically, it only provides user interface related functionalities. Unlike X Window [61], both server-side and client-side have to be executed on mobile devices in the Nano-X Window System. Because the usage of Nano-X is similar to usage of X Window, developer can use the same process to build mobile application appearance.. 2.2.5. ART Adaptive Remote Terminal (ART) [60] is a mobile development framework capable of executing the application on server-side and displaying user interface on client-side. Besides, it can output different content formats for different browsers. End-users can use built-in browsers or the proprietary browser to access these applications run on server-side.. 2.3. Java Class File Structure Figure 2-4 is the structure of the java class file. There are many parts in a class file, including - 14 -.

(29) header, constant pool, access rights, this class, super class, implemented interfaces, fields, methods and attributes. It is worth to notice that there are many indexes. Every index is used to pointer to an entry in the constant pool. In fact, there is much information stored in the constant pool, such as methods’ name, methods’ signatures, fields’ name, fields’ type, class name, and so on. By analyzing the constant pool in a class file, all information can be got and there are many tools capable of modifying or examining the class files. In other words, Java class file is easy to be modified. In GJMA, BCEL [62] is used to do this. It can generate class file or modify the class file on demand, including the bytecode in the methods.. class file format. Detailed Constant Pool. Header. CONSTANT_Utf8 “org/evitan/gma/Hello”. zoom in. Constant Pool. CONSTANT_Utf8 “java/lang/Object” CONSTANT_Utf8 “toString”. Access Rights This class. CONSTANT_Utf8 “( )Ljava/lang/String;”. Super class Implemented Interfaces . CONSTANT_Utf8 “self” CONSTANT_Class *name_index = “org/evitan/gma/Hello” CONSTANT_Class *name_index = “java/lang/Object”. Fields. Methods. CONSTANT_NameAndType *name_index *descriptor_index. Attributes. CONSTANT_Fieldref *class_index = “org/evitan/gma/Hello” *name_and_type_index = “self” CONSTANT_Methodref *class_index = “org/evitan/gma/Hello” *name_and_type_index = “toString”. bytecode aload_0 invokevirutal org.evitan.gma.Hello.toString. Figure 2-4: Java class file structure. - 15 -.

(30) Chapter 3 GJMA Development Framework Overview This chapter will introduce GJMA concepts, GJMA system entities and three supported running modes.. 3.1. GJMA Concepts It is difficult for a mobile application to support all devices well due to varying computing power and functionalities. A simple scenario follows. Three end-users want to control home appliances via their own mobile devices, named DeviceA, DeviceB, and DeviceC, respectively, using a Java ME MIDP (JSR 118) home appliance control application which uses Web services to control home appliances. These devices have different functionalities. DeviceA cannot run Java ME applications and only has a built-in WAP browser. DeviceB has a WAP browser and is Java ME MIDP compatible, but it does not support Web services (JSR 172). DeviceC is similar to DeviceB, except DeviceC supports Web services. In the scenario, DeviceC can run the home appliance control application directly, but DeviceA and DeviceB cannot. Without an automatically adaptation framework, a developer can only solve the problem in two ways. The first approach is to develop three specific editions for the three devices. The second approach is to develop one general WAP version which can be accessed by WAP browsers on all devices. The former is a tedious task and the latter sacrifices the computing power of DeviceB and DeviceC. One of the primary GJMA framework objectives is to let all devices run at capacity without publishing many editions of an application: write an application once and it can support all kinds of devices well.. - 16 -.

(31) Browser-enabled. Java-enabled. Application server. internet or intranet. Middle-tier. Backend-tier. Smartphone & PDA. Other devices Front-tier. Figure 3-1: Three-tier architecture used in GJMA. GJMA uses a three-tier architecture, as Figure 3-1 shows, to solve the problems of diverse computing power and functionalities. End-users use their own desktops or mobile devices, called end-devices, in the front-tier to access mobile applications. There is at least one application server in the middle-tier, which provides necessary execution environments and services for running applications and end-devices. An application in the GJMA is designed to be capable of running in the front-tier (fat-client computing), in the middle-tier (thin-client computing), or even in both tiers (distributed computing) simultaneously depending on the computing power and functionalities of end-devices. More front-tier computing power means more codes will be run in the front-tier (implicitly fewer codes will be run in the middle-tier). By analyzing, an application may therefore face three different running cases:. z The computing power of the end-device is not good enough or the device cannot run applications other than built-in applications. The device here is not suitable for the application or cannot run the application. Thus, thin-client computing, such as WEB-based technology, is suitable for this case. Entire application codes must be executed in the. - 17 -.

(32) middle-tier, and the front-tier is only responsible for user interface. z The computing power of the end-device is good enough and the device supports all functionalities which the application requires. In this case, entire application codes can be executed on end-devices. This is a kind of fat-client computing, like running a Java ME MIDP application on a mobile device. z The computing power of the end-device is good enough but the device does not support all functionalities which the application requires. The device in this situation cannot execute some codes within the application, and these codes have to be handled by the middle-tier application server. This is a kind of distributed computing, such as Java RMI.. To support all kinds of end-devices, GJMA provides three different running modes for an application to fit the three cases above: BROWSER mode (thin-client computing), STANDALONE mode (fat-client computing), and MASTER-SLAVE mode (distributed computing). Section 3.3 will discuss the details.. 3.2. GJMA System Entities The GJMA framework contains three important entities: end-device (GJMAClient), GJMApp, and GJMAServer. In Figure 3-1, End-device (GJMAClient) participates in front-tier and GJMAServer involves in middle-tier as the application server. Furthermore, GJMApps are applications capable of running in one of the three running modes.. 3.2.1. End-device (GJMAClient) An end-device is any device used by an end-user in the front-tier. These include PDAs, mobile phones, notebooks and so on. End-devices can be divided into two categories according to their programmable characteristics. All end-devices belonging to the programmable GJMAClient category can execute applications other than their built-in applications. On the other hand, all - 18 -.

(33) end-devices belonging to the non-programmable GJMAClient category can only execute the built-in applications.. Because there are many differences between end-devices, the GJMA framework contains an end-device database to provide related information. This database helps the GJMA framework adjust applications to fit different end-devices. The end-device database comprises two XML [27] documents: device profile and class profile. Device profile describes related information for end-devices, and class profile describes decision trees used to find the most suitable classes. End-device capabilities are listed in device profile as Listing 3-1 expressed, including execution environments, screen size and other data. Figure 3-2 is an example of a decision tree for the org.gjma.application.GJMApp class. The class has four implementations for different running modes and Listing 3-2 is the corresponding class profile.. <Vendor="SonyErission"> <Device name="k700i"> <Browser type="WAP"> </Browser> <ExecutionEnvironment val="J2ME_MIDP"> </ExecutionEnvironment> </Device> </Vendor> Listing 3-1: Partial device profile. Running modes?. BROWSER. MASTER-SLAVE. STANDALONE a. b. Server or Client?. c. - 19 -. d.

(34) Figure 3-2: The decision tree for the class org.gjma.application.GJMApp. <Class name="org.gjma.application.GJMApp"> <Decision var="RunningMode"> <Equal val="BROWSER"> <Edition name="a" path="BROWSER\org\gjma\application\GJMApp.class“ /> </Equal> <Equal val="STANDALONE"> <Edition name="b" path="STANDALONE\org\gjma\application\GJMApp.class“ /> </Equal> <Equal val="MASTERSLAVE"> <Decision var="MasterOrSlave"> <Equal val="Master"> <Edition name="c" path="MS\MASTER\org\gjma\application\GJMApp.class“ /> </Equal> <Equal val="Slave"> <Edition name="d" path="MS\SLAVE\org\gjma\application\GJMApp.class“ /> </Equal> </Decision> </Equal> </Decision> </Class>. Listing 3-2: Partial class profile. 3.2.2. GJMApp Every mobile application developed from the GJMA framework is called a GJMApp. Developing a GJMApp is similar to writing a general Java ME MIDP application, but there are something differences between them as Listing 3-3 shows. In Java ME MIDP applications, developers must consider whether or not the classes within the Java ME application are compatible for end-devices. This is because all classes have to be handled by the end-devices. Conversely, GJMApp developers need not worry about compatibility problems since the server will help end-devices handle all incompatible classes. Classes which need to be executed by the servers are determined in deployment time. A GJMApp can be deployed in different running modes according to end-device execution environments, computing power, and functionalities. Because different running modes have different requirements for end-devices, a GJMApp can support the majority of end-devices by adapting to different running modes. As a result, developers do not need to take different devices into account. Instead, they can focus on - 20 -.

(35) business logic only. Section 4.4.4 introduces deployment process details.. public class TestMIDlet extends javax.microedition.midlet.MIDlet {. public class TestGJMApp extends org.gjma.application.GJMApp {. public TestMIDlet() { //constructor } public void startApp() { //this will be called, when MIDlet is started } public void pauseApp() { //this will be called, when MIDlet is paused } public void destroyApp(boolean unconditional) { //this will be called, when MIDlet is destroyed } }. public TestGJMApp() { //constructor } public void startApp() { //this will be called, when GJMApp is started } public void pauseApp() { //this will be called, when GJMApp is paused } public void destroyApp(boolean unconditional) { //this will be called, when GJMApp is destroyed } }. Listing 3-3: Java ME MIDP codes vs. GJMApp codes. Every GJMApp has a main class which must inherit from the org.gjma.application.GJMApp class. This is similar to every Java ME MIDP application which has a main class which must inherit from javax.microedition.midlet.MIDlet class. The GJMA framework, like software development kits, provides classes other than the org.gjma.application.GJMApp class as Table 3-1 shows. This helps developers build mobile applications efficiently. The GJMA framework prepares many different editions of classes to support all kinds of end-devices in three running modes. Different editions of a class have the same functionalities but have different implementations. When a GJMApp is deployed, the most suitable classes are chosen according to. the. class. profile. in. the. end-device. database.. For. example,. the. class. org.gjma.ui.LayoutManager is used to arrange widgets, and has two editions. One is for small screens and the other is for large screens. Another example is that the class org.gjma.application.GJMApp, which initializes all necessary resources in runtime, has four editions. One is for the STANDALONE mode, one is for the BROWSER mode, and two are for the MASTER-SLAVE mode as Figure 3-2 shows.. Table 3-1: The GJMA packages - 21 -.

(36) package name. descriptions. org.gjma.application. core package, including main class, loader class and so on. org.gjma.ui. all user interface related classes are put in this package. org.gjma.io. The classes used to handle I/O are put in this package. org.gjma.service. The classes related to UPnP, Web Service and Jini are put in this package. org.gjma.util. The utility classes are put in this package. 3.2.3. GJMAServer The GJMAServer plays an important role in the BROWSER and the MASTER-SLAVE modes. If a GJMApp is run in the STANDALONE mode, the GJMAServer is unnecessary. Generally speaking, the GJMAServer provides runtime environments and services for GJMApps. The GJMAServer’s main functions are application management, communication management, and user interface adaptation. Application management manages the lifecycle of GJMApp. It can load, start, and stop a GJMApp according to end-device requests. Communication management supports different network protocols. It converts all requests into messages, named GJMAMesg described in section 5.2. Moreover, user interface adaptation transforms user interface to different content formats.. 3.3. Three Running Modes in GJMA This subsection discusses the concepts of the three running modes. The mode(s) in which a GJMApp is deployed depends on which end-devices are used, and the decision is made in deployment time. In other words, a GJMApp may be simultaneously deployed in different running modes to support different kinds of end-devices. End-device deployment results may be different even though a GJMApp is deployed in the same running mode because the end-devices may have different functionalities as Figure 3-3 shows.. - 22 -.

(37) GJMAServer. GJMAClient GJMApp X. GJMApp BROWER. a. Y. X. STANDALONE. b. Y. b. (2). GJMAppSlave c. X. MASTER‐SLAVE. (1). GJMAppStandalone X. MASTER‐SLAVE. a. Y. GJMAppSlave Xb. GJMAppMaster. +. a. Y. (3). GJMAppMaster. +. a. Y. (4). Figure 3-3: A GJMApp deployed to different running modes or devices.. Figure 3-3 is a sample to demonstrate the result after deployment. Many details, such as proxy class and other necessary classes, are omitted in this figure to keep it simple. For the same class name, different superscript represents different editions/implementations. In Figure 3-3, the original GJMApp is consisted of two classes, X and Y. Moreover, the GJMApp is deployed to four different end-devices. (1) Deploy the GJMAPP to BROWSR mode. Both X and Y are placed on GJMAServer. (2) Deploy the GJMApp to the STANDALONE mode. Both X and Y are placed on GJMAClient, specially named GJMAppStandalone. (3) Deploy the GJMApp to the MASTER-SLAVE mode. X is placed on GJMAClient, specially named GJMAppSlave and Y is placed on GJMAServer, specially named GJMAppMaster. (4) Deploy the GJMApp to the MASTER-SLAVE mode also. This case is similar to the case (3) but the target end-device is different. Hence, (3) and (4) have different results. In other words, (3) and (4) used different editions of class X.. - 23 -.

(38) 3.3.1. BROWSER Mode In the BROWSER mode, all GJMApp codes are handled by a GJMAServer. The front-tier in Figure 3-1 is a presentation layer, and end-devices are responsible for user interface only as Figure 3-4 shows. End-users can use many types of devices in the front- tier and the GJMA framework will automatically tailor content formats to fit various end-devices in runtime. When a GJMApp is deployed in the BROWSER mode, it can be used by a great majority of browser-enabled devices. This mode is also device-independent, and all GJMApps can be deployed in this mode.. widgets widgets widgets GJMABrowser. GJMAMesg over HTTP, TCP or UDP. Java ME MIDP/Java SE. APP APP APP APP GJMAServer. widgets widgets. Java SE Built‐in browser. HTTP or WAP. Symbian/WinCE Front‐tier. Middle‐tier. Figure 3-4: A diagram for the BROWSER mode. Currently, GJMA systems support two kinds of browsers: built-in browsers and the GJMABrowser. End-users can use either one, but the latter is specifically designed for GJMA use. As a result, it has better display effects and interactive abilities. However, it requires a GJMABrowser installation before use. For built-in browsers, no additional applications need to be installed prior to use.. z. Built-in browser - 24 -.

(39) Mobile devices use many different kinds of built-in browsers, such as XHTML browsers, WAP browsers, and others. They may use different network protocols to communicate, including HTTP and WAP. This means that a GJMAServer must support these different protocols. Currently, most mobile devices have a built-in browser. If an end-device is a non-programmable GJMAClient, its built-in browser is the only interface to interact with GJMApps.. z. GJMABrowser A GJMABrowser is a mobile application capable of drawing UI widgets and handling end-user actions. A GJMABrowser only can be installed on a programmable GJMAClient. It interacts with GJMApps by delivering GJMAMesg between them. The most popular mobile device programming environments are currently Java ME MIDP and .NET CF. Two editions of GJMABrowser are implemented to support both environments.. The front-tier consumes very few resources in this mode because all application codes are handled by the middle-tier. The front-tier is responsible for presentation only. End-users can access several mobile applications simultaneously in this mode, and GJMA provides a menu like the task manager in Microsoft Windows XP (see Figure 3-5). This helps end-users select which GJMApp to start, stop or switch to.. - 25 -.

(40) Figure 3-5: A screenshot of the GJMA task manager. 3.3.2. STANDALONE Mode In the STANDALONE mode, all application codes are run entirely on end-devices and do not need any middle-tier assistance, implying that this mode can be used in an environment without a network. When a GJMApp is deployed in the STANDALONE mode, the entire application, called GJMAppStandalone, will be executed devices which are powerful enough. This mode is device-dependent, so the application must be re-deployed when changing end-devices. In other words, a GJMApp has to be deployed in the STANDALONE mode many times for different end-devices.. 3.3.3. MASTER-SLAVE Mode When a GJMApp is deployed in the MASTER-SLAVE mode, its codes will be divided between end-devices and the GJMAServer as Figure 3-6 shows. The end-device part belongs to GJMAppSlave, and the GJMAServer part belongs to GJMAppMaster. Both of them are generated automatically from the original GJMApp in deployment time. The details will be described in section 4.4.3.. - 26 -.

(41) APP1 widgets widgets. APP2. APP3. GJMAppMaster. GJMAppSlave. GMAMesg over HTTP, TCP or UDP. APP1. GJMAServer Java SE. Java ME MIDP/Java SE Front‐tier. Middle‐tier. Figure 3-6: A diagram for the MASTER-SLAVE mode. 3.3.4. Three Running Modes Comparison Table 3-2 is a comparsion table among the three running modes and there are five criteria in the table. The first criterion is the computing power requirement for end-devices. Today, almost end-devices can access a GJMApp in the BROWSER mode. The second criterion is whether or not need network environemnts when running a GJMApp. If a GJMApp is deployed in STANDLAONE, the GJMApp can be executed when off-line. The third criterion is whether or not support to access multiple GJMApps concurrently. Because almost end-devices, especially hand-held devices, can only run a KVM at the same time, they can only launch a Java application at one time also. The fourth criterion is whether or not need to install additional program on end-devices. In GJMA, only GJMABrowser has to be installed. The final criterion is whether or not to deploy a GJMApp on end-devices before accessing it.. Table 3-2: The comparsion table of the three running modes. BROWSER built-in. MASTER-SLAVE STANDALONE. GJMABrowser. 1. requirements. Low. Middle. High. 2. need network?. Must. Must. No. 3. support multi-tasks?. Yes. No. No. No. No. Yes. Yes. 4. need installation? 5. need deployment?. No. Yes No. - 27 -.

(42) Chapter 4 GJMA Design Issues This chapter contains two parts. The first part introduces system architecture and the second part discusses adaptation mechanisms.. 4.1. GJMAServer Architecture GJMAServer plays an important role in the BROWSER and MASTER-SLAVE running modes because some GJMApp codes are executed by the GJMAServer in these two modes. GJMAServer architecture is shown in Figure 4-1. It can be considered a layered architecture; with an Adaptive Transport Layer, a Message Routing Layer and an Application Runtime Layer from bottom to top. In this way, GJMA can be modularized very well and the layered design makes maintenance and upgrading easier. The following sub-sections will discuss these three layers respectively.. Application Runtime Layer Non‐GJMA resources. Message Routing Layer Adaptive Transport Layer Java Virtual Machine Operating System HTTP. TCP. UDP. Others. Figure 4-1: The layered architecture of GJMAServer.. 4.1.1. Adaptive Transport Layer The Adaptive Transport Layer enables GJMAServer to communicate with different kinds of GJMAClients which may use different network protocols. Figure 4-2 helps illustrate the detailed GJMAServer architecture.. - 28 -.

(43) The primary role in this layer is Communication Manager (CommMngr), which is a super daemon capable of handling many different networks protocols including TCP, UDP, HTTP and so on. It has two missions. First, it establishes the relationship between GJMAServer and GJMAClient when a GJMAClient sends a login request to GJMAServer. Secondly, after successful login, CommMngr creates a logic process (i.e. a user process, including a UserOutD, a UserInD and a UserOutQ) for the GJMAClient. Every logic process might have different components or functionalities depending on which network protocol it uses. The UserOutD is a thread. It is responsible for picking messages called GJMAMesg from the queue named UserOutQ, and sending them to the corresponding GJMAClient directly or translating GJMAMesgs to specific content formats. The UserInD is also a thread. It handles GJMAMesgs from its client directly or translates incoming requests from its client to GJMAMesgs, and then put them into the queue named InnerQueue. Section 4.5 and Section 4.6 introduce the details of this layer’s adaptation mechanisms. In short, the main functionality of this layer is to transform from different network protocols and content formats to GJMAMesgs and to transform GJMAMesgs to different network protocols and content formats.. - 29 -.

(44) Application Runtime Layer. GJMApp1. GJMApp2. GJMApp3. WinMngr. WinMngr. ObjMngr. AppInQ. AppInQ. AppInQ. AppMngr. Message Routing Layer. MesgDispatcher. UserOutQ. UserOutQ. UserOutQ. InnerQueue Translator. Adaptive Transport Layer. CommMngr UserInD. UserOutD. UserInD. UserOutD. UserInD. User process. User process TCP. HTTP. GJMABrowser. UserOutD. User process TCP, UDP, or HTTP. built‐in browser. GJMASlave. Figure 4-2: The detailed architecture of GJMAServer.. 4.1.2. Message Routing Layer The Message Routing Layer implements an asynchronous message delivery mechanism and the process unit in this layer is GJMAMesg, which’s formats is introduced in Section 5.2. This layer is responsible for delivering GJMAMesgs to right queue(s) depending on the information encoded in the GJMAMesgs. For example, when a user presses a button or a GJMApp orders the client-side to create a new UI widget, a corresponding GJMAMesg will be generated and routed to the proper destination. The main components in this layer are Queue and Message Dispatcher (MesgDispatcher). The MesgDispatcher is responsible for routing GJMAMesg to the correct queue(s). Moreover, there are three kinds of queues on GJMAServer: InnerQueue, AppInQ and UserOutQ.. - 30 -.

(45) Every request received by UserInD is translated to a GJMAMesg and placed it into InnerQueue. Then MesgDispatcher will dispatch them to the some AppInQ in which GJMApp will process these GJMAMesg or call Application Manager (AppMngr) to handle the GJMAMesg.. Once a GJMApp generates a GJMAMesg whose destination is a GJMAClient, the message will be placed in UserOutQ within the GJMAClient’s user process. UserOutD within the user process will later send the message to its client or pass the message to the translator according to the kinds of GJMAClient.. If a GJMApp needs to negotiate with other GJMApps on the same GJMAServer, GJMAMesgs will be sent back to InnerQueue and wait for dispatching by MesgDispatcher again.. Since wireless networks are often not stable enough, the GJMA framework uses the asynchronous message delivery mechanism mentioned above for transmissions between GJMAServers and GJMAClients. This mechanism decouples the GJMApp and low-level network protocols, helping the GJMAServer handle disconnection situations and preventing GJMApps from accessing the network directly. After a GJMAClient reconnected, just rebind the previous used GJMApps. Also, this mechanism enables communication among GJMApps and supports one-to-one, one-to-many and many-to-many modes.. 4.1.3. Application Runtime Layer A GJMAServer can serve many GJMAClients at the same time. Also, the GJMAClient can access several GJMApps run on the GJMAServer at the same time if the GJMAClient is a GJMABrowser or a built-in browser. The Application Manager (AppMngr) is responsible for loading, resuming and stopping GJMApps. Before starting a GJMApp, AppMngr will check if - 31 -.

(46) any instance of the GJMApp already exists in the memory. If it does, AppMngr will then check the startup setting of the GJMApp and decide to create a new instance or bind the GJMAClient to the old one. This is useful when a network is temporarily broken. When the GJMAClient re-connects to the GJMAServer, previous work can continue. AppMngr uses different class loader instances to load a GJMApp every time to maintain independent space between them. This lets every GJMApp have its own space. How to use different class loader instances to load class is explained in section 5.1.. 4.2. GJMAClient Architecture There are four kinds of GJMAClient: built-in browser, GJMABrowser, GJMAppSlave, and GJMAppStandalone. It must be noted that the first one can be used by both programmable and non-programmable GJMAClient. The remaining three can only used by programmable GJMAClient. Moreover, GJMAppSlave and GJMAppStandalone are generated from original GJMApp when deployment.. GJMABrowser architecture is similar to the GJMAServer as Figure 4-3 illustrates. Because a GJMABrowser can communicate with only one GJMAServer at a time, there are only a couple of InputD and OutputD in the Adaptive Transport Layer. InputD always listens for an arriving GJMAMesgs; if it gets any, it will put the message to the InputQ. At the same time, Message Handler (MesgHandler) retrieves messages from InputQ asynchronously and passes them to the Command Manager (CmdMngr) or Window Manager (WinMngr). The functionality of WinMngr is to manage widgets created on the GJMABrowser. CmdMngr plays almost the same role that the AppMngr on GJMAServer does, but it does not physically load or stop GJMApp instances. It only issues those requests to the GJMAServer and waits for the results.. Every widget has an associated listener. Whenever the status of a widget is changed by its user, - 32 -.

(47) the listener is triggered and generates some corresponding GJMAMesgs. WinMngr then puts these GJMAMesgs into OutputQ, and OutputD will later send them to the GJMAServer.. Adaptive Transport Layer. Message Routing Layer. Application Runtime Layer. GJMAServer. Figure 4-3. The layered architecture of GJMABrowser.. 4.3. Initialization Process within GJMApp Every GJMApp has to be initialized prior to use, and these initialization process is taken care by the constructor of the class org.gjma.application.GJMApp. Moreover, different running modes may need different initialization process, and this section will discuss them.. 4.3.1. GJMApp in GJMAServer A GJMApp requires different components when running in different modes on a GJMAServer. A GJMApp deployed in the BROWSER mode needs a window manager (WinMngr) to manage all objects related to user interface. A GJMApp deployed in the MASTER-SLAVE mode needs an object manager (ObjMngr) for both parts to manage remote objects. These necessary components are initialized by the org.gjma.application.GJMApp constructor. Hence, when loading a GJMApp, the constructor will be invoked and the necessary components will be initialized automatically. The following content discusses the initialization process of a GJMApp in different running modes.. - 33 -.