Sinds de eerste lancering wint BizTalk Server aan populariteit en zijn we inmiddels met BizTalk Server 2006 R2 beland bij de vijfde versie van het product. De huidige versie R2 is een uitbreiding op de vorige waarin een aantal functionaliteiten zijn toegevoegd zoals de ondersteuning voor native EDI en RFID, WCF en SharePoint Services 3.0. Volgens de laatste cijfers van Microsoft werken wereldwijd meer dan 8000 klanten met BizTalk Server. Ook binnen ons land werken een behoorlijk aantal bedrijven met BizTalk Server zoals SNS Reaal, Grontmij, De Friesland Zorgverzekeraar, UWV, Achmea, Interpolis en Stegeman.
Dit is allemaal indrukwekkend, maar waar moet de klant nu rekening mee houden op moment dat het BizTalk Server in huis haalt? Waar bestaat het uit en hoe ziet een BizTalk Platform architectuur er nu uit? En tot slot, wat betekent het voor ontwikkelaars, information workers (business analisten) en architecten? In dit artikel zullen deze vragen beantwoord worden.
Business context
Wat zou de business (de klant) of IT bewegen tot de aanschaf van producten zoals BizTalk? Welke overwegingen of wensen leiden tot oplossingen waar BizTalk een rol in kan spelen? De business vandaag de dag moet flexibel zijn en snel op veranderingen in de markt kunnen inspelen. Het IT deel van een organisatie zal daarbij de eisen van de business volledig moeten begrijpen en kunnen inschatten. Daarnaast moet worden ingeschat, hoe deze business eisen impact hebben op de bestaande of nieuwe systemen.
De meest voorkomende business eisen zijn collaboration, governance, ROI en de eerder genoemde flexibiliteit. Collaboration, ofwel samenwerking, binnen en buiten een organisatie, is belangrijk om de business te laten groeien. Dit geldt voor zowel het ad hoc versturen van berichten naar derde partijen, als voor de integratie van alle business functionaliteit binnen de organisatie. Governance, ofwel toezicht, heeft de business nodig om te kunnen voorzien in audit trails ten behoeve van wet- en regelgeving. En ten slotte wil de business altijd een return of investment (ROI) zien, zodat zij inzichtelijk hebben welke voordelen een systeem op termijn heeft.
Waarom BizTalk?
De hierboven genoemde eisen zijn allemaal legitieme business eisen, maar hoe past BizTalk hier nu in? BizTalk Server biedt de mogelijkheid om bijvoorbeeld legacy systemen te ontsluiten, systemen die voor de business onmisbare systemen zijn. Vaak zijn dit monolithische, starre systemen, die met behulp van BizTalk flexibeler en wendbaar worden. Functionaliteit van dergelijke systemen wordt inzichtelijker en makkelijker onderhoudbaar.
Dit is niet het enige argument om BizTalk in te zetten. Om het nog meer inzichtelijk te maken wat de argumenten kunnen zijn voor zowel business als de IT, volgt hieronder een overzicht van functionaliteiten …
Validatie van berichten. De structuur van een te ontvangen en/of te verzenden bericht wordt geanalyseerd en gevalideerd tegen een gedefinieerde structuur. De structuur wordt vastgelegd door middel van schema's.
Transformatie van berichten. In de ideale wereld wordt er van één berichtdefinitie gebruik gemaakt. Meestal is dit echter niet zo en worden voor eenzelfde type object meerdere berichtdefinities gebruikt (schema's). De integratie-broker biedt standaard voorzieningen om berichten om te zetten naar een andere structuur (mapping van het ene schema naar het andere schema).
Routering van berichten. Een ontvangen bericht wordt geanalyseerd en op basis daarvan doorgestuurd naar de geabonneerde applicaties/services. Routering kan plaatsvinden op basis van zogenaamde header-informatie of op berichtinhoud (content based routing).
Aggregatie van berichten. Het samenvoegen van meerdere berichten tot een nieuw bericht (aggregator pattern). Naast dit pattern zijn er met de integratie-broker meerdere patterns te implementeren, zoals opspliten van berichten (splitter pattern), verzamelen van berichten en versturen naar meerdere ontvangers (gatter-scatter pattern).
Betrouwbaarheid en beveiliging. Technisch-functionele diensten zoals gegarandeerde bericht aflevering, beveiligd transport, garantie van afzender en van oorspronkelijkheid van het bericht.
Adapters en transport. Koppeling en communicatie naar applicaties en systemen.
Orchestration (samenstelling). De mogelijkheid om bestaande diensten te combineren tot een nieuwe, gecombineerde dienst. Een voorbeeld hiervan is het aanbieden van locatie gebaseerde informatie: de service die de locatie bepaalt, wordt gekoppeld aan de service die informatie over de locatie oplevert. Door combinatie van twee 'eenvoudige' services ontstaat een nieuwe service/product.
BAM (Business Activity Monitoring). Processen en/of samengestelde services kunnen door middel van voorafgestelde KPI's gemeten worden. BAM is de service die dit realiseert en biedt de mogelijkheid om via een cockpit de resultaten te analyseren en op basis van deze analyse het proces aan te passen.
Business to Business Integration. XML, EDI en dergelijke formaten worden ondersteund, zodat externe systemen kunnen communiceren met BizTalk. Ook Business processen in de ene organisatie kunnen communiceren met BizTalk proces in andere organisatie.
RFID Platform. Het platform binnen BizTalk voor ontwikkelen, uitrollen en management van Radio Frequency Identification (RFID) oplossingen, waarbij de meeste RFID apparaten worden ondersteund.
Business Rule. Het toepassen van logica (regels) op processen (orchestrations) binnen BizTalk. Het raamwerk maakt het mogelijk declaratieve regels op te stellen, die een duidelijke betekenis hebben en gekoppeld kunnen worden aan feiten (zoals XML documenten, database tabellen of .NET componenten).
Management. Management van processen, berichten en applicatie artefacten via een centraal management console.
Integratie met Visual Studio. Tools voor ontwikkelen, testen en uitrollen van BizTalk artefacten en oplossingen.

Fig. 1: Schematische weergave van functionaliteiten binnen BizTalk Server 2006 R2
Nu we de business kant van het verhaal belicht hebben, gaan we het eens bekijken vanuit de IT kant. Daarbij kun je de vraag stellen hoe BizTalk past in hun landschap? Het antwoord is deels terug te vinden in de genoemde functionaliteiten van BizTalk. Adapters en transport zijn b.v. interessant, omdat daarmee koppelingen en communicatie naar andere applicaties en systemen mogelijk zijn.
Binnen heterogene omgevingen kan BizTalk met haar adapters een belangrijke rol spelen om applicaties met elkaar te integreren
Adapters
Adapters die met BizTalk meegeleverd worden of beschikbaar zijn via Microsoft, stellen je in staat met diverse systemen te integreren zoals PeopleSoft, JD Edwards, SAP, Siebel, TIBCO, IBM Mainframes, IBM DB2 en Oracle. Daarbij worden allerlei communicatieprotocollen ondersteund zoals HTTP, FTP, SOAP, MQSeries, MSMQ. Data in de diverse systemen kunnen dus via allerlei communicatie protocollen door BizTalk ontsloten worden.
Binnen heterogene omgevingen kan BizTalk met haar adapters een belangrijke rol spelen om applicaties met elkaar te integreren. Zeker wanneer binnen een organisatie Microsoft de voorkeur heeft boven leveranciers als IBM of Oracle, die vergelijkbare producten leveren zoals IBM WebSphere en Oracle Fusion.
Orchestration
Dit is zeker niet de enige interessante functionaliteit van BizTalk. Het kunnen ondersteunen van een zakelijk proces door meerdere diensten samen te stellen met behulp van Orchestration is een erg krachtige functionaliteit. Met behulp van het volgende denkbeeldige scenario wordt dit een stuk duidelijker. In het voorbeeld zullen ook de overige functionaliteiten van BizTalk de revue passeren. BizTalk zal zeer geschikt blijken te zijn voor geautomatiseerde machine naar machine processen.
Een landelijk garage bedrijf stelt automobilisten in staat een afspraak te maken voor een servicebeurt via een website. De gebruiker kan, waar dan ook in Nederland, op een gewenst moment deze servicebeurt voor zijn auto laten plaatsvinden. Hij of zij zal via de website een verzoek doen voor een afspraak op een bepaald tijdstip bij een van de aangesloten garages. Een verzoekbericht van de afspraak (persoon, auto, tijdstip, locatie en dergelijke) zal worden verstuurd richting BizTalk Server, die het bericht inspecteert en valideert en start vervolgens een proces. Binnen het proces wordt het bericht verder ontleed en worden andere systemen geraadpleegd. We gaan even uit van een heterogene omgeving, waarbij een CRM applicatie (Siebel) aanwezig is en Oracle en DB2 databases. In dit scenario brengen de adapters van BizTalk uitkomst; immers, koppelingen met deze systemen worden ondersteund. Deze systemen krijgen het verzoekbericht toegestuurd, waar de informatie van het oorspronkelijke verzoekbericht in staat. Deze berichten worden binnen BizTalk aangemaakt, eventueel met behulp van een transformatie, en door routing worden de berichten naar de juiste systemen verstuurd. De systemen sturen hun antwoorden terug naar BizTalk. Deze antwoorden bepalen dan het verdere verloop van het proces. Uiteindelijk zal een succesvol verlopen proces leiden tot een afspraak. Deze afspraak zal dan aangemaakt worden in het systeem van de gewenste garage. Tot slot zal het proces eindigen in een bericht met tijdstip en locatie en deze informatie zal worden verzonden naar de website. De gebruiker zal dit als een bevestiging van zijn verzoek op de website zien.
Het bovenstaande is een scenario als een proces succesvol verloopt. Dit is in de praktijk natuurlijk niet altijd het geval. De gebruiker zou dan een melding krijgen, dat de afspraak niet mogelijk is of dat er alternatieven zijn voor tijd en/of locatie. Omwille van de eenvoud hebben we dit buiten beschouwing gehouden.
BizTalk Server Overzicht
Duidelijk is wel welke functionaliteiten BizTalk Server bevat en wat het een organisatie te bieden heeft. Als architect, ontwerper en developer heb je ook behoefte de exacte werking van BizTalk te kennen en te weten uit welke componenten BizTalk bestaat en wat er onder de motorkap uitzit.
BizTalk transformeert en persisteert alle berichten die het ontvangt, in een 'MessageBox' database op SQL Server om te kunnen voorzien in integratie van applicaties (applicatie-integratie) en coördinatie van logica tussen zakelijke processen (Business Process Management). Door middel van een adapter accepteert het berichten van externe applicaties, services, processen en systemen.
BizTalk maakt daarnaast gebruik van een pijplijn aan de ontvangende kant om berichten te converteren naar XML Data. Daarna verwerkt BizTalk Server de berichten door middel van een Orchestration en routeert het verzoekbericht (request), of er wordt gebruikt gemaakt van een versturende pijplijn om XML data te converteren naar een ander formaat en door te sturen naar externe applicaties, diensten, processen en systemen.
Bovenstaande beschrijft in hoofdlijnen de belangrijkste functies binnen BizTalk 2006. Alle data van en naar externe systemen via BizTalk zal de hierboven beschreven weg bewandelen (zie figuur 2). Dit is van wezenlijk belang bij het opzetten van een architectuur voor een BizTalk omgeving. Je kunt je namelijk richten op applicatie integratie en/of proces sturing binnen een organisatie. Belangrijk daarbij is het kunnen doorgronden van BizTalk Server Messaging Architectuur.

Fig. 2: Berichten stroom in/uitgaand
BizTalk Server Messaging Architectuur
De onderstaande figuur geeft een overzicht van een BizTalk architectuur vanuit een bericht (message) perspectief.

Fig. 3: BizTalk messaging architectuur
Een bericht wordt ontvangen door een ontvang (receive) locatie in een ontvangende poort.
De volgende componenten zijn betrokken in het ontvangen, verwerken en versturen van berichten binnen BizTalk Server.
Ontvangende poorten en ontvangst locaties
Een ontvangende (receive) poort is een verzameling van een of meerdere ontvang-locaties, die de specifieke ingangen in BizTalk definiëren. Een ontvangst-locatie is de configuratie van een enkel eindpunt om berichten te kunnen ontvangen. De locatie bevat configuratie-informatie van zowel ontvangst-adapter als -pijplijn (pipeline). De adapter is verantwoordelijk voor het transport en het communicatiedeel van het ontvangen van een bericht. De pijplijn is verantwoordelijk voor voorbereiding van een bericht, voordat het in de ‘MessageBox’ kan worden geplaatst (gepubliceerd). Een pijplijn bevat een reeks componenten, die in volgorde worden uitgevoerd, die voorzien in een specifiek deel van de voorbereiding van een bericht voor publicatie zoals decryptie, ‘parsing’ of validatie.
Verzendpoorten
Een verzendende poort is een combinatie van een versturende pijplijn (send pipeline) en een zend-adapter. Het is eigenlijk het omgekeerde van een ontvangende poort en haar ontvangst-locatie. Een verzendende poort kan ook nog worden gegroepeerd, zodat die de werking heeft zoals een e-mail distributielijst. De pijplijn wordt gebruikt om een bericht voor te bereiden en te versturen naar een andere service. De zend-adapter is verantwoordelijk voor het uiteindelijke versturen van het bericht en maakt daarbij gebruik van een protocol zoals SOAP of FTP.
Orchestrations
Orkestratie (orchestration) is een vormgegeven proces binnen BizTalk die berichten ontvangt vanuit de 'MessageBox' welke voor hem bestemd zijn. Een orkestratie kan ook berichten publiceren door deze te versturen naar de 'MessageBox'. Een bericht verstuurd vanuit een orkestratie, wordt op een gelijke wijze in de 'MessageBox' geplaatst alsof het via een ontvang-locatie wordt ontvangen.
Berichten ‘brievenbus’ (MessageBox) Database
Het hart van de ‘publish/subscribe’ engine in BizTalk is de ‘MessageBox’ database. Deze bestaat uit twee componenten, nl. een of meerdere Microsoft SQL Server databases en een berichten-agent. De SQL Server database voorziet in persistentie van zaken als berichten, haar eigenschappen, de abonnementen hierop, de status van orkestraties, de volgdata (tracking) en de host wachtrijen (queue) voor routering.
Host en host instanties
Een host is een logische representatie van een Microsoft Windows proces, die BizTalk Server artefacten als zend-poorten en orkestraties uitvoert. Een host instantie (host instance) is een fysieke representatie van een host op een specifieke server. Een host kan een ‘in-process’ host zijn, die wordt beheerd door BizTalk Server, of een geïsoleerde (isolated) host. In het laatste geval, voert BizTalk Server de programmeercode in een niet door BizTalk gecontroleerd proces uit, b.v. via Internet Information Server (IIS) voor HTTP en SOAP. Hosts worden gedefinieerd voor een gehele BizTalk Server groep, wat een verzameling van BizTalk Servers kan zijn. Een BizTalk Server groep deelt de configuratie van MessageBox(en), poorten, etc.
Deze componenten en hun gedrag/rol binnen BizTalk Server zijn van invloed op de wijze waarop de architectuur voor een BizTalk omgeving tot stand komt. Een belangrijke architectuurafweging richt zich op het wel of niet kunnen verwerken van berichten. Daarbij spelen volume en frequentie van berichten van elk interface die de BizTalk omgeving gaat ondersteunen, een rol.
Andere overwegingen spelen ook een rol bij een architectuur voor BizTalk. Waar worden b.v. de poorten (ontvang/verzend) ondergebracht; samen op een machine met eventueel Orchestrations? Worden de berichten apart verwerkt of bewerkt? Gaan alle componenten draaien op enkele hosts op één enkele machine? Zo ja, dan betekent het dat deze voldoende resources (verwerkingskracht (CPU), geheugen en diskruimte) moet bezitten. Anders kunnen de componenten beter draaien in hosts verspreid over meerdere machines, zodat de belasting van de resources verspreid kan worden. Overwegingen die onder andere ook bij de uitrol van BizTalk Server een belangrijke rol spelen. Daarbij speelt ook de hoeveelheid aan omgevingen een rol zoals een ontwikkel-, test-, acceptatie- en productie-omgeving. Dit valt buiten de scope van dit artikel.
BizTalk Server Platform Architectuur
De functionaliteiten van BizTalk Server en haar werking zijn nu uitgebreid aan bod gekomen. Daarbij hebben we nog niet de diverse rollen die met BizTalk te maken kunnen hebben behandeld. Gezien de uitgebreide mogelijkheden van BizTalk Server en de wijze waarop het binnen een organisatie kan worden ingezet kun je BizTalk eigenlijk niet meer beschouwen als een product op zich. Het is wel een server product van Microsoft, maar feitelijk zou je moeten spreken over een platform, waarbij een architect, ontwikkelaar en information worker (business analist) een wezenlijke rol spelen (figuur 4).
BizTalk is meer een Platform dan een Server

Fig. 4: Schematische weergave van BizTalk Server Platform
De architect zal zich richten op de architectuur van BizTalk Server zoals deze in dit artikel aan bod is gekomen. De developer zal zich bezighouden met ontwikkelen van BizTalk artefacten zoals pipelines, schemas, mappings en orchestrations. De administrator zal zich focussen op uitrol en beheer van de BizTalk-omgeving en -applicaties. Tot slot de information worker, die zich deels met ontwerp van schema’s zal bezighouden. Dat is echter niet het enige dat hij of zij zal doen:
- Opstellen van logica die van toepassing is op een zakelijk proces binnen BizTalk een orkestratie;
- Monitoren of inzicht verkrijgen in lopende processen;
- Generen van rapportage rond berichten verkeer en processen.
De rollen van administrator, developer en analist zijn gebonden aan tools zoals de management console van BizTalk, Visual Studio 2005 en de Business Intelligence Manager (Business Rule Composer).
BizTalk versies
Tot slot is het voor architect en wellicht developer belangrijk om te weten, dat er een keuze bestaat uit 3 BizTalk versies: Branche, Standard en Enterprise.
De Branche-versie is bedoeld als extra installatiepunt bij een business-partner naast een Enterprise-editie bij de hoofdgebruiker.
De Standard-versie voorziet alleen in een single-server installatie met de mogelijkheid om de database op een aparte server in te stellen. De standaard versie is niet schaalbaar en biedt slechts ruimte aan 5 applicaties. Als er een omgeving ingericht gaat worden die ruimte moet bieden aan een groeiend aantal applicaties, dan is de functionaliteit van de Enterprise-versie vereist. Deze versies zijn beschikbaar bij BizTalk Server 2006 R2.
Wat betreft BizTalk Server 2006 heeft R2 heeft de volgende relevante uitbreidingen / verbeteringen ten opzichte van BizTalk Server 2006:
- Ondersteuning voor Windows Communication Foundation;
- Ondersteuning voor Windows SharePoint Service 3.0 en MOSS;
- Ondersteuning voor Excel 2007 voor Business Activity Monitoring.
Het laatste is ook niet onbelangrijk als een afweging gemaakt dient te worden bij migratie van eerdere versies van BizTalk Server naar R2.
De Toekomst
Met de komende Biztalk 2009 zullen de mogelijkheden van de nieuwe versies van Windows producten als Windows Server 2008, .NET Framework 3.5, Visual Studio 2008 en SQL Server 2008 gebruikt gaan worden. Daarnaast zullen naar alle waarschijnlijkheid de volgende mogelijkheden aan het product worden toegevoegd:
- Ondersteuning voor UDDI 3.0;
- Verbeterde en nieuwe adapters voor LOB applicaties, databases en legacy/host systemen;
- RFID Mobile;
- Verbeterde interoperabiliteit en connectiviteit voor protocollen zoals SWIFT en EDI;
- ESB Guidance 2.0;
- SOA patterns en practices guidance.
De toekomstige versie BizTalk 2009 laat nog even op zich wachten, terwijl vele BizTalk specialisten graag met BizTalk en Visual Studio 2008 aan de gang willen. BizTalk 2009 zal BizTalk verder richting een platform duwen voor implementatie van een SOA en/of ESB. Daarmee zal het product meer aan populariteit winnen en het aandeel in de markt van applicatie-servers doen toenemen.
Conclusie
In dit artikel is duidelijk geworden wat BizTalk Server betekent voor zowel de business-kant als de IT-kant binnen een organisatie. Daarbij zijn de afwegingen die kunnen worden gemaakt of gelden eveneens beschreven. Tevens is inzichtelijk gemaakt welke functionaliteiten BizTalk Server kent, uit welke componenten het bestaat en hoe de werking intern is. Door te wijzen op het feit dat BizTalk Server meer als een platform kan worden beschouwd dan een product, zijn de diverse rollen als architect, administrator, information worker en developer beter te duiden. Tot slot zijn de rollen gekoppeld aan de beschikbare tooling en de diverse versies van BizTalk aan bod gekomen. Interessant is de ontwikkeling die het product door heeft gemaakt en hoe de toekomstige versies eruit gaan zien.