Page tree
Skip to end of metadata
Go to start of metadata

Innehåll

Sammanfattning

Övergången till nya Ladok kommer att innebära stora förändringar med avseende på många av de integrationer som finns idag mot dagens Ladok på lärosätena. Dokumentet är framtaget för att hjälpa lärosätena att göra övergången så smidig som möjligt, samt för att skapa bra förutsättningar för framtida förvaltning och utveckling.Dokumentet ger inga detaljerade lösningar, utan beskriver istället olika mönster och principer som man ska följa vid integration av lokala system med nya Ladok. De lokala systemen kan vara system som ersätter/kompletterar viss funktionalitet i Ladok eller system som på något sätt behöver eller levererar information från/till Ladok.

Målgrupp

Dokumentet vänder sig främst till systemägare, Ladokansvariga, integratörer och arkitekter.

Referenser

Begrepp

BegreppFörklaring
Atom feedAtom är ett XML-baserat format för publicering av information, som använder http för transport.
RESTRepresentational State Transfer, är ett IT-arkitekturbegrepp som beskriver hur tjänster för maskin till maskin-kommunikation kan tillhandahållas. Begreppet härrör från en avhandling av Roy Fielding (en av författarna till HTTP-specifikationen) och har fått en snabb spridning inom systemutvecklingsområdet.
LpWLadok på Web samlingsbegrepp för ett antal olika tjänstegränssnitt mot gamla Ladok.
LW-tjänsterWebbgränssnitt för olika utdata-tjänster (del av LpW)
LP-tjänsterLadok Ping-tjänster (del av LpW)
T-tjänsterLadok SOAP-tjänster (del av LpW)
TG-tjänsterLadok Portletar (del av LpW)
SOAPEtt protokoll för utbyte av information i decentraliserade och distribuerade miljöer (tidigare även kallat Simple Object Access Protocol)
SQLStructured Query Language, ett standardiserat språk för att hämta och modifiera data i en relationsdatabas

Principiell skillnad i arkitektur

En viktig skillnad mellan gamla Ladok och nya Ladok är tillgången på tjänstegränssnitt. I gamla Ladok finns den övervägande delen funktionalitet i Ladok Nouveau, som har sitt eget gränssnitt mot databasen. Endast vissa delar av systemet tillgängliggjorts via tjänstegränssnitt (T-tjänster), medan övrig integration istället gjorts direkt mot Ladoks databas via SQL.

I nya Ladok är all funktionalitet åtkomlig via REST-tjänster och används även av användargränssnittet. Majoriteten av dessa REST-tjänster kommer även att vara åtkomliga för lärosätena. Detta betyder att nya Ladok kommer att tillhandahålla ett komplett utbud av tjänstegränssnitt (REST/Atom feeds) och inte en begränsad uppsättning som i gamla Ladok gör genom T-tjänsterna. Förutom de REST-tjänster som användargränssnittet använder kan det även finnas ytterligare REST-tjänster som stöd för andra typer av maskin-till-maskin integrationer.

Med Atom feeds kan ett integrerande system hållas uppdaterat mot Ladok. I stort sett alla förändringar i Ladok resulterar i en händelse. Dessa händelser används internt i Ladok för att tjänsterna ska kunna hålla sig uppdaterade mellan varandra.

Ändrade gränssnitt

De gränssnitt som finns och används i olika utsträckning på lärosätena idag kommer att ersättas av andra typer av gränssnitt i nya Ladok. De förändringar som sker vid övergång till nya Ladok sammanfattas i nedanstående tabell och beskrivs även i den efterföljande texten.

Gamla LadokNya Ladok

Webb

  • LW - utdata

Webb

  • Uppföljning med motsvarande rapporter

Webbkomponenter

  • TG – portlets

Webb

  • Studentgränssnitt, för närvarande (2013-02-08) inte definierat i detalj
  • REST-tjänster

Tjänstegränssnitt

  • T – SOAP-tjänster
  • LP - ping

Tjänstegränssnitt

  • REST-tjänster
  • Inbyggt i systemet och finns tillgängligt via REST och användargränssnitt

SQL

  • Direkta DB frågor/ uppdateringar

SQL

  • Uppföljningsdatabas (enbart läsrättigheter till Informationsobjekt)
-

Händelser

  • Atom feeds

LW-tjänster

LW-tjänster (webb) används för uppföljningsändamål i gamla Ladok. I nya Ladok ingår motsvarande funktioner som en del av de rapporter som Uppföljningstjänsten tillhandahåller.

TG-tjänster

TG-tjänsterna i gamla Ladok riktar sig dels till personal, som komplement till Nouveau och dels till studenterna och används då ofta i lärosätets studentportal respektive intern portal för t ex lärare.

Personal

För TG-tjänster som riktar sig till personal, kommer motsvarande funktionalitet vara tillgängliga i nya Ladok via det interna användargränssnittet. Åtkomsten för olika användarkategorier (administratörer, lärare, examinatorer, etc.) styrs via behörighet.

Student

För TG-tjänster som riktar sig till studenterna pågår ett arbete (VT2014) för att detaljera innehåll och utformning av de studenttjänster som ska inkluderas i uppdraget för nya Ladok-projektet. De TG-tjänster som finns idag kommer att ha en funktionell motsvarighet i nya Ladok, men den tekniska lösningen kommer däremot inte vara densamma som idag.

T-tjänster (SOAP)

De T-tjänster som finns i gamla Ladok kommer att ersättas av REST-tjänster. I vissa fall kan likheterna vara ganska stora konceptuellt och i andra fall kan skillnaderna vara stora. Eftersom all funktionalitet som nya Ladok tillhandahåller baseras på REST-tjänster kommer det att finnas avsevärt fler än dagens T-tjänster.

LP-tjänster (Ping)

Eftersom nya Ladok blir en gemensam installation för alla lärosäten finns inte längre något behov av en extern Ping-lösning som används idag. Det betyder att motsvarigheten till LP-tjänsterna kommer att finnas som en delmängd av de REST-tjänster nya Ladok tillhandahåller. Under en övergångsperiod då det finns kvar lärosäten i gamla Ladok kommer dock Ladok Ping användas.

SQL-gränssnitt

Målsättningen med nya Ladok är att undvika användning av SQL som integrationsgränssnitt. Det finns flera orsaker till detta. De viktigaste är:

  • Att säkerställa följsamhet till systemets verksamhetslogik och regler
  • Att säkerställa aktivitetsloggning och spårbarhet
  • Att minimera beroenden mellan Ladok DB och lokala lösningar
  • Att minimera risken för påverkan på integrationer från interna förändringar i Ladok

Idag används SQL för i huvudsak nedanstående användningsområden i Ladok, antingen mot produktionsdatabasen eller mot en speglad kopia (Ladok Open):

  1. Uppföljning (Ladok Open)
  2. Integration (Ladok eller Ladok Open)

Uppföljning

Nya Ladok tillhandahåller en separat Uppföljningstjänst där varje lärosäte har sin egen databas. Man kan använda det inbyggda rapportstödet för olika typer av rapporter, bland annat årsredovisning och olika nyckeltal. Alternativt kan man även använda SQL mot de informationsobjekt Uppföljningstjänstens databas tillhandahåller. Denna möjlighet kan t ex vara lämplig att använda för de BI-verktyg lärosätena använder. Informationsmodellen i uppföljningsdatabasen är anpassad för uppföljningsändamål, bland annat kommer varje förändring att tidstämplas. Genom tidstämplingen får man möjlighet att återskapa gamla rapporter gjorda en viss tidpunkt och på det sättet slipper lagra aggregeringar i databasen.

Integration

Användning av SQL-åtkomst för integrationsändamål i gamla Ladok ersätts av REST-tjänster, ibland i kombination med händelsemeddelanden från nya Ladok. Detta beskrivs mer ingående i separat kapitel.

Händelsehantering

Något gamla Ladok saknar är möjligheten att informera omgivande system om förändringar i en tjänst, t ex att en student registrerar sig på ett kurstillfälle. I nya Ladok finns stöd för att leverera händelser med information om vad som hänt som resultat av förändringar. Integrerade system kan därför använda dessa händelser för att hålla sig uppdaterade om vad som hänt i nya Ladok och vid behov agera på dessa händelser.

Principer och riktlinjer

All åtkomst till funktioner i nya Ladok går via de REST-tjänster som nya Ladok tillhandahåller. Detta gäller både för de användargränssnitt som nya Ladok tillhandahåller och för integrationer från andra system. Det finns olika angreppssätt för att hantera förändringarna. Ett alternativ är att frikoppla de lokala systemen från Ladok m h a en integrationsplattform. En fördel med detta är att man skapar större möjligheter och flexibilitet för framtida förändringar.

Integrationsplattform

Den kanske mest flexibla lösningen med avseende på integration mot Ladok är att använda sig av en integrationsplattform (t ex BizTalk). Fördelarna är att man kan minimera påverkan på befintliga system och få en smidig successiv övergång. Mycket förenklat kan man beskriva tillvägagångssättet enligt följande.

Utgående från dagens lösningar utvecklar man adaptrar i integrationsplattformen som frikopplar de lokala systemen från Ladoks databas och LpW-tjänsterna enligt nedanstående figur. Detta kan även inbegripa att integrationsplattformen använder en egen lokal databas för de lokala systemen som fortfarande använder SQL för sin integration.

Som ett andra steg utvecklar man adaptrar för kopplingen mellan integrationsplattformen och nya Ladok och motsvarande REST/Atom feeds.

I senare skeden kan sedan de lokala systemen successivt anpassas till modernare integrationslöningar.

Indirekt integration

I enklare miljöer med ett mindre antal integrationer kan de principer som visas i Integrationsplattform även lösas utan en integrationsplattformsprodukt. Genom att skapa egna interna integrationsgränssnitt kan man få en lösare koppling mellan REST-tjänsterna och de lokala systemen.

Direkt integration

Ett annat alternativ till användning av en integrationsplattform är att istället anpassa befintliga SQL-kopplingarna i de lokala systemen direkt till REST-tjänsterna i nya Ladok. Användningen av REST-tjänster innebär då ofta ett helt annorlunda integrationsmönster jämfört med motsvarande befintliga SQL-lösningar. Det finns i princip två olika användningsområden för integration mot Ladok:

  • Försystem – system som bearbetar och förser Ladok med information (t ex utbildningsdatabaser)
  • Beroendesystem – system som behöver information från Ladok (t ex behörighetskatalog)

Försystem till Ladok

Från databasintegration till tjänsteintegration

Vissa lokala system kan vara utvecklade som en slags utökning av Ladok. Det vill säga de använder sig av en kopia av hela eller delar av dagens Ladok databas med egna utökningar. Informationen speglas mellan den egna databasen och Ladok för att hålla informationen i databaserna uppdaterad. Ett exempel på ett försystem är de utbildningsdatabaser lärosätena har mot Ladok idag. I dessa utbildningsdatabaser planeras, utvecklas och definieras utbildningsutbud för att i något läge skrivas över via SQL till Ladoks databas. Alla regelverk och kontroller görs i utbildningsdatabasen och skrivs därefter över till motsvarande tabeller i Ladoks databas

I dessa fall krävs ganska radikala förändringar i det lokala systemet för att fungera ihop direkt med Ladoks REST-tjänster. Istället för att ha en tabellorienterad integration använder man en verksamhetsorienterad integration via REST-tjänsterna. REST-tjänsterna tillhandahåller de regelverk som gäller i nya Ladok för att säkerställa kvalitet och konsistens på informationen. De förändringar/ uppdateringar man kunde göra tidigare kommer inte att vara möjliga på samma sätt som tidigare på grund av detta. Man måste även ta hänsyn till att man i nya Ladok har en stor del av den funktionalitet man har i dagens utbildningsdatabaser och baserat på det även utvärdera fördelningen mellan utbildningsdatabasen och nya Ladoks hantering av Utbildningsinformation.

Det kan betyda vid uppdatering att man i fallet utbildningsdatabas först läser in den utbildningsinformation man ska ändra från Ladok och presenterar den i utbildningsdatabasens användargränssnitt, där ändrar man önskad uppgift och därefter begär att den ska uppdateras. Utbildningsdatabasen använder då motsvarande REST-tjänst för att uppdatera uppgifterna i Ladok. Är ändringen inte tillåten enligt regelverket i Ladok får utbildningsdatabasen ett motsvarande felmeddelande tillbaka. Dessa grundprinciper gäller även för andra typer av system som fungerar som försystem till Ladok.

Beroendesystem till Ladok

Ett ”beroendesystem” är ett system som enbart behöver (läser) information från Ladok. Ett vanligt exempel på detta är de behörighetskataloger man har på lärosätena. Dessa behöver uppgifter från Ladok för att dels känna till alla studenter och dels de kurser dessa är registrerade på (deltagande). Genom att använda sig av de händelser som Ladok producerar kan behörighetskatalogen hållas uppdaterad med dessa uppgifter.

Har man behov av en initial synkronisering kan man antingen hämta alla händelser från start, eller vilket kanske är mer aktuellt hämta/söka ut de aktuella uppgifterna via motsvarande REST-tjänst och lagra dem i sin behörighetskatalog. Därefter börjar man hämta/ta emot händelser via Atom feeds från den tidpunkt man hämtade de aktuella uppgifterna för att hålla behörighetsuppgifterna uppdaterade i behörighetskatalogen.

Händelsehantering

Nya Ladok använder händelser både internt och externt för att informera om olika förändringar. Varje lärosäte har tillgång till de händelser som gäller för det egna lärosätet. Händelserna kommer i tidsordning, men är inte grupperade för olika typer av händelser.

Händelserna i nya Ladok kan användas på olika sätt beroende på vilka behov man har, det kan vara att:

  • Trigga aktiviteter i lokala system
  • Hålla lokala system uppdaterade

Finns flera mottagande system kan en lokal händelsehanterare fungera som en typ av ”dispatcher” för olika händelser till olika mottagande system. Behöver man mer information för bearbetningen, kan man kombinera mottagningen av händelsen med att via REST-tjänster hämta övriga nödvändiga uppgifter för bearbetningen.

Trigga aktivitet i lokala system

Exempel på användningsområde kan vara en student som registrerar sig på sin första kurs på ett lärosäte. Händelsen tas emot av en lokal händelsehanterare som kan filtrera/distribuera de händelser som är intressanta för de lokala systemen. I ovanstående figur triggas studentens åtkomst till kursmaterial i System 1.

Hålla lokala system uppdaterade

Ett annat exempel på användning av händelser är då man har ett system som behöver hålla en lokal kopia av informationen för sin hantering (System 2 i ovanstående figur).

Riktlinjer

Undvik "dataspegling"

Massdumpning och massläsning som tidigare gjorts via SQL för att spegla tabellinnehåll mellan Ladok databas och lokal databas kan och får inte göras på samma sätt via REST. Har man den typen av lösning idag gäller de förändringar som beskrivs i Försystem till Ladok, vilket kan betyda en större omkonstruktion av det lokala systemet.

Minimera beroenden

Bygg inte in onödiga beroenden genom att utgå från nya Ladoks informationsmodeller då ni designar era nya lokala lösningar. Arbeta istället domändrivet och utgå ifrån era behov och anpassa era system via integrationer (inom Domain-Driven Design kallat Anti-Corruption Layer) mot nya Ladok. På det sättet gör ni er mindre beroende av framtida förändringar i Ladok. Har man många olika system kan lösningen via integrationsplattform enligt Integrationsplattform vara lämplig, annars kan andra enklare lösningar vara aktuella som t ex Indirekt integration.

Statusläsning vid studentinloggning

Nya Ladok ska inte användas som behörighetskatalog för lokalt utvecklade studentgränssnitt. Behöver man på något sätt hantera behörighet på inloggade studenter, ska man istället hantera detta i sin lokala katalogtjänst (t ex LADP-katalog), som då kan födas med information från nya Ladok via händelsehanteringen enligt den princip som beskrivs i Trigga aktivitet i lokala system.

Appendix

Exempel på REST-tjänster i nya Ladok

Kataloginformation

https://www.mit.ladok.se/restdoc/kataloginformation.html

Studentinformation

https://www.mit.ladok.se/restdoc/studentinformation.html

Utbildningsinformation

https://www.mit.ladok.se/restdoc/utbildningsinformation.html

Studiedeltagande

https://www.mit.ladok.se/restdoc/studiedeltagande.html

Resultat

https://www.mit.ladok.se/restdoc/resultat.html

Examen

https://www.mit.ladok.se/restdoc/examen.html

Exempel på händelser

Examen

https://www.mit.ladok.se/restdoc/eventschemas/schemas.ladok.se-examen.html

Resultat

https://www.mit.ladok.se/restdoc/eventschemas/schemas.ladok.se-resultat.html

Studiedeltagande

https://www.mit.ladok.se/restdoc/eventschemas/schemas.ladok.se-studiedeltagande.html

Utbildningsinformation

https://www.mit.ladok.se/restdoc/eventschemas/schemas.ladok.se-utbildningsinformation.html  

REST

REST, REpresentational State Transfer, är ett arkitektur-mönster med webben och http som bas där information hanteras som resurser. En resurs är en informations-mängd som exponeras, för nya Ladok kan det till exempel vara en student eller en kurs. En resurs har en unik identitet och en adress, url, för åtkomst. I nya Ladok implementerar vi REST fullt ut med länkar mellan resurser som har samhörighet och länkar för att förändra tillståndet på en resurs.

Nya Ladok använder REST som princip för kommunikation, dels ett tjänstegränssnitt för åtkomst till resurser, (t ex hämta resultat), och för att ändra en resurs tillstånd, (t ex registrera på kurs), dels för att publicera händelser, (t ex att en student registrerat sig på en kurs). En viktig grundprincip är att REST inte ska användas för vanlig CRUD (Create, Read, Update, Delete), istället hanterar man verksamhetsrelaterade funktioner enligt exemplen. Med ett enkelt CRUD-gränssnitt, som inte bryr sig om domänen, så kan jag göra ”get” på ett studiedeltagande och sedan förändra det och göra ”put” på samma studiedeltagande. I princip så hämtar man en resurs, förändrar den och sparar den, man låter alltså inte systemet sköta förändringen. (Den här principen strider också mot objektorienteringen, det är bättre att be ett objekt förändra sitt tillstånd).

I nya Ladoks gränssnitt kan man göra ”get” på ett studiedeltagande, men däremot inte ”put”. Istället följer man länkar för att förändra tillståndet, finns det t.ex. en länk för återbud så kan jag göra ”put” med den länken för att i princip skapa en återbuds-resurs, vilket egentligen förändrar tillståndet på studiedeltagandet. Man ber alltså systemet att förändra tillståndet. Det vill säga enligt principen: ”Tell, don’t Ask”. Här finns förstås också en koppling till User Stories; vad vill användaren göra (mänskliga eller andra system).

Ovanpå REST som princip behöver vi ett protokoll som specificerar den Ladok-specifika informationen. För detta använder vi ett domänspecifikt protokoll, DAP. SOAP och Web Services. Ett alternativ till REST är att använda Web Services och SOAP. Ett problem med denna teknik är att man bara använder en liten del av de möjligheter som http ger, man ser http enbart som ett transportprotokoll. Med REST så utnyttjar vi att http är ett applikationsprotokoll. Web Services ger också en hårdare koppling mellan tjänster eftersom man anropar operationer i en annan tjänst. Med REST får vi en lösare koppling, och därmed mindre beroende, eftersom man bara utbyter resurser. Nya Ladok använder därför REST som princip för tjänstegränssnitt.

Tjänstegränssnitt

Applikationer och system använder tjänstegränssnitten i nya Ladok för att hämta information, i form av resurser, och för att via länkar i de resurser som hämtas uppdatera dessa resurser. Exempelvis så kan ett lärosäte använda tjänstegränssnitten för att läsa information om studenters studiedeltagande, registrera studenter på kurstillfällen, registrera resultat osv.

Kompatibilitet

Grundprincipen i tjänstegränssnitten och händelserna är att de ska vara strikt i vad man publicerar och flexibla vid konsumtion för att tillåta att protokollet ändras utan att det stör i onödan. Det betyder att servern ska vara noga med vad den publicerar och för klienten ska det räcka att den hittar den information den behöver, har det tillkommit ny information så ska den kunna ignoreras om motsvarande hantering inte är implementerad. Gränssnitten kommer att behöva versionshanteras, d v s information om version ska finnas tillgängligt i gränssnittet. Consumer-Driven Contracts är ett bra koncept och beskrivs bland annat i följande artiklar: http://martinfowler.com/articles/consumerDrivenContracts.html http://iansrobinson.com/2008/04/20/a-contract-vocabulary-part-3/

DAP

Ett Domain Application Protocol, DAP, representerar ett domänspecifikt protokoll, i vårt fall ett nya Ladok-specifikt protokoll. DAP bygger på REST med hypermedia-länkar för åtkomst till resurser och för att förändra tillståndet på en resurs. Protokollet bygger förutom på information om själva resursen på två viktiga element:

• Länkar med relationer till andra resurser. En länk innehåller typen av relation och en adress till resursen. Länken kan också innehålla media-typen för resursen.

• Åtgärder för att förändra tillståndet på resursen. En relation definierar typen av åtgärd. Om en åtgärd kan utföras innehåller den en länk som man följer för att utfärda åtgärden, i annat fall information om varför den inte kan utföras. Följande exempel på ett DAP-baserat XML-meddelande visar principerna för ett svar när en klient frågar efter ett specifikt studiedeltagande:

<studiedeltagande xmlns=http://schemas.studiedeltagande.ladok.se
xmlns:dap="http://schemas.studiedeltagande.ladok.se/dap">
  <dap:link rel="http://relations.studiedeltagande.ladok.se/student"
            uri="http://studentkatalog.ladok.se/student/5678"
            mediaType="application/vnd.ladok+xml"/>
  <dap:link rel="http://relations.studiedeltagande.ladok.se/kurstillfälle"
            uri="http://localhost:8084/katalog/kurstillfalle/6789"
            mediaType="application/vnd.ladok+xml"/>
  <dap:link rel="self"
            uri="http://localhost:8082/studiedeltagande/1234"
            mediaType="application/vnd.ladok+xml"/>
  <dap:action rel="http://relations.studiedeltagande.ladok.se/återbud">
    <dap:impediment>utanför_registreringsperiod</dap:impediment>
  </dap:action>
  <dap:action rel="http://relations.studiedeltagande.ladok.se/registrering">
    <dap:link uri="http://localhost:8082/studiedeltagande/registrering/1234"
              mediaType="application/vnd.ladok+xml"/>
  </dap:action>
  <skapad>2012-01-17T14:59:15.992</skapad>
  <tillstånd>ej_påbörjat</tillstånd>
</studiedeltagande>

OBS! Det visade exemplet visar bara principen och ska inte användas som underlag för implementation.

Exemplet innehåller tre länkar, dap:link, med adress till den student och det kurstillfälle som studiedeltagandet rör samt till studiedeltagande självt, (rel="self"). Exemplet innehåller också två element som representerar åtgärder, dap:action, en för registrering, som kan göras genom att följa länken, och en för återbud, (som inte kan utföras, istället för en länk finns det ett hinder, dap:impediment). Exemplet har inte med någon information om andra resurser som t.ex. student. I verkligheten kommer troligen även en del (begränsad) information om studenten att finnas med, men kanske bara namn och/eller personnummer.

Finns det behov av mer kompletta svar kan vi behöva ett alternativt tjänstegränssnitt, ungefär som webbgränssnittet, som sätter samman information från flera tjänster och sedan returnerar hela paketet. Troligen behöver vi separera interaktion och informationssökning på något sätt för att kunna hantera vissa typer av massfrågställningar, såvida inte dessa hanteras via Uppföljningstjänsten. Vi har också möjlighet att kapsla in vårt DAP i en mer generell standard, Atom.  

Atom

Atom syftar på två relaterade standarder, Atom Syndication Format och Atom Publishing Protocol. Båda är generella men bygger på ett domänspecifikt protokoll, DAP, och tillför standardiserat metadata till detta.

Konceptuell beskrivning

I Ladok lagras händelserna per lärosäte och ger lokala system möjlighet att ta emot händelser. Händelsehanteringen baseras på Atom feeds (http://www.ietf.org/rfc/rfc4287.txthttp://www.ietf.org/rfc/rfc5023.txt). Varje sådan feed kan innehålla en eller flera händelser (entryn). Varje feed har en länk till nästa och föregående, som används för att kunna traversera sig genom listan. Varje feed har även ett unikt ID, som används av den tjänst som hämtar informationen för att hålla reda på vilken feed som hämtades i senaste hämtningen.

Hämtningen börjar från den senaste händelsen i listan och går mot den äldsta, tills man träffar på det ID man redan hämtat, då går man tillbaka i listan till nästa nyare händelse osv tills man har läst in alla nyare händelser till det senaste. Spontant kanske det verkar generera onödig trafik, men genom att utnyttja de caching-mekanismer som finns i http-protokollet behöver inte informationen transporteras igen, utan tas istället från cachen då man sedan hämtar de nyare händelserna.

Atom Syndication

Format Atom Syndication Format är ett generellt XML-baserat hypermediaformat för att representera tidsstämplade listor med information som kan användas för att överföra data mellan system, men enbart för att hämta information.

För nya Ladok kan det användas för att publicera händelser, exempelvis nya kurser eller ändrat status på studiedeltagande. Atom representerar data som listor, feeds, som består av en eller flera entries som var och en består av en tidsstämpel, det data som transporteras och metadata om detta. Även med Atom som ett standardformat så innehåller det ett domänspecifikt format för det Ladok-specifika innehållet i en entry. Följande exempel på ett Atom-baserat XML-meddelande visar principerna för en händelse, i detta fall att en student för första gången registrerat sig på ett kurstillfälle:

<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Studiedeltagande, händelser</title>
  <id>urn:uuid:6356f9a2-dc1e-4eb9-8f83-3f1bb3ad9993</id>
  <updated>2012-01-15T00:01:02.745</updated>
  <link rel="self"
        href="http://studiedeltagande.ladok.se/notifications/153"/>
  <link rel="prev-archive"
        href="http://studiedeltagande.ladok.se/notifications/152"/>
  <link rel="next-archive"
        href="http://studiedeltagande.ladok.se/notifications/154"/>
  <entry>
    <category scheme=http://studiedeltagande.ladok.se/categories/event
              term="förstagångsregistreradpåkurstillfälle"/>
    <content type="application/vnd.ladok+xml">
      <förstagångsregistreradpåkurstillfälle
            xmlns=http://schemas.studiedeltagande.ladok.se
            xmlns:dap="http://schemas.studiedeltagande.ladok.se/dap">
        <studiedeltagandeid>1234</studiedeltagandeid>
        <studentid>2345</studentid>
        <kurstillfälleid>3456</kurstillfälleid>
        <tidpunkt>2012-01-17T14:59:15.992</tidpunkt>
      </förstagångsregistreradpåkurstillfälle>
    </content>
  </entry>
</feed>

OBS! Det visade exemplet visar bara principen och ska inte användas som underlag för implementation.

Atom Publishing Protocol

Atom Publishing Protocol, AtomPub, är ett http-baserat protokoll för att skapa och uppdatera resurser och bygger på Atom Syndication Format, och därigenom indirekt också på ett DAP. AtomPub ger möjlighet för en klient att förutom att läsa även att skicka information för att skapa eller uppdatera information. För nya Ladok kan det användas i tjänstegränssnitten. Referens: http://www.ietf.org/rfc/rfc5023.txt

DAP - Atom

Grunden för våra två typer av gränssnitt är ett protokoll, DAP (se kap 4.2.3), specifikt för nya Ladok. DAP kan sedan byggas på med ett Atom-baserat (se kap 0) format eller protokoll beroende på behovet. I nya Ladok kommer vi att använda båda varianterna enligt följande kapitel.

Händelser

Vid publicering av händelser behöver varje händelse extra information, exempelvis en unik identitet, ordningsföljd och tidsstämpling. Det är metadata som Atom Syndication Format på ett standardiserat sätt enkelt kan tillföra vårt DAP. Det finns också färdiga komponenter för implementation av ett Atom-format. Vi väljer därför att för publicering av händelser använda Atom Syndication Format ovanpå vårt DAP.

Tjänstegränssnitt

För tjänstegränssnitten kan Atom Publishing Protocol användas och det tillför då metadata till vårt DAP för att läsa och uppdatera resurser. Vi ser för närvarande inget av behov av denna utökning av metadata utan mer att det ökar komplexiteten. Vi väljer därför att enbart använda ett DAP i implementationen av tjänstegränssnitt.

REST vs. SOAP-tjänster

Eftersom REST baseras på väl etablerade standarder (http och XML) finns ett brett plattformsstöd för de gränssnitt som används i nya Ladok. I nya Ladok baseras tjänstegränssnitten på REST, istället för SOAP, enligt de arkitekturella principer som tagits fram för nya Ladok. Med REST får man en lösare koppling mellan systemen och därmed ett mindre beroende. I SOAP använder man bara en liten del av de möjligheter som HTTP ger, då HTTP används enbart som ett transportprotokoll där. Med REST utnyttjas HTTP som ett applikationsprotokoll. De T-tjänster (SOAP) som används i gamla Ladok använder ett XML-schema som utgår från den informationsmodell som finns i gamla Ladok.

Eftersom nya Ladok kommer att ha en helt ny informationsmodell, kommer även dessa XML-scheman att påverkas. Det betyder att förutom övergång från SOAP-baserade tjänster till REST-baserade, så kommer även informations-innehållet att skilja sig åt. Till exempel kan vissa enskilda SOAP-tjänster ersättas med flera REST-tjänster. Informationsobjekten kan se annorlunda ut med olika mängd attribut, etc. I följande kapitel ges ett fiktivt exempel på ett SOAP-anrop och motsvarande fiktiva svar, samt ett motsvarande fiktiva REST-anrop med svar.

Begär studiedeltagande - SOAP

Med SOAP beskriver anropet ett gränssnitt, som ska hantera anropet. Ändras gränssnittet måste även anropet ändras. Det http-verb som används är POST, även då man hämtar uppgifter.

Exemple SOAP

POST /studiedeltagande HTTP/1.1
Host: www.example.org
Content-Type: application/soap+xml; charset=utf-8
Content-Length: 123

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.example.org/studiedeltagande">
  <m:GetStudiedeltagande>
    <m:StudiedeltagandeID>1234</m:StudiedeltagandeID >
  </m:GetStudiedeltagande >
</soap:Body>
</soap:Envelope>

OBS! Det visade exemplet visar bara principen och ska inte användas som underlag för implementation.

Begär studiedeltagande REST

I REST begär man istället en resurs.

Exempel REST

GET /studiedeltagande/1234 HTTP/1.1

OBS! Det visade exemplet visar bara principen och ska inte användas som underlag för implementation.

Svar studiedeltagande SOAP

Svaret i SOAP innehåller i princip en datastruktur, som man sen kan använda på olika sätt, t ex genom att skapa en ny SOAP-begäran enligt Konceptuell beskrivning för att hämta nya uppgifter eller uppdatera någon uppgift.

Exempel SOAP

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<soap:Body xmlns:m="http://www.example.org/stock">
  <m:GetStudiedeltagandeResponse>
    <m:StudiedeltagandeID>1234</m:StudiedeltagandeID>
    <m:Student>6789</m:Student>
    <m:Kurstillfalle>6789</m:Kurstillfalle>
    <m:Impediment>utanför_registreringsperiod</m:Impediment>
    <m:Skapad>2012-01-17T14:59:15.992</m:Skapad>
    <m:Tillstånd>ej_påbörjat</m:Tillstånd>
  </m:GetStudiedeltagandeResponse>
</soap:Body>
</soap:Envelope>

OBS! Det visade exemplet visar bara principen och ska inte användas som underlag för implementation.

Svar studiedeltagande REST

Svaret i REST innehåller motsvarande resultat men innehåller också på samma gång uri:er till de olika resurserna. En sådan uri kan sedan användas till att påverka eller skapa en resurs, men också för att hämta motsvarande resurs information. På det sättet får man automatiskt information om vad man kan göra i den aktuella tjänsten. I nedanstående exempel kan man hämta uppgifter för studenten 5678 och kurstillfället 6789. På motsvarande sätt kan man (”dap:action”) registrera på studiedeltagandet 1234, men inte lämna återbud på studiedeltagandet (”dap:impediment”).

Exempel REST

HTTP/1.1 200 OK
Content-Type: text/xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0"?>
<studiedeltagande xmlns=http://schemas.studiedeltagande.ladok.se
                  xmlns:dap="http://schemas.studiedeltagande.ladok.se/dap">
  <dap:link rel="http://relations.studiedeltagande.ladok.se/student"
            uri="http://studentkatalog.ladok.se/student/5678"
            mediaType="application/vnd.ladok+xml"/>
  <dap:link rel="http://relations.studiedeltagande.ladok.se/kurstillfälle"
            uri="http://localhost:8084/katalog/kurstillfalle/6789"
            mediaType="application/vnd.ladok+xml"/>
  <dap:link rel="self"
            uri="http://localhost:8082/studiedeltagande/1234"
            mediaType="application/vnd.ladok+xml"/>
  <dap:action rel="http://relations.studiedeltagande.ladok.se/återbud">
    <dap:impediment>utanför_registreringsperiod</dap:impediment>
  </dap:action>
  <dap:action rel="http://relations.studiedeltagande.ladok.se/registrering">
    <dap:link uri="http://localhost:8082/studiedeltagande/registrering/1234"
              mediaType="application/vnd.ladok+xml"/>
  </dap:action>
  <skapad>2012-01-17T14:59:15.992</skapad>
  <tillstånd>ej_påbörjat</tillstånd>
</studiedeltagande>

OBS! Det visade exemplet visar bara principen och ska inte användas som underlag för implementation. 

 

Behörighet och säkerhet för REST-tjänster

För information om behörighet och säkerhet för REST-tjänsterna, se Behörighetshantering för integrerade system.

 

 

 

  • No labels