TECHNICAL DESIGN DOCUMENT

Transcriptie

1 TECHNICAL DESIGN DOCUMENT BACHELORPROJECT IN3405 John Ciocoiu Elwin Dokter TECHNISCHE UNIVERSITEIT DELFT FACULTEIT EWI WOENSDAG 28 APRIL 2010 VERSIE 1 COMMISSIE: Ing. D.J. van Roest (opdrachtgever) REPROVINCI INTERNETDIENSTEN B.V., SCHOONHOVEN Ir. H.J.A.M. Geers (begeleider) Ir. B.R. Sodoyer (ST coördinator bachelorproject) TECHNISCHE UNIVERSITEIT DELFT, DELFT

2 INHOUDSOPGAVE Inhoudsopgave Inleiding Architectuur Diagram Klasse indeling... 4 Webapplicatie... 4 Overige Servers Communicatie / serverindeling/verwijzing? Zend Framework SOAP aanmaken app.php Downloaden uitpakken.zip

3 1. INLEIDING Dit document geeft het technisch ontwerp van ons systeem. Het is het laatste document voorafgaand aan de implementatiefase en bevat de opdeling van het systeem in diverse klassen. 1.1 ARCHITECTUUR DIAGRAM Hieronder is nogmaals (zie ADD) het architectuur diagram gegeven van ons systeem. De scheidingslijn geeft aan waar de grens zit tussen de opslag van de websites (webservers) en de eigenlijke applicatie die we gaan schrijven (webapplicatie). Dichte pijlen zijn controle pijlen, gestippelde zijn responses. CONTROLLER De Controller van de webapplicatie, weet via de DatabaseHandler hoe hij de Controllers van de overige servers kan bereiken. Vandaar de twee pijlen tussen Controller aan de webapplicatie kant en de Controllers aan de Webservers kant. In werkelijkheid zijn dit er nog meer, vandaar de... Momenteel zijn er 4 servers die zijn ingericht als webserver. Een hiervan zal ook de webapplicatie gaan bevatten. Er is dus één pijl van Controller naar Controller die eigenlijk een zelfverwijzing is, echter de functie verschilt. Controller van de Webapplicatie doet aanroepen, waar de Controller van de webservers vrij passief zijn en waar alleen een connectie mee opgesteld wordt zodat ze bestanden kunnen ontvangen. 3

4 2. KLASSE INDELING WEBAPPLICATIE CONTROLLER VIEW 4

5 MODEL context User inv: id <> null inv: username.length > 3 inv: password.length > 5 inv: name.length > 3 context Server inv: id <> null inv: name <> null inv: hostname <> null inv: path <> null context Framework inv: id <> null inv: name <> null context Release inv: id <> null inv: name <> null inv: framework <> null context Website inv: id<> null inv: name.length > 2 inv: cms_id <> null inv: server_id <> null inv: locked = 0 (not locked), user-id (else) 5

6 OVERIGE SERVERS CONTROLLER 6

7 3. COMMUNICATIE / SERVERINDELING/VERWIJZING? De drie webservers waar de webapplicatie niet op draait, draaien alle drie een Plesk-omgeving. Op deze servers moet ook een Controller komen die geuploade zip-bestanden op een goede manier uit kunnen pakken op zichzelf (goede mappenstructuur opbouwen). Verder moeten deze server Controllers de verbinding kunnen opstellen met de Deimos-webapplicatie server, zodat er ook daadwerkelijk bestandsoverdracht plaats kan vinden. Deze communicatie verloopt via SOAP. Hieronder worden alle onderdelen nog eens uitgelegd. 3.1 ZEND FRAMEWORK Het Zend Framework is een open source framework voor web applicaties en services met PHP. Elk component is maar gering afhankelijk van hoogstens een aantal andere componenten, wat ontwikkelaars in staat stelt om gebruik te maken van de afzonderlijke componenten. Daarentegen vormen de Zend Framework componenten binnen de standaard bibliotheek een krachtig geheel wanneer deze gecombineerd worden gebruikt. Zend biedt dan een robuust framework volgens het MVC principe. Dit Zend Framwork koppelt de controllers aan web urls. Zo is de IndexController (IndexController.php) bijvoorbeeld benaderbaar, wanneer achter de url /admin wordt getypt. De ReleaseController wordt bereikt via /admin/release. Ook beschikt het over bepaalde SOAP klasses, waardoor ook dat protocol makkelijk geïntegreerd kan worden. Meer over SOAP in de volgende paragraaf. Het component Zend_Auth wordt gebruikt voor gebruikersauthentificatie. Van dit component zullen wij gebruik maken, aangezien we ook gebruikersauthentificatie gaan gebruiken. Het te maken versiebeheersysteem zal gaan draaien op het Zend Framework. Van de standaardbibliotheek gebruiken we het MVC raamwerk als basis voor onze applicatie. Deze keuze is gemaakt, omdat het bestaande CMS systeem hier ook op draait en er dus allereerst kennis over aanwezig is binnen het bedrijf. Verder is het handig, omdat dit Framework over een hoop features beschikt waar gebruik van kan worden gemaakt. Je beschikt dan over een goed fundament, wat al grondig getest is. Dit neemt een aantal verantwoordelijkheden weg bij de programmeurs en het scheelt in implementatietijd. 7

8 3.2 SOAP SOAP communiceert via het http protocol. Het voordeel hiervan is dat je niet met proxy en firewall problemen te maken krijgt die de connectie kan blokkeren. SOAP is gebaseerd op XML en werkt met aanvragen ( request ) en antwoorden ( responses ). De kant die de request uitvoert is de server, de client stuurt vervolgens een response. In sommige gevallen wil je van beide kanten requests uitvoeren. Dan moeten beide zowel client als server zijn, afhankelijk van de richting waarin je de aanroepen wilt doen. Dit wordt uitgelegd aan de hand van het voorbeeld van het uploaden van een release naar de servers. Uploaden van een release Server: webapplicatie (1) SOAP request get ready for upload (4) SOAP response the upload (6) SOAP response ok Server: webserver SOAP response I m ready (2) SOAP request send me the upload (3) SOAP request server x is klaar (5) In het voorbeeld fungeert de webapplicatie in (1) als soap server en de webserver als soap client in (2). In (3) en (4) (en 5 en 6) zijn de rollen omgedraaid. Deze 6-stappen procedure vindt plaats zodat je eerst kan bepalen of de webserver klaar is voor een upload (staat deze wel aan, is die bereikbaar, enz.). Vervolgens reageert de webserver met een request, waarbij hij bij de webapplicatie een functie activeert die de link als response geeft waar de upload zich bevindt. Als de upload opgehaald is door de webserver en ook uitgepakt en het de juiste mappen bevat (de upload is een zip-archief, zie een aantal kopjes hieronder), stuurt de webserver naar de webapplicatie dat de upload geslaagd is. Tijdens het uploaden van een release geeft de View van de webapplicatie de status van de upload van de diverse servers aan. Om de CMS releases en de bijbehorende Zend Frameworks op de webservers te installeren maken we gebruik van SOAP. We gebruiken SOAP verder om op de betreffende server waar een website wordt toegevoegd een bestandje, met daarin de bijbehorende verwijzingen naar de juiste versie van het CMS en het Framework, aan te maken in de juiste map van die website. Als deze map van de website nog niet bestaat wordt deze ook aangemaakt, anders dan wordt alleen het bestandje toegevoegd. Zie verder App.php. Er zijn dus twee momenten waarbij we SOAP gebruiken. Hieronder zijn de twee bijbehorend Configurators gegeven met daarbij hun functies. - WebsiteConfigurator: o Make Appfile o Database Update o Cache Update - ReleaseConfigurator: o Zip ophalen o Zip uitpakken o Bevestiging van juist installeren release De WebsiteConfigurator wordt gebruikt tijdens toevoegen of wijzigen van een website aan het versiebeheer systeem. Zie verder App.php, Database Updaten en Cache Update. De ReleaseConfigurator wordt gebruikt tijdens het uploaden van een nieuwe release. Zie het bovenstaande voorbeeld en Downloaden uitpakken.zip. 8

9 3.3 APP.PHP De verwijzingen naar de CMS-versie map en de Zendversie komen in het bestandje app.php. Dit bestandje moet toegevoegd worden in de hoofdmap van een website. De hoofdmap is de map waarin het index-bestand van de website staat. Dit bestandje wordt elke keer aangemaakt wanneer er een website van versie veranderd, of wanneer er een website geïnstalleerd wordt. In de index.php wordt als eerste dus app.php ingeladen zodat hij weet waar er gekeken moet worden voor het bijbehorende CMS en het daarbij horende Zend Framework. Er is nu alleen een probleem. Het versiebeheersysteem heeft geen rechten in andere mappen, dan zichzelf. Daar moet een oplossing op verzonnen worden. De volgende twee opties zijn mogelijk: - In de serverconfiguratie rechten geven aan het versiebeheersysteem voor bewerkingen in alle mappen. - Het plug-in aan het CMS toevoegen wat mogelijk maakt om deze app.php aan te maken, want het CMS heeft deze rechten wel. De keuze is vooralsnog gevallen op de eerste optie. Deze brengt de minste moeite met zich mee. Ook de beveiliging van het systeem gaat er niet onder lijden. 3.4 DOWNLOADEN UITPAKKEN.ZIP Om een CMS-release op een server te krijgen wordt deze in een archiefbestand gezet. Door dit archiefbestand uit te pakken op de juiste locatie wordt de nieuwe versie geïnstalleerd. Waar haalt de server dit archiefbestand vandaan? Hiervoor zijn ook twee opties te bedenken: - De server krijgt een link van waar het zip-bestand is geupload op de hoofdserver, zodat hij via deze link het zip-bestand kan downloaden. - De server krijgt via SOAP het zip-bestand door en gaat daarmee aan het werk. Hierbij is er gekozen voor de eerste optie. Het zip-bestand wordt door het versiebeheersysteem klaargezet op de hoofdserver zodat deze gedownload kan worden door andere partijen. Door via de SOAP-connectie, zoals hierboven verteld is, deze link door te sturen naar de servers, kunnen de servers het bestand downloaden en uitpakken in de goede map. De functies die voor het downloaden en uitpakken worden gebruikt, zitten al in PHP zelf. Daarom is het slechts een kwestie van op de goede manier deze functies gebruiken en de goede mappen aangeven. Rechten over geuploade bestanden/mappen 9