Onderzoek Open Source Ondersteuning SGA
Onderzoek Open Source Ondersteuning Service Gerichte Architectuur
Opdrachtgever Projectleider Versie Status Datum
: : : : :
Bestuursdienst Gemeente Rotterdam Folkert-Jan de Groot ( 06 – 51 277 300 ) 1.2 Definitief 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
6
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
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.
Uitvoeren van een Proof of concept met Mule als ESB.
5.
Bureauonderzoek naar de functionele aspecten die niet in het PoC zijn getoetst.
6.
Onderzoek naar aspecten ten aanzien van dienstverlening.
7.
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 1 gekozen voor het Quint2/Extended ISO-Model . 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 2 het Quint2 model. Daarnaast zijn de eisen die in QSOS 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
1 2
Toelichting Lightweight ESB with a custom implementation model. http://www.mulesource.org
Sun OpenESB
https://open-esb.dev.java.net/
Apache ServiceMix
JBI implementatie (standaard voor ESB's).
http://www.softwarekwaliteit.nl/index.php?title=Quint2 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 gegevensmagazijn via de ESB. Verwerkingstijd op een voor Rotterdam representatieve set . Testen op foutmarge, gemak van foutdetectie, en eventueel foutcorrectie.
2.
PoC-GM
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.
3.
PoC-TMF
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
4.
PoC-WABO
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
van de software die van invloed zijn op de tijd dat het product beschikbaar is voor de gebruiker, op de momenten dat het beschikbaar moet zijn’. Mule scoort voldoende op dit aspect. Dit wordt voornamelijk veroorzaakt door het feit dat het installeren van een nieuwe service op een Mule instantie niet kan zonder Mule te herstarten. Er zijn hiervoor wel work arounds mogelijk. Bijvoorbeeld het inzetten van een load balancer, zodat requests op een andere instantie terecht komen. Tijdsgedrag Tijdsgedrag behoort tot de categorie Efficiëntie en betreft ‘Eigenschappen van de software die van invloed zijn op de reactie- en verwerkingstijden en op de doorvoercapaciteit’. Mule scoort goed op dit aspect. Resourcegedrag Resourcegedrag behoort ook tot de categorie Efficiëntie en betreft ‘Eigenschappen van de software die van invloed zijn op de hoeveelheid gebruikte resources en de tijd gedurende welke de resources worden gebruikt’. Mule scoort goed op deze aspecten. Onderhoudbaarheid Een verzameling attributen die van invloed is op de inspanning benodigd voor het maken van gespecificeerde wijzigingen. Mule scoort op analyseerbaarheid en veranderbaarheid goed. Hierbij moet aangetekend worden dat er ondersteunende tooling nodig is voor het raadplegen van de verschillende informatiebronnen. Mule levert informatie ten behoeve van onderhoudbaarheid, maar biedt geen grafische ondersteuning hiervoor. Dit is conform de technische architectuur zoals beschreven in de component architectuur gegevensuitwisseling. Betrouwbaarheid Betrouwbaarheid betreft de mate waarin de software in staat is te functioneren onder vastgestelde voorwaarden tijdens een vastgestelde periode. Mule scoort hierop goed, met uitzondering van beschikbaarheid, hierop scoort Mule voldoende. De configuratie van Mule moet zo ingericht worden, dat de gewenste beschikbaarheid gerealiseerd kan worden. Hiervoor zijn verschillende mogelijkheden. Overdraagbaarheid Mule biedt goede ondersteuning op het gebied van overdraagbaarheid. Dit betreft eigenschappen om de software van de ene omgeving naar de andere over te dragen. Mule scoort goed op deze eigenschappen door de modulaire opbouw, de mogelijkheid configuraties en eigenschappen los te definiëren en de ondersteuning voor automatische installatie. Conclusie Mule scoort voldoende tot goed op alle kwaliteitsaspecten. Ondersteuning voor het maken van alternatieve oplossingen wordt zeer goed ondersteund door Mule via standaard interfaces en het definiëren van uitbreidingspunten. Daarnaast is er een actieve community waar extensies ontwikkeld worden. Voorwaarde is dat er duidelijke richtlijnen komen voor de extensies zodat deze ook beheerd en hergebruikt kunnen
Pagina 21 van 46
worden. Op basis van het bureauonderzoek wordt een positief advies gegeven met betrekking tot Mule als keuze voor de concern ESB.
3.2
DIENSTVERLENINGSASPECTEN Hoewel open source gemeenschappen bekend staan om hun grote informele ondersteunende vermogen, is dit geen vervanging voor intensieve professionele ondersteuning. Ook geeft de gemeenschap geen enkele garantie op de kwaliteit van de software of de beschikbaarheid op lange termijn. Bij de inzet van open source software is het daarom van belang goed na te denken over deze drie aspecten: • Duurzaamheid. Wat is het toekomstperspectief van de software en is de dienstverlening ook op langere termijn beschikbaar? • Licentiemodel. Welke mogelijkheden en beperkingen zijn verbonden aan het licentiemodel waaronder de software gebruikt mag worden? • Het afdekken van risico’s. Welke afspraken kunnen gemaakt worden ten aanzien van garantie en aansprakelijkheid? • Ondersteuning. Welke mogelijkheden zijn er voor het leveren van ondersteuning bij de installatie en het gebruik van de software?
3.2.1 Duurzaamheid Mule is een open source product maar wordt gesponsored door een commerciële partij, namelijk het Amerikaanse MuleSource. Dit bedrijf heeft Mule ontwikkeld en is het centrum van de Mule community. Het onderhoud is niet afhankelijk van enkele indivuele ontwikkelaars maar wordt gesteund door een gespecialiseerd team dat baat heeft bij een zo grote mogelijk verspreiding van het product. Hiermee is de continuïteit in doorontwikkeling van het product geborgd (tot op zekere hoogte). Inherent aan de aard van open source is dat de duurzaamheid van de software gegarandeerd is in die zin dat de broncode beschikbaar is en de gebruiker desnoods zelf het onderhoud op zich kan nemen. Maar het uitgangspunt is natuurlijk dat het onderhoud in de community plaatsvindt. De afhankelijkheid van die community is daarom groot. Om die reden wordt ook in de QSOS-criteria al rekening gehouden met de duurzaamheid van een product en is daarmee onderdeel geweest van de voorselectie. In QSOS scoort Mule op ‘Intrinsieke duurzaamheid’ een score van 1.34 van maximaal 2, dit is een goede score. Deze score is gebaseerd op een aantal kengetallen en is een momentopname. De status van de Mule community ten tijde van dit schrijven is: Kengetal
Waarde
De grootte van de community Aantal leden van de community
19.036
Aantal organisaties waarvan bij Mulesource bekend is dat ze
6.000
Mule gebruiken Actieve ontwikkelaars
17
Pagina 22 van 46
De activiteit van de community als het gaat om bugs en nieuwe ontwikkelingen Aantal bugs open
626
Aantal bugs gesloten
3435 (sinds april 2005)
Aantal releases in 2009
4 (2.1.3/2.1.4/2.2/2.2.1/2.5)
Roadmap voor komende versies
Beschikbaar
3.2.2 Licentiemodel Mule wordt geleverd onder de voorwaarden van de Common Public Attribution Licence Version 1.0 (CPAL). Deze licentie verschaft vrij gebruiksrecht op de software, maar tegen bepaalde voorwaarden. De CPAL-licentie is gebaseerd op de Mozilla Public Licence (MPL) maar heeft daar twee belangrijke aanpassingen op gemaakt. Belangrijke kenmerken van MPL: • Code uit de distributie die aangepast wordt en weer gedistribueerd wordt, moet onder de MPL worden gedistribueerd. Het is niet verplicht om deze aanpassingen te distribueren. • Code die nieuw wordt toegevoegd aan de distributie mag onder elke licentie worden gedistribueerd, dus ook een commerciële (dit in tegenstelling tot de GPL). Het is niet verplicht om deze aanpassingen te distribueren. Verschil tussen CPAL en MPL: • De CPAL kent een ‘Attribution-clause’. Dit betekent dat software die gebruik maakt van de broncode een verwijzing naar de originele Auteur in beeld moet brengen. a. Mule kent geen grafische interface voor eindgebruikers waardoor deze clausule zich beperkt tot een verwijzing in de bronbestanden. b. Mule geeft aan dat dit voor intern gebruik niet van toepassing is. •
De CPAL vereist dat het gebruik van de software over een netwerk gezien wordt als distributie van de broncode. Dit betekent dat een applicatie die gebruik maakt van de broncode van Mule en bedoelt is om over een netwerk te gebruiken, onder de CPAL licentievoorwaarden moet vallen.
Ook al lijkt het risico bij het gebruik van deze licenties klein, het verdient toch aanbeveling om hier een expertadvies over in te winnen. De licentie is opgesteld in het Engels onder het recht geldend in California. Er is geen beleid ten aanzien van open source software en de inkoopjuristen van de gemeente konden geen uitsluitsel geven over de acceptatie van de licentie anders dan dat de algemene inkoopvoorwaarden van toepassing verklaart zouden moeten worden.
3.2.3 Afdekken van juridische risico’s In paragraaf 1.2 zijn de risico’s bij het gebruik van open source software en de
Pagina 23 van 46
3
mogelijke maatregelen geïntroduceerd , zijnde: #
Risico
Kans en impact
Mogelijke maatregelen
1.
Inbreuk op intellectueel
De kans is klein. In de praktijk
Vrijwaring van de
eigendom
zijn dergelijke claims bijzonder
leverancier of een
schaars en is nog nooit een claim
tussenpersoon.
toegewezen. De impact hangt af van de inhoud van de claim maar
Audit op de broncode.
kan groot zijn. Bijvoorbeeld als het volledige gebruik van de software gestaakt moet worden. 2.
Schade door gebrekkige
Er zijn geen gegevens
Aanvullende afspraken
software
beschikbaar die aangeven of de
maken met een
kans op schade groter of kleiner
tussenpersoon ten
is dan bij gesloten software.
aanzien van garantie en
Indien de kans groot zou zijn,
aansprakelijkheid.
zou dit zeker bekend zijn. Hieruit kan men afleiden dat de kans gemiddeld tot klein is.
Voor het omgaan met deze risico’s bestaan in het geval van de Mule ESB twee mogelijkheden: 1. Accepteren en geen aanvullende maatregelen nemen. Indien de gemeente van mening is dat de kans op het voordoen van deze risico’s klein is en de impact van de risico’s onvoldoende groot is, dan moet er vooral geen geld besteed worden aan het afdekken van deze risico’s. 2. Aanschaf van de Mule Enterprise Edition. Hierbij wordt namelijk geleverd: • Vrijwaring op claims van inbreuk op intellectueel eigendom. • Garantie op de software. Onduidelijk is wat deze garantie inhoudt. We hebben op dit moment niet de beschikking over de garantiebepalingen. Ongetwijfeld blijft aansprakelijkheid vergaand uitgesloten. De tussenpersonen die in het kader van het onderzoek geïnterviewd zijn (Cap Gemini en Atos Origin) leveren geen vrijwaring op de software en bieden geen afspraken ten aanzien van garantie en aansprakelijkheid.
3
Dit zijn uitsluitend risico’s ten aanzien van het gebruik van open source software. Indien de gemeente van zins is zelf software te (laten) maken en deze onder een open source licentie ter beschikking te stellen zijn andere maatregelen nodig.
Pagina 24 van 46
3.2.4 Ondersteuning Voor het verkrijgen van ondersteuning op Mule bestaan drie kanalen: 1. De community, deze ondersteuning is vrij beschikbaar. 2. MuleSource (de leverancier van Mule); Hiervoor dient de Enterprise Edition aangeschaft te worden. 3. Dienstverlener (Atos, Cap Gemini, ...); Hiervoor dient een contract gesloten te worden. Ondersteuning door de community Voor ondersteuning van Mule (de Community Edition) kan een beroep gedaan worden op de community. Deze community biedt hiervoor de volgende mogelijkheden: • Documentatie (voorbeelden en ‘getting started guide’). • Mailing lijst. • Issue tracker. • Discussieforum. • Aanmelden van bugs. Regelmatig wordt een nieuwe versie van Mule gepubliceerd die kan worden gedownload. Daarnaast bestaat er een platform (MuleForge) voor het ontwikkelen en hosten van uitbreidingen op de Mule ESB. Ondersteuning door MuleSource MuleSource biedt ook een commerciële versie van Mule aan. Het open source gedeelte van die commerciële versie is gelijk aan de gratis versie. Het commerciële pakket daarbovenop bevat (zie 5.2 Bijlage: MuleSource ondersteuning): • Extra functionaliteiten in de Mule ESB. • Kwaliteitsgaranties op de software. • Een licentie voor de beheersoftware Mule HQ. • Extra documentatie. • 24x7 ondersteuning middels: o Toegang tot een ‘support portal’. o Drie niveau’s van beheer: Silver, Gold, Platinum. Met als belangrijkste verschillen: Silver
Gold
Platinum
Named contacts
1
2
3
Number of incidents
10
30
75
Response time
2d
1d
2h
Real-time diagnostics
Daarnaast biedt MuleSource commerciële diensten aan voor training en advies. MuleSource heeft een kantoor in San Francisco en een kantoor in Londen. Dit maakt het leveren van on-site ondersteuning lastig.
Pagina 25 van 46
Ondersteuning door een tussenpersoon In het kader van dit onderzoek zijn gesprekken gevoerd met Cap Gemini en Atos Origin. Beide partijen hebben hun open source dienstverlening opgebouwd vanuit hun ervaringen in Frankrijk. Het gebruik van open source software is in Frankrijk beduidend meer ingeburgerd dan in Nederland. Beide partijen bieden dienstverlening op Mule en hebben kenniscentra in zowel Nederland als Frankrijk. In feite worden dezelfde diensten aangeboden als voor commerciële producten. Onderstaande tabel geeft de normen aan die Cap Gemini aanbiedt voor Mule. Wat daarin opvalt is dat er wel normen zijn opgenomen voor het leveren van een tijdelijke oplossing, maar niet voor een definitieve. Reaction time
Intermediate Solution
type
delivery time
kpi
delivery time
kpi
Prio 1
< 1 hr
99%
<1 day
90%
Prio 2
< 1 hr
99%
<2 days
90%
Prio 3
< 1 hr
99%
<5 days
90%
Prio 4
< 1 hr
99%
<8 days
90%
Corrective Solution delivery time
kpi
Zie 5.3 Bijlage: Cap Gemini ondersteuning. Naast de directe ondersteuning op de installatie en inrichting zijn er ook mogelijkheden voor het afnemen van andere diensten zoals: • Technology watch: het op de hoogte houden van ontwikkelingen in de techniek. • Strategic watch: het in de gaten houden van de markt en het identificeren van trends. Een contract met een tussenpersoon is interessant indien die partij veel kennis heeft van de technische omgeving in de organisatie, bijvoorbeeld omdat ze betrokken zijn bij enkele ontwikkeltrajecten. De lijn van ontdekken van het probleem naar expertise inroepen naar oplossing van het probleem is dan kort. Indien de tussenpersoon geen kennis heeft van de ICT-omgeving moeten er allerlei interpretatieslagen gemaakt worden en is de kans op fouten in de communicatie groot.
Pagina 26 van 46
3.3
ORGANISATORISCHE ASPECTEN Uit het onderzoek is gebleken dat in het geval van Mule er meerdere partijen beschikbaar zijn voor dienstverlening. Het is zelfs zo dat Mule eigenlijk gewoon door een commerciële partij (Mulesource) wordt geleverd en onderhouden. Daarnaast zijn er partijen zoals Atos Origin en Cap Gemini die ook als tussenpersoon kunnen fungeren. Op basis daarvan kan men stellen dat de inzet van Mule, alleen omdat het open source is, geen andere gevolgen voor de organisatie heeft dan de inzet van een gesloten product. Indien men er voor kiest om geen tussenpersoon in te schakelen dan is de logische consequentie dat alle activiteiten in het kader van het applicatiebeheer door de interne organisatie moeten worden uitgevoerd. Dit vraagt een hele actieve en kennisintensieve rol. Onderdeel van de implementatie van Mule zal zijn een keuze te maken tussen deze dienstverleningsmodellen. Migratie Het advies van de werkgroep is om de consequenties voor migratie van bestaande 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 elke andere willekeurige ESB. Al eerder is vastgesteld dat een andere ESB dan de huidige Oracle ESB noodzakelijk is om in alle behoeften te voorzien. Training, migratie en inpassing in de bestaande infrastructuur zal daarom altijd nodig zijn.
3.3.1 Roadmap Allereerst zal besluitvorming plaatsvinden door de stuurgroep van dit project. Daarna zal een notitie ingebracht worden in de Stuurgroep Bedrijfsvoering op 11 juli. De week daarvoor zal behandeling nodig zijn in de ICT Adviesgroep. De besluitvorming omvat de opdrachtverlening voor het vervolg, bestaande uit twee parallele stromen: 1. Het vervolg naar de mogelijkheden van open source ondersteuning bij SOAsoftware. 2. De implementatie van Mule. Gedurende dit onderzoek is de beschikbare capaciteit van de werkgroep een groot probleem gebleken. De lange doorlooptijd van het onderzoek is hier een direct gevolg van. Voor de vervolgstappen zal capaciteit expliciet gereserveerd moeten worden. Onderstaande road map bevat een geschatte doorlooptijd. Voor elk van de twee hoofdlijnen zal een plan van aanpak geschreven moeten worden waarin een gedetailleerde planning wordt opgenomen, inclusief benodigde capaciteit.
Pagina 27 van 46
Activiteit Besluitvorming
Maand 1
Maand 2
Maand 3
Maand 4
x
Vervolg onderzoek open source Opstellen Componenten Architecturen Onderzoek Component Services Onderzoek Component Orkestratie Onderzoek Migratie
Implementatie van Mule Afsluiten dienstverleningscontract Technische implementatie van Mule Beschrijven Mule als TW Dienst Inrichten functioneel beheer Voorbereiden ontwikkelorganisatie Governance overdragen
Vervolg onderzoek open source ondersteuning Het vervolg van dit onderzoek kan de aanpak blijven volgen zoals deze tot nu toe is geweest, namelijk per component (Services en Orkestratie): 1. Architectuur opstellen. 2. Eisen en criteria opstellen. 3. Bureauonderzoek en eventueel een Proof of Concept. 4. Rapportage en besluitvorming. De huidige projectgroep kan gehandhaafd blijven, incidenteel aangevuld met een vertegenwoordiging van service eigenaren (informatiemanagers) en proceseigenaren. Voor het vervolg van het onderzoek naar open source zal overwogen moeten worden in hoeverre de component Gouden Gids nog steeds buiten scope valt. Het is namelijk zo dat inmiddels stappen zijn gezet in de beleidsvorming daaromtrend die het mogelijk maken te starten met softwareselectie. Tevens is een project gestart voor het opstellen van een architectuur voor de componenten Services en Gouden Gids. Voor de component Orkestratie bestaat, in ieder geval in de architectuur, een directe afhankelijkheid met het BPM-project dat opgestart gaat worden. Een aanvullend risico hierin is dat er nog weinig ideëen binnen de gemeente Rotterdam zijn op het gebied van bijvoorbeeld human workflow en business rules. Implementatie van Mule Na besluitvorming door de Stuurgroep Bedrijfsvoering kan worden gestart met de technische en organisatorische implementatie van Mule. Voorgesteld wordt om na een positief advies van de Stuurgroep SOA te starten met een plan van aanpak voor de implementatie zodat begin oktober een geïmplementeerde generieke ICT
Pagina 28 van 46
component binnen de Concern Informatie Architectuur beschikbaar is. Onderstaande activiteiten worden onderscheiden, per activiteit is aangegeven wie er bij betrokken moeten worden en wat de geschatte doorlooptijd is. Afsluiten van een dienstverleningscontract Er zal een definitieve keus gemaakt moeten worden voor het dienstverleningsmodel. Op basis daarvan kan een inkoopprocedure gestart worden. Betrokkenen: OIM, TWD, IOO, Inkoopbureau. Technische implementatie van Mule De technische implementatie is een belangrijk onderdeel van het onder architectuur brengen van Mule. Het valt uiteen in de volgende activiteiten: • Opleiden technisch beheerders • Opstellen installatiehandleiding • Opstellen en inrichten technische architectuur • Aanschaf benodigde hardware • Inrichten operationele monitoring en logging Betrokkenen: TWD, IOO en externe expertise (b.v. R. Swart) Beschrijven van Mule als TW Dienst Naast een technische implementatie dient er een organisatorische inbedding plaats te vinden binnen de TWD, hiervoor is nodig: • Beschrijven van Mule als TW-dienst. • Exploitatievoorstel voor Mule als generieke TW Dienst. Betrokkenen: TWD Inrichten functioneel beheer Gekoppeld aan het leveren van Mule als TW-dienst is de inrichting van functioneel applicatie beheer op Mule als generiekee ICT component (SO-GICT): • Opstellen van eisen aan opleveringen die gebruik maken van Mule. • Inrichten van functionele monitoring en logging. Betrokkenen: SO-GICT, IOO en externe expertise (b.v. R. Swart) Voorbereiden ontwikkelorganisatie De stabiliteit en beheersbaarheid van een infrastructuur is voor een deel afhankelijk van de kwaliteit van de ontwikkelde software en het overdrachtsproces tussen de ontwikkel- en de beheerorganisatie. Daarom zullen ook de ontwikkelorganisaties voorbereid moeten worden op het gebruik van Mule, bestaande uit de volgende activiteiten: • Afspraken maken t.a.v. functionele monitoring bij de ontwikkeling van toepassingen . • Opleiden van ontwikkelaars. • Opstellen van ontwikkelstandaarden t.a.v. Mule. Betrokkenen: SO-GICT, IOO en externe capaciteit (b.v. R. Swart)
Pagina 29 van 46
Governance Nadat Mule als dienst is ontwikkeld dient het demand management te worden overgenomen door de DO-GICT . Betrokkenen: DO-GICT, SO-GICT
3.3.2 Kosten Het vergelijken van kosten is, zonder volledige inkoopprocedure, een lastige zaak. De producten zijn allemaal erg verschillend qua functionele scope. Daarnaast is het ene product wellicht eenvoudiger in beheer of vraagt minder hardware-resources. Een volledige TCO-berekening is niet haalbaar, 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]. De Mule ESB is gratis verkrijgbaar, maar er is ook een Enterprise Edition beschikbaar. Deze biedt additionele functionaliteiten, monitoring software en extra documentatie. Dit wordt gebundeld met een juridische vrijwaring en support. De kosten voor aanschaf van deze Mule ESB Enterprise Edition, inclusief drie jaar 4 support , zijn ongeveer € 190.000. Hiermee kunnen drie quad-core productieservers worden ingericht, één testserver en één ontwikkelserver. Om een idee te geven van het verschil in kosten tussen verschillende ESB-producten (zowel open als gesloten software) is in 5.5 Bijlage: ESB Kostenvergelijking een onderzoek van het Utah Department of Technology Services uit oktober 2006 opgenomen. De totale kosten komen in dat onderzoek, verspreid over 3 jaar, op: Software Apache Servicemix Aqualogic
4
Totale kosten $ 94.101 1.654.680
IBM Websphere
824.571
Mule
143.541
Zie bijlage 5.2 voor informatie over support. Voor de schatting is uitgegaan van niveau Gold.
Pagina 30 van 46
4
CONCLUSIES EN ADVIES Het onderzoek gaat om de vraag of het mogelijk is om binnen de gemeente Rotterdam een open source product in te zetten als Enterprise Service Bus en deze tot standaard te benoemen. Gebleken is dat Mule ESB hiervoor geschikt is. 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: de communicatie met de Overheids Service Bus. 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. De drijvende kracht achter Mule is een commerciële partij, namelijk Mulesource. Naast de vrij beschikbare versie van Mule levert zij een Enterprise Edition, aangevuld met diensten. Met deze partij kan een supportcontract worden afgesloten. Onderdeel van dat contract is een vrijwaring voor claims van inbreuk op intellectueel eigendom waarmee dat risico kan worden afgedekt. 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 van Mule. Er is binnen de gemeentelijke organisatie onvoldoende expertise beschikbaar om een conclusie te kunnen trekken. Ook al lijken de risico’s marginaal en zijn er geen praktijkvoorbeelden van juridische problemen, toch verdient het aanbeveling hier een uitspraak over te doen. Om duidelijkheid te krijgen zal overleg met Mulesource nodig zijn of kan extern advies ingewonnen worden. 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 zal een bredere strategie bedacht worden. Bij de implementatie van Mule zal rekening gehouden moeten worden met extra configuratiewerk en maatwerk ten behoeve van monitoring en logging. Op financieel vlak kan de keuze voor Mule de gemeente een aanzienlijk kostenvoordeel opleveren door de besparing op licenties en onderhoud.
Pagina 31 van 46
Advies De werkgroep adviseert de Enterprise Edition van Mule aan te schaffen en volgens de roadmap te implementeren en onder architectuur te brengen. De leverancier Mulesource kan worden benaderd als elke andere leverancier. 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. 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. Het zal noodzakelijk zijn om hiervoor capaciteit expliciet te reserveren. De werkgroep adviseert tevens om de consequenties voor migratie van bestaande 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 32 van 46
5
BIJLAGEN
5.1
BIJLAGE: QSOS RESULTATEN
De weging is gebaseerd op de eisen en wensen vanuit de perspectieven van Architectuur, Ontwikkeling en Beheer. ESB Generic section Intrinsic durability Maturity Age Stability History, known problems Fork probability, source of Forking Adoption Popularity (related to: general public, niche, ...) References Contributing Community books Development leadership Leading team Management style Activity Developers, identification, turnover Activity on bugs Activity on functionalities Activity on releases Industrialized solution
ServiceMix 3.1.1 Score Weight 0.8 1 1.34 1.2 1 2 1 0 1 2 1 1 0 2 2 1 1.5 2 1 1 2 0.87
2 2 1 2 1 1 2 2 1 2 2 1 2 0 2 2 2 2 2 2
Mule 1.4.1 Score Weight 1.56 1 1.59 1.8 2 2 1 2 1 2 1 1 0 2 2 1 1.75 2 2 1 2 1.21
2 2 1 2 1 1 2 2 1 2 2 1 2 0 2 2 2 2 2 2
JBossESB 4.2 Score Weight 1 1 1.36 1 1 1 1 1 1 1 1 2 0 2 2 1 1.75 2 2 1 2 0.89
2 2 1 2 1 1 2 2 1 2 2 1 2 0 2 2 2 2 2 2
Pagina 33 van 46
Independence of developments Services Training Support Consulting Documentation Quality Assurance Quality Assurance Tools Packaging Source Debian FreeBSD HP-UX MacOSX Mandriva NetBSD OpenBSD RedHat Solaris SuSE Windows Exploitability Ease of use, ergonomics Administration / Monitoring Technical adaptability Modularity Code modification Code extension Strategy License Permissiveness (only if user wants to own code) Protection against proprietary forks Copyright owners Modification of source code Roadmap Sponsor Strategical independence Basic features Transport Communication modes Synchronous Asynchronous Point-to-point Publish-Subscribe Fire and forget Transaction support Integrated MOM Routing Rule based Content based routing Address based routing Metadata based routing Script based
1 0 0 0 0 2 0 0 0 1.43 2 2 0 0 2 0 0 0 0 0 0 2 0.67 0 1 0.33 1 0 0 0.75 2 2 2 2 1 0 0 0 1.39
1 2 2 2 2 2 2 2 2 2 2 0 0 0 1 0 0 0 2 0 0 2 2 1 2 2 2 2 2 1 1 2 1 1 2 2 1 1 2
1 0 0 0 0 2 1.5 2 1 1.43 2 2 0 0 2 0 0 0 0 0 0 2 1.67 1 2 2 2 2 2 1.13 2 2 2 2 2 0 0 1 1.27
1 2 2 2 2 2 2 2 2 2 2 0 0 0 1 0 0 0 2 0 0 2 2 1 2 2 2 2 2 1 1 2 1 1 2 2 1 1 2
1 0 0 0 0 1 0.5 1 0 2 2 0 0 0 2 0 0 0 2 0 0 2 1 1 1 1 1 0 2 0.5 2 2 2 2 0 0 0 0 0.89
1 2 2 2 2 2 2 2 2 2 2 0 0 0 1 0 0 0 2 0 0 2 2 1 2 2 2 2 2 1 1 2 1 1 2 2 1 1 2
1.07 1.2 2 2 2 0 0 2 0 1.34 0.67 2 0 0 2
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
1.73 1.2 2 2 2 0 0 2 2 0.34 0.67 2 0 0 0
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
1.07 1.2 2 2 2 0 0 2 0 0.34 0.67 2 0 0 0
2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
Pagina 34 van 46
Transformation Formats XML XSLT XQuery Non XML formats Rule based Script based Schema Validation Adapters
1.75 1 1 2 0 1 2 2 2 1.58
2 2 2 2 2 2 2 2 2 2
1.75 1 1 2 0 1 2 2 2 2
2 2 2 2 2 2 2 2 2 2
1.25 1 1 2 0 1 2 0 2 1.89
2 2 2 2 2 2 2 2 2 2
Transport adapters JMS HTTP SOAP FTP SMTP RMI CORBA XMPP Proprietary MOMs Functional Adapters ERP CRM Data adapters DBMS File Advanced features
1.75 2 2 2 2 2 0 2 2 1 2 2 2 1 0 2 1.38
2 2 2 2 2 2 1 0 0 1 2 2 2 2 2 2 1
2 2 2 2 2 2 2 0 2 2 2 2 2 2 2 2 1.57
2 2 2 2 2 2 1 0 0 1 2 2 2 2 2 2 1
1.67 2 2 2 2 2 0 2 0 0 2 2 2 2 2 2 1.15
2 2 2 2 2 2 1 0 0 1 2 2 2 2 2 2 1
1 0 2 1 1 2 0 2 0 2 0 1.33 0.67 0 2 0 1 2 2 0 0 1 2 0 2 2 2
1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
1.5 1 2 1.4 1 2 0 2 2 2 0 1.33 0.67 0 2 0 1 2 2 0 0 1 2 0 2 2 2
1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
1 0 2 0.6 1 2 0 2 0 0 0 0.93 0.67 0 2 0 1 2 2 0 0 1 1 1 2 0 2
1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
Orchestration Business rules BPEL support Security Authentication JAAS support SAML support Authorization Data encryption Data integrity PKI support Administration Monitoring SNMP support JMX support Supported management software QoS Logging Guaranteed delivery Scalability Fault tolerance Process control BAM Exception handling Administration tools Service discovery Development tools
Pagina 35 van 46
Integration Supported standards BPEL Web Services WSDL SOAP UDDI WS-Transaction WS-Coordination WS-Security WS-Reliability WS-Choreography Java standards JCA JBI XML standards XSLT XQuery XSD SCA SCDL support SDO Business Object Business Graph Business Object Type Metadata Business Object Services Plugin architecture Extensiblity APIs Adapter API Transport API
1.56
2
1.57
2
1.68
2
1.81 2 2 2 2 2 2 2 2 2 2 2 2 2 1.33 2 2 0 0 0 0 0 0 0 0 2 1 2 0
1 1 2 2 2 2 1 2 2 1 1 2 2 1 2 2 2 2 0 0 0 0 0 0 0 2 2 2 2
0.85 2 0.62 0 2 0 0 0 2 0 0 0.67 0 2 0.67 2 0 0 0 0 0 0 0 0 0 2 1.5 2 1
1 1 2 2 2 2 1 2 2 1 1 2 2 1 2 2 2 2 0 0 0 0 0 0 0 2 2 2 2
1.4 2 1.23 2 2 2 0 0 2 0 0 2 2 2 0.67 2 0 0 0 0 0 0 0 0 0 2 1.5 2 1
1 1 2 2 2 2 1 2 2 1 1 2 2 1 2 2 2 2 0 0 0 0 0 0 0 2 2 2 2
Pagina 36 van 46
5.2
BIJLAGE: MULESOURCE ONDERSTEUNING MULESOURCE SUBSCRIPTIONS Overview Offered by the original creators of Mule®, MuleSource® subscriptions are the best way to leverage the power of Mule and Mule Galaxy™. With a MuleSource subscription, customers get access to tools and services not otherwise available. For a single annual fee, a MuleSource subscription offers a unique combination of support, sophisticated management tools, and reduced total cost of ownership (TCO), making it a must-have for enterprise-level deployments and mission-critical applications. High-level subscription benefits include:
Pagina 37 van 46
Subscription Overview
Pagina 38 van 46
5.3
BIJLAGE: CAP GEMINI ONDERSTEUNING GROUP 1 ant
GROUP 2
GROUP 3
hibernate
acegi
mapserver
Acceleo
keepalived
hibernate tools
androMDA
mod_jk
Alfresco
lvm
horde
Apache
Mono
amanda
mailscanner
jalopy
argoUML
MRTG
bacula
MailX
javancss
awstats
nagios
bash
mandriva
jdom
BIRT
ntp
bastille linux
mibble
jetty
bogofilter
nutch
Celtix
miranda
jfreechart
bouncycastle
nuxeo
centos
mod_security
junit
cacti
octopus
centreon
mod_ssl
jwebunit
cakePHP
openbravo
clamav
mondorescue
kt-dms
castor
OpenLDAP
compiere
Mule
LemonLDAP
compass
openoffice
cups
mysql
Limesurvey
curl
openWFE
Debian
nareto
log4j
CVS
owl
dimdim
Netbeans
Lucene
cyrus imap
pcre
dspam
nfs
maven
CYRUS SASL
pdfcreator
ejbCA
nmap
maven plugins
DansGuardian
perl
enomalism
ntop
mediawiki
drupal
petals
erp5
Ocs inventory
mevenide
eclipse
php
Fedora Core
OpenESB
mod_perl
eclipse CDT
plone
Fedora Directory
openssl
mootools
eclipse DTP
pluto
firebird
opensta
MyFaces
eclipse ECF
postgresql
freebsd
opensuse
openssh
eclipse JDT
Procmail
gentoo
openwengo
osworkflow
eclipse MWE
python
glassfish
openxchange
phpBB
eclipse Mylyn
rrdtool
glpi
parted
phpmyadmin
eclipse PDT
sakai contrib
groundwork
pentaho
apache CXF
phppgadmin
eclipse RCP
sakai core
heartbeat
POSTFIX
archiva
pmd
eclipse TPTP
SENDMAIL
hyperic HQ
psi
apache commons Beanutils apache commons Betwixt apache commons CLI apache commons Codecs apache commons Collections apache commons Configuration apache commons DBCP apache commons DBUtils apache commons Digester apache commons EL apache commons Email apache commons IO apache commons Javaflow apache commons JCI apache commons Jelly apache commons JEXL apache commons Lang apache commons Logging apache commons Net apache commons Pool apache commons Transaction apache commons Validator apache commons VFS apache commons XML apache commons XML Graphics
Axis
prototype
eclipse WTP
serviceMix
Interldap
qmail
bugzilla
quartz
exim
shorewall
iReport
rsync
cactus
saxon
Ez-Components
slony
ISC BIND
ruby
cargo
spamassassin
Ez-Publish
snort
ISC DHCP
SAMBA
CAS
SPIP
Fetchmail
spring modules
ISC INN
selenium
Pagina 39 van 46
checkstyle
spring
firefox
squidguard
itext
sequoia
continuum
squirrel
FreeRadius
Symfony
Jabber
spagoBI
cruisecontrol
struts
ganglia
Syslog-ng
jasper report
SQUID
dbunit
Subversion
geoserver
talend
JasperServer
tsung
derby
sympa
Gnupg
tcpdump
JBOSS AS
ubuntu
displaytag
the grinder
httpunit
thunderbird
JBOSS ESB
virtual box
dom4j
Tomcat
iptables
vsftpd
JBOSS PORTAL
Wireshark
fop
typo3
jaxen
vtiger
JBOSS Rules
xen
ganttproject
xalan
jdepend
watir
gforge
xdoclet
jetspeed
webalizer
grammatica
Xerces
Jmeter
webmin
Jonas
Weka
Joram
wget
Josso
xmlbeans
kettle
xradar
liferay
zope cps
Jboss Transactions JBPM
zabbix zimbra
mantis
Pagina 40 van 46
Pagina 41 van 46
Pagina 42 van 46
5.4
BIJLAGE: RESULTATEN FUNCTIONELE ASPECTEN Zie bijbehorend Excel document: “Eisen Criteria en Resultaten (1.9).xls”.
Pagina 43 van 46
5.5
BIJLAGE: ESB KOSTENVERGELIJKING Uit: [9] Woolley, R. (2006, Oktober) Enterprise Service Bus (ESB) Product Evaluation Comparisons, Utah Department of Technology Services Cost estimates for each product were based upon a comparable level of effort assumption for initial deployment and ongoing use. Those assumptions need to be verified by applying the evaluation criteria in Appendix A. Some of the solutions have proprietary components and may require greater effort for integration and ongoing support. Training cost estimates are based upon training requirements for the relative complexity of each product, and are based on training for six senior level IT Analyst 3 positions in DTS. The assumption would be that these personnel would serve as resource for training other analysts. This analysis looks at initial procurement and ongoing support costs for each vendor in the comparison and year two and three ongoing cost estimates. Table 8 lists the cost information as supplied by vendors for licensing and support for three environments with two servers in each environment for Production, Acceptance Testing, and Development. Server cost estimates were provided by DTS staff. All cost estimates are based upon a three year cost forecast and assume additional server, licensing, and support resource requirements for each year. Actual server deployment costs and configurations would probably be somewhat lower than the estimated costs.
Table 8: Three Year Cost Comparison
Pagina 44 van 46
(1) Costs supplied by Vendors (2) Assumes intial environments for Acceptance Testing, Production, and Development (2-Linux Dual Processor Servers, 4GB Memory, 1.2TB HD) for each environment (3) Assumes initial training for 6 FTE Analysts at quoted vendor rates (4) Assumes an addition of one Linux Dual Processor Server for years 2 and 3 for Production and Acceptance Testing (5) Assumes support and maintenance cost per Vendor price schedules (6) Assumes additional training for 6 FTE Analysts per year (7) Assumes a 3% of total cost contingency for unplanned expenses
Products with more complexity and component offerings will generally have a correspondingly higher expense for training State technical personnel. For purposes of equity, no attempt was made to assess variations in training complexity from a time perspective with State personnel. Each of the options has some reserves for contingencies. Final cost information will vary, as final deployment configurations are established. In most cases costs will be reduced.
Pagina 45 van 46
6
LITERATUURLIJST [1] NOIV (2008, maart) Het verwerven van (Open Source) Software [2] De Groot, F.J. (2009) Projectplan Onderzoek OSO SGA_v1.0.doc [3] Werkgroep (2009) ESB_Eisen_en_Criteria_IOO_v01.xls [4] Osinga, N. (2009) Pocs_Mule_ESB_v3.doc [5] OSOR Guidelines Public procurement and Open Source Software (2008) European Commission [6] Positionering Gegevensuitwisseling [7] BKAS Handreiking juridische aspecten (2005) [8] Resultaat Stuurgroep (2008-12-08) [9] Woolley, R. (2006, Oktober) Enterprise Service Bus (ESB) Product Evaluation Comparisons, Utah Department of Technology Services
Pagina 46 van 46
