Det finns idag ett växande antal leverantörer på marknaden som anser sig leverera hård- och mjukvara för att tekniskt realisera en SOA. De olika leverantörernas ingående komponenter kan skilja sig åt gällande namn, definition och funktionalitet. Viss funktionalitet kan finnas i en komponent hos en leverantör men spänna över flera komponenter eller produkter och under ett annat namn hos en annan leverantör. Det gör det svårt att objektivt specificera vilka komponenter som ska eller bör ingå i en teknisk plattform för en SOA. OASIS (2006) exemplifierar med att vissa mjukvaru-leverantörer levererar sina registry- och repositoryprodukter som en enda produkt, vilket bidrar till en viss begreppsförvirring. Vi väljer därför att titta på den tekniska plattformens önskade egenskaper istället för att redogöra för alla de komponenter som kan eller bör ingå.
Lösa kopplingar mellan tjänster är en egenskap som benämns i litteraturen som fundamentalt viktig för att minska beroenden och öka flexibiliteten i en tjänste-orienterad arkitektur. Utan lösa kopplingar så försvinner hela syftet med en SOA (Erl, 2005). Skapandet av lösa kopplingar har möjliggjorts av olika tekniker, komponenter och öppna standarder så som exempelvis Enterprise Service Bus (ESB), SOA repository, SOA registry och Web Services (Hurwitz et al., 2007).
Pulier och Taylor (2006), Hurwitz et al. (2007) och Bieberstein et al. (2005) varnar alla för de säkerhetsproblem som kan förekomma i en SOA-miljö. En tjänste-orienterad arkitektur är till allra största del baserad på maskin till maskin kommunikation. IT-säkerhet, som annars vanligtvis grundas på människa – maskin är då inte tillämpbar. Exempelvis så kan identitetsverifiering och auktorisering bli en större utmaning i en SOA-miljö. Det är omöjligt att blockera obehörig användning av Web Services i en osäkrad SOA då de i grunden saknar möjlighet för att spåra vem som använder dem eller vem som har tillåtelse att använda dem. Det går heller inte att
hindra oönskad avlyssning av de meddelanden som skickas i en osäkrad SOA. Då arkitekturen av sin natur är öppen så är det svårare att säkra den mot oönskad överbelastning från både externa och interna kommunicerande system. En sådan överbelastning kan komma från illvilliga parter eller från system som omedvetet nyttjar tjänsten till en högre grad än vad den är avsedd för (Pulier & Taylor, 2006). Det finns dock både paketerade och anpassade säkerhetslösningar från leverantörer som potentiellt kan adressera alla de säkerhetsproblem som existerar. Det är viktigt för en organisation som planerar ett SOA-införande att identifiera de risker som finns och se över vilka säkerhetslösningar som passar och är nödvändiga för just deras arkitektur (Bieberstein et al., 2005; Pulier & Taylor, 2006).
Trots att Web Services inte är ett krav för att realisera en tjänsteorienterad arkitektur så är det denna öppna standard som har möjliggjort SOA:s ökande popularitet. De interface som Web Services använder består av standarder som i stort sett hela industrin stöder (Hurwitz et al., 2007; Pulier & Taylor, 2006). Enligt Erl (2005) så stödjer även Web Services kontrakt, lösa kopplingar, abstraktion och kombinerbarhet, vilka är egenskaper som gör Web Services till ett bra val att inkludera i sin plattform (Erl, 2005). Att implementera en teknisk plattform för SOA som inte stöder de öppna och allmänt accepterade standarderna kommer troligtvis leda till problem med kompatibilitet och interoperabilitet (Erl, 2005; Bieberstein et al., 2005).
Prestanda och tillförlitlighet i en tjänsteorienterad arkitektur kan vara kritiska parametrar för en organisation att ta hänsyn till. Valet av teknisk arkitektur kan ha stor påverkan på den övergripande kapaciteten för en SOA (Bieberstein et al., 2005). Web Services anses vara något långsamma på grund av sin tekniska uppbyggnad och kan därför kräva ökade hårdvaruresurser (Pulier & Taylor, 2006). Svarstiderna hos en Web Service är också beroende av de underliggande komponenterna, som kan bestå av en eller flera underliggande tjänster, applikationer och legacy-system. Svarstiderna hos de underliggande komponenterna kan var för sig vara acceptabla, men det är summan av alla ingående komponenters svarstider som avgör tjänstens prestanda (Hurwitz et al., 2007). På samma sätt som en tjänsts prestanda avgörs av de ingående komponenterna så påverkas även tjänstens tillförlitlighet (Erl, 2005). Om en tjänst exempelvis innehåller tio komponenter som var för sig har en uppskattad tillgäng-lighet på 99.9 procent, så har de tillsammans endast en tillgängtillgäng-lighet på 99 procent. Hurwitz et al. (2007) rekommenderar att följande aspekter bör beaktas och finnas tillgängliga som verktyg i anslutning till den tekniska plattformen:
• Övervakning av tjänstavtal (Service Level Agreement/SLA): Tjänsteavtal bör vara definierade för alla affärstjänster och vara möjliga att övervaka.
• Identifiering av fel och avbrott: Fel, avbrott och störningar i nätverket ska vara möjliga att analysera.
• Felhantering: Beroende på omständigheter och konfiguration så kan vissa fel mildras eller avhjälpas med automatik eller genom manuell hantering.
• Hantering av datorresurser: Lastbalansering och hantering av serverkluster bör vara möjlig.
• Prestandamodellering och optimering: Vissa produkter kan samla information om hur de ingående komponenterna belastas under olika omständigheter. Sådan information kan användas till att modellera olika sätt att använda nätverkets resurser och underlättar planering för framtida kapacitetsbehov.
• Rapportering: Det bör finnas verktyg för att samla relevant information om prestanda, driftstörningar och andra relevanta parametrar.
Pulier och Taylor (2006) rekommenderar organisationer att se över och inventera sin existerande kunskapsnivå bland dem som kan bli involverade i ett SOA-projekt. När det gäller val av teknisk plattform så är det främst utvecklare, både interna och externa, som blir påverkade av valet. Det finns ett flertal olika leverantörer på marknaden idag som levererar lösningar riktade mot SOA-utveckling De bygger vanligen på utveckling med .NET eller Java. För att få bästa produktivitet bör organisationer utvärdera vilka utvecklingsverktyg och programspråk som passar deras organisation. Parametrar att beakta vid en sådan utvärdering är: befintlig kunskap, erfarenhet, användarvänlighet och produktivitetshöjande finesser i verktygen. Det är vanligt att organisationer som står inför ett SOA-projekt tar hjälp av externa resurser i form av konsulttjänster. Det rekommenderas då att låta den externa resursen vara delaktig i valet av tekniska lösningar (Pulier & Taylor, 2006).
5 Resultat och diskussion
I detta kapitel redovisas resultatet från de sex intervjutillfällen som genomförts för studien. Inledningsvis ges en kort beskrivning av respondenterna och de företag de representerar. Resultatet kommer sedan att redovisas faktor för faktor, för att följas av en diskussion om respektive faktor. Det gavs svar på i stort sett varje faktor i varje intervju, men i vissa fall gavs inte mer information än det som presenterats av oss. I de fall då inget svar redovisas från en respondent hade den personen inte något extra att tillägga. Avslutningsvis redovisas hur respondenterna rangordnat de fyra skikten.