Innehåll

Inledning

...

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:

• Å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

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.

Dokumentation

Integrationskatalogen

Översikt

Alla systemintegrationer som involverar centralt förvaltade applikationer på GU dokumenteras i Integrationskatalogen, som är ett ramverk och en applikation för att dokumentera systemintegrationer. Målsättningen är att samtliga integrationer på GU skall vara beskrivna här. Graden av detaljer kan variera, men alla integrationsflöden skall kunna återfinnas åtminstone på den översta nivån (tjänster och kontrakt). Ansvaret för innehållet i integrationskatalogen ligger hos ICC.

...

Målgrupp för Integrationskatalogen

Integrationskatalogen är tillgänglig för all personal på universitetet, men den huvudsakliga målgruppen är:

• Objektägare, Objektledare och Objektspecialister tillsatta enligt GUSPP styrmodell

• IT-arkitekter och personal på IT-enheten knutna till ICC

• Externa aktörer som önskar integrera med GU:s IT-system

Funktion och innehåll

Integrationskatalogen är en implementation i Sharepoint av den begreppsmodell som beskrivs ovan. Detta innebär att följande objekt finns för alla integrationer: 

• Publicerande system (System, benämns Application i bilden ovan)

• Publicerad tjänst (Service)

• Tjänstemeddelande (Message)

• Kontrakt mellan mottagare och tjänst (Contract)

• Konsumerande system (System)

Förutom detta finns möjlighet att beskriva hur en tjänst eller ett kontrakt är implementerat, om detta sker utanför respektive applikation t.ex. på Integrationsplattformen:

• Kontraktimplementation (Implementation)

• Tjänsteimplementation (Implementation)

Alla ovanstående objekt representeras i listor (System List, Service List) med kopplingar sinsemellan enligt modellen. Service har således alltid en referens till System som är publicerande system för tjänsten, Message som är det meddelande som tjänsten tillhandahåller, osv.

Varje objekt har en uppsättning beskrivande attribut. Alla typer av objekt har ett ID, ett namn och en beskrivande text. Förutom detta kan det finnas mer specifika fält som t.ex. Service Endpoint Type som talar om hur en tjänst är tillgänglig (kö, REST, SFTP osv.), Message Format som talar om vilket format som ett meddelande använder (XML, JSON osv.).

Dessutom finns dokument med ytterligare information knutna till enskilda objekt. Även dessa lagras i dokumentlistor (Service Doc, Implementation Doc osv.). För meddelanden kan det vara t.ex. XML-scheman eller andra typer av formatbeskrivningar. För tjänster kan det vara information om hur man använder tjänsten och vilken data den tillhandahåller. För implementationer är det designdokument (blueprints) som i detalj specificerar hur t.ex. en konsumentadapter fungerar, vilka mappningar som görs mellan meddelandeformat osv.

Förutom dokumentation av tjänster och kontrakt finns också en avdelning i integrationskatalogen för integrationsbeställningar (Integration Request).

Designdokument och specifikationer

krfsm

...

Innehållsförteckning