Arkitektur

Med arkitektur avses strukturen hos ett (data)system. Det innebär att systemets uppbyggnad beskrivs i form av komponenter samt hur dessa samverkar med varandra. Till detta fogas även de principer som styr den aktuella struktureringen.	Innehåll: >> Vad är arkitektur Komponenter och tjänster Tjänster och arkitektur Praktikfall Framgångsfaktorer Vidare läsning

Komponenter och tjänster

För att till fullo förstå ett systems arkitektur fordras att den beskrivs ur flera synvinklar. Detta kan ske med olika modeller, exemplevis komponenternas inbördes förhållande (en statisk modell) eller deras samverkan (dynamisk modell, flöden).

En komponentmodell (statisk) fokuserar på ett systems uppdelning i funktioner och hur dessa fördelats mellan ett antal samverkande enheter. Komponenterna inkapslar var för sig sina egna data med tillhörande funktioner på i stort sett samma sätt som för objektorientering. Komponenter är dock mer omfattande än objekten inom objektorientering.

Ett annat sätt att se på samma system är att följa ett flöde genom systemet (dynamisk). De olika komponenterna ger var för sig sitt bidrag till flödet genom att de utför någon delfunktion. Man kan då se flödet som en kombination av tjänster som levereras av de medverkande komponenterna. Att se på komponenter som leverantörer av tjänster flyttar fokus från komponentens funktionsinnehåll till vad den kan leverera till omgivningen i form av tjänster. Detta kan tyckas som en subtil skillnad, men flyttar intresset på ett avgörande sätt från komponentens innehåll till dess gränssnitt mot omgivningen. Det är detta synsätt som är grunden för en tjänsteorienterad arkitektur.

Figuren illustrerar skillnaden mellan objekt, komponenter och tjänster i en arkitektur.

Tjänster och arkitektur

I en arkitektur baserad på tjänster flyttas intresset från hur komponenterna (eller snarare tjänsteleverantörerna) är implementerade till hur man kan nå tjänsterna. Kommunikation och samverkan blir nu den tekniska utmaningen.

Det är i detta perspektiv man får se det stora intresset för Web Services. Det är nämligen en teknisk lösning på detta problem. Web Services erbjuder möjligheter att söka, identifiera och anropa tjänster i en heteroge n teknisk miljö. I princip blir det nu möjligt att kombinera tjänster till mer komplexa flöden, som med relativt ringa ansträngning kan konfigureras efter behov. Denna teknik är dock ännu relativt ny och oprövad. Det finns flera betydande tekniska svårighe ter som ännu inte är helt lösta.

Praktikfall

Genom besök hos de medverkande företagen har projektdeltagarna fått tillfälle att studera och diskutera hur respektive företag närmat sig tekniken med Web Services.

För uförligare beskrivning av praktikfallen i form av PDF-dokument klicka på respektive företagsnamn.

Dokumenterade praktikfall:
- SEB Trygg Liv (beskrivs kort nedan)
- SAS (beskrivs kort nedan)
- AMF Pension
- Sandvik (beskrivs kort nedan)
- Volvo IT
- Skatteverket

Nedan beskrivs de företag som har kunnat uppvisa en relativt stor satsning på Web Services. Den samlade bilden pekar dock mot en ganska blygsam användning och i flera fall en anvävändning som befinner sig endast på försöksstadiet. Trenden är dock att man aktivt planerar för en ökad användning och ser stora fördelar med tekniken. Användningen är både för extern och intern samverkan.

SEB Tyggliv

SEB har sedan länge arbetat med en komponentbaserad arkitektur för sina IT-system. Den består bl a av tre fundamentala skikt nämligen kanaler, affärslogik och resurser. Detta är en vidareutveckling av den konventionella uppdelningen av program i presentation, logik och data.

Ett område som SEB valt för att tillämpa Web Services är integration med externa samarbetsparter. I detta fall rör det sig om att ge externa försäkringsmäklare tillgång till ett internt system. Detta har man hanterat genom att skapa ett meddelandehanteringssystem, EXA, för säkert meddelandeutbyte mellan mäklarna och SEB. EXA skickar meddelanden vidare till interna system.

Uppgiften för meddelandehanteraren är att identifiera och förmedla in- och utgående trafik. Ett problem är att ett inkommande meddelanden kan resultera i att flera meddelanden behöver sändas till interna system.

Läs mer om SEB Tryggliv >>

SAS

Inom SAS var man tidigt ute och experimenterade med Web Services. Redan 2001 hade SAS en av de första Web Services i världen som använde sig av UDDI. För närvarande använder man Web Services dels internt inom flera områden, bl a incheckning och marknadsföring, och dels externt för en bokningstjänst. Denna senare tjänst riktar sig till befintliga kunder med speciella avtal, t ex resebyråer.

Ur ett arkitekturperspektiv är SAS intressant därför att man har definierat ett gränssnitt, SAPI (Self booking API), som består av en uppsättning publika tjänster som förmedlar åtkomst till redan befintliga tjänster i de interna systemen. Vid utformningen av den externa tjänsten har man byggt vidare på de interna tjänster som ingår i incheckningssystemet. Dessa är i sin tur påbyggnader med hjälp av Web Services på det befintliga bokningssystemet, som körs i en Unisysmiljö. Finessen är att man inte ändrat i det gamla systemet utan enbart litat till befintliga gränssnitt. Med hjälp av dessa gränssnitt har SAS med små resurser byggt skräddarsydd bokningstjänster åt olika kunder.

Läs mer om SAS >>

Sandvik

Sandvik är det företag bland praktikfallen som kommit längst i sin användning av Web Services. Bland de faktorer som bidragit till detta kan nämnas:
· En global organisation med krav på systemsamverkan
· Krav på standardiserad kommunikation med dotterbolag och underleverantörer.

Sandvik har valt ett integrationsnav som kärnan i sin arkitektur. Navet är baserat på Micrsosoft Biztalk och föds med meddelanden från en meddelandeserver (IBM MQ) som bildar en fasad mot externa användare. För samverkan mellan fasaden och navet används SOAP.

Sandvik använder Web Service tekniken i flera system. Denna spridda användning har lett till att tre olika angreppssätt på tjänstedesign har använt s, varje angreppssätt är anpassat för en viss situation.

Läs mer om Sandvik >>

Några slutsaser

Baserat på en analys av praktikfallen kan det konstateras att Web Services grundläggande teknik fungerar väl. De initiala problemen med användning av de grundläggande teknikerna WSDL och SOAP är lösta. XML har etablerat sig som en grund för att beskriva meddelanden. När allt fler organisationer vill använda tekniken för att integrera system över organisationsgränser så
uppkommer dock andra problem. Framförallt behöver arkitektur och utveckling samt driftsättning och övervakning av Web Services anpassas för att hantera en större mängd
tjänster. Dagens hantering räcker endast till för ett fåtal tjänster.

Framgångsfaktorer

En genomgång av företagens erfarenheter kring Web Servies tillsammans med en litteraturstudie på området har resulterat i en idenitifiering av ett antal framgångsfaktorer i samband med en användning av Web Services. Nedan presenteras några exempel:

· Välj kunniga utvecklare för att kunna komplettera med egna lösningar där valda produkter inte räcker till. Arbeta i små grupper.

· Börja med begränsade funktioner som inte är verksamhetskritiska.

· Ta fram en vision av hur den framtida arkitekturen bör se ut.

· Skapa en gemensam ingång mot bakomliggande system.

· Låt inte generella funktioner som säkerhet och loggning hamna i tjänsterna utan placera dem som en del av infrastrukturen.

· Meddelandedefinitioner kräver medverkan av verksamhetskunnig personal. Var nöjd med tillräckligt bra meddelanden. Sök inte den perfekta lösningen.

Vidare läsning

Vill du läsa mer om SOA arkitektur finns följande rapporter från Serviam att ladda ner och läsa:

Henkel, M., 'Serviam Literature Survey Part III - Web Service Design'

Externa länkar:

http://www.webservicesarchitect.com >>

http://www.ibm.com/developerworks/webservices >>