Wanneer we het over SOA hebben is de link naar een Enterprise Service Bus (ESB) meestal al snel gelegd. Maar is het dan al nodig om een commercieel product aan te schaffen? Of zijn er ook open source alternatieven?
Na wat rondsnuffelen op het Internet kwam ik al snel tot de conclusie dat er serieuze alternatieven zijn voor de huidige commerciële SOA-stacks. Zo heeft de Apache Software Foundation een flinke stapel producten die een zeer volledige stackvormen, te weten ActiveMQ voor messaging, AXIS2 voor de SOAP-stack, ServiceMix als ESB, ODE als de orkestratie engine en jUDDI als directory. IONA Technologies baseert zo haar FUSE open source SOA product voor een groot deel op deze producten van Apache, maar dan weliswaar als gecertificeerd werkend geheel. Overigens niet vreemd dat IONA Technologies zo stevig steunt op Apache componenten; enkele delen zijn qua ontwikkeling voor een groot deel afkomstig uit eigen stal (Celtix), dan wel aangekocht (overname LogicBlaze).Maar ook het open source Mule en JBOSS ESB zijn behoorlijk volwassen producten aan het worden.
Over het experimenteren met SOA-stacks dus geen zorgen; voldoende keuze, prima gebruik van standaarden en over openheid geen misverstanden. Mijn vraag leek beantwoord, echter had plaatsgemaakt voor vele nieuwe. De meest prangende vraag is toch wel: waarom zou je met zo een prettige keus aan open source SOA producten nog gaan voor een commercieel product? Mule is volgens eigen zeggen al beproefd ingezet bij grote organisaties met succesvolle implementaties van real-life SOA vraagstukken. En aan ondersteuning ontbreekt het ook niet door commerciële backing van MuleSource. IONA Technologies voert een nog explicietere strategie: FUSE de open source lijn en Artix de commerciële lijn; een populair aan het worden hybride business model voor software.
Zo meldt ook een rapport over een door Unisys uitgezette studievraag bij markt forser Forrester over ‘de groeiende acceptatie van open source in bedrijfskritieke applicaties’, dat open source zelfs als belangrijke drijfveer voor SOA wordt gezien.
Uiteraard zijn er best verschillen; zo is een commerciële SOA-stack allicht completer en beter geïntegreerd, voorzien van betere GUI tooling, etc. Echter voor een lichtgewicht SOA implementatie zou een open source SOA-stack best eens een goed alternatief kunnen zijn, misschien zelfs wel door het niet hoeven afnemen van een volledige stack, maar slechts het benodigde voor de uitdagingen van nu… en zonder inkooporder.
Is het valide omte stellen dat lichtgewicht SOA implementaties best op een open source stack geïmplementeerd kunnen worden? Zijn er al ervaringen?
Gershon Janssen
Ik denk dat het vooral met de vraag van support te maken heeft. Wil je dat over 3 jaar de oplossing die gebouwd is op basis van open source software nog steeds geserviced wordt, ook al is de community uiteen gevallen? Wat dan als er door patchen van het OS de open source ESB niet meer werkt? Ik denk dat initiatieven zoals JBOSS die inmiddels een flinke stabiele community hebben opgebouwd en een stabiel groeiend marktaandeel hebben best een goed(koop) alternatief voor commerciele software kunnen zijn.
Vind het erg interessante observatie. Zien we ook dat de leveranciers open source code in hun software integreren?
Hoi Gershon,Recentelijk heb ik Netbeans 6 eens bekeken en de orchestratie ontwikkelomgeving ziet er in ieder geval op het eerste gezicht veelbelovend uit. jUDDI is absoluut (nog) geen serieus alternatief voor een commercieel serviceregister. Dit is puur een UDDI server API met een hele simpele schil. Het is niet te vergelijken met bijvoorbeeld een product als Systinet. Hierbij moet ik wel aanmerken dat ik nog niet naar de nieuwste versie heb gekeken (2.0 release 5) De reden hiervoor was het gebrek aan documentatie van deze release (ook niet echt een goed teken). Groeten,Linda