De nieuwste versie van BizTalk Server biedt de mogelijkheid om connecties met Windows Azure AppFabric te realiseren of gebruik te maken van de Windows Server AppFabric mogelijkheden. De mogelijkheid binnen BizTalk Server heet AppFabric Connect en is eigenlijk, zoals de naam al zegt, niets anders dan aansluiten met AppFabric. Zowel de ‘on-premise’ Windows Server als Windows Azure. Met behulp van AppFabric Connect-functionaliteit kunnen ontwikkelaars:
· applicaties schrijven, die een verbinding nodig hebben met een zogenaamde ‘Line-of-Business’ (LoB) systeem bijvoorbeeld SAP, Siebel, Oracle E-Business Suite zonder daarvoor code te hoeven schrijven;
· gebruik maken van transformatiemogelijkheden door middel van de BizTalk Mapper.
Daarnaast zijn met AppFabric Connect, LoB systemen en BizTalk applicaties, via de Cloud bereikbaar. De zogenaamde ‘BizTalk Server 2010 AppFabric Connect for Services’ brengt deze mogelijkheden van BizTalk en Windows Azure AppFabric samen.
Figuur 1. BizTalk Server AppFabric Connect aansluiting met Windows Server- en Azure AppFabric.
AppFabric Connect
De AppFabric Connect functie biedt WF-ontwikkelaars toegang tot zowel de BizTalk Mapper als de BizTalk Adapter Pack 2010 en dient apart te worden geïnstalleerd. De BizTalk Mapper is een tool, die draait in de Microsoft Visual Studio-omgeving. Het kan worden gebruikt voor het maken en bewerken van zogenaamde ‘maps’, welke gebruikt worden voor translatie en/of transformatie van XML-berichten. Het Adapter Pack zorgt voor samenwerking met verschillende bedrijfsapplicaties, zoals SAP, Siebel of Oracle. Dit pack is een verzameling van adapters voor belangrijke bedrijfsapplicaties die integratie met elke Windows-applicatie mogelijk maken, gebruikmakend van het Windows Communication Foundation (WCF) programmeermodel. Zodoende kunnen ontwikkelaars vanuit Visual Studio gebruik maken van de BizTalk Mapper functionaliteit zonder eerst een BizTalk omgeving in te hoeven richten. Eveneens kunnen verbindingen worden opgezet met zogenaamde LoB systemen als SAP, Oracle database, Oracle E-Business Suite, Siebel en SQL Server waar geen zelf geschreven code voor nodig is. Een ontwikkelaar kan een nieuwe applicatie bouwen in WF, die vervolgens kan worden uitgerold, gehost en gemanaged in Windows Server AppFabric. Web applicaties, bijvoorbeeld, kunnen eenvoudig toegang krijgen tot LoB-data.
Scenario
Voor scenario’s waarbij web applicatie achterliggende systemen willen raadplegen, biedt Windows AppFabric een uitkomst. Informatie ophalen is van korte duur en heeft geen persistentie en dergelijke nodig zoals BizTalk Server biedt. De korte duur of te wel “Low latency” kan heel eenvoudig worden bewerkstelligd. Dit is met BizTalk nogal lastig te realiseren, tenzij je een hele krachtige (en dure) omgeving tot je beschikking hebt. De onderstaande applicatiearchitectuur geeft weer hoe een web applicatie met behulp van een workflow service, een LoB systeem kan benaderen.
Figuur 2. Een verbinding tussen een workflow service in AppFabric/IIS en een Line of Business-systeem.
Connectie met een Line of Business Systeem
BizTalk levert een verzameling op WCF gebaseerde adapters, die onder andere geschikt zijn voor het maken van connecties met LoB-systemen. Daar zijn onder andere de WCF LoB Adapter SDK en het BizTalk Adapter Pack voor nodig, die out-of-box worden geleverd bij BizTalk Server 2010. In een WF-project in Visual Studio kan de ontwikkelaar, via het “Add Adapter Service Reference” menu onderdeel, gebruik maken van deze adapters.
Figuur 3. Het “Add Adapter Service Reference” menu onderdeel.
Zodra hij hier op klikt, komt een scherm naar voren (zie figuur 4), dat kan worden gebruikt voor de connectie naar een LoB-systeem. Binnen het scherm kan worden gezocht naar diverse artefacten welke door LoB-systeem worden ondersteund. Daarnaast kan de ontwikkelaar diverse operaties kiezen, die bij het artefact behoren en die hij wil gebruiken. In het onderstaande figuur wordt de “Select”-Operatie gekozen op een SQL Database tabel “CustomerInfo”.
Figuur 4. Add Adapter Service Reference scherm.
Op het moment dat de ontwikkelaar op OK klikt, worden WF-activiteiten gegenereerd voor de gekozen operaties. Om de nieuwe activiteiten te zien in de Visual Studio Tool box, zal hij eerst de projecten moeten compileren. Als hij dat eenmaal gedaan hebt, kunnen de activiteiten naar de workflow worden gesleept.
Figuur 5. Gegenereerde Select workflow activiteit in activiteiten toolbox.
BizTalk Mapper
Zoals eerder beschreven kunnen ontwikkelaars vanuit Visual Studio toegang krijgen tot de BizTalk Mapper. De BizTalk Mapper maakt gebruik van haar eigen grafische systeem van pictogrammen en links voor de translatie en transformatie van de input en output berichten. De mapper maakt gebruik van dezelfde grafische weergave van schema's als de BizTalk Editor. Het slaat zijn ‘maps’ op als Extensible Stylesheet Language Transformations (XSLT) stylesheets.
Zoals eerder aangegeven kunnen ‘maps’ worden gebruikt voor translatie en transformatie van data. Translatie is een proces, waarbij een bericht wordt vertaald van het ene formaat naar een ander formaat, zoals omzetten van een plat bestand in een XML-bestand. Dit is voornamelijk van toepassing voor BizTalk Server. Transformatie is het proces, waarbij informatie van het ene bericht wordt ingebracht in een ander bericht. Je zou bijvoorbeeld een verzendadres in een bestellingbericht kunnen brengen. Dit is toepasselijk binnen zowel BizTalk Server als WF services. De Mapper is als activiteit beschikbaar in de Toolbox onder de categorie BizTalk en kan worden gesleept naar een workflow.
Figuur 6. BizTalk Mapper activiteit in de toolbox.
Om van de Mapper-activiteit gebruik te kunnen maken, moet de ontwikkelaar een InputDataContractType en een OutputDataContractType specificeren. Deze contracten zijn .NET-typen voor input- en output data voor de Mapper-activiteit. Op basis van deze typen kan hij een nieuwe “mapping” maken of een bestaande selecteren. Wanneer je een nieuwe mapping maakt, zal de Mapper-activiteit, behalve een BizTalk map (.btm) file, XML schema’s genereren voor de geselecteerde input- en output data contractentypen.
Figuur 7. Creëren of selecteren van een map.
Wanneer een nieuwe of bestaande mapping aangemaakt of gekozen is, kan de ontwikkelaar de file in de BizTalk Mapper GUI binnen de WF project openen en aanpassen. Wanneer hij de “mapping” uiteindelijk opslaat, wordt het automatisch, samen met project, gecompileerd en gebouwd.
Figuur 8. BizTalk Mapper.
De Mapper-activiteit heeft een input- en output argument nodig om de te transformeren data en getransformeerde data op te slaan. De ontwikkelaar gebruikt daarvoor een variabele om input aan de Mapper-activiteit te koppelen. Hij gebruikt eveneens een variabele om de output van de “mapping” op te slaan. Runtime wordt de input eerst geserialiseerd naar XML. Het wordt dan vervolgens getransformeerd met behulp van de XSLT, welke is gegenereerd op basis van de “mapping”. Ten slotte wordt het gedeserialiseerd naar het een object van het output type.
AppFabric Connect for Services
Tot nu toe is de serverkant van AppFabric Connect beschreven en wordt nu de Cloud-kant belicht. Met de “AppFabric Connect for Services”-functionaliteit kunnen BizTalk-applicaties als WCF-Services in de Cloud worden blootgesteld, door middel van het toevoegen van Windows Azure AppFabric Service Bus eindpunten. Deze kunnen vervolgens worden geconsumeerd door afnemers, die zich buiten de firewall van de aanbieder van de services bevinden. Organisaties hebben nu meerdere uitrolmogelijkheden tot hun beschikking voor wat betreft hun applicaties en services, waarbij deze al dan niet beschikbaar worden gesteld aan afnemers buiten de bedrijfsmuren.
Windows Azure AppFabric Service Bus voorziet in mogelijkheden om het bereik van zogenaamde on-premise webservices te verlengen naar externe afnemers. Deze voorzieningen zitten in onder andere een Relay service, die Windows Azure AppFabric Service Bus ondersteund. Deze service kan als ‘mediator’ service in de Cloud tussen afnemer en de service worden gezien. Het kan worden vergeleken met een HTTP-proxyserver die, als deze eenmaal in browsers is ingesteld, alle verkeer afhandelt. Een verschil met de Service Bus is natuurlijk, dat de aanbiedende service de verbinding al opzet tijdens de initialisatie.
Windows Azure Service Bus speelt een belangrijke rol in het verlengen van het bereik van BizTalk-applicaties. Een ontwikkelaar heeft, om dit te kunnen verwezenlijken, de BizTalk WCF-Service Publishing Wizard tot zijn beschikking. Wat de BizTalk WCF-Service Publishing Wizard eigenlijk doet is operaties in BizTalk-applicaties blootstellen als WCF services. “AppFabric Connect for Services” voorziet de wizard in ondersteuning voor de Relay service van de Windows Azure AppFabric Service Bus. De wizard stelt de ontwikkelaar in staat operaties te selecteren, die hij wil blootstellen als services. Daarbij wordt het volgende gegeneerd:
· Een lokaal eindpunt voor de WCF Service
· Een Service Bus eindpunt voor de WCF Service
· Een Service Bus eindpunt voor meta-data uitwisseling met WCF Service (optioneel)
· Ontvangst poorten in een BizTalk applicatie, welke gebonden zijn aan de gewenste operaties.
Naast het blootstellen van BizTalk-applicaties, kunnen op een vergelijkbare manier LoB-applicaties worden blootgesteld aan externe afnemers, waar eveneens van de Relay service binnen Windows Azure AppFabric Service Bus gebruik wordt gemaakt. Hiervoor is de WCF Adapter Service Development Wizard beschikbaar binnen Visual Studio. Deze wizard stelt de ontwikkelaar in staat operaties bloot te stellen van LOB applicaties. Daarbij wordt het volgende gegeneerd:
· Een lokaal eindpunt voor de WCF Service
· Een Service Bus eindpunt voor de WCF Service
· Een Service Bus eindpunt voor meta-data uitwisseling relevant voor de WCF Service
Onderstaande figuur geeft een overzicht hoe een BizTalk-applicatie of LoB-systeem via de Relay service binnen Windows Azure Service Bus beschikbaar wordt gesteld voor externe afnemers.
Figuur 9. Blootstellen van BizTalk- en LoB applicatie via de Relay service in de Service Bus.
BizTalk WCF Service Publishing Wizard
Als BizTalk op hun machine is geïnstalleerd, kunnen ontwikkelaars de BizTalk WCF Service Publishing Wizard starten. En door de Wizard te doorlopen zijn zij in staat BizTalk-applicaties als WCF Service bloot te stellen in de Cloud. De ontwikkelaar bepaalt het transporttype, de mogelijkheid al dan niet meta-data uit te wisselen en of “receive locations” moeten worden aangemaakt voor de BizTalk-applicatie.
Figuur 10. WCF Service Type, transport en andere opties.
De volgende stap is een hele essentiële; het verlengen van het bereik van de WCF-Service. Belangrijk bij het aanvinken van “Add a Service Bus Endpoint” is dat de ontwikkelaar, of de organisatie waar hij deel van uitmaakt, de beschikking heeft over een Azure AppFabric Service Bus-account.Hiermee kan expliciet aangeduid worden dat de service ook in de Cloud beschikbaar moet zijn.
Figuur 11. AppFabric Connect: toevoegen van Service Bus eindpunt.
Vervolgens kan de ontwikkelaar kiezen welke BizTalk-orkestratie hij wil blootstellen. De BizTalk-orkestratie kan hier worden beschouwd als de operatie van de te genereren WCF service.
Figuur 12. Selecteren van een orkestratie voor het blootstellen via een WCF Service.
In een daaropvolgend scherm geeft de ontwikkelaar aan waar de service lokaal wordt moet worden uitgerold. Met andere woorden waar het lokale eindpunt zich uiteindelijk zal gaan bevinden. Hij zal vervolgens, als gekozen is voor verlengen van WCF Service, de eindpunten in Windows Azure Service Bus moeten configureren. Daarbij kan gekozen worden uit een drie bindings:
· NetTcpRelayBinding
· BasicHttpRelayBinding
· WS2007HttpRelayBinding
Figuur 13. Configuratie van de Service Bus eindpunten.
Voor de configuratie moet de Service Namespace geassocieerd zijn met een beschikbaar Azure AppFabric Service Bus account (zie figuur 14). De ontwikkelaar kan daarnaast de optie kiezen of het eindpunt beschikbaar moet worden gesteld in ATOM feed-pagina voor het account. Een andere optie, welke hij kan kiezen, is of meta-data uitwisseling mogelijk moet zijn voor externe partijen om een proxy te kunnen generen van de WCF Service.
Figuur 14. Service Namespace.
De laatste stap in de wizard heeft met de beveiliging van de Service eindpunt te maken. Een naam en de daar bijhorende sleutel dienen te worden ingevoerd van degene, die de service ter beschikking stelt. Deze gegevens zijn beschikbaar via Azure AppFabric Service Bus account (zie figuur 14) en zijn noodzakelijk om de beveiliging te kunnen configureren, zoals weergegeven in onderstaande figuur.
Figuur 15. Beveiliging van de service bus eindpunt.
Voor de afnemer van de service kan worden afgedwongen dat, voor gebruik ervan, deze zich heeft geauthentiseerd bij de Service Bus. De afnemer geeft de na authenticatie verkregen token aan de service. Dit token wordt aan de Relay service in de Service Bus aangeboden alvorens toegang wordt verleend aan de uiteindelijke service.
Tot slot zal de wizard een samenvatting tonen van alle gekozen instellingen. Bij afsluiten zal dan het een en ander lokaal en in de Service Bus worden gegenereerd. De BizTalk applicatie is nu gereed om beschikbaar te worden gesteld in de Cloud.
WCF Adapter Service Development Wizard
Met de WCF Service Development Wizard kan de ontwikkelaar operaties binnen LoB applicaties blootstellen via de Services Bus. Deze verschijnt als de ontwikkelaar een nieuw project kiest in Visual Studio en het project template WCF Adapter Service selecteert. Er kan vervolgens gekozen worden of service geconsumeerd wordt door een SharePoint site. Het scherm wat volgt is vergelijkbaar met scherm van de “Adapter Service Reference” (figuur 4) en waar het om allemaal om draait. De functionaliteit is hetzelfde; er kan gezocht worden naar diverse artefacten, welke door LoB systeem worden ondersteund, zoals het selecteren van operaties en dergelijke. In het onderstaande figuur is een verbinding gemaakt met SQL Server en een Select statement van de Product tabel wordt toegevoegd.
Figuur 16. Kiezen van de LoB-operaties om bloot te stellen in de Cloud.
De volgende stap is vergelijkbaar met de stap bij de WCF Adapter Publishing Wizard, namelijk de optie om de service bereiken te vergroten richting de Cloud. Hier kan eveneens expliciet aangeduid worden, dat de service ook in de Cloud beschikbaar moet zijn. Tot slot kunnen “behaviours” en eindpunten van de service worden geconfigureerd. Deze “behaviours” worden voor de lokale en mogelijke service bus eindpunten geconfigureerd, afhankelijk van keuze in het vorige scherm. Het zijn allemaal eigenschappen, die voornamelijk met beveiliging te maken hebben en vergelijkbaar zijn met het eerder beschreven beveiligen van het service eindpunt tijdens het doorlopen van de BizTalk WCF Service Publishing Wizard. Onderstaande figuur geeft de configuratie weer van het service eindpunt.
Figuur 17. Configureren van de eindpunten.
Na configuratie van het eindpunt klikt de ontwikkelaar op Apply en gaat door met de wizard, die een samenvatting toont. Na het afsluiten van de wizard zal een WCF service gegenereerd worden met een web.config file. Deze zaken worden dan toegevoegd aan het Visual Studio project.
Testen van je service
Als ontwikkelaar wil je nu gaan testen of je service via de Cloud beschikbaar is. Hij kan een client applicatie maken, bijvoorbeeld een console applicatie waar een referentie wordt toegevoegd naar het eindpunt van de service in de cloud. Er wordt uitgegaan van het testen van de zojuist beschreven Adapter service. Naast de referentie zal een ontwikkelaar nog een aantal dingen moeten doen. Als voor het service eindpunt authenticatie vereist is, dan moet aan de applicatie configuratie file (app.config) het een en ander worden toegevoegd.. Bij het configureren van de service (figuur 17) is bij RelayClientAuthentication de RelayAccessToken aangeduid. De client zal dus een authenticatietoken moeten overleggen aan de Service Bus wil het de service kunnen benaderen. Aan app.config wordt daarom een “behavior” toegevoegd.
Figuur 18. Toevoegen van “behaviour” in app.config file binnen <system.serviceModel> element.
Voor de credentials (naam en sleutel) dient de ontwikkelaar de waarde te gebruiken van de organisatie, die de service host in Service Bus (zie figuur 14). Daarnaast zal de ontwikkelaar in de app.config, een behaviorConfiguration property aan het element van de ServiceBus eindpunt genaamd “TableOp_dbo_ProductsRelayEndPoint” moeten toevoegen. De naam van deze property moet gelijk zijn aan de toegevoegde behaviour (zie figuur 18) en kan aangepast worden naar eigen inzicht, zolang ze maar gelijk zijn.
Figuur 19. Toevoegen behaviour aan de service eindpunt.
Zodra deze aanpassingen gedaan zijn en de app.config is opgeslagen, hoeft de ontwikkelaar de service alleen nog aan te roepen in code met de juiste parameter, het Select statement in dit geval. De ontwikkelaar zal ook voor de login gegevens voor de SQL database moeten meesturen (ClientCredentials). Dit is nodig om de client te authentiseren tegen het backend systeem, in dit geval SQL Server.
Figuur 20. Codesnippet voor het aanroepen van de service.
Wanneer de bovenstaande code wordt uitgevoerd zal de service worden aangeroepen, die een lokale database zal benaderen met de opgegeven credentials en de data ophalen op basis van het Select statement. In de onderstaande figuur is het resultaat te zien van de aanroep van de service.
Figuur 21. Resultaat aanroep service.
Conclusie
Met AppFabric connect worden de mogelijkheden voor een ontwikkelaar breder. Het ontwikkelen van webapplicaties, die toegang nodig hebben tot LoB applicaties wordt een stuk eenvoudiger. Met behulp van de BizTalk Mapper kunnen verschillende gegevens in verschillende systemen worden getransformeerd binnen een WF-service, die vervolgens binnen Windows Server AppFabric kunnen worden gehost en beheerd. Tot slot biedt “AppFabric Connect for Services” mogelijkheden om “on-premise” BizTalk-applicaties of LoB-systemen bloot te stellen via Windows Azure Service Bus aan externe partijen. De ontwikkelaar kan door middel van configureren met wizards dit voor elkaar krijgen zonder dat hij daar code voor hoeft te schrijven.
Links: