Exempel på SOA tillämpning

I projektet Serviam har konceptet tjänsteorienterade arkitekturer utforskats och belysts från olika perspektiv: säkerhet, arkitektur, affärsnytta och förvaltning. I litteraturen finns många löften om vad SOA och framför allt webbtjänster innebär och bringar. Däremot finns få empiriska bevis på att detta fungerar.	Innehåll: >> PoC - syfte Om systemet Aktiviteter Slutsatser Problem & rekommendationer Ladda ner rapporten

Proof of Concept - syfte

Inom ramen för Serviams andra år utvecklades ett proof of concept, för att visa på hur det kan fungera att få till en webbtjänst mellan två organisationer med vilka problem etc som kan uppstå under processen. De två inblandade ”organisationerna” är SEB och Stockholms Universitet/KTH. I den sistnämnda var ”organisationen” ett fiktivt möbelföretag med möjlighet att beställa via webben.

Systemet har enligt en överenskommelse mellan sammarbetspartners tagits bort efter avslutat projekt och är inte längre tillgängligt.

Om systemet

Huvudfunktionen hos SEBs Web Service är att den ska kunna hantera kortbetalning på en e-handelsplats (i detta fall ITea). Kunden anger sitt kortnummer som kontrolleras och om kortet är godkänt samt om beloppet godkänns uppdateras kundens disponibla belopp. Annars, om kortet ej finns eller om köpbeloppet är för högt, ska kunden få ett meddelande om att kortköpet ej kan genomföras.

Ett antal frågor som kommer upp i samband med en utvecnling är:

1. Hur ska Web Services designas så att motsvarar verksamhetsprocessen, det vill säga i viken ordning ska metoderna anropas samt vilken data ska tas emot och skickas.

2. Hur skyddar man den känsliga informationen som faktiskt skickas i samband med utnyttjandet av tjänsten?

3. Hur ska klienten designas så att den kan anropa SEBs Web Service?

Läs en detaljerad beskrivning av systemet och dess funktioner här >>

Aktiviteter

Proof of concept - aktivitetsmodell:

1.1 Framtagning av Processmodell

Mycket av arbetet skedde i form av diskussioner, där frågorna rörde sig kring dels vilka krav ITea ställde på SEBs Web Service (in- och utparametrar, vad tjänsten skulle göra), samt dels hur länkar mellan parterna skulle specificeras. Respektive aktör gjorde en modell över sin del av samverkan, enligt överenskomna variabler och processlogik, samt med överenskommet BPEL-verktyg.

Titta på den färdiga processmodellen >>

1.2 Säkerhetsrekommendationer

För att kunna bestämma lämplig säkerhetsnivå studerades först möjligheterna i standarden Web Services Security, följt av framtagning av två alternativa säkerhetslösningar. I detta fördes diskussioner kring vad i standarden som redan stöttas hos SEB med tanke på befintlig teknik och lösningar.

2. Design av Web Service gränssnittet

Baserat på den utförda processmodelleringen skapades ett gränssnitt för Web Servicen, där operationerna specificerades. Därefter designades implementationsklasser för SEBs tjänster, innan de implementerades genom kodning i Java.

Tekniska gränssnittet för SEBs Web Service >>

3.1 Utveckling av WS klienten

Från ITeas sida utvecklades och testades klienten enligt specifikationerna, först utan Web Services Security. Därefter gjordes en utökning till att även innefatta standarden.

Mer om klienten >>

3.2 Utveckling och implementation av WS hos SEB

Inom SEB togs ett kravdokument fram. Olika SOAP-implementationer studerades innan Axis valdes framför WebSphere. Till Axis valdes WSS4J. Efter detta uppkom problem med SOAP-implementationen, och beslut fattades att byta till WebSphere. Den grundläggande Web Servicen utökades med ett gränssnitt, vilket inkluderade ett deploymentdiagram och en plattformsbeskrivning. Från Web Services Security lades user name password token profile på. Samtidigt med detta utvecklades också en intern miljö för att deploya Web Servicen på inom SEB.

4. Realisering och testning

Under realiseringen upptäcktes ett fel i logiken. Detta föranledde felsökning i koden. Efter att felet korrigerats gjordes en ny provkörning/deployment.

5. Avrapportering

Information samlades in från samtliga aktörer i projektet, både genom möten och genom insamling av dokumentation av arbetet enligt en förberedd mall.

Slutsatser

Slutsatserna kan delas in i tre delar: säkerhet, teknik och utvecklingsprocess.

Säkerhet
Även om dagens utvecklingsmiljöer ofta hävdar stöd för standarden WSS är inte detta alltid fallet. Ett exempel är ”stöd” för aspekter i WSS roadmap som ännu inte är fullt standardiserade. Konsekvensen kan bli olika implementationer och tolkningar av WSS i olika miljöer, och standarden är då inte längre en standard. Kompatibiliteten kan då ifrågasättas.

Teknik
Enbart WSDL fungerar rent tekniskt. Komplexiteten kommer in på två nivåer, dels tekniskt med UDDI, och dels affärsmässigt med avtalsbiten. Vision och verklighet matchar inte ännu till 100%, eftersom det inte är så lätt som det utger sig från att vara.

Utvecklingsprocess
Olika valsituationer behöver hanteras under utveckling och design av Web Services. Exempel är processgranularitet; specificering av processimplementationer; top-down eller bottom-up-ansats; fel- och transaktionshanteringsprocedurer att definiera; m.m. Utvecklingsprocessen kan komma att innebära nya typer av problem.

Problem och rekommendationer

Detta kapitel innehåller en beskrivning av olika problem som uppkom under arbetets gång. Dessa problem har delats upp i fyra delar: säkerhetsproblem, begreppsproblem, implementation och system, samt processrelaterade problem.

Säkerhetsproblem
Säkerhetsproblem relaterar antingen till standarden (Web Services Security – WSS) i sig eller till arbetet med att implementera densamma. Det betyder att det antingen var tidsfaktorn som spelade in, eller olikheter i WSS-specifikationerna kontra SEBs respektive ITeas utvecklingssmiljöer.
Värt att nämna är att inga problem upplevdes som större, utan det som framkommit var förväntade problem. En bra dialog mellan inblandade parter har medfört att de lösningar som tagits fram är till belåtenhet för alla.

Rekommendationer:

Undersök hur befintliga arkitekturer, principer och beslut gällande säkerhet påverkar möjligheten att använda och implementation av t.ex. WS Security. Utveckling av en bra säkerhetslösning kräver tid.

Mer om säkerhetsproblem samt rekommendationer>>

Begrepp
När företag ska samarbeta krävs att de är överens om innebörden i en del centrala begrepp. Om inte detta görs kan både personal och system missförstå varandra och fel uppstå. I PoC har inte begreppsförvirring varit ett stort problem. Det enda begrepp som gav upphov till viss förvirring mellan SEBs och ITeas system var ”Kort-ID”, framför allt gällande vad som skulle ingå i det (enligt SEBs krav). Det blev mycket trial-and-error, trots att tanken med denna typ av arkitektur är att det ska gå enkelt att göra utan beskrivningar. Sådant behövs dock i praktiken, t.ex. för att inparametrar inte syns i WSDL-filer. Kontentan är att det krävs en gemensam terminologi när man arbetar tillsammans för att inter-organisatoriskt samarbete ska fungera.

Rekommendationer:

För att Web Services ska fungera i den befintliga miljön bör WSDL-filen för alla Web Services som utvecklats av andra parter studeras för att utröna hur centrala begrepp definieras. För att säkerställa en gemensam begreppsapparat i B2B-sammanhang bör en gemensam begreppsanalys genomföras för att undvika tvetydigheter.

Mer om begreppsproblem samt rekommendationer>>

Implementationssystem
Detta var den största kategorin av problem och den kan delas in i två delar: tidsaspekten, samt systemkomplexitet och kompatibilitetsproblem. Vad gäller tidsaspekten så tog det tid att dels hitta en utvecklingsmiljö som var optimal för den utvecklingsmiljö som SEB använder i övrigt i sin verksamhet och dels optimalt för säkerhetstillägget Web Service Security. Systemkomplexiteten blev ett hinder vid första valet av utvecklingsmiljö - WebSphere - som visade sig vara alldeles för nytt och odokumentarat. WebSphere applikationsserver (som användes) var dessutom inte kompatibelt med open source Apache AXIS som användes för själva Web Services tillämpningen, det vill säga hanteringen av SOAP-meddelanden.

Rekommendationer:

Valet av SOAP-implementation är inte trivialt och analys av alternativ bör göras grundligt för att undvika problem i senare skeden. Web Services-tekniken lider fortfarande av barnsjukdomar och kräver sålunda en viss ansträngning för att fungera. Arkitekturer, policybeslut, med mera, behöver ses över för att avgöra hur de påverkar skapandet och användningen av Web Services.

Mer om implementationen samt rekommendationer >>

Processen
De processrelaterade problemen hänrör sig till övergången från BPMN-beskrivningen till en exekverbar BPEL4WS-process. Det betyder att det handlar om processmodelleringsspråk snarare än om processerna själva. Detta inkluderar även många tekniska bekymmer, som integrering av Web Services som utvecklats på olika plattformar med verktyget för BPEL4WS som använts. Nuvarande resultat är att processen fungerar – om än i sin mest grundläggande form (utan felhanteringsprocedurer). Orsaken är att tiden inte räckt till för att lägga till ytterligare funktioner och procedurer.

Rekommendationer:

Verktyg för exekverbara processer i BPEL4WS brottas fortfarande med tekniska bekymmer, vilket kan försvåra och försena övergången till sådana verktyg.

Mer om processrelaterade problem samt rekommendationer >>

Proof of Concept rapporten

Ladda ner och läs dokumentationen av hela arbetsgången från planering till realisering av SEB Web Services och en Web Service klient - problemdiskussion, rekommendationer samt systembeskrivningar. I bilagorna finns specifikationer och kodexempel.

Proof of Concept >>