Over het algemeen onderscheiden we drie lagen in een doorsnee administratieve applicatie: onderop de gegevensverwerkende laag, bovenop de presentatielaag en daar tussenin de laag met de applicatielogica. Met de komst van client/server- en internet-technologie zijn we deze lagen over meerdere machines gaan uitsmeren en wordt communicatie tussen en binnen de lagen over netwerken uitgevoerd.
Met de komst van soa’s (service oriented architectures) zal het aantal lagen drastisch toenemen. Er komt een laag waarmee de functionaliteit verborgen in bestaande applicaties ontsloten wordt als services. De interfaces van deze services zullen echter low-level zijn, erg datageoriënteerd. Veelal zullen de interfaces, zoals aanwezig in de applicaties, voor een groot deel één-op-één overgenomen worden. Laten we ze daarom dataservices noemen.
Daarnaast zal er een laag gebouwd moeten worden waar de business processen gedefinieerd zijn en die door business process engines ofwel orchestration engines verwerkt kunnen worden.
De dataservices zijn meestal te technisch en te gedetailleerd om direct aan de business-process laag te koppelen. Een mogelijke dataservice zou zijn ‘geef-de-eerste-orderregel’ of ‘geef-het-adres-van-een-klant’. De business-processen worden te technisch als ze zelf de stap naar deze dataservices moeten maken. In de gedefinieerde business-processen zien we dan de ware business niet meer echt terug.
Een extra derde laag is dus noodzakelijk die de dataservices omzet naar services waar de business wel in gedefinieerd kan worden: de business-services. Mogelijke business-services zijn ‘geef-de-gehele-order’ en ‘geef-het-klantbeeld’. De bestaande dataservices worden in deze laag als het ware gecombineerd tot services met een ‘grotere’ interface.
Organisaties die bezig zijn met soa’s zullen ontwerpbeslissingen moeten nemen over deze services en hun respectievelijke interfaces. Een beslissing die ook genomen moet worden is in welke talen de business-process en de business-services laag ontwikkeld worden? Talen als Java, C# en VisualBasic hebben voldoende functionaliteit om hier voor gebruikt te worden. Echter, de business-processen zelf zullen dan niet direct zichtbaar zijn in deze talen. Aan te raden is om tools te gebruiken die gebaseerd zijn op standaarden als BPEL of BPSS. Hiermee worden business-processen beter uitgedrukt in concepten van de business. Het is dan meer een één-op-één vertaling.
Voor het ontwikkelen van de laag met business-services is het antwoord echter niet zo duidelijk. Welke taal gebruik je om dataservices met een simpele, maar wel op SOAP en XML gebaseerde interface om te zetten naar een meer documentgeoriënteerde en ook op XML en SOAP georiënteerde interface? Wederom, de bekende programmeertalen kunnen het aan, maar dat leidt tot veel coderen. Hier hebben we meer baat bij talen die speciaal ontwikkeld zijn voor het transformeren van ‘XML naar XML’. Denk hierbij aan XSL(T) of XQuery. Al zit niemand er op te wachten om in dit soort talen te ontwikkelen. Wat nodig is, zijn tools met een sterke grafische interface waarmee gebruikers op een heldere manier de omzetting kunnen definiëren. Belangrijk hierbij is tevens dat deze specificaties in een directory opgeslagen worden zodat impact analyses uitgevoerd kunnen worden. Dit zou op een vergelijkbare manier moeten gebeuren als nu bij menig ETL tool.
Deze twee lagen gaan ongetwijfeld een dominante rol spelen in de gehele informatieverwerkingsstructuur van een organisatie. Als organisatie ben je uiteindelijk zeer afhankelijk van de tools waarmee deze lagen gebouwd zijn. Dus voor beide lagen zou wel eens een heftige strijd kunnen gaan ontstaan tussen de leveranciers. Zij willen zeer zeker deze markt veroveren. Elke leverancier wil uiteindelijk hun klanten aan zich binden. Laten we de komende jaren deze strijd eens gaan volgen.< 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.
