Elke service georiënteerde architectuur bestaat uit een aantal lagen. Het fundament wordt meestal gevormd door de bestaande applicaties. Hierop draaien primitieve services. Dit zijn vaak kleine, tamelijk technische services die ons toegang geven tot de functionaliteit van die onderliggende applicaties. De interface van deze primitieve services zullen vooral gebaseerd zijn op SOAP en XML en zullen via een Enterprise Service Bus (ESB) benaderbaar zijn.
Stel dat een organisatie beide lagen klaar heeft. Dan is het punt bereikt dat we de bestaande applicaties via die services kunnen hergebruiken. Er kunnen nieuwe applicaties gebouwd worden die gebruik maken van die primitieve services.
Momenteel is er nog een strijd gaande met als inzet wie de dominante leveranciers van ESB’s zullen worden. Deze strijd zal nog wel zo’n twee jaar voortduren. Er zullen ongetwijfeld drie of vier winnaars komen. De kans is groot dat daarna de ESB’s het predikaat ‘commodity’ opgeplakt krijgen, net als eerder met applicatieservers is gebeurd. Het is niet eens uitgesloten dat ze in de doos met de besturingssystemen meegeleverd worden.
Wie er ook als winnaar uitkomt, deze discussie zal naar de achtergrond verdwijnen en een belangrijkere zal in de schijnwerpers komen te staan: met welke tools en of talen gaan we die nieuwe applicaties maken die op die primitieve services draaien? Hiermee zal uiteindelijk door de meeste organisaties de winst gepakt moeten worden en een ROI gehaald worden. De nieuwe applicatie, we noemen deze voor het gemak maar even SOAPP (Service Oriented Application), is waarom we met SOA begonnen zijn, waarom we hier geld en tijd in geïnvesteerd hebben.
Vandaag kunnen we al kiezen uit zeer uiteenlopende oplossingen om SOAPP’s te maken, want steeds meer leveranciers gaan zich op deze markt richten.
Natuurlijk kan voor de Spartaanse manier gekozen worden. Talen als C# en Java worden dan gebruikt om services te combineren tot applicaties. Dit lijkt me echter tijdrovend en kostbaar. Als we de vraag stellen welke it’ers de SOAPP’s zullen ontwikkelen, zal het antwoord vaak luiden dat het de business-georiënteerde zijn. Deze groep zit uiteraard niet te wachten op programmeren in technische programmeertalen.
Of komt het antwoord van UML? Met tools van IBM (Rational) en van Compuware (OptimalJ) kunnen we onze applicatielaag met behulp van UML ontwerpen en daarna de Java-code laten genereren. Volgens mij is deze weg te verkiezen boven de vorige. Deze route zal veel architecten aantrekken.
We zien ook weer een aantal oudgedienden die hiervoor speciale tools ontwikkelen. Software AG komt deze winter bijvoorbeeld met een tool en Sybase is al klaar (WorkSpace). Beide hebben veel ervaring met ontwikkeltools en hebben bewezen robuuste oplossingen te kunnen neerzetten. Vergeet ook leveranciers als Progress niet, die deze markt eenvoudig kunnen binnenwandelen (in het geval van Progress via dochter Sonic).
Bedrijven als Cordys en Oracle kiezen meer voor talen als BPEL of BPEL-achtigen om services aan elkaar te knopen. Zeker gezien vanuit het business-georiënteerd denken is dit een goed alternatief.
Ook nieuwe leveranciers als Above All Software en Composite Software moeten we niet onderschatten. Zij leveren speciale tools voor het ontwikkelen van meer business-georiënteerde services vanuit de primitieve services. Niet dat zij kunnen concurreren met de grote spelers, maar ze kunnen de tools bouwen die straks door een grote leverancier opgekocht en gedistribueerd worden.
De strijd zal ongetwijfeld begin volgend jaar losbarsten. Ik ben reuzebenieuwd wat de markt gaat kiezen. Het zal voor een groot deel afhankelijk zijn van de aard van de ontwikkelaars die deze laag gaan ontwikkelen. Hebt u al een keuze gemaakt?
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
