Asynchrone verwerking in J2EE!

Maat: px
Weergave met pagina beginnen:

Download "Asynchrone verwerking in J2EE!"

Transcriptie

1 Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE Asynchrone verwerking in J2EE! door Samuel Dauwe Promotoren: Prof. Dr. Ir. F. De Turck, Prof. Dr. Ir. B. Dhoedt Scriptiebegeleider: Lic. B. Van Den Bossche Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar

2 Voorwoord Graag zou ik alle personen willen bedanken die hebben geholpen bij het tot stand komen van deze thesis. Mijn promotoren, professor Filip De Turck en professor Bart Dhoedt wil ik bedanken voor de mogelijkheid die ze mij hebben geboden om deze thesis te maken. Ook zou ik mijn dank willen betuigen aan mijn thesisbegeleider Bruno Van Den Bossche voor zijn hulp, opmerkingen, het nalezen en verbeteren van de tekst. Tenslotte wil ook mij familie en medestudenten bedanken voor hun steun. Samuel Dauwe, mei 2007

3 Toelating tot bruikleen De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie 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 scriptie. Samuel Dauwe, mei 2007

4 Asynchrone verwerking in J2EE! door Samuel Dauwe Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar Promotoren: Prof. Dr. Ir. F. De Turck, Prof. Dr. Ir. B. Dhoedt Scriptiebegeleider: Lic. B. Van Den Bossche Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE Samenvatting J2EE biedt een goed gekend framework voor de ontwikkeling en implementatie van componentgebaseerde Enterprise Applicaties. Ondanks de vele voordelen van J2EE is er een gebrek aan een efficiënt generiek event model dat toelaat om op een eenvoudige manier asynchrone applicaties te ontwikkelen. Dit tekort wordt deels opgevangen door JMS maar is als event bus niet zo handig, andere technologieën zoals JAIN SLEE zijn beter geschikt maar missen de voordelen van J2EE. Deze thesis heeft als doel een generiek event systeem te ontwikkelen en te integreren binnen een bestaande J2EE applicatie server. Ter verificatie van het ontwikkelde framework zal het bestaande Massively Multiplayer Online Gaming Platform worden geoptimaliseerd door het integreren van het event model. Deze applicatie maakt gebruik van events voor de interactie van de client met de spelomgeving, waardoor kan worden afgeweken van het request/response principe. Finaal worden de prestaties en functionaliteiten van het framework in detail gevalueerd. Trefwoorden Event model, asynchrone verwerking, J2EE, applicatie server

5 Asynchronous processing in J2EE! Samuel Dauwe Supervisor(s): F. De Turck, B. Dhoedt, B. Van Den Bossche Abstract J2EE is a good known framework for the development and implementation of component-based Enterprise Applications. In spite of the many advantages of J2EE there is a lack of an efficient generic event model that allows simple development of asynchronous applications. This shortage is partly caught by JMS but is not really suitable as an event bus, other technologies such as JAIN SLEE lack the advantages of J2EE. The main goal of this article is to present a generic event model that can be plugged in an existing J2EE application server. For evaluating the functionalities of the framework their is chosen to integrate the event model in the existing Massively Multiplayer online Gaming platform. Finally the performance evaluation reults are presented. Keywords Event model, asynchronous processing, J2EE, application server I. INTRODUCTION FOR a certain type of applications is the traditional, synchronous way of communication not efficient enough. In case a component sends messages at any given point in time to a dynamically changing number of receivers there is a need for an event model. The Java 2 platform Standard Edition has a multipurpose event model, like the Java AWT (abstract Windowing toolkit). In the Java 2 Enterprise Edition there is the Java Message Service that can act as a communication channel. However, as event model it isn t efficient enough, especially for heavily event-driven enterprise applications. This article focuses on the development and implementation of a framework that acts as a communication module between loosely coupled enterprise applications. II. ARCHITECTURE The event model must enable communication between sender en receiver even if they are deployed in a different container, this is represented in Figure 1. The architecture of the event bus consists of two main components: the Eventprocessor and the logical bus. Events received from components will be placed in a central buffer, waiting to be examined. The eventprocessor analyses de header of these events to determine the destination. Because the sender and the receiver are loosely coupled, clients have to register first for the desired event type before they can receive messages. Each event type has a corresponding logical bus, this is a component responsible for the event delivery and consists of a filter, buffer and a routing unit. The first step is the filtering and is necessary filter out messages with a wrong event type. If an event is accepted it will placed in a queue where it waits to be routed. Finally, the router delivers the messages to the receiver(s); these endpoints can be local or remote. Fig. 2. architecture of the resource adapter. III. IMPLEMENTATION Fig. 1. overview of a distributed application with use of the event bus for the communication. The J2EE Connector Architecture (JCA) [1] was chosen as implementation technology, because the possibility to develop a pluggable communication module. These JCA-components are active in a J2EE application server and make it possible to interact with enterprise application. Events can be delivered in an asynchronous way by the use of Message Driven Beans. The external communication is realized with the Java new I/O (NIO) API [2] technology, because the Connector Architecture doesn t specify the way of activating components in a different container. Java NIO makes it possible to create non-blocking sockets, witch are used for the desired asynchronous event delivery.

6 IV. EVALUATION OF THE EVENT MODEL The performance evaluation of the framework was done on a couple of testmachines with the following hardware: Athlon XP (Palomino) 1.4Ghz, with 250Mb memory (in both cases). The purpose of these tests was to do some stress tests to detect the boundaries of the system. The response time and the throughput were determines in the case of an increasing sendrate and a changing event size. The results for the internal communication is given in figure 3. ACKNOWLEDGMENTS The author would like to express his gratitude to F. De Turck and B. Dhoedt, for the opportunity they have given to do research in this area. Special thanks goes out to B. Van Den Bossche for his excellent guidance. REFERENCES [1] Sun Microsystems, Inc., J2EE Connector Architecture Specification, Sun MicroSystems. [2] Sun Microsystems, Inc., The new I/O (NIO) APIs, [3] Bart De Vleeschauwer Stein Desmet Stijn De Mulder Filip De Turck Bart Dhoedt Bruno Van Den Bossche, Tom Verdickt and Piet Demeester, A platform for dynamic microcell redeployment in massively multiplayer online games, Fig. 3. results of the measurements of the latency in case of varring loads for the internal communication. According to the results, the inbound communication is very performant because there is a high throughput in de different cases an de latency is low. De external communication on the other hand doesn t have this property, because the network will form the bottleneck. There is also a diminished asynchronous behaviour because the sender blocks until the last byte is send on the wire to guarantee the event is successfully send. For the evaluation of the functionalities of the event model, the event bus was integrated in an excising distributed application, namely the Massively Multiplayer Online Gaming Platform. This heavily event-based application used the Java Message Service as a communication channel. The need for an efficient event model was clear an so there was chosen to integrate the event bus. More information about Massively Multiplayer Online Gaming is given in the article [3]. V. CONCLUSIONS The J2EE Connector Architecture (JCA) makes it possibly to develop pluggable communication modules capable of connecting enterprise applications in a loosely manner. The main goal of this thesis was to develop JCA-component that could act as an event bus in an enterprise environment. According to the tests, the asynchronous communication between applications that reside in the same application server can be implemented easy and in an efficient manner, with good performance metrics. De external communication on the other hand was not specified by the Connector Architecture. The technology Java NIO was chosen to fill this gap because the possibility to create non-blocking sockets, witch are used for the desired asynchronous event delivery. In this case the network will become the bottleneck because it s inherent reliability mechanisms witch diminish the performance on both sides.

7 INHOUDSOPGAVE i Inhoudsopgave 1 Inleiding Algemeen Probleemstelling Virtual Meeting Room Vereisten van een event model Doelstellingen van de thesis Architectuur Inleiding Overzicht Publish/subscribe principe Logische bussen Sessies Gedetailleerde beschrijving Outbound communicatie Eventprocessor Logische bus Inbound communicatie Externe communicatie Technologieën J2EE Omschrijving J2EE Connector Architecture Algemeen

8 INHOUDSOPGAVE ii Overzicht Alternatieve technologieën JMS JAIN SLEE Java Business Integration (JBI) Implementatie Mapping van de architectuur naar de J2EE Connector Architecture Externe communicatie Probleemstelling Impact op de architectuur Implementatie Scenario s Registratie voor een event type Verzenden van een event Opslaan van sessie data Eerste demo-applicatie: Air Traffic Control Omschrijving Implementatie Overzicht Sessies Externe communicatie Use case: Massively Multiplayer Online Gaming Platform Inleiding Overzicht De LoginServer De MicrocellManager De WereldServer Architectuur Oorspronkelijke opbouw Architectuur met geïntegreerde event bus

9 INHOUDSOPGAVE iii 7 Evaluatie van het framework Inleiding Evaluatie van de performantiematen Bepalen van de responsietijden en de doorvoer Interne communicatie Externe communicatie Invloed op de CPU-Load Conclusie Conclusie 51 A Cd-Rom 53 A.1 Inhoud van de cd-rom A.2 Installatie en gebruik van de software A.2.1 Voorbereidende stappen A.2.2 Uitvoeren van de applicaties Bibliografie 56

10 INLEIDING 1 Hoofdstuk 1 Inleiding 1.1 Algemeen Applicaties in een object-georiënteerde omgeving zijn opgebouwd uit verschillende componenten die met elkaar interageren. Voor de onderlinge communicatie is het traditioneel model waarbij objecten elkaars methoden oproepen soms niet de meest efficiënte oplossing, een concreet voorbeeld van zo n toepassing is een grafische interface. Deze is meestal opgesplitst in twee delen, zo zal een gedeelte instaan voor de presentatie naar de gebruiker toe en het onderscheppen van gebrukersinvoer. Een ander deel zal de eigenlijke logica bevatten om deze invoer te verwerken en de gepaste acties te ondernemen, zoals het tonen van een menu bij een bepaalde invoer van de gebruiker. Deze communicatie zal een andere aanpak vereisen dan het louter aanroepen van methodes, ten eerste is er een noodzaak aan een asynchroon gedrag. De component die in staat voor de verwerking moet instaat zijn om op gelijk welk moment een aanvraag te ontvangen, zelfs als deze bezig is met andere berekeningen. Er zal dus moeten afgeweken worden van de traditionele synchrone, procedurele aanpak er is namelijk een ontkoppeling nodig tussen de verschillende componenten. Daarnaast zal de informatie die onderling wordt uitgewisseld niet gemakkelijk meer voorgesteld kunnen worden door eenvoudige data types, er zal en voor andere aanpak moeten gekozen worden namelijk het gebruik van events. Een event is een voorstelling van een gebeurtenis, het plots ontstaan van een zekere eenheid van informatie zoals het aanklikken van een bepaalde knop in een grafische interface. Event-gedreven applicaties maken gebruik van deze vorm van communicatie. De oplossing voor bovenstaande problemen is een event model of anders gezegd een event bus

11 1.2 Probleemstelling 2 waarop applicatie op een asynchrone manier berichten kunnen versturen. Het framework zorgt dan ervoor dat deze events bij de juiste bestemmeling(en) terecht komen. Door deze aanpak hoeven de zender en ontvanger niet op de hoogte te zijn van elkaars bestaan, het is voldoende dat een component events kan verzenden naar het event model en dat de luisteraar deze kan ontvangen door zich bijvoorbeeld eerste te registreren en hierbij aan te geven in welke events het geïnteresseerd is. Daarnaast hoeven er aan de ontvangst-zijde geen bepaalde methodes zoals polling of wachten totdat een bericht beschikbaar komt toegepast te worden, deze maken het geheel enkel maar complexer en halen de performantie naar beneden. 1.2 Probleemstelling Voor de onwikkeling van event-gedreven applicaties is de noodzaak van een event model duidelijk, de volgende stap is eens na te gaan aan welke vereisten dit framework moet voldoen. Aangezien de Java 2 Platform Standard Edition over zo n veelzijdig event model beschikt, onder andere in Java AWT (Abstract Windowing Toolkit) is het beter om dit eens te onderzoeken in de Java 2 Enterprise Edition (afgekort: J2EE) [1]. Enterprise applicaties beschikken echter niet over zo n algemeen event model. Een voorbeeld van een event-gebaseerde applicatie in J2EE die niet gebruik maakt van een event model, is de Virtual Meeting Room die hieronder verder wordt beschreven. Deze applicatie is dus geschikt om de eerste vereisten van het te ontwikkelen framework op te stellen Virtual Meeting Room Omschrijving De Virtual Meeting Room is een soort chatprogramma waarin de gebruikers vrij kunnen rondlopen binnen bepaalde grenzen, dit kan bijvoorbeeld een kamer zijn of een andere willekeurige omgeving. Ze kunnen ook de snelheid waarmee ze zich verplaatsen aanpassen. Op het moment dat twee (of meerdere) gebruikers zich dicht genoeg bij elkaar bevinden, kunnen zijn met elkaar tekstberichten uitwisselen. Een persoon ziet elke andere afgebeeld in de kamer en kan real-time de bewegingen van de andere chatters volgen. Personen kunnen inloggen in het systeem door het IP-adres van de server op te geven, een minimum aan persoonlijke informatie, en een eventueel initieel gewenste positie in de omgeving.

12 1.2 Probleemstelling 3 Als een gebruiker de applicatie verlaat, kan die geen berichten meer ontvangen of versturen en wordt bij de anderen van de omgeving verwijderd. Architectuur Er wordt gebruik gemaakt van een Client-Server-architectuur. Een client zendt events naar de server die ze vervolgens zal verwerken en de gepaste acties zal ondernemen. De server zal een globaal beeld hebben van de Virtual Meeting Room en berichten aan de juiste bestemmelingen kunnen afleveren. Concreet zal er bij het versturen van bericht telkens moeten bepaald worden wie het mag ontvangen, eenmaal de juiste gebruikers zijn geselecteerd krijgen die elk het betreffende bericht. Figuur 1.1: Architectuur van de Virtual Meeting Room applicatie Vereisten van een event model De Virtual Meeting Room is een typisch voorbeeld van een event-gebaseerde gedistribueerde applicatie in J2EE. Uit de bespreking van deze toepassing kunnen we besluiten dat een event model een software architectuur zal zijn die de volgende verantwoordelijkheden zal hebben: Het moet een event producer in staat stellen events te genereren en te verzenden naar alle geïnresseerde luisteraars. Een bron van events zal vaak niet willen wachten op een bevestiging dat het event correct is afgeleverd, omdat zender en ontvanger ontkoppeld zullen zijn. Het versturen van een

13 1.3 Doelstellingen van de thesis 4 event moet dus niet blokkerend zijn, zodat de verzender na het genereren van een bericht onmiddellijk kan verder gaan met het uitvoeren van andere instructies. Event listeners moeten de mogelijkheid hebben om zich te registreren en te deregistreren voor events waarvoor ze geïteresseerd zijn. Events af te leveren aan een bestemmeling, ongeacht het moment van verzending. Er zal dus een asynchroon gedrag vereist zijn naar de gebruiker toe. 1.3 Doelstellingen van de thesis Het uiteindelijke doel van deze thesis is om een algemeen bruikbaar event model te ontwerpen en vervolgens te implementeren. Dit framework moet integreerbaar zijn binnen een bestaande J2EE applicatie server en eenvoudig toegankelijk zijn voor asynchrone, event-gebaseerde applicaties. In een tweede fase zal een event gebaseerde use case uitgewerkt worden die als doel heeft de verschillende functionaliteiten van het model aan te tonen. In dit stadium zullen ook eventuele problemen ontdekt worden en ook onvoorziene functionaliteiten kunnen in deze fase worden toegevoegd. In een laatste fase zal de globale prestatie geëvalueerd worden, belangrijke performantiematen zijn hierbij de responstijden en de doorvoer omdat deze van belang zijn voor veeleisende applicaties zoals je die typisch in telecommunicatietoepassingen kan aantreffen.

14 ARCHITECTUUR 5 Hoofdstuk 2 Architectuur 2.1 Inleiding Voor het opstellen van een architectuur van een event model dat asynchrone communicatie mogelijk maakt tussen applicaties is het belangrijk dat er een ontkoppeling is tussen de zender en de ontvanger. De component die events wil versturen moet namelijk niet op de hoogte zijn van de aanwezigheid van de ontvanger. Daarnaast moet de communicatie zo transparant mogelijk gebeuren, dat wil zeggen dat het event model de belangrijkste taken zoals routering, buffering en filtering zal uitvoeren zonder de hulp van de zendende applicatie. De architectuur moet bovendien voorzien zijn op een groot aantal geregistreerde componenten, dus de performantie van het event model zal uiteindelijk een belangrijk factor zijn. Bijkomende eisen zijn dat de event bus bi-directionele communicatie moet mogelijk maken, bovendien mag de communicatie niet beperkt blijven voor componenten die zich enkel in dezelfde container bevinden. Het moet namelijk mogelijk zijn om events te versturen van zender naar ontvanger als beiden zich in een verschillende applicatie server bevinden. In figuur 2.1 is een algemene voorstelling gegeven van een gedistribueerde omgeving waarbij er gebruik gemaakt wordt van de event bus voor de interne en externe communicatie via events. 2.2 Overzicht Het doel van de architectuur is om met de vooropgestelde vereisten zoveel rekening te houden, anderzijds moet het mogelijk zijn om later eventuele functionaliteiten toe te voegen. In het

15 2.2 Overzicht 6 Figuur 2.1: overzicht van een gedistribueerde omgeving met gebruik van de event bus voor de onderlinge communicatie. volgende overzicht wordt een samenvatting gegeven van hoe de vooropgestelde vereisten aan bod komen in de architectuur Publish/subscribe principe Om een ontkoppeling tussen zender en ontvanger mogelijk te maken wordt gebruik gemaakt van het header-based publish/subscribe patroon, de routering zal gebeuren op basis van de inhoud van het bericht die omschreven wordt via een veld in de header die het type van het event aangeeft. Hierdoor moet een bepaalde luisteraar zich enkel registreren bij de event bus op basis van het type events die hij wenst te ontvangen en hoeft hij zich niets aan te trekken van wie die berichten afkomstig zijn. Deze aanpak heeft bovendien als voordeel dat de filtering aan de ontvanger zijde minimaal zal zijn omdat hij enkel de events zal ontvangen waarin hij geïnteresseerd is. Om de routering correct te laten verlopen moet elk te verzenden event overerven van de de klasse MyEvent, die de header van het bericht zal voorstellen. Bovendien wordt deze overerving elk event serialiseerbaar, zodat de berichten over het netwerk kunnen worden verstuurd.

16 2.2 Overzicht Logische bussen Een logische de verantwoordelijkheid voor het afleveren van events aan de bestemmeling ongeacht de locatie van de event listener, deze kan zich namelijk in een andere applicatie server bevinden. Een logische bus is geassocieerd aan een bepaald event type en zal intern zorgen voor filtering, buffering en routering naar de luisteraar Sessies Een sessie wordt typisch omgezet tussen een zender en een bestemmeling en omvat een stroom van events die gerelateerd zijn aan elkaar. Aangezien de informatie horende bij een sessie nogal groot kan worden is het niet echt efficiënt om deze gegevens te verpakken in events en onderling uit te wisselen, dit zorgt enkel voor bijkomende belasting van de event bus. Om deze redenen wordt gebruik gemaakt van een datastore, deze heeft als doel het opslaan van sessie informatie. Als standaard datastore zal de JBoss cache gebruikt worden, deze biedt een object-georiënteerde, transactionele gedistrubeerde cache aan en werkt vlot samen met de JBoss applicatie server. Daarnaast heeft deze cache als voordeel dat het sterk configureerbaar is en geoptimaliseerd kan worden aan de omgeving die ofwel standalone kan zijn of in samenwerking met een applicatie server. Een component kan in de header aangegeven dat het event tot een sessie behoord door het specificeren van een sessie-id. De ontvanger kan dan aan de hand van deze identificatie de data ophalen vanuit de cache. Aangezien de cache persistente opslag toelaat blijven de objecten blijvend opgeslagen, zelfs indien de datastore herstart moet worden. Ook wordt de sessie dataopslag onafhankelijk van de event bus, als de resource adapter niet actief is dan blijft de sessiedata bewaard en tevens nog toegankelijk. Om ervoor te zorgen dat de dataopslag niet gebonden is aan een bepaald type datastore, wordt er gebruik gemaakt van een adapter. Deze heeft als doel de instructies gerelateerd aan het beheer van de sessie data te vertalen naar het onderliggende type datastore. Het is evident dat deze adapter onafhankelijk van de event bus bruikbaar is. In figuur 2.2 is een globaal overzicht gegeven van de verschillende componenten binnen een applicatie server, hierbij wordt ervan uitgegaan dat toegang tot de datastore kan verkregen worden via de connectie naar de event bus.

17 2.3 Gedetailleerde beschrijving 8 Figuur 2.2: opbouw van de globale architectuur. 2.3 Gedetailleerde beschrijving De finale architectuur van het event model is weergegeven in figuur 2.4, om het overzicht te kunnen bewaren zijn de verschillende benodigde interfaces voor het implementeren van de verschillende contracten van de Java Connector Architecture niet weergegeven. Voor een meer gedetailleerde opbouw van de resource adapter verwijs ik naar hoofdstuk 3 en 4. De belangrijkste Aspecten van de architectuur zijn: Outbound communicatie Dit omvat het communicatiegedeelte tussen een applicatie component en het event model. De client zal via een EventbusConnection events verzenden, deze berichten worden vervolgens doorgegeven aan de EventHandler. Aangezien alle events uiteindelijk in een centrale event queue in de Eventprocessor terecht komen is het noodzakelijk dat het plaatsen van berichten in deze buffer gerealiseerd wordt door gebruik te maken van een thread. Op die manier kan de concurrentie gewaarborgd worden en hoeft het EventbusConnection object niet te wachten totdat het event is afgeleverd.

18 2.3 Gedetailleerde beschrijving Eventprocessor Hier bevindt zich de meeste logica van de eigenlijke resource adapter. Alle events afkomstig van de verschillende connecties naar de event bus toe, komen terecht in een centrale buffer vooraleer ze verwerkt worden door de Eventprocessor. De voornaamste taak van deze component is het interpreteren van de informatie die zich bevindt in de header van een event. Berichten die dus niet over een geschikte header beschikken worden direct geweigerd omdat verdere verwerking dan toch niet veel zin meer heeft. Aangezien er ontkoppeling is tussen de zender en de ontvanger worden de betrokken componenten niet op de hoogte gebracht van zo n weigering. Dit heeft als voordeel dat de verzenden component zich niets moet aantrekken van foutafhandeling bij het verzenden van events. De volledige routering steunt op het concept van event types. Zo kan een applicatie component zich registreren voor een bepaald type event, waardoor de Eventprocessor die luisteraar aan de correcte logische bus zal associëren. Daarnaast is ook deregistratie mogelijk. Maar het uiteindelijk hoofddoel is het routeren van een event naar de juiste logische bus. Elke logische bus is geassocieerd met een bepaald uniek event type, de Eventprocessor hoeft dus in principe enkel het event type uit de header te lezen, de bijhorende logische bus op te zoeken en vervolgens het bericht ernaar toe te sturen. Om de Eventprocessor en logische bussen ook daadwerkelijk in staat te stellen om luisteraars te bereiken moet er een lijst bijgehouden worden van proxy s. Een proxy is een lokale vertegenwoordiger van een bestemmeling, alle berichten die er aan doorgegeven worden komen bij de bestemmeling terecht onafhankelijk of deze zich nu lokaal bevindt of op een andere machine. Met elke proxy is een ActivationSpecification geassocieerd die een event listener identificeert. Wanneer in de deployment descriptor van een enterprise bean verwezen wordt naar een JCAcomponent, moeten ook de verschillende vereiste gegevens worden opgegeven die nodig zijn voor het correct opstellen van de ActivationSpecification. In deze specificatie moet zeker een unieke identificatie opgegeven worden, zoals bijvoorbeeld de JNDI-naam van de bean. Het is aan de hand van deze identificatie dat de bron van een event kan worden achterhaald, die bij een registratie of deregistratie gebruikt wordt om de correcte proxy op te zoeken en te binden aan de gewenste logische bus.

19 2.3 Gedetailleerde beschrijving Logische bus Omwille van performantie redenen wordt gebruik gemaakt van het concept logische bus, de interne opbouw is weergegeven in figuur 2.3. Figuur 2.3: interne structuur van een logische bus. In het volgende overzicht wordt een beschrijving gegeven van de verschillende elementen van de logische bus. Filtering Luisteraars drukken hun interesse uit voor events door zich te registreren voor een bepaald event type. Om die reden zal een logische bus geassocieerd zijn met een bepaald type om de routering efficiënter verlopen. Bovendien krijgen we een reeks onafhankelijke bussen die eventueel individueel geoptimaliseerd kunnen worden. De voornaamste verantwoordelijkheid van de filter is berichten van een afwijkend event type de toegang te weigeren. Aangezien een logische bus geassocieerd is met een event type kan de routering efficiënter verlopen. Ook zal voor sommige events een verschillende quality of service (QoS) noodzakelijk zijn, zo zal het voor het ene bericht noodzakelijk zijn dat die voor onbepaalde duur gebufferd wordt indien er geen luisteraar is geregistreerd en voor de andere niet. In de header van de event kan aangegeven worden indien een speciale behandeling gewenst is, de filter zal deze events uit de stroom van berichten halen zodat ze apart verwerkt kunnen worden. Buffering Aan een logische bus kunnen een groot aantal luisteraars gebonden zijn, het asynchroon afleveren van een event bij al deze eindpunten zal een zekere niet te verwaarlozen tijd vergen. Om ervoor te zorgen dat tijdens de routeringsfase geen nieuw ontvangen events verloren gaan worden deze berichten ondertussen in een buffer geplaatst waar ze een tijdje

20 2.3 Gedetailleerde beschrijving 11 moeten wachten vooraleer ze gerouteerd zullen worden. Hierdoor kan gegarandeerd worden dat bij zwaardere belaste bussen geen inkomende events verloren gaan. Routering In deze laatste fase wordt nagegaan welke luisteraars geregistreerd zijn en vervolgens wordt het bericht afgeleverd aan de bestemmelingen. Deze routering zal tevens rekening moeten houden met de locatie van de ontvanger, die kan zich namelijk in een verschillende applicatie server bevinden Inbound communicatie Dit omvat het eigenlijke versturen van het event van de resource adapter naar de luisteraar. Hiervoor wordt gebruik gemaakt van een LocalEvendEndpoint object die dienst doet als proxy naar de ontvanger toe, met elke luisteraar is zo n object geassocieerd Externe communicatie Voor het gebruik van de event bus in meer gedistribueerde omgevingen is het noodzakelijk dat de architectuur er op voorzien is dat de zender en de bestemmeling zich kunnen bevinden in een verschillende container, in deze situatie moeten events correct terecht komen bij deze luisteraar. Om met deze situatie overweg te kunnen werden 2 verschillende scenario s voorzien: Ontvangen van events afkomstig van een externe event bus: de architectuur is hierop voorzien door het invoeren van 2 hulpklassen, de RemoteListener en EventHandler. De RemoteListener zal instaan voor het ontvangen van het eigenlijke event, soms kan het nodig zijn dat hier nog een paar operaties gebeuren zoals het deserialiseren van het ontvangen object naar een event zodanig dat de Eventprocessor hiermee overweg kan. Vervolgens wordt het bericht doorgegeven aan de EventHandler. Deze handler zorgt voor bijkomende buffering en zal bovendien problemen vermijden wanneer verschillende handlers op hetzelfde ogenblik events in de centrale buffer van de Eventprocessor willen plaatsen. Een luisteraar bevindt zich in een andere applicatie server: dit is opgelost door het invoeren van een RemoteEventEndpoint klasse, die dienst doet als proxy naar de externe event listener. Deze klasse zal uiteindelijk dezelfde interface implementeren als de LocalEvendEndpoint klasse, op die manier hoeft de logische bus niet op de hoogte te zijn

21 2.3 Gedetailleerde beschrijving 12 van de locatie van de luisteraar. Door deze aanpak krijgt de EventProcessor een extra verantwoordelijkheid, hij moet namelijk detecteren of de bestemmeling lokaal aanwezig is of indien hij zich op een externe locatie bevindt. Indien de luisteraar lokaal is hoeven geen extra acties ondernomen te worden, maar als deze aanwezig is in een andere applicatie server moet er een proxy aangemaakt worden naar deze bestemmeling. Het is dan de taak van de RemoteListener om in de header extra informatie toe te voegen zodat dit realiseerbaar is, op die plaats is immers de meeste informatie beschikbaar over het gebruikte protocol. De EventProcessor zal dus uiteindelijk over twee lijsten beschikken met elk een verschillend type event listener, lokaal of extern. Bij een registratie event moet hij enkel de juiste proxy selecteren en binden aan de gewenste logische bus. Een voordeel deze aanpak is dat er gemakkelijk kan overgeschakeld worden naar een andere manier van externe communicatie. Als bijvoorbeeld een ander communicatie protocol gekozen wordt hoeven enkel de RemoteListener en de RemoteEventEndpoint klasse vervangen worden. Daarnaast moeten nog enkele wijzigingen aangebracht worden aan de interpretatie logica van de EventProcessor maar de de globale impact van zo n wijziging blijft beperkt tot 3 klassen.

22 2.3 Gedetailleerde beschrijving 13 Figuur 2.4: de verschillende componenten binnen de J2EE application server en de vereenvoudigde opbouw van de event bus.

23 TECHNOLOGIEËN 14 Hoofdstuk 3 Technologieën Het doel van deze thesis is het ontwikkelen van een event model voor enterprise applicaties, de implementatie technologie is dan ook Java 2 Enterprise Edition (J2EE). In dit hoofdstuk worden de voordelen van J2EE gegeven, daarnaast wordt een kort overzicht gegeven van de J2EE Connector Architecture (JCA). Deze technologie laat toe resource adapters te creëren en laten toe de functionaliteiten van een applicatie server uit te breiden. Connectors worden voornamelijk gebruikt om verbindingen mogelijk te maken naar heterogene achterliggende systemen, Enterprise Information Systems (EISs) genoemd. Aangezien deze connecties in het kader van deze thesis niet noodzakelijk zijn wordt er in de vertaling van de architectuur naar de eigenlijke JCA-component iets dieper op ingegaan hoe dit probleem werd opgelost. 3.1 J2EE Omschrijving Het ontwikkelplatform Java 2 Enterprise Edition is een uitbreiding op de Java standaard editie en wordt gebruikt voor de ontwikkeling van componentgebaseerde applicaties. Een veel gebruikt type architectuur bij de ontwikkeling van gedistribueerde J2EE applicaties is het drie-lagen model zoals weergegeven is in Figuur 3.1. Enerzijds hebben we de client laag waarbij meestal uitgegaan wordt van een thin client, deze heeft als taak de voorstelling van de gegevens naar de gebruiker toe en het verzamelen van gegevens voor de volgende laag. Daarnaast is er de business laag waarin de eigenlijke verwerking zal gebeuren. Het overgrote deel van de logica zal zich in deze laag bevinden en zit vervat in Enterprise JavaBeans (EJB) die zich in de EJB container

24 3.1 J2EE 15 bevinden. Containers waarin deze componenten actief zijn hebben als voordeel dat ze veel taken van de programmeurs kunnen overnemen, zodat deze zich voornamelijk op de eigenlijke business logica kunnen richten. De belangrijkste zaken die kunnen afgehandeld worden door de container zijn: authenticatie, naming services, verzorgen van data-integriteit en geautomatiseerde dataopslag. Figuur 3.1: voorstelling van een multitier gedistribueerd omgeving. We kunnen drie type EJB s onderscheiden waarbij de onderlinge verschillen in het volgende overzicht zijn weergegeven. Session Beans (SB) Een Session Bean is een voorstelling van een conversatie tussen een client en de serverzijde, deze beans worden gebruikt in een bepaalde sessie voor het uitvoeren van business logica. We kunnen twee types onderscheiden, ten eerste zijn er de stateless Session Beans die geen interne toestand hebben. Ten tweede zijn er stateful Session Beans, die gekoppeld zijn aan een bepaalde client en dus niet kunnen hergebruikt worden wegens het hebben van een interne toestand. Entity Beans (EB) Entity Beans zijn de voorstelling van business objecten die zich bevinden in een relationele databank en zorgen voor persistentie van data. Een Entity Bean zal dus corresponderen met een tabel in een databank en elke instantie van een bean is een voorstelling van een rij in deze tabel.

25 3.2 J2EE Connector Architecture 16 Message Driven Bean (MDB) Deze enterprise bean stelt J2EE applicaties in staat om asynchroon berichten te laten ontvangen en te verwerken. Het kan enerzijds fungeren als luisteraar voor berichten afkomstig van JMS maar kan ook gebruikt worden als event listener voor berichten afkomstig van een JCA-component. 3.2 J2EE Connector Architecture Algemeen Een resource adapter is een component die in een J2EE applicatie server kan geplugd worden. Componenten kunnen er dan gebruik van maken om te interageren met een Enterprise Information System (EIS) zoals bijvoorbeeld een ERP systeem of een databank. Om deze communicatie te kunnen realiseren moet een resource adapter voldoen aan een aantal contracten opgelegd door de J2EE Connector Architecture specificatie. Een overzicht van de verschillende contracten is weergegeven in Figuur 3.2. Het system-level contract maakt de interactie mogelijk tussen de application server en de resource adapter en omvat connection management, transaction management en beveiliging. Componenten maken gebruik van een client API om te communiceren met het EIS, dit kan mogelijk gemaakt worden door de implementatie van de in de JCA gepecificeerde Common Client Interface (CCI) of via een zelf gekozen interface. Aangezien de connector georiënteerd is op de communicatie met achterliggende heterogene systemen wordt, legt de Connector geen verplichtingen op voor het protocol of de interfaces voor deze interactie. De resource adapter kan zowel gebruikt worden in een managed omgeving als in een non-managed omgeving. In een managed omgeving hebben we typisch te maken met een meerlagige architectuur waarbij de in de applicatie server ontplooide componenten (EJB s, JSP of servlets) connectie maken met het achterliggede EIS via de resource adapter. In een non-managed omgeving interageert een component direct met de resource adapter zonder gebruik te maken van de services aangeboden door de applicatieserver.

26 3.2 J2EE Connector Architecture 17 Figuur 3.2: overzicht van de contracten tussen de verschillende componenten Overzicht Connection management Een J2EE applicatie component moet de mogelijkheid hebben om een connectie te verkrijgen van de resource adapter, waarmee hij kan communiceren met het achterliggende EIS. Om dit te realiseren moet een JCA-component voldoen aan het connection management contract dat gespecificeerd is tussen de applicatie server en de resource adapter. Daarvoor zal de resource adapter onder andere een connection factory binden in de JNDI namespace. J2EE applicatie componenten gebruiken deze factory om de eigenlijke connectie te creëren, wat meestal zal gebeuren via de getconnection methode, waarbij ook eventuele beveiligsinformatie kan worden meegegeven. Met elk connection factory object, is er een ConnectionManager geassocieerd. In een managed omgeving zorgt de applicatie server voor de implementatie van deze ConnectionManager, deze zal dan bepaalde services zoals connection pooling zelf afhandelen. In een non-managed omgeving moet de resource adapter hiervoor zorgen. De eigenlijke connectie wordt voorgesteld door een ManagedConnection object, de connection handle genoemd, waarmee een application server meestal een ConnectionEventListener zal associëren om het beheer te vereenvoudigen.

27 3.2 J2EE Connector Architecture 18 In Figuur 3.3 is een overzicht gegeven van het proces voor het verkrijgen van een connectie, tussen de verschillende onderdelen die gespecificeerd zijn in het connection management contract. Een J2EE component zoekt eerst een connection factory op in de JNDI namespace, beschikbaar gesteld door een bepaalde resource adapter. Om een connectie te verkrijgen moet de getconnection methode opgeroepen worden. De connectie factory zal deze aanvraag doorgeven aan de ConnectionManager, die eerst zal proberen een bestaande inactieve verbinding te hergebruiken, indien er zo geen zijn wordt er een nieuwe aangemaakt. De J2EE applicatie zal vervolgens een connection event listener registreren bij de ManagedConnection, om onder andere te kunnen detecteren dat een verbinding wordt gesloten. De applicatie server vraagt vervolgens een connection handle bij de ManagedConnection. Tenslotte wordt deze handle via de connection factory aan het J2EE component afgeleverd. Figuur 3.3: de verschillende interacties die nodig zijn voor het verkrijgen van een connectie. Work Management Resource adapters zullen voor hun werking veelal gebruik maken van een aantal threads, deze kunnen handig zijn om op een concurrente manier berichten te ontvangen, verwerken en af te leveren aan de juiste bestemmeling. Aangezien de resource adapter actief is binnen de

28 3.3 Alternatieve technologieën 19 applicatie server is het beter deze server de afhandeling van java threads te laten afhandelen. Bovendien heeft de applicatie server een globaal overzicht over de runtime environment. Het work-management contract laat een resource adapter toe om work instanties door te geven aan de application server. Deze work instanties worden doorgegeven aan de workmanager die verdere afhandeling van de threads verzorgt. Wanneer een resource adapter een WorkListener instantie doorgeeft aan de application server wordt de adapter op de hoogte gehouden van de status van de work threads. Message Inflow Via message inflow of inbound communication genoemd, kan een resource adapter asynchroon berichten of events afleveren aan componenten die zich in de applicatie server bevinden. De componenten die meestal asynchroon deze berichten zullen ontvangen en verwerken zullen meestal message-driven beans zijn. 3.3 Alternatieve technologieën JMS De Java Message Service is een Java API die toelaat applicaties of componenten onderling berichten uit te wisselen. De belangrijkste eigenschappen zijn: Zender en ontvanger zijn niet gekoppeld met elkaar, ze hoeven niets af te weten van elkaars bestaan. De communicatie via JMS is asynchroon Berichten worden slechts een maal afgeleverd, ook wordt de garantie geboden dat er geen dubbele exemplaren zullen toekomen bij de ontvanger. Mogelijkheid tot ondersteuning van transacties. De Java Message Service is onder andere bruikbaar voor application clients, enterprise JavaBeans en web componenten. Asynchroon ontvangen van berichten is eenvoudig mogelijk door gebruik te maken van Message-driven beans.

29 3.3 Alternatieve technologieën 20 JMS ondersteund zowel het point-to-point als het publish/subscribe principe. In het pointto-point model wordt gebruik gemaakt van een message queue waar de zender berichten naar stuurt, de ontvanger kan deze vervolgens opvragen op een zelf gekozen ogenblik. Elk bericht heeft dus slechts een ontvanger, extra betrouwbaarheid wordt bekomen doordat de client voor elk correct ontvangen message een bevestiging stuurt. Het publish/subscribe messaging domain steunt op het concept van een topic waarop berichten kunnen worden gepubliceerd. Een client registreert vervolgens om een bepaald type bericht te ontvangen waarin het geïnteresseerd is. Deze aanpak heeft als voordeel dat een bericht meerdere consumers kan hebben, een nadeel is wel dat berichten verloren gaan als er geen luisteraars geregistreerd zijn. De voornaamste nadelen van het gebruik JMS als event bus zijn Telkens een event verstuurd wordt via JMS moet deze verpakt worden in een message zodat de Java Message Service hiermee overweg kan, dit kan leiden tot dalende performantie als de de belasting van de server hoog wordt. De filtering vindt plaats aan de client-zijde, voor elk ontvangen bericht moet eerst gecontroleerd worden of dit gewenst is vooraleer de verdere verwerking ervan kan beginnen. JMS is minder efficint bij een groot aantal gebruikers, aangezien er dan extra inspanningen moeten worden geleverd worden aan de client-zijde om een goede filtering te bekomen van de berichten JAIN SLEE De Java APIs for Intelligent Networks (afgekort: JAIN) [2] is een onderdeel van de Java API die toelaat om services te ontwikkelen voor netwerkomgevingen op een platformonafhankelijke en netwerkonafhankelijke manier. In deze context treffen we de standaard JAIN Service Logic Execution Environment (afgekort: JAIN SLEE) [3] aan. Deze heeft als doel een asynchroon event-gedreven, performant framework aan te bieden en wordt vooral gebruikt in de telecommunicatie. JAIN SLEE maakt gebruik van een component gebaseerde architectuur en is dus het best vergelijkbaar met de J2EE architectuur waarbij applicaties zich in een container bevinden die bepaalde services zal aanbieden. Het grootste verschil echter is dat JAIN SLEE speciaal werd ontworpen om lage latenties en hoge throughputs te bekomen, de communicatie gebeurd bij volledig via events waardoor deze metrieken een belangrijke rol spelen.

30 3.3 Alternatieve technologieën Java Business Integration (JBI) Java Business Integration (JBI) [4] is een specificatie die beschrijft hoe componenten op een platformonafhankelijke manier met elkaar kunnen worden verbonden en met elkaar kunnen communiceren. Er zijn twee types componenten te onderscheiden binnen een JBI container: Service Engines: bevatten services zoals business logica of data transformatie. Binding components: zijn verantwoordelijk voor de interface met een extern protocol zoals SOAP of JMS. Voor elk ondersteund protocol is er een specifieke binding component die in de JBI container kan worden geplugd. De binding component consumeert en produceert protocol-specifieke data en levert deze data af aan de Normalized Message Service (NMS). Deze service zal instaan voor de berichten vertaling naar de Service Engines. Dit is grafisch weergegeven in figuur 3.4 Figuur 3.4: overzicht van de te onderscheiden componenten binnen een JBI container Java Business Integration (JBI) is vooral efficiënt als communicatiebus tussen applicatieservers en minder voor interne communicatie.

31 IMPLEMENTATIE 22 Hoofdstuk 4 Implementatie Het doel van dit hoofdstuk is een overzicht te geven van de vertaling van de opgestelde architectuur naar de J2EE Connector Architecture (JCA). Voor meer informatie over deze technologie verwijs ik naar hoofdstuk Mapping van de architectuur naar de J2EE Connector Architecture Een resource adapter wordt typisch gebruikt voor de connectie met een EIS, voor het event model is dit niet van toepassing. Het gedeelte van de specificatie moest worden uitwerkt is de communicatie van en naar een applicatie component. In figuur 4.1 is weergegeven hoe dit in zijn werk gaat. De event bus zal dus het normale connection management contract implementeren voor een managed omgeving, waarbij de applicatie server zal instaan voor het beheer van de verbindingen naar de resource adapter. Een ManagedConnection zal door de oproep van de getconnection-methode door de ConnectionManager een EventbusConnection creëren die aan de client zal worden afgeleverd. Deze EventbusConnection zal echter slechts de enige vereiste methode implementeren van de interface namelijk de close-methode. Deze functie zal een ConnectionEvent genereren die doorgegeven wordt aan de EventbusConnectionEventlistener, die de applicatie server in staat stelt het sluiten van een connectie naar de eventbus te detecteren. Daarnaast zal de EventbusConnection ook nog zorgen dat er connectie kan gemaakt worden met de adapter voor datastore-toegang en een fireeventmethode voorzien die het ontvangen event zal doorgeven aan de EventHandler.

32 4.2 Externe communicatie 23 Figuur 4.1: de verschillende interacties die nodig zijn voor het creeren van een connectie naar de event bus. 4.2 Externe communicatie Probleemstelling De J2EE Connector Architecture maakt het mogelijk om op een eenvoudige en asynchrone manier events te verzenden naar message-driven beans, wanneer deze zich in dezelfde applicatie server bevinden als de resource adapter. De manier om beans te activeren die zich in een andere container bevinden wordt echter niet gespecificeerd. Tijdens de implementatie-fase werd dan ook onderzocht op welke manier dit kon worden gerealiseerd. Een eerste manier om dit te realiseren zonder de Java Connector Architecture is door gebruik te maken van JMS, om redenen aangehaald in hoofstuk 1 werd dit niet verder onderzocht. Een andere mogelijkheid is via Remote Method Invocation die methode-oproepen toelaat op remote objecten. RMI heeft echter in het kader van deze thesis het nadeel dat het van nature synchroon is. Tenslotte is gekozen om gebruik te maken van de Java new I/O (NIO) API [5], die asynchroon gedrag mogelijk maakt via niet-blokkerende sockets. Aan het gebruik van Java NIO zijn wel een paar nadelen verbonden, zo moet er zelf gezorgd worden voor serialisatie en deserialisatie van events, wat meestal niet de meest efficiënte oplos-

33 4.2 Externe communicatie 24 sing zal opleveren. Een mogelijke manier hoe dit kan gebeuren is weergegeven in Figuur 4.2. Aangezien Java NIO gebruik maakt van een SocketChannel voor de communicatie, moet een event eerst vertaald worden naar een ByteBuffer-object zodat het kanaal hiermee overweg kan. Daarom moet elk bericht via een ObjectOutputStream geschreven worden die het vervolgens zal doorgeven aan een ByteOutputStream om uiteindelijk in een ByteBuffer terecht te komen. Aan de client-zijde zal het omgekeerde gebeuren, alleen zal er hier nog een kleine probleem optreden. Java NIO vereist immers dat de buffergrootte op voorhand is vastgelegd, aangezien de grootte van een ontvangen event op voorhand ongekend is levert dit problemen op bij de deserialisatie. Zo kan er bijvoorbeeld de volgende situatie optreden: een event wordt van de SocketChannel gelezen, maar direct daarachter volgt nog een event, er zal dus geprobeerd worden de alreeds onvolledig opgevulde buffer aan te vullen met bytes van het laatst ontvangen bericht. Dit heeft als resultaat dat een ByteBuffer meerdere events bevat of in het slechtste geval het einde van een event ontbreekt omdat de buffer vol was. Om zo n problemen te vermijden wordt door de zender eerst de grootte van het bericht bepaald en voorgesteld als een integer van 4 bytes groot. Deze grootte wordt eerst in de ByteBuffer geplaatst gevolgd door het eigenlijke event. De event bus zal telkens eerst het vaste aantal van 4 bytes inlezen en aan de hand daarvan een buffer kunnen alloceren met de correcte grootte Impact op de architectuur Het toevoegen van de externe communicatie of het verwisselen van protocol zal geen grote gevolgen hebben voor de eigenlijke architectuur. Zoals ook verduidelijkt werd in Hoofdstuk 2 komt dit enkel neer op het vervangen van de klassen RemoteListener en RemoteEventEndPoint. De aanpassingen aan de logica van de Eventprocessor blijft eerder beperkt Implementatie Publish/subscripe principe Door het gebruik van SocketChannels voor de communicatie, kunnen we componenten nu identificeren aan de hand van een socket adres, dit is de combinatie van een IP-adres en een poortnummer. De RemoteListener die we vanaf nu een duidelijkere naam zullen geven zoals de SocketChannelListener, zal voor elke binnenkomende socket het IP-adres met bijhorende poort bepalen van de zender. Deze informatie wordt toegevoegd aan de header van het event.

34 4.2 Externe communicatie 25 Figuur 4.2: de verschillende stappen nodig voor de serialisatie en deserialisatie van events. Bij een registratie voor een bepaald event type zal de Eventprocessor detecteren dat het socket adres van de zender niet overeenkomt met het lokale adres. Vervolgens wordt een RemoteEvent- EndPoint gecreëerd die een verbinding zal opzetten naar de zender van het registratie event. Tenslotte wordt dit object aan de juiste logische bus gebonden. De deregistratie zal analoog verlopen. Routering van events vanuit de logische bus kan nu transparant gebeuren, de bus moet enkel de berichten doorgeven aan de gebonden proxy s die ofwel lokaal als extern zijn. Dit strikte onderscheid is voor de logische bus niet van belang aangezien de beide types Endpoints dezelfde interface implementeren

35 4.3 Scenario s Scenario s Registratie voor een event type De component creëert een nieuwe context en doet een JNDI lookup naar java:eis/eventbus om een EventbusConnectionFactory object te verkrijgen. Met behulp van de factory kan een nieuwe connectie naar de eventbus worden aangemaakt. Er wordt vervolgens via een nieuw aangemaakte eventfactory een registratie-event gecreëerd. Deze event wordt via de eventbus connectie naar de EventHandler gestuurd die het vervolgens in de buffer van de eventprocessor zal plaatsen. De eventprocessor zal de header van het event analyseren, eventueel een nieuwe logische bus aanmaken en de proxy corresponderende met de zender aan de logische bus binden. Tenslotte wordt een bevestiging van registratie verstuurt via de proxy. Figuur 4.3: interactiediagram voor de registratie van een component voor een event type Verzenden van een event Het event wordt via de eventbus connectie naar de EventHandler gestuurd die het vervolgens in de buffer van de eventprocessor zal plaatsen. De eventprocessor zal de header van het event

36 4.3 Scenario s 27 analyseren, de juiste logische bus die met het event type overeenkomt opzoeken en het bericht doorgeven. De logische bus zal de filtering, buffering en routering afhandelen, een luisteraar moet telkens eerst geactiveerd om pooling van event listeners mogelijk te maken. Vervolgens wordt het event afgeleverd door een asynchrone oproep. Figuur 4.4: interactiediagram die de onderlinge communicatie weergeeft bij het verzenden van een event Opslaan van sessie data Een applicatie component zal via de EventbusConnection sessie gerelateerde data doorgeven aan de StorageAdapter. De adapter zal voor een aan de hand van de sessie identificator en de locatie een entry aanmaken in de datastore waar het object kan worden opgeslagen. Raadplegen, schrijven en verwijderen van data zal steeds gebeuren aan de hand van de sessie-id en de locatie.

37 4.3 Scenario s 28 Figuur 4.5: interactiediagram die de onderlinge communicatie weergeeft bij het opslaan van sessie data.

38 EERSTE DEMO-APPLICATIE: AIR TRAFFIC CONTROL 29 Hoofdstuk 5 Eerste demo-applicatie: Air Traffic Control In een eerste fase van de thesis was het noodzakelijk om een concrete use case op te bouwen om de eerste functionaliteiten aan te tonen. Deze eerste demo-applicatie moest uitvoerbaar zijn in een niet gedistribueerde omgeving. Dit hoofdstuk heeft dus al doel om de eigenlijke applicatie toe te lichten, met de nadruk hoe de verschillende functionaliteiten aan bod kwamen in de applicatie. 5.1 Omschrijving Een luchtverkeersleiding systeem omvat een systeem dat locatiebepaling toelaat van vliegtuigen via een radarsysteem. Daarnaast heeft het de verantwoordelijkheid om het aankomende en vertrekkende verkeer in goede banen te leiden. Om een goed beeld te hebben over de externe factoren die van invloed zijn op de goede werking van de luchthaven, moet het systeem overweg kunnen met invoer van informatie afkomstig van sensoren. In deze applicatie is deze informatie afkomstig van weersensoren. Elk vliegtuig geeft op regelmatige tijdstippen zijn positie door aan het luchtverkeersleiding systeem, die de nieuwe positie zal updaten op het radarscherm. Daarnaast kan de component ook andere informatie meedelen zoals huidige snelheid en traject. Vliegtuigen moeten ook in de mogelijkheid gesteld worden om op te stijgen of te landen, daarvoor moeten ze eerst een aanvraag doen. Deze aanvraag wordt zichtbaar gemaakt aan de operator

39 5.2 Implementatie 30 van het systeem die dan vervolgens een landingsbaan kiest, in het geval van een landingsaanvraag moet ook de gepaste gate worden aangegeven. Aangezien luchtverkeersleiding systeem over een globaal beeld beschikt van de toestand van de luchthaven kunnen ook aanvragen geweigerd worden, zoals bijvoorbeeld in het geval van extreme weersomstandigheden of indien de landingsbanen in gebruik zijn. In zo n geval zal een toestel zijn vlucht moeten verder zetten naar een andere luchthaven of later opnieuw een aanvraag doen. 5.2 Implementatie Een luchtverkeersleiding systeem kan het best gemodelleerd worden aan de hand van een eventgebaseerde applicatie. Ten eerste is er een ontkoppeling nodig tussen de verschillende zenders en het systeem, omdat het aantal event producenten niet op voorhand gekend is. Daarnaast kunnen events op gelijk welk ogenblik toekomen waardoor een asynchrone aanpak vereist is Overzicht Voor de modellering van een vliegtuig werd gekozen voor message-driven beans, omdat deze van nature asynchroon zijn. Aangezien dit type bean geen interne toestand heeft is het bijna ondoenbaar om een vliegtuig als één message-driven bean voor te stellen, aangezien de logica van de bean veel te complex zou worden en omdat het concept van sessies minder duidelijk naar voor zou komen. Daarom werd gekozen om de logica geassocieerd met het gedrag van een vliegtuig te verdelen over verschillende beans. In figuur 5.1 is een overzicht gegeven van de verschillende componenten van de Air Traffic Control applicatie die zich in de applicatie server bevinden. Om het gedrag van de verschillende componenten te beschrijven volgt een korte omschrijving, die als verduidelijking dient voor de verschillende deeltaken. FlightSetupBean: staat in voor het configureren en starten van een vlucht. Deze component zal onder andere de verantwoordelijkheid hebben om vlucht-gerelateerde gegevens in de cache beschikbaar te maken zoals de coördinaten van de luchthavens en de aanvraagzone s. FlightControllerBean: is een voorstelling van een vliegtuig in vlucht en heeft te verantwoordelijkheid om periodiek de nieuwe positie van een vliegtuig te berekenen en door te geven aan het luchtverkeersleiding systeem.

40 5.2 Implementatie 31 ArrivalRequestControllerBean: heeft de verantwoordelijkheid om een landingsaanvraag te doen. Deze component zal actief worden vanaf het toestel zich bevindt in een bepaalde vooraf gespecificeerde zone. ArrivalControllerBean: staat in voor de eigenlijke landingsprocedure zal wachten op een toewijzing van landingsbaan en gate. DepartureRequestControllerBean: heeft de verantwoordelijkheid om een aanvraag tot vertrek te doen en zal wachten op een antwoord van de operator. DepartureControllerBean: is verantwoordelijk voor de opstijgprocedure. TaxiingController: brengt een toestel van het einde van de landingsbaan naar een gate of omgekeerd. Sensoren: generen random data die een voorstelling zijn van de huidige weersomstandigheden. Deze zullen enkel events genereren en zijn de eenvoudigste componenten. We treffen er verschillende aan en deze zullen instaan voor de verzameling van data over temperatuur, luchtdruk, windsnelheid, windrichting en luchtvochtigheid. Het opsplitsen van de logica geeft als resultaat dat elke component een duidelijk omgeschreven taak krijgt, daarnaast wordt de logica van elke message-driven bean relatief eenvoudig. De opsplitsing zorgt ervoor dat de componenten nu meer moeten samenwerken om een vlucht in goede banen te leiden. Aangezien message-driven beans toestandsloos zijn en de events gerelateerd aan een bepaalde vlucht samen horen is het gebruik van sessies ideaal Sessies Aangezien er relatief veel componenten nodig zijn voor het realiseren van een vlucht en het aantal aanwezige toestellen groot kan worden is het best om de informatie die in een event terecht komt, laag te houden om snellere verwerking mogelijk te maken. Dit is nodig omdat we te maken hebben met een quasi real-time systeem en grote vertragingen onaanvaardbaar zouden zijn. Het gebruik van de cache is hier dus ideaal, aangezien die vlot raadpleegbaar zijn voor de event-verwerkende componenten en de events ontlasten van sessie data. We kunnen twee types sessie data onderscheiden: ten eerste is er de gemeenschappelijke data, dit type zal voor alle opgezette sessies dezelfde zijn. Voorbeelden hiervan zijn onder andere de

41 5.2 Implementatie 32 Figuur 5.1: overzicht van de verschillende componenten binnen de applicatie server van de Air Traffic Control applicatie. coördinaten van de luchthavens en de zone s waar een toestel een aanvraag tot landing moet doen. Een tweede type is de specifieke data zoals de naam van het vliegtuig, traject en aantal passagiers. Door de verdeling van de logica zijn de verschillende message-driven beans met elkaar verbonden, als een component zijn taak heeft uitgevoerd heeft hij de controle aan een andere. Deze vorm van chaining is weergegeven in Figuur 5.2 en Figuur Externe communicatie Ondanks dat het de bedoeling niet was dat we te maken zouden hebben met een gedistribueerde omgeving, is dit noodzakelijk omdat er interactie nodig is met de gebruiker. Zo is het gewenst dat een vlucht kan gestart en gestopt worden, ook alle informatie moet grafisch weergegeven worden om enig overzicht te hebben en daarnaast moet de gebruiker kunnen ingrijpen op het controleverloop. De grafische interface zal typisch een standaard Java applicatie en zal actief zijn in een verschillende container dan deze van de J2EE-componenten.

42 5.2 Implementatie 33 Figuur 5.2: traject die de events volgen doorheen de verschillende componenten in het geval van een aankomst scenario. Figuur 5.3: stroom van events volgen door de verschillende componenten in het geval van een aankomst scenario. Om deze interactie met de gebruiker mogelijk te maken werd in een eerste fase hetzelfde principe gebruikt als bij de Virtual Meeting Room applicatie (zie ook Hoofdstuk 1) en werden alle berichten van de client naar een session bean gestuurd die ze vervolgens naar de event bus zal stuurde. Componenten zoals de ArrivalRequestControllerBean en de DepartureRequestControllerBean wachten namelijk op deze door de gebruiker gegenereerde events. Om real-time informatie te verkrijgen over de toestand van een vlucht aan de client-zijde werd JMS gebruikt. Alle componenten zullen dus voortdurend status informatie sturen naar een JMS queue. In een tweede fase is gebruikt gemaakt van een nieuwe functionaliteit van het event model, namelijk de externe communictie. Hierdoor het mogelijk om de verschillende events direct naar de event bus te sturen in plaats van naar een session bean. De resource adapter is nu ook in staat om status informatie direct naar de client te sturen, zodat het gebruik van de Java Message service overbodig wordt.

43 USE CASE: MASSIVELY MULTIPLAYER ONLINE GAMING PLATFORM 34 Hoofdstuk 6 Use case: Massively Multiplayer Online Gaming Platform 6.1 Inleiding Massively Multiplayer Online Games (afgekort: MMOG s), zijn een vorm van computerspellen waarbij spelers met elkaar kunnen interageren in een uitgestrekt virtuele wereld. Deze omgeving wordt typisch uitgespreid over een aantal servers, waarmee de spelers in verbinding staan via een internet verbinding. Alle MMO s maken gebruik van een server-cluster, of multi-tier architectuur om de performantie te verhogen. De use case: Massively Multiplayer Online Gaming Platform is een implementatie van een MMOG, maar met een paar specifieke eigenschappen. Ten eerste wordt de virtuele wereld opgesplitst in kleine regio s, genaamd microcellen, die verdeeld worden over een aantal servers. Daarnaast is het mogelijk om dynamisch cellen te verplaatsen tussen servers om bottlenecks te vermijden en de belasting per server laag gehouden worden. Deze uitwisseling is noodzakelijk omdat de belasting van de betrokken server gerelateerd is aan de populatiedichtheid in een bepaalde regio, de activiteitsgraad van de verschillende regio s zal dus voortdurend in de gaten gehouden moeten worden.indien een server overbelast dreigt te geraken zal er centraal beslist worden om een regio te verplaatsen naar een minder belaste server. Om die manier kan men dus overweg met plots stijgende aantal spelers in een bepaald gedeelte van de wereld. Een belangrijk aspect hierbij is dat een verplaatsingen op gelijk welk ogenblik kan plaatsvinden, gedurende dit proces mag de speler geen hinder ondervinden. Hiermee wordt bedoeld dat tijdens een relocatie

44 6.2 Overzicht 35 nog steeds interactie mogelijk moet zijn met de virtuele wereld. Bovendien mogen er geen onaanvaardbare hoeveelheden vertragingen optreden in de communicatie tussen de clients en de servers. Ook mogen geen events verloren gaan of dubbel toekomen, andere zal de omgeving in een inconsistente toestand terechtkomen. Voor meer gedetailleerde informatie over dit onderwerp wordt verwezen naar de volgende thesissen: Ontwerp en Implementatie van een Massively Multiplayer Online Gaming Platform: Dynamische Loadbalancing in een Celgebaseerde Wereld, door Stein Desmet ([6]) en Ontwerp en Implementatie van een Massively Multiplayer Online Gaming Platform: ontwikkeling van een celgebaseerd wereldmodel, door Stijn De Mulder ([7]). Ook wordt verwezen naar the paper A platform for dynamic microcell redeployment in massively multiplayer online games ([8]); Door de gedistribueerde architectuur en de noodzaak aan een performant communicatiegedeelte, is dit een heel geschikte applicatie om gebruik te maken van het ontwikkelde framework. In dit hoofdstuk wordt een kort overzicht gegeven van de oorspronkelijke architectuur en de aanpassingen die moeten gemaakt worden voor de integratie van het event model. 6.2 Overzicht Het overzicht heeft als doel een beschrijving te geven van de globale opbouw van het Massively Multiplayer Online Gaming platform, vooraleer de gedetailleerde architectuur wordt voorgesteld. Een grafische voorstelling van de applicatie is weergegeven in figuur De LoginServer De LoginServer heeft de verantwoordelijkheid om spelers in en uit te loggen, om dit te kunnen realiseren is het nodig om voor elke speler de laatst gekende locatie in de spelwereld bij te houden. Door de verdeling van de spelomgeving in regio s, die microcellen worden genoemd, is het nodig om ook een tabel bij te houden die informatie bevat over de locatie van de server die dit gedeelte van de wereld bevat De MicrocellManager De MicrocellManager moet zorgen voor de gelijkmatige verdeling van de totale belasting over de verschillende servers. Omdat dit een centrale component is heeft het een globaal overzicht, door

45 6.2 Overzicht 36 Figuur 6.1: globaal overzicht van het Massively Multiplayer Online Gaming Platform. op regelmatige tijdstippen de belasting op te vragen bij de wereld servers kan het aan de hand van deze statistische data bepalen of er microcellen verplaatst moeten worden. Er zal dus indien nodig een commando gegeven worden aan een relatief zwaar belaste server om één of meerdere cellen te verplaatsten naar een andere server met een mindere activiteitsgraad De WereldServer De WereldServer bevat typisch een deel van de totale spelomgeving en moet interactie van een speler met deze wereld mogelijk maken. Hiervoor zijn verschillende componenten aanwezig zoals weergegeven in figuur 6.2, die hier verder worden besproken. De ActorController De ActorController heeft als taak om de communicatie van en naar een speler mogelijk te maken. Hiervoor beschikt het over een tabel met de huidige toestand van een client, of hij in staat is berichten te ontvangen. Ook wordt de locatie van de speler in de wereld bijgehouden, aangezien deze verborgen blijft voor de gebruiker. De locatie indicator wordt telkens toegevoegd aan een bericht om de MicrocellController in staat te stellen de routering uit te voeren.

46 6.3 Architectuur 37 Figuur 6.2: overzicht van de opbouw van de WereldServer. De MicrocellController Deze centrale component van de WereldServer omvat het communicatiegedeelte, de hoofdfunctionaliteit is het routeren van events, daarnaast heeft het ook de taak om microcell-verplaatsingen te coördineren. De MicrocellController zal dus ideaal geschikt zijn voor het verzamelen van statistische data, die een beeld geven van de belasting van de server. De Microcell De virtuele wereld is opgedeeld in regio s waarmee telkens een hoeveelheid data geassocieerd is, het is de microcel die deze data zal bevatten. 6.3 Architectuur In deze sectie worden twee architecturen voorgesteld, een eerste versie maakt gebruik van de Java Message Service om asynchrone communicatie te verkrijgen. De nadelen van deze aanpak werden in Hoofdstuk 1 besproken, daarom wordt een alternatieve oplossing voorgesteld. Deze gewijzigde architectuur maakt echter gebruik van het ontwikkelde event model.

47 6.3 Architectuur Oorspronkelijke opbouw In figuur 6.4 is de originele architectuur in detail weergegeven. Het is niet de bedoeling om deze architectuur in detail te bespreken, aangezien in het kader van deze thesis het communicatie gedeelte van belang is. In figuur 6.3 is een overzicht gegeven hoe de uitwisseling van berichten tussen de verschillende componenten oorspronkelijk verliep. Figuur 6.3: overzicht van de onderlinge communicatie in de oorspronkelijke architectuur. Spelers maken voor de communicatie met de wereld server gebruik van JMS. Clients zullen berichten naar een queue sturen die die vervolgens bij de ActorController terecht komen. Clients ontvangen berichten via een topic met behulp van berichtfilters en berichtselectie. De ActorController zal bij elk ontvangen bericht de routeringstabel raadplegen om zo te weten

48 6.3 Architectuur 39 te komen in welke microcell de speler zich bevindt. De data hiervoor zit vervat in een databank, waarin ook zal bijgehouden worden of de client al dan niet in staat is berichten te ontvangen of te versturen. Vervolgens zal het bericht aan de MicrocellController doorgegeven worden, deze zal instaan voor de routering. De MicrocellController zal in de routingstabel de locatie van de bestemmeling opzoeken, en vervolgens het bericht op de JMS Queue van de correcte server plaatsen. Zelfs als de bestemming lokaal is, dan zal toch gebruik gemaakt worden van de Java Message Service omdat zo een asynchrone aflevering kan verkregen worden. De MicrocellController staat dus in voor alle interne en externe communicatie waarbij telkens gebruik gemaakt wordt van de Java Message Service. Daarnaast is hij ook verantwoordelijk voor het in goede banen leiden van de celverplaatsingen, de logica hiervoor zit in het relocatie gedeelte van de MicrocellController. Wanneer de MicrocellManager het nodig acht een cel-relocatie te starten zal hij aan de 2 betrokken servers de opdracht geven om een relocatie te starten. Daarbij zal de ene server de cell-data moeten verpakken in berichten en versturen naar de andere server. Dit proces kan een tijdje duren, ondertussen mogen events die bestemd zijn voor de cel in verplaatsing niet verloren gaan. Daarom is er de aanwezigheid van de FakeMicrocellBean, deze heeft als taak de berichten te bufferen totdat de cell-data aangekomen is op de doelserver. Aangezien voor het tijdelijk bewaren van de berichten gebruik gemaakt werd van een JMS queue was een bijkomende functionaliteit noodzakelijk. In de oorspronkelijke situatie werden inkomende berichten gewoon verwijderd in de logische bus wanneer er geen luisteraars waren geregistreerd. De motivatie hiervoor was om de complexiteit van de bus te verlagen om zo een betere performantie te bekomen. Om de vereiste functionaliteit toe te voegen werd gekozen om een extra veld toe te voegen aan de event header, die aangeeft of een bericht moet bewaard worden zolang de logische bus bestaat indien er geen geregistreerde luisteraars zijn voor het betreffende event type. De filter in de logische bus haalt die speciale events uit de inkomende berichtenstroom en plaatst ze in een aparte buffer. Bij een registratie van een luisteraar krijgt deze al de events toegestuurd uit die buffer Architectuur met geïntegreerde event bus In Figuur 6.4 is de gewijzigde architectuur in detail weergegeven, na de integratie van de resource adapter.

49 6.3 Architectuur 40 Bij het opstellen van de architectuur werd de opsplitsing van de MicrocellController overgenomen, deze bestond namelijk uit twee delen: het relocatiegedeelte en het communicatiegedeelte. De resource adapter neemt het routeringsgedeelte over, hierdoor verloopt alle uitwisseling via events in plaats van JMS-berichten. Hierdoor wordt een tijdswinst verkregen aangezien het niet nodig is de conversie van events naar JMS-berichten te maken en omgekeerd. Aangezien het communicatiegedeelte gebruik maakte van de routeringstabellen moesten die bewaard blijven, elke component die een event wil versturen naar een client of een microcell moet deze tabel raadplegen om de header juist in te stellen. Hierdoor kan de event bus de routering correct uitvoeren. Voor het relocatiegedeelte werd ook het gebruik van de Java Message Service overbodig, het enige probleem bij dit gedeelte was dat de FakeMicrocellBean om de buffering te realiseren gebruik maakt van een JMS queue. Daarom moest nog een nieuwe functionaliteit toegevoegd worden aan het event model, zo moesten events die bestemd waren voor een logische bus waarbij geen ontvanger geregistreerd was, gebufferd worden. Aangezien dit soms niet voor alle events gewenst is werd een speciaal vlag opgenomen in de header die zal bepalen of deze quality of service al dan niet gewenst is. Voor de communicatie van en naar de client werd oorspronkelijk ook gebruik gemaakt van JMS, maar aangezien de resource adapter toelaat berichten te versturen tussen twee verschillende containers, is het gebruik van de Java Message Service overbodig. Om de communicatie van de MMOG-applicatie naar de client te realiseren wordt dus gebruikt gemaakt van de externe communicatie mogelijkheid van de event bus. Terzijds kan nog opgemerkt worden dat logische bussen als voordeel hebben dat alle spelers van een bepaalde microcell aan dezelfde bus gebonden kunnen worden, dit zorgt ervoor dat er minder filtering nodig is aan de client-zijde.

50 6.3 Architectuur 41 Figuur 6.4: overzicht van de opbouw van de architectuur met gebruik van JMS voor de communicatie.

51 6.3 Architectuur 42 Figuur 6.5: overzicht van de opbouw van de architectuur met gebruik van de event bus voor de communicatie.

52 EVALUATIE VAN HET FRAMEWORK 43 Hoofdstuk 7 Evaluatie van het framework 7.1 Inleiding Dit hoofdstuk heeft als doel de performantie van het ontwikkelde event model te evalueren. Voor een communicatie module zijn performantiematen zoals de responsietijd en de doorvoersnelheid van groot belang, op deze metrieken zullen de testen zich dan ook voornamelijk toespitsen. De gedane testen waren vooral stress testen, met de bedoeling om de bottlenecks en de limieten van het systeem op te sporen. Deze zullen vooral van belang zijn bij het ontwikkelen van realworld applicatie, aangezien al op voorhand kan voorspeld worden wat de impact is van het gebruik het event model op de globale performantiematen. De testen hebben als hoofddoel het eigenlijke event model te evalueren, in een later stadium kan nagegaan worden wat de impact is op de performantie bij de real-world applicaties door het gebruik van de event bus. Wegens tijdsgebrek is er op dit aspect niet dieper ingegaan maar kan wel interessant zijn, omdat in zo n situatie het framework de werkelijke situatie meer kan benaderen dan een reeks testen. Om de verschillende functionaliteiten te evalueren werd gekozen voor de integratie van het event model in het Massively Multiplayer Online Gaming Platform, hiervoor verwijs ik naar de gedetailleerde beschrijving in hoofdstuk 6 De uitvoering van de testen gebeurde op 2 verschillende machines die beschikten over dezelfde hardware configuratie, die bestond uit een Athlon XP (Palomino) 1.4Ghz, met 250Mb geheugen. Op deze testmachines was de volgende software aanwezig:

53 7.2 Evaluatie van de performantiematen 44 Besturingsysteem: Linux ,i386 Java Virtuele Machine: Java HotSpot(TM) Server VM b03, Sun Microsystems Inc. J2EE Applicatie Server: JBoss [Zion] GA Application Server Beide testmachines stonden in verbinding met elkaar door middel van een 100Mbit netwerk. 7.2 Evaluatie van de performantiematen Voor componenten die willen gebruik maken van het ontwikkelde event model kan het nuttig zijn een idee te hebben over hoelang een event erover doet om zijn bestemmeling te bereiken. Daarnaast is ook de verwerkingscapaciteit van groot belang aangezien ze aangegeven met hoeveelheid events per seconde het framework overweg kan. Om een beeld te krijgen van deze performantiematen wordt er gebruik gemaakt van de hardwaretimers van de testmachine. In elk verzonden event wordt het tijdstip opgenomen waarop het op de event bus wordt geplaatst, de ontvanger zal bij ontvangst het verschil bepalen tussen deze tijd en het moment van ontvangst. Aangezien deze vertraging in de grootte orde van enkele milliseconden zal liggen is het noodzakelijk dat de zender en ontvanger zich op dezelfde machine bevinden. Op die manier worden foutieve metingen ten gevolge van niet gesynchroniseerde klokken vermeden. Het is ook van belang dat de eigenlijke testen niet gebeuren op een pas opgestarte machine, er zullen dus eerst events moeten verstuurd worden om de applicatie server en event bus de kans te geven om de vereiste objecten aan te maken en in te laden. Na een zekere tijd zal een stabiele toestand worden bereikt en dan kunnen de testen beginnen Bepalen van de responsietijden en de doorvoer Interne communicatie In een eerste fase is nagegaan welke de vertraging is die de events ondervinden wanneer ze verzonden worden tussen twee componenten die zich in dezelfde container bevinden, dit is schematisch weergegeven in figuur 7.1.

54 7.2 Evaluatie van de performantiematen 45 Figuur 7.1: schematische weergave van de testopstelling voor de interne communicatie. Om variërende belastingen te simuleren werd de zendsnelheid geleidelijk naar hogere waarden gebracht. Dit proces werd herhaalt voor events voor verschillende events groottes, door er telkens een hoeveelheid random data toe te voegen. De resultaten van deze test is weergegeven in figuur 7.2. In deze voorstelling is voor elk event de grootte van de payload aangegeven, in het basisgeval wordt slechts de header verstuurd wat een ondergrens is voor alle andere metingen. Ook werd de impact van een heel groot event nagegaan op de latency. Figuur 7.2: resultaten van de bepaling van de latency bij variërende belastingen in het geval van interne communicatie. Uit de resultaten van de latency bepaling blijkt dat er een correlatie is tussen de event grootte

55 7.2 Evaluatie van de performantiematen 46 en de maat van vertraging, ook het doen stijgen van de zendsnelheden doet deze tijden toenemen. Deze metingen waren te verwachten want de variatie van deze veranderlijken zal direct invloed hebben op de belasting van de event bus en de bijbehorende geïntroduceerde vertragingen. Om een werklast voor de eventbus te creëren is er noodzaak aan timing-informatie van de onderliggende hardware, bij het versturen van een burst van events moet er voortdurend een systeemoproep gedaan worden naar de hardware timer. Dit doet de CPU-belasting wel gemakkelijk met 20% stijgen bij de hogere sendrates. Komt daarbij dat zender, ontvanger en events bus zich bevinden opdezelfde server waardoor de minimum CPU-load 25% en meer bedraagt. Er valt nog op te merken dat er telkens getest werd naar de maximaal haalbare zendsnelheid, hierdoor houden de curves plots op. Om eens na te gaan of het gebruik van een eventbus connectie voldoet aan de vereiste van aynchrone oproepen werd bij het verzenden van een event telkens nagegaan hoe lang de zender op deze instructie blokkeerde. Indien deze blokkering te lang zou duren kan de zender ondertussen geen verdere instructies uitvoeren wat de perfomantie niet ten goede komt. In figuur 7.3 zijn de resultaten grafisch weergegeven, hieruit kunnen we afleiden dat de vertraging geïntroduceerd door het verzenden van een event verwaarloosbaar is, althans in de gevallen van een normaal gebruik want events zijn typisch niet zo groot. Figuur 7.3: worst-case tijden die een zender blokkeert bij het verzenden van een event Externe communicatie Naast de interne communicatie heeft event model ook de verantwoordelijkheid om de componenten in staat te stellen te communiceren indien deze zich in een verschillende container bevinden.

56 7.2 Evaluatie van de performantiematen 47 De volgende metingen hebben als doel de responsietijden te bepalen, een zender zal zijn eigen verstuurde boodschappen ontvangen. Deze aanpak is vereist omdat de zender en ontvanger zich op dezelfde moeten bevinden om geen foutieve metingen te verkrijgen ten gevolge van onnauwkeurig gesynchroniseerde klokken. In figuur 7.4 is de testopstelling schematisch weergegeven. Figuur 7.4: schematische weergave van de testopstelling voor de externe communicatie. Bij de metingen werd een eerste bottleneck gedetecteerd namelijk het netwerk aangezien zender en event bus nu verbonden zijn via een 100 Mbit netwerk zal het netwerk een bovengrens opleggen aan de te behalen sendrates. Deze theoretische zendsnelheden zijn weergegeven in tabel 7.1. Een bijkomende probleem is dat de niet-blokkerende sockets een ongewenst effect hebben, de zender zal blokkeren op de fireevent-instructie totdat de laatste byte op het netwerk is geplaatst. We krijgen dus een niet echt asynchroon gedrag aan de zender zijde, wat nog erger is dat deze tijden onderhevig zijn aan de belasting van het netwerk en dus moeilijk voorspelbaar zijn. Een grote optimalisatie voor dit probleem zou zijn om een paar concepten uit het event model te implementeren aan de zendende component, zoals bijvoorbeeld een vereenvoudigde centrale logische bus die zal instaan voor de verzending. De component moet dan enkel het event afleveren aan de logische bus wat neerkomt op een method call en quasi direct verloopt. Hetzelfde fenomeen treed op bij de communicatie van de event bus naar een externe component, de proxy in een logische bus zal ook tijdelijk blokkeren. het grote voordeel is dat er meerdere logische bussen aanwezig zijn waardoor de intern gerouteerde events geen last zullen ondervinden. Praktisch is de responsie-tijd ten gevolge van de externe communicatie een factor drie groter dan de latency die zal optreden bij de interne communicatie. De tabel tabel 7.1 is nog eens grafisch weergegeven in figuur 7.5

57 7.3 Invloed op de CPU-Load 48 Event grootte Theoretische Worst-case connection call delay Worst-case (KiB) sendrate (events/sec.) (ms) sendrate (events/sec.) 0, , , , , , , , , ,42 4 Tabel 7.1: Vergelijking van de theoretisch haalbare sendrates met de praktisch haalbare rekening houdende met vertragingen geïntroduceerd met het verzenden van een event. 7.3 Invloed op de CPU-Load Het genereren van een bepaalde werklast voor de event bus doet de CPU-belasting van de testmachine sterk stijgen, ondere andere door het frequent oproepen van de systeemklok en het genereren van random data voor de events. Om die reden moet er gekozen worden voor een opstelling zoals in figuur 7.4 is aangegeven. Op die manier doet de event bus enkel dienst als routeringseenheid op een bepaalde machine zonder directe externe invloeden. In de grafische weergave van het verloop van de CPU-load in functie van de tijd bij een event grootte van 5,826 KiB blijkt dat de server belasting niet echt hoog wordt. De eerste hoge piek is te verklaren door het versturen van de warmup events daarna zal de CPU belasting geleidelijk toenemen naarmate meer berichten per seconde worden verstuurd. De pieken zijn te verklaren door de wachttijd na elke eventburst om de ontvanger niet te overbelasten. De zender en ontvanger bevinden zich nu echter op dezelfde machine. 7.4 Conclusie Uit de evaluatie van het event model blijkt dat voor de interne communicatie de event bus heel geschikt is wegens de lage responsietijden en de relatief hoge doorvoer. Het gebruik van de externe communicatie daarentegen is een potentiële bottleneck, niet alleen het netwerk legt een bovengrens op de maximale zendsnelheid maar ook de eigenschap van Java NIO om de zender te laten blokkeren totdat het event effectief is verzonden

58 7.4 Conclusie 49 Figuur 7.5: Grafische voorstelling van de vergelijking tussen de theoretisch haalbare sendrates en de praktisch haalbare, rekening houdende met vertragingen geïntroduceerd met het verzenden van een event.

59 7.4 Conclusie 50 Figuur 7.6: weergave van evolutie van de CPU-Load bij stijgende sendrates.

Inhoudsopgave. Hoofdstuk 1.JMS...2

Inhoudsopgave. Hoofdstuk 1.JMS...2 Inhoudsopgave Hoofdstuk 1.JMS...2 1.1.Inleiding...2 1.2.Messaging architectuur...3 1.2.1.Point to point domein...3 1.2.2.Publish/Subscribe domein...4 1.2.3.Synchrone - asynchrone verwerking...4 1.2.4.De

Nadere informatie

Zelftest Java EE Architectuur

Zelftest Java EE Architectuur Zelftest Java EE Architectuur Document: n1218test.fm 22/03/2012 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INLEIDING BIJ DE ZELFTEST JAVA EE ARCHITECTUUR Nota:

Nadere informatie

Zelftest Java concepten

Zelftest Java concepten Zelftest Java concepten Document: n0838test.fm 22/03/2012 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INLEIDING BIJ DE ZELFTEST JAVA CONCEPTEN Om de voorkennis nodig

Nadere informatie

Session Beans.

Session Beans. Session Beans joost.vennekens@kuleuven.be Prequel: annotaties Nieuw Java feature Gestructureerde manier om extra info toe te voegen aan code (ipv. commentaar) @Author( name = "Joost Vennekens", date =

Nadere informatie

MyDHL+ Van Non-Corporate naar Corporate

MyDHL+ Van Non-Corporate naar Corporate MyDHL+ Van Non-Corporate naar Corporate Van Non-Corporate naar Corporate In MyDHL+ is het mogelijk om meerdere gebruikers aan uw set-up toe te voegen. Wanneer er bijvoorbeeld meerdere collega s van dezelfde

Nadere informatie

General info on using shopping carts with Ingenico epayments

General info on using shopping carts with Ingenico epayments Inhoudsopgave 1. Disclaimer 2. What is a PSPID? 3. What is an API user? How is it different from other users? 4. What is an operation code? And should I choose "Authorisation" or "Sale"? 5. What is an

Nadere informatie

Functionele beschrijving: scannen naar UNIT4 DocumentManager

Functionele beschrijving: scannen naar UNIT4 DocumentManager Functionele beschrijving: scannen naar UNIT4 DocumentManager Algemeen Met de KYOCERA Scannen naar UNIT4 DocumentManager beschikt u over een efficiënte oplossing om uw documenten te scannen naar UNIT4 DocumentManager

Nadere informatie

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces

Software Processen. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1. Het software proces Software Processen Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1 Het software proces Een gestructureerd set van activiteiten nodig om een software systeem te ontwikkelen Specificatie;

Nadere informatie

The OSI Reference Model

The OSI Reference Model Telematica Applicatielaag Hoofdstuk 16, 17 Applicatielaag 4Bevat alle toepassingen die van het netwerk gebruik maken n E-mail n Elektronisch nieuws n WWW n EDI (Electronic Data Interchange) n Napster,

Nadere informatie

Functionele beschrijving: scannen naar Exact Globe.

Functionele beschrijving: scannen naar Exact Globe. Functionele beschrijving: scannen naar Exact Globe. Algemeen Met de KYOCERA scannen naar Exact Globe beschikt u over een efficiënte oplossing om uw documenten te scannen naar Exact Globe. Met deze oplossing

Nadere informatie

Documentatie Distributed Services Enterprise Service Bus

Documentatie Distributed Services Enterprise Service Bus Documentatie Distributed Services Enterprise Service Bus Pleun Willemsen en Walter Ebbers 19 april 2012 v1.0 1 Inhoudsopgave 1 Inleiding 4 1.1 Opdracht................................ 4 2 Analyse 5 3 Ontwikkelomgeving

Nadere informatie

Introductie in flowcharts

Introductie in flowcharts Introductie in flowcharts Flow Charts Een flow chart kan gebruikt worden om: Processen definieren en analyseren. Een beeld vormen van een proces voor analyse, discussie of communicatie. Het definieren,

Nadere informatie

Reliable Messaging. Marc de Graauw

Reliable Messaging. Marc de Graauw Reliable Messaging Marc de Graauw Betrouwbaar transport Netwerk is niet betrouwbaar Het is niet te garanderen dat twee partijen beide 100% zeker weten dat communicatie geslaagd is Het is wel te garanderen

Nadere informatie

Non Diffuse Point Based Global Illumination

Non Diffuse Point Based Global Illumination Non Diffuse Point Based Global Illumination Karsten Daemen Thesis voorgedragen tot het behalen van de graad van Master of Science in de ingenieurswetenschappen: computerwetenschappen Promotor: Prof. dr.

Nadere informatie

REST Adapter in SAP PI/PO voor REST-based Web Services

REST Adapter in SAP PI/PO voor REST-based Web Services REST Adapter in SAP PI/PO voor REST-based Web Services Inleiding Eindelijk! SAP heeft officieel de REST Adapter voor SAP PI/PO uitgebracht. Deze is beschikbaar vanaf SAP NetWeaver 7.3 EHP1 SP14 of SAP

Nadere informatie

FOR DUTCH STUDENTS! ENGLISH VERSION NEXT PAGE. Toets Inleiding Kansrekening 1 8 februari 2010

FOR DUTCH STUDENTS! ENGLISH VERSION NEXT PAGE. Toets Inleiding Kansrekening 1 8 februari 2010 FOR DUTCH STUDENTS! ENGLISH VERSION NEXT PAGE Toets Inleiding Kansrekening 1 8 februari 2010 Voeg aan het antwoord van een opgave altijd het bewijs, de berekening of de argumentatie toe. Als je een onderdeel

Nadere informatie

Settings for the C100BRS4 MAC Address Spoofing with cable Internet.

Settings for the C100BRS4 MAC Address Spoofing with cable Internet. Settings for the C100BRS4 MAC Address Spoofing with cable Internet. General: Please use the latest firmware for the router. The firmware is available on http://www.conceptronic.net! Use Firmware version

Nadere informatie

Technische architectuur Beschrijving

Technische architectuur Beschrijving A gemeente Eindhoven Technische architectuur Beschrijving Specificatiecriteria Versie 1.1 A. van Loenen Technisch Beleidsadviseur B&E 21-Sep-2011 avl/fd11027578 Colofon Uitgave Gemeente Eindhoven Realisatie

Nadere informatie

ANGSTSTOORNISSEN EN HYPOCHONDRIE: DIAGNOSTIEK EN BEHANDELING (DUTCH EDITION) FROM BOHN STAFLEU VAN LOGHUM

ANGSTSTOORNISSEN EN HYPOCHONDRIE: DIAGNOSTIEK EN BEHANDELING (DUTCH EDITION) FROM BOHN STAFLEU VAN LOGHUM Read Online and Download Ebook ANGSTSTOORNISSEN EN HYPOCHONDRIE: DIAGNOSTIEK EN BEHANDELING (DUTCH EDITION) FROM BOHN STAFLEU VAN LOGHUM DOWNLOAD EBOOK : ANGSTSTOORNISSEN EN HYPOCHONDRIE: DIAGNOSTIEK STAFLEU

Nadere informatie

INFITT01 - Internettechnologie WEEK 8

INFITT01 - Internettechnologie WEEK 8 INFITT01 - Internettechnologie WEEK 8 Programma Databases (JDBC, JNDI, ORM, JPA) MVC & Spring/Struts EJB Databases Veel web applicaties moeten informatie over langere tijd op kunnen slaan. Een voor de

Nadere informatie

Functionele beschrijving: Scannen naar AFAS Profit.

Functionele beschrijving: Scannen naar AFAS Profit. Functionele beschrijving: Scannen naar AFAS Profit. Algemeen Met de Kyocera Scannen naar AFAS Profit beschikt u over een efficiënte oplossing om uw documenten te scannen naar AFAS Profit. Met deze oplossing

Nadere informatie

Risk & Requirements Based Testing

Risk & Requirements Based Testing Risk & Requirements Based Testing Tycho Schmidt PreSales Consultant, HP 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice Agenda Introductie

Nadere informatie

Aanbesteding implementatie, beheer en onderhoud van Microsoft Dynamics 365 for Operations. Bijlage 5: Beschrijving toekomstige ESB

Aanbesteding implementatie, beheer en onderhoud van Microsoft Dynamics 365 for Operations. Bijlage 5: Beschrijving toekomstige ESB Aanbesteding implementatie, beheer en onderhoud van Microsoft Dynamics 365 for Operations Bijlage 5: Beschrijving toekomstige ESB Versie: v1.0 Datum: 17-3-2017 Inhoudsopgave 1. 2. 3. 4. Inleiding 3 Huidige

Nadere informatie

Enterprisearchitectuur

Enterprisearchitectuur Les 2 Enterprisearchitectuur Enterprisearchitectuur ITarchitectuur Servicegeoriënteerde architectuur Conceptuele basis Organisatiebrede scope Gericht op strategie en communicatie Individuele systeemscope

Nadere informatie

JBoss Administration. Inhoud

JBoss Administration. Inhoud JBoss Administration In de cursus JBoss Administration leren de deelnemers de JBoss-applicatieserver te installeren, in te richten en te configureren. Aan de orde komen de JBoss-architectuur, de installatie

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren November 2014 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 1 Inhoudstafel 1 Introductie 3 1.1

Nadere informatie

1.7 Ontleding van het eerste programma... 14

1.7 Ontleding van het eerste programma... 14 Inhoudsopgave 1 Inleiding 1 1.1 Wat kan je met Java doen?..................... 1 1.2 Over Java............................... 3 1.3 Gebruik van dit boek......................... 5 1.4 Installatie...............................

Nadere informatie

Continuous testing in DevOps met Test Automation

Continuous testing in DevOps met Test Automation Continuous ing in met Continuous testing in met Marco Jansen van Doorn Tool Consultant 1 is a software development method that emphasizes communication, collaboration, integration, automation, and measurement

Nadere informatie

Technisch Ontwerp W e b s i t e W O S I

Technisch Ontwerp W e b s i t e W O S I Technisch Ontwerp W e b s i t e W O S I WOSI Ruud Jungbacker en Michael de Vries - Technisch ontwerp Website Document historie Versie(s) Versie Datum Status Omschrijving / wijzigingen 0.1 20 nov 2008 Concept

Nadere informatie

My Benefits My Choice applicatie. Registratie & inlogprocedure

My Benefits My Choice applicatie. Registratie & inlogprocedure My Benefits My Choice applicatie Registratie & inlogprocedure Welkom bij de My Benefits My Choice applicatie Gezien de applicatie gebruik maakt van uw persoonlijke gegevens en salarisinformatie wordt de

Nadere informatie

The Leading Open Source MDA Platform. openmdx 2 Overview. June

The Leading Open Source MDA Platform. openmdx 2 Overview. June openmdx 2 Overview June 2008 openmdx 2 New Features Mappings / Bindings MOF CCI2 MOF JMI2 MOF JDO2 Providers / Architecture JDO PersistenceManager architecture Plugin architecture Gateway Persistence Lightweight

Nadere informatie

Software Design Document

Software Design Document Software Design Document Mathieu Reymond, Arno Moonens December 2014 Inhoudsopgave 1 Versiegeschiedenis 2 2 Definities 3 3 Introductie 4 3.1 Doel en Scope............................. 4 4 Logica 5 4.1

Nadere informatie

Functionele beschrijving: scannen naar UNIT4 Cura Documentmanagement.

Functionele beschrijving: scannen naar UNIT4 Cura Documentmanagement. Functionele beschrijving: scannen naar UNIT4 Cura Documentmanagement. Algemeen Met KYOCERA scannen naar UNIT4 Cura Documentmanagement beschikt u over een efficiënte oplossing om uw documenten te scannen

Nadere informatie

WFS 3.0 De geo-api van de toekomst. Linda van den Brink, Geonovum 13 februari #DataToBuildOn

WFS 3.0 De geo-api van de toekomst. Linda van den Brink, Geonovum 13 februari #DataToBuildOn WFS 3.0 De geo-api van de toekomst Linda van den Brink, Geonovum 13 februari 2019 @brinkwoman #DataToBuildOn Eerste versie uit 2002 https://nl.wikipedia.org/wiki/web_feature_service Web Feature Service

Nadere informatie

BRP-BZM Use Case Realisations Guidelines

BRP-BZM Use Case Realisations Guidelines BRP-BZM Use Case Realisations Guidelines Versie 2.0 02-09-2011 Definitief Versiehistorie Datum Versie Auteur 23-12-2010 0.1 Eerste versie R.F. Schaaf 04-01-2011 1.0 Feedback verwerkt R. Schaaf en D. Geluk

Nadere informatie

API...1 Identificatie...1 Opties...2 Acties...3 Webserver...6 Heartbeat...6 Buffer groottes...8

API...1 Identificatie...1 Opties...2 Acties...3 Webserver...6 Heartbeat...6 Buffer groottes...8 API API...1 Identificatie...1 Opties...2 Acties...3 Webserver...6 Heartbeat...6 Buffer groottes...8 Identificatie Alle programma's communiceren met elkaar door gebruik te maken van JSON objecten. Het normale

Nadere informatie

Betekent SOA het einde van BI?

Betekent SOA het einde van BI? Betekent SOA het einde van BI? Martin.vanden.Berg@sogeti.nl 18 september 2007 Agenda Wat is SOA? Wat is BI? Wat is de impact van SOA op BI? Sogeti Nederland B.V. 1 Agenda Wat is SOA? Wat is BI? Wat is

Nadere informatie

Weblogic 10.3 vs IAS 10.1.3

Weblogic 10.3 vs IAS 10.1.3 Vision ~ Knowledge ~ Results Weblogic 10.3 vs IAS 10.1.3 OGh Fusion Middleware/ SOA Dag 19 Mei 2010, Het Oude Tolhuys Edwin Biemond email edwin.biemond@whitehorses.nl Web http://blogs.whitehorses.nl/,

Nadere informatie

DATAMANAGEMENT MET OPEN SOURCE

DATAMANAGEMENT MET OPEN SOURCE DATAMANAGEMENT MET OPEN SOURCE Bart Hansen Solution Architect bij TUI Jacob Hoeflaken Technology Leader bij Axians 1 WIE ZIJN WIJ? Jacob Hoeflaken Technology Leader Axians Integrated Solutions Bart Hansen

Nadere informatie

VOORKOM CONFIGURATIE CONFLICTEN EN ACTIVERINGSISSUES TUSSEN SAP PI KLASSIEKE EN JAVA-ONLY SCENARIO S

VOORKOM CONFIGURATIE CONFLICTEN EN ACTIVERINGSISSUES TUSSEN SAP PI KLASSIEKE EN JAVA-ONLY SCENARIO S VOORKOM CONFIGURATIE CONFLICTEN EN ACTIVERINGSISSUES TUSSEN SAP PI KLASSIEKE EN JAVA-ONLY SCENARIO S Door Roberto Viana-Blanco / Enterprise Integration Architect @Rojo Consultancy INTEGRATED CONFIGURATION

Nadere informatie

Multi user Setup. Firebird database op een windows (server)

Multi user Setup. Firebird database op een windows (server) Multi user Setup Firebird database op een windows (server) Inhoudsopgave osfinancials multi user setup...3 Installeeren van de firebird database...3 Testing van de connectie met FlameRobin...5 Instellen

Nadere informatie

De reden dat providers (KPN) voor Routed IPTV kiezen is vanwege het ondersteunen van bepaalde diensten zoals Netflix op de SetupBox.

De reden dat providers (KPN) voor Routed IPTV kiezen is vanwege het ondersteunen van bepaalde diensten zoals Netflix op de SetupBox. Routed IPTV Inhoudsopgave Routed IPTV... 3 Routed IPTV WAN configuratie... 4 Routed IPTV LAN configuratie... 8 IGMP Proxy & IGMP Snooping... 11 Hardware Acceleration... 12 Load Balance / Route Policy...

Nadere informatie

1 Inleiding probleembeschrijving

1 Inleiding probleembeschrijving Bas Weelinck (5985498), Merlijn Wajer (5948940), Koos van Strien (5783437) 18 mei 2010 1 Inleiding probleembeschrijving Volgens de specificaties gegeven in het opdrachtdocument moet een gedistribueerde

Nadere informatie

Creatief met Claim Check VNSG Tips & Tricks juni 2017

Creatief met Claim Check VNSG Tips & Tricks juni 2017 1 Creatief met Claim Check VNSG Tips & Tricks juni 2017 Auteur: Wouter Luijten Datum: 29-05-2017 2 Inleiding Het Claim-Check pattern is een pattern dat geïmplementeerd kan worden in SAP Netweaver PO ten

Nadere informatie

L.Net s88sd16-n aansluitingen en programmering.

L.Net s88sd16-n aansluitingen en programmering. De L.Net s88sd16-n wordt via één van de L.Net aansluitingen aangesloten op de LocoNet aansluiting van de centrale, bij een Intellibox of Twin-Center is dat de LocoNet-T aansluiting. L.Net s88sd16-n aansluitingen

Nadere informatie

ONZE PARTNERS GROEIEN.

ONZE PARTNERS GROEIEN. WE WILLEN DE BESTE ZIJN. SAMEN MET ONZE PARTNERS EN KLANTEN NAAR EEN NEXT LEVEL GROEIEN. Paul Ramakers, Exact DRIVEN BY AMBITION WOENSDAG 11 MEI INN STYLE, MAARSSEN EXACT LIGHTWEIGHT INTEGRATION SERVER

Nadere informatie

Informatiearchitectuur

Informatiearchitectuur Informatiearchitectuur Onderwerpen Waarom is architectuur (nu) zo belangrijk? Wat is informatiearchitectuur? Ontwikkelingen in de tijd Structuur applicaties Applicatie-integratie Webservices Praktijkvoorbeeld

Nadere informatie

SSL VPN. In deze handleiding zullen wij onderstaande SSL mogelijkheden aan u uitleggen. - SSL VPN account/groep creëren.

SSL VPN. In deze handleiding zullen wij onderstaande SSL mogelijkheden aan u uitleggen. - SSL VPN account/groep creëren. SSL VPN SSL VPN SSL VPN is een web based versie van VPN waarbij er geen VPN client software nodig is. Het wordt niet beperkt door netwerkomgevingen en is zeer eenvoudig te configureren. SSL staat voor

Nadere informatie

Organiseer uw verschillende SOAP services in één scenario

Organiseer uw verschillende SOAP services in één scenario 1 Organiseer uw verschillende SOAP services in één scenario Wouter Luijten wouterluijten@creetion.com 2 Introductie Tijdens de implementatie van een proces heeft u vaak te maken met een veelvoud aan services.

Nadere informatie

MyDHL+ Uw accountnummer(s) delen

MyDHL+ Uw accountnummer(s) delen MyDHL+ Uw accountnummer(s) delen met anderen Uw accountnummer(s) delen met anderen in MyDHL+ In MyDHL+ is het mogelijk om uw accountnummer(s) te delen met anderen om op uw accountnummer een zending te

Nadere informatie

Ius Commune Training Programme 2015-2016 Amsterdam Masterclass 16 June 2016

Ius Commune Training Programme 2015-2016 Amsterdam Masterclass 16 June 2016 www.iuscommune.eu Dear Ius Commune PhD researchers, You are kindly invited to attend the Ius Commune Amsterdam Masterclass for PhD researchers, which will take place on Thursday 16 June 2016. During this

Nadere informatie

LDAP Server on Yeastar MyPBX & tiptel 31xx/32xx series

LDAP Server on Yeastar MyPBX & tiptel 31xx/32xx series LDAP Server on Yeastar MyPBX & tiptel 31xx/32xx series Tiptel b.v. Camerastraat 2 1322 BC Almere tel.: +31-36-5366650 fax.: +31-36-5367881 info@tiptel.nl Versie 1.2.0 (09022016) Nederlands: De LDAP server

Nadere informatie

Security Les 1 Leerling: Marno Brink Klas: 41B Docent: Meneer Vagevuur

Security Les 1 Leerling: Marno Brink Klas: 41B Docent: Meneer Vagevuur Security Les 1 Leerling: Klas: Docent: Marno Brink 41B Meneer Vagevuur Voorwoord: In dit document gaan we beginnen met de eerste security les we moeten via http://www.politiebronnen.nl moeten we de IP

Nadere informatie

Hoe met Windows 8 te verbinden met NDI Remote Office (NDIRO) How to connect With Windows 8 to NDI Remote Office (NDIRO

Hoe met Windows 8 te verbinden met NDI Remote Office (NDIRO) How to connect With Windows 8 to NDI Remote Office (NDIRO Handleiding/Manual Hoe met Windows 8 te verbinden met NDI Remote Office (NDIRO) How to connect With Windows 8 to NDI Remote Office (NDIRO Inhoudsopgave / Table of Contents 1 Verbinden met het gebruik van

Nadere informatie

MyDHL+ ProView activeren in MyDHL+

MyDHL+ ProView activeren in MyDHL+ MyDHL+ ProView activeren in MyDHL+ ProView activeren in MyDHL+ In MyDHL+ is het mogelijk om van uw zendingen, die op uw accountnummer zijn aangemaakt, de status te zien. Daarnaast is het ook mogelijk om

Nadere informatie

Pesten onder Leerlingen met Autisme Spectrum Stoornissen op de Middelbare School: de Participantrollen en het Verband met de Theory of Mind.

Pesten onder Leerlingen met Autisme Spectrum Stoornissen op de Middelbare School: de Participantrollen en het Verband met de Theory of Mind. Pesten onder Leerlingen met Autisme Spectrum Stoornissen op de Middelbare School: de Participantrollen en het Verband met de Theory of Mind. Bullying among Students with Autism Spectrum Disorders in Secondary

Nadere informatie

Zelftest OOAD/UML. Document: N0767Test.fm 30/08/2010. ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium

Zelftest OOAD/UML. Document: N0767Test.fm 30/08/2010. ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium Zelftest OOAD/UML Document: N0767Test.fm 30/08/2010 ABIS Training & Consulting P.O. Box 220 B-3000 Leuven Belgium TRAINING & CONSULTING INTRODUCTIE Deze test is gebaseerd op de inhoud van onze cursus OO

Nadere informatie

Software Design Document

Software Design Document Software Design Document PEN: Paper Exchange Network Software Engineering groep 1 (se1-1415) Academiejaar 2014-2015 Jens Nevens - Sander Lenaerts - Nassim Versbraegen Jo De Neve - Jasper Bevernage Versie

Nadere informatie

The genesis of the game is unclear. Possibly, dominoes originates from China and the stones were brought here by Marco Polo, but this is uncertain.

The genesis of the game is unclear. Possibly, dominoes originates from China and the stones were brought here by Marco Polo, but this is uncertain. Domino tiles Dominoes is a game played with rectangular domino 'tiles'. Today the tiles are often made of plastic or wood, but in the past, they were made of real stone or ivory. They have a rectangle

Nadere informatie

Ius Commune Training Programme Amsterdam Masterclass 15 June 2018

Ius Commune Training Programme Amsterdam Masterclass 15 June 2018 www.iuscommune.eu Dear Ius Commune PhD researchers, You are kindly invited to participate in the Ius Commune Amsterdam Masterclass for PhD researchers, which will take place on Friday, 15 June 2018. This

Nadere informatie

J2EE/.NET en de rol Applicatie Architectuur

J2EE/.NET en de rol Applicatie Architectuur J2EE/.NET en de rol Applicatie Architectuur Edwin van Dillen evdillen@sogyo.nl 2003 Sogyo Information Engineering 1 Sogyo information engineering! IT Innovator sinds 1995! Klanten: ABN AMRO, Rabobank,

Nadere informatie

Marktscan Digikoppeling 2017

Marktscan Digikoppeling 2017 Testrapport Marktscan Digikoppeling 2017 Versie: 1.0 Datum: 18-6-2015 Auteur: egem Datum : 2 juni 2017 Versie : 1.0 Inhoudsopgave 1. Inleiding... 2 2. Managementsamenvatting... 3 3. Testopzet... 4 3.1

Nadere informatie

GETTING THE BEST OUT OF YOUR SOURCE CODE MODERNISEREN MET UNIFACE

GETTING THE BEST OUT OF YOUR SOURCE CODE MODERNISEREN MET UNIFACE GETTING THE BEST OUT OF YOUR SOURCE CODE MODERNISEREN MET UNIFACE 2 OMNEXT IN HET KORT Broncode als bron van informatie Gevestigd in NL, UK en USA Kennis van meer dan 40 diverse technologieën Verschillende

Nadere informatie

Aim of this presentation. Give inside information about our commercial comparison website and our role in the Dutch and Spanish energy market

Aim of this presentation. Give inside information about our commercial comparison website and our role in the Dutch and Spanish energy market Aim of this presentation Give inside information about our commercial comparison website and our role in the Dutch and Spanish energy market Energieleveranciers.nl (Energysuppliers.nl) Founded in 2004

Nadere informatie

Functionele beschrijving: scannen naar Trivium FORTUNA.

Functionele beschrijving: scannen naar Trivium FORTUNA. Functionele beschrijving: scannen naar Trivium FORTUNA. Algemeen Met KYOCERA scannen naar Trivium FORTUNA beschikt u over een efficiënte oplossing om uw documenten te scannen naar Trivium FORTUNA. Met

Nadere informatie

DALISOFT. 33. Configuring DALI ballasts with the TDS20620V2 DALI Tool. Connect the TDS20620V2. Start DALISOFT

DALISOFT. 33. Configuring DALI ballasts with the TDS20620V2 DALI Tool. Connect the TDS20620V2. Start DALISOFT TELETASK Handbook Multiple DoIP Central units DALISOFT 33. Configuring DALI ballasts with the TDS20620V2 DALI Tool Connect the TDS20620V2 If there is a TDS13620 connected to the DALI-bus, remove it first.

Nadere informatie

Handleiding Zuludesk Parent

Handleiding Zuludesk Parent Handleiding Zuludesk Parent Handleiding Zuludesk Parent Met Zuludesk Parent kunt u buiten schooltijden de ipad van uw kind beheren. Hieronder vind u een korte handleiding met de mogelijkheden. Gebruik

Nadere informatie

Classification of triangles

Classification of triangles Classification of triangles A triangle is a geometrical shape that is formed when 3 non-collinear points are joined. The joining line segments are the sides of the triangle. The angles in between the sides

Nadere informatie

IC Mail Gateway Gebruikershandleiding

IC Mail Gateway Gebruikershandleiding IC Mail Gateway Gebruikershandleiding Versiebeheer Versie Datum Naam Wijziging 1.0 27 oktober 2008 ICA Initieel document 1.1 18 juni 2010 ICA Document geheel herzien 2.0 30 januari 2013 ICA Aanpassing

Nadere informatie

SSL VPN. In deze handleiding zullen wij onderstaande SSL mogelijkheden aan u uitleggen. - SSL VPN account/groep creëren.

SSL VPN. In deze handleiding zullen wij onderstaande SSL mogelijkheden aan u uitleggen. - SSL VPN account/groep creëren. SSL VPN SSL VPN SSL VPN is een web based versie van VPN waarbij er geen VPN client software nodig is. Het wordt niet beperkt door netwerkomgevingen en is zeer eenvoudig te configureren. SSL staat voor

Nadere informatie

Together we deliver. Partner Logistics Together we deliver

Together we deliver. Partner Logistics Together we deliver Together we deliver Together we deliver 8 March, 2016 1 Agenda Introductie Waarom koos voor deze standaard WMS-oplossing? Beperkingen standaard WMS oplossing Implementatie in 3 maanden Standaard WMS in

Nadere informatie

Stichting NIOC en de NIOC kennisbank

Stichting NIOC en de NIOC kennisbank Stichting NIOC Stichting NIOC en de NIOC kennisbank Stichting NIOC (www.nioc.nl) stelt zich conform zijn statuten tot doel: het realiseren van congressen over informatica onderwijs en voorts al hetgeen

Nadere informatie

open standaard hypertext markup language internetprotocol transmission control protocol internet relay chat office open xml

open standaard hypertext markup language internetprotocol transmission control protocol internet relay chat office open xml DOWNLOAD OR READ : OPEN STANDAARD HYPERTEXT MARKUP LANGUAGE INTERNETPROTOCOL TRANSMISSION CONTROL PROTOCOL INTERNET RELAY CHAT OFFICE OPEN XML PDF EBOOK EPUB MOBI Page 1 Page 2 relay chat office open xml

Nadere informatie

Enabling Enterprise Mobility. Chantal Smelik csmelik@microsoft.com

Enabling Enterprise Mobility. Chantal Smelik csmelik@microsoft.com Enabling Enterprise Mobility Chantal Smelik csmelik@microsoft.com Nieuwe werkplek & digitaal toetsen Hanzehogeschool Groningen Agenda 1. Introductie Chantal Smelik Microsoft Maaike van Mourik project

Nadere informatie

Handleiding Installatie ADS

Handleiding Installatie ADS Handleiding Installatie ADS Versie: 1.0 Versiedatum: 19-03-2014 Inleiding Deze handleiding helpt u met de installatie van Advantage Database Server. Zorg ervoor dat u bij de aanvang van de installatie

Nadere informatie

TOEGANG VOOR NL / ENTRANCE FOR DUTCH : https://www.stofs.co.uk/en/register/live/?regu lator=c&camp=24759

TOEGANG VOOR NL / ENTRANCE FOR DUTCH : https://www.stofs.co.uk/en/register/live/?regu lator=c&camp=24759 DISCLAIMER : 1. Het is een risicovolle belegging / It is an investment with risc. 2. Gebruik enkel geld dat u kan missen / Only invest money you can miss. 3. Gebruik de juiste procedure / Use the correct

Nadere informatie

L.Net s88sd16-n aansluitingen en programmering.

L.Net s88sd16-n aansluitingen en programmering. De L.Net s88sd16-n wordt via één van de L.Net aansluitingen aangesloten op de LocoNet aansluiting van de centrale, bij een Intellibox of Twin-Center is dat de LocoNet-T aansluiting. L.Net s88sd16-n aansluitingen

Nadere informatie

m.b.v. digitale certificaten en PKI Versie: mei 2002 Beknopte Dienstbeschrijving beveiligen van VPN s

m.b.v. digitale certificaten en PKI Versie: mei 2002 Beknopte Dienstbeschrijving beveiligen van VPN s Beknopte dienstbeschrijving Beveiligen van VPN's m.b.v. digitale certificaten en PKI Document: Versie: mei 2002 Beknopte Dienstbeschrijving beveiligen van VPN s Inhoudsopgave 1. Inleiding 2 2. Snel te

Nadere informatie

Functionele beschrijving: Scannen naar Pro Management

Functionele beschrijving: Scannen naar Pro Management Functionele beschrijving: Scannen naar Pro Management Algemeen Met de KYOCERA scannen naar oplossing beschikt u over een efficiënte oplossing om uw documenten te scannen naar Pro Management. Met deze oplossing

Nadere informatie

Risico s van Technologisch Succes in digitale transformatie S T R A T E G I C A D V I S O R

Risico s van Technologisch Succes in digitale transformatie S T R A T E G I C A D V I S O R Risico s van Technologisch Succes in digitale transformatie 2e Risk Event 2019 11 april 2019 The S T R A T E G I C A D V I S O R Ymanagement school of the autonomous University of Antwerp 2 Prof. dr. Hans

Nadere informatie

Master Class Java Accelerated

Master Class Java Accelerated Stormpunt itrack vakmanschap door leren, ervaren en delen Master Class Java Accelerated Datum: 08-01-2018 StormPunt itrack 2018 i INHOUDSOPGAVE 1. Master Class Java Accelerated 1 1.1 Introductie 1 1.2

Nadere informatie

WWW.EMINENT-ONLINE.COM

WWW.EMINENT-ONLINE.COM WWW.EMINENT-OINE.COM HNDLEIDING USERS MNUL EM1016 HNDLEIDING EM1016 USB NR SERIEEL CONVERTER INHOUDSOPGVE: PGIN 1.0 Introductie.... 2 1.1 Functies en kenmerken.... 2 1.2 Inhoud van de verpakking.... 2

Nadere informatie

SAMPLE 11 = + 11 = + + Exploring Combinations of Ten + + = = + + = + = = + = = 11. Step Up. Step Ahead

SAMPLE 11 = + 11 = + + Exploring Combinations of Ten + + = = + + = + = = + = = 11. Step Up. Step Ahead 7.1 Exploring Combinations of Ten Look at these cubes. 2. Color some of the cubes to make three parts. Then write a matching sentence. 10 What addition sentence matches the picture? How else could you

Nadere informatie

OUTDOOR HD BULLET IP CAMERA PRODUCT MANUAL

OUTDOOR HD BULLET IP CAMERA PRODUCT MANUAL OUTDOOR HD BULLET IP CAMERA PRODUCT MANUAL GB - NL GB PARTS & FUNCTIONS 1. 7. ---- 3. ---- 4. ---------- 6. 5. 2. ---- 1. Outdoor IP camera unit 2. Antenna 3. Mounting bracket 4. Network connection 5.

Nadere informatie

Software Test Plan. Yannick Verschueren

Software Test Plan. Yannick Verschueren Software Test Plan Yannick Verschueren Maart 2015 Document geschiedenis Versie Datum Auteur/co-auteur Beschrijving 1 November 2014 Yannick Verschueren Eerste versie 2 December 2014 Yannick Verschueren

Nadere informatie

Ius Commune Training Programme Amsterdam Masterclass 22 June 2017

Ius Commune Training Programme Amsterdam Masterclass 22 June 2017 www.iuscommune.eu INVITATION Ius Commune Masterclass 22 June 2017 Amsterdam Dear Ius Commune PhD researchers, You are kindly invited to participate in the Ius Commune Amsterdam Masterclass for PhD researchers,

Nadere informatie

Functionele beschrijving: Scannen naar Fidura-oplossing

Functionele beschrijving: Scannen naar Fidura-oplossing Functionele beschrijving: Scannen naar Fidura-oplossing Algemeen Met KYOCERA scannen naar Fidura beschikt u over een efficiënte oplossing om uw documenten te scannen naar Fidura. Met deze oplossing kunnen

Nadere informatie

Process & IT: eerst KIEZEN maakt het DOEN daarna zoveel makkelijker

Process & IT: eerst KIEZEN maakt het DOEN daarna zoveel makkelijker Process & IT: eerst KIEZEN maakt het DOEN daarna zoveel makkelijker Wim Tindemans Manager Business Applications Business and Automation Solutions Egemin NV Agenda Probleemstelling Tegenstelling tussen

Nadere informatie

COGNITIEVE DISSONANTIE EN ROKERS COGNITIVE DISSONANCE AND SMOKERS

COGNITIEVE DISSONANTIE EN ROKERS COGNITIVE DISSONANCE AND SMOKERS COGNITIEVE DISSONANTIE EN ROKERS Gezondheidsgedrag als compensatie voor de schadelijke gevolgen van roken COGNITIVE DISSONANCE AND SMOKERS Health behaviour as compensation for the harmful effects of smoking

Nadere informatie

Applicatie-Architecturen

Applicatie-Architecturen Applicatie-Architecturen joost.vennekens@kuleuven.be http://www.cs.kuleuven.be/~joost/dn/ Programmeren in het echt! Programming in the large Deel van groter geheel! In teamverband! Open opdracht!! Inhoud:

Nadere informatie

Vergelijking Sun certificering voor Enterprise architect voor J2EE en het CPP Gecertificeerd softwarearchitect van de Open Universiteit Nederland

Vergelijking Sun certificering voor Enterprise architect voor J2EE en het CPP Gecertificeerd softwarearchitect van de Open Universiteit Nederland Vergelijking Sun certificering voor Enterprise architect voor J2EE en het CPP Gecertificeerd softwarearchitect van de Open Universiteit Nederland Inleiding Het Certified Professional Program Gecertificeerd

Nadere informatie

Technische nota AbiFire5 Rapporten maken via ODBC

Technische nota AbiFire5 Rapporten maken via ODBC Technische nota AbiFire5 Rapporten maken via ODBC Laatste revisie: 29 juli 2009 Inhoudsopgave Inleiding... 2 1 Installatie ODBC driver... 2 2 Systeeminstellingen in AbiFire5... 3 2.1 Aanmaken extern profiel...

Nadere informatie

Model driven Application Delivery

Model driven Application Delivery Model driven Application Delivery Fast. Flexible. Future-proof. How Agis streamlines health procurement using Mendix Model driven Application Platform Mendix in a nutshell Mendix delivers the tools and

Nadere informatie

Het gebruik van OSB ebms contracten in complexe infrastructuren

Het gebruik van OSB ebms contracten in complexe infrastructuren Inleiding Het gebruik van OSB ebms contracten in complexe infrastructuren Whitepaper Ernst Jan van Nigtevecht Maart 2009 Contracten die gepubliceerd worden voor een OSB ebms service hebben tot doel om

Nadere informatie

Stephanie van Dijck De integrale aanpak maakt complexiteit hanteerbaar

Stephanie van Dijck De integrale aanpak maakt complexiteit hanteerbaar Titel, samenvatting en biografie Stephanie van Dijck De integrale aanpak maakt complexiteit hanteerbaar Samenvatting: Nieuwe projecten nemen toe in complexiteit: afhankelijkheden tussen software componenten,

Nadere informatie

OUTDOOR HD DOME IP CAMERA PRODUCT MANUAL GB - NL

OUTDOOR HD DOME IP CAMERA PRODUCT MANUAL GB - NL OUTDOOR HD DOME IP CAMERA PRODUCT MANUAL GB - NL GB PARTS & FUNCTIONS 2. ---- 1. ---- 3. ---- 7. ---------- 5. 4. 6. 1. Outdoor IP camera unit 2. Antenna 3. Mounting bracket 4. Network connection 5. Power

Nadere informatie

De Samenhang tussen Dagelijkse Stress, Emotionele Intimiteit en Affect bij Partners met een. Vaste Relatie

De Samenhang tussen Dagelijkse Stress, Emotionele Intimiteit en Affect bij Partners met een. Vaste Relatie De Samenhang tussen Dagelijkse Stress, Emotionele Intimiteit en Affect bij Partners met een Vaste Relatie The Association between Daily Stress, Emotional Intimacy and Affect with Partners in a Commited

Nadere informatie

Ontwerp en Implementatie van een Massively Multiplayer Online Gaming(MMOG) Platform

Ontwerp en Implementatie van een Massively Multiplayer Online Gaming(MMOG) Platform Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. Lagasse Ontwerp en Implementatie van een Massively Multiplayer Online Gaming(MMOG) Platform Ontwikkeling van

Nadere informatie

Firewall van de Speedtouch 789wl volledig uitschakelen?

Firewall van de Speedtouch 789wl volledig uitschakelen? Firewall van de Speedtouch 789wl volledig uitschakelen? De firewall van de Speedtouch 789 (wl) kan niet volledig uitgeschakeld worden via de Web interface: De firewall blijft namelijk op stateful staan

Nadere informatie