...
| Info |
|---|
...
Dessa sidor 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
...
Integrationsarkitekturen förvaltas av ICC som en del av GUs enterprisearkitektur. |
Innehållsförteckning
| Child pages (Children Display) |
|---|