Tijdens het uitvoeren van de pilot is er onderzocht hoe Seam en Richfaces gebruikt konden worden voor dit project. Het is gelukt om een spelerslijst te tonen van beide backends. Desondanks is er besloten de pilot te stoppen; het systeemontwerp bleek niet goed aan te sluiten bij de mogelijkheden van Seam. Met deze kennis kan in de volgende pilot het ontwerp worden aangepast. In deze pilot is een proof of concept gemaakt van het GMS, de user interface en de backends. Het is mogelijk om spelers te zoeken en weer te geven van de Poker en Casino software.
6.4.1 Backendadapter implementaties
De backendadapter van de casinosoftware maakt verbinding met de Java casino backoffice, waarin verschillende methoden de resultaten teruggegeven worden. Bij de pokersoftware (C#) is besloten om niet via rmi/remoting verbinding te maken met de backoffice, maar direct met de SQL database. Dit levert een hogere performance op dan als de data via de C# backend zou worden opgevraagd.
6.4.2 Beveiliging
De webinterface is gemaakt om de spelerlijsten te tonen, inclusief het formulier waarin de beheerder de zoekopdracht kan invoeren. De GUI is beveiligd met een wachtwoord, momenteel met de bekende admin/admin username/password combinatie. Later zal hier een database met gebruikers aan moeten worden gekoppeld. De GUI is momenteel opgezet in eenvoudige tabellen met rare kleuren; deze onderdelen hebben een vreemde kleur gekregen omdat ze nog moeten worden geconfigureerd in het css bestand. Op deze manier is direct te zien welke objecten nog moeten worden toegevoegd aan het stijlbestand.
6.4.3 Spelerweergave
Na het inloggen kan de beheerder een van de twee backends selecteren in het formulier en een zoekopdracht opgeven. De twee backends zijn geconfigureerd in de JAVA code en niet dynamisch aan te passen. In een volgende pilot moeten deze worden aangemaakt naar de rol van de gebruiker (welke backends toegankelijk zijn voor de beheerder). De backends worden geladen als ze voor het eerst worden gebruikt, bijvoorbeeld bij een zoekopdracht. De verbinding wordt dus niet direct tot stand gebracht. Op deze manier worden er geen onnodige aanvragen naar de server(s) gedaan of instanties van de backends aangemaakt.
Merk op dat ook in deze layout afwijkende kleuren en expres foutieve spelling is gebruikt bij de teksten en knoppen. Deze teksten zullen met behulp van localization moeten worden omgezet, door bijvoorbeeld per beheerder een voorkeurstaal op te geven.
Figuur 6-6: Inlogformulier van de GMS webinterface
43
Document: AfstudeerverslagOnderdeel van: Afstuderen Gertjan Al, 20069275
Figuur 6-7: Screenshot van de gebruikersinterface met overzicht van spelers, mogelijkheid tot selectie van backend en zoeken van personen
6.4.4 Datamodel
Voor het proof of concept is een datamodel gemaakt (klassendiagram). De achterliggende gedachte is dat iedere backend een PlayerCollection heeft, die alle spelerfuncties biedt. Bij een zoekopdracht geeft de PlayerCollection een List terug met Player objecten, die gevuld zijn met de data uit de backoffice van de respectievelijke backend. In de PlayerCollection worden dus de Player objecten gevuld en worden de key/value pairs (database kolommen en rijen) gemapt naar een gelijke data key en klasse.
Bijvoorbeeld:
1. De casinosoftware bestaat uit players, met o.a. een String “Firstname” en een String “Registration Date”
2. De pokersoftware bestaat uit players (join users & profiles), met o.a. een String “Fullname” en een String “SignUpDate”
De voornamen worden gemapt naar Player.PlayerInfo.FIRSTNAME (String), de registratiedatums worden gemapt naar Player.PlayerInfo.REGISTRATION_DATE (java.util.Date).
Ondanks de verschillen in opslag van de beide databases, is de opslag in de Playerobjecten dus wel gelijk. Op deze manier zijn de playerobjecten dus uitwisselbaar tussen de backends.
Players kunnen een restrictie opgelegd krijgen, bijvoorbeeld het ontzeggen van de toegang. Deze restricties worden ook aangemaakt door de PlayerCollection. In de CasinoPlayerCollection is een voorbeeld van deze restriction gemaakt voor de EMAILRESTRICTION.
Het domeinmodel op de volgende pagina is het ontwerp. Merk op dat in het proof of concept geen gebruik meer wordt gemaakt van een List<Backend> in GMS, maar een Map<String (name), Backend>.
45
Document: AfstudeerverslagOnderdeel van: Afstuderen Gertjan Al, 20069275
6.4.5 Problemen tussen datamodel en Seam
Het gebruik van deze manier van opslag bleek echter niet goed te werken in combinatie met Seam. In het ontwerp is gekozen om de data op te slaan in een HashMap, zodat er geïtereerd kon worden door de variabelen. Het ophalen van een variabele in Seam zou dan echter verlopen zoals te zien is in Codevoorbeeld 6-3, regel 2. In het framework van Seam is echter de mogelijkheid om variabelen van objecten aan te roepen via de manier zoals in regel 3, waarbij automatisch de get-methode van de variabele wordt aangeroepen. Het doel van het gebruik van een framework was dat er gebruik zou worden gemaakt van standaarden. Het ontwerp voldoet niet aan deze standaard en zal moeten worden aangepast. 1 2 3 4 ...
<h:outputText value="#{player.getValue(Player.PlayerInfo.FIRSTNAME)}"/> <h:outputText value="#{player.firstname}"/>
...
Codevoorbeeld 6-3: Ophalen van de voornaam van een speler; regel 2 geeft aan hoe het met dit systeemontwerp moet worden gedaan, regel 3 geeft aan hoe het in Seam kan met behulp van automatisch gebruik van player.getFirstname()