PM Tjänstegränssnitt Ladok3

Bo Sehlberg, Jan Stenberg Sida: 1 (17) PM Tjänstegränssnitt Ladok3

Bo Sehlberg, Jan Stenberg Sida: 2 (17) Innehållsförteckning 1 Inledning...4 1.1 Målgrupp...4 1.2 Referensdokument...4 1.3 Begrepp...5 2 Grundprinciper...5 2.1 REST-tjänster...5 2.1.1 Omfattning...6 2.2 Händelsehantering...6 2.2.1 Konceptuell beskrivning av Atom feed...6 2.2.2 Händelser direkt mellan tjänsterna...7 2.3 Användning på U/H...8 2.3.1 Händelser för U/H...8 2.3.2 Tjänstegränssnitt för U/H...8 3 Exempel på typer av tjänstegränssnitt...9 3.1 Studentuppgifter...9 3.1.1 Tjänstegränssnitt...9 3.2 Utbildningsinformation...9 3.2.1 Tjänstegränssnitt...9 3.3 Studiedeltagande...9 3.3.1 Tjänstegränssnitt...9 3.4 Resultat... 10 3.4.1 Tjänstegränssnitt... 10 3.5 Examenshantering... 10 3.5.1 Tjänstegränssnitt... 10 3.6 Uppföljning... 10 3.6.1 Tjänstegränssnitt... 10 4 Meddelanden från Ladok3... 10 4.1 Studentuppgifter... 10 4.2 Utbildningsinformation... 10 4.3 Studiedeltagande... 10 4.4 Resultat... 11 4.5 Examenshantering... 11 4.6 Uppföljning... 11 5 REST i Ladok3... 11 5.1 REST... 11 5.1.1 Tjänstegränssnitt... 12 5.1.2 Händelser... 12 5.1.3 Kompatibilitet... 12 5.2 DAP... 12 5.3 Atom... 13 5.3.1 Atom Syndication Format... 14 5.3.2 Atom Publishing Protocol... 14 5.4 DAP - Atom... 15

Bo Sehlberg, Jan Stenberg Sida: 3 (17) 5.4.1 Händelser... 15 5.4.2 Tjänstegränssnitt... 15 6 REST vs. SOAP-tjänster... 15 6.1 Begär studiedeltagande SOAP... 15 6.2 Begär studiedeltagande REST... 16 6.3 Svar studiedeltagande SOAP... 16 6.4 Svar studiedeltagande REST... 17

Bo Sehlberg, Jan Stenberg Sida: 4 (17) 1 Inledning Övergången till Ladok3 kommer att innebära en hel del förändringar med avseende på de olika integrationerna på lärosätena. Detta PM beskriver övergripande vilka tjänstegränssnitt, som kommer att tillhandahållas i Ladok3. Dokumentet beskriver även hur Ladok3 tekniskt kommer att använda REST och Atom feeds. 1.1 Målgrupp Dokumentet vänder sig främst till arkitekter, systemintegratörer, IT-chefer och systemägare. 1.2 Referensdokument Namn REST in Practice PM Hantering av integrationer i Ladok3 PM REST i Ladok3 Restful Web Services Leonard Richardson and Sam Ruby. ISBN: 978-0596529260 Architectural Styles and the Design of Network-based Software Architectures Roy Thomas Fielding, (dissertation). Beskrivning http://restinpractice.com/book/ Beskriver övergripande på vilket sätt Ladok3 påverkar lärosätenas integrationer. Beskriver hur REST (tjänsteanrop mot Ladok3) och Atom feeds (händelser från Ladok3) används i Ladok3

Bo Sehlberg, Jan Stenberg Sida: 5 (17) 1.3 Begrepp Namn REST Atom feed Händelse LMS SOAP Tjänst Tjänstegränssnitt Beskrivning Verksamhetstjänst Se tjänst 2 Grundprinciper Representational State Transfer (REST) är ett ITarkitekturbegrepp som beskriver hur tjänster för maskin till maskin-kommunikation kan tillhandahållas. Atom är ett XML-baserat format för prenumeration (syndikering) av information, samt ett HTTP-baserat protokoll för att redigera informationsresurser. Information om en tillståndsförändring i en tjänst. Learning Management System eller på svenska lärplattform, t ex Moodle, Sakai, PingPong SOAP är ett XML-baserat protokoll för utbyte av information i decentraliserade och distribuerade miljöer. Ladok3:s definition av en tjänst i en tjänsteorienterad arkitektur, är att tjänsten ansvarar för en viss verksamhetsfunktion eller verksamhets(del)process. Varje tjänst kan tillhanda noll, ett eller flera REST-tjänster, samt noll, en eller flera Atom feeds. En teknisk gränsyta som en verksamhetstjänst tillhandahåller åt konsumenter. Ladok3 är preliminärt uppbyggt av sex s.k. verksamhetstjänster: Student Utbildningsinformation Studiedeltagande Resultat Examenshantering Uppföljning 2.1 REST-tjänster I Ladok3 baseras tjänstegränssnitten på REST, istället för SOAP (T-tjänster i dagens Ladok), enligt de arkitekturella principer som tagits fram för Ladok3. Med REST får man en lösare koppling mellan systemen och därmed också 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 eftersom SOAP i sig är ett protokoll. REST utnyttjar istället grunderna i HTTP som ett applikationsprotokoll.

Bo Sehlberg, Jan Stenberg Sida: 6 (17) Varje verksamhetstjänst har ett antal REST-tjänster för att kunna hantera och komma åt den information dessa tjänster ansvarar för. 2.1.1 Omfattning En stor skillnad mellan dagens Ladok och Ladok3 är tillgången på tjänstegränssnitt. I dagens Ladok har vissa delar av systemet tillgängliggjorts via SOAP-tjänster. Däremot finns en omfattande funktionalitet (framförallt i Nouveau, som har sitt eget gränssnitt mot DB) som inte finns tillgänglig via dessa tjänstegränssnitt. Figur 1: Skillnad mellan dagens Ladok och Ladok3 med avseende på tjänstegränssnitt Användargränssnittet i Ladok3 använder sig av REST-tjänster för dialogen mot Ladok. Majoriteten av dessa REST-tjänster kommer även att vara åtkomliga för lärosätena. Detta betyder att Ladok3 kommer att tillhandahålla ett avsevärt större utbud av tjänstegränssnitt (REST/Atom feeds) än dagens Ladok gör genom SOAP. Förutom de REST-tjänster som användargränssnittet använder kommer det även att finnas ytterligare REST-tjänster som stöd för andra typer av maskin-till-maskin integrationer. 2.2 Händelsehantering Förändringar i en tjänst, t ex att en student registrerar sig på ett kurstillfälle resulterar i en händelse, med information om vad som hänt. Andra tjänster kan använda dessa händelser för att hålla sig uppdaterade om vad som hänt i andra tjänster. 2.2.1 Konceptuell beskrivning av Atom feed En händelse i en tjänst lagras av tjänsten och kan sedan hämtas av andra tjänster. Varje tjänst som behöver händelser från någon annan tjänst hämtar själv dessa händelser. Händelsehanteringen baseras på tekniken Atom feeds. 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.

Bo Sehlberg, Jan Stenberg Sida: 7 (17) Figur 2: Atom feed 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. En mottagen händelse i en tjänst ska endast vara för läsning. 2.2.2 Händelser direkt mellan tjänsterna I en tjänsteorienterad arkitektur ska tjänsterna vara oberoende av varandra. Därför är nedanstående scenario inte önskvärt: där tjänst A (studiedeltagande) är beroende av tjänst B (utbildningsinformation) för att fungera inte önskvärt. Scenarion som detta bör undvikas. Figur 3: Tjänster beroende av varandra Ladok3 är uppbyggt av ett antal tjänster, som ska vara oberoende av varandra (autonoma). Även om de ska fungera oberoende av varandra finns det ändå ett visst beroende som måste hanteras, för att undvika att en tjänst blir direkt beroende av att en annan tjänst är tillgänglig. Genom att använda händelsehantering kan tjänster informera varandra om vad som händer i systemet.

Bo Sehlberg, Jan Stenberg Sida: 8 (17) Istället för att göra tjänsterna beroende av varandra, kan man istället låta tjänst B publicera meddelande om händelser, som sedan tjänst A prenumererar på. När dessa händelser inträffar, lagrar tjänst A uppgifterna som den anser sig behöva. När tjänst A får en begäran är den då inte längre beroende av externa parter, i det här fallet tjänst B, för bearbetning, vilket gör tjänst A:s tillgänglighet opåverkad av B:s tillgänglighet. Figur 4: Tjänster oberoende av varandra genom händelseuppdaterad cache En nackdel med denna hantering är att delar av informationen blir dubbellagrad. Därför är det viktigt att man endast lagrar den information som är nödvändig förtjänstens funktion (oftast nycklar till olika objekt, på samma sätt som man i en databas har samma nyckel i flera tabeller). Man måste även ta hänsyn till uppstarts- och omstartsscenario, då man måste synkronisera informationen mellan Tjänst B och Tjänst A. 2.3 Användning på U/H Som lärosäte har man tillgång till både REST-tjänster och Atom feeds. REST-tjänster för att främst kunna hantera olika typer av interaktioner med Ladok3. Atom feeds för att ta emot händelser från Ladok3. Händelser kan t ex hålla en lokal metakatalog uppdaterad med information om t ex studenten och vilka kurser den deltar i för hantering av behörighet i lärplattformar, passersystem etc. 2.3.1 Händelser för U/H Händelser i Ladok3 för ett visst lärosäte hanteras på samma sätt som händelser mellan tjänster i Ladok3 (se 2.2). Det betyder att lärosätets system läser från de feeds där händelserna lagts upp av tjänsterna i Ladok3. 2.3.2 Tjänstegränssnitt för U/H De REST-tjänster som används av Ladok3:s användargränssnitt kommer i stor utsträckning att även kunna användas för integrationsändamål på lärosätena. Eftersom REST-tjänsterna ingår som en del i produktionsmiljön finns vissa begränsningar i användandet av dessa tjänster. Med undantag för REST-tjänsterna mot Uppföljningsdelen i Ladok3, är alla REST-tjänster främst ämnade för olika typer av system-till-system interaktion. Masshantering, motsvarande stora SQL-frågor, för att t ex uppdatera någon egen lokal lösnings databas, kommer inte att vara möjlig från Ladok3. Finns behov av större informationsuttag, används istället Uppföljningsdelen i Ladok3.

Bo Sehlberg, Jan Stenberg Sida: 9 (17) 3 Exempel på typer av tjänstegränssnitt Ladok3 kommer att tillhandahålla en omfattande uppsättning tjänstegränssnitt. I detta kapitel beskrivs exempel på några olika typer av tjänstegränssnitt som kommer att vara tillgängliga i Ladok3. Den exakta uppsättningen tjänster kommer att definieras successivt vartefter de olika tjänsterna utvecklas. Listan på tjänstegränssnitt kommer alltså att utökas allt eftersom nya funktioner utvecklas. 3.1 Studentuppgifter 3.1.1 Tjänstegränssnitt Registrera student Hämta/sök student 3.2 Utbildningsinformation 3.2.1 Tjänstegränssnitt 3.2.1.1 Kurs Skapa grund för kurs status 1 (utkast, grund) Ge kurs status 2 (förslag/inrättad, delgodkänd) Ge kurs status 3 (fastställd, beslutad, godkänd) Ge kurs status 4 (avvecklad/nedlagd) 3.2.1.2 Kurstillfälle Skapa grund för kurstillfälle status 1 (utkast, grund) Ge kurstillfälle status 2 (fastställd, beslutad, godkänd) Uppdatera kurstillfälle Ge kurstillfälle status 3 (godkänd för publicering) Lista kurstillfällen Ge kurstillfälle status 4 (inställd) 3.3 Studiedeltagande 3.3.1 Tjänstegränssnitt Förstagångsregistrera student Fortsättningsregistrera Omregistrera Lämna återbud Avbrott

Bo Sehlberg, Jan Stenberg Sida: 10 (17) 3.4 Resultat 3.4.1 Tjänstegränssnitt Skapa resultatlista Dokumentera resultat Klarmarkera resultatlista Signera resultatlista 3.5 Examenshantering 3.5.1 Tjänstegränssnitt Dokumentera att en student fått ett visst examensbevis utfärdat 3.6 Uppföljning 3.6.1 Tjänstegränssnitt Skapa årsredovisning. Hämta årsredovisning 4 Meddelanden från Ladok3 De olika tjänsterna kommer att skicka meddelanden och olika typer av händelser, som kan vara av intresse för andra tjänster och system. Den exakta uppsättningen av meddelanden kommer att definieras successivt vartefter de olika tjänsterna utvecklas. Listan på meddelandetyper kommer alltså att utökas allt eftersom nya funktioner utvecklas. 4.1 Studentuppgifter Student har blivit antagen på kurstillfälle Studentuppgift ändrad 4.2 Utbildningsinformation Ny kurs skapad Kursuppgift ändrad Nytt kurstillfälle skapat Kurstillfälle ändrat 4.3 Studiedeltagande Student har blivit förstagångsregistrerad på kurstillfälle Student har fortsättningsregistrerat sig på kurstillfälle Student har omregistrera på kurstillfälle

Bo Sehlberg, Jan Stenberg Sida: 11 (17) Student har lämna återbud på kurstillfälle Student har gjort avbrott på kurstillfälle 4.4 Resultat Student har fått resultat på kurs. 4.5 Examenshantering Student har fått examensbevis. 4.6 Uppföljning - 5 REST i Ladok3 Kapitlet beskriver principer för webbaserad kommunikation enligt REST-principen för Ladok3:s gränssnitt med andra tjänster och system. Det förutsätter en kännedom om principer för hur webben fungerar, inkluderande http, adressering via url:er och liknande samt grundprinciperna för REST. 5.1 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 informationsmängd som exponeras, för Ladok3 kan det till exempel vara en student eller en kurs. En resurs har en unik identitet och en adress, url, för åtkomst. I Ladok3 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. Ladok3 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 CRUDgrä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 Ladok3:s 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).

Bo Sehlberg, Jan Stenberg Sida: 12 (17) 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. Vi väljer därför REST som princip för Ladok3. 5.1.1 Tjänstegränssnitt Applikationer och system använder tjänstegränssnitten i Ladok3 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änstgränssnitten för att läsa information om studenters studiedeltagande, registrera studenter på kurstillfällen, registrera resultat osv. 5.1.2 Händelser Ladok3 är ett distribuerat tjänste- och händelsebaserat system där tjänster publicerar händelser på verksamhetsnivå, det kan till exempel vara att en student registrerat sig eller fått ett resultat på ett kurstillfälle. Dessa händelser lagras och är åtkomliga via REST-gränssnitt för andra tjänster och system. 5.1.3 Kompatibilitet 5.2 DAP 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/ Ett Domain Application Protocol, DAP, representerar ett domänspecifikt protokoll, i vårt fall ett Ladok3-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:

Bo Sehlberg, Jan Stenberg Sida: 13 (17) 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> 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. 5.3 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.

Bo Sehlberg, Jan Stenberg Sida: 14 (17) 5.3.1 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 Ladok3 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> Referens: http://www.ietf.org/rfc/rfc4287.txt 5.3.2 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 Ladok3 kan det användas i tjänstegränssnitten. Referens: http://www.ietf.org/rfc/rfc5023.txt

Bo Sehlberg, Jan Stenberg Sida: 15 (17) 5.4 DAP - Atom Grunden för våra två typer av gränssnitt är ett protokoll, DAP (se kap 5.2), specifikt för Ladok3. DAP kan sedan byggas på med ett Atom-baserat (se kap 5.3) format eller protokoll beroende på behovet. I Ladok3 kommer vi att använda båda varianterna enligt följande kapitel. 5.4.1 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. 5.4.2 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. 6 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 Ladok3 I Ladok3 baseras tjänstegränssnitten på REST, istället för SOAP, enligt de arkitekturella principer som tagits fram för Ladok3. 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 dagens Ladok använder ett XML-schema som utgår från den informationsmodell som finns i dagens Ladok. Eftersom Ladok3 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 informationsinnehå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. 6.1 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. SOAP

Bo Sehlberg, Jan Stenberg Sida: 16 (17) 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> 6.2 Begär studiedeltagande REST I REST begär man istället en resurs. REST GET /studiedeltagande/1234 HTTP/1.1 6.3 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 6.1 för att hämta nya uppgifter eller uppdatera någon uppgift. 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>

Bo Sehlberg, Jan Stenberg Sida: 17 (17) <m:tillstånd>ej_påbörjat</m:tillstånd> </m:getstudiedeltaganderesponse> </soap:body> </soap:envelope> 6.4 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 ). 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>