Arkitektur och design

VERSION 2.1 Arkitektur och design Stockholms stad SOA-plattform 1 (47)

Innehållsförteckning 1 Tjänsteorienterad Arkitektur (SOA) 5 1.1 Syftet med Stadens SOA-plattform... 5 1.2 SOA Design... 6 1.2.1 De fyra tjänstelagren i plattformen... 6 1.2.2 Modellering av Tjänster: Top-Down kontra Bottom-up... 7 1.2.3 Tjänste Implementationer genom SOA-Plattformen... 8 1.2.4 SOA-plattformens arkitektur... 9 1.2.5 Hosting...10 1.3 Loggningsramverk för SOA-plattformen...11 1.4 Hur implementeras en tjänst i SOA-plattformen?...12 1.4.1 Implementering av tjänster...12 1.4.2 Dataregler i SOA-plattformen...12 1.5 SOA Plumbing tjänster & Regler...13 1.6 SOA Plattforms tjänster...13 2 Komponenter 14 2.1 Översikt...14 2.2 Produkten BizTalk...15 2.2.1 Vad gör BizTalk Server?...16 2.2.2 BizTalk Scenarier...18 2.3 BizTalk ESB Toolkit...20 2.4 AppFabric...23 2.4.1 WindowsAppFabric användarfall...26 2.5 WCF...27 2.5.1 Hosting i IIS Windows Appfabric (IIS/WAS, WCF/ WF)...28 2.5.2 WCF Användarfall...30 2.5.3 Windows Workflow Foundation användarfall...30 2.6 Microsoft Manage Service Engine (MSE)...32 2.7 Enterprise Single Sign On (ESSO)...34 2.8 Enterprise Libary...34 2.9 CA SSG...35 2.10 Interna Tjänster...35 2.10.1 Notifieringtjänsten...35 2.10.2 EPS...35 2.11 Signering...36 2.12 FileTransfer 2.0...37 2.13 Externa Tjänster...38 2.13.1 Betaltjänsten...38 2.13.2 CRM...38 2.14 Översikt infrastruktur...39 3 Regler, Policy och beskrivningar 40 3.1 Att implementera en tjänst...40 3.1.1 Beslutsträd för implementering av tjänster i SOA-plattformen..41 3.2 Regler för datakontrakt i SOA-plattformen...42 2 (47)

3.3 Loggning...42 3.4 Felhantering...43 3.5 Övervakning...44 3.6 Säkerhet...45 3.6.1 Spårbarhet...45 3.6.2 Auktorisation...45 3.6.3 Autentisering...45 3.6.4 Kryptering...45 3.6.5 Säkerhetsklassning...46 4 Referenser 47 3 (47)

Ordlista ADO API ASMX BAM BizTalk EAI EDI BPM ESB ETL GUI HTTP HTTPS IIS LOB MDM MSE MSI MSMQ RFID SLA SDK SOA WAS WCF WF WSDL XML ActiveX Data Objects (AktivX dataobjekt) Application Programming Interface (gränssnitt för applikationsprogrammering) Active Server Methods (aktiva servermetoder) Business Activity Monitoring (verksamhetsövervakning) En hanteringsserver för affärsprocesser Enterprise Application Integration(avser plattformar för ihopkoppling av företagets olika IT-applikationer) Electronic Data Interchange (är överföring av strukturerad information enligt ett överenskommet format) Business Process Management (affärsprocesshantering) Enterprise Service Bus (företagstjänstebuss) Extract Transform Load (extrahera omvandla ladda) Graphical User Interface (grafiskt användargränssnitt) HyperText Transfer Protocol är det kommunikationsprotokoll som används för att överföra webbsidor på informationsnätverket WWW, World Wide Web på Internet Hypertext Transfer Protocol Secure är ett protokoll för krypterad transport av data via HTTP-protokollet. Internet Information Services (serverprogramvara från Microsoft för internetbaserade tjänster) Line Of Businees Master Data Management (hantering av master data) Managed Services Engine (virtualiserings motor för hanterade tjänster) Microsoft Install (installeringsmotor) Microsoft Message Queuing är I grunden ett meddelande protokoll som tillåter applikationer att köras på separate servrar/processer för att kommunicera på ett säkert sätt Publish/Subscribe Radio Frequency Identification, en teknik för att läsa information på avstånd från transpondrar och minnen som kallas för taggar Service Level Agreement (tjänstenivåavtal) Software Delopment Kit Service Oriented Architecture (tjänsteorienterad arkitektur) Windows Application Server (Windows applikationsserver) Windows Communication Foundation, ett ramverk med inriktning att bygga serviceorienterade applikationer Workflow Foundation, en teknik för definiering, utförande och hantering av arbetsflöden) Web Service Description Language (XML-format för att beskriva webbtjänster) Extensible Markup Language, XML, är ett universellt och utbyggbart märkspråk och en förenklad efterträdare till SGML (Standard Generalized Markup Language) 4 (47)

1 TJÄNSTEORIENTERAD ARKITEKTUR (SOA) Syftet med detta dokument är att beskriva arkitekturen och hur denna har designas för SOA-plattformen. Detta för att förvaltningar, bolag samt utvecklare som skall utveckla SOA-tjänster skall förstå vilka komponenter och tjänster som finns att utnyttja i SOA Lagret. Det är också viktigt att förstå vilka regler och policys som Stockholm Stad har utfärdat och som behöver följas för att tjänsterna skall utvecklas och implementeras i SOA-plattform. För att underlätta implementationer i SOA-plattformen har Staden beslutat att det behövs ett ramverk för utvecklare att följa, genom att införa ett Software Development Kit (SDK). Detta dokument är en del av. 1.1 SYFTET MED STADENS SOA-PLATTFORM Syftet med SOA-plattformen är att leverera ett mervärde genom att: Tillhandahålla återanvändbara tjänster. Att snabbt kunna agera utifrån nya förutsättningar från verksamheten. Tillhandahålla enhetlig övervakning av undantag. Inhämta statistiska uppgifter kring processerna. Tillhandahålla administration av tjänster (Governance). 5 (47)

1.2 SOA DESIGN 1.2.1 DE FYRA TJÄNSTELAGREN I PLATTFORMEN Det finns fyra tjänstelager att ta hänsyn i denna plattform, enligt nedanstående bild. Lager 4: Lager 3: Lager 2: Lager 1: Process- eller sammansatta tjänster: En kombination av entitetstjänster och enkla tjänster som implementerar en affärsprocess. Dessa tjänster bör nästan alltid placeras i plattformen. Entitetstjänster och enkla tjänster: Dessa tjänster innefattar en enda operation med den allra lägsta nivån av granularitet (finkornighet), vanligtvis en enkel uträkning, operation eller dataoperation. Datatjänster: Tjänster som underlättar för dataoperationer, inklusive Master Data Management-tjänster och versionerade referensdatatjänster. Plumbing-tjänster: Tjänster som endast finns som en funktion i plattformen. Innefattar Publish/Subcriber-strukturer med tjänster såsom utgivare och prenumeranter, exempelvis BAM och ESB Guidance Error Management. Detta lager kan även innehålla adaptiva tjänster som t.ex. Biztalk-adaptrar, WCF verksamhetsadaptrar eller WCF-tjänster som visar intern applikationslogik för plattformen och som fungerar som enkla adaptrar. 6 (47)

1.2.2 MODELLERING AV TJÄNSTER: TOP-DOWN KONTRA BOTTOM-UP Det finns två sätt att bestämma vilken typ av tjänster och särskilda operationer som ska skapas i plattformen. Med top-down-strategin görs en förundersökning av organisationen med målsättningen att skapa en modell av organisationens data och processer. Med bottom-up-strategin skapas tjänster anpassade till verksamhetssystemets behov så gott det går, utan att ta hänsyn till entiteter eller processer som har betydelse för hela organisationen. Begränsningarna med Bottom-up-strategin metoden är flera, bland annat att likartade entiteter kan benämnas och formas på olika sätt i respektive tjänst. Om behovet av att utnyttja dessa tjänster i en process uppstår, kommer det att krävas utveckling av ett sambandslager mellan dessa tjänster vilket ökar förvaltningskostnaderna. Bottom-up-strategin utgår oftast från applikationsinriktad utveckling snarare än tjänsteorienterad utveckling (SOA). Applikationsinriktad utveckling har en benägenhet att förlita sig på äldre metoder som fokuserar på teknologin snarare än funktionens roll i verksamheten i ett större perspektiv. Detta komplicerar contract-first -utvecklingen som är central inom tjänsteorienterad utveckling. Resultatet kan bli att tjänster framställs på verksamhetssystemens villkor, utan en central styrning och hänsyn till tjänstegranularitet. Tjänsteutveckling med utgångspunkt från verksamhetssystem och teknologi skapar en hårdare koppling mellan systemen. Bottom-up-strategin kan snabbt skapa oordning i plattformen och motarbeta syftet med SOA-konceptet och skapa sådana situationer som SOA ska motverka. Med top-down-strategin undviks dessa problem genom att tjänsterna måste följa en informations- och processmodell. Detta gör att det skulle bli mycket enklare att implementera tjänster med standardkontrakt och därmed kan nackdelarna med bottom-upstrategin undvikas. Däremot så tar det väldigt lång tid att skapa affärsmodeller med top-down-strategin, vilket gör att man kan gå miste om en mer detaljerad bild som man får genom en riktig utförd tjänsteutveckling. 7 (47)

1.2.3 TJÄNSTE IMPLEMENTATIONER GENOM SOA-PLATTFORMEN Det finns tre referensmodeller när man implementerar tjänster i SOA-plattformen. Vilken referensmodell som skall användas när man skall implementera en tjänst i SOA plattformen beskrivs i beslutsträdet i avsnitt 3.1.1. För komplexa sammansatta tjänster bör ett uppstarts möte eller projekt initsieras tillsammans med Staden, Leverantören samt VIT som förvaltar SOA Plattformen för at inte skapa onödig med arbete för alla parter, om det visar sig att det blivit fel för att alla parter inte har förståt hur komplexa tjänster behöver designas. 8 (47)

1.2.4 SOA-PLATTFORMENS ARKITEKTUR För att få en överblick som utvecklare eller beställare så behöver man få en förenklad bild, för att förstå hur arkitekturen av SOA-plattformen är uppbyggd. Detta behövs också för att förstå vad och var den nya tjänsten kommer att operera i SOA-plattformen och för att få ut den optimala affärsnyttan av den eller de tjänster som skall implementeras. Så här ser den förenklade arkitektoniska plattformen ut idag. Bilden visar en plattform utan tjänster men visar flödet med de centrala komponenterna. 9 (47)

1.2.5 HOSTING Med hosting menas var och hur de nya tjänsterna skall köras i för värd t ex BizTalk, IIS(WAS), WCF eller WF. Det finns ett fall där Self Hosting t ex en Windows Service behöver användas och det är när behovet av en Call-Back funktionalitet behövs, detta beskrivs inte ingående i detta dokument. Men i beslutsträdet finns denna variant med. SOA-plattformen ska främst bestå av organisationsdata och de affärsprocesser som använder dessa data. Dessutom ska plattformen göra det möjligt att exekvera processerna. Det är plattformens tjänster som binder dessa enskilda koncept samman, och dessa tjänster måste placeras någonstans. De produkter och tekniker som kan agera som värd beskrivs i kapitel 2, för att få en insikt i de produkter och tekniker som används i SOA-plattformen. Valet av värd är en kombination av beslutsträdet (se avsnitt 3.1.1) samt processen för införande av tjänster, då Volvo IT samt Staden tar ett gemensamt beslut var tjänsten skall placeras i för värd. Från ett SOA-perspektiv så bör man undvika lokalt hostade tjänster i verksamhetssystem, så man inte hamnar i en spagetti miljö. Fördelar: Det snabbaste sättet att få igång en tjänst på eftersom de som skapar tjänsten redan kan systemet och förstår processen. Färre orosmoment vad gäller säkerheten om tjänsten ligger i samma miljö som verksamhetssystemet. Verksamhetssystemet kommer ändå att ha behov av uppdatering i samband med utvecklingen av tjänsten under implementeringen av adaptrar i plumbing-lagret. Nackdelar: Governance -regler blir svåra att upprätthålla vilket leder till en dålig kontroll över versionshantering, spårning etc. Ändringar i affärsprocessen kommer att kräva utvecklare som är väl förtrogna med verksamhetssystemen. Ju fler tjänster som är placerade i olika verksamhetssystem, desto svårare blir det att upprätthålla tjänsteregler inom företaget. Undantagshanteringen kommer att variera för de olika tjänsterna vilket gör att det kommer att bli svårt att införa anvisningar för undantagshantering eftersom systemen kan ha tekniskt olika databaser. Om verksamhetssystemet flyttas eller blir utbytt så försvinner tjänsten. Det är väldigt svårt att uppnå bra kvalitet när system skiljer sig åt så pass mycket, och uppkomsten av undermåliga tjänster kan påverka hela systemet. Risken för att plumbing (i detta fall adaption) och affärslogik blandas ihop är mycket större i detta fall. 10 (47)

1.3 LOGGNINGSRAMVERK FÖR SOA-PLATTFORMEN För att hantera spårbarheten för information och data som flödar igenom SOAplattformen kan nedanstående bild ge en översikt hur detta hanteras i SOA-plattformen. Då detta är en del av implementationen så kommer detta att beskrivas i implementations dokumenten. 11 (47)

1.4 HUR IMPLEMENTERAS EN TJÄNST I SOA- PLATTFORMEN? 1.4.1 IMPLEMENTERING AV TJÄNSTER Hur avgörs vilken teknik som ska användas för att implementera en tjänst? Vissa mönster är lättare att lösa med BizTalk än med WCF, andra mönster kommer att innebära extra arbete för BizTalk och det finns mönster som kommer vara helt omöjliga att implementera (både av tekniska och politiska skäl) utanför verksamhetssystemet. En beskrivning av de olika teknikerna finns i kapitel 2, som tillsammans med ett beslutsträd verkar som stöd för var tjänsterna kommer att placeras. 1.4.2 DATAREGLER I SOA-PLATTFORMEN Det finns flera problem som man bör uppmärksamma och undvika: 1) Tjänsteanvändarna kan ibland behöva en lista på data som representerar ett val i ett frågemeddelande till en SOA-tjänst. 2) Meddelanden som innehåller referensdata, dvs. databasnycklar, blir hårdkodade för databasstrukturen. Detta kallas tät koppling och bör undvikas. 3) Konstant behörighetshantering från SOA-datatjänster kan mycket väl generera en belastning som den ursprungliga databasen helt enkelt inte är byggd för och inte heller kommer att klara av. 4) Om SOA-datatjänster används för en särskild typ av referensdata kan det sluta med att en mängd tjänster uppstår, som är i stort sett lika, detta kommer att skapa förvirring och slöseri av resurser. 5) Utvecklare är vana vid att skicka databasnycklar för att kunna förbättra prestandan. Detta skapar mindre databastabeller men otydliga meddelanden som är tätt kopplade till ursprungssystemet. I en federerad miljö kan typ och struktur på nycklarna vara många och ofta väldigt svåra att integrera tillsammans och samtidigt behålla originalstrukturen på nycklarna. Argument: textdata är unik, är mer betydelsefull och löst kopplad. Mappning kan göras på den adaptiva nivån. Varför inte referensdata bör publiceras i meddelanden: 1. Till exempel; en lista som kallas kundtyp finns i tre databaser. Flera av SOAtjänsterna använder person typ för att utföra en operation som återfinns i de tre olika systemen. 2. En stund senare ska statistik tas fram baserat på kundtyp och informationen från de tre operationerna grupperas. Hur ska då datat länkas? 12 (47)

3. I ett av ovanstående system har transaktionerna lång körtid och kan ta upp till flera månader att bli färdiga. Om referensdata finns i meddelandet och ändras medan transaktionen pågår, så blir datat i meddelandet betydelselöst. 4. En ny kundtyp har lagts till i systemen. Om detta inte utförs på exakt samma tidpunkt i alla tre systemen kan data cirkulera runt och till slut hamna hos ett system där datat inte längre har någon betydelse. 1.5 SOA PLUMBING TJÄNSTER & REGLER I SOA-plattformen finns ett antal generella tjänster och regler som är till för att stödja SOA-plattformen med gränsöverskridande tjänster, så att alla tjänster som implementeras i SOA-plattformen får samma typ av plumbing-tjänster. Nedan vissas vilka typer av plumbing-tjänster som finns i SOA-plattformen samt exempel på vilka produkter som används. Implementeringen av dessa plumbing-tjänster beskrivs i dokumentet Utvecklingav tjänster. Även om det är gemensamma tjänster så är det designat så att de olika verksamhetssystemen eller tjänsterna inte blandas ihop. 1.6 SOA PLATTFORMS TJÄNSTER För att minska antalet tjänster som behöver tillföras i Staden, finns det ett antal generella SOA-tjänster som tillhandahålls för förvaltningar och bolag att nyttja. De tjänster som finns tillgängliga är nedanstående tjänster, som beskrivs under i kapitel 2. De gemensamma tjänsterna kommer att växa i antal då det tillkommer nya gemensamma tjänster efter behov. De röda rutorna nedan är gemensamma tjänster men förvaltas inte av Volvo IT. 13 (47)

2 KOMPONENTER 2.1 ÖVERSIKT Här beskrivs vilka komponenter som ingår i Stadens SOA-plattform samt en generell beskrivning av de enskilda komponenterna och vad de används till i dagens SOAplattform. 14 (47)

2.2 PRODUKTEN BIZTALK BizTalk har en hög nivå av funktionssäkerhet och återhämtningsförmåga och är en färdigförpackad host -lösning med inbyggd spårning, uthållighet samt inbyggda övervakningsverktyg. Därför är BizTalk förstahandsvalet för alla tjänster. Men.NET 4.0 och Workflow-tjänsterna kan förvirra och påverkar beslutet då denna typ av teknologi i kombination med Windows Appfabric har kopierat BizTalks starka sidor och gjort om dem till mindre komplexa ramverk, som t.ex. med korrelation. Att använda BizTalk för att skapa och placera tjänster innebär en försämring av prestanda, eftersom allt måste gå igenom meddelandeboxen. Vissa tjänster kommer inte att kräva den nivå av funktionssäkerhet som BizTalk erbjuder och istället ha ett större behov av korta svarstider. Dessa tjänster kan då istället implementeras som oberoende WCF-tjänster. Försök att undvika lokalt (i verksamhetssystemet) implementerade tjänster. Heterogena system Varje IT-avdelning av rimlig storlek använder system från minst två separata leverantörer. I denna heterogena värld finns det ett antal utmaningar som man alltid står inför: Inkompatibla dataformat. Inkompatibel system metadata. Metadata som är utspridda system, utan konsekvent struktur och representation. Transport och applikationsspecifika protokoll: HTTP, SFTP, HTTPS, MSMQ, IBM MQSeries, SAP-IDOC, RFC, BAPI och SAP DB. Inkompatibla meddelande protokoll: SWIFT kontra FIX, X12 kontra EDIFACT, EDIINT, RNIF, BTF 2,0. Alla har olika tillförlitliga protokoll som måste stödjas. Svag process, synlighet: Hur kan jag se vad som händer? BizTalk som produkt erbjuder lösningar för ovanstående problem, med hjälp av de inbyggda komponenter som finns i BizTalk produkten. 15 (47)

2.2.1 VAD GÖR BIZTALK SERVER? De flesta Microsoft-produkter ger viss funktion/funktionalitet. Microsoft Exchange Server äger e-post, SQL Server äger datanivån, och IIS är Microsofts webbhotelllösning. BizTalk Server är Microsofts premium integrationslösning för verksamheter. Med få ord, det ger möjlighet att ansluta olika heterogena system tillsammans. Detta ger en fullständig systemintegration, som går längre än bara dataanslutning samt adapteranslutningar och meddelande transformation som används för data. En robust orkestreringsmotor gör det också möjligt för komplexa händelser och tunga processer som ska hanteras. BizTalk ger också möjlighet att exponera och konsumera tjänster, övervaka end-to-end process flöden (förutsatt att man har insyn i processen), och även RFID-anslutning. Följande är de viktigaste faktorerna att tänka på: Anslutningsformat: antalet och komplexiteten av olika applikationer/system som man behöver ansluta till, är en viktig faktor. BizTalk har en omfattande flora av anslutningsmöjligheter med 25 out-of-the-box-adaptrar och har fler tillgängliga adaptrar paketerade; dessutom finns adaptrar från tredjepartsleverantörer. En majoritet av dessa är utvecklade ovanpå WCF LOB Adapter SDK, så att de kan användas från alla.net applikationer. Detta innebär att antingen kan BizTalk Server användas, eller så används WCF-adaptrar utanför BizTalk Server miljön i ett LOBsystem. Eller så kan man använda en annan host, såsom Windows AppFabric, eller i ett eget anpassad värdprogram. Dataformat: Det finns fortfarande inget generellt XML-beställnings-format i alla system, och därför krävs meddelandetransformation. Detta är ofta det krav som är mest utmanade, eftersom olika leverantörers LOB-system tenderar att ha ett olika sätt att modellera och lagra organisatorisk metadata. Detta innebär mer jobb för att få transformationen korrekt mellan organisationer. Det är mycket ovanligt att hitta ett gemensam XML-meddelandeformat som kan användas i alla system inom en organisation. Utöver detta kan LOB-system komma att uppgraderas, byta version, och så vidare, alla dessa faktorer kan påverka den modell som används. Detta förvärras av det faktum att en organisation kan besluta att ändra attributen för de metadata som har modellerat LOB-applikationen. Om en tät koppling byggs mellan varje LOB, är det viktigt att beakta det arbete som krävs vid en förändring på båda systemen. I synnerhet bör man vara uppmärksam på schemat och förändringar av modell och överväga hur mycket utvecklingsarbete som detta kommer att kräva. 16 (47)

Process Management: WCF ger en separation av kontrakt (funktionalitet) och datatransport (bindning). Detta ger endast en anslutning, men tjänstevärden behövs fortfarande för att hantera stabiliteten för tjänsten, förse med verktyg, hantera utskalning, och så vidare. BizTalk tillhandahåller denna och även andra byggstenar som kan användas i din applikation. Sammanfattningsvis, för att möta verksamhetens behov, måste lösningar faktisk tillhandahålla en versionskontroll, förmågan att rulla ut olika versioner, med liten eller ingett driftstopp, hantera tjänster som processas under en lång tid, och även ha robusta instrument och verktyg. BizTalk tillhandahåller en rik värdmiljö som har dessa funktioner. Hosting i BizTalk Nedan listas för och nackdelar med att hosta i BizTalk: Fördelar: Enkel integrering med externa system genom adaptrar som inte kan erbjuda WSDL-baserade tjänster. Avancerat stöd för Business Process Management (Process services). Lätt att abstrahera från implementeringen genom att skapa interna scheman och reducera kopplingen till verksamhetssystemen. Inbyggd spårning. Standardiserad undantagshantering (ESB Guidance) Bra nivå av lös koppling (ESB Guidance) Funktionssäker meddelandetjänst som är enkel att implementera. Enklare att ändra affärsprocessen än att utföra ändringar i kod. Utmärkt EDI-stöd. Orkestreringsdesigner. Orkestreringar kan läggas upp som WCF-tjänster för enkel åtkomst för användarna. Färdig PUB/SUB-arkitektur. Enkel administration, övervakning. Persistering, transformering och korrelationsfunktionalitet. Funktionssäkerhet. Tjänst för affärsregler. Nackdelar: Prestandaförlust p.g.a. bearbetning av meddelandebox, längre svarstider. Svårt att hantera stort antal av exponerade WCF-tjänster. BizTalk-utvecklare är inte lika vanligt förekommande som.net/wcfutvecklare och tjänster som behöver skapas i BizTalk kan därför dröja i väntan på rätt kompetens. Ovanstående exempel är några punkter att tänka på inför implementering av tjänster i SOA-plattformen. 17 (47)

2.2.2 BIZTALK SCENARIER Den moderna företaget har ofta problem med sina integrationer av olika system., Ofta är problemet att man har många system som har ett-till-ett förhållande och detta mynnar ut i en s.k. spagettimiljö, som inte naturligt kan kommunicera med varandra på grund av inkompatibla plattformar, dataformat och säkerhetspolicy. Detta kan innebära problem för normala affärsverksamheter. Till exempel när en nyanställd börjar behöver en post skapas i HR-systemet och en order på en bärbar dator placeras i affärssystemet. Ett konto kan behöva skapas för dem i CRMsystemet med lämplig nivå av access. För att undvika att göra detta manuellt kan man skriva ett program som har all inbyggd logik som krävs för att ansluta till dessa olika system. Eller kanske har HR-systemet en modul, som gör att man kan använda några programmeringsspråk för att bygga logiken där. Med tiden, behövs en tålig host utvecklas för att köra den anpassade integrationskoden. Tät koppling mellan system innebär att eventuella förändringar ofta bryter den anpassade integrationen i flera system och kräver förändringar i flera system. Tyvärr resulterar punkt-till-punkt tillvägagångssätt att man hämmar en organisation från att söka ett serviceinriktat förhållningssätt gentemot systemintegration. För att undvika detta problem, använder sig många organisationer av BizTalk som Integrations Broker. Detta ger följande funktionalitet: Centraliserad förvaltning och administration av integrationernas endpoints och under liggande instanser. Lösa kopplingar av applikationer, vilket innebär inga fysiska beroenden mellan program. Hållbar infrastruktur med en skalbar modell. Insikt i meddelandet flödet och affärsprocesserna genom BizTalk Tracking and Business Activity Monitoring (BAM). Följande diagram visar BizTalk i en integrations brokers roll. Detta är den klassiska användningen av BizTalk och något som har förankring i de 10 år som gått sedan den första versionen levererades. 18 (47)

Business-to-Business (B2B) Det andra scenariot är att använda BizTalk som business-to-business broker för att hantera all kommunikation över organisationens gränser. BizTalk stöder Internet-vänliga adaptrar och kan även kommunicera med äldre och icke-internet vänliga endpoints system. Det stöder också channel och meddelandebaserad säkerhet. BizTalk Server ger inbyggt stöd för EDI och en mängd av acceleratorer är inriktade på specifika industrivertikaler, inklusive en SWIFT (Society for Worldwide Interbank Financial Telecommunication)-accelerator för finansiella tjänster. Detta minskar den tid som krävs för att genomföra hållbar och robust B2B-kommunikation. Business Process Automation (BPA) BizTalks kapacitet kan utnyttjas för att automatisera befintliga manuella processer i organisationer. Vanligtvis har scenarier som är repetitiva och definieras av regler och policys samt involverar flera system, typiska fall för att använda sig av BPA. Enterprise Service Bus (ESB) BizTalk kan agera som en centraliserad tjänstebuss för organisationen, som visas i bilden nedan. Genom att exponera on-ramper till en mängd destinationer, som bestäms när meddelandet tas emot, gör BizTalk det möjligt att fungera som en varaktig meddelandebuss som är ansvarig för att samordna kommunikationen i hela organisationen. Med BizTalk Server 2010 släppte Microsoft ESB Toolkit 2,1 som bygger ut kärnan för BizTalk-plattformen för att minimera den tid som behövs för att genomföra detta scenario. 19 (47)

2.3 BIZTALK ESB TOOLKIT BizTalk ESB Toolkit 2.1 är en samling av verktyg och bibliotek som utökar BizTalk Server 2010 funktioner för att stödja löst kopplade och dynamiska arkitekturer för meddelandehantering. Den fungerar som middleware som ger verktyg för en snabb medling mellan tjänster och deras konsumenter, samt aktiverar maximal flexibilitet vid runtime körning. BizTalk ESB Toolkit 2.1 förenklar löst kopplade sammansättning av tjänster ( endpoints ) och hantering av tjänsternas interaktioner. BizTalk ESB Toolkit 2.1 viktigaste block och byggstenar och arkitektur visas i nedanstående bild. 20 (47)

Dokumentationen av ESB Guidance beskriver följande situationer där komponenterna kan användas: Point-to-Point Resolution of Endpoints and Transformation Requirements (point-to-point-lösningar av endpoints och konverteringskrav) Request-Response Resolution of Endpoints and Transformation Requirements (lösningar på förfrågningar/svar av endpoints och konverteringskrav) Transformation Without Persisting in the BizTalk Message Box Database (konvertering utan persistering i BizTalk Message Box Database) Defining Routing and Message Transformation Service Invocations Using Itineraries (fastställa anrop av konverteringstjänster för routing och meddelanden genom att använda resvägar) Defining Routing and Message Transformation Through Multiple Orchestrations Using Itineraries (fastställa konvertering av routing och meddelanden med multipla orkestreringar genom att använda resvägar) Defining Custom Orchestration Service Execution Using Itineraries (fastställa anpassat tjänsteutförande av orkestrering genom att använda resvägar) Routing a Message to a Disk Folder, Queue, or FTP Folder ( routing av meddelanden till disk-katalog, kö eller FTP-katalog) Transforming and Routing a Message to Disk Folder, Queue, or FTP Folder (transformering och routing av meddelande till disk-katalog, kö eller FTP-katalog) Collecting Exceptions and Routing Messages for Repair and Resubmit (uppsamling av undantag och routing -meddelanden för reparation och återinsändning) Collecting Exceptions and Persisting the Payload Using the ESB Exception Processor (uppsamling av undantag samt persisteringar av nyttolast genom att använda ESP undantagsprocessor) Repairing and Resubmitting Messages Using the ESB Management Portal (reparera och åter insända meddelanden genom att använda ESBförvaltningsportal) Preserving JMS Headers When Routing Through an Orchestration (bevara JMS-sidhuvuden under routing genom en orkestrering) Handling Externally Submitted Exceptions with a Custom Handler (hantering av externt insända undantag genom en anpassad hanterare) Adding and Removing Namespaces in an XML Message Document (tillägg och borttag av namnrymd i ett XML-meddelandedokument) Implementing the Scatter-Gather Pattern for Multiple Web Service Invocations (implementering av spridnings-ihopsamlingsmönsret för multianrop av webbtjänster) Transforming and Routing a Message to Multiple Endpoints (transformering och routing av meddelanden till flera endpoints) 21 (47)

Grundfunktionen hos ESB Guidance är att minska kopplingsnivån mellan tjänsterna och deras konsumenter. Meddelanden kan styras till endpoints baserat på inmatningar i en databas, UDDI-minne, affärsregel etc. Resvägar för meddelanden kan anges innan meddelandet skickas till systemet, vilket gör det möjligt för klienter att designa egna sammansatta tjänster utan att behöva skapa eller kompilera kod. Enbart detta är en stor fördel för att snabbt kunna implementera affärsprocesser. Mycket av funktionaliteten som beskrivits ovan kan också användas för att lösa generella problem i alla BizTalk-projekt och inte enbart i ESB-baserad arkitektur. 22 (47)

2.4 APPFABRIC Vad är Windows Server Appfabric? En sanning när man utvecklar applikationer är: Applikations utvecklare ska inte spendera sin tid med att skapa infrastruktur. Även om varje applikation behöver supporttjänster, skall resurser som kodar dessa applikationer endast fokusera på att generera och skapa mervärde för användarna av applikationen. Oberoende av infrastruktur som behövs så skall infrastrukturen finnas på den plattform de utvecklar mot. En väg att förbättra plattformen är att förse den med en bättre applikationsinfrastruktur, och det är här AppFabric kommer in i bilden. Microsoft har skapat en rad av utökningar ( extensions ) för rollen Applikations Server, där de gjort ordning ett ramverk för att hantera WCFtjänster som hanteras genom IIS administratörskonsol. AppFabric s funktioner för hosting förbättrar värdskapet för.net Framework version 4 WCF och Windows Workflow Foundation (WF) tjänster i Windows Process Activation Service (WAS) genom att tillhandahålla de följande funktioner: Förenklad driftsättning och hantering av WCF och WF tjänsterna värd i WAS Förenklad konfiguration av arbetsflöden som pågår över en lång tidsperiod Anpassningsbara spårningsprofiler som gör att man kan fånga endast de data man behöver. Sökningsbar lagring för spårade uppgifter. Windows PowerShell cmdlets gör att man kan skapa egen förvaltnings skript. Anpassningsbar övervakning av värdtjänster. Stöder Internet Protocol Version 6 (IPv6) i Windows IPv6-stacken. Automatisk start av program för att minimera tjänstens fördröjning. AppFabric cache-funktioner ger en distribuerad cache i minnet för att hantera skalbara, tillgängliga och högpresterande applikationer. Följande är de viktigaste funktionerna i AppFabric caching: lagrar alla serializable serialiserbara CLR objekt i cache och ger tillgång till dessa genom enkla API er. Common Language Runtime (CLR) är en virtuell maskin och huvudkomponenten i Microsofts.NET initiativ. Det är en implementering av standarden Common Language Infrastructure, som definierar en exekveringsmiljö för programkod. CLR exekverar en typ av bytekod som kallas CIL (Common Intermediate Language). Stöder verksamhetens storlek. Kan konfigureras för att köras som en tjänst över nätverket. Stöder vanliga cache-konfigurationer. Stöder dynamisk skalning genom att lägga till nya noder. 23 (47)