Inledning
Denna sida beskriver GU:s integrationsarkitektur. Med integrationsarkitektur avses de principer, modeller och ramverk som tillämpas inom systemintegration på GU.
Integrationsarkitekturen förvaltas av ICC som en del av GUs enterprisearkitektur.
Arkitekturella principer för integration
Följande är arkitekturella principer för systemintegration som skall vara vägledande i allt arbete med integration på GU.
Princip | Innebörd |
|---|---|
Tjänsteorienterad design Bakomliggande arkitekturella principer:
|
|
Tydliga ansvarsgränser Bakomliggande arkitekturella principer:
|
|
Lös koppling Bakomliggande arkitekturella principer:
|
|
Standardformat för meddelanden Bakomliggande arkitekturella principer:
|
|
Händelsestyrd överföring Bakomliggande arkitekturella principer:
|
|
Tjänsteorientering
Begreppsmodell
Tjänsteorientering kan sägas vara kittet och den överordnade principen i hela GU:s integrationsarkitektur. Följande begreppsmodell är central i arkitekturen:
Modellen visar hur alla kopplingar mellan applikationer (Consumer, Provider) definieras i termer av tjänster (Service) och kontrakt (Contract). Detta sätt att beskriva systemintegrationer driver och underlättar en återanvändbar design.
Definitioner
Begrepp | Innebörd |
|---|---|
Service Sv: Tjänst, Integrationstjänst | En Tjänst används av en eller flera applikationer (konsumenter). En integrationstjänst definieras av bland annat:
|
Message Sv: Meddelande | Ett Meddelande beskriver vilken information som kan utbytas med en tjänst. |
Application (Provider) Sv: Producent | En Producent är en applikation som tillhandahåller (äger) en tjänst. |
Application (Consumer) Sv: Konsument | En Konsument är en applikation som konsumerar (använder) en tjänst. |
Contract Sv: Kontrakt | Ett Kontrakt beskriver den logiska kopplingen mellan en konsument och en tjänst. |
Implementation (Provider) Sv: Implementation (tjänst) | En Implementation (tjänst) är de tekniska komponenter som realiserar en integrationstjänst. Om en tjänst saknar dokumenterad implementation innebär det att den i sin helhet realiseras av applikationen själv (t.ex. ett REST-API). Om en tjänst bygger på infrastruktur utanför applikationen, t.ex. komponenter på Integrationsplattformen, räknas denna infrastruktur till tjänstens implementation och ägs alltså av den applikation som äger tjänsten. Detta kallas även tjänste-adapter. |
Implementation (Consumer) Sv: Implementation (kontrakt) | En Implementation (kontrakt) är de tekniska komponenter som realiserar ett kontrakt. Om ett kontrakt saknar dokumenterad implementation innebär det att kontraktet i sin helhet realiseras av applikationen själv (t.ex. en REST-klient). Om ett kontrakt bygger på infrastruktur utanför applikationen, t.ex. komponenter på Integrationsplattformen, räknas denna infrastruktur till kontraktets implementation och ägs alltså av den applikation som äger kontraktet. Detta kallas även konsument-adapter. |
Logisk tjänstearkitektur
Kopplingar mellan applikationer på logisk nivå beskriver vi med en logisk tjänstearkitektur. Syftet med detta är att illustrera informationsmässiga samband och interaktioner mellan system på en övergripande nivå.
Exempel på en tjänst med två konsumenter:
Observera att en logisk tjänstearkitektur inte säger något om den tekniska lösningen (implementationen). Den visar endast vilka system som utbyter vilken information. Namnet på tjänsten ger också en indikation på hur interaktionen är tänkt att gå till, mer om detta nedan.
Namnstandard för tjänster
Namnkonventionen för tjänster följer riktlinjer från OAGIS, dvs. <Verb>.<Noun>.
(resten av detta stycke är på engelska av historiska skäl)
Syntax för namn på tjänster: <Verb>.<Informationsentitet>[Kvalificering][Omfattning][Mottagare][Parameter]
Följande verb används för att beskriva tjänstens grundläggande beteende:
Verb | Innebörd |
|---|---|
Sync | |
Get | |
Process |
Resten av tjänstenamnet beskriver vilken information som kan utbytas med tjänsten. I normalfallet är detta bara namnet på ett informationsobjekt, t.ex. Person, Student eller Kurs.
Ibland behövs dock ytterligare information för att kvalificera vilken data tjänsten tillhandahåller. Dessa delar är inte obligatoriska, men skall följa nedanstående rekommendationer för namngivning om de används.
Komponent | Innebörd |
|---|---|
Informationsentitet | Namn på informationsobjekt. Informationsobjekt har alltid namn på svenska. Det skall vara enkelt att förstå vilken data tjänsten tillhandahåller. Använd singular eller plural efter behov. Exempel: Student, Studenter |
Kvalificering (ej obligatorisk) | Indikerar en specifik variant av informationsobjekt. Exempel: OrganisationerBakåtTotal indikerar att tjänsten tillhandahåller bakåtkompatibelt organisationsträd. |
Omfattning (ej obligatorisk) | Används endast om flera informationsobjekt skickas i samma meddelande. Använd “Delta” eller “Total” för att indikera om meddelandet innehåller samtliga objekt eller bara nya/uppdaterade objekt. Exempel: PersonalTotal, PersonalDelta |
Mottagare (ej obligatorisk) | Används endast för “privata tjänster” dvs legacy-tjänster ämnade för direktintegration med en specifik konsument. Använd med försiktighet. Använd prefix: “To”. Exempel: FrånvaroTotalToRetendo |
Parameter (ej obligatorisk) | Används endast för Get-tjänster där en parameter är nödvändig för att göra skillnad mellan likartade tjänster som tillhandahåller samma informationsobjekt. Använd med försiktighet. Använd prefix: “By”. Exempel: Get.UserIDByPersonnummer |
Livscykel för tjänster
Integrationstjänster följer samma livscykel som andra objekt i arkitekturen. Följande modell beskriver denna livscykel:
Livscykelstadier
Följande tabell beskriver livscykelns olika stadier i en integrationstjänstekontext.
Tillstånd | Innebörd |
|---|---|
Proposed | Tjänsten är på förslag att tas fram och designarbete pågår. |
Rejected | Arbetet med tjänsten har avbrutits. |
Decided | Design är granskad och godkänd av integrationsarkitekt. Beslut är fattat om införande. |
Emerging | Tjänsten är under utvärdering. |
Appointed | Tjänsten följer beslutade designprinciper och är det föredragna sättet att integrera med systemet för detta syfte. |
Preserving | Tjänsten är tillgänglig tills vidare men följer inte designprinciper och kan komma att ersättas i framtiden. |
Sunset | Det finns ett beslut om att avveckla tjänsten och den har ett fastställt datum för End of Life. Nya konsumenter bör i normalfallet inte använda den. |
Decommissioned | Tjänsten är avvecklad. |
Ägarskap
Inom arkitekturen och i synnerhet inom integrationsarkitekturen är ägarskap en central fråga för att definiera tydliga ansvarsgränser, både när det gäller ansvar för att data är korrekt och sprids enligt beslutade riktlinjer men också för administrativa och ekonomiska gränsdragningar.
Alla objekt (tjänster, kontrakt, implementationer och meddelanden) som ingår i begreppsmodellen har en ägare som är liktydig med den applikation som är part i systemintegrationen. Från detta följer ett ägarskap och förvaltningsansvar inom ett objekt i GUSPP Styrmodell. Detta ägarskap dokumenteras i Integrationskatalogen.
Generellt gäller att den som äger en tjänst fattar beslut som rör dess förvaltning och utveckling, vilka som får konsumera tjänsten och så vidare. Det är också objektets förvaltningsbudget som bekostar vidmakthållande och vidareutveckling av externa implementationer där sådana finns, t.ex. på Integrationsplattformen.
I alla dessa frågor är ICC ett stöd inom administration och dokumentation, arkitektur och teknik. Inga implementationer och ingen data ägs av ICC eller Integrationsplattformen. Integrationsplattformen och de tekniska komponenter som ingår där (IBM MQ, webMethods osv) utgör en infrastruktur som tillhandahålls av IT-enheten, att jämföra med nätverk och lagring. Alla tjänster och integrationsflöden på GU ägs av en applikation och därigenom ett objekt, inte av ICC.