Mark Willems

45 punten

0stemmen

Cloud

Artikel: 29 maart 2011

BizTalk Server AppFabric Connect voor Services

1141 views - Download: PDF

EEN HYBRIDE CLOUD OPLOSSING REALISEREN

Mark Willems

Cloud computing is een relatief nieuw begrip en een hybride cloud is zo mogelijk nog nieuwer. Een hybride cloud is een architectuur waarbij we het beste uit twee werelden samenvoegen: Applicaties die enerzijds on-premise actief zijn, maar tegelijkertijd communiceren met applicaties in de cloud.

Intro

Veel commerciële en technische krachten zorgen er momenteel voor dat een hoop klanten sterk overwegen om hun bestaande applicaties op het Windows Azure Platform te gaan draaien. In de meeste gevallen zullen de klanten deze overgang stap voor stap gaan realiseren.
Bestaande applicaties die on-premise blijven bestaan, maar in staat zijn om te communiceren met andere applicaties die zich op het Windows Azure Platform bevinden: dat is de hybride aanpak. Voor veel klanten is zo’n hybride aanpak niet zomaar een overgangsfase, maar eerder een voorwaarde. Omdat van bepaalde applicaties of data vereist wordt dat ze on-premise draaien vanwege juridische-, procedurele- of beveiligingsredenen. Een klant wil bijvoorbeeld een website hosten op het Azure platform. Echter juridisch gezien mag de data het land niet verlaten of worden opgeslagen in één van de cloud data centra over de wereld. Of de klant wil de investeringen die door de jaren heen zijn gedaan in zijn on-premise systemen niet zomaar afschrijven.

Probleem/Scenario

Voorheen werd er een gat geslagen in de firewall en NAT (Netwerk Adres Translatie)-routering toegepast om de on-premise en off-premise applicaties met elkaar te laten communiceren. Deze methode kent echter vele nadelen, niet in de laatste plaats vanwege de management overhead, beveiligingsissues of configuratie uitdagingen. De meeste organisaties echter kunnen of willen niet in één keer al hun IT naar de cloud verplaatsen.
Met de tooling van Microsoft bestaat de mogelijkheid om te kiezen tussen de cloud en on-premise en is een hybride scenario mogelijk. Dus de grote vraag is: Hoe kan ik mijn on-premise diens-ten laten communiceren met de diensten die ik in Windows Azure host? Er zijn grofweg twee methoden om dat te bereiken, met de Windows Azure AppFabric Service Bus of met Windows Azure Connect. De oplossing in dit artikel, maakt gebruik van de eerstgenoemde methode.
Om het scenario verder te verduidelijken nemen we CompanyXYZ als voorbeeld. CompanyXYZ is van plan een online portaal te bouwen waar klanten een aanvraag kunnen doen voor een vergunning. De data voor het nieuw te bouwen portaal bevindt zich in meerdere systemen, zoals bijvoorbeeld Microsoft Dynamics CRM of SAP. De klant wil niet dat deze data in de cloud wordt opgeslagen.

Tevens is BizTalk Server al in gebruik als message broker en wil de klant niet dat de investeringen die gedaan zijn voor de interfaces verloren gaan met het inzetten van de cloud.
Om het portaal in de cloud goed te kunnen laten werken is data nodig vanuit de systemen binnen de muren van het bedrijf. Daarvoor gaan we bepaalde functionaliteit vanuit de reeds aanwezige BizTalk interfaces via de Azure AppFabric Service Bus als endpoint beschikbaar stellen. De Service Bus wordt door Microsoft gehost op hun eigen Windows Azure platform en faciliteert de verbinding tussen verschillende systemen.

Figuur 1: Scenario overzicht

AppFabric Connect voor Services

De volledige benaming van deze nieuwe feature luidt BizTalk Server 2010 AppFabric Connect voor Services, een hele mond vol. Het is echter niets meer of minder dan een BizTalk feature pack dat sinds oktober 2010 beschikbaar is. Het stelt klanten die al gebruik maken van BizTalk Server 2010 in staat om hun bestaande on-premise applicaties te verbinden met de cloud.
Om van deze functionaliteit gebruik te maken dienen klanten te beschikken over een geldige licentie voor BizTalk Server 2010 of het BizTalk Server Adapter Pack 2010. Dit feature pack biedt de mogelijkheden om twee krachtige oplossingen uit de Microsoft stack te combineren, BizTalk Server en Windows Azure AppFabric.
AppFabric Connect voor Services breidt de mogelijkheden van de BizTalk WCF Service Publishing Wizard verder uit. Hierdoor wordt het voor ontwikkelaars mogelijk om functionaliteiten van een BizTalk Applicatie voor externe afnemers aan te bieden, door gebruik te maken van WCF services via de Windows Azure Service Bus relay service. De relay service acteert als een brug tussen de client en de service.

Figuur 2: Windows Azure Service Bus relay service

Beveiligen van de Endpoints

Wie of wat toegang krijgt tot de Service Bus, wordt bepaald door de Access Control Service. Applicaties die gebruik willen maken van de Windows Azure AppFabric Service Bus moeten bepaalde beveiligingsgegevens opvoeren tijdens de registratie/configuratie of bij het aanroepen van de functionaliteit. Deze beveiligingsgegevens omvatten zowel authenticatie als autorisatie door middel van tokens van de Access Control Service. Nadat toegang is verleend door de Service Bus is het de beurt aan de service zelf. De service maakt voor de uitwisseling van berichten ook gebruik van authenticatie, encryptie, enzovoorts. Dit heeft echter niets van doen met de beveiligingsfunctionaliteit van de Windows Azure Service Bus, het is uitsluitend een zaak van de service en zijn clients. Er zijn momenteel vier mogelijke manieren voor authenticatie richting de Service Bus:

SharedSecret, een wat complexere vorm van username/password maar eenvoudig om te gebruiken.
SAML (Security Assertion Markup Language), wat gebruikt kan worden om te communiceren met SAML 2.0 authenticatie systemen.
SimpleWebToken, maakt gebruik van OAuth Web Resource Authorization Protocol(WRAP) en Simple Web Tokens.
Geen authenticatie, zorgt voor communicatie met het service endpoint zonder een vorm van authenticatie.

In de links aan het einde van dit artikel is meer informatie te vinden over dit onderwerp.

Beveiliging van de oplossing

Vanwege het gedistribueerde karakter van een hybride oplossing is beveiliging van groot belang. Onze klanten gaan gegevens beschikbaar stellen aan services buiten hun eigen vertrouwde omgeving. Gelukkig maken de huidige technieken het mogelijk om alleen gebruikers toegang te verlenen die het bedrijf vertrouwt. In de praktijk zal dit meestal neerkomen op het gebruik van Federated security. Als we willen dat onze on-premise identiteit bekend is bij de websites en services die we in Windows Azure hosten, dan is een lokale identiteitsprovider nodig zoals Active Directory Federation Services 2.0(ADFS 2.0). De services kunnen vervolgens zo geconfigureerd worden dat ze de claims vertrouwen die zijn uitgegeven door de identiteitsprovider. Meer informatie hierover vind je in het artikel van Erwyn van der Meer in het december 2010 nummer.

Oplossing

Na het installeren van het feature pack zijn er twee mogelijkheden:

De BizTalk WCF Service Publishing Wizard gebruiken om een orchestration of schema als WCF service met een relay endpoint beschikbaar te maken in de Windows Azure AppFabric Service Bus.
De BizTalk WCF adapter Service Development Wizard gebruiken om methoden van een Line of Business systeem als WCF service met een relay endpoint beschikbaar te maken in de Windows Azure AppFabric Service Bus.

We kiezen in dit artikel voor de eerste optie. De BizTalk WCF Service Publishing Wizard creëert de volgende artifacts:

Een lokaal endpoint voor de WCF service.
Een Service Bus endpoint voor de WCF service.
Een Service Bus endpoint voor metadata uitwisseling met de WCF service (indien geconfigureerd).
Receive poort in de BizTalk Application, welke gebruikt wordt om de verbinding tot stand te brengen met de business logica.

Allereerst dienen we een service namespace te registreren bij de Windows Azure AppFabric Service Bus.
Hiertoe gaan we naar de portal (https://appfabric.azure.com) en maken een service namespace (bijvoorbeeld dotnetmagazine) aan.

Figuur 3: Registreren namespace bij de Azure services bus

Vervolgens doorlopen we de BizTalk WCF Service Publishing Wizard vanuit het Tools menu in Visual Studio.NET. We configureren een WsHttp endpoint en nu valt het op dat de wizard een aantal extra opties bevat welke belangrijk zijn om ons endpoint in de cloud beschikbaar te stellen.

Figuur 4: Toevoegen van een Service Bus endpoint

Er kan gekozen worden om een schema of orchestration als WCF service te publiceren. We kiezen in dit geval voor de schema optie en doorlopen de wizard verder. Belangrijk is hierbij de configuratie van het service bus endpoint, waarbij de service namespace de naam is van de eerder in dit artikel aangemaakte dotnetmagazine service namespace

Figuur 5: Service Bus endpoint configuratie

Als laatste stap is de authenticatie informatie vereist voor de eerder genoemde service namespace. Deze informatie wordt verkregen vanuit de Windows Azure AppFabric portal. De checkboxen onder client authenticatie bepalen of de client die het service endpoint consumeert een authenticatie token aan de service bus moet tonen. Kosten voor de Windows Azure AppFabric worden berekend op basis van toegang. Daarom is het verstandig om ongeoorloofd gebruik tegen te gaan en de client zich bekend te laten maken bij de service bus.

Figuur 6: Service Bus endpoint beveiligings configuratie

Als alles goed geconfigureerd is dan levert de wizard een WCF service op in Internet Information Services en tevens een bijbehorende locatie in BizTalk waarop wordt geluisterd voor inkomende berichten van een bepaald type. Er is een ATOM feed pagina beschikbaar waar alle publiekelijk toegankelijke endpoints getoond worden. De URL voor deze pagina is altijd in het formaat:

http://.servicebus.windows.net

In het geval van dit artikel levert dat de volgende URL op:

http://dotnetmagazine.servicebus.windows.net

Voer deze URL in de browser in en druk op Enter. Er wordt nu een lijst getoond van alle beschikbare endpoint adressen voor deze service namespace. Indien de service succesvol is geregistreerd bij de Service Bus, dan wordt de service worden getoond in de eerder genoemde lijst.

Testen van de service

Nu de service in de cloud beschikbaar is, kan de client applicatie gebruik maken van de service. Maak daarvoor in Visual Studio.NET een nieuwe console applicatie aan en voeg een referentie toe naar het endpoint van de service in de cloud.

Omdat client authenticatie vereist is voor het service endpoint, moet de client een authenticatie token aan de Service Bus kunnen overleggen. In dit voorbeeld wordt de SharedSecret credential type gebruikt. Dit kan je doen door het app.config bestand aan te passen en een behavior toe te voegen binnen het element.

 
<configuration>
   <system.serviceModel>
      <behaviors>
         <endpointBehaviors>
            <behavior name="sharedSecretClientCredentials">
               <transportClientEndpointBehavior credentialType="SharedSecret">
                  <clientCredentials>
                     <sharedSecret 
                        issuerName="Owner"
                        issuerSecret="PHmOJdVApx9N1QQvX1PP491EC1/zJA68bOgA+kTOK3I=" />
                  </clientCredentials>
               </transportClientEndpointBehavior>
            </behavior>
         </endpointBehaviors>
      </behaviors>

Codevoorbeeld 1: Toevoegen van een behavior

De waarden voor issuerName en issuerSecret dienen verstrekt te worden door de organisatie die de service host. De waarde voor de behavior naam kan al naar gelang worden aangepast. Maar dient wel gelijk te zijn aan de naam van de behaviourConfigura-
tion attribuut bij het endpoint element.

 
<endpoint 
   address="sb://dotnetmagazine.servicebus.windows.net/DotNetMagazineService/DemoService.svc"
   binding="netTcpRelayBinding"
   bindingConfiguration="RelayEndpoint"
   contract="DemoService.DemoService"
   behaviorConfiguration="sharedSecretClientCredentials"
   name="RelayEndpoint" />

Codevoorbeeld 2: Toevoegen van een behavior aan endpoint

Het enige wat nu nog rest, is het aanroepen van de service met de juiste parameters. Dit werkt zoals we gewend zijn bij het aanroepen van een WCF service. De service zal op zijn beurt de gegevens doorsturen naar de ontvangst locatie in BizTalk. Uiteindelijk wordt er een bericht in BizTalk geplaatst, wat vervolgens verder verwerkt zal worden.

 
DemoService.DemoServiceClient client = 
     new DemoServiceClient("RelayEndPoint"); 
Case newCase = new Case();
newCase.Name = "Willems";
newCase.Income = "1000000";
client.ReceiveCase(newCase);

Codevoorbeeld 3: aanroepen service

Conclusie

BizTalk Server 2010 AppFabric Connect voor Services verrijkt de standaard BizTalk tooling en biedt daarmee de mogelijkheid om on-premise en cloud applicaties met elkaar te verbinden via de Azure Service Bus. Deze krachtige combinatie van Microsoft technologieën biedt ontwikkelaars de mogelijkheden om hybride oplossingen te realiseren voor hun klanten en daarmee de overgang naar de cloud te realiseren. Hieronder staan nog een paar interessante links vermeld die nodig zijn bij het realiseren van het scenario beschreven in dit artikel.