Cloud-enabled software framework voor on-the-move Augmented Reality

Cloud-enabled software framework voor on-the-move Augmented Reality Pieter Bonte

Promotoren: prof. dr. ir. Filip De Turck, dr. ir. Bruno Volckaert 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 en Architectuur Academiejaar 2012-2013

Cloud-enabled software framework voor on-the-move Augmented Reality Pieter Bonte

Promotoren: prof. dr. ir. Filip De Turck, dr. ir. Bruno Volckaert 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 en Architectuur Academiejaar 2012-2013

iv

Voorwoord De zoektocht naar een onderwerp voor mijn masterproef verliep vlotter dan verwacht. Mijn fascinatie voor cloud computing is altijd al groot geweest. Toen ik dit onderwerp ontdekte dat cloud computing wou combineren met meer exotische technieken als Augmented Reality was ik meteen verkocht. Deze masterproef was dan ook heel verruimend en zeker een meerwaarde voor mijn opleiding. Graag wil ik van de gelegenheid gebruik maken om enkele mensen te bedanken. Eerst en vooral wil ik mijn promotoren prof. dr. ir. Filip. De Turck en dr. ir. Bruno Volckaert bedanken om deze masterproef mogelijk te maken. Grote dankbaarheid gaat uit naar mijn begeleiders, ir. Wannes Kerckhove en ir. Thomas Dupont, om mij door heel het verloop van deze masterproef bij te staan. Mijn ouders wens ik in het bijzonder te bedanken om mij de kans te geven deze studie te beginnen en mij doorheen de jaren te steunen. Een speciaal woord van dank gaat uit naar mijn vriendin, Charlotte, die altijd waakte over de beperkte tijd tussendoor. Tot slot bedank ik mijn goede vrienden voor de memorabele studententijd. Pieter Bonte, mei 2013

v

vi

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.”

Pieter Bonte, mei 2013

vii

ix

Cloud-enabled software framework voor on-the-move Augmented Reality door Pieter BONTE Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2012–2013 Promotoren: prof. dr. ir. F. DE TURCK & dr. ir. B. VOLCKAERT Begeleiders: ir. W. KERCKHOVE & ir. T. DUPONT Faculteit Toegepaste Wetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. D. DE ZUTTER

Samenvatting De toenemende rekenkracht in mobiele apparaten laat toe steeds meer geavanceerde applicaties te bouwen. Deze applicaties kunnen genieten van de bewegingsvrijheid die gepaard gaat met het gebruik van een mobiel toestel. Augmented Reality-applicaties die interageren met de omgeving stijgen daarom in populariteit. Deze masterproef onderzoekt hoe een modulair en dynamisch framework kan worden aangeboden dat toelaat Augmented Reality-applicaties te bouwen. Wegens de stijgende populariteit van cloud computing voorziet het framework een naadloze integratie met de cloud waarbij maatregelen worden getroffen op vlak van Availability en Scalability.

Trefwoorden Augmented Reality, Cloud computing, OSGi, Load Balancing

x

Cloud-enabled software framework voor on-the-move Augmented Reality Pieter Bonte Supervisor(s): prof. dr. dr. Filip De Turck, dr. ir. Bruno Volckaert, ir. Wannes Kerckhove, ir. Thomas Dupont Abstract— The computational increase in mobile devices leads to more advanced programs. These application can take advantage of freedom of movement which accompanies the use of a mobile device. Augmented Reality applications that interact with their environment therefore increase in popularity. In this article, an Augmented Reality framework is presented allowing to create Augmented Reality applications that can be integrated in a cloud environment. Therefore precautions have been taken to provide Scalability and Availability in these applications. Keywords— Augmented Reality, Cloud computing, OSGi, Load Balancing

modularity on top of the standard Java environment. It allows to define loosely coupled components, called bundles, that can be combined to form a whole. Each of these bundles can be started, stopped and updated, even at runtime. Each bundle can provide multiple services, these services can be registered so other bundles can make use of them. It’s even possible to use remote services, which are registered in another OSGi project. B. Structure

I. I NTRODUCTION

T

HE increasing demand for Augmented Reality applications has lead to numerous frameworks built to create such applications. Unfortunately, these frameworks have shown some serious shortcomings. They are built for a specific set of applications and do not allow the developer to extend the framework to fulfill his desired goals. Nor is it possible to introduce one’s own functionality. Also, the rising popularity of cloud computing has not yet reached the functionality of these frameworks. Nevertheless, offloading complex and intensive calculation to a cloud service would increase the performance and battery lifetime of the mobile devices on which these applications are ought to run. In this research a dynamic and modular framework for the creation of Augmented Reality applications is introduced. Precautions have been made to allow a fluent integration with the cloud. II. S OLUTION The proposed framework can be seen as a construction kit from which the necessary components for building the Augmented Reality application can be selected. The framework, which serves as a basic structure for these applications can be easily extended and adapted. It consists of a number of well defined components who have been provided with a standard implementation. These components can be extended and new implementations can be used. When the need arises, new types of components can be added to the framework. A high level of modularity [1] is obtained by separating definitions and implementations of these components, using well defined interfaces. To allow a fluent integration with the cloud, precautions have been made in terms of Scalability and Availability. The framework also proposes the choice to integrate extra functionality at the client side or to load it off to the server. A. Technology To meet the modularity requirements of the framework, OSGi is used. OSGi [2] introduces an extra layer of dynamics and

The framework is split in four subsystems: the clients, a load balancer, the servers and a datasystem. The client is the subsystem that runs on the device of the user. The load balancer fulfills the scalability and availability demands. The server is used to compute complex calculations and forms an access point to the datasystem. Figure 1 shows a schematic representation.

Client

*

Load Balancer

1

1

*

Server

*

1

Data systeem

Fig. 1. Structure of the framework

B.1 Client The client subsystem is built based on the Microkernel pattern [3]. This allows for easy extension of the client subsystem, if needed. However, there are already a number of predefined building-block components to facilitate the implementation of a typical Augmented Reality scenario. There is a ServiceContainer component which also presents itself at the server side. This leaves the choice to use the same functionality at the client side or at the server side. The interactions between these different components can be defined in the core of the Microkernel. And because only component definitions have to be known in advance, different implementations can be used. B.2 Load balancer The load balancer subsystem makes sure the scalability and availability demands are met. The load balancer talks to multiple servers, allowing the server load to be distributed amongst them. It also prevents the failure of one server affecting the whole system. Each client and server subsystem will register itself with the load balancer. This enables the load balancer to capture a global view of the available subsystems. This is possible by using OSGi remote services. The load balancer keeps a list of client and server information and their offered services. This way, newly registered clients are provided with

4500

4000 3500 3000 time (ms)

a well suited server. There are however several options to select this server [4]. To support multiple implementations, the selection mechanism is provided as a separate interface allowing different load balancing techniques. When a server fails, the load balancer will detect this failure and provide the clients who were currently using this server with a new one.

2500 2000

without server failure

1500

with server failure

1000

500

B.3 Server

0 156

The server subsystems is used to perform heavy computations or to extract information. It is also built on the Microkernel pattern, which allows the subsystem to be easily extended. The requirements of the server subsystem are rather limited because it depends on the expected functionality of the actual application. This illustrates the extensible characteristic of the Microkernel pattern. When the need arises for specific components, they can be easily introduced. The server subsystem still contains a few basic components: a component to interact with the datasystem, the same ServiceContainer to allow the introduction of extra functionality and a communication component. Services in the ServiceContainer can be registered to the communication component to make them usable for the clients.

312

625 1250 2500 5000 10000 20000 #clients

Fig. 2. Evaluation communicationsystem

IV. F UTURE WORK Although the framework has many advantages, there is still room for improvement. As it is now, the load balancer itself forms an availability risks, because it contains a lot of useful information that is not shared among other subsystems. If the load balancer fails, new clients will not be able to receive a server. As such, future research will first have to focus on improving this situation. V. C ONCLUSION

C. Communication mechanism The framework proposes an elaborated communication mechanism which consist of the communication component at the client side and the functionality in the load balancer. The client takes precautions when communicating with a server. To prevent the scenario that a call to the server gets lost because the server fails, the client stores the calls locally until a response is retrieved. This is possible by using Java Reflections [5]. The client proposes various ways to communicate safely with the server. Both synchronous, as asynchronous calls are possible. If the server fails while executing a call to the server, the load balancer will detect this failure and provide the client with a new server. When the client receives this server, all the stored calls will be executed again. III. E VALUATION To evaluate the scalability of the proposed system a distinction in response time is measured in a system with only one server and a system with a load balancer and multiple servers, with an increasing number of clients. As a result, it can be found that the server workload can be perfectly divided over the number of servers when using a load balancer. To evaluate the extended availability a test is performed where the server fails during a method invocation. The difference between the scenario where the server does and does not failed is shown in figure 2. The response time increases with the number of clients because each client, that used the failed server, needs to be reassigned a new server. Despite of the increase in response time, all requests are properly executed. If the communication mechanism would not be used, the requests would be lost.

The proposed framework for building Augmented Reality applications in this master thesis has a high level of extensibility so it can easily be expanded to meet the developers needs. Furthermore, a high level of modularity is reached, allowing multiple implementations and easy updates, even at runtime. The provided communication mechanism has many advantages to cope with unreliable servers. The proposed Augmented Reality framework can help spur the growth of more complex Augmented Reality applications for mobile devices and support them in offloading heavy calculations to the ever more important cloud. ACKNOWLEDGMENTS The author would like to acknowledge the suggestions of the supervisors prof. dr. ir. Filip De Turck, dr. ir. Bruno Volckaert, ir. Wannes Kerckhove and ir. Thomas Dupont. R EFERENCES [1] K. J. Sullivan, W. G. Griswold, Y. Cai, and B. Hallen, The structure and value of modularity in software design, SIGSOFT Softw. Eng. Notes, vol. 26, pp. 99-108, Sept. 2001. [2] The OSGi Alliance, OSGi service platform core specification, release 4.3, 2011. [3] L. Bass, P. Clements, and R. Kazman Software architecture in practice., Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1998. [4] W. Tarreau, Making applications scalable with load balancing, 2006. [5] Oracle, Java reflection., http://docs.oracle.com/javase/6/docs/technotes/ guides/reflection/, 3 2013.

Inhoudsopgave 1 Inleiding 1.1 Probleemstelling . . . . . . . . 1.2 Voorgestelde oplossing . . . . . 1.3 Verkennen domein . . . . . . . 1.3.1 Augmented Reality . . . 1.3.2 Cloud computing . . . . 1.4 Use case . . . . . . . . . . . . . 1.5 Overzicht van de hoofdstukken .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

2 Specificatie 2.1 Bestaande frameworks . . . . . . . . . . . . . . . . . . . . 2.1.1 Mixare . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Metaio . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 KHARMA . . . . . . . . . . . . . . . . . . . . . . . 2.1.4 Vuforia . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.5 Besluit . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Functionele vereisten . . . . . . . . . . . . . . . . . . . . . 2.2.1 Algemene vereisten van het framework . . . . . . . 2.2.2 Specifieke vereisten van de client . . . . . . . . . . 2.2.3 Specifieke vereisten van de server . . . . . . . . . . 2.3 Kwaliteitsattributen . . . . . . . . . . . . . . . . . . . . . 2.3.1 Kwaliteitsattributen met betrekking tot het volledig 2.3.2 Server specifieke kwaliteitsattributen . . . . . . . . 3 State of the art 3.1 Cloud computing . . . . . . . . . . . . . . . . 3.1.1 Schaalbaarheid . . . . . . . . . . . . . 3.1.2 Availability . . . . . . . . . . . . . . . 3.1.3 Load balancing . . . . . . . . . . . . . 3.2 Modulaire raamwerken . . . . . . . . . . . . . 3.2.1 OSGi . . . . . . . . . . . . . . . . . . . 3.2.2 Alternatieven . . . . . . . . . . . . . . 3.3 Gedistribueerde technologieën en raamwerken 3.3.1 SOA . . . . . . . . . . . . . . . . . . . 3.3.2 Java RMI . . . . . . . . . . . . . . . . 3.3.3 CORBA . . . . . . . . . . . . . . . . . xi

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . .

1 1 2 2 2 3 4 5

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . framework . . . . . . .

7 7 7 7 8 8 8 8 8 9 10 10 10 11

. . . . . . . . . . .

13 13 13 14 16 17 17 20 23 23 23 24

. . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

Inhoudsopgave

xii . . . . .

24 25 25 26 27

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

29 29 30 31 31 32 36 39 39 41 41 43 44 48

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

49 49 50 50 51 51 52 52 52 53 54 54 55 55 55 58 58 60 60 61

6 Evaluatie 6.1 Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Gebruikte infrastructuur . . . . . . . . . . . . . . . . . . . . . .

63 63 63

3.4

3.5

3.3.4 Web services . . . . . . . . Augmented Reality technologieën 3.4.1 Marker detectie . . . . . . 3.4.2 Locatie bepaling . . . . . Besluit . . . . . . . . . . . . . . .

4 Architectuur 4.1 Algemeen . . . . . . . . . . . . 4.1.1 Componenten overzicht . 4.1.2 Communicatie overzicht 4.2 Client . . . . . . . . . . . . . . 4.2.1 Componenten overzicht . 4.2.2 Communicatie overzicht 4.3 Server . . . . . . . . . . . . . . 4.3.1 Componenten overzicht . 4.3.2 Communicatie overzicht 4.4 De load balancer . . . . . . . . 4.4.1 Componenten overzicht . 4.4.2 Communicatie overzicht 4.5 Besluit . . . . . . . . . . . . . .

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

. . . . .

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

. . . . .

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

. . . . .

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

. . . . .

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

. . . . .

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

5 Implementatie 5.1 Specifieke OSGi-technieken . . . . . . . . . 5.1.1 De OSGi ServiceTracker . . . . . . 5.1.2 De OSGi ServiceRegistration . . . . 5.2 Ontdekking van services . . . . . . . . . . 5.2.1 OSGi Discovery . . . . . . . . . . . 5.2.2 Configuratie . . . . . . . . . . . . . 5.3 Aanbieden en detecteren van services . . . 5.3.1 Server . . . . . . . . . . . . . . . . 5.3.2 Client . . . . . . . . . . . . . . . . 5.4 Load balancer . . . . . . . . . . . . . . . . 5.4.1 Registratie services . . . . . . . . . 5.5 Client . . . . . . . . . . . . . . . . . . . . 5.5.1 Bewaren methode . . . . . . . . . . 5.5.2 Oproepen van methoden . . . . . . 5.5.3 Een voorbeeld . . . . . . . . . . . . 5.6 Use Case . . . . . . . . . . . . . . . . . . . 5.6.1 Afbeelden van virtuele objecten . . 5.7 Integratie met de Cloud . . . . . . . . . . 5.7.1 Amazon EC2 Command Line Tool

. . . . .

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

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

. . . . .

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

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

. . . . .

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

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

. . . . .

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

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

. . . . .

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

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

. . . . .

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

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

. . . . .

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

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

. . . . .

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

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

. . . . .

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

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

. . . . .

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

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

. . . . .

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

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

. . . . .

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

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

. . . . .

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

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

. . . . .

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

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

. . . . .

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

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

Inhoudsopgave

6.2

6.3

6.1.2 De server werklast Scenarios . . . . . . . . . . 6.2.1 Scenario 1 . . . . . 6.2.2 Scenario 2 . . . . . 6.2.3 Scenario 3 . . . . . 6.2.4 Scenario 4 . . . . . 6.2.5 Scenario 5 . . . . . Besluit . . . . . . . . . . .

xiii . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

7 Verdere ontwikkelingen 7.1 De load balancer als zwakke schakel 7.2 Dynamische generatie van ID’s . . . 7.3 Datasysteem . . . . . . . . . . . . . 7.4 Beveiliging . . . . . . . . . . . . . . 7.5 Technologieën en frameworks . . . . 8 Conclusie

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

. . . . .

. . . . . . . .

64 65 65 66 67 70 71 72

. . . . .

75 75 75 75 76 76 77

Inhoudsopgave

xiv

Tabel van afkortingen en symbolen AR ARM API ADD AMI AWS CPU CORBA CSS DNS EC2 ECF EJB HTML HTTP IaaS ID IP JAR JSP LDAP MVC OS OSGi PaaS POI RCP REST RMI SaaS SMTP SOA SOAP WIFI XML

Augmented Reality Acorn RISC Machine Application Programming Interface Attribute Driven Design Amazon Machine Image Amazon Web Services Central Processing Unit Common Object Request Broker Architecture Cascading Style Sheets Domain Name System Elastic Compute Cloud Eclipse Communication Framework Enterprise Java Beans HyperText Markup Language Hypertext Transfer Protocol Infrastructure as a Service Identification Internetprotocol Java ARchive JavaServer Pages Lightweight Directory Access Protocol Model View Controller Operating System Open Services Gateway Initiative Platform as a Service Point of Interest Rich Client Platform Representational State Transfer Remote Method Invocation Software as a Service Simple Mail Transfer Protocol Service-Oriented Architecture Simple Object Access Protocol Wireless Fidelity Extensible Markup Language

xv

Inhoudsopgave

xvi

Hoofdstuk 1 Inleiding In dit hoofdstuk wordt het onderwerp van deze masterproef toegelicht. Het probleem wordt voorgesteld en een passende oplossing wordt voorgesteld. Verder worden nog enkel essentiële termen toegelicht om het onderwerp te verduidelijken.

1.1

Probleemstelling

De toenemende rekenkracht in mobiele apparaten laat toe steeds meer geavanceerde applicaties te bouwen. Deze applicaties kunnen genieten van de bewegingsvrijheid die gepaard gaat met het gebruik van een mobiel toestel. Augmented Reality-applicaties die interageren met de omgeving stijgen daarom in populariteit. Bestaande frameworks om Augmented Reality-applicaties mee te ontwerpen zijn echter eerder applicatie-specifiek. Ze zijn geoptimaliseerd voor het bouwen van een kleine set van applicaties waarbij wat programmeer-hulp voorzien wordt zodat de ontwikkelaar zich enkel hoeft te concentreren op de belangrijkste zaken. Dit impliceert echter een sterke limitering op vlak van de creativiteit van de programmeur. Daar het introduceren van nieuwe functionaliteit niet ondersteund wordt, is het praktisch onmogelijk om af te wijken van deze voorgedefinieerde set van applicaties. Ook de stijgende populariteit van cloud computing mag niet uit het oog worden verloren. Steeds meer diensten worden aangeboden als een cloud service. De bestaande frameworks laten het echter niet toe een eigen gekozen functionaliteit in de cloud te integreren. Het overlaten van rekenintensieve bewerkingen aan een externe service heeft nochtans grote voordelen op vlak van prestatie en energieverbruik bij mobiele toestellen. Dit impliceert dat applicaties minder beperkt zijn door de gelimiteerde rekenkracht van het mobiel toestel. Intensieve bewerkingen hebben echter ook een sterk negatieve invloed op de levensduur van de batterij. 1

Hoofdstuk 1. Inleiding

1.2

2

Voorgestelde oplossing

Het doel van deze masterproef bestaat er in om een modulair en dynamisch framework te introduceren waarmee Augmented Reality-applicaties kunnen gebouwd worden. Daarbij wordt ook aandacht besteed aan een eventuele latere cloud-integratie van het framework. Het framework zelf kan gezien worden als een bouwdoos waaruit de nodige componenten kunnen worden geselecteerd om aan de behoeften van de applicatie te voldoen. De implementaties van de componenten worden door het framework voorzien maar het framework laat toe zelf componenten te schrijven of uit te bereiden. Het framework moet in staat zijn nieuwe componenten te aanvaarden zodat de functionaliteit kan uitgebreid worden. Ook moet het framework toelaten componenten aan te passen of toe te voegen wanneer het systeem actief is. Zo kan extra functionaliteit ge¨ıntroduceerd worden zonder dat het systeem hoeft te worden stop gezet. Voor de integratie met de cloud worden extra maatregelen getroffen zodat het systeem schaalbaar wordt en niet hoeft te lijden onder het eventuele onzeker karakter van cloud computing. Zo worden mechanismen aangeboden om er voor te zorgen dat het falen van een server geen negatieve invloed heeft op het systeem. De opkomst van tablets die beschikken over een Intel-processor [1] brengt heel wat voordelen met zich mee. Voordien waren de mogelijke instructies beperkt op een mobiel toestel, omdat die wegens energie-overwegingen beschikten over een zuinige ARMprocessor [2]. Deze processors beschikken over een andere architectuur waardoor programma’s die geschreven werden voor een traditionele processor, die gevonden wordt in computers en laptops, niet kunnen worden uitgevoerd. De komst van dergelijke tablets laat toe complexere programma’s te schrijven die gebruik maken van technologieën die voorheen niet mogelijk waren op een mobiel toestel. In deze masterproef wordt het gebruik van een dergelijke tablet verondersteld.

1.3

Verkennen domein

Om het het verloop van deze masterproef op een correcte manier te volgen, worden eerst enkele essentiële begrippen toegelicht.

1.3.1

Augmented Reality

Augmented Reality (afgekort AR) is, zoals Milgram het vastlegde in [3], het annoteren van de echte omgeving met virtuele objecten. Hier zal dit gerealiseerd worden door bovenop het beeld, opgenomen door de camera van het toestel, enkele virtuele objecten te plaatsen.


3

Soorten AR Er kunnen twee grote types onderscheiden worden: ”Marker Based” en ”Location Based”. Bij marker based AR wordt typisch gebruik gemaakt van bidimensionele markers die worden herkend via computer vision-software. Bovenop deze markers wordt dan een virtueel object getekend, zie figuur 1.1.

Figuur 1.1: Marker gebaseerde AR [4]

Indien gebruik gemaakt wordt van locatie gebaseerde AR zullen de virtuele objecten geplaatst worden op basis van gps-coördinaten, zie figuur 1.2. Layar [5] en Wikitude [6] zijn hier beiden voorbeelden van. Merk op dat Marker based en location based AR kunnen gecombineerd worden.

Figuur 1.2: Locatie gebaseerde AR [7]

1.3.2

Cloud computing

Cloud computing is het beschikbaar stellen van hardware en software via het internet[8]. Het laat toe op een eenvoudige manier nieuwe hardware bij te reserveren als er meer rekenkracht of opslag ruimte nodig is.


4

Verschillende modellen Cloud computing kan onderverdeeld worden in drie modellen: SaaS, Software as a Service, biedt een complete applicatie aan als een service zonder dat de gebruikers dienen te weten waar en hoe de berekingen gebeuren of waar de data opgeslagen worden. Voorbeelden hiervan zijn GMail [9], Wikipedia [10], Facebook [11],... PaaS, Platform as a Service, levert een complete ontwikkelingsomgeving zoals .Net of Java. Voorbeelden hiervan zijn Google App Engine [12], Microsoft Azure [13], Engine Yard [14],... IaaS, Infrastructure as a Service, biedt een volledige infrastructuur aan. Voorbeelden hiervan zijn Amazon EC2 [15], GoGrid [16], RightScale [17],... Het is de bedoeling het mogelijk te maken een deel van de applicatie, gemaakt aan de hand van het framework, aan te bieden als SaaS. Voor- en nadelen van cloud computing Het grote voordeel van cloud computing is dat hardware geen bekommernis meer vormt. Deze wordt aangeboden en onderhouden door een derde partij. De kost om nieuwe machines bij te reserveren is klein vergeleken met het scenario waar er zelf nieuwe machines moeten aangekocht worden. Dit maakt het mogelijk applicaties te schrijven die heel schaalbaar zijn. Het nadeel van cloud computing is dat er mogelijks onbetrouwbare machines worden toegewezen. Zo moeten extra maatregelen getroffen worden om de impact van het falen van een machine te minimaliseren.

1.4

Use case

Om aan te tonen dat het mogelijk is aan de hand van het framework augmented realityapplicaties te bouwen, wordt een use case uitgewerkt. Deze use case maakt het mogelijk virtualiteit te introduceren binnenshuis. Zo wordt het mogelijk uw muur te decoreren met virtuele schilderijen en posters. Maar ook om te interageren met virtuele objecten in uw omgeving. De applicatie laat u toe uw e-mails te lezen op de muur, virtuele berichten na te laten voor uw medebewoners of meldingen van sociale media te zien in een oogopslag. Als de gebruikte apparatuur het toelaat zou het in theorie mogelijk worden televisie te kijken zonder TV-toestel. Bewerkingen en opzoekingen die reken- en tijdintensief zijn, zullen in de cloud gebeuren. Er dient wel opgemerkt te worden dat het resultaat van de uitgewerkte applicaties beter tot zijn recht zou komen indien men gebruik maakt van een zogenaamde Virtual


5

reality-bril [18].

1.5

Overzicht van de hoofdstukken

Het boek is als volgt opgesteld: In hoofdstuk 2 wordt onderzocht wat de vereisten van het framework zijn. Waarbij een onderscheid wordt gemaakt tussen de functionele vereisten en de kwaliteitsattributen. Deze analyse wordt gemaakt door eerst enkele bestaande Augmented Reality frameworks te onderzoeken. Hoofdstuk 3 bevat het state-of-the-art onderzoek. Er wordt onderzocht wat cloud computing juist is en hoe Scalability en Availability binnen een cloud omgeving kunnen aangeboden worden. Vervolgens worden enkele raamwerken besproken die het mogelijk maken modulariteit te introduceren. Waarbij dieper wordt in gegaan op wat OSGi is en hoe het kan gebruikt worden in het eigen framework. Aangezien een integratie met de cloud moet mogelijk zijn worden enkele technologieën en raamwerken besproken die het mogelijk maken om te gaan met gedistribueerde software. Tot slot worden nog enkele specifieke Augmented Reality technologieën besproken. In hoofdstuk 4 wordt de architectuur van het systeem uitgewerkt. Eerst wordt een globaal beeld gegeven waarna er telkens dieper ingegaan wordt op elk subsysteem. Aan de hand van verschillende diagrammen wordt de architectuur van het systeem met zijn subsystemen verduidelijkt. Hoofdstuk 5 geeft een extra verduidelijking op vlak van implementatie van enkele onderdelen uitgelegd in hoofdstuk 4. Waarbij geprobeerd wordt de specifieke werking te schetsen van de onderdelen die Availability en Scalability mogelijk maken. In hoofdstuk 6 wordt het ontworpen systeem geëvalueerd, waarbij vooral zal getest worden wat de voor- en nadelen zijn van een schaalbaar systeem en wat de positieve en negatieve invloeden zijn van het mechanisme dat de beschikbaarheid van het systeem garandeert. In hoofdstuk 7 worden enkele zaken aangehaald die mogelijks nog in de toekomst kunnen onderzocht worden. In hoofdstuk 8 wordt afgesloten met een weloverwogen besluit.


6

Hoofdstuk 2 Specificatie Om de functionele vereisten en kwaliteitsattributen te bepalen van het framework werden een aantal bestaande AR applicaties en frameworks onderzocht. Door hun sterkten en beperkingen te onderzoeken was het mogelijk de vereisten van het eigen AR framework samen te stellen. Onder de beschouwde applicaties behoren onder meer: Layer [5], Wikitude [6], Satellite AR [19], iOnRoad [20], Yelp [21]. Enkele beschouwde frameworks zijn onder andere: Mixare [22], Metaio [23], KHARMA [24], Vuforia [25].

2.1

Bestaande frameworks

Omdat het onderzoek niet te ver zou leiden, worden niet alle bestaande frameworks in onderstaande uitzetting opgenomen. Er werden vier populaire frameworks geselecteerd. Uit de toelichting van deze vier wordt al een algemeen beeld zichtbaar.

2.1.1

Mixare

Mixare is een gratis open scource augmented reality browser [22]. Het is locatie gebaseerd en laat toe geodata af te beelden op een smartphone. Deze geodata kan afkomstig zijn van bestaande databronnen zoals GeoNames of Wikipedia, maar Mixare geeft ook de mogelijkheid verbinding te maken met een eigen databank die geodata bevat. Er kan besloten worden dat Mixare een handige tool is om geodata af te beelden maar het is niet flexibel genoeg om zelf logica toe te voegen. Ook is het enkel locatie gebaseerd en biedt het geen ondersteuning voor marker detectie.

2.1.2

Metaio

Metaio is een uitgebreid betalend Augmented Reality Development Kit [23] waarmee men in staat is zowel marker gebaseerde als locatie gebaseerde applicaties te creëren. Het laat ook toe data in de cloud te bewaren. Het is echter niet mogelijk zelf berekeningen in de cloud uit voeren. Ook zijn de gebouwde applicaties vrij statisch in de zin dat ze het niet toelaten op een gemakkelijke manier zelf componenten aan te passen of nieuwe componenten toe te voegen. 7

Hoofdstuk 2. Specificatie

2.1.3

8

KHARMA

KHARMA is een Augmented Reality framework [24] dat gebruik maakt van web technologieën zoals HTML5, CSS3 en Javascript om virtuele objecten en functionaliteit mee te creëren. Het laat toe eender welke webtechnologie te integreren wat een goede stap vooruit is maar het blijft echter enkel bij webtechnologieën. Het is echter niet mogelijk eigen functionaliteit in de cloud te integreren.

2.1.4

Vuforia

Vuforia is een platform dat toelaat marker gebaseerde AR-applicaties te bouwen [25], waarbij ondersteuning aangeboden wordt om zelf een marker te creëren en virtuele objecten te ontwerpen. De detectie van markers en het afbeelden van virtuele objecten kan ge¨ıntegreerd worden in een applicatie waarin extra functionaliteit kan worden voorzien. De mogelijkheid wordt terug geboden data in de cloud te bewaren. Zelf functionaliteit integreren in de cloud is echter niet mogelijk.

2.1.5

Besluit

Er kan besloten worden dat bestaande frameworks eerder statisch zijn en weinig uitbreidingen en aanpassingen toelaten. Ze richten zich vooral op toepassingen die enkel op het apparaat van de gebruiker draaien. In het beste geval wordt het bewaren van data in een databank aangeboden. Er kan dus gesteld worden dat de integratie met de cloud nog veraf is.

2.2

Functionele vereisten

Op basis van de functionaliteit die aangeboden wordt in huidige frameworks en hun beperkingen in gedachte houdend, worden de functionele vereisten bepaald voor het eigen framework. Aangezien de mogelijkheid aangeboden wordt een deel van het framework te implementeren in een cloud omgeving wordt een onderscheid gemaakt tussen een gebruikerszijde en een serverzijde. Met de gebruikerszijde of client wordt het deel bedoeld dat zal draaien op het toestel van de gebruiker. Het is enkel de serverzijde die zal ge¨ıntroduceerd worden in een cloud omgeving. Hieronder volgt een lijst met de geëxtraheerde functionele vereisten waarbij het onderscheid wordt gemaakt voor de vereisten die gelden voor heel het framework en de specifieke vereisten voor de client en server. Een gestructureerde voorstelling is terug te vinden in figuur 2.1.

2.2.1

Algemene vereisten van het framework

De algemene vereisten van heel het framework worden hieronder opgelijst. Deze vereisten zijn zowel voor de client als voor de server van toepassing.


9

Framework

Algemeen

Client

Server

Duidelijke API's aanbieden Inladen nieuwe modules Keuze laten modules op client/server te draaien Efficiënte communicatie Opnemen omgeving Bepalen locatie Marker detectie Afbeelden virtuele objecten Toelaten extra functionaliteit Opzoeken data Ophalen POI's Uitvoeren rekenentensieve bewerkingen Toelaten extra functionaliteit Beschikbaarheid garanderen Schalen

Figuur 2.1: Functionele vereisten

Het framework moet duidelijke API’s aanbieden zodat ontwikkelaars nieuwe componenten kunnen schrijven. De mogelijkheid moet voorzien worden om nieuwe componenten op een dynamische manier in te laden en uit te voeren. Het framework moet de keuze kunnen bieden een component langs de gebruikerszijde of serverzijde te draaien. Een efficiënte communicatie moet mogelijk gemaakt worden tussen client en server die er rekening mee houdt dat servers kunnen komen en gaan.

2.2.2

Specifieke vereisten van de client

Hieronder worden de specifieke functionele vereisten voor de client weergegeven. Het framework moet in staat zijn om de omgeving op te nemen aan de hand van een camera. De locatie van de gebruiker moet kunnen bepaald worden. Markers in de omgeving moeten kunnen gedetecteerd worden.


10

Virtuele objecten moeten kunnen geplaatst worden op basis van de locatie van gedetecteerde markers. Virtuele objecten moeten kunnen geplaatst worden op basis van de locatie van de gebruiker. Interactie met virtuele objecten moet mogelijk gemaakt worden. Het framework moet toelaten extra logica en functionaliteit te introduceren.

2.2.3

Specifieke vereisten van de server

Tot slot worden hieronder de vereisten van de server opgelijst. Aan de serverzijde moet het framework toelaten data op te zoeken en te bewaren. Het moet mogelijk zijn op basis van de locatie van de gebruiker data op te halen van POI’s(Point Of Interest). Geavanceerde en rekenintensieve AR-technieken moeten kunnen ge¨ımplementeerd worden langs de serverzijde. Het moet mogelijk zijn extra functionaliteit in het algemeen aan te bieden. De serverzijde moet kunnen schalen als het aantal aanvragen sterk stijgt of daalt. De beschikbaarheid van een server moet kunnen gegarandeerd worden.

2.3

Kwaliteitsattributen

Ook de kwaliteitsattributen voor het framework kunnen afgeleid worden uit de voorgaande analyse. Er wordt een onderscheid gemaakt tussen de kwaliteitsattributen voor het hele framework en enkele bijkomende attributen specifiek voor het server gedeelte.

2.3.1

Kwaliteitsattributen met betrekking tot het volledig framework

Modifiability Het framework dient in staat te zijn op een dynamische manier aanpassingen toe te laten. Dit laat bijvoorbeeld toe aan de client nieuwe virtuele objecten toe te voegen of up te daten. Ook andere componenten kunnen aangepast worden en extra functionaliteit kan ge¨ıntroduceerd worden. Aan de serverkant wordt het op deze manier mogelijk functionaliteit toe te voegen en aan te passen zonder dat de server herstart dient te worden.


11

Extensibility Het framework kan gezien worden als een basisstructuur die reeds enkele essentiële componenten voorziet. Het is waarschijnlijk dat deze componenten niet de vereisten van alle AR-applicaties zullen dekken, dus dient het mogelijk te zijn extra componenten te introduceren. Als er nood komt aan een nieuw soort type component dient het framework te kunnen aangepast worden zodat ook deze nieuwe component gemakkelijk kan ingebouwd worden. Het framework is momenteel AR-specifiek maar het moet mogelijk zijn het framework aan te passen en uit te breiden zodat het bruikbaar wordt in andere toepassingen. Reusability Componenten van het framework moeten kunnen hergebruikt worden in verschillende applicaties. Zo dienen de developers bepaalde functionaliteit niet telkens te herschrijven.

2.3.2

Server specifieke kwaliteitsattributen

Scalability Opdat het framework zou bruikbaar zijn voor applicaties met een verschillend aantal gebruikers moet het servergedeelte zich zelf kunnen aanpassen aan het aantal gebruikers. Dit zorgt er ook voor dat de apparatuur en energie zo efficiënt mogelijk worden gebruikt, wat niet onbelangrijk is een tijd waar men het zich niet meer kan permitteren om inefficiënt met energie om te springen. Availability Het framework moet maatregelen nemen om te garanderen dat een client altijd een server kan raadplegen. Ook moet er in voorzien worden dat een oproep naar de server niet verloren gaat als de server in kwestie uit valt.


12

Hoofdstuk 3 State of the art In dit hoofdstuk wordt de huidige stand van zaken op vlak van technieken en theorieën besproken die zouden kunnen gebruikt worden om aan de noden uit de behoefte analyse te voldoen.

3.1

Cloud computing

Zoals aangegeven in sectie 2.3 wordt onderzocht hoe de nodige Availability en Scalability technieken kunnen aangeboden worden in een cloud omgeving. Om te kunnen spreken over cloud computing moet echter aan enkele karakteristieken voldaan zijn. Deze staan vast gelegd in [26] en zijn onder meer : On-demand self-service. Het is mogelijk om computer-eenheden op een geautomatiseerde wijze aan te vragen. Broad network access. De computer-eenheden moeten over het netwerk beschikbaar zijn. Resource pooling. De aangeboden diensten worden gebundeld zodat meerder klanten kunnen behandeld worden. Er is ook een notie van locatie-onafhankelijkheid wat de computer-eenheden betreft. Rapid elasticity. De computer-eenheden moeten op een elastische manier beschikbaar gesteld worden. Measured Service. Cloud systemen controleren het gebruik en de klant betaalt enkel voor wat hij verbruikt. Omdat er hier een applicatie zal gebouwd worden boven op een cloud-platform zijn enkel Resource pooling en Rapid elasticity belangrijk. Het is aan de cloudprovider om de andere items te garanderen.

3.1.1

Schaalbaarheid

Elasticiteit aanbieden binnen cloud computing komt neer op het mappen van de performantie vereisten op de beschikbare computer-eenheden [27]. Dit proces wordt typisch het schalen van een applicatie genoemd. Te weinig computer-eenheden voorzien kan 13

Hoofdstuk 3. State of the art

14

nefaste gevolgen hebben voor de performantie. Terwijl te veel computer-eenheden voorzien zal resulteren in ongebruikte eenheden wat een onnodige kost als gevolg heeft. Volgens [28] kan zowel verticaal als horizontaal schalen onderscheiden worden, waarbij verticaal schalen duidt op de mogelijkheid om de computer-eenheid van meer rekenkracht te voorzien. Bij horizontaal schalen zullen meerdere computer-eenheden gebruikt worden om aan de performantie vereisten te voldoen. Aangezien verticaal schalen een kostelijke en tijdsintensieve ingreep is zal voortaan enkel gesproken worden over horizontaal schalen. Er zijn vijf mogelijke categorieën om te schalen [27]:

Statische, drempel-gebaseerde politiek. Deze categorie maakt gebruik van twee regels: één om omhoog te schalen en één om omlaag te schalen. In deze regels worden performantie metrieken als processorverbruik, geheugengebruik en responstijd gebruikt. Als voor een van de metrieken een bepaalde drempelwaarde bereikt is zal de schaling in actie treden. Deze regels zijn eerder gemakkelijk op te stellen maar wel applicatie-afhankelijk. Reinforcement Learning. Deze categorie zal kennis over voorgaande toestand van het systeem in acht nemen om beslissingen te maken als het systeem al dan niet moet schalen. Dit systeem zal uit eigen ervaring leren wat de beste uit te voeren actie is. Wachtlijntheorie. Een techniek die gebruikt wordt om performantie metrieken als de wachtlijnlengte of de gemiddelde wachttijd te schatten. Er wordt gebruik gemaakt van de wiskundige wachtlijntheorie om te berekenen hoeveel servers nodig zijn om de aanvragen in de wachtlijn te verwerken gegeven de snelheid waarmee aanvragen toekomen, de lengte van de wachtlijn, het aantal aanvragen in de wachtlijn en de verwerkingstijd. Controletheorie Dit kan gezien worden als een feedback-systeem. Een controleeenheid evalueert als het systeem voldoet aan bepaalde performantie vereisten en geeft feedback als er bijvoorbeeld nieuwe computer-eenheden moeten opgestart worden. Tijd-serie analyse Een tijd gebaseerde analyse die opzoek gaat naar bepaalde patronen om de werklast te kunnen voorspellen.

3.1.2

Availability

Omdat er geen notie meer aanwezig is van waar de gebruikte machines staan en welke machines men toegeëigend krijgt, is het bij cloud computing zeker nodig in het achterhoofd te houden dat de systemen kunnen falen [29, 30]. Als men wil voorkomen dat het falen van één computer-eendheid nefaste gevolgen heeft voor heel het systeem moeten extra maatregelen genomen worden. In de software architectuur spreekt men over Availability als het gaat over het falen van het systeem en de gevolgen daarvan [31]. Nu volgen enkele tactieken om met systeem fouten om te gaan [32, 31]:


15

Fouten detecteren: Ping/Echo: Het uitsturen van berichten vanuit een computer-eenheid naar een ander en wachten op een respons om zo te determineren als de computer-eenheid nog actief is. Heartbeat: Het periodiek uitsturen van berichten om aan te geven dat het systeem nog actief is. Exception: Om aan te geven dat er iets mislopen is wordt een foutboodschap gegenereerd.

Herstellen van fouten: Het herstellen van fouten bestaat uit twee delen: een voorbereiding en een herintroductie.

1. De voorbereiding: Voting: Alle lopende processen nemen dezelfde input en berekenen een simpele output die naar een voter gestuurd wordt. Als de voter afwijkend gedrag opmerkt van één van de processen wordt deze niet meegerekend. Actieve redundantie: Alle redundante componenten antwoorden in parallel op een event, uiteindelijk wordt de respons van één component gebruikt. Meestal is dat deze die het snelst antwoordt. Passieve redundantie: Een component reageert op de events en informeert de andere componenten als ze status updates moeten doorvoeren. Spare: Een standby systeem dat de gefaalde computer-eenheid vervangt.

2. De herintroductie: Shadow: Een gefaalde component loopt even in schaduw-modus tot zijn gedrag is aangepast aan het gedrag van de correct werkende componenten. Staat herintroductie: De redundantie-technieken vereisen dat de staat van een component hersteld wordt vooraleer het terug actief wordt. Een bericht met de staat van de redundante componenten kan de staat van de machine in kwestie up-to-date brengen. Rollback: Het systeem maakt zelf periodiek checkpoints aan van de staat waarin het zich bevindt. Na faling kan de staat hersteld worden aan de hand van deze checkpoints.

Fouten voorkomen: Verwijderen van service: Deze techniek zal een component verwijderen om geanticipeerde fouten te voorkomen. Transacties: Een transactie is een bundel van opeenvolgende stappen. Als één stap faalt uit de bundel worden alle voorgaande stappen hersteld.


16

Process monitor: Als een fout in een proces ontdekt is kan een monitor dit proces verwijderen en een nieuwe instantie ervan opstarten.

Een gestructureerde samenvatting vindt u in figuur 3.1.

Availability Tactieken

Fout detectie

Herstellen van fouten

Voorbereiding

Ping/Echo Heartbeat Exception

Voting Actieve Redundantie Passieve Redundantie Spare

Fouten voorkomen

Herintroductie Shadow Staat herintroductie RollBack

Verwijderen van service Transacties Process monitor

Figuur 3.1: Samenvatting availability tactieken

3.1.3

Load balancing

Scalability en availability vereisten in gedistribueerde architecturen kunnen voldaan worden door de aanvragen van de clients te verdelen over meerdere servers op een transparante wijze [33]. Dit wordt ook wel load balancing genoemd. Er kunnen verschillende load balancing technieken onderscheiden worden [33, 34]:

De DNS aanpak: De gemakkelijkste manier om load balancing toe te passen is om de servers te verdelen over voorgedefinieerde groepen van gebruikers. Dit kan gedaan worden door verschillende IP-adressen voor eenzelfde website op te geven in een DNS-server. Op deze manier zullen verscheidene gebruikers verschillende adressen zien behorende bij dezelfde naam.

Het aantal gebruikers per server minimaliseren: Een meer algemene techniek is om de gebruikers zelf te verdelen over meerdere servers. Hier is een extra component nodig tussen de servers en de clients, namelijk een load balancer. Deze kan zowel in hardware als software bestaan. Een load balancer in hardware zal werken op niveau van netwerkpakketten en gebruik maken van routeringstechnieken om de gebruikers over de server te verdelen. Load balancers ge¨ımplementeerd in software zullen zich naar de gebruiker toe voordoen als een server maar het verkeer zal vanuit de load balancer geforward worden naar een echte server.


17

De server testen: Om een server te selecteren moet de load balancer weten welke servers beschikbaar zijn. Dit kan aan de hand van de technieken om fouten te detecteren zoals gezien in sectie 3.1.2. De beste server selecteren: Er zijn verscheidene technieken om de load te verdelen. Een misvatting zou zijn om de server te kiezen die het snelst reageert. Indien dezelfde server altijd eerst reageert, wat verschillende redenen kan hebben, zal de load ongelijk verdeeld worden. Een beter idee is om de server te kiezen met de minste werklast. Ook dit kan ongewenste gevolgen hebben omdat in een webomgeving de werklast heel snel kan stijgen. De meest aangeraden techniek is de Round robin”-methode die elke server op zijn beurt zal se” lecteren. Indien niet alle servers dezelfde capaciteit aanbieden kan een gewogen versie van de methode gebruikt worden. In wat volgt zullen enkele technologiën, raamwerken en technieken besproken worden waarbij de bespreking beperkt wordt tot het Java domein. Deze keuze is tweezijdig, enerzijds wordt gekozen voor Java vanwege onze voorkennis en anderzijds wordt Java gekozen vanwege het platform onafhankelijk karakter.

3.2

Modulaire raamwerken

Om mogelijk te maken in het eigen framework nieuwe modules in te laden en te hergebruiken werd opzoek gegaan naar bestaande modulaire frameworks. Modulariteit is het opdelen van een computerprogramma in verschillende modules waarbij de de functionaliteit van deze modules vast ligt in een gegeven interface [35]. Er is een loskoppeling tussen interface en implementatie zodat nieuwe implementaties van een module gemakkelijk kunnen gebruikt worden. Modulariteit reduceert de complexiteit, vergemakkelijkt aanpassingen, resulteert in een gemakkelijkere implementatie en laat parallelle ontwikkeling toe [36]. Ook laat het toe code te hergebruiken [37]. Java zelf biedt geen modulariteit aan, het dichts aanleunende zijn Java jar-files die eigenlijk eerder kunnen gezien worden als een aggregatie van meerdere bestanden in één.

3.2.1

OSGi

Open Services Gateway Initiative afgekort OSGI is een extra laag bovenop de bestaande Java-omgeving die een extra factor dynamiek en modulariteit toevoegt aan de huidige omgeving[38]. Hierdoor is het mogelijk losstaande componenten te definiëren die kunnen samengebracht worden om één geheel te vormen. Deze componenten of


18

ook wel ’bundles’ genoemd kunnen dynamisch worden ge¨ınstalleerd, gestart, gestopt, ge¨ updatet en gede¨ınstalleerd at runtime. Bundles De eenheid van modulariteit in OSGi zijn bundles [39], waarbij elke bundle kan gezien worden als een extra abstractielaag. Deze abstractielaag zorgt voor encapsulatie van code maar dan op een hoger niveau. Een bundle is een JAR-bestand bestaande uit enkele klassen en een manifest-bestand dat metadata bevat over welke klassen zichtbaar zijn van buitenaf. OSGi gebruikt deze metadata onder andere om de naam, versie-nummer, start klasse vast te leggen en de afhankelijkheden te bepalen tussen verschillende bundles. Services Elke bundle kan één of meerdere diensten of zogenaamde services aanbieden [39]. Verschillende bundles kunnen gebruik maken van de functionaliteit aangeboden binnen een bepaalde service. De signatuur van een service ligt vast aan de hand van een contract wat een Java interface is. Ook services kunnen metadata definiëren aan de hand van properties. OSGi framework Het OSGi framework is een gelaagde architectuur gebouwd boven op de bestaande Java omgeving. Deze extra lagen zijn de module laag, de lifecycle laag en de service laag [39] (zie figuur 3.2).

Service Life cycle Module

Securit y

Bundles

Execut ion Environment Hardware/ OS

Figuur 3.2: OSGi architectuur [39]

De module laag werkt met de bundles en gebruikt de metadata om te bepalen welke klassen gedeeld mogen worden. De life cycle laag behandelt alle aspecten van de levenscyclus van een bundle waardoor het mogelijk wordt een bundle te installeren, te starten, te stoppen, te updaten en te verwijderen. De volledige levenscyclus kan u terug vinden in figuur 3.3.


19

newBundle

INSTALLED

update stop

update stop init

init start

STARTING init, start

start

RESOLVED stop update stop update start init

ACTIVE

init start

stop update STOPPING

Figuur 3.3: OSGi levencyclus [39]

De service laag biedt een register aan waar bundles een bepaalde service kunnen publiceren en waaruit ge¨ınteresseerde bundles deze service kunnen opvragen. Er worden technieken aangeboden om het publiceren en vinden van services mogelijk te maken. Implementaties Er zijn vier implementaties van OSGI: Knoperflerfish [40], Apache Felix [41], Concierge OSGI [42] en Equinox [43]. Als grootste onderling verschil kan gesteld worden dat Equinox de mogelijkheid aanbiedt gebruik te maken van Eclipse RCP [44]. Verder is Equinox ook een vrij complete implementatie die naast de OSGi specificaties ook implementaties aanbiedt voor remote services (zie sectie 3.2.1). Knoperflerfish is een heel populaire OSGi versie die als enige ook een betalende pro versie aanbiedt. Concierge is een eerder compacte implementatie met een voetafdruk van slechts 80 kBytes wat het dus zeer geschikt maakt voor mobile apparaten. Naast Concierge is ook Felix een vrij compacte uitvoering. OSGi remote services OSGi laat het ook toe om op een gedistribueerde wijze met services te communiceren. Het OSGi framework biedt een lokaal service register aan waar bundles communiceren aan de hand van service-objecten. Hierbij kan een service-object gezien worden als een object dat de ene bundle registreert en de andere opvraagt. De signatuur van de communicatie ligt vast bepaald door één of meerdere interfaces. Een distribution provider kan deze loskoppeling tussen bundles gebruiken om een geregistreerde service te exporteren door een endpoint aan te maken. Omgekeerd kan de distribution provider een proxy creëren die verbinding zal maken met een endpoint en deze proxy registreert als ge¨ımporteerde service. Hierbij is een endpoint een commu-


20

nicatiemechanisme naar een service in een ander framework [39]. De distribution provider moet verschillende rollen vervullen. Eerst moet het bepalen voor welke lokale services een endpoint moet aangemaakt worden en voor welke gedetecteerde services een proxy dient gegenereerd te worden om hun communicatie mogelijk te maken. Ten tweede moet een topologie gevormd worden waarin een overzicht gegeneerd wordt van welke services zich op welke endpoints bevinden. De derde rol is discovery. Om tot een specifieke topologie te komen is het nodig te ontdekken waar de geëxporteerde services zich bevinden in andere frameworks [45]. Een architectuur van de OSGi remote services kan terug gevonden worden in figuur 3.4. ServiceConsumer Impl

Service Producer Impl service.export ed.int erfaces

imported service

to an endpoint

exported =* service

endpoint

service.import ed =... Distribution Provider Impl

Figuur 3.4: Remote service architectuur [39]

Ook bij remote services ligt de implementatie niet vast door OSGi. Zo zijn er twee voorbeelden van implementaties van de distribution provider component. Apache CXF [46] implementeert de remote services functionaliteit gebruikmakend van web services als SOAP over HTTP(zie sectie 3.3.4). De service zelf wordt aangeboden via een WSDL-contract. Vanaf versie 1.1 is het ook mogelijk Java interfaces aan te bieden en te consumeren als RESTful JAX-RS services(zie ook sectie 3.3.4). Eclipse ECF [47] biedt een modulaire implementatie aan van de OSGi remote service standaard waarbij ondersteuning gegeven wordt voor REST- en SOAPgebaseerde remote services en asynchrone berichten voor remote services. In tegenstelling tot CXF is ECF specifiek ontworpen voor OSGi Remote Services.

3.2.2

Alternatieven

Nu worden er nog enkele mogelijke alternatieven voor OSGi behandeld: Java Enterprise Edition Enterprise applicaties zijn applicaties die gebruik maken van een grote databank en die een groot aantal potentiële gebruikers hebben [48]. Java Enterprise Edition [49]


21

(afgekort Java EE) laat toe dergelijke applicaties te bouwen. De architectuur van Jave EE bestaat uit drie lagen: de databanklaag, de businesslaag en de presentatielaag. Componentent in de businesslaag draaien in een EJB (Enterprise Java Beans) container terwijl componenten in de presentatielaag in een webcontainer lopen. In de presentatielaag wordt typisch gebruik gemaakt van servlets en JSP componenten en in de businesslaag van EJBs. De EJB container biedt enkele aantrekkelijke niet-functionele features aan [48]: Component levencyclus management: zal componenten starten als ze nodig zijn en stoppen als ze niet langer vereist worden. Transactie processing: zal er op toezien dat een set operaties uitgevoerd wordt in de context van een transactie zonder dat dit extra moeite vergt van de programmeur. Security handling: er wordt voor gezorgd dat het oproepen van een specifieke methode enkel kan gebeuren als de aanvrager van de methode de juiste permissies heeft. Persistentie: voorziet in het automatisch opslaan en ophalen van data in een databank zonder dat de programmeur databank queries moet schrijven. Remotability: houdt in dat componenten op een gedistribueerde manier kunnen opgeroepen worden zonder dat de programmeur hier extra code voor moet schrijven. Timer: maakt het mogelijk taken te plannen. State management: houdt de waarden van variabelen bij, ook al zijn de componenten niet actief. Resource pooling: resources (CPU en geheugen) worden verdeeld over meerdere aanvragen om ervoor te zorgen dat er een efficiënte verdeling is. Messaging: laat het toe data te publiceren en clients te laten registeren op de data waarin ze ge¨ınteresseerd zijn. De voordelen van de gehele Java EE architectuur zijn [48]: Vereenvoudiging van het ontwerp van grote gedistribueerde applicaties: de EJB container voorziet diensten op systeemniveau aan de enterprise beans, de bean ontwikkelaar kan zich focussen op het oplossen van het businessprobleem, de EJB container is verantwoordelijk voor systeemniveau diensten zoals transactiemanagement en autorisatie. De client developper kan zich focussen op de presentatie naar de client toe : omdat de beans de business logica bevatten en de clients zelf minder logica moeten bevatten (thin client). Enterprise beans zijn herbruikbaar: er kan een nieuwe applicatie gebouwd worden met bestaande beans. Spring Spring kan gezien worden als alternatief voor Java EE [50]. In Spring wordt gebruik gemaakt van Inversion of Control of Dependency Injection waarbij men terug Java-


22

Beans [51] gebruikt. Deze JavaBean hoeft niets te weten over de rest van het systeem. In tegenstelling tot Java EE hoeft een JavaBean zich geen zorgen te maken over afhankelijkheden van andere beans, de Spring-container zorgt hiervoor. Er kan gesteld worden dat Spring uit zeven georganiseerde modules bestaat [51]. Een gestructureerde voorstelling van deze modules vindt u in figuur 3.5.

Figuur 3.5: Overzicht van het Spring framework [52]

Core: Is het meest fundamentele stuk van het Spring framework. Er wordt een BeanFactory aangeboden zodat een loskoppeling ontstaat tussen de configuratie en specificatie van afhankelijkheden en de logica van het effectieve programma. Context: Maakt het mogelijk om verschillende beans op te halen. DAO: Biedt een JDBC-abstractie laag aan wat het gebruik van een databank vergemakkelijkt. ORM: Een integratie laag wordt aangeboden om object-relationele mapping mogelijk te maken. AOP: Laat het toe functionaliteit los te koppelen die logisch gezien niet samen hoort. Web: Biedt basis web-georiënteerde integratie mogelijkheden aan. Web MVC: Voorziet een Model-View-Controller implementatie voor web-applicaties. Aan de hand van deze modules is het mogelijk om Spring te gebruiken voor verscheidene scenario’s. Dit kan gaan van simpele applets tot volwaardige enterpise applicaties. Vergelijking Als grote verschil tussen Java EE en Spring kan gesteld worden dat de JavaBeans in Spring minder afhankelijk zijn van het systeem. Dit impliceert dat implementaties in Spring gemakkelijker herbruikbaar zijn in andere frameworks. De Spring-container zal


23

zelf de nodige afhankelijkheden aanbieden in tegenstelling tot de werkwijze in Java EE waarbij de programmeur dit zelf moet doen. In tegenstelling tot OSGi laten Java EE en Spring echter geen aanpassingen toe at runtime.

3.3

Gedistribueerde technologie¨ en en raamwerken

Mits er bij cloud computing gebruik gemaakt wordt van een gedistribueerde architectuur wordt hieronder het SOA principe en enkele voorbeelden ervan besproken.

3.3.1

SOA

SOA is een architectuur waarvan de design stijl is afgesteld op ondernemingen. Het belangrijkste aspect aan SOA is dat het service georiënteerd is, het centrale bouwblok van een SOA design is een service. Deze service bouwstenen implementeren specifieke vaardigheden die gemakkelijk kunnen (her)gebruikt worden bij het ontwerpen van complexe applicaties [48, 53]. Het gebruik van het SOA-ontwerp principe heeft zowel voorals nadelen. De voordelen: Verbeterde kwaliteit van applicaties: door de functionaliteit van verschillende bouwblokken te combineren kan een onderneming de focus leggen op het ontwerpen van het blok waarin hun expertise ligt en de andere blokken laten implementeren door andere specialisten. Reductie van ontwerptijd: applicaties kunnen sneller gemaakt worden omdat bepaalde bouwblokken kunnen hergebruikt worden of kunnen gekocht worden van andere ontwerpers. Het zakelijk aspect wordt vergemakkelijkt: vereenvoudiging van integratie met de klanten, leveranciers en de partners. Reductie van de kosten: Door bepaalde functionaliteit te outsourcen kan de ontwerpen onderhoudskost gereduceerd worden. De verwachte risico’s: Verhoogde moeilijkheidsgraad: SOA is een moeilijk concept om op een correcte manier uit te voeren. Lange termijn onderneming: De voordelen op korte termijn zijn meestal bescheiden. Het is pas op lange termijn dat SOA rendabel wordt. Verder worden nog enkele technieken besproken die gebruik maken van het SOA principe.

3.3.2

Java RMI

Java Remote Method Invocation (afgekort Java RMI) is een manier om Java-objecten op een gedistribueerde manier te laten communiceren [54]. Een methode oproep op een


24

gedistribueerd object wordt net op dezelfde manier uitgevoerd als op een lokaal object, met het verschil dat een RemoteException moet opgevangen worden. Als gedistribueerde objecten worden meegegeven in een methode als parameter wordt dit gedaan by reference”1 , terwijl lokale objecten worden doorgegeven by value”2 [48]. ” ” De RMI architectuur zelf bestaat uit vijf componenten [48]: Proxy: de lokale voorstelling van een gedistribueerd object en deze implementeert ook de interface van dit object. Dispatcher: zal de op te roepen methode identificeren. Skeleton: roept de methode op en stuurt het antwoord terug naar de proxy. Communicatie module: verzorgt de communicatie tussen de client en server. Remote interface module: beheert de referenties van de gedistribueerde objecten en vertaalt tussen lokale en gedistribueerde objecten. Een schematische weergave is terug te vinden in figuur 3.6.

Figuur 3.6: RMI architectuur [48]

3.3.3

CORBA

Common Object Request Broker Architecture (afgekort CORBA) laat toe met softwarecomponenten te communiceren onafhankelijk van hun programmeertaal. Dit is mogelijk door gebruik te maken van communicatie via sockets.

3.3.4

Web services

Een web service is een software component die aangeboden wordt aan de hand van een netwerkadres. Er zijn twee opties voor webservices: 1

Als een variable wordt meegegeven by reference” wordt enkel de verwijzing naar de variabele ” meegegeven, dus niet de waarde in de variabele [55]. 2 Wanneer een variabele wordt meegeven by value” wordt de effectieve waarde van de variabele ” meegegeven [55].


25

SOAP Simple Object Acces protocol is een text-gebaseerd protocol dat boven op HTTP of SMTP ge¨ımplementeerd wordt. SOAP is object georiënteerd en specificeert de object attributen en methode oproepen. De interface van deze services kan gedefinieerd, beschreven en ontdekt worden aan de hand van XML. REST Representation State Transfer is eerder een architectuur stijl waarbij gebruik wordt gemaakt van HTTP-methoden. REST biedt zogenaamde resources aan. Deze resources kunnen aan de hand van HTTP-methoden opgehaald of gemanipuleerd worden. Zo kan bijvoorbeeld met de GET-methode een resource opgehaald worden en met de PUTmethode een resource ge¨ updatet worden [56].

3.4

Augmented Reality technologie¨ en

Aangezien een framework gemaakt wordt voor augmented reality applicaties werd gezocht naar augmented reality libraries die in het framework kunnen ingevoegd worden.

3.4.1

Marker detectie

ARToolKit ARToolKit is samen met ARToolKitPlus een van de meest gebruikte AR libraries. Deze libraries slagen erin virtuele objecten toe te voegen boven op een live video. De plaats van de virtuele objecten wordt bepaald door in elk beeld van de video opzoek te gaan naar een soort van zwarte vierkanten die gebruikt worden als zogenaamde markers, zie figuur 3.7. De werking van ARToolKit kan in de volgende stappen samengevat worden[4]:

Figuur 3.7: Voorbeeld van een marker

1. De camera neemt een video op van de omgeving en stuurt het door naar de computer 2. De software op de computer zoekt in elk beeld naar een vierkante vorm.


26

3. Vanaf het ogenblik dat een vierkant gevonden is, wordt de positie van het vierkant bepaald ten opzichte van de camera aan de hand van wiskundige methoden. 4. Indien de positie van de camera gekend is, kan de computer een grafisch model tekenen boven op de positie van de marker. 5. Het grafisch model dat boven op de marker wordt afgebeeld wordt samen met de video stroom zichtbaar op het scherm voor de gebruiker.

ARToolKitPlus ARToolKitPlus [57] is de opvolger van ARToolKit. Het implementeert verbeterde detectie algoritmen, maar in tegenstelling tot zijn voorloper biedt ARToolKitPlus geen mogelijkheden om een grafisch model op te bouwen of af te beelden boven op het opgenomen beeld.

JavaCV JavaCV is een Java wrapper voor de meest gebruikte computer vision libraries waaronder ARToolkitPlus [58]. Dit maakt het mogelijk om in Java de ArtoolkitPlus library aan te spreken die oorspronkelijk bedoeld was voor C++. Verder biedt JavaCV ook ondersteuning om gebruik te maken van een camera wat, zoals aangegeven in sectie 2.2, nodig is om de omgeving te kunnen opnemen.

3.4.2

Locatie bepaling

Bij locatie gebaseerde augmented reality zijn er twee dingen nodig: de exacte locatie van de gebruiker en de locatie van de te plaatsen virtuele objecten. Als de coördinaten van beiden geweten zijn kan de relatieve positie van het virtuele object ten opzichte van de gebruiker bepaald worden. De coördinaten van de gebruiker worden meestal verkregen aan de hand van een GPSsysteem mits de gebruiker zich in de buitenlucht bevindt. Indien men zich binnenshuis bevindt kan overgestapt worden op een techniek die gebruik maakt van de sterkte van WIFI-signalen om de locatie van de gebruiker te bepalen[59]. Wel is er een leerfase nodig waarbij de signaal sterkten op enkele posities worden opgenomen en later kan aan de hand van deze data de positie van de gebruiker geschat worden. Nu de posities geweten zijn moet nog geverifieerd worden of het virtuele object zich in het gezichtsveld van de gebruiker bevindt. Door gebruik te maken van een acceleratiemeter kan de rotatie van de gebruiker bepaald worden[60]. Nu zijn alle nodige elementen gekend om een virtueel object op de juiste locatie binnen het gezichtsveld van de gebruiker te plaatsen.


3.5

27

Besluit

In deze sectie zal de uiteindelijke keuze van technologie op basis van de voorgaande secties verantwoord worden. Zoals aangegeven in sectie 2.2 werd opzoek gegaan naar een modulair framework. JavaEE en Spring maken het mogelijk zogenaamde Beans aan te maken en deze te hergebruiken, maar het is enkel OSGi die de mogelijkheid biedt om aanpassingen at runtime door te voeren. Zo kunnen er at runtime nieuwe bundles worden ge¨ınstalleerd en gestart. Dit maakt het bijvoorbeeld mogelijk updates aan de serverzijde te doen zonder dat het systeem offline hoeft te gaan. Omdat zowel aan de gebruikerszijde als serverzijde gebruik zal gemaakt worden van OSGi wordt er gekozen voor de Eclipse implementatie van OSGi namelijk Equinox. Daarbij wordt niet voor de meest compacte versie van OSGi gekozen alhoewel dit de meest logische keuze zou zijn om te gebruiken op mobiele apparatuur. Bij latere uitbreidingen laat deze keuze het toe aan de serverkant gebruik te maken van meer geavanceerdere OSGi technieken. Bij gebrek aan ervaring met OSGi leek het ons verstandiger te opteren voor een goed gedocumenteerde en complete implementatie. Verder biedt Eclipse ook remoting technieken aan wat dus voor een gemakkelijke integratie zorgt. Omdat OSGi gebruikt maakt van services is het mogelijk om zowel de gebruikerszijde als serverzijde een service te laten aanbieden zodat ook de serverzijde oproepen kan doen naar de gebruiker. Dit is een zogenaamde push-techniek [61] waarbij de server data pusht” naar de gebruiker. Dit heeft als voordeel dat de gebruikerszijde zelf niet ” steeds om updates moet vragen aan de server. Deze techniek, die typisch polling” ” wordt genoemd, is meestal energie-efficiënter omdat de gebruikerszijde zelf niet steeds moet vragen of er nieuwe gegevens beschikbaar zijn, wat energie en bandbreedte kost. Verder wordt gekozen voor Eclipse ECF om gebruik te maken van gedistribueerde services. Deze keuze wordt gemaakt omdat er problemen waren bij het opzetten van Apache CXF. Als bijkomend probleem blijkt dat de aanbieding van REST web services toch nog niet helemaal op punt staat bij ECF. Hierdoor is het noodzakelijk gebruik te maken van SOAP web services. Deze web services nemen typisch meer data in wat meestal minder ideaal is op een mobiel apparaat. De voorkeur gaat naar JavaCV om markers te detecteren. Dit omdat het een Java implementatie aanbiedt en ook ondersteuning voorziet om beelden op te nemen met een camera. De bestaande standaard Java libraries voor webcam ondersteuning zijn immers verouderd en werken niet binnen een eerder recente omgeving als OSGi.


28

Hoofdstuk 4 Architectuur In dit hoofdstuk wordt de architectuur van het volledige systeem besproken. Er wordt gebruik gemaakt van een top-down benadering: eerst wordt de globale structuur bekeken, waarna dieper wordt ingegaan op elk subsysteem. Telkens wordt zowel een statisch als dynamisch beeld van het systeem gevormd om zo goed mogelijk de werking van het systeem te verduidelijken.

4.1

Algemeen

Aan de hand van de Attribute Driven Design (ADD) methode [31] wordt de architectuur van het systeem en zijn subsystemen bepaald. De ADD-methode is een proces bedoeld om het systeem op te splitsen aan de hand van voorgaand gedefinieerde kwaliteitsattributen en functionele vereisten. De opsplitsing wordt hier gerealiseerd door een combinatie van het Broker- en Layerpatroon [31]. Het kwaliteitsattribuut dat hier van belang is, is Modifiability. Elk van de subsystemen moet gemakkelijk kunnen aangepast worden zonder dat een ander subsysteem hiervan last ondervindt. Kwaliteitsattributen als Reusability en Extensibility zijn eerder van belang bij het client- en server-subsysteem dan in het overkoepelende systeem. Het Broker-patroon laat toe een opsplitsing te maken in een gedistribueerde context. Waarin meerdere onafhankelijke componenten at runtime kunnen toegevoegd of verwijderd worden. In deze context kan onder deze componenten de clients en servers begrepen worden. Een extra onderdeel, de broker, fungeert als tussenliggende component die de coördinatie en communicatie verzorgt tussen de andere componenten. Dit laat de clients toe op een locatie-transparante wijze te communiceren met de server. Hier zal het load balancer-subsysteem fungeren als broker, meer informatie over het load balancer-subsysteem is te vinden in sectie 4.4. Er kan gesteld worden dat het systeem momenteel onderverdeeld is in een aantal clients, een broker en een aantal servers. De broker zal de communicatie tussen de clients en servers verzorgen. Ook het layer-patroon kan aangewend worden om structuur aan te brengen en een applicatie te ontbinden in verschillende componenten. Naast de servers is nog een 29

Hoofdstuk 4. Architectuur

30

component nodig die zal dienen als data-opslagsysteem. De server component, uit hoofdstuk 2, kan dus opgesplitst worden in een server deel waar berekeningen kunnen gebeuren, wat voortaan gewoon als server” zal bestempeld worden en een opslagsys” teem waarin data kunnen opgehaald en bewaard worden. Het dataopslagsysteem vormt nog een extra laag bij de voorgaande opsplitsing. Zo wordt de initiële server component opgesplits in een load balancer, een aantal servers en een dataopslagsysteem.

4.1.1

Componenten overzicht

Om de algemene structuur van het framework te verduidelijken wordt een contextdiagram opgesteld. Het contextdiagram heeft als doel de structuur van het systeem op het hoogste niveau weer te geven [62]. Het contextdiagram zelf is terug te vinden in figuur 4.1. Vier verschillende subsystemen kunnen worden onderscheiden: Client: Het subsysteem dat draait op het apparaat van de gebruiker en instaat voor het detecteren van markers en afbeelden van virtuele objecten. Er wordt dieper ingegaan op het client-subsysteem in sectie 4.2. Load balancer: De load balancer neemt onder andere de rol van broker op zich. Dit subsysteem zal servers toekennen aan de clients. Het is ook dit subsysteem dat zorgt dat er wordt tegemoet gekomen aan de Availability en Scalability vereisten uit hoofdstuk 2. Meer info over dit subsysteem wordt gegeven in sectie 4.4. Server: Biedt gedistribueerde functionaliteit aan en dient ook als toegang tot het datasysteem. In sectie 4.3 worden meer details over dit subsysteem verschaft. Datasysteem: Dient als globaal informatieopslagsysteem. Hier kan gebruikersdata bewaard worden maar ook POI’s kunnen bewaard en opgehaald worden in dit subsysteem.

Client

*

1

Load Balancer

1

*

Server

*

1

Data systeem

Figuur 4.1: Algemene structuur

Uit het contextdiagram blijkt dat het systeem meerdere clients en servers kan omvatten en slechts één loadbalancer en één data systeem. Er wordt geopteerd om slechts één datasysteem te gebruiken, dit maakt het mogelijk met data om te springen die voor alle clients en servers gelijk is. Om de werklast te verdelen over de servers dient de load balancer op de hoogte te zijn van het aantal clients en servers. Een eenvoudige manier om dit te verwezenlijken is


31

om alle clients en servers te registreren bij hetzelfde systeem (de load balancer), zodat daar een globaal beeld kan gevormd worden. Dit impliceert wel dat de load balancer de zwakste schakel van het systeem wordt. Als het load balancer-subsysteem faalt gaat alle globale informatie omvat in de load balancer verloren en is er geen communicatie tussen de andere subsystemen mogelijk. Communicatie wordt onmogelijk omdat de load balancer geen servers meer kan toewijzen aan de verschillende clients. Hier kunnen oplossingen voor gevonden worden, maar dit valt buiten het bestek van deze masterproef.

4.1.2

Communicatie overzicht

Om de interacties tussen de subsystemen te verduidelijken wordt een communicatiediagram opgesteld. Een communicatiediagram visualiseert de flow van berichten tussen de verschillende subsystemen en toont hun onderlinge relaties [62]. Het communicatiediagram van het volledige systeem is terug te vinden in figuur 4.2.

2.1:findBestServer() :Client

2:registerClient() :Load Balancer 2.2:sendServer()

1:registerServer()

3.1:calculate() :Server

3.2:getExtraData()

:Data System

3:callToServer():result

Figuur 4.2: Communicatie algemene structuur

Er kunnen drie stappen worden onderscheiden: 1. Een of meer servers registreren zich bij de load balancer. 2. Bij de registratie van een client bij de load balancer wordt gezocht naar een passende server. 3. Als de client wordt voorzien van een server kan hij deze rechtstreeks aanspreken. In wat volgt worden de drie eerste subsystemen verder uitgediept. Telkens wordt bekeken uit welke componenten deze subsystemen bestaan, dit gebeurt in het componenten overzicht. Hoe deze componenten onderling interageren wordt aangehaald in het communicatie overzicht.

4.2

Client

In deze sectie wordt dieper ingegaan op het client-subsysteem. De ADD-methode wordt verder gezet. Dit keer wordt het client-subsysteem onderverdeeld. In sectie 2.3 werden Modifiability, Reusability en Extensibility vast gelegd als


32

kwaliteitsattributen. Het is niet mogelijk een match te vinden die alle kwaliteitsattributen dekt, daarom moet gekozen worden op basis van het attribuut met de hoogste prioriteit. Aangezien het framework kan gezien worden als een basisstructuur die nog zal moeten uitgebreid worden, afhankelijk van de applicaties, kan aan Extensibility priorieit gegeven worden. Zo wordt gekozen voor het Microkernel-patroon wat Extensibility, Flexibility, Portability en scheiding van ontwerp en implemenatie aanbiedt [31]. De Microkernel laat toe een minimale kern te definiëren waarin verschillende componenten met elkaar kunnen communiceren. Dit maakt het mogelijk modulariteit te introduceren, de verschillende componenten dienen enkel elkaars signatuur te kennen. Wat toe laat verschillende implementaties te gebruiken.

4.2.1


Aan de hand van een componentendiagram wordt de structuur van het client-subsysteem duidelijk gemaakt. Componentendiagram Het componentendiagram toont de structurele relaties tussen de componenten van het systeem [62]. Waarbij een component hier een fysieke eenheid is met goed gedefinieerde interfaces en die kan gezien worden als een vervangbaar stuk van het systeem. Het componentendiagram voor het client-subsysteem is te vinden in figuur 4.3.

Render

ServiceContainer

IRender

Location

IServiceContainer

Core ILocation

IDetection

Detection

Capture ICapture

ICommunication

Communication

Figuur 4.3: Componentendiagram client

Zoals aangegeven in sectie 2.2 is het een algemene vereiste dat duidelijke API’s aangeboden worden zodat developers bestaande componenten kunnen gebruiken of nieuwe


33

implementaties kunnen voorzien die voldoen aan de vast gelegde structuur. Daarom legt elke component, behalve de core, de communicatie vast aan de hand van een interface. Hetzelfde fenomeen doet zich voor aan de serverzijde. In sectie 2.2 werd ook de specifieke functionaliteit voor het client-subsysteem vast gelegd. Zo moet de client in staat zijn om de omgeving op te nemen aan de hand van een camera, de locatie van de gebruiker te bepalen, markers te detecteren, virtuele objecten af te beelden en extra functionaliteit toe te laten. Deze functionaliteit zit telkens omvat in een andere component. Deze scheiding heeft een positief effect op de modulariteit. Het inladen van bijvoorbeeld een nieuwe detectiecomponent heeft geen invloed op de andere componenten. Er kunnen zeven componenten worden onderscheiden. Elke component, behalve de core, wordt afgebeeld met hun aangeboden interface. Core: De Core is de centrale component die de interactie tussen de andere componenten mogelijk maakt. Capture: De Capture-component neemt de omgeving op aan de hand van een camera. ICapture: De signatuur van de Capture-component ligt vast in de ICaptureinterface. getCaptureBufferedImage():BufferedImage Er wordt gekozen elk beeld voor te stellen als een BufferedImage, omdat dit het meest gebruikte formaat is binnen Java om afbeeldingen in terug te geven.

Communication: Zoals aangegeven in sectie 2.2 is er een efficiënte communicatie nodig tussen de verschillende subsystemen. De communication-component zal deze efficie¨ nte communicatie aan de gebruikerszijde voor zijn rekening nemen. Deze component zal zich registreren bij de load balancer en communiceren met een server. Er worden verschillende mechanismen aangeboden voor deze communicatie. Zo wordt de mogelijkheid aangeboden zowel synchrone- als asynchrone-oproepen te doen. Ook worden er in deze component maatregelen getroffen voor het wegvallen van een server tijdens de uitvoering van een oproep. Dit wordt uitvoerig besproken in sectie 5.5. ICommunication: Deze component wordt ook aangeboden als een interface maar aangezien de communicatie uitvoerig uitgewerkt wordt, lijkt het op het eerste zicht niet nodig een andere implementatie te gebruiken. init(clientId:int,serverInterface:Class,useLoadbalancer:boolean) Er wordt een initialisatie fase aangeboden die opgeeft welk ID de client wenst te gebruiken, met welke interface wenst gecommuniceerd te worden aan de serverzijde en of men al dan niet verlangt gebruik te maken van een


34

load balancer. Indien dit niet het geval is wordt de server gekozen die het snelst reageert. callSynchronous(method:String,params:Object[]):Object Deze methode laat het toe een synchrone oproep naar de server te doen. callAsynchronous(method:String,params:Object[]):int De callAsynchronous-methode laat een asynchrone oproep toe. getResult(callId:int):Object Laat toe het resultaat van een asynchrone oproep op te halen.

Detection: De Detection-component zal instaan voor de detectie van markers in de omgeving. IDetection: De detectie zelf kan gebeuren in één methode. detect(img:BufferedImage):double[] Enkel een detecteer methode die een afbeelding meekrijgt en een doublearray terug geeft is strikt noodzakelijk. De afbeelding is nodig om de detectie op toe te passen en de positie van de gedetecteerde marker wordt terug gegeven aan de hand van een transitie-matrix. Deze matrix wordt gerepresenteerd in de double-array.

Location: Detecteert de positie van de gebruiker. ILocation: De Location-Interface geeft de signatuur om de locatie en rotatie van een gebruiker te bepalen zodat op basis van de methode beschreven in sectie 3.4.2 de nodige ingrediënten aanwezig zijn om de virtuele objecten te positioneren op het scherm. getLocation():double[] Haalt de locatie van de gebruiker op. getRotation():double[] Bepaalt de rotatie van de gebruiker. calcTransitionMatrix(lat:double,long,double):double[] Een transitiematrix kan worden berekend door de coördinaten van een POI op te geven. Deze transitiematrix kan terug worden meegegeven aan de Render-component zodat de virtuele objecten op de juiste positie op het scherm kunnen afgebeeld worden.

Render: Deze component zal de visualisatie verzorgen van de virtuele objecten. Het is natuurlijk nodig zelf op te geven hoe de virtuele objecten er moeten uitzien. Er wordt enkel een component aangeboden die virtuele objecten kan afbeelden. De Render-component biedt de IRender-Interface aan die de signatuur van de Render-component vast legt.


35

IRender: Naast een af te beelden virtueel object zijn er minimaal drie zaken nodig: een afbeelding waarop de virtuele objecten zullen afgebeeld worden, een transitiematrix die de rotatie en translaties van het af te beelden virtueel object definiëren en een projectie-matrix. setProjectionMatrix(projectionMatrix:double[]) De projectie matrix moet één keer worden ingesteld en geeft de camerapositie terug ten opzichte van de virtuele objecten. addRenderObject(renderObj:IRenderObject) Deze methode voegt een virtueel object toe. Virtuele objecten worden gedefinieerd in de IRenderObject-Interface, zie hieronder. renderImage(BufferedImage img, double[] transitionMatrix) Via de renderImage-methode worden de virtuele objecten afgebeeld bovenop de afbeelding. De transitiematrix is de matrix die wordt teruggegeven door de Detection- of Location-component.

IRenderObject: De RenderObjecten kunnen worden toegevoegd in de Render. Dit laat toe om gemakkelijk nieuwe virtuele objecten in te laden. renderObject(gl:GL2) Er wordt maar één methode aangeboden die het object zelf zal renderen op basis van de 3D-omgeving die gemodelleerd wordt in de Render-component.

ServiceContainer: In deze component kunnen extra lokale services geregistreerd worden. Deze services kunnen dienst doen om extra functionaliteit aan te bieden. De andere componenten kunnen van deze functionaliteit genieten. Services binnen de ServiceContainer kunnen gemakkelijk andere services aanspreken of de communicatiemodule gebruiken. IServiceContainer: De IServiceContainer-Interface biedt de signatuur aan om extra diensten toe te voegen, op te halen of te verwijderen. getService(serviceName:String):Object De getService-methode laat toe een service op te halen op basis van de voorgedefinieerde naam van de service. addService(service:IService) Deze methode laat toe een service toe te voegen. Elke service wordt gedefinieerd aan de hand van de IService-Interface. removeService(service:IService) Laat toe een service te verwijderen uit de ServiceContainer.

IService: Biedt de signatuur aan voor de extra diensten. Deze extra diensten kunnen worden ingeladen in de ServiceContainer en gebruikt worden door andere diensten of andere componenten. setServiceContainer(container:IServiceContainer) Zorgt ervoor dat elke IService gebruik kan maken van de ServiceContainer.


36

De implementatie wordt zoveel mogelijk los gekoppeld van de functionaliteit zodat het mogelijk wordt andere versies van bepaalde componenten te gebruiken. Dit is mogelijk door enkel te definiëren hoe de verschillende componenten dienen te communiceren aan de hand van de vooropgestelde interfaces. Net vanwege deze modulariteit wordt het mogelijk bijvoorbeeld om een andere detectiecomponent te implementeren die toch kan gebruikt worden binnen het systeem. De meeste componenten werden echter al van een implementatie voorzien. Gebruikers van het framework kunnen deze componenten benutten om hun eigen augmented reality applicatie mee te maken. Dan is er enkel extra logica nodig om de samenwerking van deze componenten mogelijk te maken en te specificeren hoe de virtuele objecten er moeten uitzien. Het is ook mogelijk een nieuwe implementatie van een bepaalde component te implementeren als de noden van de applicatie dit vereisen. Tot slot laat deze architectuur het toe extra componenten te definiëren en toe te voegen omdat de architectuur flexibel en uitbreidbaar is.

4.2.2


In deze sectie wordt gekeken hoe de communicatie gebeurt binnen het client-subsysteem. Waarbij het duidelijk wordt hoe berichten worden uitgewisseld in het systeem zodat een beter zicht verkregen wordt op het algemeen gedrag [62]. Een activiteitendiagram visualiseert het verband tussen de verschillende activiteiten en bewerkingen binnen het systeem [62]. In figuur 4.4 wordt de algemene flow getoond van het systeem in de vorm van een activiteitendiagram. Het systeem begint met alle modules in te laden. De verschillende modules zijn terug te vinden in sectie 4.2.1. Er wordt gestart met het nemen van een beeld van de omgeving aan de hand van een camera. Als er gebruik gemaakt wordt van marker gebaseerde augmented reality zal marker detectie toegepast worden op dat beeld. Indien gebruik gemaakt wordt van locatie gebaseerde augmented reality zal de locatie van de gebruiker bepaald worden en gezocht worden naar POI’s in de omgeving. Op basis van deze gegevens kan worden bepaald waar de virtuele objecten moeten afgebeeld worden. Indien extra gegevens nodig zijn kunnen die extern opgehaald worden door verbinding te maken met de server. Ook is er de mogelijkheid een lokale service te hanteren uit de ServiceContainer. Als de virtuele objecten klaar zijn kunnen deze worden gerenderd op het scherm. De cyclus kan nu opnieuw beginnen tot de gebruiker het systeem afsluit. Ter verduidelijking worden nog twee sequentie diagrammen getoond die aangeven hoe lokale en externe diensten kunnen gebruikt worden. In figuur 4.5 wordt getoond hoe naar POI’s gezocht wordt aan de hand van een lokale service. Figuur 4.6 toont een gelijkaardig scenario waar wordt gebruik gemaakt van een externe dienst aangeboden door de server. De poiRetriever” staat in voor het ophalen van de ” POI’s, de signatuur van dit object ligt vast in de POIRetriver-interface.


37

Core laadt alle modules

Neem omgeving op met camera

[locatie gebasseerd]

Bepaal locatie gebruiker

[marker gebaseerd] Marker detectie op beeld

Zoek omliggende POI

Verwerking van gegevens

Zoek service [interne service nodig] in ServiceContainer

[externe service nodig]

Communicatie bereidt oproep voor

[geen service nodig] . interne oproep

Bereidt virtueel object voor

Verwerk respons

Render virtueel object

Figuur 4.4: Activiteitendiagram Client

externe oproep

response oproep


38

:Capture

:Core

:Location

:ServiceContainer

poiRetriever:POIRetriever

:Render

getCapturedBufferedImage() image getLocation() location getService("POIRetriever") poiRetriever

getPOIs(location) pois

findPOIs()

calcTransitionMatrix(pois) transitionMatrix renderImage(image,transitionMatrix)

Figuur 4.5: Sequentie diagram Client met lokale service

:Communication

:Core

:Capture

:Location

:Render

:Server

init(clientID,IPOIRetriever.class,true) getCapturedBufferedImage() image getLocation() location callAsynchronous(getPOIs,params) call(getPOIs,params) callID pois getResult(callID) pois calcTransitionMatrix(pois) transitionMatrix renderImage(image,transitionMatrix)

Figuur 4.6: Sequentie diagram Client met externe service

calculate


4.3

39

Server

In deze sectie wordt het server-subsysteem verder ge¨ınspecteerd. De server dient vooral als omgeving om externe diensten in aan te bieden. Daarom is de aangeboden architectuur eerder simpel. Dit omdat de aangeboden functionaliteit eerder applicatie specifiek is en hierover kan enkel worden gespeculeerd. De aangeboden structuur maakt het mogelijk op een eenvoudige manier een of meerdere externe diensten aan te bieden. De ADD-methode wordt terug gebruikt om het server-subsysteem verder op te splitsen. Om dezelfde redenen als bij de architectuur van de Client wordt opnieuw gebruik gemaakt van het Microkernel-patroon. Aangezien het server subsysteem weinig verantwoordelijkheden heeft kunnen er ook minder componenten worden onderscheiden. Als blijkt dat de nood voor specifieke componenten groot wordt, kan vanwege de aangeboden Extensibility van het Microkernel-patroon nog gemakkelijk extra componenten toegevoegd worden in de architectuur. Met specifieke component kan het ophalen van data of het opzoeken van POI’s bedoeld worden. In sectie 2.2 werd aangegeven dat de server moet in staat zijn data op te halen, POI’s te zoeken in de omgeving van de gebruiker en rekenintensieve berekeningen te kunnen uitvoeren. Er wordt gekozen deze functionaliteit niet te voorzien, noch hiervoor een specifieke component te reserveren. Deze keuze wordt gemaakt om het serversubsysteem zo generiek mogelijk te houden. Eender welke dienst kan in de server ingevoegd worden zonder al te veel beperkingen op te leggen aan de verwachte structuur. Het ophalen van data of het opzoeken van POI’s kan natuurlijk nog altijd aan de serverzijde gebeuren, er is echter geen specifieke component voorzien. Verder vergt dit ook communicatie met het Datasysteem wat in dit onderzoek niet uitgewerkt wordt.

4.3.1


Aan de hand van een componentendiagram wordt de structuur van het server-subsysteem verduidelijkt. Componentendiagram In figuur 4.7 wordt het componentendiagram getoond dat bestaat uit vier componenten. Elke component, behalve de core, wordt terug aangeboden als een interface zodat nieuwe implementaties kunnen voorzien worden. Core: Dit is de centrale component die de interactie tussen de andere componenten mogelijk maakt. DataBase: Verzorgt de communicatie met het databank-subsysteem. Het databanksubsysteem wordt echter in dit werk niet uitgewerkt.


40

DataBase

IDataBase IServerCommunication Communication

Core

IServiceContainer

ServiceContainer

Figuur 4.7: Componentendiagram server

IDataBase: De IDataBase-Interface legt vast hoe de communicatie verloopt met de databank. Communication: De communication-component zorgt dat de clients kunnen communiceren met bepaalde aangeboden diensten uit de ServiceContainer. Ook zal deze module zich aanmelden bij de load balancer. IServerCommunication: De IServerCommunication-Interface biedt de signatuur aan om diensten beschikbaar te maken over het internet. init(serverId:int,serverInterface:Class) De init-methode initialiseert de communicatiemodule. Er wordt een serverID meegegeven om de server te kunnen identificeren en een interface om de communicatie naar buiten toe mee vast te leggen. De interface zelf is van het type Class, zo hoeft de signatuur van de aangeboden interface niet vooraf bepaald te worden. setService(service:Object) Deze methode laat toe te specificeren op welk object de oproepen van buitenaf moeten gebeuren.

Er wordt gekozen geen limitering op te leggen wat de interface van de aangeboden diensten betreft. Zo is het mogelijk gelijk welke interface aan te bieden met een passend object (in de setService-mehode). Op deze manier blijft het communicatiesysteem zo generiek mogelijk. ServiceContainer: Net zoals in de Client architectuur is er ook hier een ServiceContainer aanwezig. Dit heeft speciaal als doel de keuze te laten om bepaalde


41

diensten lokaal (op de client) of op de server te draaien. Door enkel de signatuur van deze diensten vast te leggen wordt de modulariteit van het framework bevorderd. Het zijn de diensten uit de ServiceContainer die zich kunnen registreren bij de Communication-component zodat deze beschikbaar worden voor de clients.

4.3.2


Aan de hand van een activiteitendiagram wordt terug de algemene flow geschetst. Het activiteitendiagram zelf is te vinden in figuur 4.8. Bij het starten van het server-subsysteem zal de core de verschillende modules inladen. Deze verschillende modules staan uitgelegd in sectie 4.3.1. Als alle componenten ingeladen zijn zal gekeken worden welke services enkel lokaal moeten beschikbaar zijn en welke ook van buiten af kunnen geraadpleegd worden. De laatste moeten geregistreerd worden bij de communicatiecomponent zodat de client deze kan gebruiken. Zowel langs de client als serverzijde moet de interface van deze services opgegeven worden om de communicatie mogelijk te maken. Als de externe services geregistreerd zijn is het wachten tot een client er een oproep op doet. Wanneer een service in uitvoering is kan hij zowel de databank als andere services raadplegen. Als extra verduidelijking wordt in figuur 4.9 aan de hand van een sequentie diagram ge¨ıllustreerd hoe een dienst aan de serverzijde aangeboden wordt. Terug wordt de POIRetriever-interface gebruikt om de communicatie vast te leggen.

4.4

De load balancer

De load balancer is het subsysteem dat servers zal toekennen aan de clients en ervoor zorgt dat het systeem schaalbaar is. De ADD-methode wordt niet gebruikt om het load balancer-subsysteem nog verder op te splitsen, omdat dit systeem beperkt is in grootte. Aangezien gebruik gemaakt wordt van OSGi is het mogelijk om zowel de client als de server een service aan te bieden naar de load balancer toe zodat deze een totaal overzicht heeft van alle beschikbare clients en servers. Dit zorgt ervoor dat de load balancer altijd op de hoogte is welke servers beschikbaar zijn. Ook kan het detecteren indien een server uitvalt of online gaat overgelaten worden aan OSGi. Zowel bij de client als server wordt deze service aangeboden in de communicatiemodule. Als teruggekeken wordt naar hoofdstuk 2 is er helemaal geen sprake van een load balancer systeem. Het load balancer systeem werd in sectie 4.1 ge¨ıntroduceerd om dienst te doen als broker en om aan de Scalability en Availability vereisten te voldoen uit sectie 2.3. Zoals gezien in sectie 3.1.3 kunnen deze vereisten voldaan worden door gebruik te maken van load balancing. De load balancer zal Scalability garanderen door het toe te laten servers te starten of te stoppen. Doordat er meerdere servers beschikbaar zijn kan gegarandeerd worden dat de client op elk moment één van de beschikbare servers kan benutten. Zo kan voldaan worden aan de Availability vereisten.


42

Core laadt modules

extra services registeren zich

[enkel lokaal beschikbaar]

service aanvraag

registratie bij ServiceContainer

[extern beschikbaar] . Registratie bij Communicatie [wacht op oproep].

Communicatie zoek service op Bewerkingen in service [databank toegang] [geen databank toegang] [extra service nodig]

Haal extra info uit databank ServiceContainer zoekt service op

[geen extra service nodig] Communicatie bereidt respons voor

service voert oproep uit

respons naar client

Figuur 4.8: Activiteiten diagram server


:Core

ServerCommunication

43

:ServiceTracker

poiRetriever:POIRetriever

:Client

init(serverID,POIRetriever.class)

getService(POIRetriever) poiRetriever setService(poiRetriever)

call(getPOIs,params)

getPOIs(params) result result

Figuur 4.9: Sequentie diagram Server

Het client-subsysteem zal zelf ook nog maatregelen nemen, dit wordt besproken in hoofdstuk 5.

4.4.1


Het klassendiagram van het load balancer subsysteem wordt eerst bekeken, zie figuur 4.10. Het load balancer systeem is heel beperkt en bestaat grotendeels uit een register dat bijhoudt welke clients gebruik maken van welke servers. Ook zal de load balancer omgaan met het beschikbaar worden of wegvallen van servers. Hoe dit in zijn werk gaat wordt besproken in sectie 4.4.2. De architectuur van de load balancer omvat vijf grote delen: LoadBalancer: De LoadBalancer klasse bevat twee listeners die zullen detecteren of een client of server service geactiveerd of gedeactiveerd wordt. De listeners zullen deze activatie en deactivatie doorgeven aan het register. Hoe dit in zijn werk gaat wordt uitgelegd in hoofdstuk 5. Client: Een wrapper rond de service aangeboden door het client-subsysteem met de mogelijkheid om het ID op te halen en een nieuwe server toe te kennen. Het toekennen van deze server wordt doorgespeeld naar de onderliggende client-service. De toekenning zelf gebeurt aan de hand van een serverID. Server: Representeert de service aangeboden door de server en een lijst van Clientobjecten die gebruik maken van de server in kwestie.


Load Balancer -register: Register -clientTracker:ServiceTracker -serverTracker:ServiceTracker

1 1

44

Register serverRegister:ArrayList<Server> queueClients:Queue lbTechnique:ILBTechnique addServer(serverID:String) removeServer(serverID:String) addClient(clientID:String) removeClient(clientID:String) 1

1 «interface» ILBTechnique findBestServer(serverRegister:List):Server scaleUp() scaleDown()

1 0..n

Client IServerRetriever: clientService id:String getId():String setServer(id:String) 0..n

1 0..n Server clients:ArrayList id:String getId():String addClient(c:Client ) removeClient(c:Client) getNumOfClients():int

0..1

Figuur 4.10: Architectuur load balancer

Register: Deze klasse zal bijhouden welke servers gebruikt worden door welke clients. Ook is er een queue aanwezig waarin clients kunnen worden bewaard indien geen servers actief zijn. ILBTechnique: De ILBTechnique-interface wordt gebruikt door het Register en omvat de load balancing technieken. Deze worden aangeboden als een aparte interface zodat de modulariteit bevorderd wordt en zodat verschillende implementaties mogelijk worden. Zoals gezien in sectie 3.1.3 zijn verscheidene technieken mogelijk om de werklast te verdelen. findBestServer(serverRegister:List):Server Zoekt een server om toe te kennen aan een client. Hierbij wordt getracht de clients zodanig te verdelen over de servers zodat de werklast bij de verschillende servers zo weinig mogelijk verschilt. Als argument wordt een lijst van alle servers meegegeven zodat de nodige informatie gekend is om de werklast zo goed mogelijk te verdelen. scaleUp() Deze methode laat het toe nieuwe servers op te starten zodat het systeem kan schalen. scaleDown() Dit is de omgekeerde bewerking waarbij servers gestopt worden omdat de werklast op de servers te laag ligt.

4.4.2


Ook voor de load balancer wordt aangehaald hoe het uitwisselen van berichten gebeurt aan de hand van een activiteiten diagram dat terug te vinden is in figuur 4.11.


45

Er worden vier scenario’s onderscheiden: het registreren van een client en server en het de-registeren van client en server. Bij elk scenario wordt nog een sequentie-diagram gegeven om een specifiek geval te verduidelijken.

Load Balancer wacht op clients/servers

registratie client

[server aanwezig]

haal clients uit queue

registratie server

[clients in queue]

[geen server aanwezig] [geen clients in queue] plaats client in queue

zoek beste server

verdeel clients over server(s)

registreer server

ken server aan client toe

stuur serverID naar client deregistratie client

deregistreer client

deregistreer server

[niet toegewezen bij clients]

deregistratie server

[toegewezen bij client] Zoek nieuwe server voor deze clients

Figuur 4.11: Activiteiten diagram load balancer

Registratie server Als een server zich registreert zal hij toegevoegd worden in het register. Vervolgens zal er nagegaan worden of er clients in de queue staan die nog geen server toegekend kregen. Dit is enkel het geval als er nog geen andere servers beschikbaar zijn. Indien er nog clients in de queue aanwezig zijn zullen ze worden toegekend aan deze server. Dit laatste scenario wordt nog eens extra weergegeven aan de hand van een sequentiediagram in figuur 4.12. Registratie client Als een client zich registreert zal eerst gekeken worden als er al servers aanwezig zijn. Indien dit niet het geval is zal de client in de queue geplaatst worden tot een server zich aanmeldt. Als er wel al servers geregistreerd zijn zal op zoek gegaan worden naar


Client

46

Load Balancer

Server

registerClient enqueueClient registerServer dequeueClients registerClientToServer sendServerID

Figuur 4.12: Sequentie-diagram: registratie server

de beste” server. Met beste” wordt bedoeld de server waarvan verwacht wordt dat ” ” zijn werklast het kleinst is. Van zodra er een server geselecteerd is, zal de client worden toegekend aan deze server. De registratie van een client in een systeem waar al een server aanwezig is wordt nog eens extra weergegeven aan de hand van een sequentiediagram in figuur 4.13. De-registratie server Bij het offline gaan van een server moet nagezien worden of er clients zijn die deze server gebruiken. Indien dit niet het geval is kan de server zonder probleem uit het register worden gehaald. Als er wel clients gebruik maken van deze server moet voor elk van de clients een nieuwe server gezocht worden of in de queue geplaatst worden als er geen servers beschikbaar zijn. Dit laatste scenario wordt nog eens extra weergegeven aan de hand van een sequentie-diagram in figuur 4.14. De-registratie client In het geval dat een client offline gaat moet deze enkel bij de server worden weggehaald waarbij hij was toegekend. Indien er geen servers aanwezig zijn, staat deze client nog in de queue en moet hij uit deze queue worden verwijderd. Dit wordt nog eens extra weergegeven aan de hand van een sequentie-diagram in figuur 4.15. Bij het zoeken naar een server voor een client kan bepaald worden of er te veel of te weinig clients gebruik maken van de servers. Indien dit het geval is kan het systeem schalen en kunnen servers gestart of gestopt worden. Zoals gezien in sectie 3.1.1 zijn er verschillende technieken om te schalen mogelijk. Hier wordt gebruik gemaakt van de zogenaamde drempel gebaseerde politiek”. De loskoppeling van de load balancing ”


Client

47

Load Balancer

Server registerServer addServerToRegister

registerClient

findBestServer registerClientToServer sendServerID setServer serverCall

caculateAnswer returnAnswer

Figuur 4.13: Sequentie-diagram: registratie client

Client

Load Balancer

Server

deregisterServer removeServer redistributeClients sendServerID

Figuur 4.14: Sequentie-diagram: de-registratie server


48

technieken aan de hand van de ILBTechnique-interface laat toe verschillende technieken te introduceren. Client

Load Balancer

Server

deregisterClient

removeClientFromServer

Figuur 4.15: Sequentie-diagram: de-registratie client

4.5

Besluit

Het framework kan gezien worden als een basisstructuur die afhankelijk van de applicaties dient uitgebreid of aangepast te worden. Het voorgestelde systeem wordt opgesplitst in vier delen: de clients, een load balancer, de servers en een datasysteem. Zowel aan de client- als serverzijde wordt gebruik gemaakt van het Microkernel patroon. Vanwege de structuur van dit patroon wordt het mogelijk componenten die voorheen nog niet in het framework werden opgenomen bij te voegen. Ook dient enkel de signatuur van de verschillende componenten gekend te zijn zodat verschillende implementaties van een bepaalde component mogelijk zijn. Het framework verwacht ook dat er wordt tegemoet gekomen aan de Scalability en Availability vereisten. Hiervoor wordt een load balancer opgezet die het mogelijk maakt het systeem te schalen door servers te starten en te stoppen. Ook zorgt het load balancersubsysteem ervoor dat een client altijd gebruik kan maken van een server, indien die aanwezig zijn. Het datasysteem werd niet uitgewerkt omdat het minder interessant is binnen dit onderzoek.

Hoofdstuk 5 Implementatie In dit hoofdstuk wordt de implementatie van het framework besproken waarbij vooral wordt in gegaan op het communicatiesysteem. Het communicatiesysteem omvat zowel de communicatiemodule van client en server als de toegevoegde werking van de load balancer. De andere modules komen minder aanbod omdat deze vooral applicatie specifiek zijn. Bij de implementatie wordt gebruik gemaakt van de Agile-programmeermethode [63]. Waarbij elk subsysteem in elke iteratie dieper uitgewerkt wordt.

5.1

Specifieke OSGi-technieken

Aangezien er in verschillende componenten gebruik gemaakt wordt van dezelfde OSGitechnieken worden deze eerst toegelicht. Zoals vermeld in sectie 3.2.1 is een OSGi-applicatie opgebouwd uit een aantal bundles. Een bundle kan een bepaalde functionaliteit aanbieden en deze functionaliteit wordt een service genoemd. Elke bundle kan zijn services registeren zodat andere bundles van deze services gebruik kunnen maken. OSGi heeft een speciale component om services te registeren, dit is de centrale OSGI Service Registry [39]. Typisch zal er gebruik gemaakt worden van een Java-interface om de interface van de service te definiëren. Het is dan ook op basis van deze interface dat de registratie in het register gebeurt. Aangezien services dynamisch kunnen gestart en gestopt worden moeten de bundles die ge¨ınteresseerd zijn in de desbetreffende services, service listeners registeren die zullen worden op de hoogte gebracht als een service gestart of gestopt wordt. Er zijn twee mogelijkheden om dit te doen: aan de hand van de OSGi ServiceTracker of via Declarative Services. Declarative Services zullen hier niet gebruikt worden, omdat deze niet flexibel genoeg zijn. Declarative Services zijn niet fexibel genoeg omdat bepaalde parameters in een file opgeslagen worden en dus niet veranderbaar zijn at runtime. 49

Hoofdstuk 5. Implementatie

5.1.1

50

De OSGi ServiceTracker

Elke bundle heeft een klasse die zal geactiveerd worden als de bundle gestart wordt. Dit is meestal de Activator-klasse die de BundleActivator-interface implementeert [39]. Deze bevat een starten stopmethode. Het is de bedoeling om in deze methoden de logica te schrijven die nodig is bij het starten of stoppen van de bundle. Beide methoden nemen een BundleContext-object als argument. Het is dit object dat toegang verleent aan het service register. Uit dit object kan een geregistreerde service gehaald worden, maar dit is een eenmalige operatie. Dus is er een meer dynamische component nodig die telkens zal detecteren of de service waarin men ge¨ınteresseerd is, zich registreert. Dit is de ServiceTracker. Het is mogelijk een eigen instantie van de ServiceTracker te maken waarin kan gespecificeerd worden wat er moet gebeuren als de service waarin men ge¨ınteresseerd is wordt toegevoegd, aangepast of verwijderd. In listing 5.1 wordt een voorbeeld getoond van een eigen implementatie van de ServiceTracker. Er worden twee methoden overschreven: de addingService- en removedService-methode. Het zijn deze methoden die zullen detecteren wanneer een service respectievelijk wordt gestart of gestopt. De methode addingService neemt zowel het BundleContext-object als de naam van de interface waarin men ge¨ınteresseerd is als argumenten. Na regel 5 kan zelf logica toegevoegd worden om te werken met nieuw gestarte services. Op dezelfde manier kan omgegaan worden met gestopte services in de removedService-methode. Listing 5.1: Voorbeeld ServiceTracker. 1 2 3 4 5 6 7 8 9 10 11 12 13 14

ServiceTracker tracker = new S e r v i c e T r a c k e r ( bundleContext , I S e r v i c e R e t r i e v e r . c l a s s . getName ( ) , null ) { public Object a d d i n g S e r v i c e ( S e r v i c e R e f e r e n c e r e f e r e n c e ) { Object s v c = super . a d d i n g S e r v i c e ( r e f e r e n c e ) ; i f ( s v c instanceof I S e r v i c e R e t r i e v e r ) { I S e r v i c e R e t r i e v e r s e r v i c e = ( I S e r v i c e R e t r i e v e r ) svc ; } return s v c ; } public void r e m o v e d S e r v i c e ( S e r v i c e R e f e r e n c e r e f e r e n c e , Object s e r v i c e ) { super . r e m o v e d S e r v i c e ( r e f e r e n c e , s e r v i c e ) ; } }; t r a c k e r . open ( ) ;

5.1.2

De OSGi ServiceRegistration

Nu zal er gekeken worden hoe remote services kunnen aangeboden worden. Een service kan geregistreerd worden bij het BundleContext-object door de registerService-methode op te roepen. Aan deze methode kunnen de volgende argumenten meegegeven worden: de naam van de interface, het object die deze interface implementeert en zal dienen als aangeboden service en tot slot nog een properties-object die extra eigenschappen van


51

de registratie kan bevatten. Bij het aanbieden van een remote service moet in het properties-object gespecificeerd worden hoe de communicatie moet gebeuren. Een voorbeeld van het gebruik van de ServiceRegistration wordt gegeven in listing 5.2. In regel 4 tot 7 wordt getoond hoe de extra informatie gespecificeerd wordt om dit mogelijk te maken aan de hand van ECF.

Listing 5.2: Voorbeeld ServiceRegistration. D i c t i o n a r y <S t r i n g , Object> p r o p s = new Hashtable<S t r i n g , Object > ( ) ; S t r i n g h o s t = get HostI P ( ) ; int p o r t = g e t P o r t ( ) ; p r o p s . put ( ” s e r v i c e . e x p o r t e d . i n t e r f a c e s ” , ” * ” ) ; p r o p s . put ( ” s e r v i c e . e x p o r t e d . c o n f i g s ” , ” e c f . g e n e r i c . s e r v e r ” ) ; p r o p s . put ( ” e c f . e x p o r t e d . c o n t a i n e r f a c t o r y a r g s ” , g e t A d d r e s s ( host , p o r t ) ) ; p r o p s . put ( ” e n d p o i n t . i d ” , g e t A d d r e s s ( host , p o r t ) ) ; ServiceRegistration registration = bundleContext . r e g i s t e r S e r v i c e ( s e r v i c e I n t e r f a c e . getName ( ) , s e r v i c e , p r o p s ) ;

1 2 3 4 5 6 7 8 9

Het oproepen van de registerService-methode geeft een ServiceRegistration-object terug. Door het oproepen van de unregister-methode kan de aangeboden service worden gestopt.

5.2

Ontdekking van services

Deze sectie behandelt de ontdekking van services in een gedistribueerde omgeving.

5.2.1

OSGi Discovery

Zoals aangehaald in sectie 3.2.1 bestaat de derde rol van de distribution provider bij OSGi remote services uit discovery. Om gebruik te maken van remote services binnen OSGi is er een mechanisme nodig dat elke container op de hoogte brengt van de beschikbare remote services. Dit gebeurt aan de hand van OSGi Discovery [45, 64]. Het is ook de discovery die zal aankondigen wanneer een service uit zijn eigen container remote beschikbaar geworden is. Bij het ontdekken van een service zal de discovery de service in kwestie doorspelen naar de Topology Manager die de uiteindelijk beslissing zal nemen of de service al dan niet dient ge¨ımporteerd te worden. Voor het ontdekken en aankondigen kan gebruik worden gemaakt van de discovery protocols als Service Location Protocol [65], JGroups [66] en ZooKeeper [67]. De voorkeur gaat uit naar Apache ZooKeeper [68], omdat het weinig extra configuratie vergt. Heel de opstelling kan via Java Virtual Machine argumenten geconfigureerd worden. Zookeeper maakt gebruik van centrale server die alle informatie bijhoudt over de beschikbare services. Andere services kunnen genieten van deze informatie door


52

verbinding te maken met de centrale server.

5.2.2

Configuratie

Aangezien alle clients en servers zich registeren bij de load balancer zal deze dienst doen als centrale server. Dit laat een eenvoudige configuratie toe, enkel het fysiek adres van de load balancer dient geweten te zijn. De virtuele machine van het load balancer subsysteem dient geconfigureerd te worden met de toevoeging van de volgende parameter: -Dzoodiscovery.flavor=zoodiscovery.flavor.standalone= Elke server of client dient als volgt te worden geconfigureerd: -Dzoodiscovery.flavor=zoodiscovery.flavor.centralized=

5.3

Aanbieden en detecteren van services

In dit onderdeel wordt onderzocht hoe de services van client en server worden aangeboden en ontdekt.

5.3.1

Server

Aangezien de communicatiemodule van de server de simpelste is, zal deze eerst behandeld worden. Zoals aangehaald in sectie 4.3 is het mogelijk bij de communicatiemodule te definiëren welk object met welke interface moet beschikbaar gesteld worden voor de clients. Dit gebeurt aan de hand van een ServiceRegistration zoals werd uitgelegd in sectie 5.1.2. Met als verschil dat er een extra eigenschap wordt toegevoegd in het properties-object met het ID van de server. In listing 5.3 wordt getoond hoe de communicatiemodule kan worden aangemaakt en gestart voor een service die de IPOIRetriever-interface implementeerd. Het aanmaken van de communicatie, wat terug te vinden is in regel 1, gebeurt in de communicatiecomponent zelf. Het Communication-object wordt dan geregistreerd als service zodat andere componenten hiervan kunnen gebruik maken. Het initialiseren, wat te zien is in regels 2 en 3, gebeurt in de component die wenst gebruik te maken van de communicatiecomponent. De setService-methode roept regel 8-9 uit sectie 5.2 apart op zodat een update van het service-object gemakkelijk kan worden doorgevoerd. Listing 5.3: Initialisatie communicatie server. 1 2 3

Communication com = new Communication ( bundleContext ) ; com . i n i t ( s e r v e r I D , I P O I R e t r i e v e r . c l a s s ) ; com . s e t S e r v i c e (new P O I R e t r i e v e r ( ) ) ;


5.3.2

53

Client

Het aanbieden van de client remote services gebeurt evenwel via de methode uit sectie 5.1.2. Waarbij deze keer het clientID wordt meegegeven in het properties-object. Aangezien het de bedoeling is dat de client gebruikt maakt van de services aangeboden door de server worden aan de hand van de methode uitgelegd in sectie 5.1.1, deze server-services verkregen. Ook in de client moet opgegeven worden welke serverinterface wenst gebruikt te worden. De client-service zelf heeft een voorgedefinieerde interface. Deze interface heeft twee methoden (zie listing 5.4): sendServerId en sendResult. De eerst methode laat de load balancer toe een server toe te kennen aan de client. De tweede methode zorgt ervoor dat een server rechtstreeks een antwoord kan geven aan de client. Listing 5.4: Client-service interface. 1 2 3 4

public i n t e r f a c e I S e r v i c e R e t r i e v e r { public void s e n d S e r v e r I d ( S t r i n g s ) ; public void s e n d R e s u l t ( int i d C a l l , Object r e s u l t ) ; }

In listing 5.5 wordt aangetoond hoe de client communicatiemodule kan worden aangemaakt en ge¨ınitialiseerd. Listing 5.5: Initialisatie communicatie client. 1 2

Communication com = new Communication ( bundleContext ) ; com . i n i t ( c l i e n t I D , I P O I R e t r i e v e r . c l a s s , true ) ;

Waarbij het derde argument een boolean is die aangeeft of het al dan niet wenselijk is gebruik gebruik te maken van een load balancer. Indien gebruik gemaakt wordt van een load balancer is de client enkel ge¨ınteresseerd in de server die hij toegewezen kreeg door de load balancer. Daarvoor zal in de ServiceTracker gefilterd worden op het serverID die meegegeven werd in het properties-object. Dit is mogelijk door aan het BundleContext-object een filter aan te vragen die gebuik maakt van het LDAP-principe [69, 70]. Een LDAP-filter maakt het mogelijk zoekcriteria te definiëren aan de hand van strings en laat efficient zoeken toe. In listing 5.6 wordt getoond hoe een filter aangemaakt wordt in functie van het serverID. In regel 2 Listing 5.6: Filteren op serverID. 1 2

F i l t e r f = bundleContext . c r e a t e F i l t e r ( ” ( t h e s i s . s e r v e r . i d=”+s e r v e r I d+” ) ” ) ; t r a c k e r = new S e r v i c e T r a c k e r ( bundleContext , f , null ) { . . . } ;

wordt getoond dat de ServiceTracker wordt aangemaakt door de filter mee te geven inplaats van de naam van de interface zoals in listing 5.1.


5.4

54

Load balancer

Nu de remote service aan de client- en serverzijde beschikbaar zijn gesteld zal bestudeerd worden hoe deze services in de load balancer kunnen worden gedetecteerd en verwerkt. Bij het opstarten van de load balancer moet enkel opgegeven worden welke interface de server-service gebruikt. Het is niet nodig dit op te geven voor de clients, omdat deze zich altijd aanmelden met een voorgedefinieerde client-interface. De interface van de server-service ligt niet vast, dit maakt het mogelijk eender welke service aan te bieden aan de serverzijde zonder te limiteren op de aangeboden interface. Wel moet er in de load balancer worden gedefinieerd welke interface benut zal worden. Als er in de server meerdere service worden aangeboden dient er slechts één bijhorende interface worden opgenomen in de load balancer. In listing 5.7 wordt aangegeven hoe de load balancer kan gestart worden voor een server-service die de interface IPOIRetriever implementeert.

Listing 5.7: Registratie service. 1 2

LoadBalancer l b=new LoadBalancer ( bundleContext ) ; lb . s t a r t ( IPOIRetriever . class ) ;

5.4.1

Registratie services

Nu de load balancer gestart is, kan algemeen gekeken worden hoe de aangeboden service van zowel client als server kunnen gedetecteerd worden. Deze detecties gebeuren op basis van de aangeboden methode uit sectie 5.1.1. In sectie 4.4 werd getoond dat het load balancer-subsysteem vooral bestond uit een register. Het toevoegen en verwijderen van zowel clients en servers aan het register zal gebeuren in de methoden van de ServiceTracker. Listing 5.8 demonstreert hoe dit in zijn werk gaat voor het toevoegen van een client. Het verwijderen gebeurt analoog maar dan in de removedServicemethode. Ook het toevoegen en verwijderen van servers gebeurt volledige analoog.

Listing 5.8: Registratie client in load balancer. 1 2 3 4 5 6 7 8 9 10

public Object a d d i n g S e r v i c e ( S e r v i c e R e f e r e n c e r e f e r e n c e ) { Object s v c = super . a d d i n g S e r v i c e ( r e f e r e n c e ) ; i f ( s v c instanceof I S e r v i c e R e t r i e v e r ) { I S e r v i c e R e t r i e v e r s e r v i c e = ( I S e r v i c e R e t r i e v e r ) svc ; S t r i n g c l i e n t I D= ( S t r i n g ) r e f e r e n c e . g e t P r o p e r t y ( ” t h e s i s . c l i e n t . i d ” ) ; // Toevoegen aan r e g i s t e r : r e g i s t e r . a d d C l i e n t (new C l i e n t ( s e r v i c e , c l i e n t I D ) ) ; } return s v c ; }


5.5

55

Client

In deze sectie zal de werking van de client communicatiemodule behandeld worden.

5.5.1

Bewaren methode

Zoals eerder vermeld in sectie 4.2.1 worden in de communicatiemodule van de client maatregelen getroffen om het verloren gaan van een methode oproep naar een server tegen te gaan als deze uitvalt. Dit is mogelijk als de opgeroepen methode bewaard wordt bij de client. Maar deze methoden moeten nadien ook nog kunnen uitgevoerd worden. Er wordt gekozen om gebruik te maken van Java Reflections [71]. Java Reflections maakt het mogelijk een Method-object aan te maken op basis van een object of zijn interface en de naam van de methode. Later kan dit Method-object worden uitgevoerd op ditzelfde object of een object die zelfde interface implementeerd. Een codevoorbeeld hiervan wordt gegeven in listing 5.9. Waarbij service een object is die Listing 5.9: Gebruik reflectie. 1 2 3 4

// o p h a l e n methode Method m=findMethod ( s e r v e r I n t e r f a c e , methodName ) ; // oproepen methode m. i n v o k e ( s e r v i c e , params ) ;

de serverInterface implementeert, methodName een string is met de naam van de op te roepen methode en params een Object-array is met eventuele parameters. De mogelijkheid van Java reflections om een methode oproep los te koppelen van het object is hier interessant. Zo wordt het mogelijk een methode oproep naar de server te specificeren zonder vast te leggen op welke server-service dit moet gebeuren. Als een server uitvalt kan de oproep dus zonder probleem gebeuren op een service-object afkomstig van een andere server. De vereiste data om een methode te bewaren bestaat dus uit de interface van de serverservice, de naam van de methode en de parameters. Bij het bewaren van de methode gaat wel wat programmeergemak verloren. Zo kan een methode niet meer rechtstreeks op een object worden aangeroepen, maar dienen zowel de methodenaam als het object worden meegegeven als parameters.

5.5.2

Oproepen van methoden

Er wordt gebruik gemaakt van een klasse, speciaal ontworpen, om methoden te behandelen die kunnen bewaard worden. Dit is de Reflector klasse. Deze laat toe oproepen op drie verschillende manieren door te voeren, deze worden hieronder doorgelicht. Verder bevat deze klasse twee queue’s: een eerste queue wordt gebruikt om de op te roepen methoden in te bewaren en een tweede queue dient om de antwoorden tijdelijk in te bewaren. Alle asynchrone oproepen worden voor de uitvoering bewaard in de eerste


56

queue en worden er pas uitgehaald als een antwoord van de server verkregen wordt. Dan wordt dit antwoord tijdelijk in de tweede queue geplaatst. Nu volgen enkele aangeboden methoden om oproepen naar de server te realiseren: Synchrone oproep De eerste variant is een gewone synchrone oproep. Deze oproepen maken geen gebruik van de queue’s uit de Reflector. Wel moet er rekening gehouden worden met enkele randgevallen. Het eerste probleem doet zich voor als er geen server aanwezig is op het moment dat een oproep gedaan wordt. Dan zal actief gewacht worden tot een server zich registreert (Zie figuur 5.1 en de waitForService-oproep). Een tweede probleem doet zich voor als de connectie met de server tijdens de methode oproep onderbroken wordt. Dit wordt gedetecteerd door een opgeworpen Exception. Als dit gebeurt zal de oproep opnieuw uitgevoerd worden tot een antwoord verkregen wordt. Hoe de synchrone oproep omgaat met het wegvallen van een server wordt hieronder structureel weergegeven: 1. Er wordt een synchrone oproep gedaan op de communicatiemodule van de client. 2. De communicatiemodule geeft deze oproep door naar het Reflector-object die zal controleren als er al een server-service geregistreerd is. Indien dit niet het geval is zal actief gewacht worden tot de load balancer een server toekent. 3. De Reflector doet een oproep naar de server. Tijdens deze oproep loopt er iets fout in de server waardoor deze offline gaat. 4. Omdat de verbinding verbroken werd wordt een Exception opgeworpen bij de client. Deze Exception wordt opgevangen en de oproep wordt opnieuw gestart. Als er nog geen nieuwe server is toegekend door de load balancer zal terug actief gewacht worden als in stap 2. 5. In tussentijd heeft de load balancer gedetecteerd dat de server weggevallen is. Deze zal kijken welke clients gebruik maakten van deze server en elk van deze clients een nieuwe server toekennen. Client:Communication

Client:Reflector

Server

synchronousCall(methodName,params) waitForService envokeCall

calculate returnResult returnResult

Figuur 5.1: Synchrone methode oproep


57

6. Als de gebruiker een nieuwe server wordt toegekend stopt het actief wachten en wordt de oproep opnieuw geprobeerd. Pseudo-asynchrone oproep Bij de tweede methode zal een nieuwe thread opgestart worden waarin een synchrone oproep wordt verstuurd naar de server. Deze synchrone oproep mag niet worden verward met de variant hierboven uitgelegd. Er wordt een synchrone oproep gedaan in een nieuwe thread, zonder de mechanismen te gebruiken die hierboven werden beschreven om het wegvallen van de server of het niet aanwezig zijn van de server te behandelen. Hier wordt wel gewerkt met de twee queue’s uit de Reflector. Zo wordt bij het oproepen van een pseudo-asynchrone oproep een ID terug gegeven en op basis van dit ID kan het resultaat terug gevonden worden in de resultaten queue. (Zie sequentie diagram 5.2). Pas bij het terug krijgen van het resultaat wordt de oproep uit de eerste queue verwijderd. Indien de server wegvalt blijft de oproep in de eerste queue aanwezig. Bij het registeren van een nieuwe server zullen alle oproepen in die queue opnieuw uitgevoerd worden. Hoe deze oproep omgaat met het wegvallen van een server wordt hieronder verklaard: 1. Een pseudo-asynchrone oproep wordt gedaan vanuit de communicatiemodule. Deze geeft de oproep door naar de Reflector. 2. De reflector maakt een nieuwe oproep aan door gebruik te maken van Java Reflections zodat de oproep kan worden bewaard en plaatst de oproep in de queue. 3. Er wordt een nieuwe thread aangemaakt waarin een synchrone oproep gebeurt naar de server. 4. Tijdens deze oproep valt de server weg. 5. De client detecteert het wegvallen van de server, maar doet momenteel niets. 6. Ook de load balancer heeft het wegvallen van de server gedetecteerd en voorziet alle clients die deze server gebruikten van een nieuwe server. 7. De client die nu in bezit is van een nieuwe server zal alle oproepen die nog in de queue staan opnieuw uitvoeren. De oproep wordt pas uit de queue gehaald als een antwoord wordt voorzien door de server. Asynchrone oproep Om een volledige asynchrone oproep te realiseren is er een mogelijkheid nodig voor de server om het antwoord door te sturen naar de client. Dit gebeurt aan de hand van de sendResult-methode uit de IServiceRetriever-interface. Er dient wel opgemerkt te worden dat het mogelijk moet zijn voor de client om zich te registeren bij de server. Ook zijn er twee extra parameters nodig: het clientID en het ID van de oproep moeten meegegeven worden. Het clientID wordt meegegeven zodat de server weet naar welke client een antwoord moet gestuurd worden. Het ID van de oproep wordt meegegeven zodat de oproep bij de client uit de queues kan gehaald worden. Opnieuw zal het oproepen van de asynchrone oproep een ID terug geven waarmee in de tweede queue kan nagegaan worden of de oproep al tot een succesvol einde werd gebracht.


Client:Communication

58

Client:Reflector

Server

pseudoAsyncCall(methodName,params) enqueueCall createNewThread envokeCall calculate returnResult dequeueCall addResultToDoneQueue

Figuur 5.2: Pseudo-asynchrone methode oproep

In figuur 5.3 wordt de werking terug verduidelijkt aan de hand van een sequentiediagram, de client module die de client-service aanbiedt wordt benoemd als Retriever”. ” Tot slot wordt nog gekeken hoe deze asynchrone oproep omgaat met het wegvallen van een server: 1. Er wordt een asynchrone oproep gedaan op de communicatiemodule van de client die de oproep doorgeeft aan de Reflector. 2. De Reflector maakt, met behulp van Java Reflectie, een nieuwe oproep aan en plaatst deze in de queue. 3. Als een server reeds werd toegekend wordt een oproep gedaan naar de server. 4. Tijdens deze oproep faalt de server. 5. De load balancer detecteert dat deze server offline is en kent nieuwe servers toe aan de clients die deze server gebruikten. 6. Als de client een nieuwe server wordt toegekend worden de oproepen die nog in de queue staan opnieuw uitgevoerd.

5.5.3

Een voorbeeld

Listing 5.10 toont hoe de verschillende oproepen in de praktijk kunnen verwezenlijkt worden. Het resultaat moet telkens gecast worden naar het verwachte antwoord type, omdat gebruik wordt gemaakt van Object-objecten om alles zo generiek mogelijk te houden.

5.6

Use Case

In deze sectie worden enkele implementaties specifiek voor de use case uit hoofdstuk 1.4 behandeld.


Client:Communication

59

Client:Retriever

Client:Reflector

Server

asyncCall(methodName,params) enqueueCall createNewThread envokeCall

calculate sendResult

result dequeueCall addResultToDoneQueue

Figuur 5.3: Asynchrone methode oproep

Listing 5.10: Oproep naar de server. 1 2 3 4 5 6 7 8 9 10 11

// I n i t i a l i s a t i e communicatiemodule com . i n i t ( c l i e n t I D , IOperand . c l a s s , true ) ; // s y n c h r o n e oproep d i e r e s u l t a a t d i r e c t t e r u g g e e f t int r e s u l t =( int ) com . c a l l S y n c h r o n o u s ( ” operand ” , new Object [ ] { 1 5 , 3 3 } ) ; // p s e u d o a s y n c h r o n e oproep int c a l l I D 1=com . c a l l P s e u d o A s y n c h r o n o u s ( ” operand ” , new Object [ ] { 1 5 , 3 3 } ) ; // a s y n c h r o n e oproep int c a l l I D 2=com . c a l l A s y n c h r o n o u s ( ” operandAsyn ” , new Object [ ] { 1 5 , 3 3 } ) ; // o p h a l e n r e s u l t a a t i f ( com . isDone ( c a l l I D 2 ) r e s u l t =( int ) com . g e t R e s u l t ( c a l l I D 2 ) ;


5.6.1

60

Afbeelden van virtuele objecten

Zoals aangehaald in sectie 4.2.1 is het nodig zelf de virtuele objecten te definiëren. Voor de use case werd nog een extra feature ge¨ımplementeerd die toelaat virtuele objecten te herschikken zodat ze niet gebonden zijn aan de positie van de marker. Op deze manier wordt het ook mogelijk meerdere virtuele objecten te projecteren zonder dat deze elk op een afzonderlijke marker dienen geplaatst te worden. De locatie van de marker wordt door de detectiemodule teruggegeven als een OpenGL ModelView matrix [72]. OpenGL werkt met twee soorten matrices die de 3D-omgeving kunnen bepalen [72]. Een die de locatie van de camera in de omgeving bepaalt ook wel projectiematrix genoemd en één die de locatie van het virtuele object aangeeft, dit is de modelview-matrix. Om in staat te zijn virtuele objecten te herschikken moet eerst toegelaten worden om een bepaald object te selecteren door erop te klikken. Dit impliceert dat de locatie in de 3D-ruimte moet worden omgezet naar coördinaten in een 2D-omgeving. Om dit te realiseren moeten de coördinaten uit de 3D-omgeving eerst omgezet worden naar zogenaamde clip-coördinaten. Waarbij de clip-ruimte kan gezien worden als een projectiescherm achteraan de 3D-omgeving. Dit wordt gedaan door de projectiematrix te vermenigvuldigen met de modelview-matrix. Vervolgens moeten deze coördinaten nog genormaliseerd worden om een gelijke verdeling over het scherm te bekomen in het [-1,1] interval. Nu kan de omzetting gedaan worden naar de 2D-coördinaten van het scherm zelf zodat het mogelijk wordt om te bepalen wanneer de muis zich bovenop een virtueel object bevindt. Op dezelfde manier kunnen de virtuele objecten herschikt worden. De coördinaten van de muis worden terug genormaliseerd naar het [-1,1]-interval van de clip-ruimte en dit kan vermenigvuldigd worden met de inverse projectiematrix zodat een nieuwe modelview-matrix bekomen wordt. De verschillende ruimten in OpenGl worden getoond in figuur 5.4.

5.7

Integratie met de Cloud

Omdat het framework ook moet kunnen ge¨ıntroduceerd worden op een echt cloudsysteem zal worden onderzocht hoe het framework kan ge¨ıntegreerd worden met Amazon Web Services [15] (afgekort AWS). Er werd gekozen voor AWS, omdat dit een van de veel gebruikte Cloud-systemen is. Merk op dat dit slechts een mogelijke integratie is, alternatieven zijn mogelijk. Zoals kort aangehaald in sectie 4.4 zal de load balancer beslissen over het starten of stoppen van de servers. Het is nodig ook servers te termineren als die niet gebruikt worden wegens energie- en kostoverwegingen.


61

Figuur 5.4: Structuur OpenGL [72]

5.7.1

Amazon EC2 Command Line Tool

Om dit te realiseren kan de load balancer zelf het commando geven om nieuwe servers te starten of te stoppen. Dit kan worden verwezenlijkt met de Amazon EC2 Command Line Tool. Deze zal eerst moeten ge¨ınstalleerd worden op de load balancer. Deze tool maakt het mogelijk commando’s op te roepen om nieuwe servers te starten en te stoppen. Dit is onder andere het RunInstances” commando. Dit commando vraagt ” minimum drie parameters [73]: een ImageId, het minimum aantal servers dat gestart moet worden en het maximaal aantal servers dat gestart mag worden. Het ImageId is een referentie naar een Amazon Machine Image(AMI) [74]. Dit is een voorgedefinieerd besturingssysteem dat zal worden ge¨ınstalleerd op de nieuw gestarte server. Er kan zelf een AMI aangemaakt worden met alle nodige applicaties reeds geinstalleerd (vb. het serverdeel van het framework) of er kan gekozen worden voor een lege Windows of Linux installatie. Voor deze integratie wordt geopteerd voor een lege installatie, met als voorwaarde dat deze al Java bevat. Bij het starten van een nieuwe server wordt als respons het IP-adres terug gegeven zodat een connectie kan gemaakt worden met de nieuwe server om de serversoftware over te zetten en te starten. Deze stap zou niet nodig zijn als gebruik wordt gemaakt van een zelfgemaakte AMI. Toch had dit hier niet de voorkeur omdat de serversoftware op de AMI mogelijks niet up-to-date zal zijn. Op dezelfde manier is het mogelijk met het commando StopInstances” servers te ” stoppen.


62

Hoofdstuk 6 Evaluatie In dit hoofdstuk wordt het communicatiesysteem geëvalueerd dat besproken werd in hoofdstuk 5. Eerst wordt een overzicht gegeven van de gebruikte testopstelling, gevolgd door de verschillende scenario’s met hun resultaten. Tot slot volgt een conclusie. De bedoeling van deze evaluatie is te testen hoe schaalbaar het systeem is en na te gaan hoeveel infrastructuur nodig is als het systeem op grote schaal gebruikt wordt, waarbij metrieken als responstijd en geheugengebruik in aanmerking komen. De evaluatie omvat twee componenten: de load balancer en het ingebouwde communicatiesysteem aan de clientzijde. Telkens wordt het voordeel in responstijd onderzocht maar ook de overhead op basis van geheugengebruik.

6.1 6.1.1

Testopstelling Gebruikte infrastructuur

De testopstelling maakt bij de meeste scenario’s gebruik van drie machines. Deze machines zijn geconnecteerd door een high-bandwidth interconnectie netwerk van 100MB/s. Hieronder worden de drie machines verder toegelicht. Figuur 6.1 toont een schematische voorstelling. Machine 1 start verschillende gebruikers op en staat in voor de tijdsmetingen aan de gebruikerszijde. Om de verschillende gebruikers te simuleren wordt voor elke gebruiker enkel een communicatiecomponent aangemaakt. Deze communicatiecomponent registreert zich bij de load balancer en doet de oproepen naar de server. Verder beschikt deze machine over de volgende specificaties: Intel Core2 Duo P7350 @ 2.00GHz, 4GB RAM, Windows 7 Professional. Op Machine 2 draait de load balancer en de server waarvoor de responstijden worden gemeten. Deze machine beschikt over de volgende specificaties: Intel Pentium DualCore CPU T4300 @2.1GHz, 4GB RAM, Windows 7 Home Premium

63

Hoofdstuk 6. Evaluatie

64

Op Machine 3 draaien de verschillende servers. Het beschikt over de volgende specificaties: AMD Athlon 64 X2 6400+ @3.12GHz, 3GB RAM, Windows 7 Professional

Machine 3

Machine 2

Load balancer Test server

Servers

Router (100MB/s)

Machine 1

Clients

Figuur 6.1: Evaluatie opstelling

Er dient opgemerkt te worden dat de responstijd aan de gebruikszijde steeds gemeten wordt ten opzichte van de server die op machine 2 draait zodat de responstijd niet lijdt onder het CPU gebruik van andere server instanties, wat het geval kan zijn bij Machine 3.

6.1.2

De server werklast

Als gekozen werklast aan de serverzijde wordt in de Augmented Reality sfeer gebleven. De gebruiker krijgt de mogelijkheid zijn coördinaten door te sturen zodat kan opgezocht en berekend worden welke POI’s dicht bij de gebruiker gelegen zijn. De workflow ziet er als volgt uit:

1. De gebruiker stuurt zijn coördinaten door naar de server. 2. De server zoekt omliggende voorgedefinieerde locaties binnen een bepaalde straal en stuurt deze door (met geringe informatie) naar de gebruiker. 3. De gebruiker vraagt extra informatie op over één van toegestuurde locaties. 4. De server haalt extra informatie op en stuurt deze terug naar de gebruiker. Waarbij elke gebruiker om de vijf seconden een locatie-update doet. Aan de serverzijde wordt gebruik gemaakt van een Thread Pool [75] om het aantal parallelle oproepen te beperken, zodat meerdere server-subsystemen kunnen draaien op eenzelfde machine. Om een databanktoegang te simuleren wordt de uitvoerende draad per oproep even in slaapmodus gebracht.


6.2

65

Scenarios

In deze sectie worden de resultaten van de verschillende scenario’s samen met hun resultaten besproken. De eerste drie scenario’s evalueren het load balancer-subsysteem, de laatste twee scenario’s meten de performantie van het volledige communicatiesysteem. Om de load balancer te testen wordt het verschil in responstijd onderzocht bij een systeem met en zonder load balancer. Waarbij het aantal gebruikers die oproepen doen naar de server(s) toeneemt en de overhead op basis van toekenningstijd en geheugen die hiermee gepaard gaan gemeten wordt.

6.2.1

Scenario 1

Het doel van dit scenario is om na te gaan of er effectief nood is aan een load balancer die de werklast verdeelt. Een systeem zonder load balancer wordt opgezet bestaande uit één server en meerdere gebruikers die periodiek een oproep doen naar de server, waarbij het aantal gebruikers toeneemt. Figuur 6.2 toont het resultaat. Het valt duidelijk af te lezen dat de responstijd lineair stijgt naarmate het aantal gebruikers stijgt en dus het aantal oproepen toeneemt. 5000 4500 responstijd (ms)

4000 3500 3000 2500 2000

gemiddelde RTT

1500 1000 500 0 0

1000

2000

3000

4000

5000

6000

7000

8000

#clients

Figuur 6.2: Scenario 1: Responstijd

Dit resultaat bevestigt de verwachtingen en zal later gebruikt worden om de vergelijking te maken met de scenario’s waar een load balancer wel wordt gebruikt. De responstijd bedraagt al ongeveer 4 seconden wanneer 7000 gebruikers simultaan oproepen doen. Dit is net nog acceptabel maar wegens het lineair karakter van de curve kan de lijn door getrokken worden en bij 20000 gebruikers wordt dan een responstijd verwacht van ongeveer 10 seconden. Dit resultaat werd bekomen door telkens 150 nieuwe gebruikers op te starten en voor deze extra gebruikers 34 metingen op te nemen. Uit deze metingen wordt een gemid-


66

delde waarde berekend waarbij de eerste twee en laatste twee metingen niet opgenomen worden. Deze dienen als opwarmings- en afkoelingsfase.

6.2.2

Scenario 2

In dit scenario wordt de load balancer ge¨ıntroduceerd. Er wordt gekeken hoe de responstijd daalt indien er meer servers geregistreerd zijn bij de load balancer. Waarbij dezelfde reeks van gebruikers wordt aangewend als in Scenario 1. Uit Scenario 1 was het mogelijk te besluiten dat het nodig is de werklast te verspreiden over meerdere machines als het aantal gebruikers toeneemt. Er wordt opnieuw gebruik gemaakt van dezelfde reeks gebruikers maar het aantal servers neemt ditmaal ook toe. Er wordt gemeten welke invloed de toename van de servers heeft op de responstijd. In figuur 6.3 worden deze responstijden gepresenteerd. 4500 4000 responstijd (ms)

3500

3000 2500

1 server

2000

2 servers

1500

3 servers

1000

4 servers

500 0 0

2000

4000

6000

8000

#clients Figuur 6.3: Scenario 2: Responstijd

Wanneer slecht één server wordt gebruikt wordt natuurlijk hetzelfde gedrag ondervonden als in Scenario 1. Het is duidelijk dat de responstijd daalt naarmate meer servers gebruikt worden. Theoretisch gezien kan gesteld worden dat de responstijd voor i servers moet gelijk zijn aan responstijdinitieel /i omdat de werklast over i servers verdeelt wordt, met responstijdinitieel de responstijd uit scenario 1 . In tabel 6.1 wordt de vergelijking gemaakt tussen de theoretische responstijd en de gemeten responstijden. Een geval met 7000 gebruikers wordt bekeken. Er kan besloten worden dat het algemene gedrag terug te vinden is in tabel 6.1 grotendeels voldoet aan de verwachtingen. Toch kan er verschil in theoretische en praktische responstijd gemeten worden. Bij 3 servers wordt bijna een verschil van 100 ms gemeten.


67

Tabel 6.1: Vergelijking theoretische en praktische responstijd

i theoretische responstijd(ms) 1 3970 2 1985 3 1323 4 992

praktische responstijd(ms) 3970 1875 1428 844

Dit lijkt veel maar aangezien dit slechts een afwijking is van minder dan 10% kan deze variatie vermoedelijk verklaard worden door variaties in de belasting van het netwerk of het systeem. Dit resultaat werd op dezelfde manier bekomen als bij scenario 1. Waarbij de metingen voor elk aantal servers diende herhaald te worden.

6.2.3

Scenario 3

Scenario 3 bekijkt de keerzijde van de medaille waarbij onderzocht wordt hoe lang het duurt om een server toegewezen te krijgen door de load balancer en hoeveel geheugen moet gereserveerd worden indien men wenst gebruik te maken van een load balancer. In figuur 6.4 zijn de responstijden uitgezet voor de verschillende gevallen uit scenario 1 en scenario 2. Deze keer wordt ook de toekenningstijd van een server aan de gebruiker door de load balancer in rekening gebracht. Deze toekenning moet in de meeste gevallen maar één keer gebeuren maar er kan pas van een tijdswinst gesproken worden bij meer dan 2000 gebruikers. 5000 4500 responstijd (ms)

4000 3500 3000

zonder LB

2500

LB_1server

2000

LB_2servers

1500

LB_3servers

1000

LB_4servers

500 0 0

2000

4000

6000

8000

#clients

Figuur 6.4: Scenario 3: Responstijd

Er dient wel extra benadrukt te worden dat dergelijke responstijden zich enkel voordoen als de gebruiker nog geen server toegekend kreeg op het moment dat hij een oproep wil


68

doen naar de server. In de andere gevallen kan terug gevallen worden op de resultaten uit figuur 6.3. Toekenningstijd Wanneer een gebruiker online komt krijgt hij een server toegekend. De selectie van deze server kan op verschillende manier gebeuren maar in dit specifieke geval zal de load balancer een server kiezen die op dat moment het minst gebruikers bedient. Een alternatief zou zijn om telkens de volgende server te kiezen, ook wel Round Robin genoemd. Een tweede scenario waar de toekenning van een server gebeurt, is het geval dat de vorige server offline gaat, dit wordt besproken in sectie 6.2.4 In figuur 6.5 worden de toekenningstijden uitgezet in functie van het aantal gebruikers en geregistreerde servers. Er dient opgemerkt te worden dat dit de toekenningstijd is wanneer de gebruiker voor de eerste keer online komt. Dit impliceert dat de toekenningstijd bestaat uit de nodige tijd om de client te registreren bij de load balancer en de tijd voor de effectieve toekenning van een server. In theorie wordt verwacht dat het aantal gebruikers weinig invloed heeft op deze toekenning, omdat enkel de verschillende servers overlopen worden en gekeken worden hoeveel clients bij elke server geregistreerd zijn. Een complexiteit van O(n) kan verwacht worden met n het aantal geregisteerde servers. 600

toekenningstijd (ms)

500

400 1server

300

2servers

200

3servers 4servers

100 0 1000

2000

3000

4000

5000

6000

#clients

Figuur 6.5: Scenario 3: Toekenningstijd

In de figuur is geen echte stijging in tijdsduur zichtbaar naarmate het aantal servers stijgt wat te verklaren is door het feit dat er slechts een heel klein aantal servers gebruikt wordt. Verder wordt er wel een kleine stijging gemeten als het aantal gebruikers toeneemt. Dit is vermoedelijk afkomstig van de belasting van het systeem.


69

Deze voorgaande metingen werden op dezelfde manier bekomen als in scenario 2. Waarbij een onderscheid in toekenningstijd en uitvoeringstijd werd gemaakt.

Geheugen

geheugen (MB)

Het is ook belangrijk na te gaan hoeveel geheugen het load balancer systeem inneemt als het aantal geregistreerde gebruikers stijgt. Zo kan een beeld gevormd worden van het aantal gebruikers die kunnen geregistreerd worden bij een bepaald systeem. Figuur 6.6 toont hoe het geheugen stijgt bij toename van het aantal gebruikers. Er wordt terug

600 400 200 0 0

2000

4000

6000

8000

#clients Figuur 6.6: Scenario 3: Geheugen overhead

een lineaire stijging gevonden wat goed is om het gedrag te voorspellen bij een bepaald aantal gebruikers. Bij 10000 gebruikers wordt wel al een geheugengebruik van 750 MB gemeten. Als deze lijn doorgetrokken wordt, bekomt men de resultaten uit figuur 6.7 bekomen. Waar er voor 100000 gebruikers al 6 GB geheugen moet voorzien worden. Indien verwacht wordt ooit meer dan één miljoen gebruikers te behandelen moeten een systeem voorzien worden meer met 60 GB geheugen enkel voor de load balancer. Er dient wel opgemerkt te worden dat hier een worst-case scenario gemeten wordt, waarbij het aantal gebruikers zich op hetzelfde moment registeren bij de load balancer. Het geheugen stijgt naarmate de gebruikers toenemen omdat de load balancer op elk moment een connectie moet kunnen maken met elke geregistreerde gebruiker en server. Dit is nodig om te kunnen detecteren wanneer een server weggevallen is en om snel een nieuwe te kunnen toekennen aan de gebruikers. Dit laatste resultaat werd bekomen door in de load balancer het geheugengebruik te meten telkens als een nieuwe client zich registreert. Aangezien het geheugengebruik fluctueert door de Java Garbadge Collection werden enkel de maxima in rekening gebracht. Over een set van 1000 gebruikers werd het maximum berekend en deze waarde werd gebruikt in de grafiek. Om het communicatiesysteem van het client-subsysteem te evalueren worden verschillende scenario’s opgesteld om zowel de voorals nadelen van het systeem te benadrukken.


70

7000

geheugen (MB)

6000 5000 4000

3000 2000 1000

0 0

20000

40000

60000

80000

100000

120000

#clients Figuur 6.7: Scenario 3: Geheugen overhead (interpolatie)

6.2.4

Scenario 4

Dit scenario heeft als doel het verschil in responstijd te meten als een server al dan niet uitvalt. In dit scenario wordt gemeten hoelang het duurt eer een gebruiker wordt voorzien van een antwoord op een serveroproep wanneer de server in kwestie tijdens de oproep uitvalt. Waarbij in het geval dat de gebruikte server wel uitvalt nog een nieuwe server moet toegekend worden. In figuur 6.8 wordt de effectieve responstijd uitgezet waarbij de vergelijking gemaakt wordt tussen het geval dat de servers niet uitvalt en het geval dat de server wel uitvalt en een nieuwe server moet toegekend worden door de load balancer. De oproep naar de server wordt langs de gebruikerszijde altijd bewaard tot een antwoord gegenereerd wordt. Als de toegekende server uitvalt net op het moment dat de gebruiker een oproep doet naar deze server zal deze oproep aan de gebruikerszijde bewaard worden en opnieuw worden uitgevoerd wanneer een nieuwe server wordt toegekend. Een opmerkelijke stijging in responstijd wordt gemeten als het aantal gebruikers toeneemt. In de testopstelling voor dit scenario worden twee servers gebruikt waarbij de servers elk om beurt automatisch offline gehaald worden als een oproep wordt gedaan. Er kan dus gesteld worden dat het aantal gebruikers uit figuur 6.8 dan ook het aantal gebruikers zijn die geregistreerd zijn bij de online server. Als een oproep wordt gedaan naar deze server gaat die offline en ondertussen is de andere server terug actief zodat alle gebruikers die geregistreerd waren bij de initiële server nu geregistreerd worden bij de nieuwe server. Al deze gebruikers dienen verwittigd te worden dat een andere server kan gebruikt worden. Het is net het overlopen van deze lijst met gebruikers en de gebruikers verwittigen wat steeds tijdrovender wordt naarmate het aantal gebruikers stijgt. Wanneer een tweede oproep wordt gedaan naar de nieuwe server berekent deze wel het resultaat zonder offline te gaan. Het onderscheid wordt gemaakt op basis van een meegegeven parameter.


71

4500

4000 3500 tijd (ms)

3000 2500 2000

zonder falen server

1500

met falen server

1000

500 0 156

312

625 1250 2500 5000 10000 20000 #clients Figuur 6.8: Scenario 4: Responstijd

Deze resultaten werden bekomen door het aantal gebruikers telkens te laten verdubbelen en terug 34 metingen uit te voeren waarvan de eerste en laatste twee niet in beschouwing werden genomen.

6.2.5

Scenario 5

Tenslotte wordt nagegaan of het bewaren van de oproepen naar de server langs de gebruikerszijde niet tot een geheugen overbelasting kan leiden. Als een gebruiker een oproep doet naar de server dan wordt deze in een queue geplaatst en pas verwijderd als een antwoord verkregen wordt van de server. Maar als er tijdelijk geen servers actief zijn en de gebruiker toch blijft oproepen doen, dan moeten er steeds meer oproepen bewaard worden. In dit scenario wordt gemeten of het bewaren van deze oproepen niet problematisch kan worden als er lange tijd geen server actief is. De grootte van één oproep-object wordt bepaald door het weg te schrijven naar het geheugen. De grootte van een dergelijk bericht bedraagt ongeveer 428 bytes. Dit is eerder miniem, maar ook te verklaren aangezien de nodige informatie zo summier mogelijk is gehouden. Enkel de volgende zaken worden behouden: De interface waarop een oproep dient gemaakt te worden. De naam van de methode. Een object met de nodige parameters.

De grootte van dit object is wel afhankelijk van het aantal en type parameters. Indien er continue beeldmateriaal verstuurd wordt zal een heel ander resultaat bekomen worden.


72

Een oplossing voor dergelijke parameters zou zijn ze weg te schrijven naar de schijf en enkel terug in te laden als er opnieuw verbinding is met een server. Figuur 6.9 wordt gegenereerd om een idee te geven hoeveel geheugen zal ingenomen worden bij een bepaald aantal bewaarde oproepen. Bij 1000 bewaarde oproepen zal ongeveer 418 kB gebruikt worden. Als om de 5 seconden een oproep gedaan wordt, is dit al na 83 minuten. Als de lijn doorgetrokken wordt en de servers een hele dag offline zijn zal toch al ongeveer 7 MB aan opgeslagen oproepen gebruikt worden.

geheugen(kB)

450 400 350 300 250 200 150 100 50 0 -200 -50 0

200

400

600

800

1000

1200

#bewaarde oproepen

Figuur 6.9: Scenario 5: Geheugen overhead

6.3

Besluit

Er kan besloten worden dat de prestatie van de load balancer sterk afhankelijk is van het aantal gebruikers. Het is wel een goede zaak dat een lineaire verhouding waargenomen wordt, zodat kan worden voorspeld hoeveel en welke infrastructuur nodig is. Het voordeel dat de load balancer bijhoudt welke gebruikers en servers online zijn, heeft ook nadelen. Zo is een infrastructuur met heel veel geheugen nodig om ons systeem op grote schaal te gebruiken. Verder kan gesteld worden dat het grootste prestatie verlies afkomstig is van het herverdelen van de gebruikers over de overige servers indien een server offline gaat. De gebruikerszijde zelf ondervindt weinig negatieve invloed door gebruik te maken van dit communicatiesysteem. Zo heeft de gebruiker geen last wanneer een gebruikte server offline gaat. Het bewaren van oproepen naar de server kan efficiënt gebeuren, zodat het systeem geen negatieve invloed heeft op vlak van geheugengebruik. Maar algemeen is de responstijd natuurlijk afhankelijk van het aantal gebruikers. Deze evaluatie richt zich vooral op de kwaliteitsattributen Scalability en Availability uit hoofdstuk 2. De andere kwaliteitsattributen als Extensibility, Modifiability en Resua-


73

bility zijn echter moeilijk te meten en werden daarom niet in de evaluatie opgenomen. Het blijkt dat de introductie van de load balancer het systeem perfect schaalbaar maakt. Zoals gezien in scenario 2 kan de totale werklast verdeeld worden door het aantal actieve servers. Op vlak van Availability werd aangetoond dat het systeem perfect in staat is de gebruiker van een nieuwe server te voorzien als deze uitvalt. Ook het communicatiesysteem aan de gebruikerszijde zorgt er effectief voor dat een oproep naar de server niet verloren gaat. Deze technieken hebben echter weinig invloed op de performantie van het systeem. Zoals gezien in scenario 4 stijgt de herverdelingstijd wel naarmate het aantal gebruikers toeneemt. Aangezien er zonder load balancer helemaal geen verbinding met een server mogelijk was, is deze overhead toegestaan.


74

Hoofdstuk 7 Verdere ontwikkelingen Met oog op verdere ontwikkelingen worden nog enkele elementen aangehaald voor verder onderzoek. Deze werden in dit onderzoek niet uitgewerkt omdat ze buiten het bestek van deze masterproef vallen.

7.1

De load balancer als zwakke schakel

Zoals aangehaald in sectie 4.4 beschikt het load balancer-subsysteem over een totaal zicht op de aanwezige clients en servers. Dit is mogelijk omdat zowel de clients als servers zich registeren bij de load balancer. Dit impliceert echter wel dat de load balancer de zwakste schakel van het systeem wordt. Indien de load balancer faalt is er geen communicatie mogelijk tussen de verschillende subsystemen. Daarom is het nodig een mechanisme te voorzien zodat de informatie, omvat in het load balancersubsysteem, kan verspreid worden over meerdere instanties. Zodat bij het falen van het load balancer-subsysteem al deze informatie niet verloren gaat.

7.2

Dynamische generatie van ID’s

De verschillende clients en servers worden momenteel onderscheiden aan de hand van hun ID. Dit ID wordt meegegeven als argument bij het starten van elk subsysteem. In de praktijk zal een gebruiker natuurlijk niet weten welke ID nog vrij te gebruiken is. Daarom wordt een systeem aangeraden waarbij de load balancer kan ID’s toekennen aan de clients en servers. De load balancer die toch beschikt over een totaal overzicht van alle subsystemen kan gemakkelijk bepalen welke ID’s al gebruikt zijn en op basis van deze data een unieke ID generen voor elke client en server.

7.3

Datasysteem

In het huidige systeem het is het data-subsysteem niet uitgewerkt. Dit impliceert echter dat het momenteel nog niet mogelijk is te communiceren met een databank. Aangezien het ophalen en bewaren van data in een databank belangrijk is, dient dit systeem nog 75

Hoofdstuk 7. Verdere ontwikkelingen

76

verder ontwikkeld te worden. Omdat de clients verspreid zijn over meerdere servers is het enkel mogelijk om te gaan met globale data via het data-subsysteem.

7.4

Beveiliging

Momenteel wordt geen rekening gehouden met beveiliging. Zo is het niet mogelijk om een beveiligde communicatie op te zetten tussen client en server. De authenticatie van een client gebeurt aan de hand van een simpel ID wat gemakkelijk kan vervalst worden. Ook worden er geen mechanismen voorzien om gevoelige data op een veilige manier tijdelijk te kunnen bewaren aan de server kant.

7.5

Technologie¨ en en frameworks

Gezien de beperkte kennis van OSGi werd initieel gekozen om Eclipse Equinox te gebruiken, zowel aan de gebruikers- als serverzijde. Zoals gezien in sectie 3.2.1 is de Concierge implementatie van OSGi veel compacter wat zijn voordelen kan hebben op een mobiel apparaat wat meestal beperkt is in geheugen en opslagcapaciteit. Als verdere ontwikkeling kan gepoogd worden om bij de client gebruik te maken van deze compactere implementatie. Ook werd gebruik gemaakt van SOAP als communicatie protocol. Dit was eerder een noodzaak dan een vrije keuze, zie sectie 3.5. Als verdere ontwikkeling kan overgestapt worden van SOAP naar REST aangezien REST minder data verbruikt. Het dataverbruik wordt op een mobiel toestel best gelimiteerd omdat een mobiel systeem vaak afhankelijk is van een tariefplan bij het verbuiken van data.

Hoofdstuk 8 Conclusie Het doel van deze masterproef bestond erin een framework voor gedistribueerde Augmented Reality applicaties te ontwikkelen. Waarbij het de bedoeling was een basisstructuur op te stellen waaruit vertrokken kan worden bij het bouwen van een Augmented Reality applicatie. Uit het state-of-the-art onderzoek bleek dat weinig hedendaagse Augmented Reality frameworks het toe laten functionaliteit te integreren in de cloud. Nochtans zorgt dit ervoor dat rekenintensieve bewerkingen niet meer op het toestel van de gebruiker dienen te gebeuren. Verder laten deze frameworks weinig uitbreiding toe zodat men meestal vast zit aan een voorgedefinieerde set van mogelijke programma’s. Bij het ontwerpen werd vooral aandacht besteed aan de uitbreidbaarheid van het framework. Aangezien enkel een basissstructuur aangeboden wordt moet het mogelijk zijn extra componenten en functionaliteit toe te voegen. Even belangrijk was om het framework zo modulair mogelijk te houden. De basisstructuur bestaat al uit een aantal goed gedefinieerde componenten. Door enkel de interfaces van deze componenten te specificeren laat het framework het toe nieuwe implementaties van bestaande componenten te gebruiken. Er kan gesteld worden dat de structuur en implementatie zoveel mogelijk gescheiden werd. Ook werden maatregelen getroffen op vlak van Scalability en Availability. Zo werd een load balancer ontwikkelt die beschikt over meerdere servers die kunnen toegekend worden aan de verschillende clients. Als een server uitvalt worden de clients die gebruik maakten van deze server spontaan van een andere server voorzien. De load balancer laat ook toe het systeem te schalen als het aantal aanvragen te hoog of te laag wordt. Door gebruik te maken van OSGi kan de aangeboden modulariteit extra benut worden. OSGi laat toe at runtime componenten die voldoen aan een voorgedefinieerde interface toe te voegen of aan te passen. Hierdoor wordt het onder andere ook mogelijk het systeem van een update te voorzien zonder dat het systeem hoeft gestopt te worden. Door gebruik te maken van OSGi kan elke client en server zich laten registeren als een service bij de load balancer, zodat de load balancer een compleet beeld krijgt van de aanwezige subsystemen. OSGi verzorgt ook de detectie van gestarte of gestopte services zodat de load balancer maatregelen kan nemen als een server uitvalt. 77

Hoofdstuk 8. Conclusie

78

Tot slot biedt het client-subsysteem enkele communicatietechnieken aan die een antwoord op een oproep garanderen, zelfs als de gebruikte server uitvalt. Uit de evaluatie van het aangeboden communicatiesysteem, dat zowel bestaat uit de communicatietechnieken uit het client-subsysteem als de methoden aangeboden in de load balancer, kon besloten worden dat het systeem zowel voorals nadelen met zich meebrengt. De grootste voordelen worden gevonden bij het automatisch toekennen van een server en het bewaren van oproepen aan de gebruikerszijde. Om deze automatische toekenning te realiseren moet de load balancer data bewaren over alle clients en servers, dit zorgt ervoor dat het geheugengebruik sterk stijgt naarmate het aantal clients en servers toeneemt. Er kan besloten worden dat dit framework een positieve invloed kan hebben op de evolutie en diversiteit van Augmented Reality applicaties. Het aangepaste communicatiesysteem laat toe schaalbare applicaties met een hoge beschikbaarheid te ontwikkelen die kunnen genieten van de extra rekenkracht aangeboden in de cloud infrastructuur. Dit impliceert dat meer geavanceerde en complexere Augmented Reality applicaties kunnen verwacht worden.

Bibliografie [1] Intel, “Discover a tablet that moves as fast as you do.” http://www.intel. com/content/www/us/en/tablets/tablets.html, 10 2012. [2] ARM, “The architecture for the digital world.” http://www.arm.com/ products/processors/index.php, 10 2012. [3] F. K. Paul Milgram, “A taxonomy of mixed reality visual displays,” 1994. [4] “Artoolkit.” http://www.hitl.washington.edu/artoolkit/, 12 2012. [5] Layar, “Layar official website.” http://www.layar.com/, 10 2012. [6] Wikitude, “The world’s leading augmented reality sdk.” http://www. wikitude.com/, 10 2012. [7] M. P. Subway, “Paris metro augmented reality application.” http://www. metroparisiphone.com/index_en.html, 4 2013. [8] C. M. R. Giordanelli, “The cloud computing paradigm: Characteristics, opportunities and research issues,” pp. 3–4, 2010. [9] Google, “Gmail.” mail.google.com, 10 2012. [10] Wikipedia, “De vrije encyclopedie.” http://nl.wikipedia.org/wiki/ Hoofdpagina, 10 2012. [11] Facebook, “Facebook.” www.facebook.com, 10 2012. [12] Google, “Google app engine.” https://appengine.google.com, 10 2012. [13] Microsoft, “Windows azure.” http://www.windowsazure.com/, 10 2012. [14] E. Yard, “Engine yard platform as a service.” https://www.engineyard. com/, 10 2012. [15] Amazon, “Amazon web services.” http://aws.amazon.com/, 10 2012. [16] GoGrid, “Complex infrastrure made easy.” http://www.gogrid.com/, 10 2012. [17] RightScale, “Cloud management.” http://www.rightscale.com/, 10 2012. 79

Bibliografie

80

[18] S. Klepper, “Augmented reality - display systems,” 2007. [19] agi, “Satellite ar: Satellite tracking with augmented reality on android.” http: //satar.agi.com/MobileApps/about.htm, 10 2012. [20] iOnRoad, “Smart phone, smart driver.” http://www.ionroad.com/, 10 2012. [21] Yelp, “Yelp is the best way to find great local businesses.” http://www.yelp. com/, 10 2012. [22] “Mixare, an open source augmented reality engine.” http://www.mixare. org/, 10 2012. [23] “Augmented reality sdk for app development.” http://www.metaio.com/ home/, 10 2012. [24] “Kharma- kml/html augmented reality mobile architecture.” https:// research.cc.gatech.edu/kharma/content/home, 10 2012. [25] Qualcomm, “Augmented reality (vuforia).” https://developer. qualcomm.com/mobile-development/mobile-technologies/ augmented-reality, 10 2012. [26] P. Mell and T. Grance, “The NIST Definition of Cloud Computing,” tech. rep., July 2009. [27] T. Lorido-Botrán, J. Miguel-Alonso, and J. A. Lozano, “Auto-scaling Techniques for Elastic Applications in Cloud Environments,” Research EHU-KAT-IK, Department of Computer Architecture and Technology, UPV/EHU, 2012. [28] D. Rubio, “Web application performance and scalability. with cloud computing services, non-rdbms data storage and multi-core.” [29] M. Ferdman, A. Adileh, Y. O. Ko¸cberber, S. Volos, M. Alisafaee, D. Jevdjic, C. Kaynak, A. D. Popescu, A. Ailamaki, and B. Falsafi, “Clearing the clouds: a study of emerging scale-out workloads on modern hardware,” in ASPLOS, pp. 37– 48, 2012. [30] J. Varia, Architecting for the Cloud: Best Practices, Jan. 2010. [31] L. Bass, P. Clements, and R. Kazman, Software architecture in practice. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1998. [32] J. Scott and R. Kazman, Realizing and Refining Architectural Tactics: Availability. Technical report, Carnegie Mellon University, Software Engineering Institute, 2009. [33] V. Cardellini, R. I, M. Colajanni, and P. S. Yu, “Dynamic load balancing on web-server systems,” IEEE Internet Computing, vol. 3, pp. 28–39, 1999. [34] W. Tarreau, “Making applications scalable with load balancing,” 2006.

Bibliografie

81

[35] K. J. Sullivan, W. G. Griswold, Y. Cai, and B. Hallen, “The structure and value of modularity in software design,” SIGSOFT Softw. Eng. Notes, vol. 26, pp. 99–108, Sept. 2001. [36] R. S. Pressman, Software Engineering: A Practitioner’s Approach. McGraw-Hill Higher Education, 5th ed., 2001. [37] S. Tripakis, “Modular code generation from synchronous block diagrams: Modularity vs. reusability vs. code size,” February 2009. [38] “Osgi official website.” http://www.osgi.org/Main/HomePage, 11 2012. [39] The OSGi Alliance, “OSGi service platform core specification, release 4.3,” 2011. [40] Knopflerfish, “Knopflerfish project.” http://www.knopflerfish.org, 11 2012. [41] A. S. Foundation, “Apache felix.” http://felix.apache.org/, 11 2012. [42] ETH, “Concierge osgi.” http://concierge.sourceforge.net/, 10 2012. [43] E. Foundation, “Equinox.” http://www.eclipse.org/equinox/, 10 2012. [44] Eclipse, “Rich client platform.” http://wiki.eclipse.org/index.php/ Rich_Client_Platform, 1 2013. [45] The OSGi Alliance, “OSGi service platform service compendium , release 4.3,” 2011. [46] Apache, “Apache cxf distributed distributed-osgi.html, 12 2012.

osgi.”

http://cxf.apache.org/

[47] Eclipse, “Eclipse communication framework project.” http://www.eclipse. org/ecf/, 12 2012. [48] F. D. T. Bart Dhoedt, Ontwerp van Gedistribueerde Software. [49] Oracle, “Java ee.” http://www.oracle.com/technetwork/java/ javaee/overview/index.html, 10 2012. [50] S. Source, “Spring.” http://www.springsource.org/, 10 2012. [51] e. a. Rod Johnson, Juergen Hoeller, “The spring framework - reference documentation.” http://static.springsource.org/spring/docs/2.5.4/ reference/, 10 2012. [52] S. Source, “An introduction to spring.” http://static.springsource. org/spring/docs/2.5.3/reference/introduction.html, 10 2012. [53] e. a. Surekha Durvasula, Martin Guttmann, “Soa practitioners guide.” http: //www.soablueprint.com/whitepapers/SOAPGPart2.htm, 4 2013.

Bibliografie

82

[54] Oracle, “Remote method invocation home.” http://www.oracle.com/ technetwork/java/javase/tech/index-jsp-136424.html, 4 2013. [55] U. of Washington Bothell, “Function pass by value vs. pass by reference.” http://courses.washington.edu/css342/zander/css332/ passby.html, 5 2013. [56] P. Bakker, “Restful webservices, een serieus alternatief voor soap?,” pp. 12–18, june 2008. [57] D. Wagner and D. Schmalstieg, “Artoolkitplus for pose tracking on mobile devices,” 2007. [58] S. Audet, “Javacv.” http://code.google.com/p/javacv/, 12 2012. [59] Z. Xiang and et al., “A wireless lan-based indoor positioning technology,” 2004. [60] K. Kunze, P. Lukowicz, K. Partridge, and B. Begole, “Which way am i facing: Inferring horizontal device orientation from an accelerometer signal,” in Proceedings of the 2009 International Symposium on Wearable Computers, ISWC ’09, (Washington, DC, USA), pp. 149–150, IEEE Computer Society, 2009. [61] M. Bhide, P. Deolasee, A. Katkar, A. Panchbudhe, K. Ramamritham, and P. Shenoy, “Adaptive push-pull: disseminating dynamic web data,” Computers, IEEE Transactions on, vol. 51, no. 6, pp. 652–668, 2002. [62] J. Rumbaugh, I. Jacobson, and G. Booch, Unified Modeling Language Reference Manual, The (2nd Edition). Pearson Higher Education, 2004. [63] M. B. Kent Beck, “Manifesto for agile software development.” "http:// agilemanifesto.org/, 5 2013. [64] O. C. Wiki, “Remote service admin.” http://wiki.osgi.org/wiki/ Remote_Service_Admin, 5 2013. [65] openSLP, “Service location protocol.” http://www.openslp.org/, 5 2013. [66] JGroups, “A toolkit for reliable multicast communication.” http://www. jgroups.org/, 5 2013. [67] P. Hunt, M. Konar, F. P. Junqueira, and B. Reed, “Zookeeper: Wait-free coordination for internet-scale systems,” in In USENIX Annual Technical Conference. [68] Apache, “Apache zookeeper.” http://zookeeper.apache.org/, 2 2013. [69] OSGi, “Interface filter.” http://www.osgi.org/javadoc/r4v43/core/ org/osgi/framework/Filter.html, 3 2013. [70] Microsoft, “Search filter syntax.” http://msdn.microsoft.com/en-us/ library/windows/desktop/aa746475(v=vs.85).aspx", 3 2013.

Bibliografie

83

[71] Oracle, “Java reflection.” http://docs.oracle.com/javase/6/docs/ technotes/guides/reflection/, 3 2013. [72] S. H. Ahn, “Opengl transformation.” http://www.songho.ca/opengl/gl_ transform.html. [73] “Runinstances on amazon aws.” http://docs.aws.amazon.com/AWSEC2/ latest/APIReference/ApiReference-query-RunInstances.html, June 2013. [74] “Amazon machine images (amis).” https://aws.amazon.com/amis, June 2013. [75] Oracle, “Thread pools.” http://docs.oracle.com/javase/tutorial/ essential/concurrency/pools.html/, 4 2013.

Bibliografie

84

Lijst van figuren 1.1 1.2

Marker gebaseerde AR [4] . . . . . . . . . . . . . . . . . . . . . . . . . Locatie gebaseerde AR [7] . . . . . . . . . . . . . . . . . . . . . . . . .

3 3

2.1

Functionele vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.1 3.2 3.3 3.4 3.5 3.6 3.7

Samenvatting availability tactieken OSGi architectuur [39] . . . . . . . OSGi levencyclus [39] . . . . . . . . Remote service architectuur [39] . . Overzicht van het Spring framework RMI architectuur [48] . . . . . . . . Voorbeeld van een marker . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

16 18 19 20 22 24 25

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15

Algemene structuur . . . . . . . . . . . . . . . Communicatie algemene structuur . . . . . . . Componentendiagram client . . . . . . . . . . Activiteitendiagram Client . . . . . . . . . . . Sequentie diagram Client met lokale service . Sequentie diagram Client met externe service . Componentendiagram server . . . . . . . . . . Activiteiten diagram server . . . . . . . . . . . Sequentie diagram Server . . . . . . . . . . . . Architectuur load balancer . . . . . . . . . . . Activiteiten diagram load balancer . . . . . . Sequentie-diagram: registratie server . . . . . Sequentie-diagram: registratie client . . . . . . Sequentie-diagram: de-registratie server . . . . Sequentie-diagram: de-registratie client . . . .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

30 31 32 37 38 38 40 42 43 44 45 46 47 47 48

5.1 5.2 5.3 5.4

Synchrone methode oproep . . . . . Pseudo-asynchrone methode oproep Asynchrone methode oproep . . . . Structuur OpenGL [72] . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

56 58 59 61

6.1 6.2 6.3

Evaluatie opstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scenario 1: Responstijd . . . . . . . . . . . . . . . . . . . . . . . . . . . Scenario 2: Responstijd . . . . . . . . . . . . . . . . . . . . . . . . . . .

64 65 66

85

. . . . . . . . . . . . [52] . . . . . .

. . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . .

Lijst van figuren 6.4 6.5 6.6 6.7 6.8 6.9

Scenario Scenario Scenario Scenario Scenario Scenario

86 3: 3: 3: 3: 4: 5:

Responstijd . . . . . . . . . . . . . Toekenningstijd . . . . . . . . . . Geheugen overhead . . . . . . . . Geheugen overhead (interpolatie) . Responstijd . . . . . . . . . . . . . Geheugen overhead . . . . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

67 68 69 70 71 72

Lijst van tabellen 6.1

Vergelijking theoretische en praktische responstijd . . . . . . . . . . . .

87

67

Cloud-enabled software framework voor on-the-move Augmented Reality

Recommend Documents