Onderzoek Open Source Ondersteuning SGA Onderzoek Open Source Ondersteuning Service Gerichte Architectuur Opdrachtgever : Bestuursdienst Gemeente Rotterdam Projectleider : Folkert-Jan de Groot ( 06 51 277 300 ) Versie : 1.2 Status : Definitief Datum : 26 juni 2009
SAMENVATTING Als gevolg van veranderende behoeften staat de gemeente voor de keus een andere Enterprise Service Bus (ESB) te selecteren. De stuurgroep heeft, in lijn met het gemeentelijk beleid, verzocht om eerst te kijken naar de mogelijkheden van open source software. De aanpak is om eerst de meest waarschijnlijke kandidaat te onderzoeken. Mocht deze niet voldoen dan wordt een ander onderzocht of wordt het onderzoek stopgezet. Uit een selectie van tien mogelijke ESB s is uiteindelijk Mule van Mulesource geselecteerd. Voor het beoordelen van de geschiktheid is vanuit drie verschillende invalshoeken naar het product gekeken: 1. Functionele aspecten; Bestaande uit eisen en criteria voortvloeiend uit de concern informatiearchitectuur. Hierin zijn de perspectieven van Architectuur, Ontwikkeling en Beheer samen gebracht. 2. Dienstverleningsaspecten; Bestaande uit algemene kenmerken van open source software ten aanzien van ondersteuning op de software en juridische risico s. 3. Organisatorische aspecten; Bestaande uit vragen over de gevolgen voor de beheersorganisatie, migratieaspecten en kosten. Voor de beoordeling is gebruik gemaakt van bureauonderzoek, een proof of concept, een bezoek aan de gemeente Groningen en de inhuur van externe expertise op het gebied van de implementatie van Mule. Onderzoeksresultaten Voor Mule gelden de algemene voordelen van open source software zoals transparantie, interoperabiliteit, onafhankelijkheid en flexibiliteit. De ondersteuning van open standaarden is goed, er is een actieve community die uitbreidingen ontwikkeld en er zijn meerdere partijen in de markt beschikbaar die ondersteuning bieden op Mule. Functioneel voldoet Mule aan de gestelde eisen met één aandachtspunt, namelijk de communicatie met de Overheids Service Bus die in specifieke gevallen gebruik maakt van het ebms-protocol. Deze communicatie is mogelijk via de OSB Gateway en voorlopig voldoet deze oplossing. Het biedt echter niet de schaalbaarheid die uiteindelijk gewenst is. Een ebms-adapter biedt die schaalbaarheid wel maar is nog niet beschikbaar. Op een later moment zal bekeken worden of de ontwikkeling van een ebms-adapter noodzakelijk is. Pagina 2 van 46
De drijvende kracht achter Mule is Mulesource, een commerciële partij die de vrij beschikbare versie van Mule onderhoudt en publiceert. Daarnaast bieden ze een Enterprise Edition aan. Deze bevat additionele functionaliteiten, monitoring software en extra documentatie. Dit wordt gebundeld met een juridische vrijwaring en support. Met Mulesource kan een dienstverleningscontract worden afgesloten. De stabiliteit, beschikbaarheid en betrouwbaarheid van Mule zijn daarmee voldoende gewaarborgd. Het onderzoek heeft geen volledige helderheid kunnen krijgen over de gevolgen van de licentievoorwaarden. Er is binnen de organisatie onvoldoende expertise beschikbaar om een conclusie te kunnen trekken. De risico s lijken marginaal en er zijn geen praktijkvoorbeelden van juridische problemen, toch verdient het aanbeveling hier een uitspraak over te doen. Ten behoeve van functioneel en technisch beheer biedt Mule wel grafische functionaliteiten voor monitoring en logging maar deze zijn zeer beperkt. Ontsluitingsmogelijkheden richting gespecialiseerde monitoringsoftware zijn daarentegen ruim aanwezig. Mule is slechts één infrastructuurcomponent, in het kader van monitoring over alle componenten heen wordt een bredere strategie bedacht. Bij de implementatie van Mule moet rekening gehouden worden met extra configuratiewerk en maatwerk ten behoeve van monitoring en logging. De kosten voor aanschaf van de Mule ESB Enterprise Edition, inclusief drie jaar support, worden geraamd op 190.000. De keuze voor Mule kan de gemeente een aanzienlijk kostenvoordeel opleveren door de besparing op licenties en onderhoud. Advies De werkgroep adviseert de Enterprise Edition van Mule aan te schaffen. De leverancier Mulesource kan worden benaderd als elke andere leverancier. Om duidelijkheid te krijgen over de licentievoorwaarden zal overleg met Mulesource nodig zijn of kan extern advies ingewonnen worden. Geadviseerd wordt de broncode van de software vooral niet zelf aan te passen maar dit door de leverancier te laten doen. De gemeente heeft voldoende expertise in huis om direct met Mulesource te kunnen communiceren. Een tussenpartij zoals Atos Origin of Cap Gemini heeft daarom geen meerwaarde. Alvorens projecten gebruik kunnen gaan maken van de ESB is het noodzakelijk de beschreven roadmap te volgen voor de implementatie en het onder architectuur brengen van Mule. De resultaten van het onderzoek geven voldoende aanleiding om ook voor de andere componenten uit de concern informatiearchitectuur naar de mogelijkheden van open source software te kijken. Hiervoor is het noodzakelijk capaciteit expliciet te reserveren. De werkgroep adviseert tevens om de consequenties voor migratie van bestaande Pagina 3 van 46
applicaties pas in kaart te brengen nadat het onderzoek naar het component Orkestratie is afgerond. Dit vanwege de sterke afhankelijkheden tussen de ESB, het Services-platform en de Orkestratie-instrumenten. Voor de keuze van Mule speelt het geen rol. De invoering van Mule is gelijk aan de invoering van een andere ESB. Aangezien al is vastgesteld dat een andere ESB dan de huidige Oracle ESB noodzakelijk is, zal training, migratie en inpassing in de bestaande infrastructuur altijd nodig zijn. Pagina 4 van 46
INHOUDSOPGAVE 1 INLEIDING... 6 1.1 AANLEIDING... 6 1.2 INLEIDING OP OPEN SOURCE SOFTWARE... 7 2 OPZET... 10 2.1 DOEL... 10 2.2 SCOPE... 10 2.3 UITGANGSPUNTEN... 11 2.4 VERLOOP VAN HET ONDERZOEK... 11 2.4.1 Acceptatiecriteria... 12 2.4.2 Inventariseren van kandidaatsoftware... 12 2.4.3 Referentiebezoek gemeente Groningen... 14 2.4.4 Proof of concept Mule ESB... 14 2.4.5 Bureauonderzoek naar functionele aspecten... 15 2.4.6 Onderzoek naar dienstverleningsaspecten... 16 2.4.7 Onderzoek naar organisatorische aspecten... 16 3 RESULTATEN... 18 3.1 FUNCTIONELE ASPECTEN... 18 3.1.1 Proof Of Concept... 18 3.1.2 Bureauonderzoek... 19 3.2 DIENSTVERLENINGSASPECTEN... 22 3.2.1 Duurzaamheid... 22 3.2.2 Licentiemodel... 23 3.2.3 Afdekken van juridische risico s... 23 3.2.4 Ondersteuning... 25 3.3 ORGANISATORISCHE ASPECTEN... 27 3.3.1 Roadmap... 27 3.3.2 Kosten... 30 4 CONCLUSIES EN ADVIES... 31 5 BIJLAGEN... 33 5.1 BIJLAGE: QSOS RESULTATEN... 33 5.2 BIJLAGE: MULESOURCE ONDERSTEUNING... 37 5.3 BIJLAGE: CAP GEMINI ONDERSTEUNING... 39 5.4 BIJLAGE: RESULTATEN FUNCTIONELE ASPECTEN... 43 5.5 BIJLAGE: ESB KOSTENVERGELIJKING... 44 6 LITERATUURLIJST... 46 Pagina 5 van 46
1 INLEIDING 1.1 AANLEIDING Overheden moeten vanaf april 2008 gebruik maken van open standaarden. Daarnaast geniet open source software bij gelijke geschiktheid de voorkeur. Dit is het beleid van zowel de Gemeente Rotterdam als de centrale overheid. De onderliggende doelstellingen van dit beleid zijn [1]: Het vergroten van de interoperabiliteit tussen en met de verschillende bouwstenen en vormen van dienstverlening van de eoverheid. Het verminderen van de afhankelijkheid van leveranciers bij het gebruik van ICT. Het vergroten van de transparantie en flexibiliteit van gebruikte software. Het bevorderen van een gelijk speelveld op de softwaremarkt en voorts bevorderen van innovatie en de economie. Dientengevolge hoort bij iedere aanschaf van software een beoordeling van de mogelijkheden van open source software. Deze beoordeling kan op twee manieren met het inkoopproces worden verweven: 1. De beoordeling wordt, voordat de markt wordt benaderd, door de gemeente zelf uitgevoerd. Alle activiteiten, zoals het vinden, beschrijven en testen van potentiële softwarepakketten worden door de gemeente uitgevoerd. Eerst wordt gezocht naar open source mogelijkheden, pas als die niet zijn gevonden wordt de markt benaderd. Een noodzakelijke voorwaarde is dat de gemeente beschikt over voldoende expertise. 2. In de aanbestedingsprocedure worden open en gesloten software naast elkaar gevraagd en beoordeeld. Het voordeel hiervan is dat veel van de onderzoeksactiviteiten door de softwareleveranciers uitgevoerd worden als onderdeel van het offertetraject. Dit onderzoek is onderdeel van het project Aanbesteding BPM/SOA dat als doel heeft software te selecteren voor de realisatie van een Service Gerichte Architectuur. De stuurgroep van dit project heeft gekozen voor optie 1, namelijk om eerst een onderzoek te doen naar de mogelijkheden van open source software [8]. Dit document is het resultaat van dat onderzoek. Pagina 6 van 46
1.2 INLEIDING OP OPEN SOURCE SOFTWARE De aard van open source software is ongetwijfeld bij de lezer bekend. Echter, voor een goed begrip van dit onderzoek is het van belang een aantal specifieke kenmerken van open source software helder te beschrijven. Te beginnen met een definitie. Open source software is software dat een gebruiker vrij kan [5]: a. inzetten voor elk doel, b. bestuderen door de broncode te analyseren, c. aanpassen en verbeteren, d. distribueren, met of zonder aanpassingen. Deze eigenschappen van open source software dragen bij aan de beleidsdoelstellingen (zie 1.1) door: Transparantie: de broncode van de software is vrij beschikbaar en kan worden bestudeerd en aangepast. Hierdoor kan tot in detail inzage worden verkregen in de processen die plaatsvinden. Interoperabiliteit: het gebruik van open standaarden bevordert interoperabiliteit ( de mogelijkheid om met systemen van andere leverenaciers samen te werken). Open source producten gaan veelal correct om met open standaarden. Daarbij kunnen producten die volgens dezelfde open standaarden werken elkaar in principe vervangen. Onafhankelijkheid: transparantie en interoperabiliteit maken het mogelijk dat in principe alle leveranciers de software kunnen leveren, aanpassen en onderhouden. Flexibiliteit: open source software kan worden aangepast naar de specifieke behoeften van de gebruiker. Hiervoor is men niet afhankelijk van de originele leverancier van de software. De gebruiker kan dit zelf doen of in leveranciers in concurrentie laten aanbieden. Open standaarden Het staat een ieder vrij een bijdrage te leveren aan open source software. Veel open source software wordt dan ook ontwikkeld door een internationaal verspreide community van ontwikkelaars. Het gebruik van standaarden is in die context een belangrijke voorwaarde voor de effectiviteit van de samenwerking. De aard van de open source wereld is natuurlijk dusdanig dat open standaarden de voorkeur hebben. Dit leidt er toe dat open source producten veelal correct omgaan met open standaarden. Vendor lock-in Open source software speelt een rol om vendor lock-in s te voorkomen. Door de openheid is in principe iedere leverancier in staat het product te leveren en dezelfde diensten aan te bieden. Doorgaans kan een open source product ook van het internet gedownload worden en zonder tussenkomst van een leverancier worden ingezet. Daarnaast hebben veel open source producten geen afhankelijkheid van een specifiek besturingssysteem; ze vereisen meestal een omgeving die aan een aantal (vaak open) standaarden moet voldoen. Pagina 7 van 46
Open source en aanbesteding Het staat overheidsorganisaties vrij om gratis software zonder aanbesteding in gebruik te nemen [1]. In veel gevallen worden er allerlei producten en diensten aangeboden gerelateerd aan die software. Dit kan variëren van additionele documentatie tot installatie van de software. Hiervoor dient de reguliere inkoopprocedure worden gevolgd, namelijk door de diensten aan te besteden, dan wel in te kopen via bestaande mantelpartijen. en de vraag worden gesteld of er sprake is van een aanbestedingsplicht. Indien behoefte is aan deze dienstverlening verloopt de verwerving ervan volgens het reguliere inkoopproces, Als de kosten van de diensten onder het drempelbedrag vallen is een overheidsorganisatie zoals altijd in beginsel vrij de opdracht te gunnen, mits daarbij de beginselen van het aanbestedingsrecht in acht worden genomen [1]. Ook kan de overheidsorganisatie ervoor kiezen om de software en de diensten toch tegelijkertijd als één opdracht aan te besteden, zodat in ieder geval de productkeuze niet mededingingsrechtelijk belemmerend werkt. Juridische aspecten Het gebruik van open source software brengt twee juridische risico s met zich mee: 1. Inbreuk op intellectueel eigendom. In dit geval claimt een derde partij het intellectueel eigendom op (een deel van) de software. Op grond van de inbreuk kan de derde partij vorderen dat de gebruiker stopt met het gebruik en/of schadevergoeding betaalt [7]. Een bekend voorbeeld hiervan is de claim van SCO op delen van Linux. In de praktijk is het nog nooit voorgekomen dat een dergelijke claim is toegewezen. Het afdekken van dit risico kan op twee manieren: a. Een vrijwaring (indemnification) door ofwel de leverancier van de software of een tussenpersoon. Zo levert HP een vrijwaring op Linux. b. Een audit op de broncode, die is immers beschikbaar. 2. Gebrekkigheid van de software In dit geval leidt de organisatie schade doordat de software fouten bevat. Hierdoor kan een informatiesysteem bijvoorbeeld lange tijd uitvallen of er kunnen belangrijke gegevens verdwijnen. In open source software-licenties wordt aansprakelijkheid in de regel vergaand uitgesloten en worden geen garanties gegeven over de werking van software. In dit opzicht verschillen open source software-licenties nauwelijks van commerciële licenties. Open source software-licenties staan echter wel toe dat met derde partijen aanvullende afspraken worden gemaakt over garantie en aansprakelijkheid. [7] Pagina 8 van 46
Kosten Het gebruiksrecht van software kan wel gratis zijn, het feitelijke gebruik van software is dat niet. Licentiekosten zijn maar een gedeelte van de totale kosten van het gebruik van de software. Er wordt daarom wel eens gevraagd om de total cost of ownership (TCO). Naast aanschafkosten wordt in de TCO rekening gehouden met de kosten voor de benodigde hardware, kosten voor het installeren en beheren van de software, kosten voor het trainingen van medewerkers, et cetera [1]. Echter, het berekenen van de TCO is buitengewoon lastig. Voor de lange termijn zouden bijvoorbeeld ook de exit kosten meegenomen moeten worden. Daarbij beperken TCO-methoden zich uitsluitend tot kwantificeerbare kosten. Voordelen als flexibiliteit, onafhankelijkheid en transparantie verdwijnen uit beeld. Terwijl deze juist zo belangrijk zijn voor een publieke organisatie [5]. Pagina 9 van 46
2 OPZET 2.1 DOEL Het doel van het project is te onderzoeken in welke mate de behoefte ten aanzien van Service Gerichte Architecturen kan worden ingevuld middels open source software en welke impact de selectie van deze software zal hebben op de organisatie. 2.2 SCOPE De behoefte waaraan de geselecteerde software invulling moet geven bestaat niet uit louter functionele eisen. De mogelijkheden voor het afdekken van bedrijfsrisico s (financieel, continuïteit, imago) zijn net zo goed van belang. Tezamen met de gevolgen voor de organisatie onderkennen we daarmee drie categorieën: 1. Functionele aspecten a. Functionele eisen en wensen uit oogpunt van Software Beheer. b. Functionele eisen en wensen uit oogpunt van Software Ontwikkeling. c. Functionele eisen en wensen uit oogpunt van de concern proces- en informatiearchitectuur. 2. Dienstverleningsaspecten a. Garanties ten aanzien van het gebruik van de software. b. Ondersteuning bij het gebruik van de software. 3. Organisatorische aspecten a. Gevolgen voor de beheerorganisatie van de TWD-omgeving. b. Gevolgen voor bestaande applicaties en projecten. c. Kosten van aanschaf en dienstverlening. De software voor het onderwerp SOA heeft betrekking op de volgende onderdelen in de concern informatiearchitectuur [2]: 1. Gegevensuitwisseling 2. Services 3. Orkestratie Gegevensuitwisseling kan op verschillende wijzen plaatsvinden en ingericht worden. Vanuit het uitgangspunt van service oriëntatie kiest de gemeente Rotterdam voor enkelvoudige berichtuitwisseling en het aanbieden van services voor een enterprise service bus (ESB) [6]. Op dit moment bestaat bij een groot aantal lopende projecten behoefte aan een ESB. Daarnaast zijn de behoeften, de toegevoegde waarde en de kaders voor gebruik in kaart gebracht voor het concern [6]. Hierom is eerst begonnen met de keuze voor een ESB en komen Services en Orkestratie later. Er is rekening gehouden met het feit dat de ESB onderdeel uitmaakt van een totale infrastructuur. De ESB is een bepalende component in deze infrastructuur. Daarom wordt eerst gerapporteerd over de resultaten van de ESB alvorens verder te gaan. Dit document bevat dus alleen de onderzoeksresultaten ten aanzien van de ESB. Pagina 10 van 46
2.3 UITGANGSPUNTEN 1. De werkgroep bestaat uit specialisten die ook op het gebied van open source veel ervaring hebben. De kennis die deze groep tezamen heeft is voldoende om dit project uit te voeren. Op onderdelen kan extern getoetst worden. 2. De vraag of SOA ondersteund kan worden met open source is al beantwoord omdat de praktijk dit bewijst (zie de gemeente Groningen). Er wordt met name gekeken naar aspecten die typisch zijn voor de Rotterdamse situatie. 3. De selectie die eventueel volgt op dit onderzoek leidt tot het vaststellen van een concernstandaard. Hierdoor zijn kwaliteit en zorgvuldigheid belangrijker dan snelheid. 4. Het PoC in het onderzoek zal zich richten op 1 softwarepakket tegelijkertijd. Indien een geschikte kandidaat gevonden wordt zal niet verder worden gezocht naar een mogelijk betere. De achtergrond hiervan is dat de werkgroep voldoende expertise bevat om voor de PoC de beste keuze te maken. 2.4 VERLOOP VAN HET ONDERZOEK Onderstaande tabel geeft de stappen weer die gedurende het onderzoek genomen zijn. De volgorde geeft een zekere chronologie aan maar veel activiteiten zijn parallel uitgevoerd, zoals het opstellen van de criteria en het inventariseren van kandidaatsoftware. # Stap 1. Opstellen van de acceptatiecriteria. 2. Inventarisatie van kandidaat open source software. 3. Referentiebezoek aan de gemeente Groningen. 4. 5. 6. 7. Uitvoeren van een Proof of concept met Mule als ESB. Bureauonderzoek naar de functionele aspecten die niet in het PoC zijn getoetst. Onderzoek naar aspecten ten aanzien van dienstverlening. Onderzoek naar de organisatorische gevolgen van de selectie van open source. 8. Evaluatie en rapportage. Pagina 11 van 46
2.4.1 Acceptatiecriteria De acceptatiecriteria zijn opgesteld door de werkgroep en gevalideerd bij de Werkgroep GUC. De volledige uitwerking van de criteria kunt u vinden in het document "ESB_Eisen_en_Criteria_IOO_v01.xls" [3]. Om te komen tot deze uitwerking zijn de volgende stappen genomen: 1. De producten van de werkgroep GUC zijn als uitgangspunt genomen voor de eisen en criteria. Voor de concrete implementatieaspecten is in deze werkgroep gekozen voor het Quint2/Extended ISO-Model 1. Dit Quint2 model is een uitbereiding van de ISO 9126 standaard voor softwarekwaliteit. In de ISO 9126 standaard worden zes kwaliteitseigenschappen van softwareprodukten gedefinieerd, te weten: Functionality, Usability, Efficiency, Reliability, Maintainability en Portability. Elk van deze eigenschappen is onderverdeeld in een aantal deeleigenschappen. Het Quint2 model voegt aan deze 21 deeleigenschappen nog elf, in de praktijk veelgebruikte, eigenschappen toe [4]. 2. De werkgroep heeft de pincipes en eisen uit de concern informatiearchitectuur (componentarchitectuur gegevensuitwisseling, implementatie-aspecten, patronen) die relevant zijn voor een ESB vertaald naar eisen en gecategoriseerd volgens het Quint2 model. Daarnaast zijn de eisen die in QSOS 2 staan vermeld voor open source ESB s geïnventariseerd en opgenomen in de lijst van eisen en criteria. QSOS (http://www.qsos.org) is een instrument voor het selecteren en vergelijken van open source software. Het resultaat hiervan is een evaluatiesheet (zie Bijlage: QSOS Resultaten ). 3. Deze sheet is vervolgens omgewerkt naar een set acceptatiecriteria die getoetst kunnen worden [3]. Per criterium is aangegeven op welke wijze de toetsing plaatsvindt, namelijk via een PoC, via documentatie of via een referentie bezoek/consultant. Dit is uitgewerkt in Pocs_Mule_ESB_v3.doc [4]. 2.4.2 Inventariseren van kandidaatsoftware De werkgroep beschikt over een aantal specialisten op het gebied van SOA die de markt en het open source landschap goed kennen. Gezamenlijk is gekomen tot een lijst van mogelijke open source producten voor de ESB. Hieronder staan deze producten in willekeurige volgorde. Product Mule Sun OpenESB Apache ServiceMix Toelichting Lightweight ESB with a custom implementation model. http://www.mulesource.org https://open-esb.dev.java.net/ JBI implementatie (standaard voor ESB's). 1 http://www.softwarekwaliteit.nl/index.php?title=quint2 2 http://www.qsos.org Pagina 12 van 46
http://servicemix.apache.org Spring Integration Fuse ESB Apache Camel Apache Synapse Apache Tuscany JBoss ESB PEtALS An integration framework part of Spring. http://www.springframework.org/spring-integration Gebaseerd op ServiceMix. http://open.iona.com/products/fuse-esb/ ActiveMQ http://activemq.apache.org/camel http://ws.apache.org/synapse Implementation of the (SCA) specification. http://tuscany.apache.org Gebaseerd op JBoss messaging. http://labs.jboss.com/jbossesb/ JBI-based ESB, hosted by OW2 (formerly ObjectWeb) http://petals.objectweb.org/ Keuze voor Mule Voor de initiële selectie is gebruik gemaakt van een aantal instrumenten: 1. Vergelijking van producten die in de markt aanwezig zijn: a. QSOS test. Er is gebruik gemaakt van het instrument dat beschikbaar is bij QSOS (http://www.qsos.org). QSOS is een instrument voor het selecteren en vergelijken van open source software. Het resultaat hiervan is een evaluatiesheet (zie Bijlage: QSOS Resultaten ). Hierin werden drie producten vergeleken: Mule, ServiceMix en JBoss ESB. Mule 1.4.1 kwam hier als beste uit. De versie van Mule die tijdens de test gebruikt wordt is 2.1. b. Open ESB boek. Hierin wordt een aantal ESB s besproken. Ook hier komt Mule als meest geschikte ESB uit naar voren. c. Overheidservaring. Mule is bij de instanties waar informatie is verzameld als enige open source ESB genoemd: i. DIMPACT is een samenwerkingsverband tussen een aantal gemeenten dat gebruik maakt van Mule. ii. De gemeente Groningen heeft gekozen voor Mule. iii. Een aantal landelijke voorzieningen gebruiken Mule (zoals de gateway voor de Overheids Service Bus). 2. Quickscan van Mule a. Past het binnen de werkwijze van IOO? Het product past qua gekozen technologie en opbouw goed binnen de werkwijzen van IOO (Java en Spring, kan met Eclilpse ontwikkeld worden). b. Past het binnen de concern informatiearchitectuur? Mule is gebaseerd op dezelfde patronen die gebruikt zijn voor de uitwerking van de gegevensuitwisselingscomponent (Enterprise Integration Patterns: Designing, Building and Deploying Messaging Solutions (http://www.eaipatterns.com/)). Pagina 13 van 46
c. Past het binnen de TWD omgeving? Mule ondersteunt JMX (voor monitoring) en is installeerbaar als jar, war of als ejb op een applicatieserver. 3. Relatie met andere componenten (services en orkestratie) a. Mule vereist geen applicatieserver, maar kan wel geïnstalleerd worden en gekoppeld worden aan een applicatieserver. Dit betekent dat het geen beperkingen oplevert voor het selectietraject van het services platform en/of de orkestratiesoftware. b. Mule vereist geen specifieke ontwikkelomgeving (IDE). Alle componenten die voor Mule gebouwd moeten worden zijn een combinatie van configuratie in de vorm van xml, property files en Java. Dit kan met iedere willekeurige Java ontwikkelomgeving (of een tekst editor) gebouwd worden. c. JBoss applicatieserver heeft een connector voor Mule. Deze open source applicatieserver komt veel in de markt voor en zou als services platform dienst kunnen doen. d. Mule heeft een connector voor jbpm. jbpm is orkestratiesoftware. 2.4.3 Referentiebezoek gemeente Groningen De gemeente Groningen heeft gekozen voor een implementatie van de Mule ESB. De werkgroep is op bezoek geweest om zich te laten informeren over hun keuze voor Mule. De belangrijkste conclusies hieruit zijn: 1. De situatie in Groningen is qua inhoud (architectuur/componenten/applicaties) vergelijkbaar met die van Rotterdam. Wel bestaat een duidelijk verschil in schaalgrootte (aantal services/aantal berichten). 2. De perspectieven Architectuur en Ontwikkeling waren voldoende belicht en vielen positief op. Minder aandacht was in Groningen besteed aan operationeel beheer. Hier heeft het project vervolg aan gegeven door in het PoC extra nadruk op beheer te leggen. Daarnaast is een expert benaderd voor advies. 3. Voor dienstverlening zal Groningen een contract aangaan met een dienstverlener. Zij zijn sterk betrokken bij de huidige implementatie en bij enkele lopende projecten. 4. De keuze voor Mule is voornamelijk tot stand gekomen in samenwerking met een specifieke dienstverlener. Hier zijn acceptatiecriteria voor opgesteld waaraan voldaan werd. 2.4.4 Proof of concept Mule ESB Het Proof of Concept voor Mule ESB bestaat uit vier verschillende maar samenhangende testen: # Titel Omschrijving Pagina 14 van 46
1. PoC-GBA Kennisgevingen vanuit de GBA-personen bron applicatie naar 2. 3. 4. PoC-GM PoC-TMF PoC-WABO gegevensmagazijn via de ESB. Verwerkingstijd op een voor Rotterdam representatieve set. Testen op foutmarge, gemak van foutdetectie, en eventueel foutcorrectie. Verwerking van een informatieverzoek vanuit een webapplicatie aan het gegevensmagazijn via de ESB op een voor Rotterdam representatieve set. Testen op verwerkingstijd, foutmarge en gemak van fout detectie en eventueel capaciteit. Aansluiten vanuit Rotterdam op de landelijke TerugMeldFaciliteit via de Overheids service bus (OSB). De beschrijving van de landelijke TMF kan teruggevonden worden in het document Startarchitectuur TMF versie 1.0, 29 januari 2008 Aansluiten vanuit Rotterdam als tweede applicatie op de OSB. Aantonen dat de ESB dienst kan doen als toegangspoort naar buiten door een tweede service aan te sluiten via de OSB. Deployment model, autenthicatie en autorsatie, ebxml. De ontwikkeling van de software voor PoC 1 en 2 is uitgevoerd door IOO De ontwikkeling van de software voor PoC 3 is uitgevoerd door IT-eye. De testen zijn uitgevoerd door IOO/TWD_GW op hardware van TWD_GW en op locatie bij TWD_GW. De beoordeling van de PoC software en de PoC tests is uitgevoerd door de ESB Open Source werkgroep, hierin zijn specifiek vertegenwoordigd OIM Architectuur, TWD_GW en IOO. 2.4.5 Bureauonderzoek naar functionele aspecten Voor de indeling van de eisen is Quint2 gebruikt. Niet al deze eisen hoeven aangetoond te worden middels een werkend voorbeeld: een aantal is gemakkelijk te controleren via documentatie. Een eis is via bureauonderzoek getoetst indien de Rotterdamse situatie niet of nauwelijks verschilt van andere gebruikersgroepen, of als een criterium op dit moment niet van toepassing is op de Rotterdamse situatie. De volgende bronnen zijn gebruikt voor het bureauonderzoek: De QSOS score van Mule. Een aantal van de criteria is gemeten met behulp van QSOS (http://www.qsos.org/?p=81). Hierbij is een weging gegeven aan de criteria gebaseerd op de concern informatiearchitectuur en de gestelde technische eisen. De Mule 2.x User Guide. Deze is op te vragen via de Mule site na registratie. De website van Mule. Deze is vrij toegankelijk. De website van Apache CFX (één van de componenten die gebruikt wordt in Mule). De werkwijze is als volgt, er zijn drie scores: Goed als Mule voldoet aan het acceptatiecriterium zonder wijzigingen te hoeven aanbrengen anders dan in de configuratie van Mule. Voldoende als Mule geen voorgedefinieerde ondersteuning biedt voor het Pagina 15 van 46
criterium maar wel mogelijkheden biedt om deze te realiseren. Dit kan op de volgende manieren: o Standaard ondersteuning via Mule Extensions (zie http://www.mulesource.org/display/muleforge/projects). o Standaard ondersteuning via Mule custom componenten. Deze componenten kunnen zelf ontwikkeld worden middels zogenoemde custom compnents. Een voorbeeld is een custom transport. o Alternatieve oplossing. Er zijn soms alternatieve oplossingen die standaard in Mule zijn gebouwd om hetzelfde te bereiken. Slecht als Mule niet voldoet aan het criterium en ook geen ondersteuning biedt om de functionaliteit zelf te realiseren. Ieder kwaliteitsaspect kent een aantal onderdelen, voor het bureauonderzoek is het in een totaal samengevat. 2.4.6 Onderzoek naar dienstverleningsaspecten Het beschikbaar stellen van softwarefunctionaliteit bestaat niet alleen uit de initiële verwerving en installatie van software. Verreweg de grootste component in termen van tijd en kosten is het onderhoud en beheer dat nodig is om de software beschikbaar te houden. Het is van groot belang om hier bij de verwerving van de software rekening mee te houden. De wijze waarop open source software wordt onderhouden (zie 1.2) is fundamenteel anders dan bij gesloten software. Dit heeft directe consequenties voor de organisatie van zowel het onderhoud (van de softwarecode) als het beheer (van de installatie). De gemeente Rotterdam heeft nog weinig ervaring met de grootschalige inzet van open source software op het niveau van applicaties. Op het niveau van het operating system ligt dit anders, Linux is zelfs een gemeentelijke standaard. Dit is maar heel beperkt met elkaar te vergelijken omdat het open source landschap per applicatie heel verschillend is. Om inzicht te krijgen in de dienstverleningsmogelijkheden voor Mule hebben we de volgende activiteiten ondernomen: 1. Afstemming met de gemeente Groningen over de wijze waarop zij onderhoud en beheer van plan zijn in te richten. 2. Bureauonderzoek naar de achtergronden van dienstverlening rond open source in zijn algemeenheid. 3. Overleg met marktpartijen (Atos Origin en Cap Gemini) over de dienstverlening die zij leveren op Mule. 4. Bureauonderzoek naar de diensten van de leverancier van Mule (Mulesource) en de ondersteuning van de community rondom Mule. 2.4.7 Onderzoek naar organisatorische aspecten Het in gebruik nemen van nieuwe software heeft gevolgen voor de organisatie. Het kan zijn dat er opleidingen, migraties, nieuwe procedures en dergelijke nodig zijn. Het Pagina 16 van 46
is de vraag of het ingebruik nemen van open source software andere consequenties met zich meebrengt dan gesloten software. Enerzijds kunnen dat consequenties zijn die kunnen volgen uit de techniek, zoals een andere manier van monitoring. Anderzijds kunnen dat consequenties zijn die volgen uit een verandering in de rol die de organisatie vervult bij het gebruik van de software. De gemeente heeft ervaring met open source software. Linux wordt grootschalig ingezet en is een standaar. Andere open source software wordt welliswaar ingezet maar veelal lokaal en in weinig kritische situaties. De keuze voor een open source ESB en de standaardisatie hierop binnen het concern is van een andere orde. Dit deel van het onderzoek bestaat uit het formuleren van antwoorden op de volgende drie vragen: 1. Heeft de inzet van een open source ESB andere gevolgen voor de organisatie dan de inzet van gesloten software? 2. Wat zijn de gevolgen voor de organisatie met betrekking tot het beheer bij de TWD? 3. Wat zijn de gevolgen voor bestaande applicaties en projecten? 4. Wat zijn de kosten van aanschaf en dienstverlening? Het resultaat van dit deel van het onderzoek is een roadmap van de benodigde stappen volgend op de behandeling van dit rapport. Pagina 17 van 46
3 RESULTATEN 3.1 FUNCTIONELE ASPECTEN De functionele aspecten zijn beoordeeld middels bureaonderzoek of via een concrete test (Proof of Concept). De volgende paragrafen bevatten een samenvatting van die resultaten. Alle resultaten zijn opgenomen in 5.4 Bijlage: Resultaten Functionele Aspecten. 3.1.1 Proof Of Concept Het proof of concept is opgebouwd uit de volgende drie elementen: 1. Softwaretesten Mijn Loket Het project Mijn Loket levert software op waarvan een deel gebruikt kan worden om Mule te testen. Daarvoor zijn door de IOO specifiek testen ontwikkeld die in samenwerking met de TWD en OIM zijn uitgevoerd en beoordeeld. Op alle criteria scoort Mule goed. 2. Beoordeling door de TWD De beheerbaarheid van Mule is beoordeeld door beheerders van de TWD. Hier is op meerdere manieren invulling aan gegeven. Voor logging en monitoring zijn diverse softwarepakketten bekeken, tevens is een dag externe expertise ingehuurd met gedegen kennis van Mule. Uit het onderzoek naar de beheerbaarheid van Mule blijkt dat Mule voldoende scoort als het gaat om monitoring en logging. Welke monitoring tool gekozen wordt maakt in principe niet veel uit omdat informatie via JMX of via een custom http-service opvraagbaar is. Bij de implementatie van Mule dient rekening te worden gehouden met extra configuratiewerk en maatwerk ten behoeve van monitoring en logging. 3. Koppeling met de Overheids Service Bus (OSB) De OSB maakt gebruik van het ebms-protocol indien specifieke eisen gesteld worden aan de betrouwbaarheid en vertrouwelijkheid van de communicatie. Dit protocol wordt binnen de gemeente Rotterdam niet gebruikt. Het is daarom noodzakelijk een vertaling te maken tussen dit protocol en de webservicestandaarden die gebruikt worden in Rotterdam. Het was de bedoeling om de koppeling met de OSB in de praktijk te toetsen met behulp van de projecten Wabo en Stelsel van Basisregistraties. Dit is niet uitgevoerd. Voor de vertaling naar ebms bestaan twee varianten: 1. Met behulp van de OSB Gateway. Deze wordt door het ICTU gratis beschikbaar gesteld maar is vooral bedoeld voor gemeenten die geen eigen Service Bus hebben. 2. Met behulp van een zogenaamde ebms-adapter. Deze adapter is specifiek voor elk merk ESB. Rotterdam heeft een voorkeur voor deze variant. Pagina 18 van 46
Er blijkt geen out-of-the-box ebms-adapter beschikbaar te zijn voor Mule. Atos Origin, de ontwikkelaar van de OSB Gateway, gaf aan over een dergelijke adapter te beschikken, maar deze bleek slechts ten dele aan onze eisen te voldoen. Voorlopig kan gebruik gemaakt worden van de OSB Gateway. Op een later moment zal opnieuw gekeken worden naar de mogelijkheden om een adapter in te zetten. Deze keuze wordt gemaakt op basis van twee argumenten: 1. Het overleg met Atos Origin geeft aan dat de ontwikkeling van een dergelijke adapter mogelijk is. De kosten hiervan zijn onduidelijk, mede omdat het ICTU bezig is om de OSB Gateway open source te maken. Deze Gateway bevat een deel van de benodigde code. 2. Er komt een lobby op gang richting het ICTU om zo min mogelijk services te ontwikkelen op basis van ebms omdat deze technologie inmiddels ingehaald is. Daarmee zou het gebruik van de adapter beperkt zijn. Dit sluit aan op het voornemen uit de Nederlandse Overheids Referentie Architectuur (NORA 2.0 pagina 139, 140) waarin wordt geconstateerd dat voor webservices gewerkt moet worden aan een standaard, waarmee ook betrouwbaar berichtenverkeer met webservices mogelijk wordt. 3.1.2 Bureauonderzoek Na de voorselectie is een aantal criteria aangewezen die door middel van een bureauonderzoek zijn getoetst. Mule voldoet op alle aspecten aan de eisen die gemeente Rotterdam aan een ESB stelt. Hieronder volgt een samenvatting van de resultaten per categorie. Geschiktheid Geschiktheid behoort tot de categorie Functionaliteit en betreft negen eigenschappen van software die van invloed zijn op de aanwezigheid en geschiktheid van een verzameling functies voor gespecificeerde taken. Mule scoort op zes eigenschappen goed. Op Standaarden, Transformaties en Patronen scoort Mule voldoende. Dit wordt veroorzaakt doordat de volgende aspecten voldoende in plaats van goed zijn: UDDI, XQuery, Constante mappings, en publish/subscribe. Standaarden: UDDI UDDI is een standaard die gebruikt wordt voor het bevragen van een service catalogus. Op dit moment heeft Rotterdam nog geen beleid ten aanzien van deze service catalogus. Dit zal verder worden uitgewerkt in de component architectuur services en gouden gids. Als gekozen wordt voor de UDDI-standaard en er vanuit Mule een koppeling gelegd moet worden naar deze catalogus kan een custom transport gemaakt worden. Transformaties: XQuery en Constante mappings Op het gebied van transformaties scoort Mule voldoende omdat er niet standaard ondersteuning voor XQuery geboden wordt. Indien gewenst kan er een custom tranformer gebouwd worden voor XQuery. Hetzelfde geldt voor constante mappings. Pagina 19 van 46
Patronen: publish-subscribe en queues Mule ondersteunt een groot aantal patronen, waaronder publish-subscribe. Voor het opslaan van berichten in een zogeheten queue zal Mule aangesloten moeten worden op een Queuing Provider. De meest bekende producten (zowel open source als commercieel) worden door Mule ondersteund. Deze constructie wordt gebruikt bij de meeste commerciële producten (zoals Oracle ESB). Al zijn er ook producten op de markt die zowel ESB funtionaiteit leveren als een queue implemenatie (bijvoorbeeld de Sonic ESB van Progress). Traceerbaarheid Traceerbaarheid betreft eigenschappen van de software die van invloed zijn op de inspanning benodigd voor het vaststellen van de correctheid van gegevensverwerking op gewenste punten. Rotterdam kiest ervoor om traceerbaarheid en monitoring via een centrale oplossing te realiseren en niet per middleware element. Het gaat immers om de traceerbaarheid van de berichten die behalve via de ESB ook via andere componenten (services, orkestratie) verwerkt worden. Mule scoort hierop voldoende. JMX wordt standaard ondersteund, voor SNMP kan een eigen connector geschreven worden, mocht Rotterdam ervoor kiezen om SNMP te gebruiken in plaats van JMX. Overige eigenschappen met betrekking tot functionaliteit Op alle overige eigenschappen met betrekking tot functionaliteit die zijn getoetst in het bureauonderzoek (accuratesse, koppelbaarheid, compliance en beveiliging) scoort Mule goed. Veranderbaarheid Veranderbaarheid behoort tot de categorie Onderhoudbaarheid en betreft Eigenschappen van de software die van invloed zijn op de inspanning benodigd voor het wijzigen, het aanpassen, het verwijderen van fouten of het veranderen van de omgeving van de software. Mule is modulair opgebouwd en kan door middel van tools gecompileerd worden. Mule scoort goed op dit kwaliteitsaspect. Beheerbaarheid Beheerbaarheid behoort ook tot de categorie Onderhoudbaarheid en betreft Eigenschappen van de software die van invloed zijn op de inspanning benodigd voor het draaien van software. Mule scoort goed op dit kwaliteitsaspect. Volwassenheid Volwassenheid behoort tot de categorie Betrouwbaarheid en betreft Eigenschappen die van invloed zijn op de frequentie van falen door fouten in de software. Mule scoort goed op dit kwaliteitsaspect. Mule is meer dan drie jaar oud, heeft klanten over de hele wereld en een grote actieve community. Dit blijkt onder andere uit MuleForge, waar allerlei extensies op Mule ontwikkeld worden door de open source community. Beschikbaarheid Beschikbaarheid behoort tot de categorie Betrouwbaarheid en betreft Eigenschappen Pagina 20 van 46