NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET MASTEROPPGAVE

NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET FAKULTET FOR INFORMASJONSTEKNOLOGI, MATEMATIKK OG ELEKTROTEKNIKK MASTEROPPGAVE Kandidatens navn: Anders Rene Sveen, Lars Kirkhus Fag: Datateknikk Oppgavens tittel (engelsk): MOWAHS - Mobile Collaboration Framework Oppgavens tekst: This assignment will explore the area of mobile collaboration on mobile devices. Through scenarios, common characteristics for mobile collaboration is to be extracted, resulting in a requirements specification. This specification will be used to initiate development of a framework for supporting collaborative applications on mobile phones. Oppgaven gitt: 20. januar 2004 Besvarelsen leveres innen: 15. juni 2004 Besvarelsen levert: 15. juni 2004 Utført ved: Institutt for datateknikk og informasjonsvitenskap Veileder: Alf Inge Wang Trondheim, 15. juni 2004 Alf Inge Wang Faglærer

Abstract In this thesis the domain of Computer Supported Collaborative Work, CSCW, on mobile phones is examined, and a framework is designed. CSCW on mobile phones is a relatively new research area and largely undiscovered. Third party applications for mobile phones has not been possible until just recently, and few solutions exists for development frameworks. A framework for collaboration on mobile phones will help decrease development costs and increase the spread of applications on mobile phones. Earlier studies has shown that Java 2 Micro Edition, J2ME, would be the best choice as a technology platform for applications. This is mainly because of its popularity on current mobile phones. It has a wide spread on many hardware platforms, and the mobile manufacturers are committed to continue supplying mobile phones with new versions of J2ME. J2ME will thus be the focus of the designed framework. Framework development is an extensive task and requires careful planning and broad knowledge of the problem domain. A framework is meant to cover a wide range of applications and must be extensible and flexible enough to handle most usage scenarios. Analysing the domain and developing requirements is therefore just as important as the design which is based upon it. In this thesis we develop five scenarios which are analysed to extract domain knowledge and find common characteristics. This results in a complete requirement specification for a collaborative framework on mobile phones. The requirements forms the basis for our design process of the framework. During the design two scenarios were used to verify that the requirements and design were in line with the scenarios. The application of these scenarios helped us greatly in making the design less abstract and our reasoning more realistic. We find that the framework covers the requirements as well as the two applied scenarios, and that it will make a good foundation for implementation and testing. Due to the continuous nature of framework development, later iterations will bring forth changes to the framework. But the extensive domain knowledge, thorough analysis and design of this thesis will be an important resource for future improvements. 3

Preface This thesis has been carried out by Lars Kirkhus and Anders René Sveen during the spring semester of 2004. The project is related to the course TDT4900, Software Engineering, Master thesis, which is part of the Masters degree at the Norwegian University of Science and Technology [18]. It has been assigned by the Software Engineering Group [19] at the Department of Computer and Information Science [17]. Acknowledgements We would especially like to thank Associated Professor Alf Inge Wang for his guidance in writing this report. It has been of invaluable help to us to hear his viewpoints and benefit from his experience. Trondheim, June 15th, 2004 Lars Kirkhus Anders R. Sveen 4

Contents 1 Introduction 11 1.1 Motivation.......................................... 12 1.2 Limitation of Scope...................................... 13 1.3 Problem Definition...................................... 14 1.4 Context............................................ 15 1.5 Method............................................ 16 1.6 Readers Guide........................................ 17 I Prestudy 18 2 Previous Work 20 2.1 Mobile devices........................................ 20 2.2 Development platform.................................... 21 2.3 Wireless technology..................................... 21 2.4 Technology solution..................................... 22 3 New Technological Developments 23 3.1 J2ME............................................. 23 3.2 Phones............................................. 23 3.3 Summary........................................... 24 4 Related Work 25 4.1 P2P and ad-hoc networks.................................. 25 4.2 The Anhinga project..................................... 26 4.3 Jadabs............................................. 27 4.4 Proem............................................. 27 4.5 JXTA and JXME....................................... 28 4.6 Summary........................................... 29 5 Designing Frameworks 31 5.1 Implications of J2ME.................................... 31 5.1.1 Connected Limited Device Configuration (CLDC)................ 31 5.1.2 Mobile Information Device Profile (MIDP).................... 32 5.1.3 The Kilobyte Virtual Machine (KVM)....................... 32 5.1.4 Conclusions...................................... 33 5.2 Framework development................................... 33 5.2.1 Layered systems................................... 33 5.2.2 The framework and its parts............................ 34 5.2.3 Development phases................................. 34 6 Our Approach 35 5

CONTENTS II Scenario and Requirements Analysis 36 7 System Scenarios 38 7.1 Strategy game......................................... 38 7.1.1 Goals and preconditions............................... 39 7.1.2 Normal action sequence............................... 39 7.1.3 Critical exceptions and error checking....................... 40 7.2 Information exchange.................................... 40 7.2.1 Goals and precondition............................... 40 7.2.2 Normal action sequence............................... 40 7.2.3 Critical exceptions and error checking....................... 41 7.3 Business card exchange................................... 42 7.3.1 Goals and precondition............................... 42 7.3.2 Normal action sequence............................... 42 7.3.3 Critical exceptions and error checking....................... 42 7.4 Tank game.......................................... 43 7.4.1 Goals and preconditions............................... 43 7.4.2 Normal action sequence............................... 43 7.4.3 Critical exceptions and error checking....................... 44 7.5 Synchronisation........................................ 44 7.5.1 Goals and preconditions............................... 44 7.5.2 Normal action sequence............................... 44 7.5.3 Critical exceptions and error checking....................... 45 8 Scenario Analysis 46 8.1 Goal analysis......................................... 47 8.1.1 Scenario Goals.................................... 47 8.2 Inbound event analysis.................................... 49 8.2.1 Event identification................................. 49 8.2.2 Requirements elaboration.............................. 50 8.3 Output requirements analysis................................ 51 8.3.1 Event identification................................. 52 8.3.2 Requirements elaboration.............................. 53 9 Requirements 54 9.1 Requirements list....................................... 54 9.2 Requirements prioritising.................................. 56 III Design 57 10 Tools 59 10.1 Modelling language...................................... 59 10.2 Computer software...................................... 60 10.2.1 Features........................................ 60 10.2.2 Diagram implications................................ 60 10.2.3 Code synchronisation................................ 61 11 Requirements Resolution 62 11.1 Requirements summary................................... 62 11.2 Requirements and implications............................... 63 12 Domain Concepts 65 12.1 Main structure........................................ 65 12.2 Transport interface...................................... 65 6

CONTENTS 12.3 The domain.......................................... 66 12.3.1 Node.......................................... 66 12.3.2 Group......................................... 67 12.3.3 Service......................................... 67 12.4 Application interface..................................... 67 13 Framework Design 68 13.1 Main package structure................................... 68 13.2 The Core package....................................... 69 13.3 The Transport package.................................... 70 13.4 The Domain package..................................... 72 13.5 Internal relationships in Spectre............................... 73 14 Application Design Using the Framework 75 14.1 Use cases........................................... 75 14.1.1 Business Card Exchange............................... 75 14.1.2 Strategy Game.................................... 76 14.2 Class diagrams........................................ 79 14.2.1 Business Card Exchange............................... 79 14.2.2 Strategy Game.................................... 80 14.3 Sequence diagrams...................................... 83 14.3.1 Startup business card exchange........................... 84 14.3.2 Startup strategy game................................ 86 14.3.3 Search......................................... 87 14.3.4 Connect........................................ 89 14.3.5 Join group request.................................. 91 14.3.6 Group change notification.............................. 93 14.3.7 Transfer........................................ 94 14.3.8 Receive........................................ 96 14.3.9 Execute turn..................................... 98 14.3.10 Full battle....................................... 100 15 Fulfilled Requirements 102 IV Evaluation 104 16 Findings and Contributions 106 16.1 Findings............................................ 106 16.1.1 Computer Supported Cooperative Work...................... 106 16.1.2 Mobile design..................................... 107 16.1.3 Software design.................................... 107 16.2 Contributions......................................... 107 17 Discussion 109 17.1 Methods............................................ 109 17.1.1 Requirements..................................... 109 17.1.2 Design......................................... 110 17.1.3 Method summary................................... 110 17.2 The design.......................................... 110 17.2.1 Applications..................................... 111 17.2.2 Transports...................................... 111 17.2.3 Interfaces....................................... 111 17.2.4 Design summary................................... 111 7

CONTENTS 18 Conclusion 112 19 Future Work 113 19.1 Long term goal........................................ 113 19.2 Implementation........................................ 113 19.3 Transports........................................... 114 19.4 Transactions......................................... 114 19.5 CDC Profile.......................................... 114 19.6 Other devices......................................... 115 20 Our Experience 116 V Appendix 119 Index 121 Bibliography 122 8

List of Tables 9.1 Prioritised functional requirements............................. 56 9

List of Figures 4.1 Anhinga architecture..................................... 26 4.2 Jadabs architecture...................................... 27 4.3 Proem architecture...................................... 28 4.4 JXTA/JXME architecture.................................. 29 8.1 Scenario analysis steps.................................... 46 12.1 Spectre main package structure............................... 66 13.1 Spectre main package structure............................... 69 13.2 Spectre core package..................................... 70 13.3 Spectre transport package.................................. 71 13.4 Spectre domain package................................... 72 13.5 Spectre transport and framework packages......................... 74 14.1 Exchange business card: Startup.............................. 76 14.2 Strategy game: Start game................................. 77 14.3 Strategy game: Execute turn................................ 78 14.4 Business Card Exchange package.............................. 79 14.5 Strategy Game package................................... 80 14.6 Strategy Game in relation to system............................ 82 14.7 Business card exchange: Startup.............................. 85 14.8 Strategy game: Startup................................... 86 14.9 Business card exchange: Search for devices........................ 87 14.10Business card exchange: Connect.............................. 90 14.11Strategy game: Join group request............................. 92 14.12Strategy game: Group change notification......................... 93 14.13Business card exchange: Transfer card........................... 95 14.14Business card exchange: Receive card........................... 96 14.15Strategy game: Execute turn................................ 99 14.16Strategy game: Full Battle.................................. 101

Chapter 1 Introduction Technology that enables collaboration regardless of geographical location is a large research field. It has been explored for a long time, but the continuous emergence of new technologies has made it an never ending research field. The development of the fax-machine has enabled people to share written information faster than through ordinary mail. The development of the Internet has put vast amounts of searchable information at the fingertips of common people, and the emergence of mobile technologies is creating an always available culture where you can reach anyone, anytime, anywhere. Through our fall project [13] we researched mobile collaboration and possible implementation platforms. J2ME were decided upon, but no framework for collaborative applications could be found. In this thesis we wish to explore collaboration on mobile devices, and seek to ease future development of applications through developing a framework for this purpose. One of the many possible applications for a framework like this is a business card exchange application that allows users to exchange and store business cards with people they meet at e.g. a conference. Such an application would require discovery of other persons able to exchange cards, authenticating, connecting and transfer of data. All of these operations can be provided by a framework in a way that abstracts away the low level details and the type of transport technology used. This means less code in the application, and the ability to use several technologies based on the same code. In the following chapter we will outline our focus and the problems we are facing. 11

Introduction 1.1 Motivation Collaboration across mobile heterogeneous devices requires a common language, more precisely termed as a common protocol. Even though devices might not share the same operating system and programming environment, it is possible for them to communicate through such protocols. But even though different platforms can communicate, a program is rarely implemented for all the available platforms. This would require much resources, and few software vendors have the resources available to support multiple platforms. Many programs are just made available on a few selected platforms, and this is especially true for the mobile phone market, where there exists no dominant operating systems and features. Java 2 Micro Edition (J2ME) has the promise of uniting all these different operating systems through a common programming environment that runs on most available platforms today. In our previous project [13] we explored different platforms and found J2ME to be the best platform based on its support for many devices and platforms. By choosing a common programming language that are deployable on several heterogeneous devices, we reduce the effort it takes to develop applications. It is also common to use third party libraries and frameworks to further reduce the programming effort needed. These libraries and frameworks provides easy to use components and functions that covers a certain problem domain, and thus gives the developers out of the box functionality. The field of programming on mobile devices, and especially Java on mobile phones is relatively new, and there are few frameworks available. Today, developing applications that utilise network enabled phones requires a lot a development and understanding about how to use these features. By creating a general framework handling the problems associated with collaboration we wish enable developers to save time and money on development of applications [14]. A framework would also help increasing the number of applications made available. 12

1.2 Limitation of Scope 1.2 Limitation of Scope According to the assignment for this thesis, we will start development of a framework for collaboration on mobile phones. Such an development is a large undertaking which will require careful planning and a extensive knowledge of the problem domain. The planning and understanding of the problem domain is very important for the final outcome, and it should be attended carefully. Devoting time and resources to these subjects early in the process, will help us avoid time consuming mistakes later on. This thesis will therefore devote special attention to analysis and extracting requirements through documented methods and the design of a framework. This will all be in preparation for implementation and testing that will be left for later, and hopefully be carried out by other participants of the MOWAHS project. 13

Introduction 1.3 Problem Definition Development of software is a complicated process. Often programmers spend time implementing the same features on different projects, and solving the same problems. This is cost intensive and time consuming, and is something most companies would like to avoid. In fact most programmers would also like to avoid doing the same tasks over and over again. Programming J2ME on mobile phones is a new field of expertise and has not had the time to mature like standard Java (Java 2 Standard Edition). The availability of extra libraries and frameworks are currently limited, but should increase over time. The industry relies on these libraries to reduce costs and save time, and the J2ME platform will need these to succeed. One of the strengths of standard Java today, is exactly the plethora of libraries and frameworks. Java has over the years become a popular language and has a high momentum regarding releases of new applications. We hope that the development of J2ME applications can be eased by new frameworks and libraries and hopefully gain some of the momentum that Java is experiencing today. We will look at a solution for supporting developers, and wish to make development of collaborative applications easier. By doing this, we hope to promote mobile collaboration, and increase the number of available options for consumers in this area. We will propose a design of a framework related to the problem domain of collaboration on mobile devices. We will analyse the problem domain to find its common characteristics and to create a framework supporting these tasks. The framework will be aimed at J2ME development and strive to save developers time and efforts in creating new collaborative applications. 14

1.4 Context 1.4 Context This thesis is written for the Software Engineering Group at NTNU. They have many projects and interests, and this thesis is in conjunction to the MOWAHS [21] project. MOWAHS is short for MObile Work Across Heterogeneous Systems and it focuses on collaboration technology for the distributed workplace. The MOWAHS goals are as following: Helping to understand and to continuously assess and improve work processes in virtual organisations. Providing a flexible, common work environment to execute and share real work processes and their artifacts, applicable on a variety of electronic devices (from big servers to small PDAs). Disseminating the results to colleagues, students, companies, and the community at large. The MOWAHS project has two sub-projects that are both working to fulfil these goals: Process support for mobile users using heterogeneous devices. Cooperating transactions support, and distributed workspaces. The area of cooperating transactions is focusing on how to maintain valid transactions over fragile communications links. When a user is on the move he may start a transaction which gets broken, or he might even start a transaction while offline. This must be committed when the user comes back online, and one must ensure that no information is lost. Our focus will be within the other area; process support. We will explore how to support mobile collaboration, while leaving the transaction aspects for later exploration. 15

Introduction 1.5 Method As described in limitation of scope, Section 1.2, this is not a project that aims to do both design and implement the system. Our focus will be to do extensive research into the problem domain, as well as create a design for future implementation. The following is a rough plan for the execution of this thesis: Research : As we are fairly inexperienced with framework design it will be an important task to research the theory surrounding it. A framework design requires special considerations, and it will be important to understand these. In addition it will be important to obtain insight as to which limitations is imposed by the targeted hardware platform. Domain knowledge : The domain knowledge is important and creates the whole base for the framework. Incorrect information about the domain results in a framework covering other requirements than those of the domain. It is therefore essential to find methods to extract the domain knowledge, and the requirements for the framework. Design : The design is based on the domain knowledge and the requirements. It, together with the discussion is the final results of this thesis, and will make up the foundation for later iterations. Discussion and future : As this thesis aims to create a solid foundation for future work it will be important to describe the strengths and weaknesses of the design. Any assumptions made, and possible directions will be an important starting point for the next iteration. Writing a thesis with thorough methods for analysis and planning will in many ways be an new experience to us. Many projects undertaken earlier in our education has had an clear focus on producing code, and maybe drawing attention away from the planning and preparations. While many projects has produced executable code it has also shown that this code usually is thrown away after the completion. This is often due to an unstructured and poorly planned approach to the development. In this thesis we hope to lay down a solid platform for future development, and a framework that will live well beyond our thesis. 16

1.6 Readers Guide 1.6 Readers Guide In this section we will give a short overview to guide you through the rest of this thesis. It aims at giving the reader a better understanding of which parts we consider interesting and important, and let you skim through the parts with information not needed or previously known for your reading. This report is divided into the following parts and chapters: Part I Prestudy - Reviews the background information necessary for this thesis. Useful to understand what principles has been guiding us when designing the framework. Chapter 2 Previous work - Describes the relevant findings from our previous project. Chapter 3 New Technological Developments - Describes technological changes since the previous project. Chapter 4 Related Work - Describes projects and software related to this thesis. Chapter 5 Designing Frameworks - Theory of framework design. Chapter 6 Our Approach - Describes our approach for the rest of the thesis. Part II Scenario and Requirements Analysis - Describes the scenarios and analyses them. The details of the analysis is only for specially interested parties. The average reader should take a look at the requirements, and read the scenarios to understand where the requirements are found. Chapter 7 System Scenarios - All the scenarios that will be used to extract our requirements are described in detail in this chapter. Chapter 8 Scenario Analysis - Analysis of the scenarios to extract the requirements. Chapter 9 Requirements - The resulting requirements. Prioritised for this thesis. Part III Design - The main result of this thesis, and important to understand the framework. Chapter 13 contains the main framework, while the other chapters are support to explain and clarify the concepts. Chapter 10 Tools - Describes the tools used and some of the implications. Chapter 11 Requirements Resolution - Describes special considerations to take when designing the framework. Chapter 12 Domain Concepts - Describes the concepts used in the design of the framework. Chapter 13 Framework Design - The main framework design. Chapter 14 Application Design Using the Framework - Two applications is applied to the design and used to develop and verify the framework. Chapter 15 Framework Fulfilment of Requirements - Summarises how the framework fulfils the requirements, and discusses shortcomings and possible problems. Part IV Evaluation - Describes our findings and discussion of the thesis. Appendix Chapter 16 Findings and Contributions - Describes the findings of the previous parts and summarises our our contributions. Chapter 17 Discussion - Discussion of process and design. Strengths, weaknesses and problems that might arise. Chapter 18 Conclusion - The conclusions made from our work. Chapter 19 Future Work - Describes possible future work, and topics not covered in this thesis. Chapter 20 Our Experience - Describes our experience with writing this thesis and the problems we have encountered. 17

Part I Prestudy 18

This thesis will be based on some of the findings of our project [13] that was carried out during the autumn of 2003. The project title was An examination of mobile devices for spontaneous collaboration and examined several types of mobile devices and development platforms which could be user for developing collaborative applications. It also described some related projects for mobile collaboration. This part will summarise the findings of our previous project, if there has been any new technological developments since our previous project, related work and an examination on how to design frameworks. 19

Chapter 2 Previous Work In our previous report [13] we examined the usage of mobile devices for spontaneous collaboration. As our initial setting we used a series of articles [10, 12, 16, 20] describing various types of collaborative support applications that included programmable name tags, wearable computers and modified PDAs. All of these supported spontaneous collaboration in one way or another. One of these projects was especially interesting, the Proem project [10]. Much of our work were based on the concept described in this project. The Proem project aimed at supporting informal collaboration through exchange of profiles between users. It relied on wearable computers that featured wireless networking. When two users came close to each other, the two devices would find each other and exchange profiles. Each device would then match the newly downloaded profile against a set of rules. These rules would determine if the profile should be stored for later usage or if the user should be notified. In our prestudy we set out to find the most suitable mobile device for collaboration. The attributes that we used when evaluating the possibilities were the following: Spread: Is this a technology common or has it the potential to become widely used? Transparency: Is this a technology that are familiar to the users and easy to use? Mobility: Is this technology something most users would bring with them without thinking about it? Non-centralised network: Can this technology establish ad-hoc connections with others without relying on a centralised infrastructure? These attributes were weighted after importance and evaluated against each technology. The resulting grades were used to find the most suitable technology within each category. For more information about this, see Chapter 3 in our previous report [13]. The choice of technology made in the previous report will be used in this thesis, and form the basis of our technology platform. The following sections will describe the technology choices made. 2.1 Mobile devices When considering our evaluation attributes we found that there were only two mobile devices that would satisfy our demands: Personal Digital Assistants (PDA) and mobile phones. The evaluation 20

2.2 Development platform concluded that mobile phones had a clear advantage over PDAs when considering spread, transparency and mobility. It was therefore natural to focus on the available phones in the consumer market and technologies available on such phones. 2.2 Development platform Mobile phones comes several different development platforms. It was important for us to find a technology that would satisfy our evaluation attributes and make a solid foundation for future development. J2ME 1 (Java 2 Micro Edition) is a lightweight version of Java designed for small and limited devices. It includes a subset of the standard Java API and some new API s focused on small devices. Mophun 2 is a development platform for game development on mobile phones. It includes C, C++ and assembler programming interfaces. BREW 3 (Binary Runtime Environment) is an application platform for mobile devices and based on C/C++. It is by many considered as the main competitor for J2ME, but the spread outside North-America is still limited. Symbian 4 is an operating system for mobile devices which offers solutions for developing thirdparty applications. Symbian is C/C++ based. Microsoft Smartphone 5 is an operating system and is based on Windows CE. It supports C/C++ development as well as the.net framework. Palm OS 6 is an operating system developed for Palm PDAs and includes C/C++ support for application development. There were several viable options, but after our evaluation we decided on J2ME because of its spread in the consumer market. The prospects for the future also suggests that J2ME will become even more common on mobile phones in the coming years. J2ME includes several programming libraries and has the promise of becoming the de facto application platform for mobile devices. For a more detailed description of J2ME, see Section 5.1. 2.3 Wireless technology Choosing a network medium was next on our list. We knew from the start that it had to be a wireless technology to ensure mobility. The wireless technologies we examined were the following: IR - Infra-Red WLAN - Wireless Local Area Network 1 http://java.sun.com/j2me 2 http://www.mophun.com 3 http://www.qualcomm.com/brew/ 4 http://www.symbian.com/ 5 http://www.microsoft.com/windowsmobile/products/smartphone/default.mspx 6 http://www.palmsource.com 21

Previous Work Bluetooth IR has the drawback of being short range (about 1 meter), and can only connect two devices at the same time. The users also have to align the devices with a clear line of sight to connect. We were looking for a technology which would be more transparent for the user. After evaluating WLAN we came to the conclusion that it is usually only included in larger devices such as PDAs or laptops, partly due the high power consumption. Bluetooth on the other hand is becoming a common feature for high-end mobile phones and is being embraced by most mobile phone manufacturers. Bluetooth was chosen for its large spread. 2.4 Technology solution As we described in the last three sections, we came to the following conclusions about what technologies to use: Mobile device: Mobile phones Development platform: J2ME Wireless technology: Bluetooth After choosing the most suitable technologies for our research we proceeded to study and test some of the main features of the technologies. As mentioned earlier the choice of platform is considered to still apply to this thesis. An exception would be for Bluetooth, since we will be looking to create a framework that is flexible enough to support several types of communication technologies. Alternatives might be both WLAN as mentioned above, as well as GPRS. In the next chapter we will look at new developments, and check that no changes has occurred that makes our choice of platform invalid. 22

Chapter 3 New Technological Developments The field of computer technology has evolved rapidly the last 20 years, and continues to develop at a fast pace. In these sections we will discuss the current situation compared to the fall project [13], and describe some of the new technological advances. As mentioned in Section 2 the technology chosen was J2ME on mobile phones. Since all our technologies are rather new, they are not expected to undergo large changes in the near future. The standards are finalised, and it will take a lot of work before they are changed again. One exception is the Bluetooth standard [6], but this is not considered critical since this thesis will not rely on Bluetooth. The other technologies is described below. 3.1 J2ME J2ME is a fairly new technology that we discuss in depth in our fall project [13]. For mobile phones the Connected Limited Device Configuration (CLDC) 1.0 and Mobile Information Device Profile (MIDP) 1.0 and 2.0 profiles are relevant. MIDP 2.0 was released towards the end of last year, and there has not been many implemented applications for these standards. We are now starting to see more applications available, and the number of devices implementing MIDP 2.0 should increase. A new version of CLDC, 1.1, is scheduled for release in late 2004. This will take time to implement on phones, and planning for this new specification should not be a priority at this stage. 3.2 Phones Both SonyEricsson and Nokia has lately released phones that are compatible with CLDC 1.0 and MIDP 2.0, and there are generally more phones available than last fall. These were the standards decided upon in our fall project [13], and we will continue to use them in this thesis. There are currently two phones available; the SonyEricsson P900 and the Nokia 6600. There has also been several announcements of new phones that should be available in the second quarter of 2004. We should see a great incline in phones supporting these standards in 2004. The first phones will be high-end business phones, while the cheaper consumer market phones will follow later on. We expect the already wide adaptation of MIDP 1.0 on mobile phones to extend to MIDP 2.0 as more and more people upgrade their phones. 23

New Technological Developments 3.3 Summary The available technologies and solutions has not changed significantly since our report last fall. This is partly because we knew about announced products that would be available, and because three to four months is not a very long time when it comes to cutting edge technology. The preconditions set out for choosing technologies in our fall project still apply, and we will not do another extensive technology evaluation in this thesis. 24

Chapter 4 Related Work This section will describe some of the related projects for this thesis. Most of these projects are aimed at custom built devices and devices that are more inconvenient to carry around than modern mobile phones. They also have far more processing power than mobile phones, and many of the experiments have utilised Java 2 Standard Edition (J2SE). Because of this the frameworks described in this chapter will mostly be of inspiration to us when designing our own framework. Some of the concepts will be hard to transfer to Java 2 Micro Edition while some of the concepts will be useful and worth absorbing in our own framework. 4.1 P2P and ad-hoc networks The following projects all utilise some form of networking to communicate. Many of them define their networks as ad-hoc, while others define it as peer-to-peer (P2P). The following is a short explanation of the differences between ad-hoc and P2P. According to [7] P2P refers to a class of systems and applications that employ distributed resources to perform a critical function in a decentralised manner. Some might argue that this is a quite narrow definition of P2P, but it does create a clean distinction between P2P and ad-hoc networks. Ad-hoc means temporary or for one purpose only. This is what happens when several units supporting ad-hoc networking comes close. They create a temporary network, that lasts for a limited time and is created for the purpose of exchanging information in that setting. Two ad-hoc networks are rarely identical and usually different for each context. This means that P2P networks might have temporary and ad-hoc-like properties, but ad-hoc networks are not P2P networks. The P2P model also includes requirements for more advanced routing, and resource management, while an ad-hoc network does not impose any requirements of this kind other than that the devices can communicate through the network. 25

Related Work 4.2 The Anhinga project The Anhinga project 1 is being developed by the Department of Computer Science, Rochester Institute of Technology. It aims to create a distributed computing infrastructure to support collaborative applications on wireless ad-hoc networks. It focuses on a decentralised structure and execution on mobile devices. Anhinga is based on Many-2-Many Invocation which means that each invocation is broadcast throughout the entire network and every object that has receptors for that kind of invocation will execute it. This eliminates the need for central servers and advanced routing, which makes it ideal for ad-hoc networks with low computational power [1]. The architecture of the Anhinga Project is illustrated in Figure 4.1. Figure 4.1: Anhinga architecture Main features of the Anhinga project include: Broadcast based Many-2-Many invocation for distributed applications Object oriented invocation of distributed functions Low computational overhead The project has been implemented and tested with example applications and concept code, and the libraries are available for download. Even though the project is aimed at mobile devices, it uses J2SE, and will not run on J2ME devices. Its main focus is towards PDAs like the Sharp Zaurus or the ipaq which can run a complete J2SE version. 1 http://www.cs.rit.edu/~anhinga/ 26

4.3 Jadabs 4.3 Jadabs The Jadabs project 2 is being developed by the Information and Communication Systems Research Group at the Swiss Federal Institute of Technology, Zurich. Its aim is to build a dynamic framework to enable mobile devices to insert, replace and remove applications at runtime. Communication is handled by an ad-hoc network and supports both UDP and Bluetooth connections. It does not support collaboration specific operations, and focuses on hot deployment of new applications in adhoc networks during runtime. The Jadabs architecture can be seen in Figure 4.2, and the main part if its code is contained in the core layer. Figure 4.2: Jadabs architecture Main features of the Jadabs project include: Hot deployment of new applications at runtime Ad-hoc network support over UDP and Bluetooth Standard based communication through JXME Jadabs is an interesting architecture that would enable propagation of applications to new people you meet on the street. It is not a relevant framework for our use, because this kind of propagation requires support that is only available in the CDC configuration and not CLDC, see [13] for further details about the relationship between CDC and CLDC. The CLDC lacks important functionality like reflection, which is common for frameworks, and necessary for the Jadabs project to utilise. Because of this, Jadabs in its current form will not run on J2ME enabled mobile phones. For more information about J2ME limitations see Section 5.1. 4.4 Proem The Proem platform 3 was one of the first frameworks for supporting collaboration on mobile devices. It focuses on the exchange of personal information through user profiles, and is a proven technology. 2 http://www.iks.inf.ethz.ch/projects/jadabs 3 http://www.cs.uoregon.edu/research/wearables/proem/ 27

Related Work It was designed to run on wearable computers that support standard Java runtime (J2SE). These computers were made by picking apart standard laptop computers. Main features of the Proem project include: Profile exchange Profile security mechanisms Profile search Event handling for ad-hoc networks (ex. User close by, user signed on) Figure 4.3: Proem architecture Figure 4.3 shows how profiles is an integral part of the Proem architecture. It is an interesting framework centred around location based encounters. Its focus is mainly on information search in profiles, but the framework is extensible enough to support other types of applications. Sadly Proem has not had any activity for a long time and there will probably never be a J2ME port of it. 4.5 JXTA and JXME JXTA 4, short for Juxtapose - meaning side by side, is an open source Java initiative from Sun Microsystems 5, focusing on P2P networks. The framework initially started as a J2SE project targeted on desktop computers, but with the introduction of J2ME the need for support on small mobile devices became evident. JXME 6, JXTA for J2ME, is targeted at both the CDC and CLDC configuration. Because CLDC is the configuration available on mobile phones, it is the implementation we will be looking into. 4 http://jxta.org 5 http://www.sun.com 6 http://jxme.jxta.org 28

4.6 Summary Figure 4.4: JXTA/JXME architecture Because the MIDP profiles, both 1.0 and 2.0, does not support XML, and XML is part of the data format in JXTA, the implementors of JXME needed to make some simplifications. This resulted in JXME not being a complete P2P solution (one that does not rely on a central server), but relies on a centralised relay node that does the heavy processing and communicates with the phones. This node is usually a desktop computer and communicates with the rest of the JXTA network on behalf of the J2ME nodes. It parses the XML and serialises it to a format the J2ME nodes is able to understand, see Figure 4.4 for JXME architecture. The JXTA and JXME project are advanced P2P projects that has matured over the last years. Because the J2ME version relies on a centralised server it is not a viable option for our use. However, a proxy less version is under development, but progress on this has been extremely limited the last year. The advanced P2P architecture of JXTA is hard to implement on resource constrained devices like mobile phones. The basic ideas of the JXTA framework will be an important inspiration for us when designing our framework. 4.6 Summary Although there are some closely related projects being developed for J2ME, not many of them are ready for real world usage just yet. Common for many of them is that they target the CDC platform and thus are not available on mobile phones. There are some speculation that phones in the future will migrate to CDC because of their increased processing power, but this is just speculations. We are looking for solutions currently available for CLDC. 29

Related Work When designing a framework for collaboration we recognise the trouble associated with the J2ME platform and heavy computing. We will be looking to create a simple framework that has a reasonable chance of being deployed in the near future. It will enable developers to create simple collaborative applications while implementing advanced P2P functionality at a later stage. 30

Chapter 5 Designing Frameworks Design of frameworks differs some from the design of applications. The level of abstraction is higher and the range of problems it is supposed to solve needs to fit with several applications. The following sections will study the technology and the limitations it enforces on the design, as well as theory associated with framework design. 5.1 Implications of J2ME J2ME shares its syntax and programming style with regular Java, but to be able to fit this runtime environment into small devices like mobile phones some parts of the Java language had to be removed. These devices have limited memory, CPU power and display sizes and had to be reflected in the J2ME implementation. This section will describe J2ME and try to anticipate any limitations that need to be taken into consideration when developing a framework. J2ME consist of three parts: runtime engine, configuration and profile. The configuration specifies the minimum features available on a device, as well as the limitations for applications. The profile is concerned with the high level details as screen size and user interface. The runtime is an implementation of the configuration and the requirements set forth by it. Most mobile phones adheres to the CLDC specification. The profile implemented is the MIDP profile. For an in-depth description of the parts and the relation between them, see our fall project [13]. 5.1.1 Connected Limited Device Configuration (CLDC) The CLDC specifies the limitations, features available, and the basic APIs that are supported in the runtime environment. To make the implementation as compact as possible some features from J2SE was left out. This includes [22]: The Java Native Interface User-defined class loaders Reflection Thread groups and daemon threads Finalisation 31

Designing Frameworks Weak references AWT Floating point number The most important exclusions to note is the removal of reflection [11], AWT and floating point numbers. AWT defines a user interface suitable for desktop computing. When creating software for smaller devices this GUI had to be redesigned, and AWT was not needed any more. The MIDP profile takes care of the GUI for mobile phones, it will be described shortly. Floating point numbers are rarely supported by the hardware of these small devices, and could not be included in the specification. The CLDC also defines many of the APIs available. Specifically the java.io, java.lang, java.util and javax.microedition.io packages [22]. In these packages there are classes that share their interface with the equivalent J2SE implementation, as well as other classes that are a cut down version of the J2SE classes. Some APIs might not support the functions we are used to from J2SE. This will not be a big problem though, and will only impose some minor limitations. A new version of the CLDC is planned, and will be available for mobile phones late this year. This is version 1.1 and amongst other things adds floating point calculations and weak references. It is backwards compatible and is an evolution of the 1.0, and thus should be easy to upgrade to when its spread has become sufficient. As mentioned earlier the spread of this new configuration will take and our focus will be on the 1.0 specification. The configuration does not handle user interfaces, and leaves that part to the profiles. Because of this CLDC often exists on a multitude of different devices with different profiles, ex. mobile phones and pagers. 5.1.2 Mobile Information Device Profile (MIDP) The MIDP profile defines APIs for supporting devices with small screens, limited user input options and little memory. This includes supported networking protocols, interface classes and persistent storage. Persistent storage in MIDP is implemented as a recordstore. It is under heavy security constraints and belong to the specified MIDlet. This means that one MIDlet can not access information in the persistent storage that belongs to another MIDlet. The network protocols defined by the MIDP will also restrain what communications that can be implemented between devices. The MIDP 1.0 implementations had some very noticeable constraints, as missing TCP server sockets and no Bluetooth support. This has been fixed in the MIDP 2.0 specification and it is regarded a more complete implementation. We will target the 2.0 specification, and even though many weaknesses has been corrected it is important to take these limitations into consideration. 5.1.3 The Kilobyte Virtual Machine (KVM) The KVM is the runtime environment for J2ME as implemented by Sun. It is a small footprint java virtual machine, and it must be installed on a phone to enable Java execution. Because the features are dictated by the configuration implemented, the KVM should impose no extra limitations beside the ones in the CLDC specification. 32

5.2 Framework development 5.1.4 Conclusions Although Java is a familiar language to us, the J2ME implementation impose some restrictions. It also redefines some of the APIs as well as limiting the number of available APIs. We need to take this into consideration when designing our framework. Some of these limitations will become evident in an implementation, while others can be predicted earlier on. We know that the float type is not supported, and we know that reflection is not supported either. Many frameworks today utilise a combination of XML files and reflection to allow dynamic configuration, but this is of course not an option for us. 5.2 Framework development Good framework design is expensive and has many aspects that needs to be taken into consideration. While it must be simple enough to be learned, it must also provide the features needed so it can be used quickly. Another important aspect is to provide hooks for new features, and features that are likely to change [8]. In this section we will outline some of the concepts to take into consideration when designing such a framework. We will later utilise this knowledge when looking at our requirements and designing the framework. 5.2.1 Layered systems According to Bachmann et al. [9] the layered view of an architecture is one of the most commonly used views in software architecture. Some even try to describe non-layered architectures with a layered view, thus giving a false impression that it is layered. This only shows us that layered architectures are common and desirable from a system development point of view. According to Bachmann et al. a layered system is described by several characteristics: A layer is a separate unit of cooperating components, that has a interface which it delivers its service through. The choice in design of layers is based on considerations as coupling, cohesion and likelihood of change. The relationship between layers are specified by implementation allowed to use. Use in this case is specified as layer A uses layer B if As correctness depends on the correctness of B as well. The allowed to use relations follow a top-down pattern where the lower layers does not use layers above. Many different allowed to use relations that does not follow a top-down manner suggests the system has a bad design. Lower layers tend to be closer to the hardware than the upper layers. Also according to Bachmann et al. the quality attributes, modifiability and portability are affected by the layer structure of the software system. It is an important tool to manage complexity and communicate the structure of software, and will be an important part of our design. 33