Innehåll

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.

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

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:

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.

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.

Ä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.

Följande bild illustrerar gränsdragningen när det gäller ägarskap för olika delar av ett integrationsflöde:

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

Kopplat till Integrationskatalogen finns ett ramverk på GU för att dokumentera integrationslösningar. I praktiken innebär detta en uppsättning mallar och mönster i Microsoft Excel och Microsoft Visio, för att dokumentera integrationsarkitektur på ett sätt som inte är direkt knutet till den tekniska implementationen.

Med hjälp av detta ramverk dokumenterar vi bland annat alla implementationer på Integrationsplattformen, t.ex. för konsumentadaptrar till olika applikationer. Denna designdokumentation är tillgänglig på Integrationskatalogen under respektive implementation.

Designdokumentationen omfattar bland annat:

• Övergripande flödesbeskrivning

• Detaljerad mappningsspecifikation (översättning mellan olika meddelandeformat)

• Detaljerad specifikation av orkestrering för berikning av meddelanden i flödet

• Detaljerad specifikation av ingående filter

Kärnan i dokumentationsramverket är symbolspråket Enterprise Integration Patterns (Hohpe-Wolff). Där det är tillämpligt används XPath och UML för t.ex. interaktionsdiagram och flödesdiagram. Ramverket förvaltas av ICC. Se även /wiki/spaces/ICC/pages/396755147.

Mallar

GU EIP Icons

Följande tabell beskriver GU:s anpassade symbolbibliotek för att beskriva implementationer, som används i designspecifikationer på Integrationskatalogen.

Namn	Symbol	Beskrivning	Attribut
Adapter		Generisk symbol för koppling till en integrerande applikation	EndPointRef: ​Endpoint ID för teknisk endpoint i Integrationskatalogen Type: ​Adaptertyp eller protokoll

Infrastruktur

Integrationsplattformen

ny bild!

• Software AG

  • webMethods Active Transfer

  • webMethods Integration Server

  • Universal Messaging

• IBM

  • MQ

Oracle, Op5, …