...
| Krav Id | Beskrivning | Typ | ||||
|---|---|---|---|---|---|---|
| K-1 | Införandet av en virtuell tjänst i samverkan mellan tjänstekonsument och tjänsteproducent ska maximalt tillföra 40 millisekunder i exekveringstid, i förhållande till ett anrop utan mellanhand. | Prestanda | ||||
| K-2 | Virtualiseringsplattformen ska stödja gängse modeller för lastbalansering, så som klustring. Virtualiseringsplattformen skalas på samma sätt som vanliga web-applikationer. | Skalbarhet | ||||
| K-3 | All kommunikation ska 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). | Säkerhet | ||||
| K-4 | VP skall enkelt kunna utökas med ny funktionalitet. Detta kan t.ex. vara att klara av framtida konverteringar mellan olika RIV-TA-profiler. | Utökningsbarhet | ||||
| K-5 | VP ska kunna driftsättas på alla plattformar där Mule ESB erbjuder installationsstöd. Det täcker alla vanligt förekommande Linux-, Unix- och Windowsversioner. | Flexibilitet | ||||
| K-6 | Virtualiseringsplattformen ska ha stöd för teknisk monitorering av Mule ESB. Detta innebär också riktat stöd för monitorering av svarstider hos tjänsteproducenter och att VP loggar på loggformat lämpliga för övervakning av gängse övervakningsverktyg. | Monitorering | ||||
| K-7 | 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. | Tillgänglighet | ||||
| K-8 | Virtualiseringsplattformen (VP) ska inte vara beroende av att Tjänstekatalogens (TAK) tjänster för att hämta behörighet och routing är tillgänglig online, vilket medför att VP ska kunna utföra sitt uppdrag även när TAK inte är tillgänglig. | Tillgänglighet | ||||
| K-9 | VP ska levereras som öppen källkod under licensen LGPL. | Flexibilitet | ||||
| K-10 | VP ska leverera en exempelapplikation som visar på ett komplett uppsatt end-to-end-exempel. Detta ger en startpunkt för de som vill testköra och praktiskt skapa sig en förståelse av VP. | Flexibilitet | K-11 | VP ska levereras med automatiserade last- och robusthets-tester. Plattformen kommer - även om den är distribuerad - att vara förknippad med höga SLA-krav. Robust exekvering av inkomna meddelanden med minimal overhead, timme ut och timme in, är avgörande för att plattformen ska anses tillförlitlig. | Prestanda | |
| K-1211 | All utveckling av VP ska baseras på portabla, komponentbaserade byggen enligt en väl beskriven produktstruktur. | Flexibilitet | ||||
| K-13 | Virtualiseringsplattformen ska inte ha egna protokoll, utan använder samma protokoll som föreskrivs av vården för samverkan mellan tjänster. | Interoperabilitet | K-14 | 12 | Virtualiseringar ska kunna skapas mha en enkel instruktion. Detta utifrån en kanonisk, abstrakt WSDL med tillhörande scheman för ett tjänstekontrakt och därefter kunna skapa paketeringar per tjänstekontrakt som kan slutkonfigureras och driftsättas i olika instanser av virtualiseringsplattformen. |
...
| Krav Id | Beskrivning | Typ | |||
|---|---|---|---|---|---|
| FK-1 | Autentisering för HTTPS ska ske via "mutual authentication" i två led eller fler led för Virtualiseringsplattformen enligt RIV Tekniska Anvisningar. | Säkerhet | |||
| FK-2 | Auktorisation för HTTPS ska ske via det HSA-id ett anropande system presenterar i certifikatets "subject" | Säkerhet | |||
| FK-3 | Autentisering och Auktorisation för HTTP ska ske genom användning av information i HTTP-headers. | Säkerhet | |||
| FK-4 | All intern kommunikation mellan SKLTP-komponenter ska gå via HTTP med extra verifiering av anslutande part enligt FK-3. | ||||
| FK-5 | VP ska stödja "RIV-TAs frivilliga anvisning angående HTTP Header för att ange ursprunglig avsändare". | ||||
| FK-6 | VP ska hantera olika versioner av RIV-TA profiler, dvs en översättning mellan olika RIV TA-profiler (transformering mellan olika kuverterings- och säkerhetsmodeller). | ||||
| FK-7 | Felmeddelande som orsakas i virtualiseringsplattformen ska rapporteras som SOAPFault till tjänstekonsumenten med tillhörande HTTP Status kod (500), samt loggas. ID i SOAPFault ska finnas för korrelering mot en loggfil. | Felhantering | |||
| FK-8 | Felsituationer som är förutsägbara baserade på inkonsistens mellan metadata i meddelandetrafik och innehåll i tjänstekatalog, ska redovisas i SOAPFaults med mycket stor tydlighet, så att det inte råder något tvivel om orsaken och vad som behöver göras (se standardiserade felkoder nedan). | Felhantering | |||
| FK-9 | Alla former av fel ska kunna spåras i efterhand då dessa loggas persistent. Loggnivån ska vara konfigurerbar för att kunna spara extra mycket spårningsinformation. | Felhantering | |||
| FK-10 | VP ska redovisa svarstider mot bakomliggande tjänsteproducenter dels i interna loggar och dels till anropande system. | ||||
| FK-11 | Virtuella tjänster ska paketeras separat och därmed kunna driftsättas separat iVP | mha enkla instruktioner.FK-12 | VP ska under drift kunna hämta och uppdatera sin konfiguration från en Tjänstekatalog (TAK). Detta innebär att VP ska behöver ha en cache med TAK konfiguration som om en sådan läsning misslyckas för att säkerställa VPs driftsfunktionalitet. Denna cache uppdateras vid ett lyckat anrop. | ||
| FK-1312 | VP ska under drift kunna hämta och uppdatera sin HSA konfiguration från en lokalt inläst HSA-fil. Detta innebär att VP skabehöver ha en cache med HSA konfiguration somom en sådan läsning misslyckas för att säkerställa VPs driftsfunktionalitet. Denna cache uppdateras vid ett lyckat anrop. | ||||
| FK-1413 | VP ska per tjänst kunna konfigurera ett separat time-out värde. Är inget time-out värde angivet skall ett defaultvärde användas(konfigurerbart). | ||||
| FK-1514 | VP ska per tjänst kunna konfigurera om keep-alive skall användas i kommunikationen. | ||||
| FK-1615 | VP ska stödja "RIV-TAs frivilliga anvisning angående status för anrop till aggregerande tjänster". | ||||
| FK-16 | VP ska per tjänst kunna besvara ett tjänsteanrop med ?wsdl. Detta så att tjänstekonsumenter alltid kan få tillbaka aktuell wsdl och scheman för tjänsten. Detta skall gälla även om det finns en reverse-proxy/lastbalanserare framför VP. |
Standardiserade felkoder
| Ankare | ||||
|---|---|---|---|---|
|
...
Bakom en reverse proxy, på ett känt nätverk (eget nätsegment) vill man minimera kommunikationsoverhead så mycket som möjligt. För att stödja detta kan SKLTP komponenter ansluta till VP genom att bifoga information om avsändare, logisk tillhörighet och ip-adress.
...
Då denna header kan användas för behörighetskontroll i källsystem så måste tjänsteplattform säkerställa att den enbart tar emot denna header från betrodda parter, typiskt andra angränsande tjänsteplattformar som den kommunicerar med. Ett sätt att säkerställa att avsändaren är känd kan vara att hålla en lista på ip-nummer som man litar på och kontrollera mot den innan man accepterar inkommande header för ursprunglig avsändare.
...
Ursprunglig avsändare och lastbalanserare/reverse-proxy
Då det är mycket vanligt att man använder lastbalanserare och/eller reverse-proxy framför sin tjänsteplattform så kompliceras bilden en smula:
...