Medische gegevensuitwisseling met mobiele applicaties

Medische gegevensuitwisseling met mobiele applicaties Wim Claeys

Promotoren: prof. dr. ir. Filip De Turck, dr. ir. Sofie Van Hoecke Begeleiders: ir. Thomas Dupont, ir. Wannes Kerckhove Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen Academiejaar 2009-2010

Medische gegevensuitwisseling met mobiele applicaties Wim Claeys

Promotoren: prof. dr. ir. Filip De Turck, dr. ir. Sofie Van Hoecke Begeleiders: ir. Thomas Dupont, ir. Wannes Kerckhove Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter Faculteit Ingenieurswetenschappen Academiejaar 2009-2010

Voorwoord

De zoektocht naar een onderwerp voor mijn masterproef bleek eenvoudiger dan verwacht. De combinatie van e-Health, OSGi en de mobiele wereld sprak mij enorm aan en de keuze was dan ook snel gemaakt. Bovendien was het uitdagend en motiverend om te weten dat het resultaat van deze masterproef gebruikt zou kunnen worden in het ICSP. Ik heb dan ook met plezier deze masterproef kunnen voltooien. Ik zou ook graag van deze gelegenheid willen gebruik maken om enkele mensen te bedanken. Eerst en vooral wil ik mijn promotoren prof. dr. ir. Filip De Turck en dr. ir. Sofie Van Hoecke bedanken om deze masterproef mogelijk te maken. Natuurlijk kunnen mijn masterproef begeleiders, ir. Thomas Dupont en ir. Wannes Kerckhove, niet ontbreken. Ik dank Sofie, Thomas en Wannes voor alle tijd en energie die ze in dit werk staken. Zij stonden afgelopen jaar steeds klaar om mijn vragen te beantwoorden en mij te begeleiden bij verdere ontwikkelingen. Daarnaast hadden ze nog talloze waardevolle tips bij het schrijven van dit boek en de extended abstract. Tenslotte zou ik graag mijn ouders en vriendin, Sabine, willen bedanken voor hun onvoorwaardelijke steun en het nalezen van dit boek.

Wim Claeys, mei 2010

Toelating tot bruikleen

“De auteur geeft de toelating deze masterproef voor consultatie beschikbaar te stellen en delen van de masterproef te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze masterproef.”

Wim Claeys, mei 2010

Medische gegevensuitwisseling met mobiele applicaties door Wim CLAEYS Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Academiejaar 2009–2010 Promotoren: prof. dr. ir. Filip DE TURCK & dr. ir. Sofie VAN HOECKE Begeleiders: ir. Thomas DUPONT & ir. Wannes KERCKHOVE Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël DE ZUTTER

Samenvatting Op kritieke diensten, zoals de dienst intensieve zorg, is het van groot belang om snel en adequaat een medische diagnose te stellen op basis van de monitoring- en labogegevens van de patiënten. Het Intensive Care Service Platform of ICSP ondersteunt de arts bij de opvolging van zijn patiënten. De services suggereren een medische beslissing, berekenen scores of geven de evolutie van de patiënt weer. De artsen kunnen zich inschrijven op één of meerdere patiënt/service combinaties. Afhankelijk van het type bericht, wensen artsen de gegevens op hun PDA te ontvangen, DECT telefoon, in hun mailbox of gepresenteerd op de bedside terminal. In deze masterproef wordt onderzocht hoe dergelijke berichten op een PDA kunnen ontvangen worden via asynchrone berichtgeving. Het is immers niet de bedoeling dat mobiele toestellen constant pollen naar nieuwe resultaten. De data moet afgeleverd worden via push technologie van zodra deze beschikbaar is. Na onderzoek en keuze van het mobiele besturingssysteem, de ontwikkelomgeving en de soort push methodes, wordt een proof of concept implementatie ontwikkeld waarbij het design rekening houdt met het batterij-verbruik en de eenvoud van onderhoud. Wat deze laatste vereiste betreft, is onderzocht hoe OSGi gebruikt kan worden om nieuwe versies van de mobiele applicatie, net als de berichten, te kunnen pushen naar de mobiele toestellen. De proof of concept wordt aan verschillende experimenten onderworpen om daarna de nodige conclusies te trekken betreffende de prestatie en schaalbaarheid van het systeem.

Trefwoorden Web Service, PDA, OSGi, Java ME CDC, Push system, Windows Mobile

Medical data exchange with mobile applications Wim Claeys Supervisor(s): prof. dr. ir. Filip De Turck, dr. ir. Sofie Van Hoecke, ir. Thomas Dupont, ir. Wannes Kerckhove Abstract— On critical medical services, like the intensive care unit, it is important to quickly and effectively make medical decisions based on monitoring and laboratory data of patients. The Intensive Care Service Platform (ICSP) supports doctors in monitoring their patients by suggesting medical decisions or showing the evolution of their patients. In this article, a proof of concept is presented to push these messages to mobile applications, while the design takes the battery life of the mobile device and the ease of maintenance into account. Keywords— Intensive Care Service Platform (ICSP), Web Service, PDA, OSGi, Java ME CDC, Push system, Windows Mobile

T

I. I NTRODUCTION

HE Intensive Care Service Platform (ICSP) [1] supports doctors in monitoring their patients and is currently evaluated by the Intensive Care Unit (ICU) of the UZ Ghent [2]. This platform integrates all the participants of the medical diagnostic process, such as laboratories, monitors, doctors, nurses, etc. The services of the ICSP suggest a medical decision, calculate scores or show the evolution of the patient. Doctors can subscribe to one or more patient/service combinations, so they only receive medical reports on their patients and are not overloaded with unimportant messages. Depending on the type of message, doctors want to receive the data on their PDA, DECT phone, in their mailbox or presented at the bedside terminal. To get the medical information anytime and anywhere when necessary, an efficient and intelligent data routing system is needed while the messages are being processed quickly and asynchronously. Because of the active Wi-Fi battery consumption of a mobile device [3], the device should not constantly poll for new results. This paper presents a solution that delivers these messages to the PDA through push technology once the data becomes available. Firstly, we look at the details of such a solution. From there on we see how the proof of concept was built and tested. This article ends with an overview of the future work and the conclusions. II. S OLUTION The first part of this section briefly explains the choice of the mobile operating system. The second part handles the development environment in which the presented solution operates. The last part of this section discusses the use of push mechanisms. A. Mobile operating system Mobile operating systems are the basis for building mobile applications. They all have their own specifications, advantages and disadvantages. However, within the framework of this academic research a mobile operating system is needed where both extensive mobile network research and research on mobile battery efficiency is possible. Based on existing research [4], a

Fig. 1. Conceptual view of the ICSP Mobile solution

study was held, that resulted in Windows Mobile [5] being the only mobile operating system that meets these requirements. B. Development environment To meet the ease of maintenance requirement, the OSGi specification was examined to see how it can be used to create new versions of the mobile application. These new versions are pushed, like the medical messages, to the PDA. This is possible, because OSGi [6] is a dynamic module system based on services. The OSGi Service Platform defines a model for an application life cycle and a service registry. The reusable components, called bundles, can be installed, started, updated, stopped and uninstalled. The Apache Felix [7] implementation is a Java implementation and was chosen, because it is smaller and slightly stricter in its interpretation of the OSGi specification compared to its competitors. As a result of the OSGi technology choice as a modular Java system that is easy to maintain, a minimum Java ME CDC v1.0 configuration is required. The Connected Device Configuration (CDC) supports, in contrast with the Connected Limited Device Configuration (CLDC), among other functionalities, userdefined class loaders, the Serializable interface and parts of the reflection capabilities. The phoneME Advanced [8] software was selected as the most reliable and stable Java ME CDC implementation that can operate on top of Windows Mobile 6.5.

C. Data communication In order to push the medical messages to the PDA, several existing mechanisms were inspected. The larger part of current push technologies on the market do not use a real push mechanism. They rather rely on polling, streaming or long poll schemes. These polling systems are inefficient, slow and have a negative impact on the battery consumption of the mobile device. As a consequence, the PDA uses two types of real push mechanisms. When the battery of the mobile device is not critical, a mini webserver is deployed on the PDA, thereby enabling a real push mechanism. When the battery of the mobile device becomes critical, SMS is used as push mechanism. After the PDA receives an SMS, a regular pull request is initiated to get the latest medical data.

Fig. 2. Multiple clients: average RTT (s)

RTT and response time of the system were measured in different situations. When the number of clients rises, it has little effect on the RTT of the system (see figure 2). When the number of services that actively run on the PDA rises, the callback time rises exponentially. The response time however, does not rise significantly. So the notification system performs well in both situations.

III. P ROOF OF CONCEPT

IV. F UTURE WORK

The proof of concepts main architecture implements the Publish/Subscribe pattern (see figure 1). After registration, Medical Services can publish new medical data to the Pub/Sub Broker. Doctors can subscribe to several patient/service combinations in order to receive these medical updates (notify). Additionally, Bundle Developers can publish new versions of the mobile software, initiating a bundle update in the OSGi container of the mobile receivers. The Medical Services and Bundle Developers use SOAP to communicate with the broker, while the Pub/Sub Broker and the Mobile Receivers communicate through a binary protocol. The Mobile Receiver application that is written, uses Thinlet [9] as the GUI component. It provides a single class based on AWT, implementing all the necessary GUI elements for a rich environment. Java Native Access [10] was used in order to communicate with the underlying operating system and query the battery status. Small C++ DLLs were created to provide access to the Connection Manager and above all, to catch SMS messages that were send by the Pub/Sub Broker. At the Pub/Sub Broker application, each Mobile Receiver has its own sending queue. This queue contains the events (MobileEvents) that are waiting to be send to their corresponding Mobile Receiver. A ContactTask object is part of a threadpool that the Pub/Sub Broker provides and is responsible for executing the following task: At first, it will try to push the event to the mobile device through Wi-Fi. When this fails, an SMS message is send. At this point, the ContactTask stops working, but will be reinitiated when the Mobile Receiver, after receiving the text message, requests the latest event. Because of the slow reputation of SMS gateways, the Pub/Sub Broker sends the textmessages with the aid of a connected mobile phone through a serial cable and sending AT commands to the GSM’s modem. Both the Pub/Sub Broker’s and Mobile Receiver’s implementation were coded with special attention to future users, e.g. developers of medical services or maintainers of the system. Abstract classes are provided to implement new server or mobile (medical) services. These classes take on a lot of responsibility in registering the service and providing communications. All of this is completely transparent to the developer. The program was put through a series of tests in which the

Although the proof of concept is fully functional, there are some points where improvement and further development is possible. A first important improvement is security. Medical data is sensitive and cannot be send over the air unprotectedly. The next opportunity of improvement can be found in how the mobile receivers are contacted. The proof of concept uses a threadpool with a preset size for the tasks that contact the mobile receivers. This could potentially become a bottleneck. A solution to this problem is to transform these tasks to a distributed environment. An interesting topic for future developments is to consider what contribution Mobile IPv6 can make to push systems. Mobile IPv6 allows an IPv6 client to arbitrary change its location on the network, while still retaining the existing connections. V. C ONCLUSIONS This article discusses a solution that is based on a comprehensive state-of-the-art study. The implemented proof of concept was evaluated and future work opportunities were presented. Furthermore, thanks to its generic structure, the software can be used in any context where there is a need for a push system in a mobile environment. In conclusion, the developed solution has a high added value as an extension of the current ICSP platform. R EFERENCES [1] S. Van Hoecke, J. Decruyenaere, C. Danneels, K. Taveirne, K. Colpaert, E. Hoste, B. Dhoedt and F. De Turck. Service-oriented Subscription Management of Medical Decision Data in the Intensive Care Unit, Methods of Information in Medicine 2008; 47 (4): 364-380. [2] Intensive Care Unit of the Ghent University Hospital. http://www.icu.be/. [3] J. Sharkey. Coding for Life – Battery Life, That Is, http://code.google.com/intl/nl/events/io/2009/ sessions/CodingLifeBatteryLife.html. [4] A Oliver. Survey of platforms for mobile networks research, Sigmobile Rev. 12, 4 (Feb. 2009), 56-63. [5] Windows Mobile 6.5. http://www.microsoft.com/windowsmobile. [6] OSGi Alliance. www.osgi.org/. [7] Apache Felix. http://felix.apache.org/. [8] phoneME Advanced. Java ME CDC implementation, http://phoneme.dev.java.net/. [9] R. Bajzat. Thinlet GUI Toolkit, http://thinlet.sourceforge.net/home.html, 2006. [10] Java Native Access. http://jna.dev.java.net/.

INHOUDSOPGAVE

i

Inhoudsopgave

1 Inleiding

1

2 Mobiele technologie onderzoek

3

2.1

2.2

2.3

Besturingssystemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.1

iPhone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.2

Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.3

Blackberry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.4

Symbian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.1.5

Windows Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

2.1.6

Andere mobiele besturingssystemen . . . . . . . . . . . . . . . . . . . . .

7

2.1.7

Vergelijkende studie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

Applicatie-management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2.1

OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2.2

Mobile OSGi & JSR 232 . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.2.3

OSGi implementaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12

2.2.4

Alternatieven voor OSGi

. . . . . . . . . . . . . . . . . . . . . . . . . . .

13

2.2.5

Vergelijking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

Ontwikkelomgevingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

2.3.1

14

Java ME

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

INHOUDSOPGAVE

2.4

2.5

ii

2.3.2

Sprint Titan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

2.3.3

Flash Lite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

2.3.4

Web Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

2.3.5

eRCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.3.6

Ice Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

2.3.7

JavaFX Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.3.8

AGUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

2.3.9

Thinlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

Datacommunicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.4.1

Pull-technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

2.4.2

Push-technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

2.4.3

HTTP Server push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

2.4.4

Comet en Bayeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

2.4.5

SMS en WAP Push

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.4.6

XMPP en SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

2.4.7

MIDP Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

Technologie keuze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3 Specificatie

30

3.1

Use Case

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

3.2

Key Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.3

Quality attributes requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.3.1

Usability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.3.2

Modifiability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

3.3.3

Performance

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

3.3.4

Adaptability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

INHOUDSOPGAVE

3.3.5 3.4

iii

Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Main Success Scenarios

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

3.4.1

Registreren voor het ontvangen van notificaties . . . . . . . . . . . . . . .

33

3.4.2

Deregistreren van het ontvangen van notificaties . . . . . . . . . . . . . .

34

3.4.3

Starten/stoppen van een werkshift . . . . . . . . . . . . . . . . . . . . . .

34

3.4.4

Het ontvangen van notificaties en de mogelijkheid tot feedback . . . . . .

35

4 Architectuur 4.1

4.2

4.3

32

36

Component View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

4.1.1

Algemeen systeem: ICSP Mobile . . . . . . . . . . . . . . . . . . . . . . .

36

4.1.2

Subsysteem: Pub/Sub Broker . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.1.3

Subsysteem: Mobile Receiver . . . . . . . . . . . . . . . . . . . . . . . . .

44

Collaboration View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50

4.2.1

Sequentiediagrammen tussen de subsystemen . . . . . . . . . . . . . . . .

51

4.2.2

Sequentiediagrammen van de Pub/Sub Broker . . . . . . . . . . . . . . .

52

4.2.3

Sequentiediagrammen van de Mobile Receiver . . . . . . . . . . . . . . . .

56

Deployment View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

5 Implementatie

61

5.1

Algemeen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

5.2

Mobiele ontvanger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

5.2.1

Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

5.2.2

Grafische gebruikers interface . . . . . . . . . . . . . . . . . . . . . . . . .

64

5.2.3

JNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

Pub/Sub Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

5.3.1

SOAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

5.3.2

SMS verzenden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

5.3

INHOUDSOPGAVE

5.4

iv

5.3.3

Binair REST protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

70

5.3.4

Mobiele ontvanger contacteren . . . . . . . . . . . . . . . . . . . . . . . .

71

5.3.5

Datastore module

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

Externe services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

6 Evaluatie 6.1

6.2

75

Prestatie testen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

6.1.1

Opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

75

6.1.2

Stijgend aantal services . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

6.1.3

Stijgend aantal clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

6.1.4

Batterijverbruik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82

6.1.5

SMS notificatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

Functionele test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

6.2.1

De medische service en de bundel ontwikkelaar . . . . . . . . . . . . . . .

84

6.2.2

De arts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

85

7 Conclusies

87

7.1

Verdere ontwikkelingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

87

7.2

Algemeen Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

88

INHOUDSOPGAVE

Tabel met afkortingen en symbolen API

Application Programming Interface

CDC

Connected Device Configuration

CLDC

Connected Limited Device Configuration

CORBA

Common Object Request Broker Architecture

CSS

Cascading Style Sheets

DECT

Digital Enhanced Cordless Telecommunications

DLL

Dynamic Link Library

FP

Foundation Profile

GPRS

General Packet Radio Service

GSM

Global System for Mobile Communications

GUI

Graphical User Interface

HTTP

Hypertext Transfer Protocol

ICSP

Intensive Care Service Platform

IP

Internet Protocol

JBI

Java Business Integration

JCP

Java Community Process

JNA

Java Native Access

JNI

Java Native Interface

JPA

Java Persistence API

JSR

Java Specification Request

MIDP

Mobile Information Device Profile

MIME

Multipurpose Internet Mail Extensions

MVC

Model View Controller

OS

Operating System

PBP

Personal Basis Profile

PDA

Personal Digital Assistant

PP

Personal Profile

REST

Representational State Transfer

RTT

Round Trip Time

v

INHOUDSOPGAVE

SDK

Software Development Kit

SMS

Short Message Service

SOAP

Simple Object Access Protocol

SQL

Structured Query Language

VM

Virtual Machine

Wi-Fi

Wireless Fidelity

WSDL

Web Service Definition Language

XML

Extensible Markup Language

vi

INLEIDING

1

Hoofdstuk 1

Inleiding Op kritieke diensten, zoals de dienst intensieve zorg, is het van groot belang om snel en adequaat een medische diagnose te stellen op basis van de monitoring- en labogegevens van de patiënten. Het Intensive Care Service Platform of ICSP ondersteunt de arts bij de opvolging van zijn patiënten. Dit platform integreert alle actoren binnen het medisch diagnose proces zoals labo’s, monitoren, artsen, verpleegkundigen, etc. De services suggereren een medische beslissing, berekenen scores of geven de evolutie van de patiënt weer. De artsen kunnen zich inschrijven op één of meerdere patiënt/service combinaties. Op deze manier krijgen artsen enkel medische berichten betreffende hun patiënten en worden ze niet overbelast met onbelangrijke output berichten. Afhankelijk van het type bericht, wensen artsen de gegevens op hun PDA te ontvangen, DECT telefoon, in hun mailbox of gepresenteerd op de bedside terminal. Om de medische gegevens overal en altijd te krijgen waar nodig, is er bijgevolg efficiënte en intelligente gegevensroutering nodig en moeten berichten vlot en asynchroon verwerkt worden. Het is immers niet de bedoeling dat mobiele toestellen constant pollen naar nieuwe resultaten. De data moet afgeleverd worden via push technologie van zodra deze beschikbaar is. Het doel van deze masterproef bestaat er in te kijken hoe dergelijke berichten op een PDA kunnen ontvangen worden via asynchrone berichtgeving. Daarnaast moet het met de ontwikkelde proof of concept mogelijk zijn om berichten te sturen naar mobiele applicaties, waarbij het design rekening houdt met het batterij-verbruik en de eenvoud van onderhoud. Voor deze laatste vereiste, zal onderzocht worden hoe OSGi gebruikt kan worden om nieuwe versies van de mobiele applicatie, net als de berichten, te kunnen pushen naar de mobiele toestellen. Via een eenvoudige en gebruiksvriendelijke grafische gebruikers

INLEIDING

2

interface moeten de artsen zich kunnen registreren op de medische berichten. Tenslotte is het ook de bedoeling via enkele testen de schaalbaarheid en prestatie van de proof-of-concept te evalueren. Dit boek is als volgt opgedeeld. Hoofdstuk 2 is het state-of-the-art onderzoek. Er wordt onderzocht welke verschillende besturingssystemen er op de markt zijn voor mobiele toestellen en welk mobiel besturingssyteem het best zou gebruikt worden bij de implementatie. Vervolgens komen verschillende ontwikkelomgevingen aan bod waarin de proof of concept mogelijks kan ge¨ımplementeerd worden. Verder wordt onderzocht wat OSGi is en hoe het kan gebruikt worden om nieuwe versies van de mobiele applicatie, net als de berichten, te kunnen pushen naar de mobiele ontvangers. Een laatste belangrijk deel wat onderzocht wordt, zijn de huidige push systemen op de markt met hun vooren nadelen. In hoofdstuk 3 wordt de gewenste specificatie van het programma uit de doeken gedaan en de use case die zal worden gebruikt tijdens de implementatie - meer bepaald de ABDose use case uitgewerkt. In hoofdstuk 4 volgt dan de beschrijving van de implementatie. Dit hoofdstuk verduidelijkt de gebruikte bibliotheken en tools. Er worden ook oplossingen voor tegengekomen problemen tijdens het implementatie proces beschreven. In hoofdstuk 5 wordt de architectuur van heel het systeem uitgewerkt. Aan de hand van componentdiagrammen en sequentiediagrammen wordt de architectuur van zowel de server zijde als de client zijde verduidelijkt. In hoofdstuk 6 wordt de ontworpen applicatie getest op prestatie en schaalbaarheid. De roundtrip time en de response time van het systeem worden geëvalueerd, alsook de levensduur van de batterij van een mobiel toestel. Tot slot rondt hoofdstuk 7 af met de conclusies en voorstellen voor toekomstige ontwikkelingen.

MOBIELE TECHNOLOGIE ONDERZOEK

3

Hoofdstuk 2

Mobiele technologie onderzoek Aan de hand van een state-of-the-art onderzoek worden in dit hoofdstuk verschillende mobiele platformen en technologieën onderzocht, daarnaast komen ook applicatie-management voor mobiele applicaties en (mobiele) push technologie bij het onderzoek aan bod (zie figuur 2.1). Doorheen dit technologisch onderzoek wordt gepoogd uit de wirwar van mobiele platformen en technologieën tot een gegronde keuze te komen en te verklaren waarom bepaalde technologieën gebruikt zullen worden.

2.1

Besturingssystemen

Mobiele besturingssystemen vormen de grondslag voor het bouwen van mobiele applicaties. Aan de hand van eerder wetenschappelijk onderzoek [3, 13] worden de volgende vijf mobiele besturingssystemen onderzocht: iPhone, Android, Blackberry, Symbian en Windows Mobile.

2.1.1

iPhone

Apple heeft voor de iPhone het besturingssysteem OS X iPhone [15] ontwikkeld. De laatste versie van dit gedeeltelijk gesloten bron besturingssyteem is iPhone OS 3.1. Het besturingssysteem is momenteel het populairste onder mobiele software-ontwikkelaars [13]. Er wordt gebruik gemaakt van XCode - wat gratis geleverd wordt bij de SDK - om applicaties te ontwikkelen voor de iPhone en de iPod Touch. Het laden van een applicatie in het mobiele toestel is echter enkel mogelijk nadat men zich heeft geregistreerd als betalend lid van het ’iPhone Developer Program’.

2.1 Besturingssystemen

4

Datacommunicatie

Ontwikkelomgeving

Besturingssysteem

Figuur 2.1: Overzicht state-of-the-art Distributie van iPhone applicaties kan gebeuren op twee manieren. Ten eerste kan men de applicatie beschikbaar stellen op de Apple AppStore, maar dit vereist dat de applicaties worden ’gesigned’ (kost van $99/jaar) na goedkeuring van Apple. Een tweede manier is om de applicatie ’ad-hoc’ te distribueren, dit is echter maar mogelijk op maximaal 100 iPhones. Er is echter (soms) ook de mogelijkheid om een iPhone te ’jailbreaken’1 , al zal dit altijd een kat en muisspel blijven met Apple [16]. Door deze beperkingen voor applicatie-ontwikkelaars zal het iPhone besturingssysteem niet verder worden onderzocht.

2.1.2

Android

Android [18] is een mobiel platform gebaseerd op Java bovenop een Linux kernel (2.6). Door middel van Android maakt Google zijn intrede in de mobiele wereld. Het besturingssysteem is oorspronkelijk ontworpen door Google, en later door de Open Handset Alliance [20] overgenomen. Samen met soft- en hardwarebedrijven en mobiele operatoren bouwen ze aan een open en gratis mobiel platform. Google Android is een open platform, zowel in open bron als in open API. Dit brengt echter risico’s met zich mee. Google wil Android volledig open houden, zonder een overkoepelend orgaan dat de applicaties moet goedkeuren zoals dat bij Apple het geval is. Wanneer ontwikkelaars de vrijheid krijgen om te veranderen wat ze willen, bestaat het risico dat het platform versplinterd raakt. Aanpassingen aan het platform door middel van applicaties, kunnen er immers voor zorgen dat applicaties van andere ontwikkelaars niet meer werken [21]. De door Google ontwikkelde 1

Jailbreak is het openen van het bestandssysteem van de iPhone. Hierdoor krijgen ook andere programmas

dan iTunes toegang tot de iPhone, waardoor het mogelijk wordt extra software te installeren. [17]


5

Java API is bovendien een subset van de Java SE 5 [22]. Applicaties worden geprogrammeerd in Java, maar draaien niet op de Sun JVM. In plaats daarvan wordt de Dalvik Virtual Machine [23] gebruikt. Er wordt geen verschil gemaakt tussen native en niet native applicaties. Iedereen heeft toegang tot dezelfde API. Android is vrij nieuw en is nog altijd aan het veranderen en verbeteren. Het is belangrijk om op te merken dat de fabrikanten van de Android-toestellen behoren tot de grootste in de wereld 2 en het platform omarmd wordt door veel mobiele operatoren. De Android API’s zijn modern en uitgebreid. Naast de typische API’s heeft Android ondersteuning voor een lokale relationele databank via SQLite. Android ondersteunt ook het programmatische scannen naar Wi-Fi toegangspunten, maar het laat echter niet toe via een specifieke netwerk interface connecties tot stand te brengen of een specifieke netwerk interface te beheren. Tenslotte zijn toepassingen in staat om de toestand van de batterij en de laadstatus op te vragen en is het bovendien ook mogelijk om energiebesparende maatregelen door te voeren. Bijvoorbeeld door het toestel in slaapmodus te brengen of in een toestand van laag energieverbruik [19, 3].

2.1.3

Blackberry

BlackBerry [30] is ontwikkeld door het Canadese bedrijf Research In Motion [31]. Alle applicaties op de smartphone zijn geschreven in Java en bevinden zich in een beschermde run-time omgeving. Als ontwikkelplatform, doet Blackberry zijn reputatie alle eer aan qua degelijkheid en betrouwbaarheid. Het heeft een rijke verzameling van bibliotheken en maakt het mogelijk applicaties naadloos te laten samenwerken. Het platform staat echter niet toe programmatisch te scannen naar Wi-Fi toegangspunten. Een applicatie kan alleen gegevens ontvangen over het toegangspunt waarmee hij op dat moment is aangesloten. Energie monitoring op de Blackberry is wel meer verfijnd in vergelijking met Android. Het platform biedt uitgebreide API’s voor onder andere het raadplegen van de toestand van de batterij, de status van opladen, de temperatuur en de mogelijkheid om het scherm (blacklight) in en uit te schakelen. Research in Motion is een hardware leverancier, maar ze proberen wel een community te creëren door hun SDK open te stellen. Dit wordt waarschijnlijk gevoed door de concurrentie van Android en iPhone. Tenslotte moet de applicatie ondertekend worden door Research In Motion opdat het maken van low-level API-aanroepen mogelijk zou zijn. Dit vereist een eenmalige aankoop van een ’code signing PIN’ [32, 3]. 2

Google, HTC, Intel, LG, Motorola, Nvidia, Sprint Nextel, T-Mobile, Sony Ericsson, Toshiba Corp, Vodafone

en vele andere.


2.1.4

6

Symbian

Symbian [24] bezit (momenteel) 50% van de mondiale smartphone-markt [14], het meest gebruikte besturingssysteem voor mobiele telefoons. Eind 2008 richtte Symbian samen met Nokia en Sony Ericsson de Symbian Foundation [25] op. Hun missie: ’to enable a global business ecosystem that collaborates to create the richest and most satisfying mobile user experiences’. Het Symbian-platform is een open bron besturingssysteem gebaseerd op Symbian OS. Symbian OS is een volledig multitasking besturingssysteem, met ondersteuning voor meerdere processen en meerdere threads binnen deze processen. Het maakt daarbij uitgebreid gebruik van een client/server-omgeving waarbij de server diensten ter beschikking stelt voor meerdere clients. Symbian OS-servers maken eigenlijk gebruik van een event handling systeem, in plaats van meerdere threads, om meerdere klanten te dienen. Symbian biedt geen ondersteuning voor programmatische beheer van netwerk interfaces, maar bevat wel een uitgebreid energiebeheer systeem. Het Symbian-platform is verder ge¨ıntegreerd met software die is ingebracht door de leden van de Symbian Foundation (o.a. de vroegere UI platformen: UIQ van Sony Ericsson en de Nokia series 80). Gedeeltes van de eerder gesloten broncodes worden momenteel open bron gemaakt. Medio 2010 zal dit proces volledig te zijn. Op dat moment zal de volledige broncode beschikbaar zijn [25].

2.1.5

Windows Mobile

Windows Mobile [26] is een besturingssysteem ontwikkeld door Microsoft voor mobiele toestellen. De laatste versie is 6.5: Windows Phone. Windows Mobile 7, genaamd naar zijn grote broer Windows 7, is in ontwikkeling. Sinds Windows Mobile 6 zijn er 3 versies van het besturingssysteem: Classic, Standard en Pro. De klassieke versie (Classic) is voor een toestel dat geen telefoonfuncties bevat. De Standard en Pro versie is bedoeld voor een toestel met telefoonfunctie en respectievelijk zonder en met aanraakscherm. [27] Software-ontwikkelaars kunnen applicaties ontwikkelen door gebruik te maken van Visual C++ (native) en/of door gebruik te maken van Visual C#/Visual Basic (managed code). De laatste twee talen in het bijzonder hebben een uitgebreide ondersteuning voor het .NET Compact Framework [28]. Dit framework is een subset van het .NET Framework waardoor ontwikkeling en debugging ook mogelijk is met Visual Studio.NET. Het .NET Compact Framework heeft onder-


7

steuning voor threads, XML, web services (SOAP) en een ingebouwde SQL database (licentie vereist) [29]. Windows Mobile laat een volledig beheer van de netwerk interfaces toe (connecties tot stand brengen op een specifieke netwerk interface, netwerk interfaces aan- en uitzetten).

2.1.6

Andere mobiele besturingssystemen

Naast iPhone OS, Android, Blackberry OS, Symbian en Windows Mobile bestaan er nog enkele open en gesloten bron besturingssystemen. Hieronder volgt een opsomming van de open bron besturingssystemen: 1. OpenMoko [49] 2. LiMo Foundation [50] 3. Maemo [51] 4. Access Linux Platform, ALP (opvolger van Palm OS overgekocht door Access Co. in 2005 [52]) Dit zijn opkomende besturingssystemen, en voorlopig zijn er slechts enkele mobiele toestellen op de markt die deze OS draaien. Volgende gesloten bron systemen bestaan ook: 1. Palm webOS Palm webOS [53] is volgens Palm de volgende generatie in mobiele platformen. De gebruikerservaring is ontwikkeld rond multitasking en de eenvoud van een webbrowser. Het beschikt over een web gebaseerde applicatie, heeft ondersteuning voor touchscreen input en is nauw verbonden met het internet en verschillende web services. De applicatieontwikkelomgeving wordt Mojo genoemd. Mojo is gebaseerd op HTML 5, CSS en JavaScript. Palm heeft momenteel enkele mobiele toestellen met het webOS platform (Palm Pre en Palm Pixi). [54, 55] 2. BREW De Binary Runtime Environment for Wireless (BREW) is een programmeeromgeving ontwikkeld door Qualcomm. BREW is vrij populair in de VS, maar heeft weinig penetratie in Europa. BREW applicaties worden ontwikkeld met behulp van C-code. De volgende


8

evolutie van de BREW client, Brew Mobile Platform (Brew MP), ondersteunt applicaties geschreven in Flash of C-code. [56]

2.1.7

Vergelijkende studie

In het kader van dit academisch onderzoek wordt gezocht naar een platform waarmee zowel mobiel netwerkonderzoek als onderzoek naar mobiele batterij-efficiëntie mogelijk zijn. We evalueren de vijf voorheen besproken besturingssystemen aan de hand van volgende karakteristieken [3]: 1. De mogelijkheid om te scannen naar een netwerk: Om toegang te krijgen tot een draadloos netwerk, moet het mogelijk zijn te scannen naar draadloze toegangspunten (’access points’). 2. De mogelijkheid om een netwerkinterface te selecteren, bij aanwezigheid van meerdere netwerkinterfaces (wat gebruikelijk is op veel van de huidige smartphones): Elke draadloze technologie heeft namelijk zijn vooren nadelen. Wi-Fi heeft bijvoorbeeld een lage monetaire kost, maar het verbruikt meer stroom dan een andere datatransmissie technologie zoals EDGE. [11] 3. Het beheer van een netwerk interface: Het vermogen om zelfstandig netwerk interfaces in en uit te schakelen kunnen een significant effect hebben op de levensduur van de batterij van een mobiel toestel. 4. De energiestatus meten: Ook in de nabije toekomst blijft het maximaliseren van de levensduur van de batterij een belangrijk punt. Het is dus handig het energieverbruik van een mobiel toestel (ten minste bij benadering) te achterhalen. 5. Mogelijkheid om energiebesparende maatregelen te kunnen doorvoeren: Een natuurlijke uitbreiding op het meten van het energieverbruik is het vermogen om het te controleren. Omdat het maximaliseren van de levensduur van de batterij essentieel is voor mobiele toestellen in het algemeen, zijn deze functies doorgaans ingebouwd in het besturingssysteem. Het meest bekende is waarschijnlijk het tijdelijk uitschakelen van het LCD-scherm na verloop van enige tijd.

2.2 Applicatie-management

9

iPhone

Android

Symbian

Windows M.

Blackberry

Scannen naar netwerk

+

+

∼

+

-

Netwerk interface selectie

+

-

+

+

+

Beheer van netwerk interface

-

+

-

+

+

Energiestatus meten

+

+

+

+

+

Energiebesparende maatregelen

∼

+

+

+

+

Legende: + =ondersteund, ∼ =gedeeltelijk ondersteund, - =niet ondersteund

Tabel 2.1: Vijf besturingssystemen en hun mogelijkheden [3]

Tabel 2.1 toont de vijf besturingssystemen en hun ondersteuning voor de beschreven karakteristieken [3]. Windows Mobile is het enige mobiele besturingssyteem dat voldoet aan alle vijf de karakteristieken en zal daarom binnen deze masterproef meer in detail onderzocht worden.

2.2

Applicatie-management

Aangezien verschillende mobiele toepassingen mainstream worden, groeit de complexiteit van de mobiele applicaties. Toepassingen vereisen vaak dezelfde functies zoals gebruikers authenticatie, transactie ondersteuning en transparante data toegang. Daarom is het zinvol om deze gemeenschappelijke functies als services beschikbaar te stellen in software containers die werken op mobiele toestellen. In de volgende sectie wordt een standaard container specificatie ge¨ıntroduceerd: de OSGi specificatie.

2.2.1

OSGi

OSGi [57] is een dynamisch module systeem dat gebaseerd is op services. De specificatie voor deze open standaard wordt ontwikkeld door de OSGi Alliance (voorheen Open Services Gateway initiative). De OSGi Alliance, bestaande uit een groot aantal vooraanstaande bedrijven 3 , heeft als missie het beheren en publiceren van deze Java specificatie, het certificeren van implementaties en het organiseren van events. Oorspronkelijk was OSGi bedoeld voor thuisautomatisering, maar momenteel worden specificaties van OSGi ook ge¨ımplementeerd in automobiele software, mobiele toepassingen en zelfs in de Eclipse software-ontwikkelomgeving. [59] 3

zoals Ericsson, IBM, Siemens, Motorola en Sun Microsystems


10

De basis voor deze standaard is het OSGi Service Platform. Dit platform levert de bouwstenen waarmee applicaties opgebouwd kunnen worden op basis van kleine, herbruikbare componenten (zogenaamde bundels). Het OSGi Service platform definieert een model voor een applicatielevenscyclus en een service-register. Daarnaast levert het functies waarmee de samenstelling van een applicatie dynamisch kan worden aangepast zonder dat de applicatie opnieuw gestart hoeft te worden. Bundels kunnen namelijk van op afstand dynamisch ge¨ınstalleerd, gestart, ge¨ updatet, gestopt en gede¨ınstalleerd worden. [1, 58] Bovenop dit platform werden een groot aantal OSGi Services gedefinieerd zoals HTTP servers, configuratie, logging, beveiliging, gebruikers administratie, XML-parsing en vele anderen. De OSGi specificatie kan genieten van verschillende commerciële en enkele populaire open bron implementaties zoals Apache Felix [65], Knopflerfish [66] en Eclipse Equinox [67].

Figuur 2.2: OSGi architectuur

OSGi Architectuur Een OSGi bundel is eigenlijk niet meer dan een JAR bestand met een manifest waarin extra meta-informatie staat. Meta-informatie zoals de naam van de bundel, versie-nummer, de klasse die moet opgeroepen worden wanneer de bundel wordt geactiveerd, en import en export packages. Import packages zijn de nodige afhankelijkheden van een bundel terwijl export packages de packages zijn die een bundel zelf ter beschikking stelt voor andere bundels. Naast de bundels, is het platform opgebouwd uit de volgende lagen: Security laag, Module laag,


11

Life-cyle laag en Service laag. Figuur 2.2 toont de gelaagde OSGi architectuur. Elke laag heeft zijn eigen functie en draagt bij tot de goede werking van het OSGi platform. De Security laag behandelt de beveilingsaspecten door de mogelijkheden van een bundel te beperken. De Service laag verbindt de bundels op een dynamische manier door een publiceer-zoek-bind-model voor Plain Old Java-objecten (POJO) ter beschikking te stellen en maakt daarbij gebruik van een service register. De Life-cycle laag maakt het mogelijk bundels te kunnen installeren, starten, stoppen, bij te werken en te verwijderen. Figuur 2.3 toont de levenscyclus van bundels. De Module laag tenslotte definieert hoe een bundel code kan importeren en exporteren. [57]

Figuur 2.3: OSGi bundel levenscyclus [2]

2.2.2

Mobile OSGi & JSR 232

De mobiele specificatie [60] van OSGi kwam samen met Release 4 (september 2006) uit en is de onderliggende technologie van JSR 232 (Mobile Operational Management) [61]. Dit platform voorziet een gestandaardiseerde omgeving voor bundels die het toelaat aan mobiele toestellen zich dynamisch aan te passen. Mobile OSGi vereist minimum de Java ME Connected Device Configuration v1.0, plus een Foundation Profile v1.0. Dit impliceert dat het populaire CLDC/MIDP2.0 profiel (zie hieromtrent supra 2.3.1) OSGi niet ondersteunt.


2.2.3

12

OSGi implementaties

Conci¨ erge Conciërge [68] is een zeer compacte en geoptimaliseerde implementatie van de OSGi Release 3 specificatie. Dit maakt het bijzonder geschikt voor platforms met beperkte middelen zoals mobiele toestellen. Conciërge is beschikbaar onder een BSD licentie. Doordat Conciërge een OSGi Release 3 implementatie is, ondersteunt het echter niet de JSR 232 standaard, wat een OSGi Release 4 implementatie wel doet. [2]

Equinox Equinox [67] is tegenwoordig het meest gebruikte OSGi platform door zijn gebruik in de Eclipseontwikkelomgeving. Equinox implementeert Release 4.2 van de OSGi specificaties en is beschikbaar onder de Eclipse Public License (EPL). [2]

Knopflerfish Knopflerfish [66] is een populaire uitvoering van zowel OSGi Release 3 en Release 4.2 specificaties. Het wordt ontwikkeld en onderhouden door Makewave AB, een onderneming gevestigd in Zweden. Knopflerfish is beschikbaar onder een BSD-licentie. Makewave biedt ook Knopflerfish Pro, een commercieel ondersteunde versie van Knopflerfish. [2]

Apache Felix Felix [65] is een community implementatie van OSGi Release 4.2 onder de Apache groep. Apache Felix is de opvolger van het eerdere OSGi Oscar platform. Het is ontworpen voor compactheid en gemak van inbedding, en is de kleinste (in termen van JAR omvang) van de Release 4 implementaties. Apache Felix is beschikbaar onder de Apache-licentie versie 2.0. [2]

IBM Lotus Expeditor IBM Lotus Expeditor [69] is een commerciële implementatie van OSGi met eRCP (zie supra 2.3.5).


2.2.4

13

Alternatieven voor OSGi

De JSR 277 is eigenlijk het enigste alternatief dat in de buurt komt van OSGi. Vroeger had men ook het Eclipse Plug-in systeem, maar dit werd sinds de Eclipse IDE versie 3.0 omgeruild voor OSGi.

JSR 277: Java Module System Java Specification Request nummer 277 is getiteld ’Java Module System’ [70]. Het belangrijkste punt om op te merken is dat op het moment van schrijven, JSR 277 een onvolledige specificatie is zonder implementatie. Er zijn plannen om het op te nemen in Java 7, maar het is onduidelijk wanneer Java 7 er zal komen. Een eerste ontwerp van JSR 277 is uitgebracht in oktober 2006 en is de beste informatie die momenteel beschikbaar is. JSR 277 heeft geen ondersteuning voor package-niveau afhankelijkheden, maar maakt gebruik van volledige module afhankelijkheden. Bovendien is JSR 277 niet dynamisch. Het vereist dat de Java Virtual Machine opnieuw wordt gestart om een module te installeren, bij te werken of te verwijderen. (Ook het in Eclipse Plug-in systeem waren afhankelijkheden gebaseerd op volledige modules en was het niet dynamisch.) Helaas komt JSR 277 vele jaren later dan OSGi en omvat het een aantal twijfelachtige ontwerpfuncties. Het lijkt op dit moment althans een stap achteruit te zijn voor modulariteit in Java. [2]

2.2.5

Vergelijking

Equinox heeft het voordeel dat het ge¨ıntegreerdt is in eRCP(zie supra 2.3.5). Apache Felix heeft op zijn beurt ook enkele kleine voordelen in vergelijking met de andere open bron implementaties. Het is een vrij compacte Release 4 uitvoering. De core van Felix is ongeveer 378kB groot versus Equinox 822kB (Knopflerfish is rond de 366kB). Bovendien is Felix iets strenger in zijn interpretatie van de OSGi specificatie, dus een bundel die werkt op Felix is quasi gegarandeerd te werken op Equinox en Knopflerfish. Ten slotte is Felix proefondervindelijk eenvoudig te configureren en te integreren in andere Java-toepassingen. [2]

2.3 Ontwikkelomgevingen

2.3 2.3.1

14

Ontwikkelomgevingen Java ME

Een Java-platform is een software-platform dat alleen boven op een native-platform draait. Dit is een combinatie van het besturingssysteem en de onderliggende hardware. Java ME [35] is het meest populaire applicatie platform voor mobiele toestellen. [13] Het biedt een robuuste, flexibele omgeving voor toepassingen die op een breed scala toestellen draaien, zoals mobiele telefoons, PDA’s, TV set-top boxen en printers. Java Micro Edition is een subset van de Java Standard Edition (met een beperkte verzameling van API’s). Java ME (vroeger genaamd de Java 2 Micro Edition, J2ME) is gedefinieerd door de JCP. Applicaties zijn overdraagbaar (”portable”) over verschillende mobiele platformen heen. Dit bereikt men door de mobiele toestellen onder te verdelen in verschillende configuraties, profielen en de mogelijkheid om optionele pakketten toe te voegen.

Configuraties Een configuratie definieert een minimale Java runtime omgeving die geschikt is voor een bepaalde klasse of een groep van mobiele toestellen. Er zijn twee configuraties: • Connected Limited Device Configuration (CLDC) • Connected Device Configuration (CDC) Deze configuraties hebben elk hun eigen virtuele machine en bibliotheken die een basisfunctionaliteit aanbieden. CLDC komt met KVM (Kilobyte Virtual Machine) en kan enkel toestellen ondersteunen met een beperkt geheugen(128-512 KB) en een langzamere processor(16 of 32 bits). CDC heeft een CVM (Compact Virtual Machine) en kan mobiele toestellen ondersteunen met een minimum van 2MB geheugen en een 32-bit processor. De CDC en de CLDC zijn nauw met elkaar verbonden omdat de CDC een superset is van de CLDC. Wat dit betekent is dat de code geschreven voor de CLDC ook uitgevoerd kan worden in de CDC, op voorwaarde dat alle profielen, klassen en specifieke extensies waarvan de code gebruikt maakt ook beschikbaar zijn. Er is enige voorzichtheid bij het programmeren vereist wanneer het wisselen tussen configuraties gewenst is. Configuraties, worden net als alle JSRs,


15

herzien van tijd tot tijd om nieuwe functies toe te voegen. Zo zijn er momenteel twee versies van de CLDC beschikbaar, 1.0 (JSR-30) en 1.1 (JSR-139), en twee versies van de CDC, 1.0 (JSR-36) en 1.1 (JSR-218).

Profielen Een profiel breidt een configuratie uit met extra API’s. Hierdoor worden de mogelijkheden van het platform voor applicatie-ontwikkelaars vergroot, maar verkleint het tegelijkertijd het aantal type toestellen die worden ondersteund. Een profiel kan extra hardware en software vereisten opleggen die hoger zijn dan of een aanvulling zijn op die van de onderliggende configuratie. Het eerste Java ME-CLDC profiel dat ontwikkeld en vrijgegeven is door de JCP was de MIDP (Mobile Information Device Profile). De meeste Java mobiele toestellen maken tegenwoordig gebruik van een CLDC-platform en bieden ondersteuning voor ofwel MIDP 1.0 of MIDP 2.0 (MIDP 3.0 [36] is in ontwikkeling). Beide profielen worden gebruikt voor het draaien van applicaties op mobiele telefoons en interactieve pagers met kleine schermen, draadloze HTTP-connectiviteit en een beperkt geheugen. Deze applicaties worden ’Midlets’ genoemd. Een CDC-gebaseerd profiel zoals de Foundation Profile (FP) breidt de CDC uit met extra Java SE klassen, de Personal Basis Profile (PBP) breidt de FP uit met een klein aantal (AWT-afgeleide) user interface klassen en de Personal Profile (PB) breidt de PBP uit met applet ondersteuning en een groter aantal UI klassen.

Optionele pakketten Het laatste deel van de Java ME is dat van de optionele pakketten. Een optionele pakket is een verzameling van API’s ter ondersteuning van extra functies die eigenlijk niet thuishoren in een specifieke configuratie of profiel. Bluetooth-ondersteuning, bijvoorbeeld, wordt gedefinieerd als een optioneel pakket. Ook de Wireless Messaging API (WMA) [89] is een optioneel pakket. Optionele pakketten hebben hun eigen minimumeisen, net als configuraties en profielen. Optionele pakketten kunnen ook afhankelijk zijn van een bepaalde configuratie en/of één of meer profielen. Aangezien een Java-platform een software-platform is dat alleen boven op een native-platform draait, (dit is een combinatie van het besturingssysteem en de onderliggende hardware) kan onderzocht worden welke mobiele besturingssystemen een Java-platform ge¨ıntegreerd hebben of


16

bij welke een JVM eventueel beschikbaar is. [34, 33, 38]

Android Android is een Java-platform. Applicaties kunnen geschreven worden met een relatief groot deel van de Java Standard Edition 5.0 bibliotheek [22] plus een heleboel bibliotheken specifiek geschreven voor het Android platform. Android-applicaties zijn dus niet porteerbaar naar andere Java-platformen. Bovendien maakt Android gebruik van de Dalvik JVM. De Dalvik JVM heeft alleen ondersteuning voor Dalvik uitvoerbare bestanden (.dex-bestanden), een soort van Javabytecode geoptimaliseerd voor het Android platform [23].

Symbian Het Symbian OS [37] heeft een MIDP runtime-omgeving als ge¨ıntegreerd onderdeel van het besturingssysteem. Het geleverde platform is een CLDC 1.1 virtuele machine en een op maat gemaakte MIDP 2.0 uitvoering ontworpen om Java-toepassingen gebruik te laten maken van de voordelen van het onderliggende besturingssysteem, zoals bijvoorbeeld de geavanceerde multitasking.

Windows Mobile Voor Windows Mobile bestaan er tal van Java virtuele machines. De J9 is een JVM van IBM en staat bekend als één van de betere Java VMs. Recent is deze JVM een volledige commercieel product geworden, waardoor een 30-dagen trial niet meer beschikbaar is. De bibliotheken kunnen echter wel nog terug gevonden worden in bijvoorbeeld de SDK van Sprint Titan of in de Java ME plug-in van Eclipse. De CrEme JVM van NSICOM is ook een uitstekende JVM. Ondanks het feit dat CrEme een commercieel product is, kunnen ontwikkelaars gratis gebruik maken van de CrEme JVM [101] en emulator. Er bestaan twee open broen Java virtuele machines voor Windows Mobile: Mysaifu JVM [100] en phoneME [102]. Momenteel zijn Mysaifu en phoneME de enige JVM open bron projecten die nog steeds in ontwikkeling zijn voor Windows Mobile. Tenslotte heeft ook Sun zijn eigen implementatie voor Windows Mobile toestellen, maar deze JVM is enkel voor evaluatie doeleinden wat betekent dat programma’s alleen werken van uit de Java ME Platform SDK.


17

Blackberry Alle BlackBerry-smartphones ondersteunen ten minste een CLDC 1.0 met MIDP 1.0, en smartphones die de BlackBerry Device Software v4.0 of hoger draaien ondersteunen CLDC1.1/MIDP 2.0. [30]

2.3.2

Sprint Titan

Sprint [64] is een wereldwijde Internet-provider (Tier 1 netwerk) en maakt een deel van de Internet-backbone. Daarnaast heeft het bedrijf in de Verenigde Staten, het grootste draadloze breedband netwerk. Naast haar functie als communicatie-provider, biedt Sprint ook een ontwikkel-platform aan. Sprint Titan [63] is een open Java-platform voor Windows Mobile 6 smartphones van Sprint. Naast het ondersteunen van de populaire Java ME MIDP-applicaties, omvat het ook CDCapplicaties, OSGi en eRCP(zie supra 2.3.5). Alle publieke API’s zijn gebaseerd op industrie standaarden. Het biedt dus met andere woorden het “ideale” mobiele Java-platform aan, maar heeft daarnaast ook specifieke Sprint API’s. Slechts een beperkt aantal mobiele toestellen krijgen ondersteuning van Sprint Titan en alleen bij HTC toestellen is de Sprint Titan runtime gratis.

2.3.3

Flash Lite

Flash Lite [39] mag eigenlijk niet worden beschouwd als een mobiel besturingssysteem zoals Windows Mobile. Het is een technologie voor het ontwikkelen van applicaties die draaien op een mobiel besturingssysteem. Flash Lite is de mobiele versie van Flash. Flash Lite is voorzien van een krachtige UI maar het ontbreekt aan een goede integratie in het mobiele toestel. Programmeren in Flash Lite is relatief eenvoudig dankzij de Action Script taal. Een nadeel is vooral het kleine marktaandeel in vergelijking met Java ME. [40]

2.3.4

Web Runtime

Een ander platform om mobiele applicaties te ontwikkelen, is door gebruik te maken van webpagina’s en hun browsers. Webpagina’s worden ondersteund door vrijwel alle moderne mobiele toestellen. Er zijn echter enkele problemen die in acht genomen moeten worden. Men moet bijvoorbeeld rekening houden met het groot aantal browsers en hun verschillen. Sommige mobiele


18

webbrowsers zijn zeer krachtig en bieden ondersteuning voor CSS en JavaScript, anderen zijn minder geavanceerd. Het grootste probleem voor webpagina’s is dat ze alleen online beschikbaar zijn en dat ze geen toegang hebben tot het mobiele toestel zelf. Een voordeel is wel dat ze gemakkelijk ontwikkeld kunnen worden. [41]

2.3.5

eRCP

De eRCP ofwel de embedded Rich Client Platform [42] is de mobiele versie van het krachtige RCP van Eclipse. Het heeft verschillende componenten, met onder andere eSWT, eJFace, eUpdate en een eWorkbench. De Eclipse kern van eRCP bestaat uit een OSGi platform en een Extension Point Framework ondersteuning. De eSWT UI-componenten hebben een sterke integratie met ondersteunde toestellen en hebben bijgevolgd dezelfde look and feel als native applicaties. Dit impliceert echter wel dat het eRCP platform afhankelijk is. Het biedt momenteel ondersteuning aan Windows Mobile 5/6 platformen. De Java ME vereisten voor eRCP zijn net zoals elk ander OSGi platform, het CDC/Foundation profiel. Voor de CLDC is er bijgevolg geen ondersteuning. De Eclipse eSWT is een geavanceerde UI toolkit voor mobiele Java-toepassingen. Het kan als ’stand-alone’ bibliotheek gebruikt worden, wat enkel het CLDC profiel vereist, of als onderdeel in eRCP. eJFace is een verzameling van klassen die eSWT uitbreiden en in staat zijn eRCP toepassingen te integreren met een eRCP workbench. Ze hebben ook ondersteuning voor meer complexe widgets en worden gebaseerd op het MVC patroon. De eWorkbench is een UI framework voor eRCP toepassingen dat het toelaat om meerdere applicaties gelijktijdig te draaien binnen een workbench. Hierdoor biedt het ook ondersteuning voor toestellen met meerdere beeldschermen. De eUpdate component tenslotte biedt de mogelijkheid om plug-ins te updaten vanop een centrale server. De aanwezigheid van deze API is te danken aan het gebruik van de OSGi-functies. Er is ook een UI aanwezig, wat vergelijkbaar is met het standaard updatemechanisme van Eclipse. Een gebruiker surft naar een bepaalde website en selecteert de plug-ins om up te daten. [42]

2.3.6

Ice Faces

Het open bron-Ajax framework, Ice Faces [43], biedt een Ajax-JSF bibliotheek aan. Applicaties worden echter niet ontwikkeld in Javascript, maar in Java. Ice Faces is een server-gecentreerde technologie die gebruik maakt van een puur Java/JSF programmeermodel. De server doet


19

met andere woorden al het zware werk. Dit impliceert dat het verbruik van resources aan de gebruikerszijde minimaal is en niet stijgt met de complexiteit van een toepassing. Er is ook een push compontent aanwezig, met als onderliggende technologie Ajax Push(zie supra 2.4.3). [43]

2.3.7

JavaFX Mobile

JavaFX Mobile is het kleine broertje van JavaFX en is een declaratieve taal boven op Java Swing. De declaratieve syntax leent zich erg goed voor het in elkaar zetten van UI’s, wat ook het doel is van JavaFX Script. JavaFX Script is een gecompileerde taal met statische typering. Het compileert naar Java bytecode. Dit betekent dat het mogelijk is om vanuit JavaFX gewone Java klassen aan te roepen. Omgekeerd is dit ook mogelijk.Applicaties draaien op Java ME. Ontwikkelaars kunnen met behulp van de JavaFX Mobile-emulator hun toepassingen weergeven op het JavaFX Mobile-platform. Momenteel biedt JavaFX Mobile ondersteuning aan Windows Mobile 6 platformen en Android. [44, 45]

2.3.8

AGUI

De Advanced Graphics and User Interface, of AGUI is een optionele bibliotheek voor het Java ME platform. De JSR 209 [46] migreert de kern API’s voor geavanceerde grafische user interfaces van het Java SE-platform naar het Java ME-platform. De AGUI API is afhankelijk van de CDC 1.1, Foundation (Basis) Profile 1.1. Het biedt Swing, 2D Graphics & Imaging en Image I/O componenten aan. [46, 47]

2.3.9

Thinlet

Thinlet is een GUI toolkit. Het ontleedt de hiëarchie en de eigenschappen van de GUI, behandelt gebruikers interactie, en roept business logica op. Het scheidt de grafische presentatie (beschreven in een XML-bestand) en de toepassing methoden (geschreven als Java-code). Gecomprimeerd is Thinlet 39kB groot. Thinlet biedt ondersteuning voor Java 1.1 tot en met 1.4 en het Personal (Basis) Profiel. Swing is daarbij niet vereist. [48]

2.4 Datacommunicatie

2.4

20

Datacommunicatie

In deze sectie worden push technologie en de verschillende implementaties in hedendaagse mobiele technologieën besproken. Vooraleer push wordt ge¨ıntroduceerd, wordt eerst onderzocht waarom we push technieken nodig hebben en wat het verschil is met pull technieken.

2.4.1

Pull-technologie

Bij pull-technologie wordt de aanvraag voor de overdracht van informatie ge¨ınitieerd door een client. Het meeste bekende model voor deze technologie, is het HTTP-model. HTTP bestaat uit een strikt request-response model waarbij de client een request maakt aan de server. De server antwoordt met de gevraagde data. Het is met HTTP dus onmogelijk om een server een bericht te laten sturen naar een client. De vraag die zich stelt is hoe een web-chatapplicatie dan bijvoorbeeld het nieuwe chatbericht, dat op de server beschikbaar is, bekomt? Hierbij wordt gebruikt gemaakt van een techniek genaamd polling. Bij polling wordt om de x-aantal milliseconden een nieuwe request verzonden. De server antwoordt met ofwel ’geen nieuw chatbericht’, ofwel de inhoud van het nieuwe chatbericht. De chatapplicatie zal vervolgens na x-aantal milliseconden opnieuw dezelfde request versturen. Het polling systeem heeft volgende nadelen: • Inefficiënt Als de webapplicatie de server bijvoorbeeld elke seconde pollt om te controleren of er een nieuw chatbericht is en er is gemiddeld één nieuw chat bericht elke 30 seconden, zullen 29 van de 30 berichten ’geen nieuw chatbericht’ bevatten. Voor 1 bericht zullen de server en client dus verschillende onnodige HTTP berichten verzonden hebben. Dit is heel inefficiënt gebruik van bandbreedte, zeker bij gebruik in een mobiele omgeving. • Traag Gaat men uit van de hypothese dat een derde persoon zelf een bericht stuurt naar de server, meteen nadat een client ’geen nieuw chatbericht’ ontvangen heeft van de server, dan zal deze voor tenminste 1 seconde dit bericht niet zien. Dit is de tijd waarna de client opnieuw een request naar de server verstuurt. Efficiënter gaan pollen door minder te pollen betekent dus automatisch dat het ontvangen van nieuwe gebeurtenissen meer wordt vertraagd.


21

• Batterijverbruik Wanneer polling wordt toegepast bij mobiele toestellen heeft dit negatieve gevolgen voor het batterijverbruik. Doordat de client vrijwel constant actief online moet zijn om te kunnen pollen, zal de levensduur van de batterij drastisch worden verminderd. [11]

2.4.2

Push-technologie

Bij push-technologie wordt het verzoek voor een bepaalde transactie ge¨ınitieerd door een centrale server. Dit staat in contrast met pull-technologie, waarbij de aanvraag voor de overdracht van informatie ge¨ınitieerd wordt door een client. Beurstickers en chatprogramma’s zijn typische voorbeelden waarbij gebruik kan gemaakt worden van push-technologie. Berichten worden ’geduwd’ naar de gebruiker zodra zij worden ontvangen op de centrale server. Het architecturale publish/subscribe-model maakt in het bijzonder gebruik van push-technologie. Een client zal zich eerst abonneren op verschillende informatie-kanalen. Wanneer vervolgens nieuwe informatie beschikbaar is op één van de kanalen, dan zal de server deze informatie pushen naar de client. Er bestaan verschillende implementaties en protocollen die push-technologie al dan niet simuleren. Deze technologieën worden hieronder besproken. [72, 73]

2.4.3

HTTP Server push

Met een creatieve implementatie is het wel mogelijk om een HTTP-bericht van de server naar de client te sturen, in opdracht van de server. Dit wordt HTTP Server push genoemd. Server Push is een meer geavanceerde en efficiëntere vervanging voor de polling techniek. Het zorgt voor een lagere latentie, zodat men niet afhankelijk is van de polling frequentie en de server en het netwerk moeten niet omgaan met regelmatige polling requests die naar updates vragen. Veronderstel opnieuw het voorbeeld van de web chatapplicatie. De client maakt een request naar de server met de vraag of een nieuw bericht beschikbaar is. In plaats dat de server het bericht ’geen nieuw chatbericht’ terugstuurt, zal de server initieel niet antwoorden. Het doet zich voor als een heel trage server (Long Poll, zie figuur 2.4). Wanneer een nieuw bericht beschikbaar is, zal de server terug ’wakker’ worden en antwoorden met het nieuwe bericht. De client hoeft op deze manier niet om de zoveel tijd een request te versturen en is er geen vertraging aanwezig door het poll-interval.


22

Jammergenoeg zijn HTTP en de meeste webservers hiervoor niet ontworpen en heeft het bijgevolg enkele architecturale uitdagingen: • Een connectie refresh is nodig Omdat eventuele proxies, de webclient of soms zelfs de webserver zelf het verschil niet kunnen zien tussen een trage code of een code die alleen maar wacht op een gebeurtenis, zullen ze op een bepaald moment aannemen dat er iets is foutgelopen. Er wordt dan een error opgesmeten (gevolg van een HTTP Timeout). Dit betekent dat een push-verbinding slechts een beperkte levensduur heeft. Op een gegeven moment, na 50 seconden bijvoorbeeld, zal de server ’geen nieuw bericht’ moeten terugsturen. Er is dus met andere woorden een ’connectie refresh’ nodig. • Geen ’flush’ Stel dat iemand in plaats van telkens het nieuwe bericht op te vragen, een live stream vraagt (Streaming, zie figuur 2.4). Antwoorden worden dan gepushed over de HTTP connectie waarbij de connectie eigenlijk nooit wordt gesloten. Het HTTP protocol heeft echter geen flush en garandeert bijgevolg niet dat verzonden bytes effectief meteen worden verstuurd naar de client. Iemand achter een caching proxy zal hoogstwaarschijnlijk de berichten ontvangen in bursts, in plaats van bericht per bericht. • Thread pool aanwezig Om een antwoord te ’pauzeren’, wordt meestal een thread gepauzeerd. De meeste web servers hebben een beperkt aantal threads tot hun beschikking (Thread pool). Nieuwe request zullen dan worden genegeerd omdat de server denkt dat hij druk bezig is. Een mogelijke oplossing is om de gepauzeerde threads lokaal op te slaan. Dit wordt in de literatuur Asynchronous Request Processing [77] genoemd. Elke geblokkeerde thread consumeert echter ook geheugen. Dit verlaagt de schaalbaarheid en kan een negatief effect hebben op de performantie. Zoals eerder vermeld is een creatieve implementatie vereist om HTTP server push te realiseren. Bijgevolg bestaan er verschillende implementatie varianten. Men kan gebruik maken van het eerder vermelde niet-sluiten-van-de-connectie. Dit principe wordt onder andere gebruikt bij Pushlets [74]. Bij een volgende implementatie wordt gebruik gemaakt van de multipart/mixed MIME header [75] of de nieuwe HTML 5 standaard: server-send events [76]. Een laatste mogelijkheid is door gebruik te maken van de ’HTTP conditional GET’. Dit laat de server toe om


23

alleen informatie terug te sturen wanneer de databron is ge¨ update sinds de laatste vraag. Deze techniek reduceert het aantal datatrafiek in het netwerk, maar reduceert niet de frequentie van de polling operatie. [72, 73, 1]

2.4.4

Comet en Bayeux

Comet is eigenlijk een verzamelnaam voor verschillende technieken om push te simuleren. Het is een combinatie van Server push samen met een Ajax web-applicatie. Comet wordt ook wel eens Ajax push of Reverse Ajax genoemd. Figuur 2.4 toont het verschil tussen de twee Server Push technieken en het gewone polling in een Ajax omgeving. Streaming

Long poll

Polling

request

request

request response event

response

event

response

event

request request

response

event

response

Figuur 2.4: Pollling en Server Push in een Ajax (browser) omgeving Bayeux [78] is een protocol voor het transporteren van asynchrone berichten, met lage latentie tussen typisch een webserver en een webclient. Het merendeel van de Bayeux implementaties zijn ontwikkeld voor HTTP en maken veelvuldig gebruik van de Server Push technieken. Het Bayeux protocol kan echter ook gebruikt worden voor andere transport-protocollen. De berichten (JSON-objecten [81]) worden omgeleid langs kanalen en kunnen worden afgeleverd door een server naar client, client naar server of een client naar client(via de server) connectie. Standaard wordt het publish/subscribe model gebruikt voor de kanalen, maar andere routeringsmodellen kunnen ook gebruikt worden. Cometd [79] tenslotte, is een project om meerdere implementaties van het Bayeux project te voorzien in verschillende programmeertalen (Javascript, Java [80], Python). Zowel client als


24

server implementaties zijn ter beschikking. De server implementaties houden rekening met de architecturale uitdagingen die Server Push met zich meebrengen(zie infra 2.4.3).

2.4.5

SMS en WAP Push

Om een bericht te laten pushen naar een client, kan ook gebruik gemaakt worden van SMS (Short Message Service). SMS is één van de meest beschikbare en populaire diensten voor mobiele telefoon gebruikers. Het kan gebruikt worden voor het verzenden van tekst- of binaire berichten. Een mobiel toestel met SMS ondersteuning is altijd aan het luisteren voor nieuwe SMS berichten. Er is dus geen extra netwerkconnectie nodig. SMS werkt typisch over GSM of CDMA netwerken. Hierdoor moet telkens wel een klein bedrag betaald worden om een SMS te versturen. De Java ME Wireless Messaging API(WMA) [89] standaardiseert SMS API’s voor alle Java ME platformen. [1] WAP staat voor Wireless Access Protocol, een vereenvoudigde versie van het HTTP-protocol. Hiermee is het mogelijk aan mobiele toestellen een beperkte internet-toegang te verschaffen. Sinds versie 2.1 is er ook WAP Push. Een Push Proxy Gateway (PPG) is een onderdeel van WAP-Push dat tyisch een URL notificatie ’duwt’ naar mobiele toestellen. De PPG heeft twee mogelijkheden voor aflevering van de notificatie. Als het IP-adres van het mobiele toestel bekend is, dan gebruikt de PPG een ’Connection Oriented Push’. Zoniet, dan zal de PPG de notificatie afleveren via SMS (’Connectionless Push’). [82, 83]

2.4.6

XMPP en SIP

XMPP en SIP zijn hoofdzakelijk twee TCP/IP transport protocollen. Hoewel ze niet direct in het rijtje passen van push technologieën, kunnen en worden ze vaak gebruikt in een publish/subscribe omgeving.

XMPP XMPP [85] staat voor Extensible Messaging and Presence Protocol. De ontwikkeling is reeds in 1998 aangevangen en is sinds 2004 goedgekeurd door IETF. Het open XMPP-protocol is oorspronkelijk ontwikkeld voor instant messaging, maar heeft tegenwoordig tal van extensies (Publish/Subscribe functionalitiet [95]). Jabber [84] is het meest populaire open bron IM-dienst


25

met als onderliggende protocol XMPP. Het wordt onder andere gebruikt in Google Wave [86], dat een extensie is van het XMPP protocol. Ook de Apple Push Notification Service maakt gebruikt van XMPP [94]. Het protocol maakt gebruik van XML-streams via TCP/IP-sockets. De XML wordt verzonden als een open stream. Een stream begint met de tag ’stream’, waarna er eventueel een reeks van bericht-elementen of ’info-query’-elementen volgen. Bij de afsluitende stream tag, wordt de onderliggende TCP-verbinding afgebroken. Tegenstanders [88] vinden dat XMPP te breedsprakig en inefficiënt is voor een mobiele netwerkverbinding. [87, 1]

SIP Het Session Initiation Protocol [90] is een protocol dat wordt gebruikt voor het beheer van multimediale communicatie-sessies op netwerken die gebruik maken van het Internet Protocol (IP). SIP is een Internet-standaard, afgeleid van HTTP, waar IETF een asynchrone gedrag heeft aan toegevoegd. Populaire voorbeelden van toepassingen zijn SIP: VoIP-telefonie, video conferencing, chatten en aanwezigheidsdetectie. De SIP API voor Java Me [91] definieert een optioneel pakket dat een algemene SIP API voor Jave ME klanten aanbiedt, zodat SIP toepassingen mogelijk zijn op toestellen met een beperkt geheugen. De API is compact en generiek zodat het kan gebruikt worden met elk Java ME profiel. Het vereist de minimum versie 1.0 van de CLDC, maar de API’s kunnen ook gebruikt worden met de CDC. [92, 1]

2.4.7

MIDP Push

De MIDP Push Registry is ge¨ıntroduceerd met MIDP 2.0 [71]. Het push register maakt het mogelijk voor Midlets om zichzelf automatisch te starten, zonder enige gebruikersinteractie. Het push register is namelijk verantwoordelijk voor netwerk of tijds-ge¨ınitieerde Midlet activatie. Een inkomende netwerk connectie of een alarm op een bepaald tijdstip, kan een Midlet activeren. Het push register is een deel van het applicatie management systeem (AMS), dit is een component van het Java CLDC ME platform dat verantwoordelijk is voor de life-cycle van elke applicatie (installatie, activatie, uitvoering en verwijdering). Het push register is een component van de AMS dat de push API ter beschikking stelt en alle push registraties beheert.


26

Het push register heeft twee mogelijke registraties: dynamisch of statisch. De statische registratie gebeurt bij de installatie en is gedefinieerd door bepaalde entries in de JAD file. De dynamische registratie gebeurt ’at runtime’ door de methode ’registerConnection()’ op te roepen. Opdat een midlet push berichten zou kunnen ontvangen, moet het een adres hebben dat gekend is bij verzenders die push berichten mogen versturen. Voor het ontvangen van SMS berichten is het push adres het telefoonnummer plus een poort (Wireless Messaging API [89]). Voor een socket en datagram connectie is dit een IP adres. Als het IP adres statisch is dan het is gemakkelijk voor iemand om berichten te pushen naar het toestel. Wanneer het IP adres echter dynamisch is, is het de verantwoordelijkheid van de Midlet om het adres te publiceren. [93, 1] Het gedrag van het push register kan beschreven worden in drie stappen: 1. De MIDlet registreert een poort samen met de protocolnaam bij het mobiel platform. Wanneer berichten vervolgens arriveren op deze poort met het gegeven protocol, zal de AMS dit bericht afleveren aan de MIDlet. 2. Vanuit de server wordt een bericht verzonden naar het mobiele toestel gebruik makend van het protocol en poort waar de MIDlet applicatie naar toe luistert. 3. Nadat het bericht is afgeleverd aan het mobiele platform, zal de AMS de MIDlet applicatie oproepen. Eenmaal het bericht is afgeleverd aan de MIDlet, is de applicatie zelf verder verantwoordelijk voor het verder verwerken van dit bericht.

Direct Push Direct Push van Microsoft is een functie die is ingebouwd in de Exchange Server 2007. Een mobiel toestel wordt op de hoogte gebracht wanneer er nieuwe data beschikbaar is om te worden gesynchroniseerd. Mobiele toestellen met ondersteuning voor Direct Push (vanaf Windows Mobile 5.0) openen een langlevende HTTPS request met de Exchange-server. Direct Push maakt gebruik van HTTPS en KEEP-ALIVE. Er dus nood aan het periodisch blijven pollen naar de server om de connectie ’levende’ te houden. [96]

Blackberry Push Een Blackberry is een PDA met telefoonfunctie, een Smartphone. De BlackBerry kwam in 1999 voor het eerst op de markt. Het is ontwikkeld door het Canadees bedrijf, Research in

2.5 Technologie keuze

27

Motion (RIM). Blackberry biedt ondersteuning voor push e-mail, internet browsing, en mobiele telefonie. BlackBerry Push minimaliseert de impact op de levensduur van de batterij. In plaats van actief te controleren op nieuwe gegevens zoals Direct Push, wacht het in de achtergrond voor de server om gegevens te duwen. BlackBerry steunt op een NOC (Network Operating Center)-gebaseerde architectuur. Er zijn wereldwijd maar een aantal geografisch verspreide NOC gelegen, elk ten behoeve van verschillende gebieden. Alle push mail datapakketten gaan via het NOC-and-forward mechanisme naar de mobiele toestellen. Het draadloze netwerk (GPRS) dat gebruikt wordt, komt van de reguliere mobiele telefonie-providers. Sinds kort kunnen ook software ontwikkelaars gebruik maken van de Blackberry Push API’s. De API’s bouwen voort op de gevestigde PAP WAP 2.2-standaard, die gebruik maakt van XML om de push parameters te definiëren voor de BlackBerry infrastructuur. Applicaties voor de Blackberry worden ontwikkeld in Java (CLDC/MIDP). [97, 98, 99]

2.5

Technologie keuze

Uit de resultaten van het state-of-the-art onderzoek (zie figuur 2.5) kan een gegronde technologie keuze gemaakt worden. Zoals in de inleiding beschreven, wordt er gezocht naar een mobiele oplossing voor het pushen van data waarbij er rekening wordt gehouden met het batterij-verbruik en de eenvoudig van onderhoud. In het kader van deze academisch masterproef wordt er echter ook gezocht naar een open mobiel platform waarbij applicaties porteerbaar zijn naar verschillende mobiele toestellen. Na onderzoek komt Java ME als enige kandidaat uit de bus. Een Java-implementatie is volledig onafhankelijk van het onderliggende platform. Uit hoofdstuk 2.1 kan men besluiten dat Windows Mobile het enige platform is waar een volledige controle over netwerk-interfaces en batterij-functies aanwezig is. Dit impliceert dat een optimaal onderzoek kan plaats vinden naar de performantie van mobiele push systemen. Het gebruik van OSGi als technologische keuze voor een modulair Java systeem dat gemakkelijk te onderhouden is, heeft als gevolg dat er minimum een Java ME CDC v1.0 plus FP v1.0 gebruikt moet worden. De keuze van een OSGi platform is quasi arbitrair. Equinox heeft het voordeel dat het ge¨ıntegreed is in eRCP, maar Apache Felix heeft op zijn beurt ook enkele kleine voordelen in vergelijking met de andere open bron implementaties. Aangezien Apache Felix een vrij compacte uitvoering is en iets strenger is in zijn interpretatie van de OSGi specificatie, wordt gekozen voor


28

Datacommunicatie

Pull

HTTP Server Push

Push

Hybrid

Ontwikkelomgeving Felix Java ME

Ice Faces

Flash Lite

eRCP Equinox

Web Runtime

JavaFX Mobile

Sprint Titan

OSGi Knoplerfish Conciërge

Besturingssysteem

Android

Symbian

Blackberry

iPhone

Windows Mobile

Figuur 2.5: Resultaten state-of-the-art onderzoek dit OSGi platform. Door het feit dat eSWT applicaties van eRCP een sterke integratie hebben met hun toestellen en dus dezelfde look and feel hebben als native applicaties, zijn ze moeilijker porteerbaar. De componenten die eRCP aanbiedt, wegen niet op tegen de extra bundels die Apache Felix aanbiedt. Er kan beter gekozen worden voor een lightweight GUI zoals bijvoorbeeld AGUI of Mobile Thinlet. Voor de datacommunicatie tussen de partijen kan gekozen worden voor drie mogelijke implementaties. Bij een eerste implementatie wordt gebruik gemaakt van HTTP Server Push. Dit kan gezien worden als referentiemodel voor push systemen. Het is een geoptimaliseerde manier van polling, maar het heeft nog steeds een negatief effect op de levensduur van de batterij en heeft bovendien verschillende architecturale uitdagingen(zie infra 2.4.3). Een tweede implementatie maakt gebruik van echte push. De server neemt het initiatief om data te verzenden naar geregistreerde cliënts. Een groot probleem hierbij is de schaalbaarheid: de cliënts sequentieel contacteren schaalt zelfs niet goed voor een gemiddeld aantal gebruikers [4]. Dit zorgt ervoor


29

dat verschillende cliënts een andere kijk hebben op het geregistreerde kanaal, in volgorde van hun positie in het push proces. Het schaalbaarheidsprobleem kan opgelost worden door gebruik te maken van een hybride oplossing. Een combinatie van de voordelen van server push (data stiptheid, consistentie) en client pull (schaalbaarheid). De client zal de eigenlijke data pullen (mogelijks groot bericht), nadat hij via het push mechanisme op de hoogte werd gebracht van de beschikbaarheid van nieuwe data (een klein bericht, een notificatie). Dit laatste kan ge¨ımplemnteerd worden door ofwel gebruik te maken van een SMS ofwel een notificatie over Wi-Fi (’wake-up call’). De drie mogelijke implementaties zijn dus HTTP Server Push, een SMS gevolgd door een pull van de client of een notificatie over Wifi gevolgd door een pull van de client.

SPECIFICATIE

30

Hoofdstuk 3

Specificatie Vooraleer een architectuur kan worden opgesteld voor de te ontwikkelen mobiele applicatie, moet er een analyse gemaakt worden van de nodige en vereiste functionaliteit. In dit hoofdstuk wordt na het beschrijven van de use case, de key features, quality attribute requirements en de main succes scenarios uitgewerkt. De zogenaamde black box werking. Deze beschrijven de minimum interacties met de mobiele applicatie die een gebruiker (arts) kan ondernemen.

3.1

Use Case

’Een dag uit het leven van...’ Een arts komt aan op intensieve zorgen van het universitair ziekenhuis Gent om te beginnen met zijn werkshift. Hij neemt zijn PDA uit de oplader en selecteert het programma Mobile ICSP. Onmiddelijk merkt de arts dat er enkele updates zijn doorgevoerd. Na het lezen van eventuele nieuwe functies gaat hij naar het tabblad ’werkshift’. Hij vult zijn identificatie gegevens in en drukt vervolgens op ’Start werkshift’. Na tien minuten in zijn ronde krijgt hij een notificiatie van Mobile ICSP dat er een nieuwe update is van de ABDose service met betrekking tot patiënt x. De arts vraagt aan Mobile ICSP meer informatie over deze melding. Hij controleert de gegevens en besluit akkoord te gaan. Daarna vervolgt de arts zijn ronde. Kort daarna komt een nieuwe patiënt toe op intensieve zorgen. Na een eerste checkup beslist de arts dat hij ook op hoogte wil gehouden worden van de antibiotica dosis (ABDose) van de patiënt. In Mobile ICSP gaat hij naar het tabblad ’registraties’ en registreert hij de nieuwe

3.2 Key Features

31

patiënt bij de ABDose Service. Een tweede update van de ABDose service doet zich voor. Deze keer voor patiënt y. De arts controleert de gegevens en beslist niet akkoord te gaan met deze melding. Hij duidt de gewenste actie aan drukt vervolgens op ’niet akkoord’. Wanneer de werkshift van de arts is afgelopen, selecteert hij het tabblad ’werkshift’ in Mobile ICSP en drukt vervolgens op de knop ’Stop werkshift’. Voordat de arts naar huis gaat, plaats hij zijn PDA nog in de oplader.

3.2

Key Features

Hieronder volgt een opsomming van de hoofdkenmerken van de mobiele applicatie afgeleid uit de use case. • Een arts moet zich kunnen (un)subscriben bij bepaalde services aan de hand van een eenvoudige GUI. • Een arts kan het platform op de hoogte brengen van het starten of stoppen van zijn werkshift. • Nieuwe notificaties worden, zonder enig initiatief van de gebruiker zelf, gepushed naar de arts. • Zonder initiatief van de arts, kan de mobiele applicatie dynamisch worden ge¨ updatet. • Een bericht dat niet kan worden bezorgd aan de desbetreffende arts moet op een gepaste manier behandeld worden. • De arts heeft de mogelijkheid om feedback te geven.

3.3 3.3.1

Quality attributes requirements Usability

Gebruikers moeten via een eenvoudige en gebruikersvriendelijke grafische user interface kunnen interageren met de mobiele applicatie.

3.3 Quality attributes requirements

3.3.2

32

Modifiability

De mobiele applicatie moet op een eenvoudige manier dynamisch kunnen worden aangepast. Dit in de context van de applicatie up te daten en bugs te verhelpen, maar ook de mogelijkheid om nieuwe functies toe te voegen.

3.3.3

Performance

De mobiele applicatie moet goed presteren qua batterijverbruik van het mobiele toestel. Dit impliceert dat er een efficiënte overdracht voor berichten nodig is. Mobiele toestellen zijn beperkt in hun middelen. Dus moet het ook goed presteren qua CPU- en geheugen-gebruik.

3.3.4

Adaptability

Wanneer de batterijstatus van een mobiel toestel laag is, moet er kunnen worden overgeschakeld naar een minder batterij intensieve overdracht van berichten.

3.3.5

Besluit

De meest belangrijke quality attributes zijn usability en modifiability. Usability, omdat een arts geen tijd kan en mag verspillen door te leren interageren met de mobiele applicatie. Een ingewikkelde grafische user interface kan te vermijden fouten introduceren in het diagnoseproces van de arts en zal bij ingebruikname meer een trial-and-error interactie hebben. Deze gevolgen zijn onaanvaardbaar in een medische omgeving. De grafische user interface moet dus zo natuurlijk mogelijk aanvoelen. Modifiability, omdat de mobiele applicatie gemakkelijk moet kunnen worden aangepast aan de noden van de arts. Bovendien zorgt een eenvoudig dynamisch update systeem ervoor dat elke arts met de laatste versie van de applicatie werkt. Hierdoor is de verspreiding van verschillende versies van de applicatie minder groot en zullen de fouten die hiervan het gevolg zijn praktisch tot nul worden gereduceerd.

3.4 Main Success Scenarios

3.4

33

Main Success Scenarios

De vijf main success scenarios die worden uitgewerkt, beschrijven de minimum interacties die een gebruiker (arts) met de mobiele applicatie kan ondernemen. De eerste twee scenarios beschrijven hoe een arts zich kan registreren voor of deregistreren van het ontvangen van notificaties. Het derde scenario beschrijft hoe een arts zijn werkshift kan starten en stoppen, wat het ontvangen en respectievelijk niet meer ontvangen van notificaties tot gevolg heeft. Het laatste scenario beschrijft de acties die ondernomen worden wanneer een nieuwe notificatie zich voordoet.

3.4.1

Registreren voor het ontvangen van notificaties

Actor

Arts

Preconditie

De mobiele applicatie is opgestart en bevat het tabblad ’registraties’.

Beschrijving 1. De arts gaat naar het tabblad ’registraties’. 2. Hij maakt een keuze uit de lijst van beschikbare medische services. 3. Eventuele parameters worden ingevuld (bijvoorbeeld: naam of dossiernummer van een patiënt). 4. De arts klikt vervolgens op ’registreer’. 5. De arts krijgt bevestiging dat hij geregistreerd is en de registratie verschijnt in de lijst van registraties. 6. Eventuele nodige updates worden ge¨ınstalleerd (zie de use case ’ontvangen van notificaties’). Postconditie

Arts is geregistreerd bij een bepaalde service voor het ontvangen van de gewenste notificaties.

Extensies

1 a. De arts klikt op het tabblad ’registraties’ en drukt op de knop ’editeer’. 1 b. Ga verder naar 3.


3.4.2

34

Deregistreren van het ontvangen van notificaties

Actor

Arts

Preconditie

De mobiele applicatie is opgestart en bevat het tabblad ’registraties’.

Beschrijving 1. De arts gaat naar het tabblad ’registraties’. 2. Hij maakt een keuze uit de lijst van geregistreerde notificatie services. 3. De arts klikt op ’deregistreer’. 4. De arts krijgt bevestiging dat hij niet meer geregistreerd is bij de service met eerder opgegeven parameters en de registratie verdwijnt uit de lijst van registraties. Postconditie

3.4.3

Arts ontvangt geen notificaties meer van een bepaalde service.

Starten/stoppen van een werkshift

Actor

Arts

Preconditie

De mobiele applicatie is opgestart en bevat het tabblad ’werkshift’.

Beschrijving 1. De arts gaat naar het tabblad ’werkshift’. 2. Hij klikt vervolgens op de knop ’start werkshift’. 3. De arts krijgt een bevestiging dat zijn werktshift is gestart. 4. De tabblad-bar bovenaan wordt groen en postconditie 1 geldt. Postconditie 1

De arts kan vanaf nu mogelijks notificaties ontvangen.

Postconditie 2

De arts zal vanaf nu geen notificaties ontvangen meer ontvangen.

Extensies

2 a. De arts klikt op de knop ’stop werkshift’. 2 b. De arts krijgt bevestiging dat zijn werkshift erop zit. 2 c. De tabblad-bar bovenaan wordt grijs en postconditie 2 geldt.


3.4.4

35

Het ontvangen van notificaties en de mogelijkheid tot feedback

Actor

Arts

Preconditie

De mobiele applicatie is opgestart en de werkshift van de arts is gestart.

Beschrijving 1. De arts ontvangt een notificatie van een service. 2. De applicatie toont een notificatie pop-up en laat het ’nieuwe-notificatie’ geluid afspelen. 3. De arts klikt op ’Lees meer’ in de notificatie pop-up om meer informatie te ontvangen. 4. Hij controleert de gegevens en beslist akkoord te gaan door te klikken op ’akkoord’. Postconditie

De arts heeft de nieuwe notificatie ontvangen en gelezen.

Extensies

1 a. De arts ontvangt een update-notificatie. 1 b. De update wordt doorgevoerd en de mobiele applicatie wordt aangepast. 4 a. De arts controleert de gegevens en gaat niet akkoord. 4 b. Hij maakt een keuze uit de mogelijke acties en drukt vervolgens op ’niet akkoord’.

ARCHITECTUUR

36

Hoofdstuk 4

Architectuur In dit hoofdstuk wordt de architectuur van het systeem voorgesteld dat beschreven werd in het vorige hoofdstuk. Bij de uitwerking van de architectuur wordt gebruik gemaakt van een top-down benadering. Vooreerst wordt het volledige systeem gespecificeerd, waarna de subsystemen en modules volgen. Vervolgens wordt de interactie tussen de componenten uitgewerkt in verschillende scenario’s. In de laatste sectie van dit hoofdstuk wordt het deploymentdiagram besproken.

4.1 4.1.1

Component View Algemeen systeem: ICSP Mobile

De algemene architectuur van het systeem is een Publish/Subscribe architectuur. In figuur 4.1 is deze architectuur uitgewerkt in een UML componentendiagram. Uit de figuur zijn duidelijk drie actoren te onderscheiden die met het systeem communiceren. Er zijn twee leveranciers die informatie aanbrengen of publiceren aan de Pub/Sub Broker en er is een arts die interageert met de Mobile Receiver (PDA). De Pub/Sub Broker is de centrale component binnen het systeem. Medische services kunnen na registratie hun nieuwe updates aanbrengen, terwijl bundel ontwikkelaars updates van bundels of nieuwe bundels voor de mobiele ontvanger kunnen aanbrengen. Dit laatste wordt mogelijk gemaakt, dankzij het gebruik van OSGi. De derde interface van de Pub/Sub Broker is de interface die gebruikt wordt door de Mobile Receiver. Een mobiele ontvanger kan zich registreren (subscribe) voor het ontvangen van nieuwe informatie. Wanneer

4.1 Component View

37

Figuur 4.1: Main system: ICSP Mobile de Pub/Sub Broker nieuwe data ontvangt worden de desbetreffende mobiele ontvanger(s) op de hoogte gebracht (notify). In de volgende twee secties wordt dieper ingegaan op de twee subsystemen: de Pub/Sub Broker en de Mobile Receiver.

4.1.2

Subsysteem: Pub/Sub Broker

De Pub/Sub Broker implementeert drie interfaces. De Developers Interface, de Medical Services Interface en de Broker Interface (zie figuur 4.2 ). Bundel ontwikkelaars hebben de mogelijkheid om met de Pub/Sub Broker te interageren via de Developers Interface om op die manier bepaalde bundels (bedoeld voor de mobiele ontvanger) te verwijderen, up te daten of nieuw aan te brengen. Zij kunnen overweg met een eenvoudige webinterface. De tweede extern beschikbare interface van de Pub/Sub Broker is de Medical Services Interface. Deze interface wordt gebruikt door de Medische services die nieuwe informatie willen publice-

4.1 Component View

38

Figuur 4.2: Subsystem: Pub/Sub Broker, Interfaces ren. Zij zullen typisch interageren met de broker via het SOAP communicatieprotocol. Vooraleer medische services nieuwe informatie kunnen versturen naar de Pub/Sub Broker, moeten ze zich registreren (registerService). Opdat een medische service zich zou kunnen registeren, wordt een naam, een bundel ( byte[] ) en optioneel een callback URL vereist. De bundel, die verantwoordelijk is om de gepubliceerde data van de bijhorende medische service op een correcte wijze voor te stellen, zal doorgestuurd worden naar de Mobile Receiver wanneer een arts zich abonneert bij die service. Na registratie verkrijgt de medische service bovendien een sleutel (key). Deze key moet gebruikt worden bij elke volgende communicatie met de Pub/Sub Broker, om zo de authenticiteit van het bericht te kunnen controleren. Uiteraard is het ook mogelijk om een medische service te deregistreren of up te daten. De ’postUpdateData’ functie van de Medical Services Interface wordt na registratie door de medische services aangeroepen om nieuwe informatie die beschikbaar is door te sturen naar de Pub/Sub Broker. Deze nieuwe informatie zit vervat in een ServiceUpdateData object (zie figuur 4.2). Naast enkele verplichte velden, kan de effectieve data (byte[]) vrij worden ingevuld door de medische service. Het ’timeToLive’ veld duidt de geldigheidsduur aan van het bericht.

4.1 Component View

39

Een laatste extern beschikbare interface die wordt ge¨ımplementeerd door de Pub/Sub Broker is de Broker Interface. Het zijn de mobiele ontvangers die zullen communiceren met deze interface met behulp van het REST communicatieprotocol. Wanneer alle bundels van de Mobile Receiver ingeladen zijn na het opstarten van het programma, wordt de ’initialize’ functie opgeroepen van de Pub/Sub Broker. Op die manier is het mogelijk om de mobiele ontvanger op een unieke manier te herkennen en bovendien de huidige bundel lijst door te sturen. Nadat de Pub/Sub Broker deze lijst heeft geanalyseerd, is het mogelijk dat er verschillende BundleEvents (zie supra) teruggezonden worden (synchronisatie van de mobiele ontvanger).

Figuur 4.3: Subsystem: Pub/Sub Broker, Components Wanneer de Pub/Sub Broker intern wordt geanalyseerd zijn er verschillende componenten vereist (zie figuur 4.3]) die elk hun verantwoordelijkheden hebben om een goede werking van het systeem te garanderen: • DataStore Component

4.1 Component View

40

– Het opslaan van alle geregistreerde medische services, samen met hun keys en hun bundels voor de mobiele ontvanger. – Per mobiele ontvanger is er een lijst van subscripties en het feit of de werkshift van de bijhorende arts al dan niet gestart is. – Het opslaan van de andere bundels (niet gerelateerd aan de medische services) voor de mobiele ontvanger. • Medical Services Component – Zorgt voor een SOAP interface die de medische services kunnen aanspreken om zich te registreren en om medische updates te kunnen aanbrengen. – Implementatie van de Medical Services Interface. • Internal Services Component – Zorgt voor het verwerken van de inkomende berichten van niet medische services die beschikbaar zijn op de mobiele ontvanger. Het gaat hier om bijvoorbeeld de Workshift Service en de Subscription Service. • Developers Component – Publiceert een webinterface waarop ontwikkelaars van bundels voor de mobiele ontvanger, bundels kunnen toevoegen, verwijderen of updaten. – Implementatie van de Developers Interface. • Mobile Communications Component – Is verantwoordelijk voor het aanspreken van de verschillende mobiele ontvangers. – Zorgt ervoor dat het bericht de mobiele ontvanger bereikt en heeft daarvoor verschillende communicatiemogelijkheden ter beschikking. • Brokering Component – Ontvangt de berichten van de mobiele ontvanger, analyseert en verwerkt ze en communiceert daarbij met de Internal en Medical Services Component en de Mobile Communications Component. – Implementatie van de Broker Interface.

4.1 Component View

41

Naast de communicatie naar de DataStore en Mobile Communications Component toe, communiceren de componenten onderling met behulp van een event gebaseerd systeem (Zie figuur 4.4).

Figuur 4.4: Subsystem: Pub/Sub Broker, EventAdmin

DataStore module In de DataStore worden vier entiteiten opgeslaan: Bundle, Subscription, Service en User (zie figuur 4.5). Deze worden gebruikt in de vier fa¸cades die vanuit de DataStore aangereikt worden (zie figuur 4.6). De functionaliteit en verschillende methodes die elke fa¸cade aanbiedt spreken voor zich.

Medical and Internal Services Module Elke service, of het nu een medische service of een interne service is, zal worden aangemaakt als extensie van de abstracte klasse AbstractServerService (zie figuur 4.7). De ServicesManager is een Singleton en is bovendien de centrale component. Deze registreert de aanwezige ServerServices en zendt de inkomende callback methodes door naar de juiste ServerService. De constructor van de AbstractServerService vereist een bepaalde service-naam, het is mogelijk dat bij constructie een NameNotUniqueException wordt opgesmeten. Daarnaast bevat het enkele abstracte methodes en enkele finale methodes. Er wordt een implementatie verwacht voor registerForCallback, registerForInternalCallback en voor registerForSystemEvents. Deze metho-

4.1 Component View

Figuur 4.5: Subsystem: Pub/Sub Broker, Module Datastore: entities

Figuur 4.6: Subsystem: Pub/Sub Broker, Module Datastore: fa¸cades

42

4.1 Component View

Figuur 4.7: Subsystem: Pub/Sub Broker, Medical and Internal Services Module

43

4.1 Component View

44

des duiden aan of de service al dan niet (interne) callbacks verwacht en voor welke systeem-events hij zich wil registreren. De twee finale methodes sentToAll en sendToPerson verzenden een MobileEvent respectievelijk naar elke arts of specifiek naar een bepaalde persoon. Uiteraard wordt bij het verzenden ervan rekening gehouden met het feit of het MobileEvent een DataEvent of een BundleEvent is. Een medisch DataEvent mag immers enkel verstuurd worden wanneer de arts zich hiervoor heeft geregistreerd en als de werkshift van de arts gestart is. De MedicalServiceListener uit 4.7 zal luisteren of er nieuwe medische services aangebracht of bestaande verwijderd worden. Wanneer een nieuwe medische service wordt geregistreerd zal een nieuwe MedicalService aangemaakt worden. Dit is een extensie van de AbstractServerService en deze registreert zichzelf voor het ontvangen van callbacks (wanneer de callback url werd opgegeven tijdens registratie) en de nodige systeem events horende bij deze medische service (bijvoorbeeld het event van een binnenkomende postUpdateData oproep).

Mobile Communications Module Figuur 4.8 toont de architectuur van de Mobile Communications Module. Elke mobiele ontvanger heeft zijn eigen MobileContact. De MobileContact is verantwoordelijk voor het ontvangen van events die naar zijn mobiele ontvanger wensen verstuurd te worden. Daarnaast is er een threadpool1 aanwezig met een vooraf bepaalde grootte. De ContacterAdmin deligeert de inkomende verzoeken door naar de correcte MobileContact en start eventueel een nieuwe ContactWorker op. Maximaal één ContactWorker zal op het zelfde moment werken op een MobileContact. De ContactWorker probeert in eerste instantie een MobileEvent te versturen naar de mobiele ontvanger door gebruik te maken van de klasse RESTMobileEventSender. Wanneer dit mislukt zal de ContactWorker het event (de unieke id van het event) versturen naar de mobiele ontvanger door gebruik te maken van de SMSMobileEventSender.

4.1.3

Subsysteem: Mobile Receiver

De Mobile Receiver Interface (zie figuur 4.9) is de enige interface die extern beschikbaar is voor de Pub/Sub Broker. Deze interface heeft eigenlijk maar één methode: postEvent, maar is wel in drie varianten terug te vinden. De twee varianten die als parameter een subklasse zijn van 1

Een threadpool bevat een een verzameling van threads. Deze threads zullen verschillende taken die toever-

trouwd worden aan de threadpool, parallel uitvoeren.

4.1 Component View

Figuur 4.8: Subsystem: Pub/Sub Broker, Mobile Communications Module

45

4.1 Component View

46

Figuur 4.9: Subsystem: Mobile Receiver MobileEvent, zenden effectieve data door naar de Mobile Receiver. De variant waar enkel een String (event id) wordt doorgezonden, vereist nog een extra request naar de Pub/Sub Broker om het MobileEvent op te halen. Typisch zal deze String-variant gebruikt worden wanneer de Mobiele Ontvanger enkel bereikbaar is via SMS (Advertising/Delivery) [7]. Een DataEvent wordt verzonden naar de Mobile Receiver wanneer de Pub/Sub Broker een nieuwe update heeft binnen gekregen van een (medische) service. De effectieve data van deze update is terug te vinden in het ServiceUpdateData object. Bij het gebruiken van een BundleEvent zijn er twee oorzaken die aan de basis kunnen liggen. Ten eerste kan het een gevolg zijn door een registratie actie bij een medische service. De verkregen data van de medische service zou dan nog niet correct kunnen worden voorgesteld. De Pub/Sub Broker herkent dit probleem direct en zendt de bundel, die zelf is aangebracht door de medische service, door naar de Mobile Receiver. Zo kan de verkregen data (via een DataEvent) van de medische service op een correcte manier voorgesteld worden op het toestel. Een tweede oorzaak vloeit uit een interactie met de Developers Interface door een bundel ontwikkelaar. Een bundel kan toegevoegd, verwijderd of ge¨ updatet worden en ook de Mobile Receiver moet hiervan op de hoogte worden gebracht.

4.1 Component View

47

Figuur 4.10: Subsystem: Mobile Receiver, Components Figuur 4.10 en 4.11 tonen in een UML-diagram hoe de verschillende componenten binnen de Mobile Receiver met elkaar communiceren. Het Display Component uit figuur 4.10 is een abstractie van het scherm van de mobiele ontvanger, de smartphone. Deze component zorgt voor een GUI container waar verschillende tabbladen kunnen worden toegevoegd of verwijderd. Daarnaast is er ook een kleine statusbar aanwezig die kan ingevuld worden met statusberichten. TabServices stellen de medische en interne mobiele services voor. Want elke service, of het nu gaat om een medische service of een interne mobiele service, krijgt van de Mobile Receiver de mogelijkheid om zich aan de arts kenbaar te maken door een nieuw tabblad in te vullen. Een medische service is bijvoorbeeld de ABDose Service, terwijl de interne mobiele services bestaan uit o.a. de Subscription Service en Workshift Service. Elk van deze services maakt enkel gebruik van de API beschikbaar in de TabServices module. De Communication Microkernel dirigeert de inkomende events naar de correcte TabServices. De Dynamic Customizer heeft de verantwoordelijkheid om de batterijstatus van het mobiele toestel in het oog te houden, zodat er tijdig kan overgestapt worden naar een minder batterij intensieve communicatie (ExComm Interface).

4.1 Component View

48

Figuur 4.11: Subsystem: Mobile Receiver, Interfaces Display Module De AWT Container (Thinlet) implementeert alle methodes die aanwezig zijn in de GUI Interface (zie figuur 4.12). Deze interface voorziet methodes om GUI elementen aan te maken, op te zoeken en te veranderen. De GUIDecorator neemt een service naam als argument in zijn constructor en vormt een decorator van de AWT Container voor de GUI Interface. De TabbedFrame is een AWT Frame en is het enige ’venster’ dat op de mobiele ontvanger zal en kan getoond worden. Dit frame bevat een tab-container waar alle objecten die GUIPanel implementeren en opgevangen worden door de GUIPanelListener, worden toegevoegd. Daarnaast implementeert TabbedFrame de Display Interface. Deze interface voorziet een methode waarbij het bericht in de statusbalk van het frame aangepast kan worden en een methode die een pop-up kan tonen met een bepaalde

4.1 Component View

49

Figuur 4.12: Subsystem: Mobile Receiver, Display Module vraag (UIInteraction).

TabServices Module Figuur 4.13 verduidelijkt de architectuur in de TabServices module. Elke MobileService heeft een bepaalde (unieke) naam en kan gestart en gestopt worden. Daarnaast kan het ofwel een interne callback maken naar de Pub/Sub Broker (doInternalCall ) ofwel een callback naar een bepaalde externe service (via de Pub/Sub Broker ). Deze laatste callback (doCallback ) zal voornamelijk gebruikt worden door de implementatie objecten van de medische services. Services hebben keuze uit drie soorten. Ofwel kunnen ze een implementatie zijn van de BundleBackgroundService, ofwel de DataBackgroundService of als laatste mogelijkheid, de TabService. Medische services zullen typisch enkel gebruik maken van de TabService. De TabService heeft namelijk

4.2 Collaboration View

50

Figuur 4.13: Subsystem: Mobile Receiver, TabServices Module als enige van de drie een GUI beschikbaar. De andere twee implementeren ofwel enkel de DataListener ofwel de BundleListener. Uiteraard zullen sommige interne mobiele services (zoals de Subscription Service en de Workshift Service) ook een implementatie zijn van de TabService. De BundleBackgroundService zal voornamelijk gebruikt worden door de BundleManager Service.

4.2

Collaboration View

Na het overlopen van de componentdiagrammen worden in deze sectie enkele sequentiediagrammen voorgesteld die de werking van het systeem en de communicatie tussen de verschillende componenten verduidelijkt. Als eerste komen de sequentiediagrammen tussen de subsystemen


51

aan bod, daarna komt de Pub/Sub Broker en vervolgens worden de sequentiediagrammen van de Mobile Receiver uitgewerkt.

4.2.1

Sequentiediagrammen tussen de subsystemen

Figuur 4.14: Sequence Diagram Medical Data (a) Figuur 4.14 en 4.15 tonen twee mogelijke volgorden van communicatie tussen de medische services, de Pub/Sub Broker, de Mobile Receiver en de arts. Bij de eerste stap in figuur 4.14 zal de arts op zijn mobiel toestel het ICSP Mobile programma opstarten. Onmiddelijk wordt de GUID van het mobiel toestel, het telefoonnummer en de bundellijst op dat moment verstuurd naar de Pub/Sub Broker (stap 2). In de derde stap registreert een medische service zich bij de Pub/Sub Broker. Dit heeft als gevolg dat de Mobile Receiver op de hoogte wordt gebracht van de aanwezigheid van de nieuwe service (stap 4). In stap 5 registreert de arts zich bij deze nieuwe service. Door deze registratie ontvangt de arts de bundel (stap 7) welke bij registratie van de medische service werd aangereikt. De arts beslist vervolgens in stap 8 om zijn werkshift te starten. Dit heeft als gevolg dat toekomstige of geldige events met een ServiceUpdateData kunnen verstuurd worden naar de Mobile Receiver (stap 11). Dit zal alleen gebeuren wanneer de medische service die de ServiceUpdateData heeft gepost (stap 10) naar de Pub/Sub Broker, de juiste key als argument kon geven.


52

Figuur 4.15: Sequence Diagram Medical Data (b) In het sequentiediagram van figuur 4.15 zijn de volgorde van de acties gewijzigd. In stap 11 wordt de postEvent bovendien per SMS verzonden naar de Mobile Receiver. Dit heeft als gevolg dat er nog een extra request van de Mobile Receiver naar de Pub/Sub Broker is om het event op te halen (stap 12). De sequentiediagrammen in figuur 4.14 en 4.15 hebben dezelfde preconditie en postconditie. Preconditie: De Pub/Sub Broker is opgestart. De arts is bij geen enkele medische service geregistreerd. Postconditie: De Pub/Sub Broker en de Mobile Receiver zijn actief. De arts is geregistreerd op de medische service en zijn toestel heeft het tabblad van deze service en een eerste informatie update ontvangen.

4.2.2

Sequentiediagrammen van de Pub/Sub Broker

Broker Interface: internalCall Het sequentiediagram in figuur 4.16 verduidelijkt hoe een internalCall doorheen de Pub/Sub Broker componenten gaat tot aan de gewenste service (stap 1-3), de Initialize Service in dit


53

Figuur 4.16: Sequence Diagram: internalCall geval. De Initialize Service zal vervolgens de gebruikersinfo in stap 4 extraheren uit de Map en ze in de DataStore opslaan (stap 5). Vervolgens wordt ook de bundel lijst van de Mobile Receiver geanalyseerd (stap 6). Deze analyse kan bepaalde BundleEvents tot gevolg hebben (stap 8) en zal dus bepaalde bundels toevoegen aan of verwijderen van de Mobile Receiver. Preconditie: De Pub/Sub Broker is opgestart en de Mobile Receiver is aan het opstarten. Postconditie: De Pub/Sub Broker is actief en de Mobile Receiver is volledig opgestart. De Mobile Receiver is ook (qua bundels) gesynchroniseerd.

Medical Services Interface: registerService In figuur 4.17 wordt het eenvoudige sequentiediagram getoond van wat er gebeurt wanneer een nieuwe medische service zich aanmeldt. De medische service moet tijdens stap 1 het systeem voorzien van zijn naam, zijn bundel die moet doorgestuurd worden naar de Mobile Receiver(s) bij gebruik van de service en eventueel een callback URL die een link bevat naar een WSDL bestand online. Na het aanmaken van de key (stap 2) wordt de service opgeslaan in de Datastore (stap 3) en wordt vervolgens een ’newServiceEvent’ verstuurd naar de EventAdmin. Preconditie: De medische service heeft zich nog niet eerder geregistreerd bij de actieve Pub/Sub


54

Figuur 4.17: Sequence Diagram: registerService Broker. Postconditie: De medische service is geregistreerd en is in bezit van zijn key. Het systeem is op de hoogte gebracht van de aanwezigheid van een nieuwe medische service.

Medical Services Interface: postUpdateData

Figuur 4.18: Sequence Diagram: postUpdateData In figuuur 4.18 wordt het sequentiediagram verduidelijkt wanneer een medische service een


55

ServiceUpdateData post. Hierbij moet de service zich bekend maken en een key meegeven (stap 1). In stappen 2 en 3 wordt vervolgens de ontvangen key vergeleken met de key uit de Datastore. Wanneer deze niet overeenkomen zal het systeem niet op de hoogte worden gebracht van de aanwezigheid van een nieuwe ServiceUpdateData (stap 4). Preconditie: De medische service heeft zich al eerder geregistreerd en is dus in bezit van een key. De Pub/Sub Broker is actief. Postconditie: Indien de key correct was, werd het systeem op de hoogte gebracht van de aanwezigheid van een nieuwe ServiceUpdateData.

Developers Interface: updateBundle

Figuur 4.19: Sequence Diagram: updateBundle In sequentiediagram 4.19 wordt een bundel van de Mobile Receiver ge¨ updatet. Bij het aanroepen van updateBundle in stap 1, moet de naam van de bundel gegeven zijn (symbolicName) met daarnaast de nieuwe bundel die in zijn plaats moet komen. In stap 2 wordt vervolgens geanalyseerd of de meegegeven bundel wel degelijk een bundel is. Zoja wordt deze aangepast in de DataStore (stap 3) en wordt het systeem op de hoogte gebracht (stap 4). Het resultaat (boolean) van de udpateBundle oproep geeft aan of de meegegeven bundel effectief een bundel was. Deze controle zal typisch gebeuren door de statische methodes van de Bundle klasse ex-

4.3 Deployment View

56

tractSymbolicName en extractVersion op te roepen. Preconditie: De Pub/Sub Broker is actief en heeft eerder al een addBundle oproep gemaakt. Postconditie: De bundel is ge¨ updatet en het systeem werd hiervaan op de hoogte gebracht.

Mobile Communications: BundleEvent Figuur 4.20 verduidelijkt de werking van het Mobile Communications component om de mobiele ontvangers op de hoogte te brengen. Dit gebeurt in het sequentiediagram aan de hand van BundleEvent. In stap 1 wordt de EventHandler van het Mobile Communications component aangemaakt en in stap 2 volgt de registratie. Wanner vervolgens in stap 3 een postEvent toekomt bij de EventAdmin, wordt de EventHandler op de hoogte gebracht (stap 4 en 5). Het verkregen event bevat de symbolicName. Deze symbolicName wordt in stap 7 gebruikt om de bijhorende Bundle op te halen. Nadat het BundleEvent is aangemaakt, wordt deze verstuurd naar alle gebruikers (stap 8 en 9). In een eerste poging wordt het event verstuurd door gebruik te maken van de WiFi (stap 10 en 11). Wanneer dit mislukt zal het eventID verstuurd worden via SMS (stap 12 en 13). Preconditie: De Pub/Sub Broker is actief. Postconditie: De Mobile Receiver(s) werden op de hoogte gebracht.

4.2.3

Sequentiediagrammen van de Mobile Receiver

Mobile Receiver Interface: postEvent In het korte sequentdiagram 4.21 wordt een postEvent in stap 1 verstuurd via een SMS. Het postEvent bevat op dat moment enkel de eventID van het event. De Communications MicroKernel zal op dat moment aan de Pub/Sub Broker het volledige MobileEvent object opvragen (stap 2). Vervolgens worden de nodige luisteraars op de hoogte gebracht (stap 3 en 4). Dit kunnen ofwel DataListener s (voor een DataEvent) zijn, ofwel BundleListener s (voor een BundleEvent). Preconditie: De Pub/Sub Broker en een Mobile Receiver zijn opgestart. Postconditie: De nodige luisteraars (DataListener of BundleListener) werden op de hoogte gebracht.

4.3 Deployment View

Figuur 4.20: Sequence Diagram: Mobile Communications, BundleEvent

57

4.3 Deployment View

58

Figuur 4.21: Sequence Diagram: postEvent

Figuur 4.22: Deployment View: Main System

4.3 Deployment View

4.3

59

Deployment View

In 4.22 wordt het deployment diagram getoond van het algemeen systeem. Er is gekozen om dit systeem in OSGi containers te deployen. Dit impliceert dat het systeem in bundels zal verdeeld worden. Het is dan ook interessant om de afhankelijkheden tussen die bundels te schetsen aan de hand van een component view. In figuur 4.23 en 4.24 worden de afhankelijkheden tusssen de bundels van respectievelijk de Pub/Sub Broker en de Mobile Receiver OSGi container uit de doeken gedaan.

Figuur 4.23: Component View: Pub/Sub Broker bundle dependencies

4.3 Deployment View

Figuur 4.24: Component View: Mobile Receiver bundle dependencies

60

IMPLEMENTATIE

61

Hoofdstuk 5

Implementatie In dit hoofdstuk wordt de implementatie van het systeem besproken. Het volledige systeem is onder te verdelen in drie grote delen: de mobiele ontvanger, de pub/sub broker en de externe services. De externe services implementeren de dummy medische services (zoals de ABDose service) die met de pub/sub broker communiceren. Naast het beschrijven van de implementatie van de belangrijkste componenten worden ook de problemen die opgerezen zijn tijdens de implementatie uitgewerkt met hun oplossingen. Vooreerst wordt een algemeen beeld geschetst van de implementatie en de gebruikte tools. Vervolgens wordt de implementatie van de mobiele ontvanger uit de doeken gedaan, daarna volgt de pub/sub broker en als laatste wordt de implementatie van de externe services besproken.

5.1

Algemeen

Zowel de implementatie van de mobiele ontvanger, als de pub/sub broker en de externe services zijn ontworpen door gebruik te maken van Maven binnen de Eclipse IDE. Hierbij wordt er handig gebruik gemaakt van de q4e Apache Maven plugin voor Eclipse.

Eclipse en Maven Na het aanmaken van een nieuw project binnen Eclipse, moet het project omgevormd worden tot een Maven project. Het is belangrijk dat bij het aanmaken van een nieuw project als bronmap ’src/main/java’ en als doelmap ’target/classes’ gekozen wordt. Op die manier zal

5.1 Algemeen

62

de structuur die Maven aanneemt, zonder problemen kunnen compileren. Resources (figuren of XML-bestanden bijvoorbeeld) die men wenst toe te voegen aan het project, dienen in de bronmap ’src/main/resources’ geplaatst te worden.

DyPSyS Zoals in de inleiding aangehaald is het volledige systeem onder te verdelen in drie grote delen. Er zijn echter verschillende kleinere delen die gekoppeld zijn aan deze drie grote delen. De verschillende modules aanwezig in het maven hoofdproject zijn af te leiden uit figuur 5.1. DyPSyS is de codenaam voor dit implementatie project en staat voor ’Dynamic Push System’.

Figuur 5.1: Maven modules De modules ’DyPSyS-Mobile-Bundles’, ’DyPSyS-Server-Bundles’ en ’ExternalActors-Bundle’ zijn op zich opnieuw een verzameling van modules (OSGi bundels) en worden in de volgende secties besproken. De drie modules ’DyPSyS-Server’, ’DyPSyS-Mobile’ en ’ExternalActors’ zijn geen OSGi bundels, maar gewone Java projecten. Ze bevatten een ”public static void main”die respectievelijk de server, mobiele ontvanger en de externe services opstart.

Felix en OSGi De drie projecten die gewone Java projecten zijn, zijn nodig opdat het Felix OSGi framework correct zou opgestart worden met de juiste configuratie. Dit heeft als voordeel dat het programma opgestart kan worden vanuit eender welke map, zonder specifiek afhankelijk te moeten zijn van een bepaalde directory of bestand. Op die manier wordt OSGi (Apache Felix) opgestart met de nodige en correcte bundelmap en cachemap als argument en wordt daarnaast het OSGi configuratie bestand naar de juiste map gekopieerd.

5.2 Mobiele ontvanger

63

Dit was vooral broodnodig bij het opstarten van OSGi binnen een Windows Mobile omgeving. De ’user.dir’ Java property werd namelijk gebruikt als root map. Dit leidde tot verschillende problemen aangezien de ’user.dir’ binnen Windows Mobile de root map is van het Windows besturingssysteem, met toegangsbevoegdheid problemen tot gevolg. Het opstartproject van de mobiele ontvanger bevat daarnaast ook nog een GUID generator. Wanneer een unieke GUID nog niet werd aangemaakt, wordt deze gegenereerd. Op die manier is de mobiele ontvanger uniek te onderscheiden, aangezien men er niet van kan uitgaan dat elke mobiele ontvanger een uniek IP-adres heeft.

5.2

Mobiele ontvanger

In deze sectie wordt de implementatie van de mobiele ontvanger besproken. Het programma heeft de naam ICSP Mobile gekregen. Na het beschrijven van het gebruikte platform, wordt de implementatie van de GUI en de programmatische toegang tot het besturingssysteem beschreven.

5.2.1

Platform

Na het state-of-the-art onderzoek werd besloten dat Windows Mobile het meest geschikte mobiele besturingssysteem was. De mobiele ontvanger wordt bijgevolg ge¨ımplementeerd en getest op een Windows Mobile 6 emulator en op een HTC Touch Pro 2 toestel met ook Windows Mobile 6 als besturingssysteem. Telkens wordt er gebruik gemaakt van de phoneME Java VM van Davy Preuveneers. Het is een open bron Java ME applicatie platform voor Windows Mobile. PhoneMe bevat twee varianten: de phoneME Feature (een CLDC implementatie) en de phoneME Advanced (een CDC implementatie). Voor de implementatie van de mobiele ontvanger wordt er (zoals eerder besproken in het state-of-the-art onderzoek) gebruik gemaakt van de CDC (Personal Profile) configuratie. Het installeren van de phoneME Advanced met het Personal Profile kan eenvoudig gebeuren door de correcte .cab file te downloaden van de phoneME website en vervolgens te kopiëren naar het (virtuele) toestel en het programma tenslotte te installeren.


64

Tegengekomen problemen en oplossingen Het was even zoeken hoe het programma gemakkelijk kan gestart geworden met de nodige parameters. Doordat dus de ’user.dir’ map binnen Windows Mobile de root folder is, moet een pad naar een bepaald bestand altijd met zijn volledig pad aangesproken worden. De volgende .lnk bestanden kunnen aangemaakt worden om het programma respectievelijk op de emulator of op een echt toestel op te starten:

254#"\Programmabestanden\pMEA PP\bin\cvm.exe" "-Xopt:stdioPrefix=/Opslagkaart,useConsole=false" -jar "\My Documents\Zakelijk\DyPSyS-Mobile-1.0-SNAPSHOT.jar" en 254#"\Program Files\pMEA PP\bin\cvm.exe" "-Xopt:stdioPrefix=/storage card,useConsole=false" -jar "\My Documents\Business\DyPSyS-Mobile-1.0-SNAPSHOT.jar" De ’Xopt:stdioPrefix’ optie wordt gebruikt opdat de console output naar bestanden op de externe opslagkaart worden uitgeschreven. Op die manier kan dan via een extern programma de output (System.out in out.txt en System.err in err.txt) gevolgd worden.

5.2.2

Grafische gebruikers interface

De GUI van de mobiele ontvanger is één van de belangrijkste componenten binnen de mobiele ontvanger. Het is de interface die interageert met de arts, wat tot gevolg heeft dat het dus een intu¨ıtieve en gebruiksvriendelijke interface moet zijn. Doordat er gebruik gemaakt wordt van het profiel ’Personal Profile’ van CDC is de AWT-bibliotheek van Java beschikbaar. De GUI van mobiele ontvanger is ontwikkeld met behulp van Thinlet [48]. Thinlet is een GUI toolkit die bestaat uit één enkele Java-klasse. Het is mogelijk om de grafische presentatie (beschreven in een XML-bestand) te scheiden van de business logica, maar het is ook mogelijk om rechtstreeks via programmatie de gewenste elementen aan te maken of aan te passen. Bij het opstarten van de applicatie worden enkele algemene elementen aangemaakt, zoals een statusbalk en een tab-container. De GUI wordt verder enkel aangevuld door tabbladen aan-


65

gereikt door de (medische/interne) services. Figuur 5.2 toont de GUI met enkele tabbladen.

Figuur 5.2: GUI van mobiele ontvanger

Tegengekomen problemen en oplossingen Er waren enkele aanpassingen nodig aan Thinlet om zijn mogelijkheden volledig te kunnen benutten binnen OSGi. Het moet immers mogelijk zijn dat een (medische) service zich dynamisch at runtime kan toevoegen aan of verwijderen uit de GUI van de mobiele ontvanger. Dit leidde tot twee problemen: een BundelContext probleem en een probleem van interferentie van de GUI van de services. Zo’n medische service wordt typisch aangebracht in een nieuwe bundel. Deze nieuwe bundel heeft zijn eigen bundel context waar de resources van deze bundel beschikbaar zijn. Deze resources kunnen bijvoorbeeld figuren zijn die men wenst te gebruiken in de GUI van die medische service. Deze bestanden zijn bereikbaar door de methode ’BundleContext.getResource’ op te roepen. Het is dus noodzakelijk dat tijdens het parsen van de GUI, de BundleContext van die specifieke bundel beschikbaar is, wanneer Thinlet deze nodig heeft om bepaalde resources uit de bundel te halen. Broncode aanpassingen aan ’parse’ en ’getIcon’ methodes waren dus nodig. Daarnaast vormde zich het probleem van interferentie van de GUI van de verschillende services.


66

Thinlet zoekt namelijk de gewenste componenten op, op basis van hun naam. Wanneer meerdere services dezelfde naam hebben voor een bepaald component zorgt dit voor problemen. Het was dus nodig elke service een eigen decorator te geven met hun service naam als argument in de constructor van de decorator (zie 4.1.3). Op die manier wordt tijdens het aanmaken en het opvragen van de gewenste componenten een prefix toegevoegd aan de component-naam. Dit gebeurt volledig transparant voor de ontwikkelaars van de (medische) services.

5.2.3

JNA

Om gebruik te kunnen maken van bijvoorbeeld de batterij of sms mogelijkheden die het besturingsysteem Windows Mobile aanbiedt, moeten er methodes opgeroepen worden van het besturingssysteem zelf. Hierbij wordt gebruik gemaakt van Java Native Access. JNA voorziet Java programmeurs van een relatief eenvoudige manier om toegang te krijgen tot het besturingssysteem. Dit in contrast met de nodige configuratie en het opbouwen van JNI code. JNA heeft echter officieel (nog) geen ondersteuning voor Windows Mobile, maar er is wel een implementatie beschikbaar. Op de volgende website is een implementatie voor de JAVA ME CDC FP 1.1 versie terug te vinden. https://jna.dev.java.net/issues/show_bug.cgi?id=108 Er zijn slechts enkele lijnen code nodig om de native methodes op te roepen. Hieronder is de Java klasse beschreven die de status van de batterij kan opvragen: (getters en het opvangen van excepties zijn weggelaten) import com.sun.jna.wince.Coredll; import com.sun.jna.wince.WMAPI.SYSTEM_POWER_STATUS_EX; public class Battery { private int batteryFlag; private int batteryLifePercent; private Coredll lib = Coredll.INSTANCE; public void makeNativeInvocation() { SYSTEM_POWER_STATUS_EX sps = new SYSTEM_POWER_STATUS_EX(); if (lib.GetSystemPowerStatusEx(sps, true)) { batteryFlag = sps.BatteryFlag;


67

batteryLifePercent = sps.BatteryLifePercent; } } } Verder wordt JNA gebruikt om SMS’en te ontvangen en de Wi-Fi van het mobiele toestel te beheren.

Ontvangen van SMS’en Methodes die gebruikt kunnen worden om een SMS te ontvangen, zijn echter niet terug te vinden in een com.sun.jna.wince klasse. Er zijn twee mogelijke oplossingen voor dit probleem. Ofwel worden alle nodige klassen en methodes vanuit de Windows Mobile API vertaald naar JNA. Ofwel wordt een kleine DLL aangemaakt welke vervolgens via JNA wordt aangeroepen. Er is gekozen voor deze laatste oplossing, omdat er onder andere vereist wordt dat er enkele registerwaarden worden toegevoegd aan het besturingssysteem en het bovendien relatief eenvoudiger is om een DLL te maken in plaats van alle nodige klassen en methodes van de Windows Mobile API om te zetten naar JNA code. De speciaal aangemaakte DLL voor het ontvangen van SMS’en filtert de inkomende SMS’en. Wanneer een bepaald bericht voldoet aan een bepaalde voorwaarde (in dit geval moet de SMS de substring ’ICSPMOBILE=’ bevatten) zal de SMS opgevangen en verwerkt worden, zoniet zal de SMS opgevangen worden door de SMS inbox van de gebruiker zelf. Het verwerken van de SMS door de DLL betekent in dit geval het programma op de hoogte brengen van de aanwezigheid van een nieuwe SMS. De DLL werd aangemaakt door gebruik te maken van Microsoft Visual Studio 2008 en is geprogrammeerd in C++. Bij het aanmaken van een nieuw project moet gekozen worden voor een ’Win32 Smart Device Project’ en vervolgens de gewenste compatibiliteit met de verschillende Windows Mobile besturingssystemen aanduiden en DLL project aanvinken. De functies die men wenst extern beschikbaar te stellen, moeten in een Module Definition File vermeld worden.

5.3 Pub/Sub Broker

68

Beheer van de Wi-Fi Ook voor het beheer van de Wi-Fi werd een DLL aangemaakt. De juiste API’s voor deze functionaliteit zijn echter niet direct beschikbaar. Na vruchteloos onderzoek in de Windows Mobile API’s en op zoekmachines, werd de onwikkelaar (Davy Preuveneers) van de Java ME VM voor Windows Mobile (phoneME) gecontacteerd. Hij had het volgende over dit onderwerp te vertellen:

Ik kan u zeggen dat het aanschakelen en uitschakelen van Wi-Fi niet eenvoudig is. Ik heb een tijd geleden iets gelijkaardig moeten doen (Wi-Fi, Bluetooth en GPRS aan- en uitschakelen) en toen heb ik undocumented features moeten gebruiken die specifiek waren voor de driver en Wi-Fi chipset van het toestel. Het beste wat in de buurt komt van wat jij wil doen, zijn de Connection Manager API’s. Het zijn dan ook deze Connection Manager API’s die gebruikt zijn voor de implementatie van de DLL. Dit heeft als gevolg dat de Wi-Fi altijd aanstaant, maar na enige tijd van inactiviteit naar een standy-modus gaat. Op dat moment is het mobiele toestel niet meer geconnecteerd met het draadloze netwerk en bijgevolg voor de Pub/Sub Broker niet meer bereikbaar. Wanneer vervolgens een SMS wordt ontvangen die de mobiele ontvanger notificeert van de aanwezigheid van een nieuw event bij pub/sub broker, zal na het oproepen van de ’activate’ methode, wel opnieuw connectie worden gemaakt met het draadloze netwerk. Het aan- en uitschakelen van de Wi-Fi is dus met andere woorden vervangen door respectievelijk een actieve- en een standbymodus.

5.3

Pub/Sub Broker

De pub/sub broker is de centrale component tussen de mobiele ontvanger en de externe services. SOAP is een eerste belangrijke component en wordt gebruikt als communicatiemiddel voor de externe services. Daarnaast volgt SMS en wordt er een binair protocol gebruikt als communicatiemiddel tussen de mobiele ontvangers en de pub/sub broker. Een laatste belangrijke component die besproken wordt is de Datastore component.

5.3 Pub/Sub Broker

5.3.1

69

SOAP

Het Simple Object Access Protocol wordt gebruikt als communicatiemiddel tussen de pub/sub broker en de externe services. Medische services en bundel ontwikkelaars kunnen op die manier interageren met de pub/sub broker. Er wordt gebruik gemaakt van de Apache CXF [103] bibliotheek om dit te realiseren. CXF is een uitgebreide bibliotheek met ondersteuning voor verschillende frontend API’s (JAX-WS, JAX-RS), protocollen (SOAP, CORBA) en transport protocollen (HTTP, JMS, JBI). Voor de implementatie van SOAP binnen OSGi, wordt er gebruik gemaakt van een subproject van CXF genaamd ’Apache CXF Distributed OSGi’. CXF Distributed OSGi is de referentie implementatie voor de ’Remote Services’ OSGi-specificatie en maakt daarbij gebruik van web services, meerbepaald met behulp van SOAP en HTTP als transport protocol, wat tot gevolg heeft dat de partijen gebonden zijn door een WSDL contract. Bij het effectief integreren van CXF binnen OSGi kan er een keuze gemaakt worden door ofwel gebruik te maken van een single-bundle distributie ofwel door gebruik te maken van een multibundle distributie. In eerste instantie werd gekozen voor de single-bundle distributie, omdat het aantal bundels met hun afhankelijke bundels snel stijgt bij het gebruik van de multi-bundle distributie. Dit heeft echter enkele praktische nadelen. Door een kleine bug in de log bundel van het Apache Felix project, tolereert deze bundel geen andere log bundel. De single-bundle distributie heeft intern een SLF4J logging systeem. Door deze bug en de combinatie van SLF4J kunnen er dead-locks ontstaan, waardoor CXF niet verder zal opereren. De verschillende bibliotheken binnen de single-bundle distributie kunnen bovendien niet apart ge¨ updatet, gestart of gestopt worden. Daarnaast heeft deze single-bundle distributie intern veel bundels gemeenschappelijk in vergelijking met de andere pub/sub broker bundels. Na het evalueren van bovenstaande gevolgen, werd vervolgens gekozen voor de multi-bundle distributie. Door het zorgvuldig selecteren van de nodige bundels en het configureren van de juiste start levels kon het aantal bundels tot een overzichtelijk aantal gehouden worden. Een webservice kan eenvoudig aangemaakt worden met de volgende lijnen code: public void start(BundleContext context) { Dictionary<String, String> p = new Hashtable<String, String>(); p.put("service.exported.interfaces", "*"); p.put("service.exported.configs", "org.apache.cxf.ws"); p.put("org.apache.cxf.ws.httpservice.context", "/medicalService");

5.3 Pub/Sub Broker

70

context.registerService(MedicalService.class.getName(), new MedicalServiceImpl(context), p); } Het WSDL contract is vervolgens beschikbaar via /medicalService?wsdl.

5.3.2

SMS verzenden

Wanneer de mobiele ontvanger niet bereikbaar is via Wi-Fi, zal een SMS worden verzonden naar de mobiele ontvanger. Bij het versturen van een SMS uitgaande van de server zijn er twee implementatie mogelijkheden. Er kan gebruik gemaakt worden van een SMS gateway. Typisch is dit een website met een bepaalde API die na het leveren van de juiste parameters instaat voor het verzenden van de SMS. Deze service vraagt echter een bepaalde meerkost per bericht en heeft bovendien de reputatie van traag te zijn. De keuze viel vervolgens snel op de tweede implementatie mogelijkheid, namelijk het aansluiten van een GSM via een seriële kabel op de server. Vervolgens kunnen dan via AT commando’s1 instructies worden gegeven aan de GSM modem. Voor de implementatie van dit stuk software werd gebruik gemaakt van de Java Communications API en delen uit open bron code [104].

5.3.3

Binair REST protocol

Om de communicatie te voorzien tussen de mobiele ontvanger en de pub/sub broker werd eerst het HTTP REST protocol aangehaald. Er zijn enkele bibliotheken, zoals Restlet, beschikbaar die het REST protocol implementeren. Een nadeel, aan de Restlet bibliotheek bijvoorbeeld, is echter dat ze een Java versie 1.5 of hoger eisen en bijgevolg niet bruikbaar zijn op een Java ME CDC configuratie. Doordat de communicatie van de pub/sub broker en de mobiele ontvanger onafhankelijk gebeurt van de specifieke implementatie van de services, zowel aan server als aan de client zijde, is een eigen implementatie van een binair protocol mogelijk. Het ge¨ımplementeerde protocol maakt gebruik van objecten die Serializable zijn en van de klassen ObjectOutputStream en ObjectInputStream. Een overzicht van de architectuur van deze component is terug te vinden in figuur 5.3. De abstracte klasse AbstractClient heeft enkele finale methodes en twee abstracte 1

De meeste modem commando’s starten met de letterreeks ’AT’, om zo de attentie van de modem te krijgen.

Daarom worden modem commando’s, AT commando’s genoemd.

5.3 Pub/Sub Broker

71

methodes. De twee abstracte methodes zijn fillRequest en analyseResponse om respectievelijk een request te construeren en een antwoord te analyseren. Door de methode doRequest op te roepen wordt de request verstuurd en een antwoord ontvangen. De RESTServer klasse luistert naar inkomende connecties op een bepaalde poort. Na constructie is het mogelijk om ServerResources toe te voegen aan deze server (attach). Een ServerResource wordt ge¨ıdentificeerd door een bepaald pad en bevat verschillende methodes die opgeroepen worden naargelang de soort inkomende request (doGet, doPost, doDelete). Bij het detecteren van een nieuwe connectie door de RESTServer wordt een nieuw Connection object aangemaakt. Deze zal zijn op zijn beurt gebruik maken van de Worker klasse om zo de correcte ServerResource aan te roepen die na analyse van het request een antwoord zal vormen.

Figuur 5.3: Architectuur Binair REST protocol

5.3.4

Mobiele ontvanger contacteren

Wanneer events zich voordoen in de pub/sub broker waarvan de mobiele ontvanger op de hoogte moet gebracht worden, zullen deze events toegevoegd worden aan de ’sendingQueue’ (zie Queue1 in figuur 5.4) van die mobiele ontvanger. Elke mobiele ontvanger heeft twee wachtrijen waarin events worden geplaatst. De eerste wachtrij (Queue1) bevat alle events die zouden verstuurd

5.3 Pub/Sub Broker

72

Figuur 5.4: De Mobiele Ontvanger contacteren

5.3 Pub/Sub Broker

73

moeten worden. De tweede wachtrij (Queue2) bevat die events die wachten tot de werkshift van de arts gestart is. Daarnaast is een threadpool aanwezig met een vooraf bepaalde grootte. ’ContactWorkers’ zijn de taken binnen de threadpool en zullen werken op de twee wachtrijen van een bepaalde mobiele ontvanger. Hoe deze ContactWorkers werken wordt beschreven in figuur 5.4. Er zijn vier gebeurtenissen die de ContactWorker opstarten. (Elke mobiele ontvanger kan maximaal één ContactWorker op zich laten werken.) • Een nieuw event wordt toegevoegd aan Queue1. • De mobiele ontvanger maakt een callback naar pub/sub broker. Dit betekent dat de mobiele ontvanger online is (als hij dat al niet was) en mogelijks berichten kan ontvangen (via Wi-Fi). • De mobiele ontvanger heeft een SMS ontvangen en vraagt vervolgens het event op aan de pub/sub broker. Ook hier betekent dit dat de mobiele ontvanger terug online is. • De werkshift van de arts is gestart. Hierdoor kunnen eventuele events die in Queue2 zitten terug verplaatst worden naar Queue1, waar ze nu wel kunnen verzonden worden. Het is belangrijk om op te merken dat telkens bij het verzenden van een event nagekeken wordt of de duurtijd van het event niet verlopen is (time-out). Zoja zal het event verwijderd en niet verzonden worden.

5.3.5

Datastore module

De pub/sub broker heeft ook een database waar alle nodige gegevens betreffende de services, gebruikers en hun subscripties opgeslaan worden. Er is gekozen om gebruik te maken van EclipseLink. Het ondersteunt OSGi en implementeert de JPA specificatie. Voor de database zelf is gekozen voor een in memory Derby [105] Database. In memory databases zijn eenvoudiger om te onwikkelen en hebben bovendien een betere performantie. Wanneer nieuwe entiteiten worden toegevoegd aan het systeem, is het belangrijk dat het persistence.xml bestand dat aanwezig is in de map META-INF ook aangepast wordt.

5.4 Externe services

5.4

74

Externe services

De externe services die met de pub/sub broker interageren via SOAP, zijn onder te verdelen in twee groepen. De medische services en de bundel ontwikkelaars. Beiden vormen op dat moment een SOAP client die communiceert met de pub/sub broker. Een SOAP client kan eenvoudig aangemaakt worden door het WSDL2JAVA programma op te roepen van Apache CXF. Het genereert alle klassen die nodig zijn om een SOAP client te construeren. Sommige medische services (zoals de ABDose service) wensen op de hoogte te worden gebracht van een beslissing van de arts (een callback) na het versturen van bepaalde medische informatie. Op dat moment is de ABDose service een SOAP server en de pub/sub broker een SOAP client. De constructie van de SOAP client aan de pub/broker zijde ligt vast. De ABDose service of eender welke andere medische service moet met andere woorden een WSDL ter beschikking stellen met de volgende structuur:

<wsdl:portType name="CallbackInterfacePortType"> <wsdl:operation name="callback"> <wsdl:input message="tns:callback" name="callback">

<xsd:element name="callback" type="tns:callback" /> <xsd:complexType name="callback"> <xsd:sequence> <xsd:element name="patientID" type="xsd:string" /> <xsd:element name="bedID" type="xsd:string" /> <xsd:element name="data" type="xsd:base64Binary" />

EVALUATIE

75

Hoofdstuk 6

Evaluatie In dit hoofdstuk wordt het systeem geëvalueerd. Eerst wordt een algemeen overzicht en de testopstelling beschreven. Daarna volgen de effectieve experimenten met hun conclusies. Als afsluiter worden de use cases uit hoofdstuk drie verwerkt in een functionele test.

6.1

Prestatie testen

6.1.1

Opstelling

´ en van Voor de testopstelling zijn er vijf laptops aanwezig, één PDA en een draadloze router. E´ de laptops is de server (zie figuur 6.1: Server Laptop). Op deze laptop draait de Pub/Sub Broker met daarnaast ook een virtueel externe medische service, in dit geval, de ABDose Service. De PDA en de vier overblijvende laptops worden gebruikt als client. De draadloze router die in het midden van figuur 6.1 staat (Wireless Router), is niet verbonden met het internet. Er werd dus met andere woorden gekozen voor een lokale opstelling. Op die manier vormen er zich geen onregelmatige pieken in het netwerkverkeer wat netwerkvertragingen kan introduceren. Specificaties van het gebruikte materiaal: • Client Laptop 1: Intel Pentium M @ 1,73 Ghz; 512MB RAM; Windows XP (SP 3). • Client Laptop 2: Intel Core 2 Duo (T7250) @ 2.00 Ghz; 2GB RAM; Windows Vista Home Premium (SP 1).

6.1 Prestatie testen

76

PDA Client Laptop 2

Client Laptop 3

Client Laptop 1

Client Laptop 4

.

Wireless Router

Server Laptop

Figuur 6.1: Evaluatie: Opstelling • Client Laptop 3: AMD Turion X2 Dual-Core Mobile RM-70 @ 2.00 Ghz; 4GB RAM; Windows 7 Enterprise. • Client Laptop 4: Intel Core i3 (M350) @ 2,27 Ghz; 4GB RAM; Windows 7 Home Premium. • Server Laptop: Intel Core 2 Duo (T8300) @ 2,40 Ghz; 4GB RAM; Windows Vista Home Premium (SP 2). • PDA: Qualcomm 7200A @ 528 MHz; 288MB RAM; Windows Mobile 6.5 Professional. • Wireless Router: D-Link; DIR-615 Wireless N 300 Router. Op verschillende plaatsen en bij bepaalde gebeurtenissen wordt binnen het systeem de tijd geregistreerd. Op die manier kan een beeld gevormd worden van de tijd die nodig is voor een bepaalde transmissie of verwerking van data. In figuur 6.2 wordt een overzicht gegeven van de verschillende tijdsregistraties binnen het systeem. Er zijn twee tijdsassen, omdat het niet mogelijk is om de PDA te synchroniseren met de server. De bovenste as stelt de tijdsas van de server voor, de onderste as die voor de mobiele ontvanger.


ABDose sends update

23 Mijlpaalbeschrijving

Pub/Sub Broker receives update

77


Pub/Sub Broker starts sending update

23

24

25 . Mijlpaalbeschrijving


25

26

Pub/Sub Broker completes sending update

Pub/Sub Broker receives callback


Pub/Sub Broker sends callback

ABDose receives callback

27

. 22

28 25/04/2010 25/04/2010 Mijlpaalbeschrijving Mijlpaalbeschrijving

.

Mobile Receiver receives update 25/04/2010

Mobile Receiver . shows update

Mobile Receiver starts sending callback

Mobile Receiver completes sending callback 26/04/2010

Figuur 6.2: Evaluatie: Tijdsregistraties

6.1.2

Stijgend aantal services

Figuur 6.3: Multiple services: RTT In dit experiment wordt er gebruik gemaakt van één client, de PDA. De bedoeling is om de volledige RTT (round-trip time) te berekenen en dit bij een stijgend aantal medische services op de PDA. Deze medische services werden voordat het experiment plaats vond, verstuurd naar de PDA. Elke medische service is verpakt in een een aparte bundel en heeft zijn eigen tabblad. De RTT wordt berekend door het verschil te meten tussen het versturen van een nieuwe informatie update uitgaande van een medische service en een callback terugkrijgen gebaseerd op deze nieuwe informatie update (zie figuur 6.2). Het maken van een callback gebeurt automatisch. In de praktijk zal deze callback typisch pas gemaakt worden na interactie met de arts. De volgende service informatie update wordt verstuurd wanneer een callback van de vorige update succesvol werd ontvangen. Dit wordt honderd maal per experiment herhaald met de veronderstelling


78

dat de PDA online en bereikbaar is. De service informatie update die verstuurd wordt heeft bovendien een grootte van 25 kilobyte. Dit komt overeen met een informatie update die een kleine figuur als payload heeft. Het aantal services die gebruikt worden tijdens het experiment, werd logaritmisch opeenvolgend gekozen. Voor de duidelijkheid is het resultaat van dit experiment in figuur 6.3 in een lineaire schaal uitgezet. Een interessante vraag is nu waar de grootste vertraging vandaan komt. Er zijn immers drie verschillende actoren aanwezig die met elkaar communiceren over een draadloos netwerk. Wie of wat is de grootste bottleneck? Number of

P/S Broker

P/S Broker

Mobile receiver

Mobile receiver

P/B Broker

update

sending

processing

sending

callback

1

0,007

0,048

0,012

0,680

0,008

2

0,008

0,048

0,014

0,744

0,009

4

0,011

0,092

0,019

1,196

0,010

8

0,009

0,104

0,046

2,358

0,011

16

0,012

0,286

0,141

5,325

0,013

32

0,015

0,890

0,177

12,290

0,024

services

Tabel 6.1: Gemiddelde duur van de acties bij een stijgend aantal services.

Figuur 6.4: Multiple services: Wireless transmission Uit analyse (zie tabel 6.1) bleek al snel dat de gegevensoverdracht van de mobiele ontvanger naar de server de grootste bottleneck is. Figuur 6.4 verduidelijkt dit nog eens. De twee func-


79

ties in deze figuur tonen de gemiddelde duurtijd van het verzenden van een bericht aan. Er kan hieruit afgeleid worden dat de overdracht van gegevens veel intensiever is voor de mobiele applicatie bij een stijgend aantal services. Dit heeft waarschijnlijk te maken met feit dat de beperkte uitvoeringsmiddelen die de mobiele applicatie krijgt van het besturingssysteem niet verder uitbreidbaar zijn. Dit heeft een negatief effect op het maken van connecties met de server gevolgd door een gegevensoverdracht.

Figuur 6.5: Multiple services: Response Time Naast het bepalen van de RTT is het met dit experiment ook mogelijk om de ’response time’ te bepalen. Dit is de tijd die nodig is opdat de mobiele ontvanger een informatie update van een medische service kan laten tonen aan de arts. Zoals kan afgeleid worden uit figuur 6.2, is het antwoord op deze vraag niet onmiddelijk beschikbaar. De ’response time’ wordt namelijk berekend door de tijdsspanne tussen het ontvangen van het event op de client en het voltooien van de callback af te trekken van de tijd waarop de server de callback van de client heeft ontvangen. Figuur 6.5 toont het gemiddelde van het resultaat van deze berekening bij een stijgend aantal services. Deze tijd kan jammer genoeg niet nauwkeuriger bepaald worden, maar krijgt door bovenstaande berekening toch een goede indicatie. In figuur 6.5 is te bemerken dat de response time voor 1 tot 4 services ongeveer gelijk is en vanaf 8 services geleidelijk aan begint te stijgen. Vanaf acht services heeft de mobiele ontvanger iets meer tijd nodig om de binnenkomende informatie te verwerken. De response time bij 32 services is nog altijd aanvaardbaar, maar een service aantal van meer dan 16 zal in de praktijk normaal toch weinig waarschijnlijk zijn,


80

aangezien dit teniet doet aan de overzichtelijkheid van de mobiele applicatie. Conclusie: Wanneer het aantal services op de mobiele ontvanger stijgt, heeft dit veel invloed op de tijd die nodig is om een callback terug te sturen naar de Pub/Sub Broker. De response time echter, stijgt in deze situatie veel minder (slechts 0,2 s). Gewone notificaties ondervinden dus weinig invloed bij een stijgend aantal services op de PDA.

6.1.3

Stijgend aantal clients

Figuur 6.6: Multiple clients: RTT Tijdens dit experiment wordt er gebruik gemaakt van de vier client laptops om meerdere clients te laten communiceren met de Pub/Sub Broker (zie figuur 6.1). Op elke laptop worden er meerdere clients geplaatst. Bij elke client zal één medische service ge¨ınstalleerd worden die automatisch na een willekeurige wachtperiode een antwoord (callback) terug stuurt. Op die manier wordt een interactie met de arts gesimuleerd. Een client krijgt telkens 50 nieuwe informatie updates te verwerken met een payload van 25 kilobyte. De focus ligt tijdens dit experiment op de Pub/Sub Broker. Hoe presteert deze bij een verhoging van het aantal mobiele clients? Figuur 6.6 geeft het antwoord op deze vraag. Het aantal clients heeft bitter weinig effect op de RTT van het systeem. Dit komt omdat er binnen de Pub/Sub Broker gebruik gemaakt wordt van een threadpool. Hierdoor kunnen de clients gelijktijdig gecontacteerd worden, waardoor de RTT gelijklopend is voor een stijgend aantal clients. Het is natuurlijk zo dat de Pub/Sub


81

Broker op een bepaald moment zijn bovengrens zal bereiken, want een threadpool heeft een op voorhand bepaalde grootte. Wanneer dit het geval is, zijn er twee mogelijkheden. Ofwel wordt het aantal threads in de threadpool verhoogt (afhankelijk van de beschikbare hardware). Ofwel wordt het proces van het contacteren van de clients gedistribueerd (is niet ge¨ımplementeerd). Op die manier bekomt men een verzameling van werkers, die op hun beurt elk opnieuw een threadpool kunnen bevatten. Het contacteren van de server vanuit de client is quasi constant

Figuur 6.7: Multiple clients: Wireless transmission (zie figuur 6.7). Er is wel een lichte stijging aanwezig bij het contacteren van de client vanuit de server, bij een stijgend aantal clients. Dit komt omdat alle clients op vrijwel hetzelfde moment gecontacteerd worden. Doordat bijvoorbeeld een laptop bij 128 clients, zelf 48 clients zal hebben, wordt door het gelijktijdig contacteren van deze clients een kleine vertraging ge¨ıntroduceerd. In figuur 6.8 wordt de Pub/Sub Broker nog eens van nader bij bekeken. De ’Server update time’ is de tijd vanaf het moment dat een nieuwe update toekomt in de Pub/Sub Broker tot deze verstuurd wordt naar de mobiele clients. De ’Server callback time’ is de tijd vanaf het moment dat een nieuwe callback van een mobiele client toekomt in de Pub/Sub Broker tot deze verstuurd wordt naar de bijhorende medische service. De Server update time stijgt, rekening houded met de tijdsas, een klein beetje bij een stijgend aantal clients. De oorzaak van deze stijging zal terug te vinden zijn bij het aanmaken van de verschillende taken om de mobiele ontvangers te contacteren.


82

Figuur 6.8: Multiple clients: Focus on the Pub/Sub Broker Conclusie: Het aantal clients die moeten gecontacteerd worden door de Pub/Sub Broker heeft weinig effect op de round-trip time van het systeem. Er kan verder ook besloten worden dat de tijd die de Pub/Sub Broker gebruikt om gegevens (update en callback ) te verwerken lineair tot constant is.

6.1.4

Batterijverbruik

Figuur 6.9: Battery usage Om het batterijverbruik te bepalen wordt er tijdens dit experiment uiteraard gebruik gemaakt


83

Figuur 6.10: Battery usage: Time spent van de PDA. Er wordt gezocht hoelang de PDA actief kan werken. Er wordt met andere woorden een arts gesimuleerd die gedurende het volledige experiment met zijn PDA aan het werken is. Dit betekent dat de Wi-Fi en de backlight van de PDA constant aan staan. De ABDose service zal gedurende het experiment nieuwe service informatie updates versturen naar de PDA. Het mobiele toestel zal op zijn beurt door het versturen van een callback antwoorden op de updates. Wanneer de ABDose service een callback ontvangt, wacht hij een seconde en verstuurt hij vervolgens de volgende informatie update. In figuur 6.9 is het aantal events terug te vinden die het mobiel toestel bij een gegeven batterij status kon verwerken. Figuur 6.10 toont de tijd gespendeerd bij een bepaalde batterij status. Er is een duidelijke dalende trend aanwezig. Conclusie: Hoe lager de status van de batterij is, hoe minder events er verwerkt kunnen worden.

6.1.5

SMS notificatie

Bij dit laatste experiment wordt wederom de PDA als client gebruikt. Er wordt gezocht hoelang het duurt, opdat een arts een service informatie update die verstuurd werd via SMS kan verwerken. Het ontvangen van de SMS gebeurt volledige transparant voor de arts. Een event die verstuurd wordt via SMS zal enkel zijn event id sturen. Vervolgens zal het mobiel toestel de SMS opvangen, de id extraheren en vervolgens aan de Pub/Sub Broker vragen om dit event

6.2 Functionele test

84

door te sturen. Als laatste stap zal de client automatisch een callback maken. In dit experiment werden 30 SMS’en verzonden. De gemiddelde totale tijd (vanaf de service update bij de medische service tot het onvangen van de callback bij de medische service) bedroeg 8,07 seconden. De grootste hap van deze tijdspanne werd ingenomen door het verzenden van de SMS (gemiddeld 7,21 seconden). Deze tijdspanne start op het moment dat het eerste commando wordt verstuurd naar de GSM modem en stopt wanneer de GSM modem aangeeft dat de SMS succesvol werd ontvangen. Het effectief ophalen van het event aan de Pub/Sub Broker door het mobiel toestel duurde gemiddeld 0,83 seconden. In tabel 6.2 worden de verschillende duurtijden met hun minimum en maximum die tijdens dit experiment voorkwamen uitgeschreven. Totale duur

Verzenden van SMS

Ophalen van event

Gemiddeld:

8,07

7,20

0,83

Standaard deviatie:

0,25

0,26

0,05

Minimum:

7,63

6,77

0,75

Maximum:

8,50

7,60

0,91

Tabel 6.2: Tijden bij gebruik van SMS. Conclusie: Het verzenden van een SMS door de Pub/Sub Broker naar de PDA is een alternatieve push methode. Het is een vervanging en een oplossing voor wanneer de PDA via Wi-Fi niet beschikbaar is. De kost van gemiddeld 7,21 seconden is met andere woorden geoorloofd om de PDA te notificeren.

6.2

Functionele test

In deze functionele test wordt bekeken of het systeem de gewenste functionaliteit bevat zoals besproken in de use cases van hoofdstuk 3. De funtionele test wordt van uit drie perspectieven (de arts, de medische service en de bundel ontwikkelaar) besproken. Er wordt telkens verwacht dat de server (de Pub/Sub Broker) actief en online is.

6.2.1

De medische service en de bundel ontwikkelaar

1. Ontwikkel de bundel die de medische service zal voorstellen op de PDA door gebruik te maken van de Mobile Services Bundle.


85

2. Ontwikkel (indien gewenst) de callback interface van de medische service volgens de structuur beschreven in sectie 5.4. 3. Maak een SOAP request met de gewenste parameters (zie figuur 6.11). 4. Bewaar de key die werd teruggegeven (zie figuur 6.12). 5. Verstuur updates met behulp van de key en de gewenste parameters. Een bundel ontwikkelaar kan op een gelijkaardige manier, zoals hierboven besproken, nieuwe bundels aanbrengen.

6.2.2

De arts

1. Start de mobiele applicatie op. 2. Ga naar het tabblad ’Subscriptions’ (zie figuur 5.2). 3. Selecteer de medische service ’ABDose’ en vul de naam en/of bed id in van de patiënt en druk op de knop ’Subscribe’. 4. Het tabblad ’abdose’ wordt automatisch toegevoegd aan de mobiele applicatie. 5. Ga naar het tabblad ’Workshift’ (zie figuur 5.2). 6. Druk op ’Start shift’. (Vanaf dit moment zullen notificaties van de ABDose service ontvangen worden.) 7. Bij het ontvangen van een nieuwe notificatie, maak een keuze tussen ’Akkoord’ of ’Niet akkoord’ (zie figuur 5.2). 8. Ga naar het tabblad ’Subscriptions’. 9. Selecteer de voorheen gemaakte registratie en druk op ’Unsubscribe’. 10. Het tabblad ’abdose’ wordt automatisch verwijderd. 11. Ga naar het tabblad ’Workshift’ en druk op ’Stop shift’.


86

Figuur 6.11: Medical Service: register

Figuur 6.12: Medical Service: register return

CONCLUSIES

87

Hoofdstuk 7

Conclusies 7.1

Verdere ontwikkelingen

Hoewel de proof of concept volledig functioneel is, zijn er nog enkele punten waar er verbetering en verdere ontwikkeling mogelijk is. Een eerste belangrijke ontwikkeling die noodzakelijk is opdat het systeem in de praktijk zou kunnen gebruikt worden, is beveiliging. Medische data is vertrouwelijk en kan niet zomaar onbeveiligd over een draadloos netwerk verstuurd worden. Doordat het mobiele toestel deze berichten moet encrypteren en decrypteren is een symmetrische cryptografie aan te raden, aangezien asymmetrische cryptografie typisch trager is en meer rekenkracht vergt. Elk mobiel toestel heeft in dat geval zijn eigen unieke sleutel. In de praktijk kan dit ge¨ımplementeerd worden door bijvoorbeeld een SecureAbstractClient en een SecureServerResource aan te maken (zie figuur 5.3). Vervolgens is het ook belangrijk om bij het verder ontwikkelen van de mobiele applicatie, feedback te krijgen van de artsen m.b.t. de GUI. Het zijn tenslotte zij die elke dag met de applicatie in contact zullen komen. De belangrijkste componenten zijn momenteel aanwezig in de GUI, maar deze kan een verfraaiing gebruiken. Op dit moment is het bovendien zo dat elke (medische en interne) service een eigen tabblad op de mobiele applicatie krijgt. Bij een groot aantal tabbladen wordt dit echter onoverzichtelijk en minder intu¨ıtief om mee te werken. Een mogelijke oplossing voor dit probleem is bepaalde medische services die enkel notificaties versturen en geen feedback vragen, samen in één tabblad te plaatsen. Alle nodige GUI-elementen zijn, doordat er gebruik gemaakt wordt van Thinlet, aanwezig.

7.2 Algemeen Besluit

88

De mobiele applicatie voorziet voor de services ook een kleine interne datastore om data persistent in op te slaan (zie figuur 4.13 van het architectuur hoofdstuk). Op dit moment wordt deze data per service uitgeschreven naar een bestand (serviceName.datastore). Het inlezen en uitschreven van en naar de bestanden gebeurt op dit moment bij het opstarten (BundleActivator.start) en stoppen (BundleActivator.stop) van de applicatie. Doordat de mobiele applicatie in principe elk moment afgesloten kan worden (batterij komt los bij het laten vallen van het mobiele toestel of het mobiel toestel valt uit doordat de batterij leeg is), is het aan te raden om dit in te toekomst te vervangen door een continue implementatie. Het is ook interessant om het systeem uitgebreider te testen met een groter aantal clients. Er worden echter geen grote vertragingen verwacht in de interne werking van de Pub/Sub Broker, maar wel tijdens het contacteren van de mobiele toestellen. Doordat er gebruik gemaakt wordt van een threadpool met taken voor het contacteren van de mobiele toestellen, is er sowieso een limiet voor het aantal clients die tegelijkertijd kunnen gecontacteerd worden. Het is in de toekomst zeker mogelijk dat deze taken, wanneer ze door de wachtlijn voor de threadpool te veel vertraagd worden, gedistribueerd kunnen worden. Een laatste interessant gegeven voor toekomstige ontwikkelingen is te onderzoeken welke bijdrage Mobile IPv6 [106] kan leveren aan het push systeem. Mobile IPv6 laat immers toe dat een IPv6 client willekeurig van locatie in het netwerk kan veranderen, terwijl het nog steeds de bestaande verbindingen behoudt.

7.2

Algemeen Besluit

Het doel van deze masterproef bestond er in te kijken hoe medische berichten en nieuwe software updates op een PDA kunnen ontvangen worden via asynchrone berichtgeving. Uit het stateof-the-art onderzoek bleek dat de combinatie van Windows Mobile, Java ME CDC en OSGi (Apache Felix), het beste framework was, aangezien het voldeed aan de vereisten en waarmee een optimaal onderzoek kon plaats vinden naar de prestatie van het systeem. Ge¨ıntegreerde tools die het ontwikkelen van native code eenvoudiger moeten maken, zijn echter niet aanwezig voor een Windows Mobile en Java ME CDC combinatie. De Java Native Access bibliotheek en de mogelijkheid om een nieuwe bundel at runtime toe te voegen in een OSGi container boden een waardig alternatief. De ontwikkelde proof of concept ondersteunt twee verschillende soorten push methodes. Een

7.2 Algemeen Besluit

89

pure push methode en een hybride push methode. De pure push methode wordt mogelijk gemaakt doordat de mobiele applicatie een mini webserver voorziet. Bij gebruik van de hybride methode daarentegen wordt eerst een SMS verstuurd, waarna het gewenste event op initiatief van de mobiele ontvanger wordt opgehaald. Deze hybride methode wordt in twee situaties aangewend. Ofwel is het mobiel toestel tijdelijk onbereikbaar, ofwel werd de Wi-Fi moedwillig door de mobiele applicatie in een standby modus geplaatst. Doordat het programma bovendien generiek is opgebouwd, kan het ook gebruikt worden in elke context waar er nood is aan een push systeem in een mobiele omgeving. Vervolgens werd er ook specifiek aandacht geschonken aan de eenvoud om het systeem uit te breiden met nieuwe services. In dat opzicht is het systeem een framework waarmee nieuwe services eenvoudig kunnen ontwikkeld worden. Dit is mogelijk door de combinatie van OSGi en de beschikbare abstracte klassen (zie AbstractServerService in figuur 4.7 en voor de mobiele applicatie o.a. TabService en BackgroundService in figuur 4.13). Er kan besloten worden dat de ontwikkelde oplossing een grote toegevoegde waarde kan hebben als uitbreiding van het huidig ICSP platform, om de artsen van service updates op hun PDA te voorzien.

BIBLIOGRAFIE

90

Bibliografie [1] M. J. Yuan, Enterprise J2me: Developing Mobile Java Applications, Prentice Hall PTR, 2003 [2] N. Bartlettn, OSGi in Practice, http://neilbartlett.name/blog/osgibook/, 2009 [3] E. A Oliver, Survey of platforms for mobile networks research, SIGMOBILE Mob. Comput. Commun. Rev. 12, 4 (Feb. 2009), 56-63. [4] M. Hauswirth and M. A Jazayeri, Component and communication model for push systems, SIGSOFT Softw. Eng. Notes 24, 6 (Nov. 1999), 20-38 [5] Y. Huang and H. Garcia-Molina, Publish/subscribe in a mobile environment, Wirel. Netw. 10, 6 (Nov. 2004), 643-652. [6] M. Hauswirth and M. Jazayeri,A Component and Communication Model for Push Systems, ACM SIGSOFT Software Engineering Notes, Volume 24 Issue 6, (Oct. 1999) [7] I. Podnar, M. Hauswirth and M. Jazayeri, Mobile push: delivering content to mobile users, (2002), 563-568 [8] M. Borges, A. N. Ribeiro and J. C. Campos, A push infrastructure for mobile application deployment in mobile environments, CSMU EEng/UM, (June 2006), 175178 [9] I. Podnar and I. Lovrek, Supporting Mobility with Persistent Notifications in Publish/Subscribe Systems, In Proc. of the 3rd Int. Workshop on Distributed Event Based Systems, 2004 [10] J. Cao, X. Feng, J. Lu, H. Chan and S. K. Das, Reliable Message Delivery for Mobile Agents: Push or Pull, Ninth International Conference on Parallel and Distributed Systems (ICPADS’02), (2002), 314

BIBLIOGRAFIE

91

[11] J. Sharkey, Google I/O: Coding for Life - Battery Life, That Is, http://code.google.com/ events/io/2009/sessions/CodingLifeBatteryLife.html, 2009 [12] J.

L.

Pratt,

Mobile

software

platform

comparison

worksheet,

http://

creativealgorithms.com/mobile_software_platforms.pdf, 2009 [13] Carnegie Mellon CyLab Mobility Research Center, Mobile development survey project, http://mobiledevelopers.pbworks.com/f/ExecSummaryFinal.pdf, 2009 [14] Canalys, Smart phones defy slowdown, http://www.canalys.com/pr/2009/r2009081. htm, 2009 [15] Apple, iPhone Dev Center, http://developer.apple.com/iphone/ [16] A. Wokke, Nieuwe iPhones niet meer te jailbreaken, http://tweakers.net/nieuws/ 63075/nieuwe-iphones-niet-meer-te-jailbreaken.html, 2009 [17] G. Van Der Zwaag, Installer voor beginners: jailbreak, repo’s en meer, http://www. iphoneclub.nl/10844/installer-voor-beginners-jailbreak-repos-en-meer/, 2008 [18] Android Developers, http://developer.android.com [19] S. Conder, Android: A Brief Introduction, http://www.developer.com/ws/article.php/ 3763991/Android-A-Brief-Introduction.htm, 2008 [20] Open Handset Alliance, http://www.openhandsetalliance.com/ [21] M. Gijzemijter, Android dwingt telefoniemarkt tot veranderingen, http://webwereld.nl/ nieuws/52847/android-dwingt-telefoniemarkt-tot-veranderingen.html, 2008 [22] E. Burnette, Java vs. Android APIs, http://blogs.zdnet.com/Burnette/?p=504, 2008 [23] D. Bornstein, Google I/O: Dalvik VM Internals, http://sites.google.com/site/io/ dalvik-vm-internals, 2008 [24] Symbian Developer Network, http://developer.symbian.com/main [25] Symbian Foundation Community, http://www.symbian.org/ [26] Windows Mobile voor ontwikkelaars, http://developer.windowsphone.com

BIBLIOGRAFIE

92

[27] Microsoft Corporation, What’s New in Naming Conventions for Windows Mobile 6, http: //msdn.microsoft.com/en-us/library/bb158525.aspx, 2009 [28] Microsoft Corporation, .NET Compact Framework, http://msdn.microsoft.com/en-us/ netframework/aa497273.aspx [29] D. Barnes, Fundamentals of Microsoft .NET Compact Framework Development for the Microsoft .NET Framework Developer, http://msdn.microsoft.com/en-us/library/ aa446549.aspx, 2003 [30] BlackBerry Developer Zone, http://na.blackberry.com/eng/developers/ [31] RIM Company, http://www.rim.com/ [32] BlackBerry Code Signing Keys, https://www.blackberry.com/SignedKeys/ [33] E. Giguere, Technical Articles, http://www.ericgiguere.com/articles/index.html [34] CDC: Java Platform technology for connected devices, http://java.sun.com/javame/ technology/cdc/cdc_whitepaper.pdf, 2005 [35] Java ME at a Glance, http://java.sun.com/javame/index.jsp [36] JSR 271: Mobile Information Device Profile 3, http://jcp.org/en/jsr/detail?id=271 [37] Java ME on Symbian OS, http://developer.symbian.org/wiki/index.php/Java_ME_ on_Symbian_OS [38] Sony Ericsson Mobile, Getting started with Jav CDC development, http://www. blueboard.com/javame/pdf/guide_sip_gsg_javame_cdc_r1a.pdf, 2006 [39] Flash Lite, http://www.adobe.com/products/flashlite/ [40] Enough Software, Mobile Developer’s Guide tothe Galaxy, http://www1.j2mepolish.org/ downloads/MobileDevelopersGuideToTheGalaxy.pdf, 2009 [41] Nokia, Web Runtime widgets, http://www.forum.nokia.com/Technology_Topics/Web_ Technologies/Web_Runtime/ [42] Eclipse Foundation, embedded Rich Client Platform, http://www.eclipse.org/ercp/

BIBLIOGRAFIE

93

[43] ICEsoft Technologies, ICEfaces J2EE Ajax project, http://www.icefaces.org/main/ home/ [44] JavaFX Mobile, http://www.sun.com/software/javafx/mobile/index.jsp [45] P. Bakker, JavaFX: Klaar om de wereld te veroveren?, http://www.infosupport.com/ Java_FX_Paul_Bakker, 2008 [46] JSR 209: Advanced Graphics and User Interface Optional Package for the J2ME Platform, http://jcp.org/en/jsr/detail?id=209 [47] B. Hopkins, The Java ME GUI APIs at a Glance, http://developers.sun.com/mobility/ midp/articles/guiapis/index.html, 2007 [48] R. Bajzat, Thinlet GUI Toolkit, http://thinlet.sourceforge.net/home.html, 2006 [49] Openmoko, http://www.openmoko.com/ [50] LiMo Foundation, http://www.limofoundation.org/ [51] Maemo, http://maemo.org/ [52] Access, Acquisition broadens ACCESS product portfolio, http://www.access-company. com/news/press/PalmSource/2005/090905_access.html, 2005 [53] Palm Developer Center, http://developer.palm.com/ [54] R. Kairer, Palm Announces the Palm webOS, http://www.palminfocenter.com/news/ 9666/palm-announces-the-palm-webos/, 2009 [55] WebOS Internals, http://www.webos-internals.org/wiki/Main_Page [56] Qualcomm

Brew

Developers,

http://brew.qualcomm.com/brew/en/developer/

overview.html [57] OSGi Alliance, http://www.osgi.org/ [58] Luminus, OSGi: dynamische modules voor Java, http://osgi.nl/introductie.data/ OSGiIntro.pdf, 2007 [59] H. Van Thiel, Open standaard in Java, http://www.computable.nl/artikel/ict_ topics/development/1327620/1277180/open-standaard-in-java.html, 2005

BIBLIOGRAFIE

94

[60] OSGi Alliance, OSGi Service Platform Mobile Specifications, http://www.osgi.org/ Markets/Mobile [61] JSR

232:

Mobile

Operational

Management,

http://www.osgi.org/JSR232/

HomePageenhttp://jcp.org/en/jsr/detail?id=232 [62] D. Beers, Is OSGi the Solution for Mobile Java?, http://www.infoq.com/news/2007/05/ osgi-javame, 2007 [63] Sprint Applications Developers, http://developer.sprint.com/site/global/home/p_ home.jsp [64] Sprint, http://www.sprint.com [65] Apache Software Foundation, Apache Felix, http://felix.apache.org/ [66] Knopflerfish, Knopflerfish Project, http://www.knopflerfish.org/ [67] Eclipse Foundation, Equinox, http://www.eclipse.org/equinox/ [68] IKS, ETH Zurich, Concierge, http://concierge.sourceforge.net/ [69] IBM, Lotus Expeditor enables client integration, http://www.ibm.com/software/lotus/ products/expeditor/ [70] JSR 277: Java Module System, http://jcp.org/en/jsr/detail?id=277 [71] JSR 118: Mobile Information Device Profile 2.0, http://jcp.org/en/jsr/detail?id=118 [72] Google

Web

Toolkit,

ServerPushFAQ,

http://code.google.com/p/

google-web-toolkit-incubator/wiki/ServerPushFAQ, 2007 [73] Push technology, http://en.wikipedia.org/wiki/Push_technology [74] J. Van Den Broecke, Pushlets, http://www.pushlets.com/doc/whitepaper-all.html, 2005 [75] S. M. Greene, Client Pull/Server Push, http://docs.rinet.ru/HTMLnya/ch38.htm, 2000 [76] W3C, Server-Sent Events, http://dev.w3.org/html5/eventsource/, 2010

BIBLIOGRAFIE

95

[77] R. Strahl, Handling long Web Requests with Asynchronous Request Processing, http: //www.west-wind.com/presentations/wwAsyncWebRequest/wwAsyncWebRequest.htm, 2001 [78] Dojo Foundation, The Bayeux Specification, http://svn.cometd.com/trunk/bayeux/ bayeux.html, 2007 [79] Dojo Foundation, CometD Project, http://cometdproject.dojotoolkit.org/ [80] Jetty Cometd client and server for Java, http://code.google.com/p/cometd/wiki/ CometdJetty [81] JavaScript Object Notation, http://www.json.org/ [82] Palo Wireless, WAP Push Services, http://www.palowireless.com/wap/wappush.asp [83] Push Proxy Gateway, http://en.wikipedia.org/wiki/Push_Proxy_Gateway [84] Jabber, http://www.jabber.org/ [85] XMPP Standards Foundation, http://xmpp.org/ [86] Google, Google Wave, http://wave.google.com [87] H. Schulzrinne, XMPP, http://www.cs.columbia.edu/~hgs/teaching/ais/slides/ xmpp.ppt, 2009 [88] Mobile XMPP, http://www.deepdarc.com/2008/02/14/mobile-xmpp/, 2008 [89] Wireless Messaging API (WMA): JSR 120 and JSR 205, http://java.sun.com/products/ wma/index.jsp [90] H. Schulzrinne, Session Initiation Protocol, http://www.cs.columbia.edu/sip/, 2008 [91] JSR 180: SIP API for J2ME, http://www.jcp.org/en/jsr/detail?id=180 [92] Q. H. Mahmoud, Getting Started with SIP API for J2ME, http://developers.sun.com/ mobility/apis/articles/sip/,2004 [93] E. Ortiz, The MIDP 2.0 Push Registry, http://developers.sun.com/mobility/midp/ articles/pushreg/, 2003

BIBLIOGRAFIE

[94] P. McLean,

96

Apple begins stress testing iPhone 3.0 push notifications,

http:

//www.appleinsider.com/articles/09/05/18/apple_begins_stress_testing_ iphone_3_0_push_notifications.html, 2009 [95] XMPP Standards Foundation,

XEP-0060:

Publish-Subscribe,

http://xmpp.org/

extensions/xep-0060.html, 2010 [96] Microsoft Corporation, Understanding Direct Push, http://technet.microsoft.com/ en-us/library/aa997252.aspx, 2009 [97] Blackberry,

Java

Application

Development,

http://na.blackberry.com/eng/

developers/javaappdev/ [98] Blackberry,

BlackBerry Push APIs,

http://na.blackberry.com/eng/developers/

javaappdev/BlackBerry_Push_APIs_Whitepaper.pdf, 2008 [99] Tech At Play, The difference between Windows Mobile and BlackBerry push email, http: //www.techatplay.com/?p=482, 2009 [100] Mysaifu JVM, http://www2s.biglobe.ne.jp/~dat/java/project/jvm/index_en.html [101] NSIcom, Creme, http://www.nsicom.com/Default.aspx?tabid=295 [102] D. Preuveneers, phoneME for Windows CE, PocketPC and Windows Mobile, http:// www2.cs.kuleuven.be/~davy/phoneme/public/index.htm [103] Apache Software Foundation, Apache CXF, http://cxf.apache.org/, 2010 [104] F.

Andriano,

http://blog.jservlet.com/post/2008/01/27/

Object-SMS-send-and-receive-SMS-from-GSM-card-SIM-with-JAVA-Communication-API, 2008 [105] Apache Software Foundation, Apache Derby, http://db.apache.org/derby/, 2010 [106] The Internet Engineering Task Force, Mobility EXTensions for IPv6 (mext), http:// datatracker.ietf.org/wg/mext/charter/

LIJST VAN FIGUREN

97

Lijst van figuren 2.1

Overzicht state-of-the-art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.2

OSGi architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10

2.3

OSGi bundel levenscyclus [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

2.4

Pollling en Server Push in een Ajax (browser) omgeving . . . . . . . . . . . . . .

23

2.5

Resultaten state-of-the-art onderzoek . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.1

Main system: ICSP Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

4.2

Subsystem: Pub/Sub Broker, Interfaces . . . . . . . . . . . . . . . . . . . . . . .

38

4.3

Subsystem: Pub/Sub Broker, Components . . . . . . . . . . . . . . . . . . . . . .

39

4.4

Subsystem: Pub/Sub Broker, EventAdmin . . . . . . . . . . . . . . . . . . . . . .

41

4.5

Subsystem: Pub/Sub Broker, Module Datastore: entities . . . . . . . . . . . . . .

42

4.6

Subsystem: Pub/Sub Broker, Module Datastore: fa¸cades . . . . . . . . . . . . . .

42

4.7

Subsystem: Pub/Sub Broker, Medical and Internal Services Module . . . . . . .

43

4.8

Subsystem: Pub/Sub Broker, Mobile Communications Module . . . . . . . . . .

45

4.9

Subsystem: Mobile Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

4.10 Subsystem: Mobile Receiver, Components . . . . . . . . . . . . . . . . . . . . . .

47

4.11 Subsystem: Mobile Receiver, Interfaces . . . . . . . . . . . . . . . . . . . . . . . .

48

4.12 Subsystem: Mobile Receiver, Display Module . . . . . . . . . . . . . . . . . . . .

49

4.13 Subsystem: Mobile Receiver, TabServices Module . . . . . . . . . . . . . . . . . .

50

LIJST VAN FIGUREN

98

4.14 Sequence Diagram Medical Data (a) . . . . . . . . . . . . . . . . . . . . . . . . .

51

4.15 Sequence Diagram Medical Data (b) . . . . . . . . . . . . . . . . . . . . . . . . .

52

4.16 Sequence Diagram: internalCall . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

4.17 Sequence Diagram: registerService . . . . . . . . . . . . . . . . . . . . . . . . . .

54

4.18 Sequence Diagram: postUpdateData . . . . . . . . . . . . . . . . . . . . . . . . .

54

4.19 Sequence Diagram: updateBundle . . . . . . . . . . . . . . . . . . . . . . . . . .

55

4.20 Sequence Diagram: Mobile Communications, BundleEvent . . . . . . . . . . . . .

57

4.21 Sequence Diagram: postEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

4.22 Deployment View: Main System . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

4.23 Component View: Pub/Sub Broker bundle dependencies . . . . . . . . . . . . . .

59

4.24 Component View: Mobile Receiver bundle dependencies . . . . . . . . . . . . . .

60

5.1

Maven modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

62

5.2

GUI van mobiele ontvanger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

5.3

Architectuur Binair REST protocol . . . . . . . . . . . . . . . . . . . . . . . . . .

71

5.4

De Mobiele Ontvanger contacteren . . . . . . . . . . . . . . . . . . . . . . . . . .

72

6.1

Evaluatie: Opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

6.2

Evaluatie: Tijdsregistraties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

6.3

Multiple services: RTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

6.4

Multiple services: Wireless transmission . . . . . . . . . . . . . . . . . . . . . . .

78

6.5

Multiple services: Response Time . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

6.6

Multiple clients: RTT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

80

6.7

Multiple clients: Wireless transmission . . . . . . . . . . . . . . . . . . . . . . . .

81

6.8

Multiple clients: Focus on the Pub/Sub Broker . . . . . . . . . . . . . . . . . . .

82

6.9

Battery usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

82

6.10 Battery usage: Time spent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

LIJST VAN FIGUREN

99

6.11 Medical Service: register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

6.12 Medical Service: register return . . . . . . . . . . . . . . . . . . . . . . . . . . . .

86

LIJST VAN TABELLEN

100

Lijst van tabellen 2.1

Vijf besturingssystemen en hun mogelijkheden [3] . . . . . . . . . . . . . . . . . .

9

6.1

Gemiddelde duur van de acties bij een stijgend aantal services. . . . . . . . . . .

78

6.2

Tijden bij gebruik van SMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

Medische gegevensuitwisseling met mobiele applicaties

Recommend Documents