Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

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:

  • Återanvändning​

  • Förvaltningsbarhet

  • Vi standardiserar integrationsgränssnitt och utrycker dem som återanvändbara tjänster som kan användas av flera konsumenter

  • Vi dokumenterar alla tjänster och hur de används i Integrationskatalogen

  • Vi väljer i första hand publish-subscribe som interaktionsmönster

Tydliga ansvarsgränser

Bakomliggande arkitekturella principer:

  • Förvaltningsbarhet

  • Vi ser till att alla tjänster har ett tydligt ägarskap

  • Integrationsplattformen är ett verktyg - inga tjänster eller information ägs av Integrationsplattformen

Lös koppling

Bakomliggande arkitekturella principer:

  • Flexibilitet

  • Vi väljer i första hand asynkron messaging med persistenta köer som transportmetod

Standardformat för meddelanden

Bakomliggande arkitekturella principer:

  • Standard

  • Förvaltningsbarhet

  • Vi väljer i första hand befintliga standardformat för respektive domän där detta är möjligt

  • Vi använder så långt möjligt strukturerade meddelandeformat som XML och JSON

Händelsestyrd överföring

Bakomliggande arkitekturella principer:

  • Användbarhet

  • Enkelhet

  • Vi väljer i första hand att agera på och propagera händelser (events) i applikationerna, till skillnad från pollning eller schemalagd överföring

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:

  • Namn - beskriver tjänstens beteende på logisk nivå (se nedan)

  • Meddelande - Ett eller flera meddelanden som används för att interagera med tjänsten

  • Interaktionsmodell - t.ex. request-reply eller publish-subscribe

  • Transportprotokoll - t.ex. REST, SOAP, JMS, MQI, SFTP…

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

Dokumentation

Infrastruktur

  • No labels