2006:62
E X A M E N S A R B E T E
Tjänsteorienterad arkitektur (SOA) för integration
mot upphandlingssystem
Ayman El-Jammal Johan Öhman
Luleå tekniska universitet Examensarbete, påbyggnadsutbildningar
Datateknik
Institutionen för Systemteknik Avdelningen för Medieteknik
Förord
Denna rapport är en examinationsuppgift omfattande 20 poäng inom Magisteringenjörsprogrammet i datateknik vid Luleå Tekniska Universitet.
Examinationsuppgiften är det sista och viktigaste momentet i utbildningen och avser att tillämpa kunskaper som förvärvats under studietiden för att
vetenskapligt lösa en förelagd uppgift.
Uppgiften har utförts i samarbete med IT‐företaget Avantra AB i Luleå under våren 2006.
Vi skulle vilja tacka vår examinator Mikael Drugge samt all personal på Luleå Tekniska Universitet som hjälpt oss slutföra vårt arbete. Vi vill även rikta ett stort tack till vår handledare John Landeborg och övrig personal på Avantra AB som bidragit med tid, resurser och gott bemötande.
Luleå, september 2006
Ayman El‐Jammal & Johan Öhman
Preface
This report is a degree thesis consisting of 20 points within Master’s Programme in Computer Science and Engineering at Luleå University of Technology. The degree thesis is the final and most important part of the programme and is intended to apply the knowledge acquired during the education period in scientifically solving a prescribed assignment.
This thesis was performed in cooperation with IT‐business company Avantra AB in Luleå during the spring of year 2006.
We would like to thank our examiner Mikael Drugge and all personnel at Luleå University of Technology who helped us complete our work. We would also like to thank our supervisor John Landeborg and all other personnel at Avantra AB, for all the time and efforts they contributed with.
Luleå, September 2006
Ayman El‐Jammal & Johan Öhman
Sammanfattning
Det finns många olika typer av affärssystem på marknaden och företagen har investerat i egna unika IT‐lösningar, vilket har medfört att man har låst in sig i den egna tekniska plattformen genom bland annat punkt till punkt‐
implementationer. För att råda bot mot detta är det då önskvärt att olika system och applikationer ska kunna kommunicera med varandra genom att utbyta data på ett standardiserat sätt. För att uppnå dessa integrationsmål har en tjänsteorienterad arkitektur, Service Oriented Architecture (SOA) växt fram.
Syftet med denna uppgift är att undersöka möjliga metoder för att utveckla en tjänstebaserad arkitektur för integration mot Avantra AB:s upphandlings‐
system, Avantra Upphandling. Detta utifrån krav och direktiv som ställdes av Avantra samt de möjligheter och begränsningar som styrs av deras utvecklings
‐miljö, ‐verktyg och ‐rutiner. Efter utförda analyser av lämpliga metoder har en valts och en prototyp, delmängd av en fullskalig integrationslösning utvecklats.
Efter direktiv från Avantra kom analysen att omfatta Microsofts integrations‐
plattform BizTalk samt olika sätt att utveckla tjänstebaserade lösningar med Web Services.
Nyckelord:
‐ B2B
‐ Integration
‐ Microsoft BizTalk
‐ SOA
‐ SOAP
‐ Web Services
‐ WSDL
‐ XML
Abstract
There are many types of business systems on the market and companies have invested in own unique IT‐solutions that have resulted in companies limiting themselves to their own technical platforms, through point‐to‐point
implementations among other things. To solve this, it is desirable that different systems and applications should be able to communicate with each other by exchanging data in a standardised manner. These aims of integration can be reached by using Service Oriented Architecture (SOA).
The purpose of this assignment is to examine possible methods for deployment of a Service Oriented Architecture for integrations with Avantra AB’s
procurement system, Avantra Upphandling. This is to be done with the
requirements and directives given by Avantra and in consideration with the possibilities and limitations settled by their development environment, tools and routines. After analysing adequate methods, one was chosen and a prototype, a subset of a complete integration solution was developed.
With the directives given by Avantra, the analysis consisted of Microsoft’s integration platform BizTalk and various ways of developing service‐based solutions using Web Services.
Key words:
‐ B2B
‐ Integration
‐ Microsoft BizTalk
‐ SOA
‐ SOAP
‐ Web Services
‐ WSDL
‐ XML
Innehållsförteckning
1 Inledning ... 3
1.1 Bakgrund ... 3
1.1.1 Avantra AB ... 3
1.1.2 Författarnas bakgrund... 4
1.2 Syfte ... 4
1.3 Direktiv... 4
2 Teori ... 5
2.1 Avantra Upphandling ... 5
2.2 Tjänstebaserad arkitektur; SOA... 5
2.2.1 Vad är SOA? ... 5
2.2.2 Vilka delar ingår i en SOA? ... 6
2.2.3 Fördelar... 7
2.2.4 Nackdelar... 8
2.3 XML ... 8
2.3.1 Fördelar med XML ... 9
2.3.2 XML Schema (XSD) ... 9
2.4 SOAP... 10
2.5 XML Web Services... 11
2.5.1 UDDI ... 14
2.5.2 WSDL... 14
2.5.3 Code‐first .NET Web Services... 15
2.5.4 Contract‐first .NET Web Services ... 15
2.6 Microsoft BizTalk Server 2006 ... 16
2.6.1 Vad är BizTalk? ... 16
2.6.2 Vilka delar består BizTalk av?... 16
2.6.3 Hur används och fungerar BizTalk?... 17
3 Metod... 25
4 Utvärdering/resultat ... 27
4.1 Analys av Avantras behov ... 27
4.2 Analys av BizTalk som integrationslösning(plattform) ... 28
4.2.1 Gränssitt och funktionalitet ... 28
4.2.2 Säkerhet och transaktionshantering ... 28
4.2.3 Driftövervakning ... 29
4.3 Analys av egenutvecklad integrationslösning med .NET Web Services ... 30
4.3.1 Gränssitt och funktionalitet ... 30
4.3.2 Säkerhet och transaktionshantering ... 33
4.3.3 Driftövervakning ... 34
4.4 Resultat av analyser/Val av integrationslösning... 35
5 Integrationslösning Avantra‐IBS ... 37
5.1 Introduktion ... 37
5.2 Krav ... 37
5.2.1 Bas ... 37
5.2.2 Extra ... 37
5.3 Översiktsbeskrivning... 38
5.3.1 Databas ... 38
5.3.2 Web Service ... 38
5.3.3 Testklient ... 39
5.4 Leveransvillkor ... 40
5.4.1 Leveransplats ... 40
5.4.2 Leveranstidpunkt... 40
5.4.3 Underhåll... 40
6 Diskussion... 41
7 Referenser... 43
7.1 Böcker ... 43
7.2 Rapport/uppsats/avhandling... 43
7.3 Tidningsartiklar ... 43
7.4 Elektroniska medier ... 43
8 Bilagor... 45
8.1 Ordlista... 45
8.2 Översiktsbild av integrationslösning ... 49
8.3 Datamodell ... 51
8.4 Web Servicens parametrar ... 53
8.5 Teknisk gränssnittsdesign för Web Service ... 55
8.6 Testklient ... 57
8.7 SOAP‐meddelanden ... 59
1 Inledning
1.1 Bakgrund
Det finns många olika typer av affärssystem på marknaden och företagen har investerat i egna unika IT‐lösningar, vilket har medfört att man har låst in sig i den egna tekniska plattformen genom bland annat punkt till punkt‐
implementationer. För att råda bot mot detta är det då önskvärt att olika system och applikationer ska kunna kommunicera med varandra genom att utbyta data på ett standardiserat sätt. Vid införandet av nya system bör dessa kunna kommunicera med den befintliga IT‐miljön.
För att uppnå dessa integrationsmål har en tjänsteorienterad arkitektur, Service Oriented Architecture (SOA) växt fram. Många förutspår att SOA kommer att slå igenom på bredfront och anledningen till detta är att det finns färdiga industristandarder som stora programutvecklande företag har enats om. Dessa möjliggör ett plattformoberoende och därmed en stabil grund för olika
integrationslösningar.
Internets framväxt som medium har också medfört att det går att utveckla billiga lösningar med enorm spridning. I många sammanhang används Web Services för att skapa en tjänsteorienterad arkitektur. Web Services möjliggör överföring av meddelanden eller åtkomst till komponenter över Internet.
Kommunikationen kan ske på ett säkert sätt mellan två parter med olika plattformar och genom brandväggar. Eftersom det finns ett stort integrations‐
behov har företag som Microsoft (Biztalk), IBM (WebSphere) och SUN (Seebeyond) gett sig in på marknaden med egna produkter för att hantera affärsprocesser genom bland annat en tjänstebaserad arkitektur.
Sammanfattningsvis torde företagen som använder sig av SOA‐arkitekturen öka den interna effektiviteten radikalt samtidigt som de skapar ökad kundnytta genom att koppla ihop externa och interna processer. Har ett system dessa egenskaper, kan det ofta ses som en avgörande orsak till ett affärssystems framgång på marknaden.
1.1.1 Avantra AB
Examensarbetet har utförts i samarbete med Luleå baserade IT‐företaget
Avantra AB. Verksamheten omfattar konsulttjänster och produktutveckling
med inriktning mot IT‐området. Avantras kärnverksamhet riktar sig mot en
produkt kallad Avantra Upphandling. Produkten stödjer upphandlare i framför
allt offentlig sektor men även stora företag i sina upphandlingar genom hela
upphandlings‐ och avtalsprocessen.
1.1.2 Författarnas bakgrund
Examensrapporten (20 poäng) skrivs som en avslutande del inom
Magisteringenjörsprogrammet i datateknik (160 poäng) vid Luleå Tekniska Universitet. Utbildningen är en påbyggnadsutbildning till en treårig
Högskoleingenjörsutbildning i datateknik (120 poäng). Arbetet görs inom ämnesområdet programvaruteknik som varit inriktningen under utbildningen.
1.2 Syfte
Syftet är att analysera och ta fram en metod för att utveckla tjänstebaserade lösningar med avseende på Avantras krav och direktiv och utveckla en prototyp, delmängd av en fullskalig integrationslösning. Analysen omfattar Microsofts integrationsplattform BizTalk samt olika sätt att utveckla
tjänstebaserade lösningar med Web Services.
Man vill finna en allmän integrationslösning för export och import mellan kunders externa system och Avantra Upphandling. Arbetet består av att ta fram en lösning som möjliggör delning av data och processer mellan godtycklig applikation eller datakälla, oberoende av plattform. Detta skall kunna göras utan omfattande ändringar i applikationer och lager/datastrukturer.
Det är sedan tänkt att Avantra ska kunna följa designmönstret som tas fram för att i slutändan utveckla i en fullskalig tjänstebaserad integrationsplattform.
1.3 Direktiv
Avantra har givit som direktiv att företaget vill standardisera sina rutiner för att effektivisera införandet och underhållet av integrationer mot andra system och på så sätt uppnå fördelar gentemot sina konkurrenter. För systemets export och import av data mot externa system har varje lösning implementerats som en kundunik punkt till punkt‐lösning, vilket medför att stora resurser går åt vid införande och underhåll av integrationen. Avantra vill att integrationslösningen som ska utvecklas ska ligga som ytterligare ett lager i systemet och utnyttja så mycket av den funktionalitet som redan finns, främst genom databasens lagrade procedurer, så kallade Stored Procedures. Om ytterligare programvara ska installeras ska den fungera i den existerande miljön för Avantra
Upphandling hos kunden. All ny funktionalitet (kod) ska implementeras i C#/.NET.
Under en senare del av projektet fick vi till uppgift att utveckla en lösning för kunden IBS som bygger på den genomförda analysen av integrationslösning.
2 Teori
2.1 Avantra Upphandling
Avantra Upphandling, AU 5.0 är utvecklat och fungerar i en Microsoft‐miljö innehållande Windows 2000 Server/XP Professional, IIS‐server, SQL Server 2003 och .Net Framework. Systemet är uppbyggt i en skiktad lösning av lager.
Lagerstrukturen består av ett gränssnitt, ett affärslager och ett datalager.
Gränssnittet och lagren är programmerade i .NET Framwork 1.0 och högre, med hjälp av Visual Studio. Gränssnittet är ett tunt lager som kommunicerar med affärslagret, Busniess Object Layer, som i sin tur kommunicerar med datalagret, Data Access Layer. Kommunikationen mellan lagren sker via COM+
och .NET Remoting. SQL Server är grundstommen i systemet och mycket av funktionaliteten definieras i databasen med hjälp av bland annat lagrade procedurer, så kallade Stored Procedures. Till systemet finns också ett antal ASP‐implementerade webbmoduler.
2.2 Tjänstebaserad arkitektur; SOA
2.2.1 Vad är SOA?
Oasis Reference Model for Service Oriented Architecture 1.0 beskriver SOA enligt följande: ʺService Oriented Architecture (SOA) is a paradigm for
organizing and utilizing distributed capabilities that may be under the control of different ownership domains.ʺ [16]
SOA kan ses som en arkitekturutveckling eftersom den bygger på arkitekturer och standarder som kom före den. [19]
Applikationsintegration är en av de viktigaste frågorna företag ställs inför.
Systemtillgänglighet, ‐pålitlighet och ‐skalbarhet belastar företagen. Med dagens krav är SOA den bästa skalbara lösningen för applikationsarkitekturer.
[9]
SOA är alltså ett systemarkitektiskt koncept som beskriver användningen av tjänster för att uppfylla de affärsmässiga kraven på IT‐system. Tjänsterna samverkar baserat på en formell definition eller kontrakt som är fristående från den underliggande plattformen och programspråken. Gränssnittet gömmer den språkspecifika tjänsteimplementationen. Mjukvarukomponenterna blir väldigt återanvändbara eftersom gränssnittet är oberoende av den underliggande implementationen. På så sätt kan exempelvis en tjänst utvecklad i C#/.NET på Windows Server‐miljö anropas av en Java‐applikation som exekveras i en UNIX‐miljö. [19]
SOA förknippas ofta med webbtjänster baserade på XML, SOAP, WSDL och
UDDI, men i princip kan SOA byggas med vilken tjänstebaserad teknik som helst. De första tjänstebaserade arkitekturerna byggdes med DCOM eller Object Request Broker (ORB) baserad på CORBA. Men SOA:s popularitet har ökat kraftigt i och med Web Services. [19]
2.2.2 Vilka delar ingår i en SOA?
Enligt Hashimi [9] finns det fyra nyckelkomponenter som spelar en viktig roll i en tjänstebaserad arkitektur; tjänster, meddelanden, dynamisk upptäckt, och Web Services.
Tjänster
Tjänsters funktionalitet exponeras med tre egenskaper:
1. Gränssnittets kontrakt är plattformsoberoende. Vilket innebär att en klient från en valfri plats, med valfritt programmeringsspråk och operativsystem kan använda tjänsten.
2. En tjänst kan vara dynamiskt lokaliserad och involverad, vilket innebär att en klient kan använda denna för att hitta en tjänst man eftersöker.
3. Tjänsten i sig är en fristående del och detta innebär att tjänsten upprätthåller sitt eget tillstånd.
Meddelanden
De som tillhandhåller och de som använder sig av en tjänst kommunicerar genom meddelanden. Tjänstens gränssnitt beskriver vad tjänsten har för argumenttyp och returtyp och eftersom tjänsten är plattform/språkoberoende måste teknologin för meddelandet inte veta något om den specifika plattformen eller programspråket klienten kommer att använda. Just därför är meddelandet oftast ett W3C Standard XML‐dokument som bekräftas/valideras mot ett XML‐
schema.
Dynamisk upptäckt
Dynamisk upptäckt är en viktig del av SOA och på en hög nivå består SOA av tre huvuddelar; tjänsteleverantör, tjänsteanvändare (klienter) och
katalogtjänsten. Katalogtjänsten fungerar som en mellanhand för de som tillhandahåller och de som använder tjänster. De som tillhandahåller tjänsten registrerar sig med en katalogtjänst och användaren gör en förfrågan mot katalogtjänsten för att hitta lämpliga tjänsteleverantörer. De flesta
katalogtjänster organiserar tjänsterna och kategoriserar dem. Genom att inbädda en katalogtjänst i en SOA åstadkommer man en lösning som:
1. Är skalbar, man kan lägga till tjänster eftersom.
2. Håller klienterna åtskilda från tjänsteleverantörerna.
3. Tillhandahåller uppdatering för tjänsten.
4. Tillhandahåller söktjänst för klienter.
5. Tillåter klienter att välja mellan olika tjänsteleverantörer under körning.
Web Services
Web Services är en implementation av SOA och beskrivs i kapitel 2.5.
2.2.3 Fördelar
• SOA kan hjälpa affärsverksamheten att snabbare reagera på ändringar i markandsvillkoren och på så sätt bli mer kostnadseffektiva. [19]
• Löst kopplade applikationer.
När applikationerna är löst kopplade sker den enda interaktionen mellan applikationerna i det publika gränssnittet. Från utvecklares synvinkel betyder det oftast att ändringar i en applikation inte påverkar andra applikationer. [12]
• Lokal‐transparens.
Betyder att användaren av tjänsten inte behöver bekymra sig om var implementationen av tjänsten återfinns. Detta kan vara användbart då servern där tjänsten är implementerad flyttas eller när en klient vill lokalisera vilken tjänsteimplementation som för tillfället svarar bäst. [12]
• Återanvändning av kod.
Innebär att återanvändning av kod kan ske över olika plattformar och programspråk. Man behöver exempelvis inte skriva om en Java‐metod som fungerar för sitt ändamål till en C#‐metod. [12]
• Fokuserar på utvecklarens roll.
En tjänstebaserad arkitektur brukar kräva att applikationer har en flerlagrigstruktur. Kunskap om hur olika lager arbetar kan åtskiljas mellan utvecklarna, exempelvis kan utvecklaren som är ansvarig för dataåtkomstlagret ha expertkunskap inom SQL, ADO.net etc. och utvecklaren som ansvarar för autentiseringslagret har expertkunskap inom områden som LDAP, WS‐securtiy etc. [12]
• Bättre testning.
Enklare att testa tjänstegränssnitten genom testprocedurer där varje element testas var för sig. [12]
• Parallell utveckling.
Utvecklare kan jobba självständigt när de har samma gränssitt att jobba mot. Så när gränssnittet är färdigutvecklat kan varje utvecklare jobba med sin del av tjänsten. [12]
• Bättre skalbarhet.
Lokal‐transparensen gynnar skalbarheten. [12]
• Bättre tillgänglighet.
Lokaltransparensen gynnar tillgängligheten. [12]
• Bättre och enklare förvaltning och underhåll.
Lättare att lokalisera fel eller byta ut komponenter i ett tjänstelager än i ett system. [14]
• Minskade hårdavarukostnader Tjänster är centraliserade. [8]
• Bättre säkerhet
Ökad säkerhet genom fler lager med fler verifieringar både på klient‐ och tjänstesidan. [8]
• Bättre informationskvalitet. [14]
• Tydligare ägarskap av information och tjänster. [14]
• Utnyttjar redan existerade investeringar i teknologin. [8]
2.2.4 Nackdelar
• Beroende av utomstående system som man ej har kontroll över. [5]
• Kostsam inköpsport för att bygga om till tjänstebaserad arkitektur. [6]
• SOA används inte i många system idag, detta gör att det inte finns många tillgängliga tjänster och få med kunskaper om hur man bygger dem. [5]
• Kräver mer teknik för säkerhet och transaktioner. [14]
• Kräver mer versionshantering. [14]
• Ett SOA‐projekt kräver ett brett samarbete mellan olika experter inom olika områden.
2.3 XML
eXtensible Markup Language (XML) är ett metaspråk, definierad av World Wide Web Consortium (W3C), som i enklaste mening består av regler och instruktioner för hur strukturerad data kan beskrivas i klartext hellre än genom binära representationer. [1]
XML har lett till stora förändringar i mjukvaruutvecklingen främst i tre avseenden; dataoberoende, arkitektur och mjukvaruutveckling. [1]
• Dataoberoende:
Datat i XML, som är ren databeskrivning, är inte bundet till något
specifikt programmeringsspråk, operativsystem eller transportprotokoll, utan kan röra sig fritt genom att använda olika webbprotokoll.
Transportprotokoll som exempelvis HTTP har haft en storskalig inverkan på XML:s gångbarhet och öppnat dörrarna för alternativ till CORBA, RMI, och DCOM, som inte fungerar över TCP/IP.
• Arkitektur:
XML‐teknologin skapar nya möjligheter att utnyttja den redan
existerande infrastrukturen på webben och möjliggör en övergång från
objektbaserade distributionssystem till distributioner baserade på Web
Services som kan bli upptäckta, är tillgängliga och kan kopplas ihop
genom den publika webbteknologin.
• Mjukvaruutveckling:
Utvecklingen av mjukvaror under 1970‐ respektive 1980‐talet bestod av applikationer skapade på ett monolitiskt sätt i stora projekt för att lösa vissa specifika problem. Detta sätt att utveckla innebar ofta att man försökte ta itu med alla problem samtidigt och på grund av projektets storlek var mjukvaran ofta olämplig att förändra i efterhand, exempelvis för att lägga in en ny funktionalitet eller instruktioner för bearbetning av teknologiförändringar. Under 1990‐talet utvecklades en ny modell för mjukvaruutveckling, genom XML, som baserades på enkelhet och samverkan. Det nya sättet innebar att mjukvaran skapades med hjälp av olika byggnadsblock som kunde kombineras med varandra eller med andra byggnadsblock som redan existerade eller skulle skapas senare.
2.3.1 Fördelar med XML
• XML‐filer är läsbara för människor. Filerna är designade som text så att det blir lätt att ta del av innehållet. Till skillnad från binära datafiler.
• Utbredd spridning av industrier som stödjer XML. Flertalet verktyg och nyttoprogram tillhandahålls tillsammans med webbläsare, databaser och operativsystem för att göra det lättare och mer kostnadseffektivt för små och medelstora företag/organisationer att importera respektive exportera data i XML‐format.
• Stora relationsdatabaser är numera kapabla att läsa respektive generera XML‐data.
• En stor mängd teknologier som stödjer XML finns tillgängliga för att översätta och tranformera XML‐data för att visa webbsidor och generera rapporter. [1]
2.3.2 XML Schema (XSD)
När XML används för att utbyta data mellan klienter, partners och leverantörer är det av vikt att kunna definiera hur XML‐dokumenten borde vara
strukturerade. Det är då ett schema behövs. [1]
”Schema” är en allmän term som beskriver dataformen. I början användes termen för att beskriva databasstrukturer. Ett schema är en formell specifikation av grammatiken för ett specifikt XML‐vokabulär. Scheman kan användas vid validering av XML‐dokuments innehåll, för att fastställa om innehållet stämmer överrens med den grammatiska beskrivningen angiven i XML Schema. Ett schema tillhandahåller även en beskrivning av XML‐strukturen till andra, som möjliggör utbytet av strukturerad information mellan samverkande
applikationer och affärspartners oberoende av plattform och mellanliggande program. [1]
Det finns två typer av scheman i XML‐världen; DTD och XML Schema. DTD fokuserar i första hand på struktur och möjliggör för designern av XML‐
vokabulären att specificera lämpliga element och attribut för en uppsättning instanser av XML‐dokument. Dock har DTD begränsningar när det gäller datatyper som kan definieras. XML Schema är en nyare teknologi, antagen som officiell rekommendation av W3C i maj 2001. Den är ämnad att tillhandahålla en typ av detaljerad struktur som ofta associeras med programmeringsspråks definitioner av datatyper. En fördel med XML Schema är möjligheten att validera att XML‐datat som utbyts är i korrekt format, före vidare bearbetning.
[1]
• DTD (Document Type Definition):
‐ Definierar strukturen för ett XML‐dokument.
‐ Datatyper för olika element är begränsade till text. Detta innebär att element endast kan innehålla text. DTD kan heller inte kontrollera om texten består av numeriska eller alfabetiska tecken.
• XML Schema:
‐ Definierar strukturen för ett XML‐dokument.
‐ Flertalet fördefinierade datatyper finns tillgängliga.
‐ Det är möjligt att definiera komplexa datatyper som kan mappas ihop med applikationsspecifika datastrukturer.
‐ Möjliggör validering av XML‐data.
2.4 SOAP
Simple Object Access Protocol (SOAP) är ett XML‐baserat protokoll som gör det möjligt för klienter och leverantörer att kommunicera med varandra och utbyta XML‐data i en decentraliserad distribuerad miljö. Protokollet består av tre delar; ett omslag som definierar ramverket för ett meddelandes innehåll och hur det ska behandlas, en uppsättning regler för att definiera datatyper och en konvention för att representera Remote Procedure Calls (RPC) och dess svar.
[20]
SOAP skapades för webben, som en kombination av XML och HTTP. Den öppnade för nya möjligheter för utbyte av distribuerat data och interaktion i löst kopplade webbmiljöer. Den främsta förändringen som SOAP ledde till var möjligheten att transportera data varsomhelst över webben. [1]
Före SOAP fanns det två principiella valmöjligheter att transportera data mellan olika partners. Den första var att bygga ett vidsträckt nätverkområde som spände över en bred geografisk region och låta partners ansluta sig till det.
Detta sätt var framtaget genom Electronic Data Interchange (EDI), där meddelanden och protokoll för dataöverföring definierades medan
utformningen av nätverk lämnades fritt åt varje partner. Resultatet blev en
samling av olika nätverk som i stort sett låste in sina partners och gjorde det
svårt och dyrt att nå ut till andra EDI‐nätverk och varva in nya partners. [1]
Det andra alternativet framtogs genom Common Object Request Broker Architecture (CORBA), Remote Method Invocation (RMI) och Distributed Component Object Model (DCOM) och innebar att en infrastruktur för
distribuerande objekt som kördes över Internet byggdes. Problemet här var att varje partner fick bestämma själv om vilket protokoll som ska användas och ligga över TCP/IP för att hantera kommunikationen av interna objekt. CORBA valde Internet Inter‐ORB Protocol (IIOP), RMI valde Java Remote Method Protocol (JRMP) och DCOM valde Oject Remote Procedure Call (ORPC). På det sättet kunde behovet att använda samma underliggande nätverk reduceras.
Dock var den stora nackdelen att varje partner kunde utan några som helst problem kommunicera internt med sina egna, men partnerna kunde inte
kommunicera externt med varandra. Dessutom var det omöjligt att direkt nå ut till webben utan att använda sig av speciella kapslar som innebar att nya lager måste läggas till en redan komplex arkitektur. [1]
Det nya aternativet där SOAP används för att transportera data kombinerar XML:s dataegenskaper och HTTP:s dataöverföringsegenskaper och har ingen av nackdelarna som både EDI och strikt kopplade system för distribuerade objekt (CORBA, RMI och DCOM) hade. Med SOAP upphör beroendet mellan data och transport och nya möjligheter för utbyte av distribuerat data via löst kopplade system uppstår. [1]
Sedan dess uppkomst 1998 har SOAP använts i allt större skala av många aktörer inom mjukvarubranschen:
• Web Services ramverk använder SOAP som transportteknologi för att skicka data och XML‐RPC över distribuerade närverk.
• Microsoft intar SOAP som en del av sin .NET‐verksamhet.
• Sun använder SOAP i sitt Web Services ramverk, Sun Open Net Environment (Sun ONE).
• IBM har haft en stor roll i specifikationen av SOAP och har en mängd olika verktyg som stödjer SOAP, bland annat verktyg som möjliggör integrering av SOAP i Java.
• Olika distribuerare av CORBA Object Request Broker (ORB) stödjer SOAP i form av CORBA‐to‐SOAP bryggor. [1]
2.5 XML Web Services
XML Web Services, ofta förkortat Web Services, är en applikationstyp utan ett (grafiskt) användargränssnitt. Den anropas istället av andra applikationer som fungerar som klienter mot gränssnittet och kan använda sig av de olika
metoderna som är definierade i Web Servicen. Dataformatet som används av Web Servicen och klientapplikationen är eXtensible Markup Language (XML).
Kommunikationen sker genom att Simple Object Access Protocol (SOAP)‐
meddelanden innehållande XML‐datat skickas mellan parterna via exempelvis transportprotokollet HTTP. Detta gör det möjligt för olika program att
kommunicera med varandra på ett standardiserat sätt oberoende av programmeringsspråk eller plattform. [15]
Genom att utgå från en detaljerad beskrivning av gränssnittsstrukturen för en viss Web Service är det möjligt att skapa en klientapplikation som anropar Web Servicen. En sådan beskrivning distribueras genom ett XML‐dokument som kallas Web Service Description Language (WSDL).
Tillvägagångssättet för att utveckla Web Services kan ske med hjälp av olika metoder. Två av dessa utvecklingsmetoder är Code‐first respektive Contract‐
first och beskrivs under särskild punkt.
Web Services utgör en lösning på bred front för det industriella behovet av en flexibel och effektiv miljö för affärssamarbete. Tekniskt sett är det ett sätt att länka ihop löst kopplade system genom en teknik som inte binder dessa till ett specifikt programmeringsspråk, komponenttyp eller plattform. Praktiskt taget utgör Web Services en tydlig affärsprocess som med hjälp av stödda protokoll beskriver och exponerar sig för webbanvändare, anropas av en extern (eng.
remote) användare samt returnerar ett svar. [1]
• Beskriver: Web Services beskriver dess funktionalitet och attribut för att andra applikation ska förstå hur dessa ska användas.
• Exponerar: Genom ett register över olika Web Services som består av o White pages; innehåller grundläggande information för
tjänstedistribuering.
o Yellow pages; listar tillgängliga Web Services med hjälp av olika kategorier.
o Green pages; beskriver hur anslutningen till och användningen av en specifik webbtjänst (Web Service) går till.
• Anropas: När en webbtjänst har lokaliserats, kan en extern applikation anropa tjänsten.
• Returnerar ett svar: Ett anrop till en webbtjänst resulterar i ett svar som returneras till externa applikationen som skickade anropet.
Drivkraften bakom Web Services är önskan att möjliggöra för
affärsverksamheter att använda sig av Internet för att publicera, upptäcka och sammankoppla andra Web Services genom den globalt stödda SOAP‐tekniken.
Det faktum att Internet är det enda som är nödvändigt för att en Web Service ska levereras och fungera innebär att såväl ärvd programkod och data som objektsystem kan koppla upp sig mot Web Service‐plattformen. Dessa
möjligheter förväntas resultera i nya produkter och affärsprocesser med globalt
omfång som kan levereras över trådbaserade respektive trådlösa nätverk. Hur
dessa ska framkomma är ännu okänt. Dock indikerar utvecklingen av webben, XML och SOAP att nya teknologier är på frammarsch. [1]
Vad kvalificeras som Web Services?
Vilken mjukvarukomponent eller applikation som helst kan exponeras som en Web Service så att den kan upptäckas och användas av en annan komponent eller applikation. Detta kan röra sig om allt från en enkel filmrecension eller väderprognos till ett komplext komplett resepaket som inkluderar hotell‐, flygbokningar och restaurangbeställningar. Web Services frambringar en teknisk infrastruktur som försäkrar att tjänster, även från olika leverantörer, kommer att samverka och har fördelen att ingen avancerad kunskap krävs i hur olika tjänster passar ihop för att allt ska fungera. [1]
Möjlighet och risk
Web Services utgör en ny form för distribuering och sammankoppling av mjukvaror baserad på föreställningen om tjänster som är globalt tillgängliga över webben hellre än objekt till objekt kopplingar över begränsade nätverk.
Denna globala tillgänglighet är väldigt attraktiv ur ett finansiellt perspektiv.
Finansiellt incitament innebär nya möjligheter genom skapandet av privata handelsnätverk, ökade intäkter genom expanderande distributionskanaler samt minskade lager‐ och transaktionskostnader. [1]
Förbättrat samarbete mellan kunder, partners och leverantörer utlovas av Web Services. Möjligheter tillhandahålls för att minska tiden och kostnaden för integration jämfört med existerande lösningar för integration mellan olika affärsapplikationer och business‐to‐business (B2B) lösningar. Det finns även lösningar för att effektivisera leveransrutiner, snabbt svara på förändringar på marknaden och kundpreferenser samt förbättra kundservicen genom att låta kunder och affärspartners ha tillgång till kärnsystem. [1]
Däremot är visionen kring Web Services relativt ny och inte helt riskfri. Trots dess signifikanta potential, är det fortfarande oklart hur stor roll Web Services kommer att ha i ett större perspektiv. Det är dock förväntat att ha en avgörande roll för leveranser av enkla tjänster, men tills tekniken mognar kommer
komplexa partnerinteraktioner att fortfarande kräva ett mänskligt element för att fastslå överenskommelser. Detta kommer att ske med hjälp av Web Services protokollen UDDI och WSDL, som tillsammans med SOAP är bland
huvudkomponenterna i plattformen. [1]
UDDI
SOAP
HTTP SMTP
FTP
WSDL
Fig. 2.1 Viktiga tekniker för Web Services.
2.5.1 UDDI
Universal Description, Discovery and Integration (UDDI) är ett protokoll som används för att beskriva Web Services‐komponenter som möjliggör för
affärsverksamheter att registrera och marknadsföra sina tjänster via en webbaserad katalogtjänst. Protokollet härstammar från samarbete och överenskommelse mellan Microsoft, IBM och Ariba om en XML‐baserad
specifikation för att etablera ett register över affärsverksamheter och tjänster på Internet, med start i augusti år 2000. [1] [21]
Kärnan i UDDI består i stort sett av UDDI Business Registry som är en global, publik, webbaserad katalogtjänst som tillhandahåller affärsverksamheter ett enhetligt sätt att beskriva (registrera) sina tjänster, upptäcka varandras tjänster samt att ta del av detaljerna som beskriver uppkopplingen mot och
interaktionen med mjukvarorna som implementerar de olika tjänsterna. [1] [21]
I funktionalitetsstacken som bygger på TCP/IP, HTTP och XML, definieras ett lager av UDDI ovanför SOAP‐lagret. Där definieras en XML‐baserad
infrastruktur som gör det möjligt för mjukvaror att automatisk upptäcka tillgängliga tjänster på webben och använder SOAP‐protokollet för att anropa dessa tjänster. [1] [21]
DISCO
Microsoft har en egenutvecklad mekanism, DISCO, för att dynamiskt lokalisera Web Services för klienter. Mer specifikt så hjälper DISCO klienterna att hitta WSDL‐filerna som beskriver anropssyntaxen för Web Services. DISCO stöds inte utanför Microsoft‐miljön och har i hög grad ersatts av UDDI. [13]
2.5.2 WSDL
WSDL står för Web Services Description Language och är en XML‐baserad
standard för Web Services, utvecklad av W3C. Den definierar ett Web Service‐
gränssnitt och detaljer för implementation. Detaljerna i WSDL kan anskaffas ur UDDI‐poster som beskriver SOAP‐meddelandena som kommer att användas för en viss Web Service. [1] [20]
Ett WSDL‐dokument är uppbyggt av flera beståndsdelar, element. [22]
• Definitions, rotelementet på dokumentet definierar namnet på tjänsten och deklarerar de namnrymder som används.
• Types, definierar alla datatyper som används av tjänsten.
• Message, definierar in‐ och ut‐parametrarna för tjänsten.
• Port type, binder ihop metoderna med meddelanden deklarerade i Message‐delen. I Port type definieras alla operationer som en metod använder sig av och vilka meddelanden som används av respektive operation. En operation kan vara uppbyggd på fyra olika sätt:
o One‐Way, tjänsten tar emot ett meddelande.
o Request‐response, tjänsten tar emot ett meddelande och skickar tillbaka ett svar.
o Solicit‐response, tjänsten skickar ett meddelande och tar emot ett svar.
o Notification, tjänsten skickar ett meddelande.
• Binding, definierar meddelandeformat och protokolldetaljer för operationer och meddelanden definierade av en viss porttyp.
• Service, definierar namnet på tjänsten, var den finns och grupperar ihop tillhörande portar.
2.5.3 Code‐first .NET Web Services
När Code‐first används som utvecklingsmetod skapas all kod inklusive all funktionalitet för den tänka Web Servicen i första steget. Beskrivningen (WSDL‐
fien) av och XML‐schemat för tjänsten skapas eller genereras i efterhand. [18]
1. Börja med att skapa en ASMX‐fil med all kod som definierar klasser, metoder, variabler och operationer för den tänka Web Servicen.
2. Generera ett XML‐schema och WSDL‐fil utifrån den skapade ASMX ‐ filen.
3. Iterera/upprepa.
2.5.4 Contract‐first .NET Web Services
I första steget för denna utvecklingsmetod skapas schemastrukturen (XML schema) för den tänka webbtjänsten. Schemat fungerar här som ett kontrakt, varav namnet, som alla parter inblandade i utvecklingen av tjänsten ska komma överrens om före fortsatt utveckling. [18]
1. Börja med att definiera Web Servicens struktur och XML‐meddelanden
genom ett XML‐schema.
2. Defineira operationerna genom en WSDL‐fil som har XML‐schemat som referens.
3. Generera en ASMX‐fil innehållande koden för Web Servicens struktur/skal utifrån WSDL‐filen som skapats i föregående steg.
4. Implementera operationerna, det vill säga all funktionalitet, i ASMX‐
filen.
5. Iterera/upprepa
2.6 Microsoft BizTalk Server 2006
BizTalk Server 2006 beskrivs nedan utifrån rapporten Understanding BizTalk Server 2006. [17]
2.6.1 Vad är BizTalk?
BizTalk är en meddelandebaserad applikationskomponent som möjliggör kommunikationen genom att koppla ihop diverse program och sedan bygga och modifiera affärsprocesser utifrån detta. I BizTalk kan informationsarbetare mäta pågående processer, integrera med partners och utföra affärsorienterade uppgifter.
BizTalks senaste version, BizTalk Server 2006, är byggd på version 2.0 av .NETs ramverk och utveckling sker i Visual Studio 2005. För lagring använder BizTalk Server 2006 antigen SQL Server 2005 eller SQL Server 2000.
2.6.2 Vilka delar består BizTalk av?
De två viktigaste delarna i BizTalk är messaging‐komponenten och
orchestrations. Messaging‐komponenten möjliggör kommunikation med en rad mjukvaror. Genom olika typer av anpassningsbara adaptrar för
kommunikation kan BizTalk stödja flera varierande protokoll och dataformat, inklusive Web Services. Orchestrations ger stöd för att bygga och köra grafiskt definierade affärsprocesser. Implementerade orchestrations kan köra hela eller delar av affärsprocesserna.
Flera andra delar ingår:
‐ Business Rules Engine, tillåter evaluering av en komplex mängd av regler.
‐ Health and Activity Tracking, ett verktyg för hälsokontroll och
aktivitetsspårning där utvecklare och administratörer kan bevaka och underhålla huvudkomponenten, BizTalk Engine, och de processer den kör.
‐ Enterprise Single Sign‐on, ger möjlighet att matcha autentiserings‐
information mellan Windows‐system och andra system.
Ytterligare delar för affärsorienterade behov:
‐ Business Acivity Monitoring, tillåter informationsarbetare att mäta en
pågående affärsprocesser. Information beskrivs i affärstermer och inte i
tekniska termer och det som visas kan kontrolleras direkt av dem som arbetar med affärsverksamhet.
‐ Busniess Activity Service, tillåter informationsarbetare att konfigurera och underhålla integrationen med handelspartners.
2.6.3 Hur används och fungerar BizTalk?
Största delen av moderna affärsprocesser är åtminstone delvis beroende av mjukvaror. En del förlitar sig på en applikation, en del förlitar sig många applikationer utspridda på diverse system. Dessa system har oftast tillverkats vid olika tidpunkter, på olika plattformar och med olika teknologier. Givet detta kräver affärsprocesserna att diverse system kan sammankopplas. Att integrera existerande applikationer, inom ett företag eller över flera
organisationer till automatiserade affärsprocesser är det fundamentala i BizTalk.
Receive Adapter
Send Adapter
MessageBox Orchestrations
Inbound Outbound
Send Pipeline
Message Path Business Rules
Engine
Incoming Message
<XML Message>
<XML Message>
<XML Message>
<XML Message>
Outgoing Message Receive
Pipeline
Subscriptions Subscriptions
Fig. 2.2 Ett meddelandes väg i BizTalk Server 2006
Ett meddelande tas emot av en Receive Adapter. Olika adaptrar erbjuder olika kommunikationsmekanismer så meddelandet kan förvärvas genom åtkomst till en Web Service, en fil eller på annat sätt. Sedan bearbetas meddelandet genom en Receive Pipeline. Den kan innehålla varierande komponenter som bland annat kan konvertera ursprungliga meddelandet till ett XML‐format, validera ett meddelandes digitala signatur. Meddelandet levereras sedan till en MessageBox som är implementerad på en SQL‐server.
Logiken som styr affärsprocessen är implementerad som en eller flera
orchesrations som består av exekverbar kod. Orchestrations byggs inte genom
att skriva kod, istället är det en affärsanalytiker eller utvecklare som använder
ett lämpligt verktyg för att grafisk organisera en grupp av former som beskriver
villkor, loopar och andra beteenden. Orchestrations har valet att använda
Busniess Rules Engine som är ett enklare och mer lättmodifierat sätt att uttrycka en mängd komplexa regler i en affärsprocess.
Varje orchestration gör meddelandeprenumerationer, subscriptions, för att indikera vilken typ av meddelande den vill ta emot. När ett lämpligt meddelande anländer till en MessageBox, avsänds meddelandet till mål‐
orchestration som sedan utför det som affärsprocessen kräver. Resultatet av processen är ofta ett annat meddelande, producerat av orchestration, som sparas i en MessageBox. Meddelandet i sin tur bearbetas av en Send Pipeline, som konverterar från det interna BizTalk XML‐formatet till formatet som mottagarsidan kräver. Meddelandet sänds sedan ut via en Send Adapter, som använder en lämplig mekanism för att kommunicera med applikationen för meddelandets destination.
Roller för att utveckla affärsprocesser
Personer inom en affärsverksamhet utnyttjar olika typer av funktionalitet i BizTalk Server 2006. Affärsanalytiker kan definiera regler och beteenden som bygger upp affärsprocessen och dess flöde, samt vilken information som sänds till varje applikation och hur den matchas till en annan struktur. Utvecklaren implementerar en BizTalk‐applikation, vilket innebär att definiera XML‐
scheman, specificera detaljerna i matchningen till en annan struktur och konstruera nödvändiga orchestations för att implementera affärsprocessen.
Administratören konfigurerar kommunikationen mellan parter och placerar ut och startar BizTalk‐applikationen.
Sammankoppla system
För att täcka en stor del av de kommunikationsstilar som existerar måste BizTalk stödja ett mängd varierande protokoll och meddelandeformat. Alla format som BizTalk hanterar konverteras först till ett XML‐dokument eftersom BizTalk endast arbetar med detta format internt.
Skicka och ta emot meddelanden, Adaptrar
För att hantera variationen i mjukvara använder BizTalk olika adaptrar. En adapter är en implementation av en kommunikationsmekanism, med ett så kallat protokoll. En utvecklare kan sedan välja vilken typ av adapter som föredras att använda i en viss situation. Adapter Framework tillhandahåller ett standardiserat sätt för att använda och bygga egna adaptrar.
Adaptrar som ingår i BizTalk Server 2006:
‐ Web Service adapter, skickar och tar emot SOAP‐meddelanden över HTTP. Viktigt för att interagera i en tjänsteorienterad miljö (SOA).
‐ Filadapter, läser och skriver från Windows filsystem.
‐ HTTP adapter, skickar och tar emot information över HTTP.
‐ MSMQ adapter, skickar och tar emot meddelanden genom att använda Microsoft Message Queuing.
‐ MSMQT adapter, skickar och tar emot meddelanden genom BizTalk Message Queuing.
‐ WebSphere MQ Adapter, skickar och tar emot meddelanden genom IBM:s WebSphere MQ.
‐ SMTP adapter, skickar e‐postmeddelanden via SMTP.
‐ POP3 Adapter, tar emot e‐postmeddelanden via POP3.
‐ Windows sharepoint Sevices (WSS) Adapter, åtkomst och publicering av dokument lagrade i SharePoints dokumentbibliotek.
‐ SQL adapter, läser och skriver information till en SQL‐server databas.
Andra adaptrar för vanligtvis förekommande affärsmjukvaror finns att tillgå från Microsoft och deras partners.
Behandla meddelanden, Pipelines
Eftersom BizTalk arbetar med XML‐dokument internt måste den kunna
konverterar inkommande och utgående format samt autentisera sändaren av ett meddelande. Pipelines hanterar detta och är indelade i block som innehåller en eller flera .NET eller Component Object Model (COM) komponenter.
Decode Disassemble Validate Resolve
Party
MIME/SMIME Decoder
BTF Disassembler
Flat File Disassembler XML Disassembler
XML Validator
Party Resolution
Receive Pipeline
Stages
Components
Fig. 2.3 Receive Pipeline, block och standardkomponenter
Blocken och standardkomponenterna i Recieve Pipeline:
• Decode, en standardkomponent. MIME/SMIME‐dekoder, hanterar MIME‐ eller säker MIME (S/MIME) ‐format och konverterar dessa till XML. Den kan också dekryptera S/MIME‐meddelanden och verifiera dess digitala signatur.
• Disassemble, tre standardkomponenter finns tillgängliga:
o Flat File Disassembler, konverterar en strukturerad textfil till XML‐
dokument.
o XML Disassembler, tolkar och läser in inkommande meddelanden skrivna i XML.
o BTF Disassembler, accepterar inkommande meddelanden från en meddelandemekanism fördefinierad i BizTalk Framework (BTF).
• Validate, validerar ett XML‐dokument skapat av Disassemble mot ett schema eller en grupp av scheman.
• Resolve Party, försöker identifiera sändaren av ett meddelande.
Assemble Encode
(Custom components only)
BTF Assembler Flat File Assembler
XML Assembler
MIME/SMIME Encoder
Send Pipeline
Stages
Components Pre-assemble
Fig. 2.4 Send Pipeline, block och standardkomponenter
Blocken och standardkomponenterna i Send Pipeline:
• Pre‐assemble, ingen standardkomponent finns tillgänglig men egna ändamålsenliga komponenter kan infogas vid behov.
• Assemble, tre standardkomponenter finns tillgängliga:
o Flat File Assembler, konverterar ett XML‐meddelande till en positionell fil eller genom att använda ett specifikt tecken för att separera värdena i filen.
o XML Assembler, gör det möjligt att lägga till ett omslag till XML‐
meddelandet.
o BTF Assembler, paketerar meddelandet för pålitlig överföring.
• Encode, en komponent som paketerar utgående meddelanden i MIME‐
eller S/MIME‐format. Med S/MIME kan meddelandet dessutom krypteras och/eller digitalt signeras.
En utvecklare kan också implementera egendefinierade Pipelines genom att använda Pipeline Designer, ett verktyg som körs i Visual Studio 2005 och tillhandahåller ett grafiskt gränssnitt för att bygga en pipelinekomponent.
Meddelandeprenumerationer, Subsriptions
Ett meddelande som färdats genom en adapter och Receive Pipline måste veta
sin fortsätta väg. Måldestinationen är oftast en orchestration men det är möjligt
att ett meddelande går direkt till en Send Pipline, i de fall BizTalk används som ett rent meddelandesystem. Måldestinationen bestäms via Subscriptions. När ett meddelande färdas genom en Receive Pipline konstrueras ett meddelande‐
sammanhang med varierande egenskaper. En orchestration eller en Send Pipline kan prenumerera (eng. subscribe) på ett meddelande, baserat på meddelandesammanhangets egenskaper.
Definera Affärsprocesser
För att definiera logiken i en affärsprocess används orchestrations och för att bygga och utvärdera grupper av affärsregler tillhandhålls Business Rules Engine.
Logiken för automatiserade affärsprocesser kan implementeras direkt i ett programmeringsspråk som C# eller Visual Basic. Men istället för att skriva kod tillhandahåller BizTalk orchetrations, där affärsprocesser skapas grafiskt. Att arbeta på detta sätt kan medföra att en affärsprocess kan skapas snabbare, bli enklare att förstå, förklara, ändra och mäta. För att utveckla orchestrations använder man sig av tre primära verktyg:
• Biztalk Editor låter utvecklare skapa XML‐scheman genom att definiera elementen i en grafisk hierarki. Existerande scheman kan också
importeras eller nås via en Web Service.
• Biztalk Mapper. Vanligtvis tas en typ av strukturerade dokument emot och en annan typ av struktur på dokumentet ska skickas. För att definiera dessa transformationer i BizTalk skapas en matchning. Detta genom att skapa grafiska relationer mellan scheman. Matchningen är implementerad i XSLT. Mer komplexa transformationer kan skapas genom användning av functoids. Dessa består av exekverbar kod som arbetar på ett eller flera element. I BizTalk finns ett antal inbyggda functoids som bland annat hanterar konverteringar, logik och beräkningar.
• Orchestartion Designer används för att skapa en grafisk beskrivning för att definiera en affärsprocess behov genom att koppla samman en serie av grafiska former på ett logiskt sätt. Formerna som används är:
o Receive shape, tar emot ett meddelande.
o Send shape, skickar ett meddelande.
o Port shape, definierar hur en meddelande skickas. Varje instans av en port är kopplad antigen en Send eller Receive Shape.
o Decide shape, representerar en ”if‐then‐else”‐sats vilket medför att en orchestration kan utföra olika arbetsuppgifter utifrån boolska villkor.
o Loop shape, används för att återupprepa en handling.
o Construct Message shape, används för att bygga ett meddelande.
o Tranformation shape, används för att transformera strukturen av en dokumenttyp till en annan genom att involvera matchning
definierad med BizTalk Mapper.
o Parallel Action shape, används för att specificera att ett flertal operationer sker parallellt istället för i en sekvens.
o Scope shape, används för att gruppera operationer till transaktioner och definiera felhantering.
o Message Assignment shape, används för att tilldela värden till variabler i en orchestration.
Web Services och orchestration
För att få åtkomst till Web Services i en orchestration används Add Web Reference i Visual Studio 2005 tillsammans med Web Service‐adaptern för att direkt involvera Web Service‐operationer. Dessutom kan Biztalk Server 2006 publicera en Web Service genom att generera en ASP.NET. På så sätt kan en Web Service exponera en eller flera orchestration‐operationer som SOAP‐
anropbara Web Services.
Busniess Rules Engine
Busniess Rules Engine används för att definiera och ändra affärsregler på ett enklare sätt. En utvecklare börjar oftast med Busniess Rule Composer för att beskriva affärsregler genom att definiera ett ordförråd för en viss regel. I Busniess Rules Engine skapas sedan affärspolicyn baserade på definierat ordförråd. Varje policy innehåller en eller flera affärsregler. En regel använder ett ord tillsammans med logiska operatorer för att definiera hur en
affärsprocess arbetar. En affärsregel kan definiera hur värden i ett mottaget XML‐dokument ska påverka värdena i ett skapat XML‐dokument som ska skickas eller hur mottagna värden ska påverka värden som skrivs till en databas eller andra definitioner.
Skötsel och övervakning
Varje applikation byggd i BizTalk Server 2006 kan behöva övervakning.
Installation av BizTalk är rättfram och kan installeras på en maskin eller genom att skapa skalbara installationer. För att sköta applikationer används BizTalk Administration console där de viktigaste delarna är:
• Deploy BizTalk applications, förpackar ihop alla delar i en lösning och sprider det på en eller flera servrar med mera.
• Configure BizTalk applications, konfigurerar hur BizTalk kommunicerar med en specifik applikation.
• Monitor BizTalk applications, övervakar driften av BizTalk‐applikationer.
