Software Architecture Document

Transkript

1 Software Architecture Document Tjänsteplattformen version 1.1 Sidan 1(48)

2 Revisioner Version Beskrivning Ändrad av PA1 Upprättande av dokumentet Mats Ekhammar PA2 Omstrukturering efter möte med Jan V Mats Ekhammar PA3 Omstrukturering efter möte med Johan E Mats Ekhammar PA4 Genomgång Jan Västernäs PA5 Uppdatering efter genomgång av Johan Eltes Mats Ekhammar A Godkänd för acceptanstest hos SVR Johan Eltes Sidan 2(48)

3 Innehållsförteckning 1 Introduktion Syfte Översikt Nyckeltermer Referenser 6 2 Funktionell vy Motiv för tjänsteplattformens komponenter Lösningsstrategier Tjänsteplattformens realisering Virtualiseringsplattform Tjänstekatalog 11 3 Icke-funktionella egenskaper Prestanda Skalbarhet Säkerhet Utökningsbarhet Flexibilitet Monitorering Tillgänglighet Interoperabilitet Öppenhet 14 4 Arkitekturella principer och avgränsningar Säkerhet Flexibilitet och konfigurerbarhet Felhantering 15 5 Process vy Grundfunktionalitet Integrationsutvecklare Driftsättare Administratör av TK Support tjänstekonsumenter Förvaltare 20 6 Logisk vy Komponentvy Tjänsteinteraktioner 24 7 Design och implementerings vy Virtualiseringsplattformen Monitorering Tjänstekatalogen Gemensamt hjälpbibliotek Gemensamt schemabibliotek 34 Sidan 3(48)

4 7.6 Referensapplikation Meddelande strukturer Utveckling Exceptions Loggning Enhetstester Lasttester 37 8 Deployment vy Målmiljö Övergripande Portabla byggen Paketering virtuell tjänst Plattformsdomäner Tjänsteplattformens distribution Installation Konfiguration 43 9 Säkerhet Autentisering Auktorisation Mutual Authentication med SSL Certifikat Truststore Nätverk Tillgång till Tjänstekatalogen via webben Tillgång till Tjänstekatalogens databas 48 Sidan 4(48)

5 1 Introduktion Detta dokument beskriver arkitekturen av Tjänsteplattformen (TP). För att se TP i ett större sammanhang hänvisas läsaren till de dokument som anges under kapitlet Referenser. Målgruppen för dokumentet är: Driftsättare av TP och virtuella tjänster Support personal av TP Integrationsutvecklare av virtuella tjänster Administratörer av tjänstekatalogen Produktägare av TP Förvaltare av TP 1.1 Syfte Dokumentet visar systemets egenskaper från ett flertal olika arkitekturella vyer för att belysa olika aspekter av systemet. Det beskriver signifikanta arkitekturella beslut som tagits vid implementeringen av systemet. 1.2 Översikt Kapitel 1: Denna introduktion. Kapitel 2: Här beskrivs hur produkten tillgodoser de funktionella kraven. Kapitel 3: Beskriver hur TP tillgodoser de icke-funktionella kraven. Kapitel 4: Arkitekturella principer och ramar som TP tagit hänsyn till. Kapitel 5: Beskriver produkten utgående från produktens intressenter. Kapitel 6: Här visas produktens logiska arkitektur. Kapitel 7: Detta kapitel beskriver produktens design och realisering. Kapitel 8: Beskrivning av hur TP drift sätts. Kapitel 9: Kapitel som beskriver säkerheten i TP. 1.3 Nyckeltermer Begrepp SAD CA BIF Beskrivning Software Architecture Document Certificate Authority, den myndighet som utfärdar ett certifikat. Bastjänster för Informationsförsörjning Sidan 5(48)

6 RIV TP TK VP Regelverk för Interoperabilitet inom Vård och omsorg Tjänsteplattformen Tjänstekatalogen (ena komponenten av TP) Virtualiseringsplattfomen (andra komponenten av TP) 1.4 Referenser Följande dokument ger en djupare beskrivning av de områden där TP verkar. Id Titel Version Senast ändrad 1 Nationell IT-arkitektur för vård och omsorg - VIT-boken PA Anvisning till VIT-boken VIT-bokens tekniska arkitektur (T-boken) Rev A RIV tekniska anvisningar Slutrapport Tjänsteplattform Proof-of-concept Rev A HSA Organisationsträd objekt och attribut RIV Informationsspecifikation HSA Struktur och innehåll Anvisning Tjänsteplattformen - Driftsättning av Virtualiseringsplattformen, Anvisning Tjänsteplattformen - Paketering av virtuell tjänst 8 Anvisning Tjänsteplattformen Driftsättning av Tjänstekatalogen, Anvisning Tjänsteplattformen - Administration av Tjänstekatalogen B B Sidan 6(48)

7 2 Funktionell vy T-boken [2] beskriver de övergripande kraven på den tekniska arkitekturen. En delmängd av dessa krav omsätter T-boken i en konceptuell arkitektur uppbyggd av komponenter som tillsammans benämns T- bokens Tjänsteplattform. 2.1 Motiv för tjänsteplattformens komponenter Här sammanfattas motiven till tjänsteplattformens komponenter. Komponenternas namn och funktionella ansvarsfördelning är baserade på resultatet av det proof-of-concept som genomfördes för T-bokens referensarkitektur [4] Krav - Administration av systemförändringar ska vara minimal Samverkan över vårdgivargränser förutsätter samverkan mellan vårdgivares lokala system, eller säkerhetsmässigt komplett anslutning till nationella tillämpningar. Arkitekturen ska minimera eventuella dominoeffekter av förändringar i systemen hos en samverkande part och i nationella tjänster. Arkitekturen ska i detta avseende ta hänsyn till att det för enskilda IT-tjänster kan skapas grupper av vårdgivare som delar infrastruktur så väl som IT-lösningar och att dessa grupper kan förändras över tiden Krav - Anslutningspunkter Arkitekturen ska minska dominoeffekten av systemförändringar, genom att erbjuda en nationell lösning för lös koppling (jfr SOA/W3C intermediary ). På så sätt kan förändringar i anslutningspunkter hos en vårdgivare isoleras från övriga parter i arkitekturen Krav - Administration av organisationsförändringar ska vara minimal Arkitekturen ska minimera effekten av omorganisationer inom vård och omsorg, som ett led i att maximera tillgängligheten hos nationellt realiserade tjänster. En rimlig målsättning är att isolera behovet av förändringar till de organisationer som deltar i omorganisationen. Organisationsförändring kan avse sammanslagningar och andra omstruktureringar vårdgivare emellan. Det kan också avse organisationers tillträde och utträde i/ur nationell samverkan t.ex. sammanhållen patientjournal Krav Meddelande format Följsamhet mot nationellt fastställda tjänstekontrakt är en viktig förutsättning för att undvika dominoeffekt av förändringar som annars riskeras. De nationella RIV-baserade formaten ska i sina xml-scheman införliva konstruktioner för utökningsbarhet. Utökning genom dessa konstruktioner ska kunna ske utan påverkan på konsumenter eller producenter som förlitar sig på grundformatet., så länge inte bruten bakåtkompatibilitet uttryckligen angivits enligt överenskommen standard. Sidan 7(48)

8 2.2 Lösningsstrategier Nedan redovisas hur tjänsteplattformens komponenter bidrar till med lösningar på ovanstående krav Virtualiseringsplattform Komponenten syftar till att tillmötesgå kraven från 2.1.1, och Genom att skapa en virtuell tjänst för varje nationellt tjänstekontrakt, kan denna installeras i en virtualiseringsplattform Med virtuell avses här en tjänst som uppträder som ställföreträdare för alla förekomster av verkliga tjänster som realiserar tjänstekontraktet. På så vis skapas en stabil (fast över tiden) tjänsteadress för varje nationellt tjänstekontrakt. Tjänstekonsumenter blir därmed oberoende av hur vårdens IT-stöd för stunden är organiserat och hur det förändras över tiden. Detta förutsätter att tjänsteproducenter i varje meddelande specificerar den organisation med vilken de avser samverka, på ett sätt som är systematiserat för den virtuella tjänster. Den virtuella tjänsten kan då genom uppslag av vägvals information, dynamiskt avgöra vilken konkret tjänsteproducent som är ansvarig för att erbjuda efterfrågad funktionalitet (uttryckt av tjänstekontraktet) för efterfrågad samverkanspart (uttryckt med partens HSA-id). En virtuell tjänst paketeras för en specifik profil av RIV Tekniska Anvisningar 2.0 eller högre. Genom att virtualiseringsplattformen genom tjänstekatalogen har tillgång till information om varje tjänsteproducents tillämpade Riv TA-profil, kan bryggning mellan av konsumenten tillämpad profil och av respektive producents tillämpade profil göras Tjänstekatalog Tjänstekatalogen är master för den information som virtualiseringsplattformen förlitar sig på. Tjänstekatalogens informationsmodell motsvarar T-bokens [2] Vägvalsmodell. Det förutsätts finnas en master per samverkansdomän [2]. Informationmodellen skapar förutsättningar för herla tjänsteplattformens funktionalitet och kan därmed sägas vara kärnan i hur kraven tillmötesgås. Tjänstekatalogen är inte bunden till någon specifik realisering av en virtualiseringsplattform. Dess kontrakt med virtuella tjänster är definierade som portabla web services. Sidan 8(48)

9 LogiskAddressat och Tjänstekontrakt representerar de begrepp tjänstekonsumenten använder för att uttrycka en logisk adress, som sedan av virtuell tjänst omvandlas till en konkret adress. Det sker med hjälp av Anropsbehörighet, som knyter en specifik tjänsteproducent till en informationsägare (Logisk Adressat) och ett tjänstekontrakt. 2.3 Tjänsteplattformens realisering De logiska komponenterna har omsatts i plattforms komponenter som sammantaget benämns Tjänsteplattformen. Dessa komponenter är Virtualiseringsplattform och Tjänstekatalog. Virtualiseringsplattformen utgör plattform för effektiv realisering av (nationella) virtuella tjänster. Tjänstekatalogen är datakälla för den information som virtuella tjänster behöver för att dirigera meddelanden mellan tjänstekonsumenter och tjänsteproducenter. Virtuell tjänst En virtuell tjänst erbjuder en anslutningspunkt per tjänstekontrakt som standardiserats genom RIVmetoden. I praktiken finns det ofta många tjänsteproducenter (regionala, landstingsspecifika eller gemensamma för ett antal vårdgivare) för ett standardiserat tjänstekontrakt. Virtuella tjänster döljer detta förhållande för tjänstekonsumenter i syfte att öppna upp för kontinuerlig konsolidering mot nationella tjänsteproducenter. [2]. Tjänsteplattformen virtualiserar nationella tjänstekontrakt genom att exponera en anslutningspunkt för tjänstekontraktet. Tjänsteplattformen ansvarar därefter för adressering, behörighetskontroll och Sidan 9(48)

10 dirigering till den verkliga tjänst som logiskt adresserats av tjänstekonsumenten. Tjänsteplattformen består av 2 huvudkomponenter: en Virtualiseringsplattform och en Tjänstekatalog. 2.4 Virtualiseringsplattform Virtualiseringsplattformen är en plattform för drift och övervakning av virtuella tjänster. En virtuell tjänst exponerar en fast anslutningspunkt för ett tjänstekontrakt för en viss version av RIV Tekniska Anvisningar. En virtuell tjänst har följande huvuduppgifter: Att erbjuda en nationell anslutningspunkt för ett nationellt tjänstekontrakt i syfte att skapa utrymme för en gradvis konsolidering av bakomliggande tjänsteproducenter. Nyckeln är här att skydda tjänstekonsumenter från strukurförändringar i regionernas IT-stöd. Det sker genom att tjänsteproducenter i meddelandekuvertet bifogar en logisk adress (verksamhetsadress) istället för att adressera specifika tjänsteproducenter. Den virtuella tjänsten använder information från tjänstekatalogen för att dirigera meddelandet till rätt mottagare. Här sker samtidigt en kontroll av teknisk anropsbehörighet d.v.s. att tjänstekonsumenten har ingått avtal om att anropa den tjänsteproducent som ansvarar för att realisera tjänstekontraktet för adresserad verksamhet. Att skapa utrymme för kontinuerlig utveckling av kommunikationsstandarder inom vården. Det sker genom genom att tjänsteproducenter och tjänstekonsumenter kan ansluta mot nationella tjänstekontrakt för aktuell version av RIV tekniska anvisningar. Genom att det finns en virtuell tjänst per tjänstekontrakt och version av RIV tekniska anvisningar, kan konsumenter ansluta mot den version som är aktuell utan att behöva hantera tjänsteproducenternas olika versioner av tekniska standards. Vidare kan nya Sidan 10(48)

11 tjänsteproducenter anslutas utan att behöva ta hänsyn till befintliga tjänstekonsumenters nivå m.a.p. RIV Tekniska Anvisningar. Det möjliggörs genom att virtuella tjänster transformererar mellan olika versioner av RIV Tekniska Anvisningar. Att erbjuda statistik över olika tjänsteproducenters svarstider i syfte att möjliggöra felsökning och monitorering av SLA. Virtualiseringsplattformen läser upp adresserings- och behörighetsinformation från Tjänstekatalogen till sin interna cache. Virtualiseringsplattformen läser av tjänstekonsumentens HSAid från klientcertifikatet och logiska adressatens HSAid från meddelandekuvertet (RIVheader). Version av RIV Tekniska Anvisningar samt vilket tjänstekontrakt det gäller befästs genom vilken virtuell tjänst som anropats. Med dessa informationsmängder (konsumentens HSAid, HSAid för logisk adressat, av tjänstekonsumenten tillämpad RIV TA-version och tillämpat tjäntekontrakt, kan virtualiseringsplattformen konsultera informationen som hämtats från tjänstekatalogen och därigenom fastställa teknisk adress till tjänsteproducenten, vilken RIV TA-version tjänsteproducenten stödjer samt att tjänstekonsumenten är behörig att anropa fastställd tjänsteproducent. Meddelande kan därefter vidarebefordras till tjänsteproducenten. 2.5 Tjänstekatalog Denna komponent tillhandahåller vägvals- och behörighetsinformation till virtualiseringsplattformen. Informationen utgörs dels av adresser till olika tjänsteproducenter och dels av behörigheter för tjänstekonsumenter till olika logiska adressater (verksamhetsadresser). Till Tjänstekatalogen finns en administrationstjänst för underhåll av dess datastruktur. T-bokens referensarkitektur pekar ut tjänsteplattfomen som en obligatorisk komponent i den nationella samverkansdomänen. Den kräver också möjlighet till uppbyggnad av federerade tjänsteplattformar i syfte att stödja lokala behov liknande dem som identifierats för den nationella domänen. För varje samverkansdomän där där t-bokens samverkansarkitektur ska tillämpas (dvs referensarkitekturen ska tillämpas) drift sätts en tjänstekatalog och en eller flera förekomster av virtualiseringsplattformen. Nedanstående bild visar hur en tjänstekonsument når en Tjänsteproducent genom federerade tjänsteplattformar. Sidan 11(48)

12 Sidan 12(48)

13 3 Icke-funktionella egenskaper 3.1 Prestanda Införandet av en virtuell tjänst i samverkan mellan tjänstekonsument och tjänsteproducent beräknas tillföra mindre än 40 millisekunder, i förhållande till ett anrop utan mellanhand. 3.2 Skalbarhet Virtualiseringsplattformen stödjer gängse modeller för lastbalansering, så som klustring. Virtualiseringsplattformen skalas på samma sätt som vanliga web-applikationer. 3.3 Säkerhet All kommunikation säkras enligt RIV Tekniska Anvisningar Basic Profile 2.0 (https med ömsesidig autentisering). Detta innebär att båda parter skall presentera giltiga certifikat vid upprättandet av en säker förbindelse (sk SSL-handshake). Se vidare kapitel 10 om säkerhet. 3.4 Utökningsbarhet TP skall enkelt kunna utökas med ny funktionalitet. Detta kan t.ex. vara att klara av framtida konverteringar mellan olika RIV-TA-profiler. 3.5 Flexibilitet TP kan driftsättas på alla plattformar där Mule ESB erbjuder installationsstöd. Det täcker alla vanligt förekommande Linux-, Unix- och Windowsversioner. 3.6 Monitorering Virtualiseringsplattformen har stöd för teknisk monitorering av Mule ESB. Den har också riktat stöd för monitorering av svarstider hos tjänsteproducenter. TP loggar på logformat lämpliga för övervakning av gängse övervakningsverktyg. 3.7 Tillgänglighet Virtuella tjänster är tillståndslösa mellan anrop, vilket gör att s.k. fail-over inte behöver införas för att uppnå hög tillgänglighet. Hög tillgänglighet bedöms kunna uppnås genom klustring. 3.8 Interoperabilitet Virtualiseringsplattformen har inga egna protokoll, utan använder samma protokoll som föreskrivs av vården för samverkan mellan tjänster. För version 1.0 innebär det RIV Tekniska Anvisningar Basic profile 2.0. Sidan 13(48)

14 3.9 Öppenhet TP levereras som öppen källkod under licensen LGPL. Sidan 14(48)

15 4 Arkitekturella principer och avgränsningar De arkitekturella principerna är härledda från de styrande principerna om samverkan mellan olika domäner enligt T-boken. Tjänsteplattformen medger samverkan i en tjänstebaserad arkitektur enligt beskrivningen i T-boken. Detta åstadkoms via klart definierade och exponerade tjänster i TP. 4.1 Säkerhet TP nyttjar HCC funktionscertifikat för att åstadkomma transportsäkerhet mellan tjänster via https. En tjänstekonsuments certifikat (del av subject) används dessutom som identifikation av tjänstekonsumenten i virtuella tjänster (HSA-Id), i syfte att verifiera anropsbehörighet till härledd tjänsteproducent. 4.2 Flexibilitet och konfigurerbarhet - All information som styr samverkan mellan tjänster administreras i en web-applikation och lagras i en relationsdatabas. - Konfiguration tjänsteplattformens komponenter sker genom redigering av en extern property fil (extern i relation till release-processen för komponenterna). - Virtualiseringsplattformen kan drift sättas redundant i syfte att undvika s.k. single-point-of-failure. - Tjänsteplattformen kan driftsättas i en federerad arkitektur som länkar samman meddelande trafik mellan olika samverkansdomäner. - Nya virtuella tjänster definieras via konfiguration utan behov av programutveckling. 4.3 Felhantering - Alla former av fel kan spåras i efterhand då dessa loggas persistent. Lognivån är även konfigurerbar för att kunna spara extra mycket spårningsinformation. - Virtualiseringsplattformen bidrar till felsökning genom att svarstider mot bakomliggande tjänsteproducenter visas. - De fel som en tjänstekonsument utsätts för innehåller tydlig information om felorsaken. Sidan 15(48)

16 5 Process vy I detta avsnitt beskrivs produkten och dess handhavande översiktligt med utgångspunkt i dess intressenter. 5.1 Grundfunktionalitet Virtualisering med vägval Produktägarens huvudsakliga syfte med att etablera tjänsteplattformen är att etablera strukturer för lös koppling i enlighet med t-bokens referensarkitektur. Detta är den grundläggande funktionaliteten som virtualiseringsplattformen ger. Bilden nedan visar hur ett anrop från en tjänstekonsument vidarebefordras till en tjänsteproducent genom TP Upprättning av säker förbindelse Processen för hur en säker förbindelse upprättas mellan tjänster beskrivs separat i kapitel Hantering RIV-TA-profiler Denna version har inget stöd för konvertering mellan RIV-TA-profiler, eftersom det bara finns en Sidan 16(48)

17 profil att ta hänsyn till. Däremot är implementationen förberedd på att hantera denna typ av konvertering. Alla Logiska Adresser som matchar given producent(logisk Adressat), Tjänstekontrakt och tidpunkt hämtas ut från Tjänstekatalogen. Det kan då finnas flera träffar med olika RIV-TA-profiler. I version 1.0 väljs den som matchande RIV-TA-profil och ett fel skapas om den saknas. 5.2 Integrationsutvecklare Utvecklare som skall paketera nya tjänstekontrakt behöver dels förstå tjänsteplattformen på en övergripande nivå samt ha tillgång till enkla instruktioner för hur en paketering görs Bygga upp förståelse för virtualiseringsplattformen Det finns en referensapplikation som visar Hur en virtuell tjänst konfigureras Hur man kan skriva en tjänsteproducent och tjänstekonsument i java. Referensapplikationens 3 projekt med dess leverabler illustreras i bilden nedan. Referensapplikationen kan provköras genom att följa beskrivning i VP Anvisningar användare[7] Paketera virtuell tjänst När man paketerar en virtuell tjänst behöver man tillgång till de filer som specificerar Sidan 17(48)

18 tjänstekontraktet (wsdl fil och schema file(er)). Därefter skrivs en konfigurationsfil för tjänsten (se kapitel för exempel). Dessa 3 filer paketeras i en packad fil av typen jar. Processen för att paketera en virtuell tjänst finns beskriven i VP Anvisningar användare[7]. 5.3 Driftsättare Här vill man kunna drift sätta TP genom att följa en enkel instruktion, både VP och TK. Man vill också kunna drift sätta enskilda paketerade virtuella tjänster till en drift satt VP genom att följa en instruktion Driftsätta VP VP baseras på en ESB som heter Mule. Första steget i en driftsättning är att installera Mule samt en Java runtime miljö på sitt målsystem (Windows eller UNIX). Mule kan köras som en service på windows eller en daemon på UNIX. Därefter packas distribution upp (zip fil) och filerna flyttas in till vår installerade Mule installation. Efter detta behöver man göra en grundkonfigurering i en medföljande property-fil. Här anger man t.ex. URL:n till tjänstekatalogens SökVägvals tjänst. Sista steget i drift sättningen är att verifiera installationen genom att installera medföljande referensapplikation. Detta kräver då att tjänstekatalogen också är installerad. Se VP Anvisningar användare[7] för utförliga instruktioner Drift sätta TK Tjänstekatalogen drift sätts genom att man deployar 2 WAR filer till en applikationsserver samt att man skapar en databas med medföljande databas skript. Se TK Anvisningar användare[8] för utförliga instruktioner Drift sätta en virtuell tjänst i VP Denna drift sättning består av att flytta in den paketerade virtuella tjänsten som man fått från integrationsutvecklaren till en katalog i Mule installationen. Sidan 18(48)

19 Därefter behöver man verifiera att tjänsten är tillgänglig vilket kräver att virtualiserings- och behörighetsinformation finns tillgängligt i tjänstekatalogen samt att den tjänsteproducent man vill nå är tillgänglig. 5.4 Administratör av TK En administratör behöver kunna logga på TK och administrera alla entiter såsom: RIV-TA-profiler Tjänstekontrakt Logisk adress Logisk adressat Tjänstekomponent Anropsbehörighet samt användare för TK. Dessutom behöver en administratör kunna spåra vem som har administrerat ingående entiteter Inloggning på TK Alla giltiga inloggningsnamn och lösenord hämtas från den databas man knutit till TK. Detta medför att man första gången måste be en databas administratör att lägga upp en användare med lösenord. Se TK Anvisningar användare[8] för utförliga instruktioner. Sidan 19(48)

20 5.4.2 Administrering av information i TK Det finns en web sida per entitet med CRUD (Create-Read-Update-Read) funktionalitet. Se TK Anvisningar användare[8] för utförliga instruktioner Spåra ändringar i TK Alla aktiviteter i TK loggas med detaljerad information om entiteten man påverkat på en logfil. Denna logfil sparas persistent på den server TK drift satts. Se TK Anvisningar användare[8] för utförliga instruktioner. 5.5 Support tjänstekonsumenter De som har support för tjänsteplattformen vill tidigt få indikationer på svarstidsproblem från bakomliggande tjänster samt få stöd att spåra tekniska problem och felorsaker som drabbar en anropande tjänstekonsument Säkerställa att VP är startad och tillgänglig VP exponerar en sk pingtjänst som kan anropas via http (tex mha en browser) och svarar om den VP-instans man ropar på är uppe. Pingtjänsten kan även användas av en lastbalanserare för att veta vilken av flera instanser som kan svara på anrop Analysera svarstidsproblem i VP VP sammanfattar och presenterar antal lyckade anrop och antal misslyckade anrop samt genomsnittliga svarstider per tjänsteproducent i en sk dashboard. Denna dashboard uppdateras automatisk var 60:e sekund. I TP 1.0 är den en enkel variant som bara lagrar data från senaste omstart per VP-instans Analysera tekniska fel VP har en loggning som är konfigurerbar m a p loggningsnivåer. Alla loggar sparas på fil för att i efterhand enkelt kunna spåra felorsaker. Tjänstekonsumenten får ett tydligt felmeddelande som retur för de felsituationer där VP har aktiverats, tex om anropsbehörighet saknas enligt definition i Tjänstekatalogen. Om det uppstår fel vid SSL-handskakningen så stoppas anropet innan anropet nått VP och då blir det andra felmeddelanden som inte följer VP-standarden. 5.6 Förvaltare En förvaltare av TP vill ha tillgång till all källkod som Öppen källkod. När förändringar i källkoden utförts vill man enkelt kunna bygga och testa hela applikationen genom att använda byggverktyg såsom Maven och enhetstester. Inför en slutleverans skall det också vara enkelt att utföra lasttester på en installation. Sidan 20(48)

21 5.6.1 Ändring i källkod All källkod finns tillgänglig som Öppen källkod under Portabla byggen Alla komponenter i tjänsteplattfomen är uppsatta för att möjliggöra portabla byggen. Alla projekt är strukturerade för maven och avses att byggas med maven 2. Filosofin sammanfattas förenklat i 3 steg, checkout, build, run Lasttester En uppsättning som kan användas för att köra lasttester i en verklig produktionsliknande miljö finns utvecklad. Den bygger på referensapplikationen som drift sätts i ett antal exemplar och har några simulerade tjänsteproducenter som svarar på anrop. Mha ett verktyg som simulerar tjänstekonsumenter kan svarstider mätas. Sidan 21(48)

22 6 Logisk vy 6.1 Komponentvy Nedanstående bild beskriver tjänsteplattformens logiska delkomponenter Vårdgivaredomän - Tjänstekonsument Härifrån sker anrop mot virtualiserad tjänst driftsatt i TjänstePlattformen. Anropet innehåller information om vilken tjänst konsumenten vill nå (tjänstekontraktet), Tjänstekonsumentens identitet (HSA-id), vilken Tjänsteproducent konsumenten vill nå (HSA-id) samt vilken version av RIV som används. Denna del ingår ej i Tjänsteplattformen utan är enbart med för att förtydliga processen. Sidan 22(48)

23 6.1.2 Vårdgivaredomän - Tjänsteproducent Detta är den verkliga tjänsten som kommer att utföra och returnera ett svar till ett inkommande anrop. Adressen till tjänsten är lagrad i Tjänstekatalogen. Denna del ingår ej i Tjänsteplattformen utan är enbart med för att förtydliga processen Virtualiseringsplattform Virtualiserad Tjänst Detta är en anslutningspunkt som Tjänsteplattformen exponerar för en viss tjänst (läs tjänstekontrakt). Givetvis kan Tjänsteplattformen härbärgera många virtuella tjänster, men varje tjänst tillförs Tjänsteplattformen genom en separat konfiguration Vägvalsrouter Denna komponent ansvarar för att ta ett beslut om att dirigera vidare ett anrop till en verklig tjänst eller ej. För att ta detta beslut använder Vägvalsroutern information från Vägvalsagenten Vägvalsagent Här sparas all information om adresser till alla tillgängliga Tjänsteproducenter (virtualiseringar) och vilka Tjänstekonsumenter som är behöriga att anropa Tjänsteproducenternas tjänstekontrakt (behörigheter). Vägvalsagenten läser upp alla virtualiseringar och alla behörigheter när Virtualiseringsplattformen startas från Vägvalsinformationstjänsten Tjänstekatalog Vägvalsinformation Tjänst Denna komponent exponerar en tjänst för hämtning av Vägvals information. Komponenten hämtar informationen från Vägvalsinformationen i Tjänstekatalogens Datalager, dvs från en databas Vägvalsadministration Denna komponent exponerar ett grafiskt användargränssnitt för administratörer av vägvalsinformations data. All data sparas i Vägvalsinformationen i Tjänstekatalogens Datalager Datalager Tjänstekatalog Vägvalsinformation Databas som håller all vägvalsinformations data. Sidan 23(48)

24 6.2 Tjänsteinteraktioner Tjänsteplattformen stödjer tjänsteinteraktioner av typen fråga-svar, informationsspridning och uppdrag-resultat Virtuell tjänst Gränssnittet för en exponerad virtuell tjänst följer WSDL:en för tjänsteinteraktionen som skall virtualiseras. Då Tjänsteplattformen enbart läser viss header information (RIV-TA-header) för att kunna göra en dirigering till den verkliga tjänsten är hanteringen av dessa WSDL:er generell Verklig tjänst Detta är den tjänst som en tjänsteproducent exponerar och detta är slutmålet för ett påbörjat anrop från en tjänstekonsument SokVagvalsInfo Detta gränssnitt tillhandahålls av Vägvalsinformationstjänsten. Gränssnittet har 2 operationer, hamtaallaanropsbehorigheter och hamtaallavirtualiseringar. Definitionen av detta gränssnitt finns i WSDL:en wrapped-vagvalsinfo-sokvagvalsinfo-1.0.wsdl. Sidan 24(48)

25 7 Design och implementerings vy Tjänsteplattformens virtualiseringsplattform och tjänstekatalog beskrivs separat utifrån ett design och implementeringsperspektiv. 7.1 Virtualiseringsplattformen För att uppnå robusthet, skalbarhet, möjlighet till framtida utökningar, och utnyttja redan skriven och testad kod nyttjar vi en ESB som grundplattform. Produkten Mule ESB har valts Valet av Mule ESB Strategin för bakom beslutet var att utgå ifrån marknadens mest etablerade öppen-källkod-esb. Mule ESB intar här en särställning helt utan konkurrens. Mule ESB har sedan utvärderats med avseende på de krav som ställdes på virtualiseringsplattformen. Utvärderingen genomfördes inkrementellt under projektet, där kraven realiserades i prioritetsordning fram tills en eventuell signifikant brist i Mule ESB upptäckts. Även om Mule ESB bedömdes vara marknadens i särklass mest utbredda ESB inom öppen källkod, är stödet för just tjänstevirtualisering relativt nytt. Det kan förmodligen förklara att en defekt kring hanteringen av ömsesidig identifiering med SSL/TLS upptäcktes under lasttest. Efter att ha kontaktat leverantören Mule Source och klargjort betydelsen av detta projekt, prioriterade leverantören den inrapporterade defektrapporten och levererade en uppdatering till projektet inom 24 timmar Bur Mule ESB tillämpas För att tillmötesgå kravet på enkel installation av nya virtuella tjänster paketeras varje virtualiserad tjänst som en komponent. Denna komponent (paketerad virtuell tjänst) hör samman med det tjänstekontrakt den virtualiserar snarare än en specifik instans av virtualiseringsplattformen. Den kan sedan installeras i alla förekommande driftsinstanser av virtualiseringsplattformen utan någon ytterligare konfiguration. som tillförs ESB'n. Vägvalsroutern är den komponent som alla virtualiserade tjänster kommunicerar med via ett internt protokoll. Sidan 25(48)