BizTalk en SOA

Introductie

Het is wel duidelijk dat het geen Nederlanders zijn geweest die de term Service Oriented Architecture hebben bedacht. Anders had het acroniem wel wat anders geluid. SOA is in elk geval wel een hype, of zelfs de ‘next big step’ in software-ontwikkeling.

Bij artikelen en presentaties over SOA duikt ook steeds vaker de kreet BizTalk op. Hoog tijd dus om die connectie wat nader te bekijken. Dit artikel zal voornamelijk ingaan op waar BizTalk past in het service georiënteerde architectuurplaatje. De techniek komt alleen om de hoek als een punt nadere uitleg behoeft, zodat het ook voor niet-BizTalkers te volgen is.

BizTalk Server is, zoals we inmiddels allemaal wel weten, een stuk middleware. Een stuk middleware dat ons kan helpen bij de integratie van LoB applicaties en/of systemen in een EAI scenario of applicaties en/of systemen van handelspartners in een B2B.

Met BizTalk kan de ontwikkelaar:

• business rules implementeren in complexe integratie of WorkFlow scenario’s;
• gegevens transformeren van het ene formaat (en platform) naar het andere;
• berichten routeren op basis van zowel metadata als inhoud;
• security-zaken als encryptie en signing afhandelen;
• en tracking informatie bewaren voor zowel business analysts als systeembeheerders.

Kort door de bocht: BizTalk biedt de ontwikkelaar een volledige bedrijfsprocesintegratie-suite

Merk het gebruik op van het woord “ontwikkelaar”. BizTalk is zeker geen product voor de eindgebruiker, ook al lijkt de Orchestrator nog zoveel op Visio. Ook de argeloze architect die zich waagt aan de Business Rules Composer (volgens Microsoft marketing een tool voor de niet-techneut) zal al snel inzien dat dit echt wel het nodige technische inzicht vereist.

BizTalk is met ingang van versie 2004 niet voor niets geïntegreerd met de Visual Studio. Het is gereedschap voor ontwikkelaars en niet voor eindgebruikers.

Met deze eigenschappen van BizTalk in het achterhoofd kunnen we gaan kijken naar hoe en waar ze functioneren in de wereld van SOA, met als groter doel om een antwoord te kunnen geven op de vraag “Waarom zou je een integratie en business processing engine willen gebruiken, als de client alleen maar een paar Web Services hoeft aan te roepen om bepaalde (beperkte) functionaliteit te kunnen bieden?”.

Deze vraag kan worden beantwoord door hem op te delen langs drie verschillende patronen die centraal staan in het service georiënteerde paradigma: de Service Broker, de Service Aggregator en de Integration Enabler.

Service Broker

Een Service Broker staat tussen de client en de web service. Hij regelt de communicatie van de web service met de client. Door deze service broker wordt er een veilige grens gecreëerd en kan de toegang tot de interne web service worden gereguleerd. Sterker: de broker is de enig toegestane en door het systeem ondersteunde route voor gebruikers van de web services van een bepaalde organisatie.

Fig. 1: Service Broker

Naast de functie van grenswacht kan een broker ook nog dienst doen als een Routing Engine voor het bepalen van de juiste web service. Hierbij baseert hij zich op de metadata (HTTP of SOAP headers) van het bericht, of hij baseert zich op elementen van de inhoud van het bericht zelf.

Fig. 2: Service Broker als Router

De service broker kan, afhankelijk van de eisen die eraan gesteld worden door de aanroepende partij, een rol spelen in zowel een request-response als een one-way scenario.

De service broker kan een rol spelen in zowel een request-response als een one-way scenario

Als de broker in een request-response scenario gebruikt wordt, dan zal het waarschijnlijk een bepaalde vorm van sync-on-async gebruiken. Deze sync-on-async wordt ook in BizTalk gebruikt, zodat BizTalk kan reageren op een synchroon bericht van de client.

Als de >broker in een one-way scenario gebruikt wordt, dan wordt er geen respons verwacht en BizTalk kan het bericht asynchroon verwerken.

Andersom kan het gebeuren, dat een respons asynchroon moet worden afgeleverd. In dat geval verstuurt de client een one-way request naar BizTalk, die het bericht vervolgens asynchroon naar de juiste web service stuurt. Het synchrone antwoord van de web service wordt vervolgens weer asynchroon door BizTalk naar de client verstuurd.

In beide gevallen wordt BizTalk gebruikt als middleware broker tussen een client en de verschillende web services. Het gebruik van BizTalk als broker zal gevolgen hebben voor de performance, omdat er een extra slag tussen de twee eindpunten plaatsvindt. Maar de voordelen van het gebruik van een routing engine wegen daar ruimschoots tegen op. Dit is zeker het geval bij organisaties waarbij de behoefte tot beveiliging hoger is dan de behoefte aan op meerdere plaatsen inzetbare web services.

Service Aggregator

De Service Aggregator is feitelijk een "super service". Een service die is samengesteld uit een aantal aparte en samenhangende services. In dit scenario wordt BizTalk gebruikt om meerdere web services te bedienen en de resultaten te aggregeren achter een façade van een enkele, coherente, bedrijfsfunctie. De aggregator biedt feitelijk de mogelijkheid om een complex samenspel van diverse, met elkaar samenhangende services op een helder georchestreerde wijze als een enkelvoudige eenheid aan te bieden.

Fig. 3: Service Aggregator

De aggregator biedt de mogelijkheid om met elkaar samenhangende services als een enkelvoudige eenheid aan te bieden

Het aanmaken van een aggregator of superservice met BizTalk houdt in, dat er met de Orchestration (de samengestelde business logic) een aantal web services in een bepaalde volgorde en/of op grond van bepaalde gegevens wordt aangeroepen. Daarna zal het eindresultaat als een enkelvoudige respons worden teruggegeven. In dit scenario fungeert BizTalk dus als broker (t.o.v. client en aggregate) en als aggregator (t.o.v. interne web services).

Integration Enabler

De twee hier besproken functies van BizTalk komen i.h.k.v. SOA het meeste voor. Maar daarnaast is er vaak de behoefte om te integreren met LoB applicaties achter de façade van web services. De cruciale rol die BizTalk speelt (of: kan spelen) in de communicatie tussen client en web service, betekent nog niet dat haar oorspronkelijke taak als applicatie-integratietool verdwijnt … integendeel.

Fig. 4: Integration Enabler

Een organisatie kan een web service die interne applicaties integreert, aanbieden aan externe handelspartners

Een organisatie kan een web service die een ERP en een voorraadsysteem integreert, weer aanbieden aan handelspartners van buitenaf. Hoewel het waarschijnlijk niet moeilijk zal zijn (afhankelijk van de interfaces van beide applicaties) om een programma te schrijven dat een dergelijke integratie implementeert, moeten we toch van dergelijke gedachten af. Point-to-point interfaces zijn op de langere termijn altijd moeilijk (zo niet onmogelijk) te onderhouden. Dit is nog afgezien van de steeds hogere kosten die aan het onderhoud verbonden zijn. Daarom doen we er goed aan ook de integratie tussen de interne kant van een web service en een of meer LoB applicaties af te handelen via een integratie tool als BizTalk. Immers: dit is waar het oorspronkelijk voor is ontwikkeld.

Conclusie

Concluderend kunnen we stellen, dat BizTalk goed past binnen de drie operationele patronen van een Service Oriented Architectuur. BizTalk wordt door white papers en andere artikelen over dit onderwerp bewierookt als een perfect instrument voor het implementeren van een SOA. En dit keer is het niet alleen Microsofts marketingtalk…

Biztalk is goed te gebruiken als SOA instrument

Natuurlijk zijn er wel valkuilen. De belangrijkste hiervan zijn performance en schaalbaarheid, maar BizTalk blijft een realistische optie. Voor elk vergelijkbaar product zijn er trouwens wel valkuilen te noemen. Het belangrijkste is, dat we ons bewust zijn van die valkuilen. We kunnen er dan in ieder geval met een wijde boog omheen of er een oplossing voor bedenken. Maar over dat laatste mag iemand anders een artikel schrijven….