Generiek framework voor administratieve toepassingen in een webgeoriënteerde omgeving

Transcriptie

1 Generiek framework voor administratieve toepassingen in een webgeoriënteerde omgeving Voorbereiding afstudeeropdracht T30311 Henk van de Ridder Versie 08 Juni 2006 Open Universiteit Nederland, faculteit Informatica Masteropleiding Technische informatica

2 Samenvatting De afstudeeropdracht Generiek Framework voor administratieve toepassingen omvat het ontwerpen en realiseren van algemeen toepasbaar framework voor administratieve applicaties in een webgeoriënteerde omgeving. De administratieve applicaties dienen ter ondersteuning van het primaire bedrijfsproces van serviceverlenende bedrijven. De opdracht omvat allereerst een literatuurstudie over de theoretische design patterns en practices gerelateerd aan de praktisch voorgestelde oplossingen in de Java/J2EE,.NET en Open Source omgevingen. Op basis van de in literatuurstudie verkregen inzicht zal functioneel en technisch een applicatie-framework ontworpen worden, waarmee snel administratief georiënteerde applicaties gebouwd kunnen worden. Essentieel is dat het framework een oplossing biedt voor generiek vastleggen van product specifieke kenmerken binnen de product-, order- en serviceprocessen. Het gaat hier om het kunnen definiëren van gegevensvelden waarvan aantal, naam en type bepaald worden door de productcategorie. Ook de workflow-processen dienen gestuurd te worden door de productcategorie en gegevenswaarden van de specifieke kenmerken. Inhoud 1. Inleiding Omgeving van de opdracht Aanleiding van de opdracht Belang van de opdracht Onderzoeksgebied Moderne software ontwikkelomgevingen Generiek programmeren N-tier architectuur Afstudeeropdracht Uitwerking De bedrijfskundige omgeving Voorbeelden Plan van aanpak Onderzoekswijze Capita Selecta afstuderen Tijdbesteding en planning Afstudeercommissie Open Universiteit Student Gebruikte bronnen...10 Bijlage A: Service Oriented Architecture (SOA)...11 H vd Ridder,

3 1. Inleiding 1.1 Omgeving van de opdracht De omgeving van het onderzoek betreft het bouwen van administratieve software voor de administratieve verwerking van het primaire bedrijfsproces voor serviceverlenende bedrijven van werknemers. Deze administratieve software heeft als doel om gegevens (data) te ontvangen, te verwerken en op te slaan en daarmee de primaire processen te sturen en te ondersteunen. Voorbeelden van de primaire processen van serviceverlenende bedrijven zijn: de registratie en instelling en facturatie proces van service providers (Internet service providers, telefoonservice verleners), het onderhoudsproces bij apparatuurservices (kopiëren, koffieautomaten, centrale verwarmingsystemen, etc), het beheerproces bij dienstverlenende ondersteuning (software of hardware helpdesks, etc). Naast het primaire bedrijfsproces kent elk bedrijf zijn secundaire processen als financiële en personeelsadministratie. Software voor deze secundaire processen is als standaardpakket verkrijgbaar. Maar voor de primaire processen geldt dat elk bedrijf (vrijwel) uniek is (of in elk geval zich zo voelt). De software voor het primaire proces veelal zelf gebouwd of gerealiseerd als toegevoegd maatwerk op ERP-systemen. Dit onderzoek spits zich toe op bedrijven die verschillende productgroepen leveren, waarbij voor elke productgroep een specifieke set gegevens (=aanvullende kenmerken) nodig is. Een voorbeeld is de metaalsector waarbij producten niet alleen gespecificeerd worden door aantal maar ook door verschillende kenmerken voor de verschillende producten: lengte, breedte en dikte van plaatmateriaal, lengte en kleuren van balken, etc. Een ander voorbeeld is de internetsector waarbij een webhosting abonnement gespecificeerd wordt in kenmerken als aantal mailboxen, basisplatform en bandbreedte en een ADSL abonnement met de kenmerken van snelheid, kwaliteit en helpdeskmogelijkheden. Essentieel bij deze klasse van bedrijven betreft het gebruiken van deze aanvullende kenmerken binnen het gehele primaire proces van verkoop via interne waardetoevoeging tot inkoop. 1.2 Aanleiding van de opdracht Software voor het voeren van de financiële administratie wordt door verschillende leveranciers standaard geleverd. Hiernaast zijn er ook softwarepakketten onder de noemer van ERP-systemen voor de besturing van het primaire bedrijfsproces standaard te verkrijgen. Maar in de praktijk blijkt dat veel bedrijven voor de ondersteuning van hun primaire bedrijfsproces toch sofware in eigen beheer ontwikkelen. Dit varieert van hobbymatig ontwikkelde toepassingen met databasepakketten als Microsoft-Access of Apple-filemaker tot professioneel uitgevoerde maatwerkaanvullingen op de ERPsystemen. De redenen om dit te doen zijn o.a. te vinden in het willen registreren en gebruiken van de in de vorige paragraaf genoemde aanvullende kenmerken bij de te leveren producten en diensten. Een standaard ERP-systeem gaat voor de registratie uit van het begrip Artikel, waarbij elk product een artikelnummer krijgt. Het ERP-systeem eist dat verschillen in kenmerken en maatvoering zich vertalen in meerdere artikelnummers. Verder ondersteunt een standaard ERP-systeem de variaties in de werkprocessen (=workflow) slechts beperkt en/of alleen op een voor alle artikelen identieke manier. Ook voor andere standaard objecten als relaties, orders, etc heeft elk bedrijf zijn eigen wensen van wat er verwerkt moet kunnen worden. In de praktijk is dit niet standaard in een ERP-systeem aanwezig, waarbij men zijn toevlucht neemt tot maatwerkoplossingen of eigenbouw systemen. Hierbij heeft elk bedrijf vanuit het verleden een eigen organisatie, gebaseerd op de aanwezige werknemers, waar de werkprocessen over afdelingen en mensen georganiseerd worden. Het specifiek ontwikkelen van de genoemde software kost veel tijd en geld. Vaak wordt vanuit het niets begonnen met het bouwen van de software en is men na de eerste oplevering van de software toch nog regelmatig bezig met bijschaven en uitbreiden van de software. In de praktijk ontstaat dan na enige tijd een softwarebrij die moeizaam te onderhouden is. Ook is er vaak sprake van eilandautomatisering waar elke afdeling zijn eigen software heeft (en bouwt), helaas zonder koppelingen, zodat overtypen van gegevens meer regel dan uitzondering lijkt. Vooral voor bedrijven met een specifiek bedrijfsproces zou het een uitkomst zijn als er een generiek toepasbaar framework zijn waarmee de bedrijfsspecifieke software te bouwen is. Essentieel is dat de H vd Ridder,

4 met het framework ontwikkelde software eenvoudig uit te breiden is en eenvoudig is aan te passen of de specifieke bedrijf- en afdelingsprocessen. Dit aanpassen betreft zowel de gegevens (extra velden, etc) als de processen (extra stappen, etc). Ook zou dit framework software heel snel moeten laten kunnen bouwen en aanpassen. Standaardfuncties als autorisatie, menusystemen etc moeten in het framework aanwezig zijn 1.3 Belang van de opdracht Het onderzoek voor en de uitwerking van deze opdracht zal een bijdrage leveren in het ontwikkelen van krachtige programmeeromgevingen, die toegepast kunnen worden bij het realiseren van administratieve toepassingen in de praktijk. Het framework biedt een oplossing voor het op compacte wijze, dat wil zeggen zonder veel statements te hoeven schrijven, kunnen programmeren van veel functionaliteit. Het voorhanden hebben van generieke functies zorgt dat toepassingen sneller ontwikkeld kunnen worden, immers delen die al gemaakt zijn hoeven niet nieuw ontwikkeld te worden. Het framework zorgt ervoor dat het nieuwbouw en vooral het onderhoud van deze toepassingen vergemakkelijkt wordt. Dat dit zinvol is om hier aandacht aan te besteden blijkt uit de beweringen bij Software Engineering [VLI01], [SCH01] dat het aanvullend software onderhoud tussen de 50% en 75% van de totale software ontwikkelingskosten van een toepassing omvat. 2 Onderzoeksgebied Het onderzoeksgebied van deze afstudeeropdracht wordt omvat in drie begrippen - Moderne software ontwikkelomgevingen - Generiek programmeren - N-tier architectuur 2.1 Moderne software ontwikkelomgevingen Moderne software voor administratieve toepassingen wordt veelal voor de webgeoriënteerde omgevingen gerealiseerd. De grote namen hierbij zijn J2EE van Sun [SUN-01] en.net van Microsoft [NET-01]. Hiernaast worden in de praktijk de webgerichte scriptomgevingen rond de talen PHP [PHP- 01], Perl, Python en Ruby heel veel gebruikt. Hierbij speelt vooral de Open Source gemeenschap een belangrijke rol. Binnen al deze omgevingen worden zowel door de leveranciers als de Open Source gemeenschappen vele practices, patterns en frameworks benoemd. Maar elke bron biedt vaak alleen maar deeloplossingen en beperkte voorbeelden: bijvoorbeeld beperkt aantal gegevensvelden per database tabel, beperkte hoeveelheden te verwerken data, etc. Een overall framework dat zowel rekening houdt met aanpasbaarheid, gebruikersgerichtheid, performance, etc is niet te vinden. Web georiënteerde omgevingen zijn die omgevingen waarbij de gebruikersinterface via een Internet browser, als Internet Explorer en Firefox, wordt benaderd. Belangrijkste alternatieven hierbij zijn: - Thin clients: paginageoriënteerde userinterfaces opgebouwd uit HTML. - Rich Internet Applicaties: browser georiënteerde userinface opgebouwd met DHTML en/of AJAX onderdelen. - Thick clients: userinterfaces die vanuit de browser bestuurd worden via een eigen machine zoals Java Virtual Machine, Macromedia Flash Player of Microsoft ActiveX componenten. 2.2 Generiek programmeren Het begrip Generiek programmeren kan als volgt omschreven worden [NWO01]: Technologieën, organisaties, en bedrijfsvoering veranderen door de jaren heen, en veel software moet bij deze veranderingen worden aangepast. Generiek programmeren is een programmeermethode die het veranderen van software ondersteunt. Een generiek programma beschrijft hoe de uitzondering geïmplementeerd wordt; het algemene geval wordt altijd op dezelfde manier opgelost. Dit betekent dat bij veranderingen alleen datgene wat verandert hoeft te worden aangepast en het overige kan blijven zoals het is. H vd Ridder,

5 De basis van generiek programmeren heeft onder de noemer van hergebruik binnen de gehele evolutie van de softwareontwikkeling al een rol gespeeld. Immers het maken en (her-)gebruiken van functiebibliotheken in Cobol is al een bepaalde vorm van generiek programmeren. Maar ook de ontwikkeling van de service georiënteerde architectuur (SOA) kan in dit kader gezien worden. Het gaat erom om software zodanig generiek te bouwen zodat nieuwe toepassingen en aanpassingen in bestaande toepassingen met zo weinig mogelijk inspanning gerealiseerd kunnen worden. Binnen de objectgeoriënteerde programmeeromgevingen wordt in dit kader het gebruik van design patterns gepropageerd. Design patterns [GAM01] zijn elegante oplossingen voor specifieke programmeer problemen in object georiënteerd software ontwerp. Vooral het MVC (Model-View- Controller) pattern wordt veel genoemd bij de omschrijvingen van Java/J2EE (o.a. Struts) en.net. Maar de invulling lijkt vaak nogal te verschillen. Voor administratieve toepassingen in de J2EE en.net frameworks zijn door de leveranciers ook uitgebreide beschrijvingen van patterns en practices gegeven, zie o.a. [IBM04], [NET01] en [SUN03]. Een praktische oplossing voor in Java/J2EE ontwikkelen van administratieve toepassingen wordt in het boek Systeemontwikkeling met J2EE [LIG01] beschreven 2.3 N-tier architectuur De omgeving van het onderzoek betreft administratieve toepassingen opgebouwd volgens de n-tier architectuur. Component en Service georiënteerde toepassingen gebruiken deze indeling voor de applicatie respectievelijk de service (zie bijlage A). De functies van deze drie belangrijkste lagen van de administratieve toepassingen zijn: - Interface- of gebruikersinteractie laag: de data wordt met behulp van interactieve of geautomatiseerde formulieren onderhouden. Technieken die gebruikt worden zijn: taalspecifieke GUI (in Java of Visual Basic), HTML-formulieren of XML formulieren. Deze gebruikersinteractie laag kan gesplitst worden in: o o Platformspecifieke interface: het formulier waarmee de gebruiker de applicatie bedient. Platform onafhankelijke interface: de interface waarmee de functies in de bewerkingslaag worden aangeroepen. - Bewerking- of businesslaag: de data, die door de gebruikersinterface wordt aangeboden, wordt gecontroleerd op juistheid en volledigheid en zodanig bewerkt dat de opslaglaag deze kan ontvangen. Ook zorgt deze laag voor de bewerking van door de opslaglaag aangeleverde gegevens voor presentatie in de gebruikerslaag. - Datalaag: de bewerkte data wordt omgevormd en persistent opgeslagen in databases of andere vormen van dataopslag. Deze laag kan ook gesplitst worden in o o Dataverwerkingslaag: de omvormingslaag die de dataverwerkingsopdrachten omzet in database specifieke opdrachten. Database: De opslagplaats van de gegevens, veelal een relationele database. Hierbij dient aangemerkt te worden dat er ook de nodige discussies zijn welke functionaliteit in de vorm van stored procedures in de database ondergebracht kan worden en welk functionaliteit in de bewerkingslaag. Deze discussie speelt als er binnen een bedrijf voor alle toepassingen voor de dataopslag van dezelfde database gebruik gemaakt wordt. Wanneer dit niet het geval is, of wanneer men zich niet wil binden aan een bepaalde database-fabrikant, moet al de verwerkingsfunctionaliteit in de zogenaamde middle -tier gerealiseerd worden. In deze afstudeeropdracht gaan we van deze situatie uit. H vd Ridder,

6 3 Afstudeeropdracht De opdracht luidt: het ontwerpen en bouwen van een generiek framework voor het kunnen realiseren van administratieve toepassingen in een web georiënteerde omgeving ter besturing van het primaire bedrijfsproces van serviceverlenende bedrijven. 3.1 Uitwerking Het ontwerpen van een generiek framework voor het kunnen realiseren van administratieve toepassingen gericht op het primaire bedrijfsproces van serviceverlenende bedrijven in het MKBsegment ( medewerkers). Het primaire proces is daarbij gericht op het leveren van een langdurige service, die vooraf gespecificeerd en onderweg gewijzigd moet kunnen worden. Serviceverlenend betekent in dit kader dat het primaire bedrijfsproces niet gericht is op materialhandling, projectmatige bouw en/of ingewikkelde productieprocessen, maar op het verlenen van een service waarbij het ter beschikking stellen van diensten centraal staat. Essentieel is dat het framework een oplossing biedt voor het vastleggen van product specifieke kenmerken binnen de product-, order- en serviceprocessen. Het gaat hier om het kunnen definiëren van gegevensvelden waarvan aantal, naam en type bepaald worden door de productcategorie. Ook de workflow-processen dienen gestuurd te worden door de productcategorie en eventuele gegevenswaarden. Het framework moet voldoen aan de volgende rand voorwaarden: - De applicatie dient verdeeld te zijn volgens de 3-tier lagen structuur: User Interface, Applicatie logica en gegevensopslag. - Voor de gegevensopslag geldt: koppelbaar aan meerdere relationele databases die SQL-92 compliant zijn, in elk geval: MySQL, Postgres, MS-SQL-server, Oracle (vanaf 10i) en DB2. - Naast gegevensopslag dient ook gekoppeld te kunnen worden aan webservices die voldoen aan de WSDL, SOAP, UDDI standaards - Voor de applicatie logica (workflow, integriteitregels, etc) geldt dat deze slechts op één plaats gedefinieerd en geprogrammeerd worden. - Voor de User Interface geldt dat dit volledig webgebaseerde GUI moet zijn, waarbij veel gebruikervriendelijkheid en sturing mogelijk is, zo mogelijk gebruik makend van de AJAXtechnieken - Te realiseren in de programmeertaal PHP. Onderzocht moet worden in hoeverre de oplossing zodanig generiek kan worden beschreven zodat inpassing binnen de omgevingen Java/J2EE resp. ASP.NET snel mogelijk is. Binnen het framework moeten de volgende mogelijkheden aanwezig zijn - Definiëren van de gegevensstructuren in combinatie met kenmerken registratie - Definiëren van GUI s - Definiëren van rolgebaseerde autorisatie - Definiëren en afspelen van workflows / business processen zowel interactief als batchgewijs. - Definiëren van XML/Webservice koppelingen - Definiëren van managementinformatie - Definiëren van helpstructuren (onderhoudbaar door de gebruikers) - Definiëren van of brief georiënteerd output Andere eisen - Voor de ontwikkeling van het framework dienen de patterns en practices van de volgende ontwikkelomgevingen onderzocht en beoordeeld te worden: o O/R mapping: de principes van mappen van Objectstructuren naar Relationele database o.net 2.0 omgeving in combinatie met de ASP.NET patterns o Java/J2EE: GUI oplossing als Struts, O/R oplossingen als Hibernate, servicelaagoplossingen als Spring o Oracle omgeving met daarbij Oracle Forms en Oracle (J)Developer o 4GL omgevingen als OptimalJ, Progress, etc H vd Ridder,

7 - Specifiek voor de PHP georiënteerde patterns dient gekeken te worden naar: o RADICORE: Rapid Application Development toolkit for building Administrative Web Applications [MAR01] o Ruby On Rails en de daarvan afgeleide toepassingen binnen PHP: Cake en Biscuit [RUB01] o PhpMyEdit - Specifiek voor de GUI dient onderzocht te worden naar de mogelijkheden o XML / XSLT transformaties (zie het RADICORE netwerk o XFORMS [W3C01] o AJAX toepassingen - Specifiek voor de werkprocessen dient gekeken te worden naar: o BPML: Business Proces Modeling Language o The Workflow Reference Model van The Workflow Management Coalition [WFM01] 3.2 De bedrijfskundige omgeving De bedrijfsmatige omgeving: spelers en interacties waarin het te ontwerpen generieke framework voor het kunnen realiseren van administratieve toepassingen wordt in de onderstaande figuur samengevat. Toelichting: GUI = Interactie via Grafische userinterface XML = Interactie via XML bestanden Service = Interactie via Web Services Web = Interactie via een Web-GUI Brief = Interactie via brief of 3.3 Voorbeelden Voorbeelden waarin het te ontwikkelen generieke framework een oplossing zou moeten bieden, zonder dat programmeren nodig is, zijn: - Extra gegevensvelden: bijvoorbeeld bij de uitbreiding klantengroep naar het buitenland, waarbij extra gegevensvelden als landcode en buitenlandse postcode in de relatietabel opgeslagen moeten worden. Het framework moet de mogelijkheid bieden om op één plaats aan te kunnen geven dat deze extra velden er zijn, wat de toegestane waarden zijn, de bedrijfsregel wat het formaat van buitenlandse postcode is afhankelijk van de landcode. Ook moeten de extra velden in de workflow voor toevoegen en wijzigen van relatiegegevens meegenomen worden. - Wijziging bedrijfsproces: bijvoorbeeld bij een beperkte organisatiewijziging waarbij een bedrijfsproces wordt heringericht en verdeeld wordt over meerdere afdelingen. Het framework moet de mogelijkheid bieden om de bestaande workflow te splitsen en de activiteiten toe te wijzen aan de verschillende afdelingen. - Extra productcategorie: bijvoorbeeld door de vergroting van het productportfolio waarbij een nieuwe productcategorie ontstaat met eigen specifieke gegevensvelden. Het framework moet de H vd Ridder,

8 mogelijkheid bieden voor het definiëren van de extra productcategorie en bijbehorende specifieke gegevensvelden. Deze definitie moet dan automatisch doorgevoerd worden in de product-, orderen serviceprocessen, zowel voor wat betreft de gegevensvelden als de workflows. - Nieuwe webservice: bijvoorbeeld als er een nieuwe externe leverancier is die een eigen Webservices/XML koppeling aanbiedt voor het plaatsen van bestellingen. Het framework moet de mogelijkheid bieden om deze koppeling te definiëren en te zorgen voor een mapping van de gegevensvelden (namen en toegestane inhoud) tussen bedrijf en leverancier, zoals ordernummer, orderdatum, artikelcode etc. 4. Plan van aanpak Het plan van aanpak geeft de onderzoekswijze, invulling van de Capita Selecta en planning en tijdbesteding weer. 4.1 Onderzoekswijze De uitvoering van de afstudeeropdracht bestaat uit drie gedeelten: - Literatuurstudie - Functioneel en technisch ontwerp - Bouwen van (delen van) het Framework en voorbeeld applicaties Het hoofdbestanddeel van deze afstudeeropdracht is het uitvoeren van de literatuurstudie. In deze literatuurstudie wordt de (theoretische) stand van zaken bepaald over: - Toepassing van de klassieke design patterns - Generiek (=adaptief) programmeren - Overwegingen gegevensgerichte of werkprocesgerichte applicatiebouw - Workflow management - O/R mapping (Objecten afbeelden op relationele databases) - Applicatiearchitecturen (O.a. de verdeling in lagen ( n-tier )) - Basisvereisten van administratieve applicaties (autorisatie, menu, GUI-eisen, functies, interactieve versus batch-processen, controlemechanismen, ) Onder literatuur wordt verstaan studieboeken en wetenschappelijke artikelen, maar ook de redbooks, whitebooks, tutorials en handleidingen op de websites van bijv. Sun, Microsoft, IBM en de diverse opensource oplossingen en frameworks. Ook dienen de oplossingen van grote en kleine ERP leveranciers (daar waar informatie publiek beschikbaar is) hierbij betrokken te worden. De literatuurstudie zal een vergelijking leggen tussen de theorie (studieboeken en wetenschappelijke artikelen) op het gebied van Generiek programmeren en (Design) Pattterns en de gevonden praktische oplossingen. Hiernaast dient een vergelijking gemaakt te worden van de overeenkomsten en verschillen in door leveranciers en Open Source gemeenschappen gepropageerde patterns, patterns en frameworks. Het tweede gedeelte van de afstudeeropdracht bestaat uit het maken van een functionele en technische beschrijving van het ideale framework. Op basis van de via de literatuurstudie verkregen inzichten wordt aangeven aan welke functionele en niet-functionele eisen het ideale framework dient te voldoen. De functionele beschrijving zal bestaan uit gewone tekst aangevuld met UML diagrammen voor de meest essentiële zaken. In het technische ontwerp wordt aangegeven wat de database- en objectenstructuur van het framework zelf is. Hierbij wordt expliciet aandacht besteedt aan het omgaan met de extra kenmerken bij product-, order en serviceprocessen. Het bouwen omvat het realiseren van de belangrijkste delen van het framework en een voorbeeld applicatie als proof-of-concept in de programmeertaal PHP. Het bouwen zal gebeuren in de vorm van meerdere iteraties waarbij elke iteratie een werkend product geeft overeenkomstig de werkwijze van Extreme Programming [MAR02]. H vd Ridder,

9 4.2 Capita Selecta afstuderen Een theoretische basis voor dit afstudeerproject is al gelegd met de OU-modulen: Concepten van programmeertalen [T12311] en Design Patterns [T16311]. In aanvulling hierop zullen twee zelfstudie opdrachten van 100 uur uitgevoerd worden: 1. Advanced Design Patterns. Met de OU-module Design Patterns [T16311] is de basis gelegd voor de kennis over en het toepassen van een aantal Design Patterns op basis van het studieboek Design Patterns van Erich Gamma e.a. [GAM01]. In deze capita selecta wordt een zelfstudie gedaan naar de toepassing van deze Design Patterns in de Java/J2EE omgeving, de.net omgeving en de Open Source omgevingen rond PHP, Perl, Python en Ruby. Dit onderzoek zal uitgaan van de whitebooks en/of tutorials zoals deze te vinden zijn op de websites van Sun en IBM voor Java/J2EE en Microsoft voor.net. Ook zal gekeken worden of er naast de klassieke Design Patterns nog andere ontwikkeld zijn, die specifiek voor administratieve software ontwikkeling van toepassing kunnen zijn. Het resultaat zal een rapportage en presentatie zijn van de gevonden Patterns. 2. XML en webservices T Deze OU module zal ingebracht worden als 2 e capita selecta. Dit omdat een onderdeel van de afstudeeropdracht ook de koppeling in het framework met webservices omvat. 4.3 Tijdbesteding en planning De verwachte tijdbesteding is in de onderstaande tabel weergegeven. In totaal zijn de uren van zowel het afstudeerproject als de Capita Selecta samengenomen. Onderdeel Uren (capita selecta 1). Advanced design patterns 100 (capita selecta 2). XML en webservices 100 Literatuurstudie rond beschreven patterns en practices over van.net en 200 J2EE bij resp. Microsoft en J2EE. Functionele analyse en Technisch ontwerp van de te implementeren 200 (administratieve) functies van het framework Bouwen van (delen van) het Framework in PHP (proof-of-concepts) 200 Tussenpresentaties bij bijeenkomensten, Afronden eindrapport, maken 100 eindpresentatie TOTAAL 900 De verwachte planning voor dit afstudeerproject is in de onderstaande tabel weergegeven. Globaal houd ik aan uur studie per maand. Onderdeel Tijdvak Literatuurstudie: selectie (verzamelen van lijsten met de te bestuderen Mei-Juni 2006 literatuur: artikelen, websites, etc) Capita Selecta 1: Advanced Design Patterns (afronding eind aug. 2006) Juli-Aug 2006 Capita Selecta 2: XML en webservices (tentamen: nov. 2006) Sept-Okt 2006 Bouwen van 1 e opzet van het framework inclusief voorbeeld applicatie. Nov-Dec 2006 Literatuurstudie Jan-Mei 2007 *1 Analyse en ontwerp Idem Iteratief bouwen van framework en voorbeeld applicatie Idem Afronden afstudeeropdracht Juni 2007 *1 De stappen Literatuurstudie, Analyse en Ontwerp en Bouwen zullen elkaar in een iteratief proces van meerdere iteraties afwisselen overeenkomstig de werkwijze bij Extreme Programming [MAR02] H vd Ridder,

10 5 Afstudeercommissie 5.1 Open Universiteit Voorzitter Prof. dr. J.T. (Johan) Jeuring Secretaris Dr. Ir. A.J.F. (Arjan) Kok Student Naam: Henk van de Ridder Studentnr: Adres Waterweg 47, 3882 RA Putten Tel: (prive), (werk) 6 Gebruikte bronnen [ANK01]: De Middle tier is overbodig. Anko Duizer, juli 2004, online [GAM01]: Design patterns, elements of reusable object-oriented software, Gamma e.a. Addison Wesley, ISBN [IBM04]: Patterns: Service-Oriented Architecture and Web Services, SG , April 2004, IBM Redbooks: [LIG01]: Systeemontwikkeling met J2EE, Ligtmans e.a, Solidium, 2005, ISBN [MAR01]: Rapid Application Development toolkit for building Administrative Web Applications, Tony Marston, [MAR02]: Agile Software Development, Robert Cecil Martin, 2003, ISBN , Pearson education. [NET01]: Application Architecture for.net: Designing Applications and Services, Microsoft, online [NWO01] Project: Typesystemen voor generiek programmeren in Haskell [PHP01] PHP hypertext processor [PHP02] PHP form generator [RUB01] Ruby on Rails, open-source web framework, [SCH01] Klassieke en objectgeorienteerd Software-engineering, p.13, Schach, ISBN , dec 2000, Academic Service [SUN01]: Designing Enterprise Applications with the J2EE Platform, Second Edition, Singh-Stearns- Johnson, 2002, online [SUN03]: Core J2EE Patterns: Best Practices and Design Strategies, Alur e.a.: Prentice Hall / Sun Microsystems Press ISBN: [VLI01]: Sofware Engineering, p.15, Vliet, ISBN , 2000 John Wiley & Sons, [W3C01]: XForms, [WFM01]: Workflow Reference Model Diagram [ZOP01]: The Web Site for the Zope Community, H vd Ridder,

11 Bijlage A: Service Oriented Architecture (SOA) De Service Georiënteerde Architectuur als basis voor de ontwikkeling van bedrijfsbrede applicaties is niet zomaar ontstaan. In de MSDN library van Microsoft wordt door Brian Travis [TRA01] de ontwikkeling van deze architectuur geschetst (zie figuur A1). Bij een traditioneel ontwikkelde applicatie wordt de programmalogica van zowel de userinterface, bedrijfsregels als datatoegang in één geheel (monolythisch) gerealiseerd. Nadeel hiervan is dat wijzigingen en koppelingen met andere applicaties altijd veel programmeerwerk kosten. In de Component georiënteerde aanpak wordt de applicatie gesplitst in presentatie, bedrijfsregels en datatoegang. Voordeel is dat een keuze voor bijvoorbeeld een andere presentatiewijze (van GUI naar Exploreromgeving) alleen verandering van de presentatie laag inhoudt. Nadeel van de Component georiënteerde aanpak is dat het koppelen met andere systemen nog lastig is. Daarom is er in de Service georiënteerde aanpak gekozen om een applicatie te ontwikkelen uit op zichzelf staande bouwstenen, services genoemd. Volgens Greefhorst [GRE01] is een service een duidelijk gedefinieerde functie die een applicatie aanbiedt aan andere applicaties. In feite is dus een service een miniapplicatie waarbinnen ook de driedeling: presentatielaag (hier interfacelaag genoemd), bedrijfsregels en datatoegang van toepassing is. Traditioneel Component Service Figuur A1: Van traditioneel naar Service georiënteerd De bovenstaande ontwikkeling naar service georiënteerde architectuur is niet los te zien van de ontwikkeling van het web [SUN02]. Het web biedt namelijk de architectuur voor de webservices waarmee communicatie tussen applicaties of services eenvoudig gerealiseerd kan worden. De fysieke locatie van een service is geen beperkende factor meer. Koppelingen tussen de services vinden via het standaard internet protocol XML. Verschillende standaards zijn op dit moment aanwezig. De twee belangrijkste zijn [LEY01]: - WSDL: de definitie voor het beschrijven van de service-interface van de webservice - SOAP: de definitie van het communicatieprotocol tussen de webservices Bronnen: [GRE01]: Eisen en richtlijnen aan Services, Greefhorst e.a., Informatie, juni 2005, ISSN [LEY01]: Business processes in a webservices world, LeyMan, IBM, august 2002, IBM developerworks ibm-ws-bpelwp.pdf [SUN02]: Sun Microsystems'Java BluePrints team, Designing Web Services with the J2EE 1.4 Platform, [TRA01]: FoodMovers: Buildig Distributed Applications using Microsoft Visual.NET, Travis, november 2003, MSDN Library (Microsoft) H vd Ridder,