Inledning
Denna sida beskriver GU:s integrationsarkitektur. Med integrationsarkitektur avses de principer, modeller och ramverk som tillämpas inom systemintegration på GU.
Arkitekturella principer för integration
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 |