Automatisch inloggen via RFID en distribueren van gepersonaliseerde medische taken

Automatisch inloggen via RFID en distribueren van gepersonaliseerde medische taken Wouter Van Isterdael

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

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

Automatisch inloggen via RFID en distribueren van gepersonaliseerde medische taken Wouter Van Isterdael

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

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

Voorwoord Ongeveer een jaar geleden, woonde ik de presentaties over de thesisonderwerpen van INTEC bij. Vooral de masterproeven betreffende e-Health waren mij bijgebleven. De interesse in de RFID technologie was een belangrijke drijfveer om deze masterproef te kiezen en ook de concrete invulling heeft mij een heel jaar kunnen boeien.

Nu ik dit voorwoord schrijf, heb ik de gelegenheid om mensen die mij hebben geholpen bij het tot stand brengen van deze masterproef, te bedanken. Het was immers een lange periode en het liep niet altijd van een leien dakje. Ik wil hen dan ook graag uitdrukkelijk bedanken om mij extra te motiveren wanneer het moeizaam verliep.

Ik zou graag in de eerste plaats mijn thesisbegeleiders, ir. T. Dupont en ir. W. Kerckhove bedanken voor het advies en de steun in de loop van dit werk.

Ten tweede wil ik ook prof. dr. ir. F. De Truck en dr. ir. S. Van Hoecke bedanken voor het mogelijk maken van dit thesisonderwerp.

Daarnaast wil ik ook mijn vriendin Anke en mijn vrienden bedanken voor hun onvoorwaardelijke steun en voor de nodige ontspanning tijdens het maken van deze masterproef. Ik wil ook mijn ouders bedanken, die mij de kans hebben gegeven om de laatste vijf jaar deze opleiding te volgen en mij steeds ten volle gesteund hebben.

Tot slot wil ik ook nog mijn broers bedanken om mij steeds bij te staan met advies, alsook de mensen die hier niet vermeld zijn en toch een bron van steun zijn geweest.

Wouter Van Isterdael, mei 2010

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

“The author gives permission to make this master dissertation available for consultation and to copy parts of this master dissertation for personal use. In the case of any other use, the limitations of the copyright have to be respected, in particular with regard to the obligation to state expressly the source when quoting results from this master dissertation.”

Wouter Van Isterdael, mei 2010

Automatisch inloggen via RFID en distribueren van gepersonaliseerde medische taken door Wouter Van Isterdael Scriptie ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Academiejaar 2009–2010 Promotoren: prof. dr. ir. F. DE TURCK, dr. ir. S. VAN HOECKE Begeleiders: ir. T. Dupont, ir. W. Kerckhove Faculteit Ingenieurswetenschappen Universiteit Gent – Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. D. DE ZUTTER

Samenvatting Momenteel zijn er op de dienst Intensieve Zorg van het UZ Gent bedside pc’s voorzien bij elke patiënt. Via deze bedside pc’s kunnen medische diensten van het ICSP (Intensive Care Service Platform) geraadpleegd worden. In het huidige systeem is er nog geen inlogprocedure voorzien op deze bedside pc’s. Er is nood aan een snelle inlogprocedure. Daarnaast is het wenselijk om een takenapplicatie te integreren. Medisch personeel kan op deze manier efficiënt opdrachten aan elkaar doorgeven, zodat kostbare tijd kan bespaard worden. Een mogelijke oplossing voor deze twee problemen bestaat eruit om een RFID-inlogprocedure te voorzien die toegang geeft tot een takenapplicatie. Een groot voordeel aan RFID is dat een omslachtige inlogprocedure, waarbij de gebruiker zijn wachtwoord en naam moet intypen, omzeild wordt. De takenapplicatie zal een gedistribueerde takenapplicatie worden, waarbij aan serverside taken kunnen gewijzigd worden of gemaakt worden op basis van regelevaluatie. De regels voor deze evaluatie kunnen eenvoudig gecreëerd worden via een grafische regelcreatie-applicatie, die een uitbreiding vormt op de takenapplicatie. Binnen dit eindwerk wordt deze oplossing uigewerkt met behulp van gedistribueerde OSGi en een Drools rule-engine. Het meeste aandacht ging hierbij naar de aanpasbaarheid van de oplossing, alsook naar de gebruiksvriendelijkheid van de taken- en regelcreatie-applicatie.

Trefwoorden gedistribueerde takenapplicatie, regelgebaseerde systemen, COSARA, grafische regelcreatie, RFID, OSGi

Automatic RFID login procedure and distribution of personalized medical tasks Wouter Van Isterdael Supervisor(s): F. De Turck , S. Van Hoecke Abstract—Many medical departments are currently developing medical services that can be accessed through bedside computers. The informatisation in these departments opens up a huge area of possibilities. Authentication is a very important aspect of these bedside clients. Users should be able to login in a quick and accurate manner. Inter personnel communication can be facilitated by these new systems, increasing ease and efficiency of communication. This article describes an extendable RFID-based login architecture, which creates an abstraction layer towards the underlying hardware. It also describes a distributed task application, that can easily be integrated in an OSGi environment. This task application uses a rule-based component to change the priorities of tasks automatically. A possible rule editor implementation is also described. Keywords—Distributed task application, rule-based systems, COSARA, graphical rule editor, RFID login procedure, OSGi, distributed OSGi

I. I NTRODUCTION

T

HE Intensive Care Unit of the UZ Ghent is currently using a software services platform, the Intensive Care Service Platform (ICSP). This platform enables physicians and other medical personnel to base their decisions on a number of medical support services. The data provided by the different services is displayed on a monitor connected to a bedside computer. At the moment, the bedside computers do not provide a login procedure. To protect the patient’s privacy, it is important to design and develop a decent login procedure. Because of the critical nature of the services in this specific department, this procedure has to be quick and accurate. It would be very useful to integrate an efficient task application within the bedside client. The existing client runs within an OSGi container. The task application should enable personnel to assign tasks to other personnel. Tasks can be assigned to a specific member of the staff, or to a specific staff role. But tasks can also be general and for a specific patient, or for no patient at all. On creation, a task gets a certain priority. Based on information in the database, the priority of tasks can change automatically. For example, the priority of a task with an approaching deadline, should be increased to a higher level without user interference. The system should also be able to create tasks based on information within the database. First we take a closer look at the chosen technologies. Next is a summary of the architecture and implementation of the login procedure, task application and rule creation application and a discussion of the results. Finally, possible future improvements are described and discussed. II. T ECHNOLOGY This section briefly introduces the RFID and OSGi technology and covers the basics of rule-based systems. Next, the chosen solution is discussed aswell as how it can be integrated

within an OSGi environment such as the client platform. A. RFID RFID is a technology that uses radiowaves to identify objects or persons automatically with no requirement for line-ofsight. An RFID system consists of an antenna, a receiver and a transponder (usually called a tag) with identification information. The antenna emits signals to activate the tag and read the data on it. [1] B. OSGi OSGi specifies a Java based service platform, that can be remotely managed. This consists of a framework, that defines an application life cycle management model, modules, service registration capabilities and an execution environment. The unit of modularisation is the OSGi bundle. This consists of Java classes and resources combined with a manifest file, that specifies additional meta-data, e.g. external dependencies. OSGi devices can download, install and remove bundles. The framework manages the installations and dependencies dynamically. [2] The OSGi implementation used in the COSARA client is Apache Felix [3], a popular open source implementation of OSGi Release 4 core framework. Distributed OSGi, which allows bundles to invoke bundles in different OSGi containers, is implemented in R-OSGi and D-OSGi. This can be seen in figure 1. D-OSGi also allows classes from a non-OGSi environment to invoke these services remotely. [4] Felix OSGi Container

Equinox OSGi Container

CXF DOSGi

Service Interface Bundle

CXF DOSGi

Consumer Bundle

invoke

Service Bundle


Fig. 1. D-OSGi communication between two containers

C. Rule-based systems Rule-based systems are able to store knowledge and manipulate this knowledge to interpret information in a useful manner. It is made of four important components: the knowledge base, the rule or inference engine, the working memory and the user interface. The knowledge base is described by a set of rules. The rule engine evaluates rules and draws deductions from them, based on the information found in the working memory. In this

specific case, when the conditions of a rule are satisfied, a task’s priority will be changed or a task will be created. III. S OLUTION The solution provided in this article suggests an extendable RFID (Radio Frequency Identification) based login architecture. The system creates an abstraction layer towards the underlying hardware, enabling the use of multiple types of reader and tag hardware. A distributed task application with a rule-based component that can easily be integrated within an existing OSGi environment is proposed. This is extended by a graphical rule creation application, which enables medical personnel with limited or no background in rule-based systems, to create useful rules in a simple manner. A. System architecture To increase modifiability, a layered architecture was introduced. Functionality is split up between client and server. The server handles persistence operations and the evaluation of rules. D-OSGi is used to make these services available remotely. Clients handle the login procedure and present the information obtained from the remote services. The conceptual view of these layers is presented in figure 2 Database

= serverside

Rule file

= clientside

Rule Engine

Persistence layer

Business layer Login procedure

Task application

Rule file

Rule creation

Presentation layer Login GUI

Task GUI

Rule GUI

in, otherwise, the periodic questioning of the readers is restarted. • Task application: The task application architecture is rather simple. It addresses the remote services for task requests, and uses an MVC-pattern for presentation. Rule evaluation is handled serverside and operates directly on the information in the database. Drools, an open source rule management system, was chosen as business rule engine. [5] • Rule creation application: The rule creation application models rules in a recursive manner. Expressions are the building blocks: they can be combined by comparison and logical operators, forming new expressions and so forth. The application is loosely coupled to the current database, it can easily be adjusted to support generic rule creation. Usability was a very important quality attribute for this subapplication, so a lot of attention was paid to the user interface. The most important result is the architecture and implementation of this system that can easily be integrated within any OSGi environment with need of an RFID-based procedure and a distributed task application for its users. It allows rule creation in a straightforward manner, allowing users to add new business logic to the task application at runtime. IV. F UTURE DEVELOPMENTS The proposed solution forms a solid foundation for a practically usable system. However, a few subjects must be further elaborated on first: • Reader and tag support: only a limited amount of reader and tag types are supported in this prototype. However, the architecture allows to add new reader types with great ease. • Push mechanism: the distributed task application currently polls tasks periodically. This could be expanded by a push mechanism. The distributed event admin (D-OSGi), can be used to introduce this mechanism within the system. • Rule model: the rule model should be expanded to support more types of rules; rules of any form and rules with a different syntax. • Onsite tests: it is important to run onsite tests with the RFID hardware to ensure there is no electromagnetic interference with medical equipment. • Security: a security mechanism for the RFID-based login procedure has not yet been implemented. V. C ONCLUSION

Fig. 2. Conceptual view of the system

The login component, task application component and rule creation component are briefly introduced: • Login procedure: the login procedure system consists of a pipes-and-filter architecture. Readers are questioned periodically, to notice whether a tag is in reading range. When a tag is noticed, the tag data is passed to a filter. This filter can abstract multiple tag types and extract the identification information. Bundles interested in events from the filters (such as a change of the current read ID) can subscribe to these events, and will receive updates on change. The session manager bundle is one of these. This session manager is responsible for database communication: it invokes a remote loginservice, offered through D-OSGi. If the read ID is valid, the user is logged

This article proposes a generic solution for an automatic login procedure (or any other procedure) based on RFID and for distribution of personalized medical tasks. The rule-creation application allows users to intuitively add business logic to the task application. This solution can easily be integrated within OSGi environments and is easily accessible from non-OGSi environments, proving it to be an utterly useful plugin for any SOAbased platform with these specific needs. R EFERENCES [1] Roy Want, “RFID Explained: A Primer on Radio Frequency Identification Technologies”, United States of America, 2006. [2] The OSGi Alliance, “OSGi Service Platform Core Specification”, Release 4, Version 4.2, June 2009. [3] Felix Apache, http://felix.apache.org/. [4] Apache CXF D-OSGi, http://cxf.apache.org/distributed-osgi.html. [5] Drools, http://jboss.org/drools.

INHOUDSOPGAVE

i

Inhoudsopgave 1 Inleiding

1

1.1

Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Oplossing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2

1.3

Hoofdstukken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2 Specificatie 2.1

2.2

5

Vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.1.1

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

5

2.1.2

Niet-functionele vereisten . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.2.1

Actoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

2.2.2

Inlogprocedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

2.2.3

Takenapplicatie en gebruikersinteractie . . . . . . . . . . . . . . . . . . . .

11

2.2.4

Takenapplicatie met automatische prioriteitsassignatie en takencreatie . .

14

2.2.5

Regelcreatie-applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

3 Technologiestudie 3.1

21

RFID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

3.1.1

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

21

3.1.2

Variaties in RFID systemen . . . . . . . . . . . . . . . . . . . . . . . . . .

22

3.1.3

Werking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

3.1.4

Toepassingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

3.1.5

Problemen

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

26

3.1.6

Standaarden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

3.1.7

Frameworks en middleware . . . . . . . . . . . . . . . . . . . . . . . . . .

28

INHOUDSOPGAVE

3.1.8 3.2

3.3

3.4

3.5

ii

Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

XACML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.2.1

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

31

3.2.2

Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

Regelgebaseerde systemen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

3.3.1

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

31

3.3.2

Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

3.3.3

Rule engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

33

3.3.4

Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

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

35

3.4.1

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

35

3.4.2

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

37

3.4.3

D-OSGi en R-OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

3.4.4

Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

Takenophaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

3.5.1

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

41

3.5.2

Webservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

3.5.3

Event Admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

3.5.4

Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

4 Architectuur

45

4.1

Conceptuele View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

45

4.2

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

48

4.2.1

Package diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

4.2.2

Persistence :: Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

4.2.3

Persistence :: DAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

4.2.4

Persistence :: Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

4.2.5

Business :: Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

4.2.6

Business :: Taskapp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

4.2.7

Business :: Ruleapp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

59

4.2.8

Presentation :: Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

4.2.9

Presentation :: Taskapp . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

4.2.10 Presentation :: Ruleapp . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

INHOUDSOPGAVE

iii

4.2.11 Uitbreiding :: Regelevaluatie . . . . . . . . . . . . . . . . . . . . . . . . .

65

4.2.12 Uitbreiding :: Webservice . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

4.3

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

66

4.4

Collaboratie view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

4.4.1

Inlogprocedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

4.4.2


69

4.4.3

Takenapplicatie met automatische prioriteitsassignatie en takencreatie . .

70

4.4.4


71

5 Implementatie

72

5.1

Implementatiewijze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

5.2

Persistentie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

72

5.3

D-OSGi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73

5.3.1

Event admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

74

5.4

Inlogprocedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

76

5.5

Takenapplicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

77

5.6

Regelcreatie-applicatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

79

6 Evaluatie 6.1

6.2

83

Prestatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83

6.1.1

Rule engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

84

6.1.2

Persistentielaag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

89

Functioneel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

92

6.2.1

Inlogprocedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

92

6.2.2


93

6.2.3


93

6.2.4

Takenapplicatie met automatische prioriteitsassignatie . . . . . . . . . . .

93

7 Conclusie

94

7.1

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

94

7.2

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

96

A Rules voor prestatietests

97

Bibliografie

97

INHOUDSOPGAVE

Afkortingen API

Application Programming Interface

BIPT

Belgisch Instituut voor Postdiensten en Telecommunicatie

DAO

Data Access Object

DB

DataBase

D-OSGi

Distributed-OSGi

EPC

Electronic Product Code

HF

High Frequency

HID

Hughes Identification Devices

ICSP

Intensive Care Service Platform

ID

IDentification

INTEC

Department Of Information Technology

ISO

International Organization for Standardization

IZ

Intensieve Zorg

J2SE

Java 2 Standard Edition

JPA

Java Persistence API

LF

Low Frequency

MVC

Model View Controller

OASIS

Organization for the Advancement of Structured Information Standards

OO

Object Oriented

OS

Operating System

R-OSGi

Remote-OSGi

RFID

Radio Frequency Identification

SOA

Service Oriented Architecture

SOAP

Simple Object Access Protocol

iv

INHOUDSOPGAVE

UHF

Ultra High Frequency

XACML

eXtensible Access Control Markup Language

XMPP

eXtensible Messaging and Presence Protocol

UZ

Universitair Ziekenhuis

WS

WebService

WSDL

Web Service Description Language

v

INLEIDING

1

Hoofdstuk 1

Inleiding In dit inleidend hoofdstuk wordt kort de probleemstelling geformuleerd. Daarna volgt een bespreking van de voorgestelde oplossing, die daarna in dit boek wordt onderzocht en uitgewerkt. Om het hoofdstuk af te ronden, volgt nog een korte beschrijving van de verschillende hoofdstukken van dit boek.

1.1

Probleemstelling

De vakgroep Informatietechnologie (INTEC) heeft in samenwerking met de dienst Intensieve Zorg van het Universitair Ziekenhuis Gent een service platform ontwikkeld om artsen te assisteren bij de behandeling en opvolging van patiënten. Dit platform, het Intensive Care Service Platform of ICSP, integreert medische actoren die van belang zijn voor het stellen van een medische diagnose - labo’s, testresultaten, medische informatie en betrokken artsen en verpleegkundigen. De services van het ICSP geven de evolutie van de patiënt aan, berekenen scores ter indicatie van orgaanfalingen en bieden de arts belangrijke informatie. Op basis hiervan worden medische beslissingen gesuggereerd. De resultaten van de services kunnen geraadpleegd worden met behulp van een bedside pc.

Gezien de kritieke aard van de diensten op deze specifieke afdeling, is het uiterst belangrijk om snel en accuraat een diagnose te kunnen stellen. Het moet uiteraard ook gegarandeerd zijn dat de privacy van de patiënt bewaard blijft. Men moet verzekeren dat artsen en verpleegkundigen enkel toegang hebben tot de informatie betreffende hun patiënten en dat niet-medisch personeel geen toegang kan verkrijgen tot het platform. Bovendien is het ook belangrijk een

1.2 Oplossing

2

onderscheid te maken tussen de rollen van het medisch personeel; een verpleegkundige hoeft bijvoorbeeld niet dezelfde informatie te zien als een neuroloog. Het is dus belangrijk dat niet alle services voor alle personeelsleden beschikbaar zijn. Om deze redenen is het aangewezen een inlogprocedure te implementeren in de ICSP client applicatie. Door deze inlogprocedure te koppelen aan gebruikersprofielen, is het mogelijk om bepaalde modules binnen de client te activeren en persoonlijke en rolspecifieke boodschappen en taken weer te geven.

1.2

Oplossing

Deze inlogprocedure zou manueel kunnen verlopen, aan de hand van het intypen van een gebruikersnaam en paswoord, maar dit zou de snelheid van het inloggen in de weg staan. Daarom is het aangewezen te zoeken naar manieren om dit sneller en efficiënter te laten verlopen. In deze masterproef zal onderzocht worden hoe deze procedure kan geautomatiseerd worden door context-awareness te integreren binnen de ICSP applicatie. Hiervoor zal een technologiestudie uitgevoerd worden naar de mogelijkheden van RFID (Radio Frequency IDentification) readers en RFID tags en bijbehorende frameworks om deze automatisering tot stand te brengen, zoals ge¨ıllustreerd in figuur 1.1. Welcome Doctor John Doe! You have incomplete high priority tasks!

Figuur 1.1: Illustratie van inlogprocedure

1.2 Oplossing

3

De tags en readers die zullen gebruikt worden zijn gericht op manuele inlezing. Het is vereist om de tag (in de vorm van een identificatiekaart) voor een lezer te houden.

Verder zal er ook onderzocht worden hoe een efficiënt takensysteem kan ge¨ıntegreerd worden binnen het platform, voorgesteld in figuur 1.2. Dit systeem moet personeel in staat stellen om taken toe te wijzen aan ander personeel en deze te koppelen aan een deadline. Wanneer de deadline nadert en de taak nog niet uitgevoerd is, zal dit gemeld worden aan het betrokken personeelslid door middel van een popup. De taken zullen bijgehouden worden in een systeem gelijkend op een mailbox, zodat dat de toegewezen persoon kan nagaan welke taken hij of zij nog moet vervullen, alsook wat de status is van taken die door hem of haar zijn toegewezen. Deze taken kunnen rolgebaseerd, persoonlijk of algemeen toegewezen worden en zijn al dan niet gebonden aan een zekere patiënt.

Daarnaast is het de bedoeling om ook een regelgebaseerd systeem te laten interageren met de takenapplicatie. Deze zou taken automatisch kunnen creëren of prioriteiten van taken automatisch wijzigen op basis van een aantal regels. Deze regels moeten echter ook eenvoudig kunnen toegevoegd worden. Daarom zal er ook een applicatie worden ontwikkeld die bevoegd personeel in staat stelt om op een eenvoudige manier zelf regels toe te voegen. Zo kunnen bv. regels toegevoegd worden die taken met een deadline binnen twee dagen automatisch een hoge prioriteit geven, of kunnen er regels ontwikkeld worden die ervoor zorgen dat er automatisch een taak gecreëerd wordt wanneer een patiënt ontslagen is.

Client

COSARA

Database

Figuur 1.2: Illustratie van takenapplicatie

1.3 Hoofdstukken

1.3

4

Hoofdstukken

De structuur van deze masterproef ziet er als volgt uit: Hoofdstuk 2 ’Specificatie’: hierin zal de use case uitgezet worden, alsook de black-box werking van de verschillende subsystemen. Ook varianten van de basis use case komen aan bod. Hoofdstuk 3 ’Technologiestudie’ van RFID, XACML, regelgebaseerde systemen, OSGi en polling en pushing van taken via diverse mechanismen. Dit hoofdstuk omvat een literatuurstudie alsook onderzoek naar de toepassing van deze technologieën, alsook afwegingen tussen de verschillende mogelijke oplossingen. Elk onderdeel wordt afgesloten met een verwijzing naar het gebruik ervan binnen het scenario. Hoofdstuk 4 In het onderdeel ’Architectuur’ wordt de uiteindelijke architectuur van het logingedeelte en het takensysteem binnenin de omgeving uitgezet. Hoofdstuk 5 In het gedeelte ’Implementatie’ zullen implementatiebeslissingen nader toegelicht worden. Ook de uiteindelijke weergave van de applicatie wordt toegelicht. Hoofdstuk 6 Een korte ’Evaluatie’ van de implementatie, met onder andere prestatiemetingen van het regelsysteem, alsook het pollen van taken. Hoofdstuk 7 Het werk wordt afgesloten met een ’Conclusie’, waarin de resultaten van dit eindwerk zullen besproken worden alsook verdere (mogelijke) ontwikkelingen.

SPECIFICATIE

5

Hoofdstuk 2

Specificatie In dit hoofdstuk zal de specificatie van de oplossing die in dit boek voorgesteld wordt, uitgezet worden. Hierbij wordt er belang gehecht aan het voldoen aan een aantal functionele, alsook een aantal niet-functionele vereisten. Daarom worden eerst de vereisten geanalyseerd. Op basis hiervan volgt een uiteenzetting van de scenario’s en varianten.

2.1

Vereisten

2.1.1

Functionele vereisten

De functionele vereisten drukken uit wat het systeem moet aanbieden in termen van functionaliteit. Deze vormen de basis voor de functionele scenario’s. De onderstaande lijst zet uit welke features voorhanden moeten zijn: • Eenvoudige instelling van de RFID infrastructuur moet mogelijk zijn voor bevoegde personen • Een personeelslid kan inloggen door zijn of haar RFID kaart voor de lezer te houden • De takenapplicatie moet de gebruiker in staat stellen om eenvoudig toegewezen taken te kunnen bekijken • De gebruiker moet eenvoudig taken kunnen toewijzen aan andere personeelsleden en dit op verschillende niveau’s: – Taken per arts of verpleegkundige – Taken per patiënt

2.1 Vereisten

6

– Taken per rol – Algemene taken – Mogelijke combinaties van deze (bijvoorbeeld voor een zekere arts en voor een zekere patiënt) • De gebruiker moet kunnen aangeven dat een taak gestart is • De gebruiker moet eenvoudig kunnen aangeven dat een taak vervolledigd is • De gebruiker moet kunnen nagaan of taken toegewezen door hem of haar zijn vervolledigd • Het systeem is in staat om een waarschuwing te geven bij niet vervolledigde taken met hoge prioriteit • Het systeem kan de prioriteiten van taken wijzigen op basis van een regelgebaseerd systeem • Het systeem kan zelf taken creëren op basis van een regelgebaseerd systeem • Het systeem kan periodiek nieuwe taken afhalen wanneer een gebruiker ingelogd is • Een daarvoor bevoegde gebruiker kan nieuwe regels toevoegen aan het regelgebaseerd systeem

2.1.2

Niet-functionele vereisten

Aanpasbaarheid Het systeem moet goed kunnen omgaan met zowel interne als externe veranderingen. Het is belangrijk dat er zonder downtime, componenten kunnen vervangen worden door nieuwe versies. Dit kan bijvoorbeeld het wijzigen zijn van de reader hardware voor de inlogprocedure, of door het wijzigen van de persistentiecomponenten voor de takenapplicatie. Het moet eenvoudig zijn om andere implementaties van bepaalde submodules toe te voegen. Deze voorbeelden vormen dan ook zeer specifieke doelstellingen voor het uiteindelijke product. Usability De inlogprocedure moet snel en eenvoudig zijn. De gebruiker mag geen hinder ondervinden van eventuele beperkingen van de onderliggende technologie.

2.1 Vereisten

7

De gebruikersinterface van de takenapplicatie moet handig zijn in gebruik. Het overzicht is hierbij een belangrijke zaak. Personeel moet eenvoudig en snel de status van zijn of haar toegewezen taken kunnen nagaan, alsook de vooruitgang van zelf uitgezonden taken. Zoeken in de taken zou een meerwaarde bieden, zo moet een arts bv. naar alle taken voor een zekere patiënt van hem of haar kunnen zoeken, alsook bv. alle taken die handelen over een specifiek onderwerp. Taken moeten snel kunnen toegevoegd worden, op een intu¨ıtieve manier, zodat het systeem snel aanvaard zal worden door het medisch personeel en zo snel mogelijk ge¨ıntegreerd wordt binnen de dagelijkse activiteiten.

De applicatie die medisch personeel in staat stelt om zelf regels te ontwikkelen moet vooral gebruiksvriendelijk zijn. Personeel met een basiskennis (of zelfs helemaal geen kennis) van regels moet in staat zijn om nieuwe regels te creëren, die natuurlijk ook het gewenste gedrag implementeren. Dit is uiteraard de belangrijkste niet-functionele vereiste van deze subapplicatie. Prestaties Het inloggedeelte moet zeer snel verlopen; wachttijden zijn onaanvaardbaar. De prestatie zal geëvalueerd worden door een tijdsmeting van het moment dat de tag voor de reader wordt gehouden, tot de gebruiker effectief ingelogd is. Het is een streefdoel om deze inlogprocedure snel te laten verlopen, een seconde lijkt de maximale wachttijd.

De takenapplicatie is minder kritisch, maar te lange wachttijden zijn opnieuw niet aanvaardbaar. Wanneer een persoon ingelogd is en een nieuwe taak wordt aan hem of haar toegewezen, dan moet deze taak uiteindelijk ook beschikbaar worden binnen een beperkte tijdspanne van een minuut. Dit kan getest worden door middel van tijdsmetingen. Het systeem moet in staat zijn een groot aantal taken te pollen in minder dan een seconde tijd (gemiddeld). Beschikbaarheid De takenapplicatie moet een hoge beschikbaarheid hebben. Beschikbaarheid kan uitgedrukt worden met behulp van de mean time between failures en mean time to recovery uitdrukkingen. Lange downtime moet vermeden worden. Dit valt echter grotendeels buiten het bereik van deze masterproef.

2.2 Scenario

8

Schaalbaarheid Schaalbaarheid omvat eigenlijk de bekwaamheid van het systeem om zich aan te passen aan verhoogde workload. Het systeem moet voldoende schaalbaar zijn, zodat er bij een groot aantal actieve gebruikers geen bottleneck ontstaat voor het ophalen van taken. Ook bij het toenemen van het aantal clients (door een toename van het aantal patiënten) is het belangrijk dat de data nog steeds snel kan verwerkt worden. Het regelsysteem moet ook in staat zijn om bij een verhoogde workload nog steeds alle regels te evalueren binnen een aanvaardbare tijdspanne. Gezien de beperkte intensiteit van een normale takenapplicatie is deze niet-functionele vereiste echter minder belangrijk.

2.2

Scenario

Hieronder volgt een uiteenzetting van de functionele scenario’s. Eerst worden kort de actoren beschreven. Het verschil met de lijst functionele vereisten in de vorige sectie, is dat deze scenario’s een structuur vormen voor de eerste stappen naar realisatie van het systeem. Er zijn vier hoofdscenario’s; een scenario betreffende de inlogprocedure, een scenario betreffende de takenapplicatie en de gebruikersinteractie ermee, een scenario betreffende de takenapplicatie met geautomatiseerde prioriteitsassignatie en takencreatie, alsook een scenario betreffende de regelcreatie-applicatie. Voor elk scenario wordt een tekstuele beschrijving gegeven en een opsomming van de belangrijkste eigenschappen. De black-box scenario’s vormen high-level uitzettingen van het systeem in termen van de interagerende componenten.

2.2.1

Actoren

• De RFID admin die de RFID infrastructuur kan configureren. • De Gebruiker stelt een ingelogde gebruiker voor, dit is een medisch personeelslid van de dienst IZ van het UZ Gent. • Het Systeem is de applicatie die instaat voor de inlogprocedure en het takenbeheer. • Het Regelsysteem stelt de interne business logic voor die in staat is om prioriteiten te wijzigen, alsook taken toe te voegen. • De COSARA client is de huidige client die voorzien is binnen het UZ.

2.2 Scenario

2.2.2

9

Inlogprocedure

Beschrijving De beschrijving voor deze procedure is vrij triviaal. Het is de bedoeling een RFID inlogprocedure te voorzien voor medisch personeel. De gebruiker houdt een identificatiekaart voor de reader. Het systeem zoekt de gebruikersidentificatiecode op in de databank en staat toegang al dan niet toe. Indien toegang is toegestaan, voert de gebruiker een aantal acties uit, waarna hij uitlogt. Gezien de aard van RFID zal de reader periodiek moeten bevraagd worden om vast te stellen of er een kaart voor de reader wordt gehouden. Prioriteit & Complexiteit Hoog & laag. Primaire actoren De gebruiker die wenst in te loggen. Secundaire actoren De RFID admin, het systeem en de COSARA client. Gerelateerde vereisten Eenvoudige instelling van de RFID infrastructuur moet mogelijk zijn voor bevoegde personen. Trigger Gebruiker houdt zijn identificatiekaart voor de reader. Gerelateerde use cases - Geen Precondities - De RFID hardware is ge¨ınstalleerd. - De RFID infrastructuur is correct geconfigureerd.

2.2 Scenario

10

Hoofdscenario 1. De gebruiker houdt zijn kaart voor de RFID reader. 2. Systeem zoekt ID van de gebruiker op in databank. 3. Gebruiker wordt ingelogd. 4. COSARA client wordt getoond. 5. Gebruiker voert zekere acties uit. 6. Gebruiker logt uit. Postcondities in geval van succes De gebruiker heeft succesvol kunnen inloggen, heeft de gewenste acties kunnen ondernemen en is daarna succesvol uitgelogd. Postcondities na faling De gebruiker is niet ingelogd. Het systeem hervat het bevragen van de reader. Mogelijke variaties 2a. Gebruiker wordt niet ingelogd (de ID is niet gevonden in de databank). Use case diagram «uses»

Login

Configureer reader

Gebruik client

RFID admin

«uses» Gebruiker Logout

Figuur 2.1: Use case diagram van: Inlogprocedure

2.2 Scenario

11

Black box werking Dit is een simplistische weergave. De reader leest periodiek om na te gaan of iemand zijn kaart voor de lezer houdt. Wanneer de gebruiker zijn kaart voor de reader houdt, wordt deze (al dan niet) ingelogd.

Gebruiker

Reader

Kaart voor lezer

Databank

Lees Zoek id op

Voer zaken uit

Uitloggen Lees Lees

Figuur 2.2: Black box werking van: Inlogprocedure

2.2.3

Takenapplicatie en gebruikersinteractie

Beschrijving De basis van de takenapplicatie heeft verschillende mogelijkheden. Dit scenario betreft vooral de eenvoudige gebruikersinteracties met de applicatie. Gebruikers kunnen hun taken beheren, nieuwe taken toewijzen en taken starten en vervolledigen. De prioriteiten kunnen ook manueel ingesteld worden bij toewijzing. Automatische prioriteitsassignatie valt onder de volgende use case. Dit scenario zet de belangrijkste activiteiten uit; het overlopen van taken, het toevoegen en vervolledigen van een taak. Prioriteit & Complexiteit Hoog & laag. Primaire actoren De ingelogde gebruiker.

2.2 Scenario

12

Secundaire actoren Het systeem. Gerelateerde vereisten De inlogprocedure moet operationeel zijn. Trigger Gebruiker activeert de takenapplicatie. Gerelateerde use cases - Inlogprocedure Precondities - De RFID hardware is ge¨ınstalleerd. - De RFID infrastructuur is correct geconfigureerd. - De gebruiker is ingelogd. Hoofdscenario 1. De gebruiker wordt gealarmeerd over eventuele hoge prioriteitstaken 2. De gebruiker selecteert de takenapplicatie binnen de COSARA client 3. De gebruiker bekijkt de aan hem of haar toegewezen taken Postcondities in geval van succes De gebruiker is op de hoogte van de aan hem of haar toegewezen taken, alsook van de status van de door hem of haar toegewezen taken. De gebruiker heeft tevens succesvol een taak toegevoegd bestemd voor een bepaald personeelslid. Postcondities na faling Met het opvragen van de taken mag en kan in principe niks fout lopen. Het toevoegen van een taak kan geweigerd worden.

2.2 Scenario

13

Mogelijke variaties 3a. De gebruiker start een taak 3b. De gebruiker vervolledigt een taak 3c. De gebruiker voegt een nieuwe taak toe, bestemd voor een zeker personeelslid met een zekere prioriteit, deadline, beschrijving 3d. De gebruiker voegt een taak toe, bestemd voor een zekere rol 3e. De gebruiker voegt een taak toe, betreffende een zekere patiënt 3f. De gebruiker voegt een algemene taak toe 3g. De gebruiker voegt een taak toe die bestaat uit een combinatie van deze Use case diagram

Taak vervolledigen

«uses»

Taak starten «uses»

«extends»

«extends»

«uses» Taken beheren

Taak toevoegen

Taak voor personeel toevoegen

Algemene taak toevoegen

«extends» Gebruiker

«uses» «uses»

«extends»

Assigneer prioriteit

Rolspecifieke taak toevoegen

Taak betreffende patiënt toevoegen

Takenlijst opvragen «extends»

Geassigneerde taken opvragen

«extends»

Taken geassigneerd door gebruiker opvragen

Figuur 2.3: Use case diagram van: Takenapplicatie en gebruikersinteractie

2.2 Scenario

14

Black box werking Dit is een simplistische weergave van een aantal mogelijke gebruikersacties. Het diagram begint wanneer de taken reeds opgevraagd zijn.

Gebruiker

Takensysteem

Databank

Taken Taken Alerts Start taak Taak gestart

Maak taak Taak gemaakt

Kan eventueel een boodschap sturen dat iemand anders taak reeds gestart heeft.

Figuur 2.4: Black box werking van: Takenapplicatie

2.2.4

Takenapplicatie met automatische prioriteitsassignatie en takencreatie

Beschrijving Dit scenario zal uitwijzen hoe de takenapplicatie en het regelsysteem zullen samenwerken. Periodiek of bij takenophaling, zal het regelsysteem serverside nagaan of de prioriteiten van taken gewijzigd moeten worden. Het zal hiervoor een collectie van regels overlopen en evalueren. Het regelsysteem kan nieuwe taken automatisch creëren op basis van regels. Er moet dus ook onderscheid gemaakt worden tussen regels die taken kunnen aanmaken en regels die enkel de prioriteiten van taken kunnen wijzigen. Prioriteit & Complexiteit Gemiddeld & hoog. Primaire actoren Het systeem, het regelsysteem.

2.2 Scenario

15

Secundaire actoren De gebruiker. Gerelateerde vereisten Het systeem moet het regelgebaseerd systeem aanspreken om prioriteiten te wijzigen, alsook om eventuele taken te laten aanmaken. Dit kan rechtstreeks op de database inwerken. Trigger Gebruiker logt in en vraagt taken op, of voegt een taak toe. Gerelateerde use cases - Takenapplicatie en gebruikersinteractie Precondities - De RFID hardware is ge¨ınstalleerd. - De RFID infrastructuur is correct geconfigureerd. - De gebruiker is ingelogd. - De regels van het regelsysteem zijn beschikbaar. Hoofdscenario 1. Na inloggen, worden taken opgehaald van de gebruiker 2. Het regelsysteem voert een evaluatie uit 3. De prioriteit van een aantal taken wordt gewijzigd 4. Een nieuwe taak wordt toegevoegd door het regelsysteem 5. De gebruiker wordt gealarmeerd over eventuele hoge prioriteitstaken 6. De gebruiker opent de takenapplicatie binnen de COSARA client

2.2 Scenario

16

Postcondities in geval van succes De takenprioriteiten zijn correct aangepast op basis van de achterliggende regels. Eventuele nieuwe taken zijn toegekend. De gebruiker heeft de takenapplicatie geopend en wordt nu geconfronteerd met de nieuwe prioriteiten en/of taken. Postcondities na faling Prioriteiten zijn niet correct gewijzigd of taken zijn niet toegevoegd. Mogelijke variaties 3a. Er werden geen prioriteiten gewijzigd 4a. Er werden geen nieuwe taken toegevoegd door het regelsysteem Use case diagram

Prioriteiten wijzigen

«uses»

Regels opvragen «uses» Taken aanmaken «uses» Regelsysteem «extends»

Regels evalueren

Taak aangemaakt voor gebruiker

Gebruiker via het systeem

Figuur 2.5: Use case diagram van: Takenapplicatie en automatische prioriteitsassignatie

Black box werking Dit is een simplistische weergave van de acties die uitgevoerd worden door het regelsysteem. In dit geval begint het diagram wanneer de gebruiker ingelogd is en de takenapplicatie heeft gestart, waardoor de taken opgevraagd worden. Het regelgebaseerd systeem werkt intussen in

2.2 Scenario

17

op de databank. De gebruiker ziet dan de wijzigingen aangebracht door de regelevaluatie.

Gebruiker

Takensysteem

Databank

Regelsysteem

Vraag taken Vraag taken Voer regels uit Wijzigen taken Nieuwe taken

Taken Taken

Figuur 2.6: Black box werking van: Regelsysteem

2.2.5

Regelcreatie-applicatie

Beschrijving Dit scenario zal uitwijzen hoe een daarvoor bevoegde gebruiker nieuwe regelbestanden kan creëren, alsook nieuwe regels kan toevoegen, verwijderen en wijzigen. Het moet mogelijk zijn om condities en consequenties te bewerken, te verwijderen en toe te voegen. Dit zijn op zich triviale acties en moeten eenvoudig uit te voeren zijn door personen zonder kennis van regelsystemen. Dit scenario wordt gekenmerkt door een hoge gebruiksvriendelijkheid. Prioriteit & Complexiteit Laag & hoog. Primaire actoren De gebruiker en het regelsysteem. Secundaire actoren Geen.

2.2 Scenario

18

Gerelateerde vereisten De regels moeten geëvalueerd worden wanneer taken opgehaald worden, anders heeft het weinig zin om nieuwe regels toe te voegen. De vorige use case moet dus succesvol ge¨ımplementeerd zijn. Trigger De gebruiker opent de gebruikersinterface voor het aanmaken van nieuwe regels. Gerelateerde use cases - Takenapplicatie en automatische prioriteitsassignatie en takencreatie. Precondities - De RFID hardware is ge¨ınstalleerd. - De RFID infrastructuur is correct geconfigureerd. - De gebruiker is ingelogd. Hoofdscenario 1. De gebruiker opent de gebruikersinterface voor het aanmaken van nieuwe regels 2. De gebruiker selecteert ’Nieuwe regel’ 3. De gebruiker voert een zekere regelnaam in 4. De gebruiker selecteert een zekere recordveldnaam voor een conditie van de regel 5. Een zekere numerieke waarde of veldwaarde wordt ingegeven voor het gekozen recordveld 6. De consequentie van de regel wordt ingevoerd in de vorm van een prioriteitswijziging en/of opdracht tot taakcreatie 7. De gebruiker slaat het regelbestand op Postcondities in geval van succes De nieuwe regel is toegevoegd.

2.2 Scenario

19

Postcondities na faling De regel is niet toegevoegd aan het regelbestand en zal niet worden geëvalueerd door het regelsysteem. Mogelijke variaties 2a. De gebruiker verwijdert een regel. 2b.1 De gebruiker selecteert ’Regel aanpassen’. 2b.2 De gebruiker selecteert een bestaande conditie en wijzigt ze. 2b.3 De gebruiker voegt een conditie toe aan de regel 3a. De gebruiker geeft een zekere salience in voor de rule 2c. De gebruiker verwijdert een conditie. 2d. De gebruiker verwijdert een consequentie. 6a. De conditie wordt verder uitgebreid. Use case diagram

«uses» Regel aanmaken

Conditie(s) toevoegen

«uses» «uses»

Beheer regels

Consequentie toevoegen

«uses» Regel verwijderen

«extends»

«extends»

Gebruiker

Taakcreatie consequentie toevoegen

Figuur 2.7: Use case diagram van: Regelsysteem beheer

Prioriteitsconsequentie toevoegen

2.2 Scenario

20

Black box werking Dit is een simplistische weergave van de acties uit te voeren door de regelcreatie-applicatie. De gebruiker maakt een regel aan met een conditie en consequentie en schrijft deze weg.

Gebruiker

Regelcreatie applicatie

Output

Nieuwe rule

Voeg conditie toe Voeg consequentie toe Opslaan Schrijf bestand Opslaan gelukt Opslaan gelukt

Figuur 2.8: Black box werking van: Regelcreatie-applicatie

TECHNOLOGIESTUDIE

21

Hoofdstuk 3

Technologiestudie Om de specificatie, uiteengezet in hoofdstuk 2, te mappen op een architectuur moeten er een aantal technologieën onderzocht worden. In dit hoofdstuk volgt een studie naar de verschillende technologieën die relevant zijn voor deze masterproef. Het betreft Radio Frequency Identification (RFID), eXtensible Access Control Markup Language (XACML), regelgebaseerde systemen, OSGi en polling- en pushmechanismen. Hierbij zal de aandacht vooral gaan naar informatie relevant tot het scenario betreffende context-awareness voor gepersonaliseerde medische informatie en distribueren van medische taken. Voor elke onderzochte topic volgt als conclusie een bespreking van de technologie binnen het scenario.

3.1 3.1.1

RFID Algemeen

RFID is een technologie die gebruik maakt van radiogolven om objecten of personen automatisch te identificeren zonder dat er een zogenaamde line-of-sight vereist is. Een RFID-systeem bestaat uit enerzijds een lezer en anderzijds een chip met een antenne (tag), omgeven door een vorm van encapsulatie. De chip van de tag wordt voorzien van een uniek serienummer (Electronic Product Code of EPC) die de persoon of het object identificeert. Sommige chips kunnen ook andere informatie bevatten, maar de meeste hebben ruimte voor tweeduizend bytes. De antenne laat de chip toe om dit nummer te verzenden naar een lezer; de energie die hiervoor gebruikt wordt kan ofwel van een batterij komen, alsook uit het signaal afkomstig van de lezer. Deze lezer kan het ontvangen signaal dan converteren naar digitale informatie, geschikt voor verwerking op een computer.

3.1 RFID

22

RFID tags kunnen net zoals barcodes gebruikt worden om objecten te identificeren. Ze hebben echter een aantal belangrijke voordelen ten opzichte van de barcodes. [1] Zo vereisen barcodes een line-of-sight en kunnen ze bovendien enkel op een relatief korte afstand gelezen worden. Bovendien kunnen RFID lezers aan een veel hoger tempo tags inlezen dan barcodes ingelezen kunnen worden. Barcodes kunnen onleesbaar worden, gezien ze zich steeds op een kwetsbare plaats bevinden van het product. Door de aard van de RFID technologie kan de tag meestal op een veiligere plek geplaatst worden. Een ander belangrijk voordeel is de mogelijkheid om informatie te schrijven op tags. Barcodes zullen echter steeds effectiever blijven voor toepassingen waar een minimale kost absolute noodzaak is. [2, 3, 4]

De laatste jaren is het gebruik van RFID enorm toegenomen en zijn talloze grootschalige projecten opgezet die gebruik maken van RFID voor geautomatiseerde identificatie - dit is grotendeels te danken aan de forse prijzendaling voor RFID materiaal. Deze prijzen zullen in de toekomst nog verder dalen. In de toekomst zal deze technologie dan ook een belangrijke rol gaan spelen in diverse markten.

Binnen e-Health zijn er al meerdere proefprojecten uitgevoerd die gebruik maken van RFID technologie voor onder andere lokalisatie van personeel en materiaal. [5, 6] De technologie is uitermate geschikt om de vervelende inlogprocedure te automatiseren om zo een snellere behandeling van de patiënten binnen de Intensieve Zorg dienst van het UZ Gent mogelijk te maken.

3.1.2

Variaties in RFID systemen

Er zijn verschillende soorten tags; algemeen kan er onderscheid gemaakt worden tussen actieve, passieve en semipassieve tags. Anderzijds kan er ook onderscheid gemaakt worden tussen de opererende frequenties van de tags en lezers. Op basis daarvan gedragen deze zich verschillend, hoewel de verschillen tussen de RFID producten afkomstig van verschillende producenten niet over het hoofd mogen gezien worden. Daarnaast zijn er ook de triviale verschillen in tags; grootte, lees- en schrijfmogelijkheden, duurzaamheid, resistentie tegen externe factoren, ondersteunde standaarden, ondersteunende lezers, de anticollisieprotocols en de beveiliging. Het is belangrijk om deze verschillen goed te begrijpen en de voor- en nadelen voldoende te vergelijken. Op basis hiervan zal afgewogen worden welk RFID systeem het best in aanmerking komt voor

3.1 RFID

23

het geautomatiseerd inloggen op basis van een kaart en kaartenlezer. [10, 11]

Passieve tags: Wanneer radiogolven uitgaande van de reader de passieve tag bereiken, vormt de antenne binnen de tag een magnetisch veld. Passieve tags halen hun energie uit dit magnetisch veld. Logischerwijze vermindert die energie als ze zich verder van de lezer bevinden. Daardoor zijn deze vooral geschikt voor identificatie op een kortere afstand. Maximale afstanden liggen rond de 4–5 meter. Ze kunnen ook slechts een beperkte hoeveelheid data bevatten. Semipassieve tags: Deze hebben de energie uit het reader veld niet nodig om de chip te ’starten’ doordat ze voorzien zijn van een batterij. Het nadeel is echter dat er geen ge¨ıntegreerde transmitter is, waardoor hij nog steeds het veld van de lezer moet gebruiken om er mee te kunnen communiceren. Actieve tags: Deze tags worden van energie voorzien door een batterij en hoeven dus geen energie te halen uit het interrogatiesignaal afkomstig van de reader. Ze hebben ook een actieve transmitter. Deze kunnen dus in tegenstelling tot de passieve tags, radiofrequentie energie genereren om zo via de antenne hun ID terug te sturen naar de lezer. Dit kan over grotere afstanden dan bij RFID tags, 100m of meer zijn geen uitzonderingen.

RFID opereert in een breed spectrum van de beschikbare bandbreedte, dit wordt algemeen verdeeld in LF, HF, UHF en microwave frequentie. [4] De exacte spectra worden vastgelegd door het Belgisch Instituut voor Postdiensten en Telecommunicatie of het BIPT. [14]

LF of Low Frequency: Het bereik van lage frequentie RFID ligt tussen 30 en 500 kHz. LF systemen hebben een lage kostprijs en een kort bereik (minder dan een halve meter voor passieve tags) en zijn niet zeer gevoelig tegenover metaal en elektrische storingen. HF of High Frequency: Deze systemen opereren tussen 10–15 MHz, waarbij 13,56 MHz het meest gebruikt wordt. Zijn iets duurder dan LF systemen, maar hebben een verder bereik (ongeveer een meter voor passieve tags) en een betere leessnelheid. UHF of Ultra High Frequency: Deze opereren tussen 400 tot 1000 MHz en tussen 2.4 GHz tot 2.6 GHz. Deze zijn een stuk duurder, maar hebben wel een zeer groot bereik (vier tot vijf meter voor passieve tags). Microwave: 2.4 GHz en ook hogere. Dit zijn zeer dure systemen.

3.1 RFID

3.1.3

24

Werking

Gezien het belangrijk is te weten hoe RFID juist werkt om het efficiënt te kunnen gebruiken binnen de context van deze masterproef, volgt hier een korte uiteenzetting over de werking.

Deze uiteenzetting is een simplificatie van de realiteit, maar het volstaat om een correct beeld te vormen van de fysische werking van het systeem. Een uitgebreide analyse van verschillen tussen UHF en HF-tags en de soorten koppeling kan gevonden worden in [4, 7]. Reader en tags De lezer of reader beschikt over één of meer antennes. Deze antennes genereren, afhankelijk van de techniek, ofwel een inductieveld (bij near-field koppeling) ofwel een elektromagnetisch veld (bij far-field koppeling) in hun lokale omgeving. Het verschil tussen beide designs en een uitgebreide analyse ervan is in meerdere werken uitgezet. [4, 8]. Naast deze antenne omvatten de meeste readers ook nog een radiofrequentie module en een controle eenheid, alsook een interface die hen in staat stelt om de ontvangen data te communiceren naar een digitaal systeem, zoals bijvoorbeeld een business applicatie.

De meeste tags of transponders die hedendaags gebruikt worden, zijn passieve tags. De logische componenten hiervan, zijn te zien in figuur 3.1. Encapsulatie Antenne Chip

Cap

Figuur 3.1: Logische componenten van een RFID tag [4]

Er zijn echter ook semipassieve en actieve tags (zie 3.1.2). De passieve tag wordt hier verder besproken. Wanneer een tag, uitgerust met een kleinere antenne, binnen het bereik van een reader wordt geplaatst, kan deze de energie van het veld tijdelijk opslaan. Wanneer er voldoende energie geaccumuleerd is kan de chip geactiveerd worden (dit is niet nodig wanneer de chip voorzien is van een batterij). De tag maakt dan gebruik van ladingsmodulatie (bij near-field koppeling) of ’backscattering’ (bij far-field koppeling) om via zijn antenne de informatie op de chip in de

3.1 RFID

25

vorm van een signaal uit te zenden. De lezer kan deze dan opvangen en controleren, alvorens deze te converteren naar digitale informatie, waarna applicaties gebruik kunnen maken van die informatie, om bijvoorbeeld te weten welke tags zich in de omgeving van de lezer bevinden. [9]

3.1.4

Toepassingen

Inloggen via RFID kaarten wordt reeds toegepast. Een eerste gebruik van RFID was het vervangen van mechanische sleutels door een elektronische kaart. Deze zijn immers moeilijker na te maken en kunnen ook gewoon uit de database verwijderd worden wanneer de toegang ontzegd moet worden, in tegenstelling tot een mechanische sleutel. Bovendien is dit helemaal niet duur.

Een belangrijke ontwikkelaar van RFID kaarten voor toegangscontrole is Hughes Identification Devices (HID). [18] Deze hebben zelfs speciale e-Health solutions voor handen, zoals te vinden op [19]. HID is de marktleider wat betreft RFID login solutions. iClass is een contactloze smart card access control systeem, zie figuur 3.2. [20] Een smartcard is een kaart die een RFID tag bevat, waardoor er geen contact met de lezer vereist is. Deze opereren aan 125 kHZ of 13,56 MHz. Een alternatief zijn de HID proximity cards, die opereren aan 125 kHz. HID vormt dus een mogelijke leverancier voor de RFID hardware.

Figuur 3.2: Een contactloze smart card en bijhorende reader

RFID toepassingen komen steeds vaker voor. Naast de veiligheidsapplicaties, zoals access control en antidiefstal systemen, zijn er ook tal van toepassingen gericht op tracking van objecten

3.1 RFID

26

(bruikbaar binnen onder andere productiesystemen), authenticiteitscontrole, elektronische betalingen en binnen de entertainment sector. Binnen de e-Health sector werd en wordt RFID reeds gebruikt voor het tracken van apparaten en voor de verificatie van medicijnen en bloedproducten. Er zijn nog veel andere toepassingen voor handen. [5, 21, 22]

3.1.5

Problemen

Het gebruik van RFID heeft naast de duidelijke voordelen, ook een aantal nadelen. De meeste problemen die vaak optreden bij RFID systemen, zullen in dit scenario echter niet van belang zijn. [23] Tag- en readercollisie Tagcollisie treedt op wanneer de signalen afkomstig van tags overlappen; bij passieve tags zal dit dus gebeuren wanneer de reader meerdere tags van energie voorziet, waardoor ze op hetzelfde tijdstip signalen terugsturen. Dit kan opgelost worden door anticollisieprotocols. Dit vormt echter geen probleem in dit scenario. Gezien het inloggen gebeurt door een kaart voor de lezer te houden, kan het bereik van de reader zeer beperkt gehouden worden. Waardoor er nooit meerdere tags op hetzelfde moment zullen gelezen worden, waardoor enkel diegene die zijn kaart in de buurt van de lezer heeft gehouden, in aanmerking zal komen voor lezing. Dit is dus een duidelijk voordeel van het manueel inloggen; wanneer er zonder kaart gewerkt zou worden, is de kans reëel dat er zich meerdere personeelsleden in de buurt van de bedside pc bevinden, waardoor er meerdere tags ge¨ıdentificeerd worden. Houden twee personeelsleden tegelijk hun kaart voor de lezer, dan zal de laatst ontvangen ID bepalen wie ingelogd is. Maar dit is natuurlijk niet de bedoeling. Een ander probleem dat duidelijk vermeden wordt door het kaartensysteem is inlezen van een ID die niet moet ingelezen worden, wanneer je met een reader werkt met verder bereik en zonder manueel inloggen, kunnen ID’s ingelezen worden zonder dat het medisch personeel de intentie heeft om in te loggen.

Readercollisie vindt plaats wanneer het bereikbaar gebied van twee readers overlapt. Dit kan leiden tot signaal interferentie en dubbele lezingen van eenzelfde tag. Van beide problemen is echter geen sprake in dit scenario.

3.1 RFID

27

Privacy problemen Gezien de aard van het inlezen van de kaarten vormt dit eveneens geen probleem. Indien er met lezers met een groter bereik gewerkt wordt, kunnen de geplaatste RFID lezers en de tags, die de medische personeelsleden bij zich dragen, het mogelijk maken om het personeel te tracken en hun locatie binnen het hospitaal steeds te weten. Dit gaat in tegen de privacy van de artsen en verpleegkundigen. Met een kaartensysteem is dit een heel stuk moeilijker, waardoor het medisch personeel het gebruik ervan sneller zal aanvaarden.

Buiten het hospitaal is er sowieso geen probleem. Indien men echt geen kaart bij zich wil houden, kan men deze ook gewoon ter plaatse laten na de werkdag. Beveiliging De ID die zich op de kaart bevindt zou theoretisch gezien met een lezer kunnen opgevangen worden, waarna de kaart kan gekopiëerd worden of het signaal zou opnieuw kunnen afgespeeld worden. Zo zou niet-medisch personeel toegang kunnen krijgen tot een bedside pc en vertrouwelijke informatie kunnen ontvreemden. Er zijn reeds authenticatieprotocols voor handen voor RFID tags. Dit valt echter buiten deze masterproef. Eenvoudige implementaties voor beveiliging zijn wel voor handen. [24, 25] Elektromagnetische interferentie of EMI Een onderzoek naar het gebruik van RFID binnen een medische site heeft uitgewezen dat de signalen afkomstig van lezers en tags kunnen zorgen voor elektromagnetische interferentie, waardoor medische apparaten storingen kunnen vertonen. [26] Gezien het gebruik van lezers met een kort bereik, zal dit in deze usecase beperkt zijn. Toch is het aangewezen voldoende onsite EMI tests uit te voeren, alvorens tot een algemene implementatie binnen de IZ over te gaan.

3.1.6

Standaarden

De algemene introductie van RFID technologie is lange tijd moeizaam verlopen doordat er onduidelijkheid was over de standaarden betreffende de technologie. Enerzijds heeft de Auto-ID Center, die verantwoordelijk is voor de ontwikkeling van EPC, zijn eigen standaarden gecreëerd. Anderzijds heeft ook de ISO zekere standaarden voor RFID protocols. [27, 28].

3.1 RFID

28

ISO ISO heeft een aantal ’air interface’ protocols. Deze beschrijven hoe tags en readers met elkaar communiceren, alsook hoe de data georganiseerd wordt. Ook voor conformiteit, de manier waarop getest wordt of aan de standaard voldaan is, zijn er standaarden. [27] De standaarden die in deze usecase relevant zijn:

ISO 14443: deze definiëert een proximiteitskaart gebruikt voor identificatie, alsook de protocols om te communiceren. ISO 18000: deze beschrijft een set van RFID technologieën, die unieke frequentiebanden gebruiken. 18000-3 beschrijft de manier waarop gecommuniceerd wordt op de 13.56 MHz frequentie. Auto-ID Center - EPCGlobal Auto-ID Center ontwikkelde zijn eigen protocols onder EPCGlobal. De relevante standaard:

EPCGlobal Gen 2: werd ontwikkeld om compatibeler te zijn dan Gen 1 (Class 0 en Class 1) met de ISO-standaarden. Deze is nu ook opgenomen onder de ISO standaarden en vormt de globale standaard.[29]

3.1.7

Frameworks en middleware

Er zijn tal van frameworks om communicatie met RFID hardware mogelijk te maken. Het grote probleem hierbij is de diversiteit aan readers - deze kunnen niet allemaal op dezelfde manier aangesproken worden. Veel readers hebben hun eigen specifieke libraries die samen met de reader aangekocht worden. Dit is vaak commerciële software. Het is belangrijk om bij de ontwikkeling van de inlogprocedure voor het IZ, voldoende abstractie aan de dag te brengen, zodat de procedure niet gebonden is aan bepaalde hardware. Hierna volgt een klein overzicht van beschikbare frameworks, libraries en middleware. Dit is natuurlijk slechts een klein aandeel van beschikbare software. Java-RFID Open source programmeerbibliotheek voor Java. Dit biedt een een soort JDBC library aan voor RFID systemen, zodanig dat er abstractie is van de onderliggende hardware. Java-RFID is getest met Texas Instruments en Microchip RFID kits. [30]

3.1 RFID

29

Dit is een zeer basic library en lijkt onvoldoende geschikt voor deze usecase. Rifidi Rifidi is een middleware platform voor het bouwen van RFID applicaties. Het omvat enerzijds Rifidi Toolkit en Rifidi Edge. De toolkit laat toe om een zogezegde virtuele RFID infrastructuur te bouwen gebaseerd op software gedefiniëerde RFID lezers, tags en events. Rifidi Edge is een middleware platform voor het ontwikkelen en deployen van RFID applicaties. Met dit platform kan eerst de reader geëmuleerd worden, waarna de business logic kan ge¨ımplementeerd worden. Daarna kan getest worden op de toolkit, alvorens de applicatie te koppelen aan echte hardware. [31]

Rifidi is open source en lijkt interessant om te overwegen. Het opzetten van een virtuele RFID infrastructuur is uitermate geschikt om abstractie van onderliggende hardware mogelijk te maken. logicAlloy Open source middleware die integratie van RFID hardware met applicaties vereenvoudigt. De ALE server verzamelt data en laat business systemen toe om zich te subscriben voor bepaalde events. Deze communicatie gebeurt via SOAP berichten, waardoor dit SOA-compatibel is. [32] RFID Anywhere Sybase’s iAnywhere: RFID Anywhere is commerciële software die naast automatische datacollectie van RFID hardware, sensoren en barcodes, ook business logic en processen integreert. Daardoor kan er een netwerk tussen de verschillende readers opgezet worden. [33]

Dit is minder interessant om twee redenen. Het is commerciële software en het is iets te geavanceerd voor dit scenario. Een netwerk van RFID lezers is immers niet vereist. Sun Java System RFID Software Sun Java System RFID Software is een middleware platform dat gebaseerd is op de EPCGlobal standaarden. Het is vooral geschikt om een EPC netwerk te genereren en het vereenvoudigt de

3.1 RFID

30

integratie met backend systemen. Het staat in voor de communicatie tussen readers en tags, alsook voor het verwerken van de EPC data en de communicatie met de backend. Dit doet het op basis van een RFID Event Manager en een RFID Information Server. Die zorgen respectievelijk voor het opvangen van de EPC events en voor de opslag en verwerking ervan. Het bevat dus ook tal van filters voor de EPC Data alsook verscheidene logging mogelijkheden. [34]

Dit is een open source middleware platform en lijkt ook geschikt voor deze usecase, hoewel er niet echt een EPCGlobal netwerk vereist is en het misschien iets te gecompliceerd is voor een eenvoudige inlogprocedure - de overhead kan te groot zijn in verhouding tot de benodigde RFID procedure.

3.1.8

Scenario

Na dit onderzoek naar de technologie RFID is het mogelijk om een aantal keuzes te maken betreffende de inlogprocedure (2.2.2). De problemen rond RFID binnen de specifieke hospitaalomgeving werden reeds besproken in 3.1.5. Tag type Voor de inlogprocedure, is het duidelijk dat passieve tags het meest aangewezen zijn. Gezien de identificatie gebeurt door middel van een kaart die voor een lezer wordt gehouden, is de afstandsbeperking geen obstakel. Ook de beperkte opslagruimte vormt geen probleem. Er moet enkel een identificatienummer opgeslagen worden. Bovendien hebben de passieve tags een langere levensduur en zijn ze een heel stuk goedkoper. [12, 13] Systeemfrequentie Voor de frequentie lijken een HF of LF systeem de beste opties. Beide hebben gelijkaardige prijskaartjes. De dienst IZ heeft maximaal 94 bezette bedden. Dit impliceert dat er 94 readers nodig zijn en eventueel wat reserve readers. Het medisch personeel omvat 22 artsen en 47 verpleegkundigen (gezien de 1:2 ratio voor patiënt:verpleegkundige). [15] Er zijn dus 69 ID cards nodig, naast wat reservekaarten. Een HF reader voor toegangscontrole is reeds te vinden voor een prijs rond de 40 euro, bijvoorbeeld de iDTRONIC Access Control Reader voor Mifare cards voor 35 euro. Voor 200 kaarten, is de prijs rond de 120 euro. [16, 17] De readers vormen dus duidelijk de grootste kost. De prijs voor een LF systeem is vergelijkbaar. [16]

3.2 XACML

31

Component

Prijs in euro

100 Readers

3500

200 Tags

3.2

XACML

3.2.1

Algemeen

120

XACML of eXtensible Access Control Markup Language is een XML-gebaseerde taal voor toegangscontrole gestandaardiseerd door de Organization for the Advancement of Structured Information Standards (OASIS). De werking is goed uitgewerkt in de masterproef (Efficiënt profielbeheer in het Intensieve Zorgen platform - 2009) van Chris Wauman, alsook een mogelijk gebruik binnen het ICSP. [35]

3.2.2

Scenario

Het gebruik van XACML binnen deze context zal gericht zijn op het gebruik van gebruikersprofielen om zo welbepaalde tabbladen al dan niet te openen en ook om na te gaan of het medisch personeel wel toegang mag hebben tot informatie betreffende een welbepaalde patiënt. Het is bijvoorbeeld mogelijk dat een bepaalde arts toegang mag hebben tot alle dossiers, met uitzondering van een patiënt die daar specifiek om gevraagd heeft of een hoofdverpleegkundige die enkel toegang mag hebben tot dossiers van patiënten op zijn of haar dienst. De masterproef van Bartel Braeckman (Automatisch inloggen via RFID en rolgebaseerde activatie van medische services - 2010), behandelt XACML binnen het ICSP en COSARA in detail.

3.3 3.3.1

Regelgebaseerde systemen Algemeen

Regelgebaseerde systemen zijn in staat om kennis op te slaan en te manipuleren om op deze manier informatie op een nuttige wijze te gaan interpreteren. Veel artificiële intelligentie applicaties maken gebruik van dergelijke systemen. Het systeem kan op basis van zijn kennisbank nieuwe kennis afleiden, door middel van logische deductie. [37]

Een regelgebaseerd systeem omvat vier basiscomponenten (zie figuur 3.3):

3.3 Regelgebaseerde systemen

32

• Kennisbank: het geheel van regels, opgeslagen als een lijst van regels. • Inferentie-engine: deze voert de regels uit met de informatie die zich in het werkgeheugen bevindt en omvat een patroonmatcher, een uitvoeringsengine en een agenda. De matcher zal kijken of de condities van regels gematcht kunnen worden op basis van kennis uit de kennisbank. De matcher vormt de kern van de engine en communiceert met het werkgeheugen en de kennisbank. De agenda legt de volgorde van de verschillende regels vast. Het zal vaak zo zijn dat de condities van meerdere regels voldaan zijn en de consequenties uitgevoerd moeten worden. De agenda neemt hiervoor de verantwoordelijkheid. • Werkgeheugen: workspace of werkgeheugen, bevat tijdelijke data zoals de feiten die dienen ter evaluatie van de regels. • Gebruikersinterface: bevindt zich tussen de inferentie-engine en de gebruiker. Hierna volgt nog een korte toelichting betreffende regels en rule-engines.

Kennisbank

Inferentie-engine Execution engine Patroon matcher

Werkgeheugen

Agenda

Figuur 3.3: Componenten van een regelgebaseerd systeem

3.3.2

Rules

Een rule is eigenlijk een soort if-then constructie: ALS conditie(s) voldaan is (zijn) DAN worden zekere consequenties/acties uitgevoerd

De consequentie van een rule kan een externe actie zijn, of kan bijvoorbeeld een toevoeging zijn van een feit aan de kennisbank. Op basis hiervan kunnen we onderscheid maken tussen onder andere deductieregels en transformatieregels. Het zijn dit soort regels die in dit scenario van belang zijn.


3.3.3

33

Rule engines

Het is belangrijk onderzoek te doen naar verscheidene rule-engines om tot een geschikte kandidaat te komen voor deze masterproef. De rule engine is verantwoordelijk voor het evalueren van de informatie in het werkgeheugen ten opzichte van de kennisbank. Indien zekere condities voldaan zijn, worden de consequenties van een rule uitgevoerd. Deze kunnen nieuwe informatie in het werkgeheugen plaatsen, of kunnen externe procedures starten. Voor deze masterproef wordt er onderzoek gedaan naar Java rule engines. De voornaamste die onderzocht zullen worden, zijn Drools en Jess. Gezien het wijdverspreid gebruik van deze, is informatie hierover eenvoudig te vinden en zijn er ook garanties voor toekomstige ontwikkelingen binnen dit domein. Rete algoritme Het Rete algoritme is een patroon matching algoritme dat gebruikt wordt bij de implementatie van regelsystemen. Het is de basis van vaak gebruikte expertsystemen zoals CLIPS, Jess en Drools. Rete staat eigenlijk voor net”. Een gewone implementatie van een regelsysteem zou ” elke regel checken tegenover de facts die zich in de kennisbank bevinden en dan eventuele consequenties uitvoeren indien condities van de desbetreffende regels voldaan zijn. Maar het Rete algoritme voorziet een efficiëntere implementatie. Het bouwt geleidelijk een netwerk van nodes op, waarbij elke node overeenstemt met het conditiegedeelte van een regel. Voor elke dergelijke node, worden de facts bijgehouden die aan deze condities voldoen. Telkens wanneer nieuwe facts worden toegevoegd, propageren deze langs het netwerk en worden de nodes uitgebreid met de matchende facts. Het evalueren van facts wordt dan dus eenvoudig uitgevoerd door het propageren in de boom, op basis van de condities van het feit. Dit levert een enorme performantieboost. [39] Jess Jess is de meest mature Java rule engine. Deze is dus logischerwijze goed gedocumenteerd en heeft een grote support. Maar de regels worden geschreven in een Prolog-syntax en het is een commercieel product. Daardoor is deze rule engine een mogelijkheid, maar is het interessant om alternatieven te onderzoeken. [40]


34

Drools Drools 5 omvat een business logic integratieplatform voor het verwerken van regels, workflow en events. Het bevat een rule engine die gebruik maakt van een uitgebreide versie van het RETE algoritme, namelijk ReteOO (Rete Object Oriented). Daarom kan dit zeer goede prestaties verwezenlijken binnen object georiënteerde omgevingen. Het is volledig aanspreekbaar via JSR94 (javax.rules API - algemene standaard, gelijkaardig aan JDBC bij databases) en is volledig open source. Drools heeft zijn eigen taal om rules op te stellen. Het drukt regels uit met behulp van Java en XML-syntax of MVEL. Een voorbeeld is te zien in figuur 3.4.

Regel in XML-formaat <parameter identifier="task"> Task <java:condition> task.getTitle().equals("X-Ray afhandeling") <java:consequence> task.setPriority(Priority.HIGH); Regel in MVEL rule "Taak met titel X-Ray afhandeling" salience 15 when $task : Task (title == “X-Ray afhandeling”) then modify ( $task ) { setPriority(Priority.HIGH) } end

Figuur 3.4: Illustratie van regels in Drools

Deze drukt uit dat de prioriteit van taken met titel X-Ray afhandeling” moet gewijzigd worden ” naar hoog. Veelal worden deze rules omschreven en opgesomd in .drl-bestanden die kunnen ingeladen worden door de Drools rule engine. Dit proces is vrij straightforward. Drools heeft een

3.4 OSGi

35

grote en sterke gebruikersgemeenschap. Hierdoor is er veel informatie te vinden op het web en in de uitgebreide handleiding: dit is belangrijk gezien het via de applicatie zal moeten aangestuurd worden. Het lijkt dan ook de beste keuze voor deze masterproef en voor de uitwerking van de twee scenario’s (2.2.4 en 2.2.5) met betrekking tot regelgebaseerde systemen. [39]

3.3.4

Scenario

De takenapplicatie zal taken voorzien van een prioriteit. Dit zal in eerste instantie gewoon gebeuren via het aangeven van een prioriteitslevel. Het is de bedoeling om dit later uit te breiden met een rule engine, die prioriteiten kan aanpassen wanneer er zekere condities voldaan zijn. Dit is uitgezet in 2.2.4. Wanneer een patiënt bijvoorbeeld ontslagen is uit het hospitaal, kan de taak om zijn dossier af te handelen een hogere prioriteit krijgen. Periodiek of bij zekere events kunnen de prioriteiten opnieuw herbekeken worden en aangepast waar de condities voldaan zijn. Het moet ook mogelijk zijn dat het systeem op basis van data uit de patiënten- en personeelsdatabank bepaalde taken zelf gaat toewijzen met een gewenste prioriteit. Op een later tijdstip zal er ook een gebruikersinterface gemaakt worden die artsen en management personeel in staat stelt om op een gebruiksvriendelijke manier nieuwe regels toe te voegen en te verwijderen.

Het regelsysteem zal eigenlijk een tussenlaag vormen tussen de presentatie en de persistentie die een deel van de business logic van de takenapplicatie zal overnemen. Complexe regels kunnen eenvoudig (en at runtime) toegevoegd worden, zonder dat er toevoegingen moeten gebeuren aan de applicatiecode. Deze regels zullen vaak vermijden dat inefficiënte if-then constructies moeten ge¨ımplementeerd worden. Het RETE-algoritme dat gebruikt wordt door de rule engines zorgt immers voor een performantieboost.

3.4

OSGi

Het COSARA platform waarin deze masterproef zal ingeplugd worden maakt gebruik van Felix OSGi. Daarom volgt hier een korte studie naar de werking van OSGi en Felix OSGi.

3.4.1

Algemeen

OSGi is eigenlijk een organisatie voor open standaarden. Zo hebben ze een Javagebaseerd serviceplatform gespecificeerd, dat vanop afstand kan beheerd worden. Dit omvat een framework, dat een applicatie life cycle management model definiëert, alsook modules, service registratie en

3.4 OSGi

36

een execution environment. Het framework ondersteunt de deployment van downloadbare en uitbreidbare applicaties. [44]

OSGi devices kunnen OSGi bundels downloaden, installeren en verwijderen wanneer ze niet meer nodig zijn. Het framework beheert deze installatie en updates op een dynamische manier en beheert dus de afhankelijkheden tussen de verschillende bundels. De functionaliteit van dit framework kan opgesplitst worden in verschillende lagen (zie figuur 3.5): Bundles

Life cycle

Security

Service

Module Execution Environment Java VM Hardware/OS

Figuur 3.5: De lagen van OSGi [44]

Security layer definiëert een veilig packaging formaat en voorziet de infrastructuur om applicaties veilig te beheren en deployen. Module layer definiëert een modularisatie model voor Java. De eenheid van modularisatie is de bundel: dit bestaat uit Java klassen en andere resources samen met een manifest-bestand. Bundels kunnen Java packages delen via exporter en importer bundels. Deze layer bepaalt regels voor het delen van packages tussen bundels en het verbergen van packages van andere bundels. Life Cycle layer voorziet in de levenscyclus API voor bundels. Het definiëert hoe bundels opgestart en gestopt worden en ook hoe ze ge¨ınstalleerd, ge¨ updatet en verwijderd moeten worden. Deze werkt dus samen met de module layer. Service layer definiëert een dynamisch model dat ge¨ıntegreerd is met de life cycle layer. Het service model is een ’publish, find and bind’ model. Een service is een Java object dat gere-

3.4 OSGi

37

gistreerd is onder een interface bij de service registry. Objecten kunnen zich registreren bij de service en kunnen ontdekt worden door andere bundels. Andere layers: de Execution environment is de specificatie van de Java omgeving (bv. J2SE). De Java VM is de virtuele machine waarin de componenten uitvoeren en samenwerken. Daaronder bevindt zich nog het OS en Hardware.

3.4.2

OSGi implementaties

Er zijn verschillende OSGi containers beschikbaar. Hierna volgt een kleine opsomming van de meest gebruikte. Eclipse Equinox Equinox is een implementatie van OSGi Release 4 core framework specificatie en omvat een set van bundels die verscheidene optionele OSGi services implementeren. Het is eigenlijk een pluginsysteem dat ontwikkelaars toelaat om een applicatie in een set van bundels te implementeren die gebruik maken van gemeenschappelijke services en infrastructuur. Eclipse gebruikt sinds versie 3.0 Equinox als plug-in systeem. Het staat bekend om zijn uitgebreide features. Het heeft een zeer actieve userbase en wordt continu bijgeschaafd. [41] Knopflerfish Knopflerfish biedt een andere implementatie van de core framework specificatie. Het ondersteunt reeds alle layers van Release 4, behalve voor security zijn er nog een aantal features niet voorzien. [42] Apache Felix Dit is een open source implementatie van OSGi Release 4 core framework specificatie. De initiële codebase is afkomstig van het Oscar project van ObjectWeb. Het voorziet een gebruiksvriendelijke implementatie, die vrij lightweight is. Het biedt een implementatie van de event admin en van de configuratieadmin. De userbase is beperkter, maar is groot genoeg om toekomstperspectieven te bieden. [43]

3.4 OSGi

3.4.3

38

D-OSGi en R-OSGi

Gezien we werken met een gedistribueerde applicatie is het interessant om te onderzoeken wat de mogelijkheden hiervoor zijn binnen de OSGi beweging. Twee mogelijkheden worden in deze sectie kort besproken: distributed OSGi of D-OSGi (een subproject van Apache CXF), alsook R-OSGi (Information and Communication Research Group of IKS, ETH Z¨ urich). De bedoeling hiervan is om bundels die draaien binnen een bepaald framework op een bepaalde server, ter beschikking te stellen van client bundels binnen een ander OSGi framework. Deze maken dus remote service calls mogelijk tussen verschillende OSGi-containers (zelfs voor verschillende containers met verschillende implementatie). D-OSGi Het Apache CXF Distributed OSGi subproject is de reference implementatie beschreven in OSGi 4.2. Het implementeert remote services met behulp van webservices, via SOAP over http en het uitzetten van de service over een WSDL contract. Het voorziet in goede locatietransparantie en maakt communicatie met niet-OSGi omgevingen mogelijk. De services kunnen ontdekt worden via hun WSDL contract. D-OSGi laat communicatie tussen verschillende containers toe, gezien deze allemaal een implementatie zijn van dezelfde OSGi specificatie. Dit is te zien in figuur 3.6.

Felix OSGi Container

Equinox OSGi Container

CXF DOSGi


CXF DOSGi

Consumer Bundle

invoke

Service Bundle


Figuur 3.6: Voorbeeld van D-OSGi tussen twee containers

Om dit mogelijk te maken is het aantal vereisten beperkt. In zowel de container met de consumer als de container die de remote service aanbiedt moeten de CXF D-OSGi bundels ge¨ınstalleerd en gestart worden. Daarnaast moet de interface in beide containers opgenomen worden. Aan de consumer side is het nodig om in een XML-bestand de remote service te beschrijven. [45]

3.4 OSGi

39

R-OSGi R-OSGi voert uit als een OSGi bundel en faciliteert distributie voor arbitraire OSGi framework implementaties. Een service provider framework moet gewoon de service registreren voor remote toegang. Daaropvolgend kunnen peers zich verbinden met de service provider peer en toegang tot de service verkrijgen. Dit gebeurt volledig transparant. Voor elke remote service wordt een proxy bundel gegenereerd. Lokale service clients kunnen dus de remote service op dezelfde manier aanspreken als lokale services, wat een duidelijk voordeel is ten opzichte van D-OSGi. Het bevat bovendien een zeer goed event systeem. Een nadeel is dan weer dat communicatie met niet-OSGi omgevingen niet ondersteund wordt. [46]

3.4.4

Scenario

Binnen het COSARA platform wordt gebruik gemaakt van Apache Felix. Er is geen reden om over te schakelen op een andere OSGi container, dat zou geen enkel voordeel bieden. Bovendien is Apache Felix strikter qua regels, waardoor bundels van Felix OSGi eenvoudig porteerbaar zijn naar de andere containers. [43] COSARA heeft de volgende belangrijke interfaces: Application is de interface voor elk afzonderlijk programma met eigen frame zoals de COSARA client. Category is de abstracte interface voor een collectie van modules zoals bijvoorbeeld alle tabs binnen COSARA. Module is de interface van een specifieke module. Een categorie wordt voorgesteld binnen de COSARA client door een button rechts bovenaan. Wanneer daarop geklikt wordt, verschijnen onderaan de tabs van de categorie (modules). Zoals te zien in figuur 3.7.

De takenapplicatie die zal ge¨ımplementeerd worden staat op een hoger niveau dan deze interfaces. De takenapplicatie zal een bundel op zich vormen, die door de client kan gedownload, ge¨ınstalleerd en geactiveerd worden wanneer nodig. Normaal gezien zal deze voor elk personeelslid actief zijn. Op zich zal de takenapplicatie volledig onafhankelijk ge¨ımplementeerd worden, en daarna als een bundel gegroepeerd worden. Een service zal gecreëerd worden die een getView() methode aanbiedt, die daarna binnenin een client kan gebruikt worden, om de gebruikersinterface van de takenapplicatie te integreren. Dit zal een intelligente view zijn, die aantoont hoeveel nieuwe taken er zijn.

3.4 OSGi

40

Figuur 3.7: Een deel van de COSARA client met de buttons rechts boven en de tabs

De takenapplicatie is een gedistribueerde applicatie. De client zal enkel het weergeven van de taken afhandelen, alsook input van de gebruiker opvangen. Dit kan enerzijds zijn om taken te starten of te vervolledigen, anderzijds om nieuwe taken toe te wijzen. Aan serverside wordt de data persistent gemaakt en worden de regels afgehandeld. Gedistribueerde OSGi vormt een mogelijkheid. De persistentiebundels worden centraal gehost en worden remote beschikbaar gesteld voor clients. Het is de bedoeling om dit systeem geschikt te maken om in te pluggen in om het even welke OSGi-omgeving, die nood heeft aan een authenticatie-procedure gebaseerd op RFID en aan een takenapplicatie voor de gebruikers ervan.

3.5 Takenophaling

3.5

41

Takenophaling

3.5.1

Algemeen

Binnen de takenapplicatie moet er onderzoek gevoerd worden naar de manier waarop de taken zullen gepolld worden van de database. Logischerwijze wordt ervan uitgegaan dat een persoon inlogt, waarna hij een aantal handelingen uitvoert, alvorens opnieuw uit te loggen. De taken pollen uit de database na inloggen, lijkt dan ook een goede keuze. Maar wanneer de persoon langer ingelogd blijft, moeten nieuwe taken natuurlijk ook kunnen ontvangen worden. Hiervoor zijn er volgende mogelijkheden:

Periodiek polling: dit houdt in dat er om de zoveel tijd wordt gepolld naar nieuwe taken. Dit is het minst efficiënt, maar ook het minst complex. Deze oplossing is courant voor dit soort applicaties. Light push: er wordt een notificatie gepusht naar de client, waarna deze pollt. Voordeel is dat het aantal polls kan geminimaliseerd worden tot het minimum. Pushen: taken kunnen gepusht worden naar de client. Dit biedt dezelfde voordelen als een light push, en bovendien kan op deze manier de datastroom tussen client en server geminimaliseerd worden.

In eerste plaats zullen nieuwe taken na authenticatie opgehaald worden. In een tweede fase zal periodiek pollen ge¨ımplementeerd worden. Het pushen van taken kan eventueel ge¨ımplementeerd worden met behulp van webservices ofwel met behulp van gedistribueerde OSGi en meer bepaald met behulp van de Event Admin. Zowel D-OSGi als R-OSGi maken het mogelijk om gebruik te maken van remote events. Zodra een remote connectie is mogelijk gemaakt, kunnen events immers geforward/gepusht worden naar elke verbonden peer.

3.5.2

Webservices

Een webservice omvat een interface die toegankelijk is via webprotocollen waarbij gecommuniceerd wordt via XML-berichten. Een webservice laat clients toe om diensten, die zich op een zekere server bevinden, aan te spreken vanop afstand. Dit gebeurt via standaardprotocollen zoals http. Webservices kunnen beschreven worden met behulp van WSDL (Web Services Definition Language). Dit is tevens een XML-document dat het model van de webservice voorstelt.

3.5 Takenophaling

42

SOAP Simple Object Access Protocol (SOAP) is een XML-gebaseerde taal voor communicatie tussen webservices en tussen webservices en clients. De communicatie gebeurt met behulp van SOAP berichten. Een dergelijk bericht is een normaal XML document, die de volgende elementen bevat: • Envelope element: deze identificeert het XML document als een SOAP bericht. • Header element: bevat de header informatie zoals de relevante adressen. • Body element: bevat eigenlijk alle respons- en oproepinformatie. Een voorbeeld van een SOAP bericht is te vinden in figuur 3.8.

Methode int doubleNumber

( int number);

SOAP Request <SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:doubleNumber xmlns:ns1="urn:MySoapServices"> <param1 xsi:type="xsd:int">2 SOAP Response <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:doubleNumber xmlns:ns1="urn:MySoapServices" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/ encoding/">

4

Figuur 3.8: Voorbeeld van een SOAP bericht

3.5 Takenophaling

43

Het gaat hier om een eenvoudige methode die een getal verdubbelt. De request geeft het getal dat moet verdubbeld worden door aan de service, die deze verdubbelt, alvorens een respons te genereren met het antwoord. [47] WSDL WSDL beschrijft webservices in een XML formaat. Een WSDL document omvat definities voor onder andere operaties en structuren van berichten (datatypes, vorm). Clients die gebruik willen maken van een webservice kunnen toegang verkrijgen tot het WSDL document en kunnen zo de functionaliteit ontdekken die deze aanbiedt. [48] WS-Eventing WS-Eventing beschrijft een protocol dat een publish-subscribe model mogelijk maakt voor webservice environments. Webservices willen immers vaak berichten ontvangen wanneer er in een andere webservice een zekere event optreedt. Het protocol maakt dit mogelijk door toe te laten dat zekere webservices zich registreren (subscriber) bij een andere webservice (publisher) om op de hoogte gehouden te worden over bepaalde events. [49]

Dit zou het dus eigenlijk mogelijk maken om clients op de hoogte te brengen wanneer een taak gewijzigd is, door middel van een light push mechanisme. De client zou zich dan enkel moeten registreren bij de webservice voor de server side business logic. Dit vormt zo dus een tweede mogelijkheid om de serverside van de applicatie te implementeren, namelijk met behulp van webservices en eventing.

3.5.3

Event Admin

De Event Admin service specificatie is sinds versie 4.2 van OSGi opgenomen in de specificatie. Deze voorziet ontwikkelaars van een standaard manier om te werken met events binnen een OSGi omgeving. Het maakt gebruik van het publish/subscribe model. Events worden gedistribueerd naar listeners die geregistreerd zijn via de EventHandler interface. [44]

Apache Felix heeft een Event Admin implementatie. Ook binnen D-OSGi en R-OSGi is het gebruik van een Event Admin mogelijk. Eclipse Communication Framework laat de creatie van een gedistribueerde Event Admin implementatie toe, die een grote variatie aan protocols kan

3.5 Takenophaling

44

gebruiken. Bijvoorbeeld ActiveMQ (zie figuur 3.9) of XMPP. [50] Ook R-OSGi laat bundels toe om zich te registreren bij een publisher van remote events.

Sender

Sender

EventHandler

EventAdmin Service

Events

EventHandler

EventAdmin Service

ECF Shared Object API

ECF Shared Object API

Provider (Active MQ)

Provider (Active MQ)

topic Active MQ Broker

Figuur 3.9: Event Admin en D-OSGi

3.5.4

Scenario

Voor het scenario (2.2.3) zal dus eerst gewerkt worden met een eenmalige poll na inloggen, waarna taken periodiek zullen opgehaald worden. Zoals besproken in 3.5.1. Daarna wordt dan de webservice oplossing architecturaal uitgewerkt, alsook het alternatief met gedistribueerde OSGi. Daarna volgt een keuze voor de implementatie.

ARCHITECTUUR

45

Hoofdstuk 4

Architectuur De specificatie (hoofdstuk 2) en de onderzochte technologieën (hoofdstuk 3) vormen de basis voor de architectuur van het systeem. In dit hoofdstuk wordt de architectuur van de oplossing uitgetekend. Eerst wordt besproken hoe de specificaties (zowel de functionele als niet-functionele vereisten - zie 2.1) de architectuur zullen be¨ınvloeden. Op basis hiervan wordt een algemeen overzicht uitgewerkt. Daarna volgt een overzicht op componentniveau in 4.2. Gezien het gaat om een gedistribueerde applicatie, wordt ook de deployment view beschreven, zie 4.3. Dit zal dan vooral op niveau van OSGi-bundels zijn. Daarna volgt een collaboratie view, waarin de interactie tussen belangrijke componenten wordt uitgetekend met behulp van sequentiediagrammen. Dit is te vinden in 4.4.

4.1

Conceptuele View

De architectuur moet tegemoet komen aan de functionele en niet-functionele vereisten die uitgezet zijn in 2.1.1 en 2.1.2. Aanpasbaarheid als voornaamste kwaliteitsattribuut heeft een grote invloed op de architectuur. Daarnaast zijn sommige delen van de applicatie zeer afhankelijk van gebruiksvriendelijkheid. Dit is uitermate belangrijk om het gebruik van de takenapplicatie in te burgeren in de dagelijkse activiteiten van het medisch personeel. Ook voor de regelcreatieapplicatie is dit een belangrijk kwaliteitsattribuut. Het is immers de bedoeling dat medisch personeel zonder achtergrond met betrekking tot regelgebaseerde systemen, in staat zal zijn om gewenst regelgedrag te implementeren en toe te voegen.

Het is belangrijk dat de applicatie vlot kan ge¨ıntegreerd worden binnen het bestaande plat-

4.1 Conceptuele View

46

form in het UZ Gent. Daarom is het belangrijk in het achterhoofd te houden dat de applicatie omgezet moet kunnen worden naar OSGi bundels. Gezien de service-oriëntatie van OSGi is het belangrijk om steeds duidelijk interfaces uit te tekenen. Deze kunnen dan later dienen als de service-interfaces binnen OSGi.

Voor de inlogprocedure (2.2.2) is het zeer belangrijk dat er voldoende abstractie ingebouwd wordt. Het moet immers haalbaar zijn om met minimale inspanning te veranderen van hardware. Dit kan een ander soort reader zijn, of een ander soort tag. Het moet ook mogelijk zijn om eventueel meerdere soorten tags en/of readers tegelijk te ondersteunen. Het is immers goed mogelijk dat er in een later stadium artsen met andere pasjes zouden toegelaten worden, bijvoorbeeld artsen die een pasje hebben van een ander hospitaal.

De takenapplicatie moet makkelijk aanpasbaar zijn. Het moet eenvoudig mogelijk zijn om over te schakelen op een andere opslagwijze en het zou een pluspunt zijn, moest de takenapplicatie in de toekomst ook via andere wegen bereikbaar zou zijn. Het zou immers handig zijn voor personeel om ook thuis zijn of haar taken te bekijken om zo eventueel een agenda uit te stippelen voor de volgende werkdag.

Met dit in het achterhoofd en gezien de aard van de applicatie (enterprise applicatie), werd de architectuur uitgezet als een gelaagde client-server architectuur. Deze deelt het systeem in een hiërarchie van partities. Binnenin deze partities is er een zekere cohesie, maar de lagen onderling zijn los gekoppeld. Elk van deze partities communiceert enkel en alleen met aansluitende partities. Dit communiceren houdt enerzijds het aanbieden van services in, anderzijds het consumeren van services. Voordelen betreffende kwaliteitsattributen zijn [51]: • Beveiliging: beveiliging kan gemakkelijk ge¨ımplementeerd worden. De interfaces voor communicatie tussen de layers zijn duidelijk afgelijnd en kunnen dus eenvoudig beveiligd worden. • Aanpasbaarheid: layers kunnen eenvoudig vervangen worden, alsook subcomponenten binnen layers, zonder dat de andere layers moeten aangepast worden. Dit is een heel belangrijk voordeel voor onze key quality attribute. Layers kunnen ook hergebruikt worden buiten deze context. • Betrouwbaarheid: ondersteunt vrij eenvoudig foutopvanging. Fouten kunnen immers

4.1 Conceptuele View

47

doorgegeven worden langs de lagen. • Onderhoud: onderhoud en aanpassingen zijn gemakkelijker doordat de lagen enkel met elkaar communiceren via de interfaces. Een laag kan dus aangepast worden zonder dat de andere lagen daar hinder van ondervinden. Bovendien heeft dit patroon geen negatieve invloed op andere belangrijke kwaliteitsattributen, zoals usability en scalability. Integendeel, schaalbaarheid kan verbeteren als gevolg van het gebruik van dit patroon indien het correct toegepast wordt. Sommige lagen kunnen immers gedupliceerd worden op meerdere servers, om aan load balancing te doen. Zo kan dus de volgende conceptuele architectuur uitgezet worden (zie figuur 4.1): Database

= serverside Rule file

= clientside

Rule Engine

Persistentie layer

Business layer Inlogprocedure

Takenapplicatie

Rule file

Regelcreatie

Presentatie layer Login GUI

Taken GUI

Regelcreatie GUI

Figuur 4.1: Conceptuele view van de architectuur Hierin zijn duidelijk de drie lagen herkenbaar, alsook een losse Rule Engine component: • Persistentie: handelt het persisteren af van de taken. Gezien het programma in eerste instantie zal ontwikkeld worden als een standalone applicatie, zullen hier ook pati¨ entengegevens en gebruikersgegevens gepersisteerd worden. Deze laag moet dus zorgen voor de communicatie met de database. Opstellen van specifieke queries, uitvoeren van transacties vallen dus binnen deze layer. Het is de bedoeling dat deze layer serverside zou werken.

4.2 Component View

48

• Business: hierin bevindt zich de business logic van het systeem. Dit omvat drie belangrijke componenten, gezien we ook in het systeem drie belangrijke functionele eenheden kunnen onderscheiden. Ten eerste dus de business logic die te maken heeft met de inlogprocedure. Deze zal instaan voor de abstractie van de randapparatuur, alsook het beheren van de inlogsessie. Een tweede component is de takenapplicatie business logic. De verantwoordelijkheden voor deze component zijn triviaal, zo zal het een model bevatten met de taken van de huidige gebruiker. Alsook zorgt het voor een verbindingspunt tussen de presentatielaag en de persistentielaag. De derde component omvat de regelcreatieapplicatie business logic. Dit zal onder andere het model zijn, die het programma in staat stelt om regels voor te stellen. Dit werkt clientside. • Presentatie: deze laag staat in voor het clientside presenteren van de data aan de gebruiker. De takenapplicatie zou gebruikers in staat moeten stellen om taken zo eenvoudig mogelijk te beheren. De regelcreatie-applicatie moet ze in staat stellen om regels te maken, die de gewenste functionaliteit kan implementeren. De inlog-gui zal steeds in de achtergrond runnen en kan eventueel tonen op welke poort en welk soort reader er momenteel gebruikt wordt. Nu de conceptuele view op het systeem is uitgezet, kan eigenlijke architectuur uitgetekend worden in termen van componenten (zowel packages als klassen), alsook in termen van bundels en in termen van collaboratievormen. Dit is terug te vinden in de volgende secties. In de componentview zal daarvoor iteratief gewerkt worden. Eerst wordt een diagram voorzien van de lagen, waarna elke laag in detail zal worden toegelicht. De rule engine wordt hierbij nog buiten beschouwing gelaten. Deze zal serverside ge¨ımplementeerd worden. Het diagram toont aan dat deze rechtstreeks op de database inwerkt (namelijk om taken toe te voegen etc.). Maar de package bevindt zich niet bij de andere logic in de business layer, gezien deze clientside werkt.

4.2 4.2.1

Component View Package diagram

In deze eerste architecturale iteratie wordt de top view uitgezet. Dit is een package diagram, waarbij tot een diepte van twee niveaus wordt uitgetekend. Dit is te zien in figuur 4.2. Klassediagrammen en expliciete interfaces worden hier nog niet voorzien, om de algemene leesbaarheid te bevorderen. De service packages omvatten de interfaces, die instaan voor de communicatie

4.2 Component View

49

tussen de packages. De impl packages vormen een implementatie. Deze structuur is uitermate geschikt om te converteren naar OSGi bundels. De services zullen dan omgezet worden naar OSGi services, terwijl de implementatie packages een mogelijke implementatie aanbieden. Hierna volgt een beknopte uiteenzetting van de verantwoordelijkheid van alle subpackages.

persistence core

dao

manager

entities

impl

impl

util

service

service

business login

taskapp

ruleapp

communication

impl

io

filtering

service

model

abstraction

impl

util

service

presentation login

taskapp

ruleapp

service

service

service

impl

impl

impl

Figuur 4.2: Top view van de architectuur

4.2 Component View

50

Persistence :: Core De core omvat twee subpackages, namelijk entities en util. De entities-package omvat de database-entiteiten die een rol spelen binnen de applicatie. Ook relaties tussen de entiteiten worden hierin voorgesteld. Daarnaast is er de util (kort voor Utilities) package, waarin zich wrappers bevinden voor deze objecten, die eenvoudig te distribueren zijn (rekening gehouden met vlot marshallen en unmarshallen). Daarnaast bevat de util package ook nog twee utility klassen, voor de personeelsrol en voor de prioriteit. Meer over de package is te vinden in 4.2.2. De util package wordt stilzwijgend gebruikt door de andere packages (dit is voor het overzicht niet uitgetekend). Persistence :: DAO DAO staat voor Data Access Object. Deze package zal voor alle belangrijke entiteiten een DAO bevatten en aanbieden als service. De services zijn de interfaces die de methodes aanbieden aan de business logic layer. Deze zijn in staat om queries uit te voeren op de databank.

De impl package biedt implementaties voor deze interfaces. De implementatiepackage maakt gebruik van de entities uit de core, alsook van de wrappers uit de util package. De services werken uitsluitend met wrappers. De implementatie maakt gebruik van de manager package, voor het afhandelen van transacties. Meer informatie is te vinden in 4.2.3. Persistence :: Manager Deze package staat in voor het opzetten van de connectie met de database en het beheren van transacties. De service package biedt dan ook een interface met de nodige methodes om transacties te beheren. De impl package biedt toegang tot een specifieke persistentie-eenheid. Een volledige uiteenzetting is te vinden in 4.2.4. Business :: Login Deze subpackage van de business logic is verantwoordelijk voor de RFID inlogprocedure. Gezien deze procedure voldoende abstractie moet kunnen creëren van de onderliggende hardware, is hier gekozen voor een pipes-and-filter patroon, dat de data van reader tot de database zal leiden. De util package met daarin Model (beheer van ChangeListeners) wordt stilzwijgend gebruikt.

4.2 Component View

51

Het bevragen van de reader gebeurt in de abstraction package. Deze package zorgt voor abstractie van de onderliggende reader hardware. Deze wordt periodiek bevraagd door de filtering laag. Deze laag maakt het mogelijk om verschillende tagtypes te analyseren en de ID te extraheren. Wanneer deze een ID opmerkt, wordt een event gestuurd naar de bovenliggende laag, namelijk de communication layer. Deze vraagt dan de ID data op en gaat de communicatie met de databank afhandelen door de DAO service van de persistentie aan te spreken, die met behulp van de manager package de databaseconnectie tot stand brengt.

Naast deze drie packages voor de inlogprocedure, is er nog een package voor algemeen beheer van readers, filters en sessiebeheerder (communication). Dit beheer biedt een service aan voor configuratie en creatie van readers en om een logout van de gebruiker op te vangen. De impl package biedt een implementatie hiervoor, te vinden in 4.2.5. Business :: Taskapp Deze package is voornamelijk een model voor de taken van een ingelogde gebruiker en alles wat er bij te pas komt. Het biedt methodes aan als een service, die aangesproken kan worden door een takenverwerker of een takenpresentator. De impl package biedt een implementatie van deze interface die communiceert met de DAO services (zie 4.2.6). Business :: Ruleapp De business logic van de ruleapp omvat enkel de io package en de model package. De IO package staat logischerwijze voor het wegschrijven van de data naar een bestand. Het model modelleert zowel het rulebestand, als de rules die het bevat. Een rule omvat op zijn beurt condities en consequenties (zie 4.2.7). Presentation :: Login De impl spreekt de service van de business laag aan om de reader en filter te configureren en te starten. Daarnaast handelt deze ook af wat er gebeurt na het inloggen. Dan wordt de taskapp en de ruleapp gestart. De service omvat nu gewoon een methode die zeker moet ge¨ımplementeerd worden, namelijk een stateChanged() voor het opvangen van een login en logout. Meer informatie is te vinden in 4.2.8.

4.2 Component View

52

Presentation :: Taskapp De structuur hier is gelijkaardig en omvat opnieuw een service en impl package. De service zal nu een methode aanbieden om de gui te initializeren en te starten, wat zal gebeuren wanneer de gebruiker de takenapplicatie activeert. In deze proof of concept zal dat gebeuren na een login. De implementatie zet structuur en gedrag van de gui uit (4.2.9. Presentation :: Ruleapp Deze package is volledig gelijkaardig aan de package voor de takenapplicatie. (4.2.10)

De eerste iteratie in het architecturaal ontwerp is hiermee afgerond. Nu kan er meer in detail getreden worden en kunnen de interfaces en klassen bestudeerd worden. Dit zal gebeuren per layer en per package (diepte 1 binnen layer), om het overzicht te bewaren.

4.2.2

Persistence :: Core

Dit diagram (figuur 4.3) zet de velden van de core klassen uit. persistence core entities

Task - id: Long - title: String - text: String 0..n - patient: Patient - dateAssigned: Date - dateCompleted: Date - taskAssigner: App_User 0..n - taskAssignee: App_User 0..n - priority: Priority - completed: boolean - isGeneralTask: boolean - roleAssigned: boolean - isInProgress: boolean - staffRole: StaffRole

Patient

1 0..n

- id: Long - firstName: String - secondName: String - discharged: boolean - tasksRegardingPatient: Collection - treatingStaff: Collection <App_User>

App_User - id: Long - rfidid: String - name: String - staffrole: StaffRole 1 - isAdmin: boolean - tasksAssignedByUser: Collection - taskAssignedToUser: Collection 1 - patientsTreatedByUser: Collection<Patient> 0..n

Figuur 4.3: Voornaamste klassen in persistence.core.entities

4.2 Component View

53

Naast deze klassen is er nog de util package. Deze bevat twee enumeratie klassen, namelijk StaffRole en Priority. Deze zijn uitgetekend in figuur 4.4. Daarnaast bevat het ook voor elke persistentieklasse een wrapper: UserWrapper, TaskWrapper en PatientWrapper. Wrapperobjecten bevatten dezelfde informatie als hun corresponderende persistentie-objecten, maar bevatten geen meervoudige relaties en bevatten ook geen referenties naar andere entiteiten, maar wel naar hun corresponderende wrappers. Bij TaskWrapper wordt de Patient bijvoorbeeld vervangen door een PatientWrapper.

persistence core util <<enumeration>>

<<enumeration>>

StaffRole

Priority

DOCTOR NURSE CHIEFNURSE

HIGH MEDIUM LOW

Figuur 4.4: Voornaamste klassen in persistence.core.util

4.2.3

Persistence :: DAO

Zoals reeds vermeld, staat DAO voor Data Access Object. Dit is een object die een interface voorziet naar een bepaalde database of persistentie-eenheid. DAO’s bieden dus zekere operaties aan, zonder de details van de database te onthullen. • PatientDAO: PatientDAO voorziet alle specifieke operaties met betrekking tot de Patiententiteit. Dit omvat het aanmaken, verwijderen, bevragen en bewerken van patients. • UserDAO: De UserDAO voorziet operaties met betrekking tot de AppUser entiteit. Dit omvat opnieuw alle standaard operaties. • TaskDAO: De TaskDAO is de belangrijkste DAO voor de takenapplicatie. Het omvat verschillende manieren om taken op te vragen, bijvoorbeeld voor algemene taken, rolgeassigneerde taken en taken gebonden aan een specifieke gebruiker.

4.2 Component View

54

Het klassendiagram is te vinden in figuur 4.5. persistence dao service

impl

patient

patient <>

PatientDAOImpl

PatientDAO + newPatient(firstName: String, secondName: String): PatientWrapper + deletePatient(patientId: long): void + deleteAllPatients(): void + getPatient(id: Long): PatientWrapper + getPatient(firstName: String, secondName : String): PatientWrapper + getPatientList(): Collection<PatientWrapper>

user

user <>

UserDAOImpl

UserDAO + newUser(rfidid: String, name: String, StaffRole staffRole): UserWrapper + deleteUser(rfidid: String): void + deleteAllUsers(): void + getUser(rfidid: String): UserWrapper + getUserByName(name: String): UserWrapper + getUserList(): Collection<UserWrapper> + getPatientListByRfidid(rfidid: String): Collection<PatientWrapper> + getPatientListByName(name: String) : Collection<PatientWrapper>

task

task <>

TaskDAO + newTaskByNames(taskAssignerName: String, taskAssigneeName: String, patientId: Long, deadline: Date, title: String, text: String, priority: Priority, isGeneralTask: boolean, isRoleAssigned:boolean, staffRole staffRole): TaskWrapper + newTaskByRfidAndName(taskAssignerRfidid: String, …): TaskWrapper + deleteTask(long taskId): void + deleteAllTasks(): void + getTask(Long id): TaskWrapper + getTasksAssignedToUser(assigneeRfidid: String): Collection + getGeneralTasks(): Collection + getRoleAssignedTasks(StaffRole role): Collection + getTasksAssignedByUser(assignerRfidid: String): Collection + getTaskList(): Collection + setTaskCompleted(taskId: Long, completed: boolean) + setTaskInProgress(taskId: Long, inProgress: boolean)

Figuur 4.5: Klassen in persistence.dao

TaskDAOImpl

4.2 Component View

4.2.4

55

Persistence :: Manager

Deze eenvoudige package omvat een interface en een implementatie. Zoals reeds besproken is deze verantwoordelijk voor transactiebeheer door toegang te verschaffen tot een EntityManager. De DAO’s openen voor elke request een nieuwe manager. Deze EntityManager is geassociëerd met een persistentiecontext. Dit is een set van entiteit-instanties waarvan de levenscyclus beheerd wordt door de EntityManager. persistence manager service

impl <>

EntityManagerCache

EntityManagerCacheImpl

+ createEM(): void + disposeEM(); void + getEM(): EntityManager + beginTransaction(): void + commitTransaction(): void + rollbackTransaction(): void

Figuur 4.6: De klassen van persistence.manager

Wanneer er bijvoorbeeld een nieuwe taak gemaakt wordt, moet eerst een EntityManager gemaakt worden, daarna moet een transactie gestart worden. Binnen de transactie zal dan in de TaskDAO uit 4.2.3 de taak gemaakt worden, waarna de transactie gecommit kan worden om finaal de EntityManager te sluiten.

4.2.5

Business :: Login

Deze package staat in voor al de business logic binnen het logingedeelte. Er werd gekozen voor een pipes-and-filter patroon, namelijk met drie lagen: abstraction, filtering en communication. De data gaat hierbij van abstractie tot communicatie. De abstractiepackage maakt dus het contact met de reader, terwijl de communicatie instaat voor het sessiebeheer (kijkt de ID na in de databank - staat wel los van pure RFID-gedeelte). Deze structuur wordt beheerd door een centrale RFIDManager. Die zal afhankelijk van de gebruikersinput connectie maken met een reader en filtert op basis van een tagtype. Deze wordt uitgezet na de pipes-and-filter structuur.

4.2 Component View

56

Deze packages zijn uitgetekend in figuur 4.7. business util

Model login communication service

impl <>

RFIDSessionManager + login (rfidid: String): UserWrapper + logout: void + addChangeListener(l: ChangeListener): void + getName(): String + getRole(): String + getRfidid(): String

RFIDSessionManagerImpl - currentID: String - active: boolean - filters: List - userDAO: UserDAO

filtering service

impl <>

GIDTagFilter

AbstractFilter + getCurrentID(): String + setCurrentID(currentID: String): void + isActive(): boolean + pause(): void + restart(): void + getReader(): AbstractReader + setReader(reader: AbstractReader): void + startFilter(interval: int): void + stopFilter(): void + addChangeListener(l: ChangeListener): void + addTagType(type: TagType): void + removeTagType(type: TagType): void

- currentID: String - active: boolean - reader: AbstractReader - supportedTypes: List - readEveryInterval(interval: int): void + extractID(tag: String): String

abstraction service

impl <>

DefaultReader

AbstractReader + startReader(): void + stopReader(): void + isRunning(): boolean + readTagsFromReader(): String + getType(): String + setIP(ip: String): void + setPort(port: int): void

- connection: Socket - out: PrintWriter - in: BufferedReader - readFromReader(in: BufferedReader)

Figuur 4.7: Klassen in businesss.login (1)

4.2 Component View

57

De services binnen deze package zijn: • AbstractReader: leest tags van de reader via readTagsFromReader(). Deze data bevat naast de ID ook (voor de inlogprocedure) nutteloze informatie; dit is echter afhankelijk van het tagtype. Het biedt een aantal methodes aan om de reader te starten en te stoppen naast nog een aantal configuratiemethodes. De DefaultReader is een standaard implementatie. Dit is de enige readersoort die zal ondersteund worden binnen deze proof of concept. Het is wel eenvoudig om een nieuwe implementatie toe te voegen. • AbstractFilter: filtert periodiek de ID uit de data afkomstig van de corresponderende reader en houdt de laatst ingelezen ID bij. In de implementatie gebeurt het inlezen via readEveryInterval(). Maar indien gekozen wordt voor een andere manier voor de bevraging, kan een andere bundel voorzien worden. Deze filter bevat als tagtype GID96, vandaar GIDTagFilter. Het extraheren is voorzien in de extractID() methode die gebruik kan maken van de TagType services, die een extractie-methode bieden voor bepaalde tagtypes en kunnen toegevoegd worden aan een filter. Gezien de eenvoud van die services worden deze niet getoond in de figuur (voor meer uitleg, zie 5.4). De filter is een uitbreiding van Model (een klasse die ChangeListeners beheert). De objecten die op de hoogte willen blijven van de currentID, kunnen zich registreren bij de filter. De GIDTagFilter stopt met de reader te bevragen als iemand succesvol inlogt. • RFIDSessionManager: registreert zich als listener bij de filter(s) en staat in voor het starten, stoppen en herstarten van de filter(s). RFIDSessionManagerImpl implementeert deze interface. Wanneer een filter zijn currentID verandert, tracht de RFIDSessionManager de ID te vinden in de gebruikersdatabase (vandaar het veld voor de UserDAO). Indien een match gevonden wordt, kan de gebruiker ingelogd worden. Anders gaat de filter gewoon verder. Bij een succesvolle login zal deze ook een event afvuren, vandaar dat ook de RFIDSessionManagerImpl een uitbreiding is van Model. Het beheert informatie over de huidige gebruiker. Het voorziet ook een logout methode. Deze herstart de filters. Een alternatief is de filters niet te pauzeren tijdens de inlogperiode. De RFIDManager gaat niet enkel deze structuur beheren, maar biedt zich als een service aan voor de presentatielaag. Deze is dus ook een model (MVC-patroon), waarin gegevens van de ingelogde gebruiker kunnen gevonden worden (via de RFIDSessionManager). Het biedt daarnaast methodes voor het instellen van readers en filters. Alsook een methode om een logout uit te

4.2 Component View

58

voeren, die doorgegeven wordt aan de RFIDSessionManager (logout is afkomstig van gebruiker, login afkomstig van filter). De start(filter) methode, start een filter. Dit is te zien in figuur 4.8. business login service

impl <>

RFIDManagerImpl

RFIDManager + getUserName(): String + getRfidId(): String + getStaffRole(): String + setIP(ip: String): void + setPort(port: int): void + setInterval(interval: int): void + logout(): void + addChangeListener(l: ChangeListener): void + start(filter: AbstractFilter): void + getFilters(): List

- session: RFIDSessionManager - filters: List - readers: List

Figuur 4.8: Beheer van business.login

4.2.6

Business :: Taskapp

Deze package bevat enkel een interface voor de presentatielaag en een implementatie van deze interface. De implementatie zorgt voor het contact met de persistentielaag (4.2.3). Het diagram is te vinden in figuur 4.9. De TaskManager vormt een model voor de takenapplicatie voor de ingelogde gebruiker. Daarom voorziet deze een setCurrentID() methode, die ingesteld wordt wanneer een gebruiker inlogt. Na inloggen haalt de takenapplicatie eenmalig de taken op (besproken in 3.5.4). Ook alle patiënteninformatie en gebruikersinformatie (beide belangrijk voor takentoewijzing) worden eenmalig opgehaald.

Wanneer er echter een periodieke poll volgt, worden de opgeslagen taken opnieuw ingeladen uit de persistentielaag. Ook bij een light push, zullen de taken opnieuw ingeladen worden vanuit de persistentielaag. Zo kunnen dus taken gecreëerd terwijl de gebruiker ingelogd was, toch gezien worden zonder dat de gebruiker moet herinloggen. De TaskManager fungeert opnieuw als model binnen een MVC-patroon. Wanneer de gebruiker een taak maakt of aanpast, wordt dit doorgegeven aan de manager. Deze communiceert dat naar de persistentie, waarna de GUI ge¨ updatet wordt.

4.2 Component View

59

business util

Model

taskapp impl

service <>

TaskManagerImpl

TaskManager + newTaskFromCurrentUser(taskAssigneeName: String, patientId: Long, deadline: Date, title: String, text: String, priority: Priority, isGeneralTask: boolean, isRoleAssigned:boolean, staffRole staffRole): TaskWrapper + deleteTask(Long taskId): void + setCurrentRfidId(rfidId: String): void + getAmountOfIncompleteTasks(): int + getTasksAssignedByCurrentUser(): Collection + getTasksAssignedToCurrentUser(): Collection + getAllPatientNames(): Vector<String> + getPatientNamesOfAssignee(assigneeName: String): Vector<String> + getPatientIdsOfAssignee(assigneeName: String): Vector + getNamesOfPossibleAssignees(): Vector + tableChanged(e: TableModelEvent): void + addChangeListener(l: ChangeListener): void + highPriorityTasksInList(tasks: Collection): boolean + setInProgress(inProgress: boolean): void + getTaskAlreadyStartedConflict(): boolean + resetForPoll(): void

- userDAO: UserDAO - patientDAO: PatientDAO - taskDAO: TaskDAO - userId: String - tasksAssignedToUser: Collection - tasksAssignedByUser: Collection - patientNames: Vector<String> - possibleAssignees: Vector<String>

Figuur 4.9: Klassen van business.taskapp

4.2.7

Business :: Ruleapp

Dit bevat een IOManager, die in staat is om bestanden weg te schrijven (figuur 4.10). business ruleapp io service

impl <>

IOManager

IOManagerImpl

+ getContents(file: File): String + appendContents(file: File, contents:String): void

Figuur 4.10: Input en output van business.ruleapp

4.2 Component View

60

Het model voor de presentatielaag bevindt zich in de business.ruleapp.model package. Dit is te zien in figuur 4.11. Dit model heeft daarnaast nog een opsplitsing voor condition en consequence. business ruleapp model util

RuleManager Model - ruleFileModel: RuleFileModel - currentCondition: Condition - currentRule: Rule

Import - pckg: Package - simpleName: String + toString(): String

Rule - name: String - salience: int - imports: imports - consequenceList: List - conditionList: List - objectMap: Map<String, Class> - ruleFile: RuleFileModel

RuleFileModel - pckg: String - imports: List - rules: List - classToFieldNames: Map - classToFieldClasses: Map

Figuur 4.11: Model voor regelcreatie-gui

• RuleManager: stelt de gebruiker in staat om de huidige rule te veranderen. Zo kan er veranderd worden van rule die momenteel bewerkt wordt. Ook de conditie waar momenteel aan gewerkt wordt kan veranderd worden. Dit zal bijvoorbeeld het geval zijn wanneer aan een bepaalde conditie nog extra voorwaarden moeten toegevoegd worden. • Import: eenvoudige voorstelling van een import, deze worden automatisch gecreëerd en toegevoegd wanneer zekere klassen gebruikt worden binnen een rule of condition. • RuleFileModel: stelt een .drl bestand voor. Heeft een lijst met rules en imports, die opgebouwd wordt uit de regels die er deel van uit maken. Op die manier worden imports

4.2 Component View

61

niet dubbel toegevoegd. Daarnaast kan deze voor relevante klassen de veldnamen en klassen teruggeven, via getFieldNames(Class cls). Daarna instantiëert hij deze, zodat de klassenreflectie beperkt wordt. • Rule: omvat een regel met naam, (eventueel) salience, een lijst van condities en consequenties. Alsook een map van objecten naar de klasse ervan (elke conditie krijgt immers en zekere klasse en naam die eraan gebonden zijn). Het houdt een referentie bij naar zijn file, om import redenen. Deze houdt een lijst met imports bij die uniek zijn binnen de rule. Dit is om gemaksredenen bij het verwijderen van de rule uit de file. De condition package omvat volgende klassen (figuur 4.12). business ruleapp model condition <>

Condition - nameOfObject: String - classOfObject: Class - rule: Rule - expressions: List<Expression> - operators: List

Operator + toString(): String <>

<>

ComparisonOperator

LogicalOperator

+ toString(): String

Equals

NotEquals

And

Or

Expression - condition: Condition + toString(): String

Variable

Comparison

Combination

Literal

- classVariableBelongsTo: Class - dataType: Type - fieldName: String

- expression1: Expression - expression2: Expression - operator: ComparisonOperator

- expression1: Expression - expression2: Expression - operator: LogicalOperator

- literalValue:String

Figuur 4.12: Model voor een ruleconditie

4.2 Component View

62

• Operator: stelt alle mogelijke operatoren voor. Hiervoor zijn er twee extensies, namelijk LogicalOperator en ComparisonOperator, die beiden een aantal subklassen hebben. Voorlopig zijn dit respectievelijk And en Or, alsook Equals, NotEquals, Greater en LessThan. • Expressie: is een recursief uitbreidbare structuur zonder haakjes. Heeft een aantal subklassen: Variable, Literal, Combination en Comparison. Een combinatie omvat twee expressies, gecombineerd met een logische operator. Een vergelijking omvat twee expressies en een vergelijkingsoperator. • Condition: stelt een conditie voor. Bestaat uit een aantal expressies, die samengebonden worden door een aantal logische operatoren. Deze expressies zijn omringd door haakjes. Op deze manier kunnen we dus de courante vormen van regels vormen met aanzienlijk gemak. De consequence package omvat volgende klassen (figuur 4.13). business ruleapp model consequence <>

Consequence - rule: Rule + toString(): String

CreationConsequence - task: TaskWrapper

AlterConsequence - objectName: String - fieldName: String - newValue: String

Figuur 4.13: Model voor een ruleconsequence

• Consequence: is een abstracte klasse die een consequentie voorstelt. Dit kan een CreationConsequence of een AlterConsequence zijn. De eerste stelt een takencreatie

4.2 Component View

63

consequentie voor, de tweede verandert de waarde van een zeker veld van een taak. Dit zal in dit eindwerk de prioriteit zijn. Deze klassen laten ons toe om regels van alle mogelijke vormen tot stand te brengen. De conversie naar een .drl bestand gebeurt met behulp van toString() methodes. Deze zijn voorzien in alle klassen. Het enige wat er moet gedaan worden wanneer de gebruiker zijn .drl bestand wil wegschrijven, is de toString() methode oproepen van het RuleFileModel en de string doorgeven aan de IOManager. Het RuleFileModel voert toString() immers uit voor alle regels, alle condities van die regels (recursief voor de expressies binnen een conditie) en tot slot ook voor alle consequenties.

4.2.8

Presentation :: Login

Dit is een eenvoudige JFrame extensie. Voor meer informatie, refereer ik naar de uiteindelijke broncode.

4.2.9

Presentation :: Taskapp

Deze takengui is iets ingewikkelder. Hier wordt gewerkt met een JTabbedPane, met een aantal panels. De klassen zijn te vinden in figuur 4.14. presentation taskapp impl

TaskGUIFrame

TaskAppPanel

TaskAppAddPanel

TaskTablePanel

TaskViewPanel

TaskTable

TaskTableModel

AssigByModel

AssigToModel

Figuur 4.14: Klassen van de takengui

4.2 Component View

64

De TaskTable omvat een takenlijst. De TaskManager vormt het model voor de TaskTableModels. Gezien deze specifiek zijn aan deze presentatiewijze, bevinden deze zich in de presentation layer en niet in de business layer.

4.2.10

Presentation :: Ruleapp

Gezien het kwaliteitsattribuut usability voor deze subapplicatie een sleutelattribuut is, is deze gui zo gebruiksvriendelijk mogelijk uitgewerkt. Onderstaande figuur (4.15 is dan ook een vereenvoudiging van de eigenlijke architectuur. presentation ruleapp impl

RuleAppPanel

ConditionJPanel

ConditionJPanel WithCheckBox

RuleTree

TaskCreationPanel

JTree Variable JComboBox

Operator JComboBox ValuePanel

Figuur 4.15: Klassen van de rulegui

Het algemene idee voor het conditiegedeelte, is dat er een optie wordt gekozen voor een conditie, namelijk een welbepaalde klasse. Deze combobox wordt beluisterd door een aantal ConditionJPanel en afhankelijk van de keuze vullen deze andere comboboxen in en/of veranderen ze deze in tekstvelden. De gebruiker kan tot vier condities invullen, dan moet hij wel een operator aanduiden. Daarna kan deze conditie verder aangevuld worden, doordat het verschijnt naast de klassen voor de conditieopties. Voor de consequenties is het gelijkaardig.

Wanneer een rule vervolledigd is, kan deze gezien worden in de boomstructuur. Daarna kan men deze daarin selecteren om hem te bewerken of verwijderen. Dit vormt dan een meer gea-

4.2 Component View

65

vanceerde view op het regelbestand. Daarnaast is er ook een panel waar het echte regelbestand kan gezien en weggeschreven worden.

4.2.11

Uitbreiding :: Regelevaluatie

De rule engine architectuur wordt beschreven als een uitbreiding. Dit vooral omdat er meerdere opties zijn voor de plaats hiervan binnen de architectuur. De keuze werd gemaakt om dit serverside te implementeren. Clientside heeft als nadeel dat het beheer van de .drl files moeizaam zal verlopen. Een wijziging zal steeds moeten gedupliceerd worden naar alle clients. Voordeel is dat de evaluatie van rules niet centraal moet gebeuren en er dus minder belasting zal zijn op de centrale server. Serverside kan de rule-evaluatie rechtstreeks op de database inwerken. Dit heeft als voordelen voornamelijk dat de evaluatie eventueel kan uitgespreid worden over meerdere rule-engine instanties (of werken via gedistribueerde regelevaluatie).

rule impl

service <>

RuleManager

RuleManagerImpl - ruleEngine: RuleEngine

+ assignPriorities(tasks: Collection, Collection<Patient>, user: App_User): boolean + assignSystemTasks(tasks : Collection , patients: Collection<Patient>, user: App_User): Collection

RuleEngineImpl - kbasePriorityAssignment: KnowledgeBase - kbaseTaskCreation: KnowledgeBase

<>

RuleEngine

+ fireRulesForPriorityChange(tasks: Collection, Collection<Patient>, user: App_User): boolean + fireRulesForCreation(tasks : Collection , patients: Collection<Patient>, user: App_User): Collection - readKnowledgeBase(String fileName): KnowledgeBase

Figuur 4.16: Klassen voor rule-evaluatie

De architectuur van het regelgedeelte is eenvoudig gehouden. Deze is makkelijk uitbreidbaar wanneer besloten wordt om bijvoorbeeld een enkele sessie op te zetten, die voortdurend facts bijmaakt en intrekt. Voorlopig is deze vooral gemaakt om bijvoorbeeld om de zoveel tijd alle regels te evalueren.

4.3 Deployment View

4.2.12

66

Uitbreiding :: Webservice

Deze webservice zou de serverside functionaliteit aanbieden. Deze zou centraal geplaatst worden en aangesproken worden door de clients. Dit is te zien in figuur 4.17. Pushen wordt dan mogelijk met behulp van WS-Eventing (3.5.2). Deze webservice kan immers alle clients die daarvoor interesse tonen, een event pushen wanneer bv. een taak toegevoegd wordt. Voor deze proof of concept zal echter gekozen worden voor gedistribueerde OSGi met behulp van D-OSGi (zie 5.3 voor meer uitleg).

<<webservice>>

DAOService

persistence core

dao

manager

entities

impl

impl

util

service

service

Figuur 4.17: Webservice voor serverside

4.3

Deployment View

Deze view zet de bundel view uit. Gezien we zullen werken binnen OSGi containers en met gedistribueerde OSGi, maken we een onderscheid tussen twee belangrijke containers. De ene zal draaien op de server, de andere zal draaien op de client. De persistentielaag wordt op de server geplaatst: gecentraliseerd werken is aangewezen.

Er wordt zoveel mogelijk onderscheid gemaakt tussen de service en de implementatie ervan. Op deze manier kunnen nieuwe versies van implementaties en/of andere implementaties geplaatst worden zonder downtime. De regelevaluatie wordt hier binnen de OSGi container geplaatst. In de proof of concept werkt deze als een aparte applicatie in op de database.

4.3 Deployment View

67

De volledige view is uitgezet in figuur 4.18. Sommige bundels hebben hier een vereenvoudigde naam. Dit voornamelijk om het overzicht te bewaren. Ook niet alle afhankelijkheden worden getoond, enkel de belangrijke. De gedistribueerde services moeten gedupliceerd worden aan clientside, anders is unmarshaling van complexe datatypes onmogelijk. <<executionEnvironment>> Operating System LAN

<<artefact>> Database

Server Felix OSGi Container

<> Core

<>

Drools

<> RuleEvaluation

<> EclipseLink

<> EntityManagerCacheImpl

<> UserDAOImpl

<> PatientDAOImpl

<> TaskDAOImpl

<> CXF DOSGI

<> EntityManagerCache

<> UserDAOService

<> PatientDAOService

<> TaskDAOService

LAN

D-OSGi Client Felix OSGi Container <> CXF DOSGI

<> SessionService

<> SessionImpl

<> TaskImpl

<> IOImpl

<> AbsoluteLayout

<> FilterService

<> FilterImpl

<> TaskService

<> IOService

<> TagTypeService

<> ReaderService

<> ReaderImpl

<> LoginService

<> LoginImpl

<> LoginGUI

<> TaskGUI

<> RuleGUI

<> LoginGUIImpl

<> TaskGUIImpl

<> RuleGUIImpl

<> RuleModel

<> Core <> BusinessUtil

<> UserDAOService

<> PatientDAOService

Figuur 4.18: Deployment view

<> TaskDAOService

4.4 Collaboratie view

4.4

68

Collaboratie view

Deze sectie illustreert een aantal belangrijke communicatieprocessen tussen de componenten. Op die manier wordt de werking van het systeem een stuk duidelijker. De communicatie wordt uitgezet in termen van de scenario’s die besproken zijn in hoofdstuk 2.

4.4.1

Inlogprocedure

Dit scenario (zie 2.2.2) werkt de communicatie uit bij een succesvolle login. De communicatie tussen reader en filter wordt als eerste uitgezet. Er wordt aangenomen dat de RFIDManager reeds succesvol beide heeft gestart en de nodige parameters (interval, port, ip etc.) heeft ingesteld en de filter gestart is. filter: AbstractFilter

Filter en reader

reader: AbstractReader

1: isRunning()

String readTag = reader.readTagsFromReader(); 2: readEveryInterval(this.interval) String readId = this.extractId(readTag)

2.1: readTagsFromReader()

2.2: extractID(readTag) stateChanged oproep bij RFIDSessionManager bij succesvolle login wordt de filter gepauzeerd

alt readId != null alt

2.3: setCurrentId(readId) !readId.equals(currentId)

Thread.sleep(interval)

alt [active]

{recursive} readEveryInterval(interval)

Figuur 4.19: Interne werking van reader en filter

De filter kijkt of de reader actief is. Daarna gaat de filter deze recursief bevragen. Elk interval gaat het de tags aan de reader vragen. Indien er een tag is gevonden, gaat hij de ID extraheren. Indien deze een geldige vorm heeft en deze is niet gelijk aan de currentID (laatst ingelezen,


69

zorgt ervoor dat bij een foute login niet steeds opnieuw de DB wordt gecheckt), dan wordt de currentID ingesteld, waarna een ChangeEvent gestuurd wordt naar de sessiebeheerder. Session, EntityManager en DAO De sessiemanager krijgt een ChangeEvent van de filter. Vervolgens gaat deze kijken in de databank of er een dergelijke gebruikersid bestaat. Om dit te doen maakt de DAO eerst een EntityManager via EntityManagerCache (waarvan steeds een nieuw object wordt gemaakt). Daarna volgt de toegang tot de databank. session: RFIDSessionManager

AbstractFilter

emc: EntityManagerCache

userDAO: UserDAO

1: stateChanged(e) 3: getCurrentID()

UserWrapper user = login(…)

2: login(filter.getCurrentID()) 3: getUser(rfidid)

4: createEM() 5: createQuery

6: disposeEM()

7: user (return) Stelt currentID, username en rol in. alt user != null

8: pause() 9: fireStateChanged()

Gaat dan naar RFIDManager, zo naar GUI’s. In dit geval is er een succesvolle login.

Figuur 4.20: Interne werking van sessie en databanktoegang

4.4.2


De takenapplicatie en de communicatie (zie 2.2.3) is eenvoudig gezien de aflijning van de interfaces. Wanneer de gebruiker de takenapplicatie activeert worden alle nodige DAO’s aangesproken voor relevante informatie: deze gebruiken daarvoor EntityManagers. Alles wordt opgeslagen in datastructuren. Enkel bij een poll worden deze opnieuw hervuld. Bij gebruikersinput (bv. takencreatie, starten van taak) wordt een transactie tot stand gebracht door de DAO.


70

Starten van taak Een voorbeeld van een tranactie is te zien in 4.21.

taskManager: TaskManager

user

emc: EntityManagerCache

taskDAO: TaskDAO

1: getTasksAssignedToCurrentUser() 2: getTasksAssignedToUser(rfidid)

3: createEM() 4: createQuery(..)

5: disposeEM() 6: tasksAssignedToUser (return) 5: startTask() Kijkt of taak reeds gestart is, terwijl de persoon ingelogd is en dit dus nog niet heeft kunnen zien (nog geen poll). In dit geval foutmelding, volgende stappen niet

7: getTask()

8: createEM() 9: createQuery(..) 10: disposeEM()

11: setTaskInProgress(true)

12: createEM()

task.setInProgress()

13: beginTransaction()

Gebruiker ziet in tabel dat taak gestart is

14: commitTransaction() 15: disposeEM()

Figuur 4.21: Interne werking van takenapplicatie en databanktoegang

De user komt hier overeen met acties die vanuit de GUI zouden komen. StartTask zal bijvoorbeeld het aanvinken van de checkbox ’Task In progress’ zijn.

4.4.3

Takenapplicatie met automatische prioriteitsassignatie en takencreatie

Gezien de beperkte complexiteit van het scenario en de interactie tussen de relevante componenten wordt hiervoor geen sequentiediagram gegeven. Meer informatie is te vinden in hoofdstuk 2.2.4 en in 4.2.11.


4.4.4

71


Het MVC-patroon zorgt hier (zie ook 2.2.5) opnieuw voor een simplificatie. Al de gebruikersinput wordt in het model geplaatst en dat model wordt uiteindelijk omgezet naar een .drl bestand. Het model zorgt ook voor het updaten van de grafische gebruikersinterface. Rulecreatie en toevoegen van conditie De creatie van een regel en het toevoegen van een conditie is te zien in figuur 4.22. Een aantal zaken worden hierop niet weergegeven. De changeEvents die verstuurd worden van RuleManager, RuleFileModel en Rule naar de GUI worden niet getoond. Dit vooral om de leesbaarheid te bevorderen. Deze changeEvents zorgen voor een hertekenen en hervullen van bepaalde stukken van de interface. model: RuleManager

user

ruleFileModel: RuleFileModel

condition: Condition

rule: Rule

1: create rule 2: getRuleFileModel() alt

2.1: ask package

getRuleFileModel() == null

2.2:: create

3: ask rule name De regel voegt zich toe aan zijn file bij creatie

4: setCurrentRule(new Rule()) Gebruiker selecteert optie voor conditie

5: new Rule(ruleFileModel, name, salience)

6: addRule(this) 5: select condition class 6: setCurrentCondtion(new Condition(...)) new Condition(currentRule, …) 7: condition input addCondition(this) 8: Add condition 9: currentCondition.addExpression() addExpression(expression)

Het toevoegen van een nieuwe expressie is vrij ingewikkeld. De gebruiker kan kiezen of hij toevoegt aan een vorige expressie, of aan een nieuwe, zie broncode

Figuur 4.22: Interne werking van regelcreatie-applicatie

IMPLEMENTATIE

72

Hoofdstuk 5

Implementatie In dit hoofdstuk worden een aantal implementatiekeuzes toegelicht. Eerst wordt kort toegelicht op welke wijze de implementatie is verlopen, in sectie 5.1. Vervolgens wordt besproken hoe de persistentielaag is uitgewerkt (5.2), alsook hoe deze persistentie beschikbaar wordt gesteld voor remote gebruik (5.3). Daarna wordt kort omschreven hoe de inlogprocedure werkt (5.4), hoe de takenapplicatie wordt weergegeven (5.5) en tot slot ook de regelcreatie-applicatie (5.6).

5.1

Implementatiewijze

Er werd besloten om een prototype als standalone applicatie te ontwikkelen, buiten OSGi. In dit prototype werd alle basisfunctionaliteit voorzien. Ook de rule engine werd ge¨ımplementeerd. Het testen van de backbone van de applicatie werd voornamelijk hier uitgevoerd. Daarvoor werden een aantal unit-tests geschreven om de functionaliteit van de DAO’s en de werking van de regelcreatie-applicatie en rule engine te testen.

Deze standalone applicatie werd dan geëxporteerd naar OSGi bundels. Dit was vooral in het begin een moeizaam proces. Sommige externe libraries zijn immers OSGi-incompatibel. Het exporteren van de packages naar OSGi was echter relatief eenvoudig, gezien de architectuur uitermate conform was aan de OSGi-werkwijze.

5.2

Persistentie

De persistentielaag werd ge¨ımplementeerd met JPA. Er werd gekozen voor EclipseLink JPA. Dit is een open source project van Eclipse Foundation, dat een uitbreidbaar framework voorziet

5.3 D-OSGi

73

dat Java ontwikkelaars toelaat om te interageren met databases via object-relationele mappings. EclipseLink werd gekozen omdat het gebruik binnen OSGi ondersteunt en het een ruime userbase heeft. Daarnaast biedt het uitgebreide features aan: ingebouwde support voor Oracle-database features, ondersteuning van de Java expressie-gebaseerde query taal en veel mogelijkheden om prestaties te tunen. [52]

De werkwijze hiervoor is eenvoudig. Het vereist de traditionele JPA annotaties binnen de persistentiepackage en het maken van een persistentie-eenheid. Deze wordt gedefiniëerd via een XML-bestand. Daarnaast zijn binnen OSGi een aantal bundels nodig. De volgende setup laat het runnen van de persistentielaag toe:

START LEVEL 5 ID State Level Name [ 0] [Active ] [ 0] System Bundle (2.0.1) [ 1] [Active ] [ 4] TaskDAOImpl (1.0.0.201004271249) [ 2] [Active ] [ 4] PatientDAOImpl (1.0.0.201004271249) [ 3] [Active ] [ 4] UserDAOImpl (1.0.0.201004271249) [ 4] [Active ] [ 3] EntityManagerCacheImpl (1.0.0.201004271249) [ 5] [Active ] [ 2] Distributed OSGi Distribution Software Single-Bundle Distribution (1.1) [ 6] [Installed ] [ 5] PersistenceTest (1.0.0.201004271249) [ 7] [Active ] [ 1] Apache Felix Shell Service (1.4.1) [ 8] [Active ] [ 1] Apache Felix Shell TUI (1.4.1) [ 9] [Active ] [ 1] TaskDAOService (1.0.0.201004271249) [ 10] [Active ] [ 1] Apache Felix Shell Service (1.4.2) [ 11] [Active ] [ 1] EclipseLink JPA (2.0.1.v20100213-r6600) [ 12] [Active ] [ 1] PatientDAOService (1.0.0.201004271249) [ 13] [Active ] [ 1] Persistence (1.0.0.201004271249) [ 14] [Active ] [ 1] EclipseLink ASM (2.0.1.v20100213-r6600) [ 15] [Active ] [ 1] UserDAOService (1.0.0.201004271249) [ 16] [Active ] [ 1] JAXP XML (1.3.4.v200902170245) [ 17] [Active ] [ 1] EclipseLink Core (2.0.1.v20100213-r6600) [ 18] [Active ] [ 1] EntityManagerCache (1.0.0.201004271249) [ 19] [Active ] [ 1] EclipseLink ANTLR (2.0.1.v20100213-r6600) [ 20] [Active ] [ 1] osgi.cmpn (4.2.0.200908310645) [ 21] [Active ] [ 1] Apache Derby Plug-in (10.1.2.1_v200803061811) [ 22] [Active ] [ 1] Java Persistence API 2.0 (2.0.0.v201002051058)

Figuur 5.1: Bundels in de persistentielaag

5.3

D-OSGi

Voor de implementatie om de services remote beschikbaar te stellen werd gekozen voor D-OSGi (3.4.3). Het duidelijke voordeel ten opzichte van het alternatief met behulp van web services, is dat er ook serverside kan gewerkt worden binnen OSGi. Dit maakt de implementatie uiter-

5.3 D-OSGi

74

mate geschikt om in te pluggen binnen andere OSGi omgevingen. D-OSGi werd gekozen boven het R-OSGi alternatief omdat het eenvoudig toelaat om de remote services aan te spreken via SOAP-berichten. Daardoor kan deze persistentielaag (4.2.3) ook aangesproken worden vanuit andere omgevingen en is het eenvoudig inplugbaar in om het even welke SOA-gebaseerd platform. De oplossing is volledig onafhankelijk van COSARA. Om de bundels remote beschikbaar te stellen, zijn er twee bundels nodig. De OSGi compendium bundel, alsook de Distributed OSGi Distribution Software Distribution bundel. Beide zijn te zien in figuur 5.1.

Bij het registreren van de remote services moet er wat code toegevoegd worden, zoals te zien in figuur 5.2. Properties props = new Properties(); props.put("DAOName", "TaskDAO"); props.put("osgi.remote.interfaces", "*"); props.put("service.exported.configs","org.apache.cxf.ws"); props.put("org.apache.cxf.ws.address", "http://localhost:9090/ taskDAO"); context.registerService( TaskDAO.class.getName(), new TaskDAOImpl(), props);

Figuur 5.2: Code voor het remote beschikbaar stellen

Aan client side moeten beide bundels ge¨ınstalleerd en gestart worden. De service kan dan aangesproken worden alsof deze zich lokaal bevindt. Een belangrijke opmerking hierbij is dat de interfaces van de remote services moeten gedupliceerd worden aan de clientside.

5.3.1

Event admin

Een ander belangrijk voordeel ten opzichte van de web services wordt geboden door de gedistribueerde event admin (reeds besproken in 3.5.3). Deze kan gebruikt worden om events te pushen en is dus een mogelijke implementatiewijze voor de light push voor takenophaling. Zo wordt de complexiteit en overhead van WS-Eventing (zie 3.5.2) omzeild en vervangen door de eenvoudig te gebruiken event admin. Hierdoor kan alle functionaliteit van het systeem binnen OSGi aangeboden worden, wat voordelen biedt voor implementatiegemak en onderhoud. Het laat tevens toe om gebruik te maken van de voorziene services binnen OSGi, die in de toekomst enkel verder uitgebouwd zullen worden.

De OSGi-omgeving moet een implementatie bevatten van de Event Admin service, Configu-

5.3 D-OSGi

75

ration Admin service en Declarative Services. In Felix OSGi zijn deze alledrie ondersteund. Wanneer alle bundels geactiveerd zijn, kan de event admin service gebruikt worden als een lokale service. Een event kan dan gepubliceerd worden op de volgende manier: eventAdmin = (EventAdmin) bctx.getService(reference); Dictionary<String, Object> props = new Hashtable<String, Object>(); props.put("message", "test"); Event ev = new Event("taskevent", props); eventAdmin.sendEvent(ev);

Figuur 5.3: Code voor het sturen van een event

Om dit mogelijk te maken zijn er een aantal bundels nodig: • EDS: event distribution system dat instaat voor de forwarding van de events naar een message broker in de vorm van berichten. • ActiveMQ Wrapper: zorgt voor het overbrengen van de messages. Ook de dependencies van deze bundel zijn noodzakelijk. Om de events op te vangen in bijvoorbeeld de client is een implementatie van de EventHandler interface nodig. Dit is te zien in figuur 5.4.

public void start(BundleContext context) throws Exception { Dictionary props = new Hashtable(); props.put(EventConstants.EVENT_TOPIC, "taskevent"); reg = context.registerService(EventHandler.class.getName(), new TaskEventReceiver(), props); } public class TaskEventReceiver implements EventHandler { public void handleEvent(Event event) { System.out.println("TaskEventReceiver: " + event.getProperty("message")); } }

Figuur 5.4: Code voor het opvangen van een event

De remote event admin is nog niet toegevoegd in de proof of concept. Het vereist echter een beperkte inspanning om het te implementeren. De grootste inspanning ligt bij het oplossen van afhankelijkheden tussen de bundels die toegevoegd moeten worden. Maar een (light) push

5.4 Inlogprocedure

76

implementatie is dus relatief eenvoudig toe te voegen. Een andere push variant kan bv. door de ID van de taak die gewijzigd is aan de eventmessage toe te voegen, waarna enkel deze taak zou kunnen opgehaald worden.

Het gebruik van D-OSGi zorgt dus voor een generieke oplossing die pushen pollmechanismen toelaat voor een takenapplicatie binnen om het even welke OSGi omgeving. De modulariteit van OSGi bevordert bovendien de aanpasbaarheid van het systeem.

5.4

Inlogprocedure

Voor de inlogprocedure werd zoals reeds gezegd een pipes-and-filter patroon en publish-subscribe patroon gebruikt (zie 4.2.5). Door deze keuzes is het systeem geschikt om om te gaan met willekeurige RFID hardware: de enige vereiste is het aanmaken van een implementatie van de bewuste service.

De architectuur ondersteunt het simultaan gebruik van meerdere readers en bijhorende filters. Er moet gewoon een implementatie van een reader en filter service voorzien worden. De bundels moeten ge¨ınstalleerd en gestart worden, waarna de RFIDManager en SessionManager opnieuw moeten gestart worden, waarna deze de nieuwe bundels opmerken en automatisch opnemen in de structuur (zie 4.2.5). Het is mogelijk om deze services dynamisch toe te voegen aan de RFIDManager en SessionManager wanneer ze gestart worden: dit is te zien in figuur 5.5.

public class ReaderTracker extends ServiceTracker {

public Object addingService(ServiceReference reference) { AbstractReader reader = (AbstractReader) context.getService(reference); rFIDManager.bind(reader); } }

Figuur 5.5: Code voor het dynamisch toevoegen van services

Op deze manier kan een service toegevoegd worden. Verwijderen gebeurt gelijkaardig. Dit is echter nog niet voorzien in de proof of concept. Wanneer er meerdere reader bundels gestart zijn en de LoginGUI wordt gestart, wordt voor elke reader een frame getoond waarin eventuele

5.5 Takenapplicatie

77

parameters kunnen ingevuld worden van de reader (poort, IP). Een alternatief is het tonen van een frame waarin de gebruiker kan selecteren welke reader van de lijst met ge¨ınstalleerde reader bundels, hij wil gebruiken. Dit is eveneens niet voorzien in de proof of concept, gezien dit weinig meerwaarde biedt voor het eindresultaat. Het gebruik van meerdere readers kan handig zijn indien er een overgangsperiode is om over te schakelen op een andere reader. Indien dit gebeurt voor readers voor niet-manuele inlezing moet er rekening gehouden worden met readercollisie (zie 3.1.5). Maar in dit scenario worden enkel manuele kaartreaders gebruikt, waardoor dit geen rol speelt.

Wanneer andere tagtypes moeten ondersteund worden, kan ofwel de extractID methode van de filter aangepast worden, ofwel moet een nieuwe TagType service bundel ge¨ımplementeerd worden en toegevoegd worden aan de filter. Deze service bevat een extractID methode, die voor zijn tagtype de ID extraheert. Een filter kan zo meerdere tagtypes ondersteunen: wanneer de ID moet geëxtraheerd worden, worden alle tagtypes geprobeerd tot er een match is. Het gebruik van tagtype services laat hergebruik toe binnen andere filters: een nieuwe filter zoekt gewoon de services van de tagtypes die ondersteund moeten worden.

Via het publish-subscribe patroon is de procedure eenvoudig herbruikbaar binnen andere omgevingen: het staat los van de rest van het systeem. Bij hergebruik moeten componenten zich gewoon registreren voor events bij de filter(s). Wanneer deze een wijziging voor de reader opvangt en een nieuwe ID leest, kan dit opgevangen worden door de ge¨ınteresseerde componenten.

5.5

Takenapplicatie

Een eerste implementatie is te zien in figuur 5.6.

Figuur 5.6: Eerste versie van de takenapplicatie

5.5 Takenapplicatie

78

Deze versie is niet bepaald gebruiksvriendelijk. Om de takenapplicatie overzichtelijk weer te geven werd gekozen voor een panel met tabs. Gebruiksvriendelijkheid was een belangrijk kwaliteitsattribuut voor het scenario, daarom is er ook veel aandacht besteed aan de manier waarop de taken gepresenteerd worden. Er kan bovendien gemakkelijk gezocht worden in de taken, alsook gefilterd worden op vervolledigde en niet-vervolledigde taken. Dit met behulp van filters op de TaskTable. De takenapplicatie in zijn huidige vorm is klaar om gebruikt te worden binnen de omgeving.

Figuur 5.7 biedt een overzicht van taken die toegewezen zijn aan de ingelogde persoon. De buttons in de toolbar laten toe om taken te filteren. Er bevindt zich ook een ’View’ button. Via deze button kan een taak met al zijn informatie bekeken worden. Via de checkboxes kan een taak gestart worden, alsook afgerond worden. Hiervoor moet op de ’In Progress’ checkbox geklikt worden bij ’My Tasks’. Het takencreatie panel laat toe om taken toe te wijzen van alle soorten. Zowel algemene taken, patiëntspecifieke taken als rolgebaseerde taken kunnen eenvoudig toegewezen worden. Dit is te zien in figuur 5.8.

Figuur 5.7: Overzicht van taken

5.6 Regelcreatie-applicatie

79

Figuur 5.8: Panel voor het maken van taken

5.6


Het belangrijkste kwaliteitsattribuut van deze subapplicatie is ongetwijfeld gebruiksvriendelijkheid. Dit is reeds besproken in 2.1.2. De gui moet eenvoudig bruikbaar zijn en het moet duidelijk zijn wat de regel precies zal doen bij evaluatie. De conditie moet eenvoudig kunnen gemaakt worden en de meest courante regels moeten ondersteund worden. Zoals besproken in 4.2.7, laat het model de creatie toe van bijna alle mogelijke regels. De gui moet in staat zijn om dit model gemakkelijk te gebruiken.

Een aantal alternatieven werden uitgewerkt: een drag-and-drop interface, waar conditie-onderdelen op de gui moesten gesleept worden, bleek na navraag bij testgebruikers onvoldoende gebruiksvriendelijk en te omslachtig. Daarna werd overgestapt naar een systeem met comboboxen. Een combobox toont de mogelijke klassen voor een conditie, alsook objecten van reeds bestaande condities. Dit laat dus zowel de creatie van nieuwe condities toe, als het toevoegen van voorwaarden aan een reeds bestaande conditie. Daarnaast kan ook een type consequentie gekozen worden, op gelijkaardige manier. Mogelijke waarden voor een zeker veld kunnen gekozen worden in de combobox voor de waarde voor een zeker veld. Wanneer bijvoorbeeld een conditie is aangemaakt voor een zekere patient (genaamd patient1), zal bij een conditie voor een taak voor


80

het veld patient, deze patient1 kunnen geselecteerd worden als waarde. Dit is zeer eenvoudig in gebruik en verbergt de complexiteit van de onderliggende regels.

In volgende figuur 5.9 is te zien hoe een consequentie wordt gemaakt voor een zeker conditieobject, namelijk task1. Dit wil zeggen dat de prioriteit van alle taken in het werkgeheugen, die voldoen aan de condities van task1, zal gewijzigd worden naar LOW. Daarnaast wordt er ook aan een conditie gewerkt voor een taak, met een specifieke titel en status. In de middenste combobox kan een operator gekozen worden, terwijl de achterste combobox vervangen werd door een tekstveld.

Figuur 5.9: Design van rules

De gebruiker kan deze regel opslaan. Op elk moment kan de structuur van het huidige regel-


81

bestand nagekeken worden in de tree. Nadat een regel is opgeslaan en er geen andere wordt bewerkt, kunnen in deze tree regel, condities en consequenties verwijderd worden. Regels kunnen ook steeds hier geselecteerd en bewerkt worden, om bijvoorbeeld nieuwe condities toe te voegen. De boomstructuur van een regel is te zien in 5.10.

Figuur 5.10: Boomstructuur van rulefile

Deze regelapplicatie is te gebruiken voor om het even welk soort regels en is dus niet gebonden aan de huidige applicatie en de huidige klassen. Het onderliggende model (zie 4.2.7) vormt een generiek model voor regelcreatie voor om het even welke applicatie en is dus perfect herbruikbaar. Bovendien kan het onderliggende model uitgebreid worden voor ondersteuning van andere rule engines en rules geschreven in een ander dialect. Momenteel zijn de ingeladen klassen Task,


82

Patient en User, maar deze kunnen gewijzigd worden naar om het even welke klasse, zodanig dat regels kunnen gemaakt worden met deze als klassen voor de conditieobjecten. Het vereist enkel het opnemen van de klasse in het systeem en deze te introduceren binnen de regelcreatieapplicatie. De AlterConsequence laat aanpassing van willekeurige velden toe voor deze nieuwe objecten.

Gezien het belang van de gebruiksvriendelijkheid en het feit dat de regelcreatie-applicatie gericht is op mensen zonder achtergrond met betrekking tot regelgebaseerde systemen, is dit echter niet te zien in de grafische gebruikersinterface: deze is zo eenvoudig en verstaanbaar mogelijk gehouden.

EVALUATIE

83

Hoofdstuk 6

Evaluatie De tests werden uitgevoerd op een notebook uitgerust met een AMD Athlon X2 Dual-Core (2.10 GHz) en 4,00 GB geheugen. Het is de bedoeling om de schaalbaarheid van de proof of concept te testen en na te gaan hoe het systeem zich gedraagt bij een toenemende belasting, zowel in de vorm van een verhoging van het aantal clients, het aantal taken en het aantal te evalueren regels. Het ophalen van taken zal daarom getest worden met toenemend aantal clients en met toenemende hoeveelheid en met een toenemende frequentie. In de proof of concept implementatie draait het regelsysteem van het systeem buiten OSGi, als een aparte Java-applicatie die inwerkt op de database. De database is een Derby Network Server, die lokaal gedraaid wordt. De regelevaluatie zal getest worden door het aantal facts (het aantal taken in het testscenario) te verhogen, en het aantal rules te verhogen. Daarnaast zal er gewerkt worden met verschillende rulesets.

Op basis van de resultaten kunnen toekomstige verbeteringen voorgesteld worden. Er zijn natuurlijk reeds een aantal mogelijkheden gesuggereerd, zoals een light push of full push via de gedistribueerde event admin (zie 5.3.1). Maar in deze proof of concept is dit nog niet ge¨ımplementeerd. Het regelsysteem binnen OSGi brengen zou ook een vooruitgang zijn. In de proof of concept worden echter periodiek gegevens ingeladen en worden de regels geëvalueerd.

6.1

Prestatie

De persistentielaag draait binnen een Felix Container en wordt remote beschikbaar gesteld met behulp van D-OSGi (zie 5.3). Daardoor is deze beschikbaar via een wsdl-contract. De tests van

6.1 Prestatie

84

de persistentielaag gebeuren dus via SOAP en meer bepaald via soapUI. [53] De regelevaluatie wordt gemeten binnen Eclipse, via eenvoudige tijdsmetingen. De facts worden steeds opnieuw ingeladen voor deze regelevaluatie en worden random ingevuld.

Elke gemiddelde waarde die als resultaat wordt aangegeven, is gebaseerd op zestig testwaarden.

6.1.1

Rule engine

De rule engine kan op een server draaien, los van de persistentielaag. Het eigenlijke streefdoel is om hier uiteindelijk een lopende sessie voor te maken, zodat regelevaluatie sneller kan verlopen. Het momenteel ge¨ımplementeerde alternatief, evalueert echter periodiek de regels op alle informatie die zich op dat moment in de databank bevindt: alles wordt opnieuw ingeladen in het werkgeheugen, waarna de condities worden geëvalueerd, prioriteiten eventueel gewijzigd, of nieuwe taken aangemaakt. Het voordeel is de simpliciteit van deze aanpak en gezien het los op de databank inwerkt is het onafhankelijk van het aantal clients.

Om de rules te testen wordt gewerkt met verschillende rulesets, te vinden in bijlage A. Er is een complexe ruleset met datevergelijkingen, die een combinatie omvat van twee expressies, beide bestaande uit twee condities. Dan is er een gemiddeld complexe ruleset, die twee condities omvat en tot slot een eenvoudige ruleset, die slechts een enkele conditie controleert. De uitvoeringstijden omvatten geen opbouw van de kennisbank, gezien dit bij uitvoering in de applicatie enkel en alleen gebeurt wanneer er een nieuw regelbestand wordt voorzien. Wat de uitvoeringstijden wel omvatten, is het maken van de connectie met de databank, het ophalen van de taken uit de databank en het eventueel afhandelen van de transactie.

De bedoeling is om de prestatie in de vorm van uitvoeringstijd na te gaan in functie van de rulesets, het aantal rules binnen de ruleset, alsook de prestatie in functie van het aantal facts die uit de databank opgehaald worden en worden ingeladen in het werkgeheugen. Uitvoeringstijd in functie van rulesets en aantal rules Voor elk type ruleset wordt de uitvoeringstijd gemeten, uitgemiddeld over dertig metingen en dit voor een hoeveelheid rules van 50, 100, 200, 500 en 1000 binnen de respectievelijke rulesets.

6.1 Prestatie

85

Het resultaat is te vinden in grafiek 6.1. In de grafiek wordt de complexe, gemiddeld complexe en eenvoudige ruleset uitgezet in respectievelijk 1, 2 en 3. De uitvoeringstijden zijn uitgezet in milliseconden.

Uitvoeringstijd in functie van rulesets en aantal rules 18000 16000

Uitvoeringstijd (ms)

14000 12000 10000 8000 6000 4000 2000 0

1

2

3

1000

16351

13919

2702

500

7823

6468

1328

200

2673

2434

614

100

1464

1320

418

50

881

821

363

Figuur 6.1: Uitvoeringstijd in functie van rulesets en aantal rules

Voor deze uitzetting werd gekozen voor een hoeveelheid van duizend facts. Dit wil zeggen dat er zich in de databank duizend taken bevinden. Het is te zien dat de evaluatie voor duizend rules bij deze hoeveelheid facts tussen de drie en zestien seconden in beslag neemt, afhankelijk van de ruleset. In de realiteit zal de tijd hier ergens tussen liggen (gezien de heterogene complexiteit van de rules). Een regelbestand van duizend rules is echter vrij onrealistisch voor deze applicatie. Honderd tot tweehonderd regels lijkt een normale hoeveelheid. Het is te zien dat de maximale tijd dan op anderhalve seconde ligt.

Een periodieke evaluatie per minuut, vooropgesteld als minimale doelstelling, is in beide gevallen haalbaar. Indien de uitvoering toch te traag zou zijn bestaat er de mogelijkheid om de regelevaluatie uit te spreiden over meerdere rule engine instanties (via gedistribueerde rule engines), zo zou de serverload kunnen verspreid worden en de snelheid waarmee regels geëvalueerd worden zou vergroten.

6.1 Prestatie

86

Uitvoeringstijd in functie van aantal rules Uit grafiek 6.1 is te zien hoe de uitvoeringstijd zich gedraagt ten opzichte van het aantal rules. De uitvoeringstijd in functie van het aantal rules werd uitgezet binnen de ruleset met gemiddelde complexiteit en de simpele ruleset. Dit is te zien in 6.2.


Uitvoeringstijd in functie van aantal rules 16000 14000 12000 10000 8000 6000 4000 2000 0

Simpele ruleset Medium ruleset

0

200

400

600

800

1000

1200

Aantal rules

Figuur 6.2: Uitvoeringstijd in functie van aantal rules

De stijging is min of meer lineair, het aantal regels kan dus eenvoudig toenemen tot duizend, zonder buitensporige uitvoeringstijden te bereiken. Uitvoeringstijd in functie van rulesets en aantal facts De facts die gebruikt worden voor de regelevaluatie zijn de taken, de patiënten en de gebruikers. Voor het testen worden er enkel taken gebruikt. Deze objecten zijn het meest complex en vormen dus een goede basis voor de tests. De uitvoeringstijd in functie van het aantal facts, en voor de verschillende types van rulesets, is uitgezet in onderstaande grafieken, voor duizend (figuur 6.3), tweehonderd (figuur 6.4) en honderd rules (figuur 6.5). Deze waarden voor het aantal rules tonen zowel het randgedrag als het gemiddelde verwachte gedrag, nl. een aantal rules tussen honderd en tweehonderd. De testen werden opnieuw uitgevoerd voor de drie rulesets: de complexe, middelmatig complexe en simpele ruleset.

6.1 Prestatie

87

Uitvoeringstijd in functie van aantal facts voor 1000 rules 140000


120000 100000 80000 60000 40000 20000 0

100

200

500

1000

1500

2000

5000

Simpel

331

641

1445

3012

4554

5769

15579

Medium

1550

3047

7397

15781

21556

28857

78488

Complex

1902

3853

10292

20567

28236

38011

115940

Figuur 6.3: Uitvoeringstijd voor 1000 rules

Op bovenstaande figuur is te zien dat het ongeveer 115 seconden zou duren om duizend regels te evalueren op vijfduizend facts. Maar duizend regels is een onrealistische hoeveelheid. De uitvoeringstijd neemt lineair toe in functie van het aantal facts. Alleen vanaf vijfduizend facts begint de stijging groter te worden, dat is zeer duidelijk te zien voor de complexe ruleset.



16000 14000 12000 10000 8000 6000 4000 2000 0

100

200

Simpel

500

1000

1500

2000

111

181

Medium

326

578

Complex

353

659

1493

359

614

1048

1320

2717

1349

2434

3996

5406

15721

2673

4102

5893

16312


5000

6.1 Prestatie

88

Voor tweehonderd rules is de maximale uitvoeringstijd 16 seconden voor vijfduizend facts. Dit is een aanvaardbare tijd voor dit randgeval. Als de gemiddelde hoeveelheid taken rond de tweeduizend ligt, kunnen alle regels binnen zes seconden geëvalueerd worden. De testregels voeren bovendien bijna altijd een externe procedure uit (prioriteitsverandering), dus in realiteit zal deze tijd lager liggen. Het is ook opvallend dat de tijden dichter bij elkaar liggen: hoe groter het aantal rules hoe groter het verschil tussen de uitvoeringstijden van de rulesets.



8000 7000

6000 5000 4000 3000 2000

1000 0

100

200

500

1000

1500

2000

5000

Simpel

78

132

266

418

686

941

2669

Medium

186

348

789

1320

2009

2776

8018

Complex

198

382

819

1464

2124

2910

8391


Bij honderd rules, kunnen vijfduizend facts opgehaald worden uit de databank en geëvalueerd worden in een tijd lager dan tien seconden. Bovenstaande grafieken tonen aan dat de regelevaluatie in termen van het aantal facts aanvaardbare tijden haalt, ook al worden nu alle facts steeds opnieuw ingeladen vanuit de databank. Een verbetering in uitvoeringstijd kan gerealiseerd worden door met een lopende sessie te werken, alsook aan load balancing te doen voor de evaluatie over meerdere servers. Uitvoeringstijd in functie van aantal facts Het lineaire verband tussen het aantal facts en de uitvoeringstijd wordt duidelijker ge¨ıllustreerd in figuur 6.6. Dit is de uitvoeringstijd voor de simpele ruleset, bestaande uit tweehonderd rules. Er zijn wel kleine afwijkingen, maar een lineair verband is zeker merkbaar.

6.1 Prestatie

89

Uitvoeringstijd in functie van aantal facts

9000 8000

2500



3000

2000 1500 1000

7000 6000 5000

Simpele ruleset

500 0

4000 3000 2000 1000

0

1000

2000

3000

4000

5000

6000

Aantal facts

Simpel Medium

Figuur 6.6: Uitvoeringstijd in functie van aantal facts

6.1.2

Persistentielaag

Via soapUI wordt nagegaan waar de limieten liggen voor een poll-gebaseerd systeem. Daarom wordt het aantal taken opgedreven, alsook het aantal clients en de frequentie van de opvragingen. Uitvoeringstijd van takenophaling in functie van aantal clients en poll-frequentie In eerste instantie is het de bedoeling om na te gaan waar de limieten van het systeem liggen. Daarom worden honderd taken opgevraagd (opgesplitst in twee dao oproepen), door steeds meer parallelle clients. De gebruikte strategie hiervoor is de soapUI Simple strategie: ingesteld met een delay van een seconde en een random factor van 0,5. Dit betekent dat de uitvoering van elke thread (client simulatie) pauzeert gedurende vijfhonderd tot duizend ms, alvorens de testcase opnieuw uit te voeren. Dit is een (onrealistisch) hoge frequentie. Daarnaast werden de testcases uitgevoerd met een delay van tien seconden, met een random van 0,5. Dit is een relatief realistische frequentie. Dit werd herhaaldelijk uitgevoerd gedurende een uur. De gemiddelde uitvoeringstijden voor de testcase zijn te vinden in figuur 6.7.

De waarden bij een delay van een seconde zijn bijzonder hoog vanaf vijfhonderd clients. Dit is

6.1 Prestatie

90

Gemiddelde uitvoeringstijd in functie van aantal clients en delay 80000


70000

60000 50000 40000

30000 20000 10000 0

1

5

10

20

50

100

200

500

1000

10s

100

100

101

101

101

133

5433

24292

62154

1s

100

100

116

280

2061

4985

10832

33142

73454

Figuur 6.7: Uitvoeringstijd in functie van aantal clients en poll-frequentie

verwacht; het is een stresstest voor het systeem. In een realistische situatie is een poll elke seconde nutteloos en het aantal clients binnen het systeem kan nooit oplopen tot deze exorbitante hoeveelheden: er bevinden zich momenteel maximaal honderd bedside computers in de dienst. Wanneer het aantal clients honderd bedraagt, is de gemiddelde tijd ongeveer vijf seconden. Dit is nog net aanvaardbaar, zelfs onder deze extreme frequentie van pollen.

Als de delay stijgt naar tien seconden, is de gemiddelde uitvoeringstijd 133 ms. Dit is zeer aanvaardbaar. Het is opvallend dat het pas bij tweehonderd clients snel begint te stijgen. Bij een kleiner aantal clients, kunnen alle requests vlot afgehandeld worden, maar eens een zekere grens bereikt wordt, stapelt de vertraging zich op, resulterend in een hogere uitvoeringstijd. Op een krachtige server zullen natuurlijk wel meer requests afgehandeld kunnen worden zonder dat er vertraging optreedt. Uitvoeringstijd van inlogscenario in functie van frequentie en aantal taken Maar het ophalen van honderd taken is slechts een deel van wat er gebeurt wanneer een gebruiker inlogt. Er is een databanktoegang voor het inloggen, alsook het ophalen van algemene taken, het ophalen van rolspecifieke taken en het ophalen van patiëntinformatie en gebruikersinformatie. De poll frequentie die kan gekozen worden, hangt hiervan af. Daarom werd een testcase ontwikkeld

6.1 Prestatie

91

die een gebruiker inlogt. Daarna worden alle taken opgehaald: rolspecifieke taken, algemene taken, specifieke taken en taken toegewezen door de gebruiker. Er worden in totaal opnieuw 100 taken afgehaald, daarna ook 200 en 500. Patiëntinformatie van twintig patiënten wordt opgehaald, alsook de gebruikersinformatie. Het aantal clients wordt ingesteld op honderd. Er worden verschillende delays geprobeerd (60s,45s,30s), steeds met een random van 0,5. Het was vooropgesteld dat de takenapplicatie kon ingeladen worden in een tijd lager dan een seconde: indien honderd clients met een zekere frequentie steeds kunnen inloggen en taken ophalen in minder dan een seconde (gemiddeld), zal ook de periodieke takenophaling uitgevoerd kunnen worden in minder dan een seconde.

Gemiddelde uitvoeringstijd in functie van aantal taken en delay 18000 16000 Uitvoeringstijd (ms)

14000 12000 10000 8000 6000 4000 2000 0

60s

45s

30s

590

955

2412

200 tasks

732

1523

6022

500 tasks

1121

5820

16521

100 tasks

Figuur 6.8: Uitvoeringstijd in functie van aantal taken en poll-frequentie

Uit deze figuur blijkt dat voor 100 en 200 taken, het systeem in staat is om met een delay van 60s (dus door de random tussen de 30 en de 60s) een gemiddelde uitvoeringstijd te halen die onder een seconde ligt. Voor vijfhonderd taken is de gemiddelde tijd 121 ms te hoog, maar nog steeds aanvaardbaar. Wanneer dus als periode voor takenophaling een minuut wordt gekozen, zal de takenapplicatie gemiddeld minder dan een seconde nodig hebben om de data in te laden vanuit de persistentielaag. Bovendien is het aantal actieve clients in deze testcase bijzonder groot. In de realiteit zal dit een kleiner aantal zijn.

6.2 Functioneel

6.2

92

Functioneel

De prestatietests gaan na in hoeverre het systeem voldoet aan de niet-functionele vereisten (zie 2.1.2). De functionele tests gaan na in welke mate het systeem voldoet aan de vooropgestelde functionele vereisten (zie 2.1.1). In de eindfase van de implementatie is het mogelijk om via interacties met de gebruikersinterface na te gaan of de gewenste functionaliteit voorzien is. De werking van de persistentielaag kan getest worden via soapUI. Daarom zal nu voor elk scenario, eerder uitgezet in sectie 2.2, worden nagegaan of de gewenste functionaliteit voorhanden is.

6.2.1

Inlogprocedure

Via Rifidi kan een Alien Reader geëmuleerd worden, alsook een aantal tags. Deze tags kunnen in de databank worden geplaatst via newUser() van UserDAO. Wanneer alle bundels geactiveerd zijn, kan de nieuwe gebruiker ingelogd worden door de reader te starten en de tag voor de reader te houden. Na het inloggen kan de gebruiker uitloggen, waarna de reader het lezen opnieuw hervat. Deze functionaliteit is volledig voor handen. Via soapUI kan de UserDAO functionaliteit voor een login getest worden door een SOAP request te sturen naar de remote service. Request <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:user="http://user.service.dao.persistence/"> <soapenv:Header/> <soapenv:Body> <user:getUser> <user:arg0>353A 4516 3D9D F249 222C E663

Response <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <ns1:getUserResponse xmlns:ns1="http://user.service.dao.persistence/"> <ns1:return> <ns2:id xmlns:ns2="http://util.core.persistence">1 <ns2:isAdmin xmlns:ns2="http://util.core.persistence">false <ns2:name xmlns:ns2="http://util.core.persistence">Wouter Van Isterdael <ns2:rfidid xmlns:ns2="http://util.core.persistence">353A 4516 3D9D F249 222C E663 <ns2:staffRole xmlns:ns2="http://util.core.persistence">DOCTOR

Figuur 6.9: SOAP request voor login

6.2 Functioneel

6.2.2

93


Dit scenario kan volledig bestudeerd worden via de gebruikersinterface. Via eenvoudige unittests voor de persistentielaag kan de onderliggende werking gecontroleerd worden. Het overige gedeelte zijn kleine business-logic bewerkingen, die getest kunnen worden via de gui. De prestatietests tonen ook al aan dat er taken kunnen toegevoegd worden en opgevraagd, alsook dat de prioriteiten kunnen gewijzigd worden. Via soapUI kan de TaskDAO bevraagd worden.

6.2.3


Via de regelcreatie-applicatie kan een eenvoudige regel gemaakt worden voor prioriteitwijziging. Als testscenario wordt daarom een regel gemaakt die alle taken met medium prioriteit wijzigt naar taken met hoge prioriteit. Dit is natuurlijk een vrij simpel voorbeeld, maar het is voldoende om aan te tonen dat de basisfunctionaliteit van dit applicatiegedeelte ge¨ımplementeerd is. Via de gebruikersinterface wordt deze regel gemaakt, waarna die ge¨ıntroduceerd wordt binnen de takenapplicatie, die dus de werking van het resultaat van dit scenario zal bewijzen. package business.taskapp import persistence.core.entities.Task; import persistence.core.util.Priority; rule "Priority test" when $task : Task (priority == Priority.MEDIUM) then modify ( $task ){ setPriority(Priority.HIGH) } end

Figuur 6.10: Source van rule gemaakt met de editor

6.2.4

Takenapplicatie met automatische prioriteitsassignatie

Om dit te testen, wordt de regel gemaakt in 6.2.3 in het regelbestand geplaatst. Daarna wordt de periodieke evaluatie gestart. Als resultaat kan vastgesteld worden dat alle taken die een medium prioriteit hadden, nu een hoge prioriteit hebben. Daarmee is ook de basisfunctionaliteit van dit scenario aanwezig.

CONCLUSIE

94

Hoofdstuk 7

Conclusie 7.1

Besluit

Het systeem voorgesteld in deze masterproef toont op welke manier een inlogprocedure en een takenapplicatie kan ge¨ıntegreerd worden binnen een willekeurige OSGi omgeving. Daarnaast ging er ook aandacht naar het koppelen van een regelgebaseerde component aan deze takenapplicatie. Door de generieke aard van de oplossing, is dit systeem eenvoudig in te pluggen binnen de COSARA clients en de omgeving binnen de dienst Intensieve Zorgen van het UZ, maar is het gebruik tevens niet beperkt tot deze omgeving.

Er werd onderzoek gedaan naar RFID systemen, XACML, regelgebaseerde systemen, OSGi en verscheidene mechanismen voor takenophaling. Daarna werden deze aangewend om een oplossing te bieden voor het gestelde probleem. De voornaamste uitdaging was de integratie binnen een bestaande OSGi omgeving. De gekozen oplossingswijze voor het eerste probleem is gebaseerd op het gebruik van een RFID-gebaseerde inlogprocedure. Voor de takenapplicatie werd geopteerd voor een gedistribueerde takenapplicatie, die gebruik maakt van een regelgebaseerde component om de prioriteit van taken automatisch te wijzigen en nieuwe taken toe te kennen. Daarnaast werd een regelcreatie-applicatie gemaakt met een hoge gebruiksvriendelijkheid, die medisch personeel in staat stelt om eenvoudig nieuwe rules aan te maken. Het onderliggende model voor deze regelcreatie-applicatie is generiek en laat regelcreatie toe voor om het even welke klassenstructuur.

Om deze oplossingswijze in de praktijk te brengen, werd een client-server architectuur ontwor-

7.1 Besluit

95

pen. Aan de clientside werd de inlogprocedure voorzien. Het systeem creëert een abstractielaag ten opzichte van de onderliggende hardware, waardoor meerdere soorten readers en tags tegelijk kunnen gebruikt worden. Dit systeem is eenvoudig uitbreidbaar, aanpasbaar en kan met aanzienlijk gemak hergebruikt worden binnen andere omgevingen. Daardoor is het niet enkel bruikbaar voor inlogprocedures, maar ook voor andere RFID-gebaseerde procedures. De takenapplicatie is gerealiseerd met behulp van D-OSGi. Deze stelt de persistentie-services (nodig voor de databank toegang) remote beschikbaar vanuit een OSGi framework op de server. Zowel OSGi bundels in andere frameworks als niet-OSGi omgevingen kunnen interageren met deze bundels, waardoor de backbone van de takenapplicatie in de toekomst kan gebruikt worden binnen om het even welke SOA-gebaseerde omgeving. Enkel de concrete invulling van de taken moet hiervoor gewijzigd worden.

De testresultaten tonen aan dat de huidige implementatie voldoet aan de gestelde niet-functionele vereisten. Gezien het grote belang van gebruiksvriendelijkheid voor de takenapplicatie en de regelcreatie-applicatie is er ook inspanning gedaan om de grafische gebruikersinterfaces goed uit te werken.

Het systeem en de onderliggende architectuur introduceren het gebruik van gedistribueerde OSGi binnen een bestaande OSGi omgeving, dit is dan ook een belangrijk resultaat van deze masterproef. Daarnaast voorziet de RFID inlogprocedure in een uitbreidbare en state-of-the-art oplossing voor het authenticatieprobleem, die eenvoudig te hergebruiken is in andere servicegeoriënteerde platforms. De takenapplicatie werd gekoppeld aan een regelgebaseerde component, waardoor at runtime nieuwe business logic aan het systeem kan toegevoegd worden. Via de regelcreatie-applicatie kunnen de rules hiervoor op een intu¨ıtieve manier aangemaakt worden.

Het totaalpakket biedt dus een generieke en uitbreidbare oplossing, die eenvoudig kan ge¨ıntegreerd worden binnen het bestaande COSARA platform, maar niet beperkt is tot gebruik binnen dit platform. De proof of concept implementatie is bijna klaar voor gebruik en mits de nodige aanpassingen (zie 7.2), kan deze zeker overwogen worden als uitbreiding voor het COSARA platform.

7.2 Verdere ontwikkelingen

7.2

96

Verdere ontwikkelingen

Er is nog voldoende werk en onderzoek vereist om deze proof of concept verder uit te werken tot een volwaardige, complete oplossing om effectief te gaan gebruiken in de praktijk.

De inlogprocedure is momenteel enkel ge¨ımplementeerd voor een standaard reader en voor een default tag type. Ondersteuning voor andere types readers en tags is nog niet voorzien. De architectuur laat dit wel eenvoudig toe. Bovendien moeten er nog aandacht gaan naar het dynamisch toevoegen van services. Dit is echter zeer beperkt qua complexiteit en is eenvoudig toe te voegen.

De gedistribueerde takenapplicatie maakt momenteel enkel en alleen gebruik van een pollmechanisme. De taken worden periodiek opgehaald. Dit kan vervangen worden door een pushmechanisme, maar dat zal wel een hogere complexiteit introduceren binnen het systeem. Door de keuze voor gedistribueerde OSGi is de implementatie hiervan echter geen grote inspanning. De gedistribueerde event admin biedt een goede oplossing (zie 5.3.1). Deze werd ook reeds onderzocht en uitgetest, maar is nog niet ge¨ıntegreerd binnen de proof of concept. Een goede uitwerking zou zijn om serverside events te gaan distribueren naar ingelogde gebruikers. Deze events kunnen bijvoorbeeld de ID’s bevatten van gewijzigde taken, of gewoon de taak-objecten. De regelgebaseerde component kan hieraan gekoppeld worden, zodanig dat deze met een lopende sessie kan werken. Momenteel werkt deze gewoon in op de informatie uit de databank, die periodiek wordt ingeladen. De lopende sessie zou echter tot betere prestaties leiden. De gekozen architectuur maakt het ook mogelijk om bv. webapplicaties te implementeren die dezelfde functionaliteit aanbieden als de takenapplicatie. Zo kunnen gebruikers ook buiten de COSARA clients hun taken bekijken. In de proof of concept is dit echter nog niet voorzien.

De regelcreatie-applicatie is momenteel enkel gericht op Drools rules. Door de huidige klassen uit te breiden en een methode te overschrijven kan dit wel eenvoudig uitgebreid worden voor rules met een andere syntax. Het onderliggende model ondersteunt ook nog niet alle mogelijke rulevormen. Om ook gecompliceerde rules te vormen, zal dit verder moeten uitgebreid worden.

Ten slotte is het belangrijk om onsite EMI-tests uit te voeren alvorens de RFID systemen te introduceren binnen de dienst Intensieve Zorgen en moet er bekeken worden hoe de RFIDgebaseerde inlogprocedure kan beveiligd worden.

RULES VOOR PRESTATIETESTS

97

Bijlage A

Rules voor prestatietests In figuur A.1 wordt de vorm van de regels ge¨ıllustreerd die gebruikt werden voor de prestatietests. Simpele rule rule "High priority" when $task : Task (priority == Priority.HIGH) then $task.setPriority(Priority.MEDIUM); end

Gemiddeld complexe rule rule "High or low priority" when $task : Task (priority == Priority.HIGH || priority == Priority.LOW) then $task.setPriority(Priority.MEDIUM); end

Complexe rule rule "Deadline overdue" when $currentDate : Date ( ) $task : Task ((deadline < $currentDate && priority == Priority.MEDIUM) || (deadline < $currentDate && priority == Priority.LOW)) then $task.setPriority(Priority.HIGH); end

Figuur A.1: De rules gebruikt in de prestatietests

BIBLIOGRAFIE

98

Bibliografie [1] Technovelgy, Advantages of RFID Versus Barcodes, http://www.technovelgy.com/ct/ Technology-Article.asp?ArtNum=60. [2] RFID Journal,

RFID journal : glossary of terms,

http://www.rfidjournal.com/

glossary/. [3] Technovelgy, What is RFID?, http://www.technovelgy.com/ct/Technology-Article. asp?ArtNum=1. [4] Roy Want, “RFID Explained: A Primer on Radio Frequency Identification Technologies”, United States of America, 2006. [5] Supply Insight Inc., RFID Applications in Hospital Equipment Tracking, http://www. supplyinsight.com/RFID_in_Hospital_Equipment_Tracking.htm. [6] ActiveWave RFID Systems,

Equipment Tracking in Hospitals,

http://www.

activewaveinc.com/applications_hospitals.php. [7] RFID Gazette, UHF Vs. HF tags, http://www.rfidgazette.org/2005/09/uhf_vs_hf_ tags.html. [8] RFID-Handbook,

Types of RFID,

http://rfid-handbook.de/rfid/types_of_rfid.

html. [9] Sanjay E. Sarma, Stephen A. Weis, Daniel W. Engels, “RFID Systems and Security and Privacy Implications”, 2003. [10] Savi Technology, “Active and Passive RFID: Two Distinct, But Complementary, Technologies for Real-Time Supply Chain Visibility”, 2002.

BIBLIOGRAFIE

99

[11] Techstore,

Two main Types of RFID Tags,

http://www.techstore.ie/Tracking/

articles/Types-of-RFID-Tags.htm. [12] Technovelgy,

Active Tag (Active RFID Tag),

http://www.technovelgy.com/ct/

Technology-Article.asp?ArtNum=21. [13] Technovelgy, Passive RFID Tag (or Passive Tag), http://www.technovelgy.com/ct/ Technology-Article.asp?ArtNum=47. [14] Belgisch Instituut voor Postdiensten en Telecommunicatie, Frequentieplan, http://www. bipt.be/nl/217/ShowContent/1057/Tabel/Plan.aspx. [15] UZ Gent - Universitair Ziekenhuis Gent - ICU - Intensieve Zorg - Intensive Care Unit , Medische staf, http://www.icu.be/arts/medstaf.asp. [16] RFID Shop, RFID Equipment - RFID Tags, Readers, Antennas, Software, http://www. therfidshop.com/. [17] GAO RFID INC., RFID Readers - 125 kHz and 13.56 MHz, http://www.gaorfid.com/. [18] Hughes Identification Devices, http://www.hidglobal.com/. [19] Hughes Identification Devices, Health Care, http://www.hidglobal.com/applications. php?app_id=3. [20] Hughes Identification Devices,

iClass Contactless,

http://www.hidglobal.com/

technology.php?tech_cat=2. [21] Maco

Pharma,

RFID

manufacturer,

Experience

of

a

blood

bag

http://www.docstoc.com/docs/3607509/

RFID-Experience-of-a-blood-bag-manufacturer-Bracknell-March-RFID. [22] The Journal of the American Medical Association, “Radiofrequency Identification Technology in Health Care”, Vol. 298 No. 19, November 21, 2007. [23] Technovelgy,

Problems

With

RFID,

http://www.technovelgy.com/ct/

Technology-Article.asp?ArtNum=20. [24] Koong Lin, Tzu-Chang Yeh, Yao-Yuan Liu, Chad Lin, “Low-Cost RFID Identification Variation”, Australia.

BIBLIOGRAFIE

100

[25] Jin-Oh Jeon, Su-Bong Ryu, Sang-Jo Park, Min-Sup Kang, “Strong Authentication Protocol for RFID Tag Using SHA-1 Hash Algorithm ”, Korea, 2007. [26] The Journal of the American Medical Association, “Electromagnetic Interference From Radio Frequency Identification Inducing Potentially Hazardous Incidents in Critical Care Medical Equipment”, Vol. 299 No. 24, June 25, 2008. [27] International Organization for Standardization, ISO 18000, ISO 14443, http://www.iso. org/. [28] RFID Journal, A Summary of RFID Standards, http://www.rfidjournal.com/article/ view/1335/2. [29] RFID Update, ISO Incorporates Gen2 into RFID Standard, http://www.rfidupdate. com/articles/index.php?id=1156. [30] Java-RFID, http://www.smartlab.deusto.es/java-rfid/. [31] Rifidi, http://www.rifidi.org/. [32] logicAlloy, http://www.logicalloy.com/. [33] Sybase, http://www.sybase.com/products/rfidsoftware/rfidanywhere. [34] Sun, Developing Auto-ID Solutions using Sun Java System RFID Software, http://java. sun.com/developer/technicalArticles/Ecommerce/rfid/sjsrfid/RFID.html. [35] Chris Wauman, “Efficiënt profielbeheer in het Intensieve Zorgen platform”, Juni 2009. [36] Sun, Getting Started With the Java Rule Engine API(JSR 94): Toward Rule-Based Applications, http://java.sun.com/developer/technicalArticles/J2SE/JavaRule.html. [37] Jocelyn Paine , “What is a rule-based system?”, http://www.j-paine.org/students/ lectures/lect3/node5.html. [38] Robert B. Doorenbos, “Production Matching for Large Learning Systems”, CMU-CS-95113, January 31, 1995. [39] Drools, http://jboss.org/drools. [40] Jess, the Rule Engine for the Java Platform, http://www.jessrules.com/.

BIBLIOGRAFIE

101

[41] Eclipse Equinox, http://www.eclipse.org/equinox/. [42] Knopflerfish, http://www.knopflerfish.org/. [43] Felix Apache, http://felix.apache.org/. [44] The OSGi Alliance, “OSGi Service Platform Core Specification”, Release 4, Version 4.2, June 2009. [45] Apache CXF Distributed OSGi, http://cxf.apache.org/distributed-osgi.html. [46] Maven - R-OSGi - transparent OSGi remote extension for distributed services, http: //r-osgi.sourceforge.net/. [47] SOAP specification, http://www.w3.org/TR/soap/. [48] WSDL Tutorial, http://www.w3schools.com/wsdl/. [49] WS-Eventing, http://www.w3.org/Submission/WS-Eventing/. [50] Distributed EventAdmin Service, http://wiki.eclipse.org/Distributed_EventAdmin_ Service. [51] Neil B. Harrison, Paris Avgeriou, “Leveraging Architecture Patterns to Satisfy Quality Attributes”, Department of Mathematics and Computing Science, University of Groningen, Nederland. [52] EclipseLink, http://www.eclipse.org/eclipselink/. [53] Eviware soapUI, http://www.soapui.org/.

Automatisch inloggen via RFID en distribueren van gepersonaliseerde medische taken

Recommend Documents