Dat een doorsnee administratieve applicatie uit drie lagen bestaat, de presentatie-, de applicatielogica- en de databaselaag, is voor de meeste IT’ers gesneden koek. Misschien zijn de drie lagen niet in alle applicaties expliciet aanwezig, dan toch bevat elke applicatie die drie functies.
Het is echter de vraag hoelang we nog in drie lagen zullen blijven denken. Indien we services gaan adopteren, dan zullen de applicaties eerder uit vier dan uit drie lagen bestaan. In feite zal de laag met applicatielogica opgesplitst worden in twee nieuwe lagen: de services en de processen.
Service is op zich geen applicatie. Voorbeelden van applicaties zijn het factureringssysteem en het voorraadbeheersysteem. In elke applicatie zitten services verborgen. Denk hierbij aan een service om de kredietwaardigheid van een nieuwe klant te controleren of het reserveren van een hotelkamer. In enkele gvallen zijn deze services duidelijk in de code aanwezig in de vorm van procedures of componenten, maar als we naar bestaande applicaties kijken, dan zijn ze vaak verstopt. Soms zijn ze zelfs zo diep opgeborgen dat een externe applicatie ze niet eens kan aanroepen.
Services kunnen interne modules zijn, maar ook externe. Een reisbureau maakt bijvoorbeeld gebruik van een service van een vliegtuigmaatschappij om een vlucht te reserveren, of een financieel systeem raadpleegt een externe service voor de koers van de Amerikaanse dollar.
Om te kunnen communiceren met services, of met andere woorden, om services aan te roepen, is enkele jaren geleden een standaard bedacht, genaamd Soap. De wijze waarop de services intern geïmplementeerd zijn, kan sterk variëren. Het kunnen gloednieuwe services zijn geschreven in moderne talen of legacy applicaties waarop een Soap-laag gelegd is. Vandaag de dag kunnen we via Soap al Cics-transacties, SAP R/3-functionaliteit, Javabeans en zelfs database stored procedures aanroepen.
Indien al die bestaande en nieuwe services bereikbaar worden voor andere applicaties, dan spreken we over een SOA (Service Oriented Architecture). De services zijn dan waarschijnlijk via een bus-structuur aan te roepen.
Maar als al die services beschikbaar zijn, wat dan? Wie gaat ze aanroepen? De bedoeling is dat we boven op de services processen gaan definiëren. En deze processen zullen de services activeren. Bijvoorbeeld het proces boek-een-vakantie roept de service reserveer-een-vlucht aan. Voor de duidelijkheid, meerdere processen kunnen één en dezelfde service aanroepen en een proces roept meerdere services aan.
Nu zijn vaak de processen verspreid over meerdere applicaties en verstopt in de code. Met een SOA gaan we ze expliciet maken.
De standaard taal die een grote kans maakt om de taal te worden voor het formuleren van processen, is Bpel4ws (Business Process Execution Language for Web Services); spreek uit biepul. Deze door IBM en Microsoft bedachte taal staat ons toe met een executeerbare taal de processen zodanig formeel te definiëren dat ze executeerbaar is. Zogenaamde orchestration engines zullen de in Bpel4ws geschreven processen lezen en verwerken. Verwerken betekent dat de onderliggende services aangeroepen worden.
Is dit alles toekomstmuziek? Nee hoor, want er zijn al diverse, commercieel beschikbare orchestration engines, waaronder die van Collaxa, Intalio, Openstorm en Seebeyond. En IBM en Microsoft zullen snel volgen.
Het is nu nog te vroeg om met zekerheid te zeggen dat dit inderdaad zal gaan gebeuren. Maar als de SOA aanslaat, dan zou Bpel4ws weleens kunnen uitgroeien tot een van de belangrijkste ontwikkeltalen. De klassieke drie-lagen applicatie zal dan verdwijnen. Misschien zullen we in de toekomst geen applicaties meer ontwikkelen, maar services en procesdefinities. Grappig, automatisering zonder applicaties!< BR>
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
