Coulouris definierade distribuerade system som "system där hårdvaru- och/eller mjukvarukomponenter som finns i ett datornätverk kommunicerar och koordinerar sina handlingar genom att utbyta meddelanden".
Detta koncept har blivit populärt de senaste åren på grund av flera faktorer. Den första faktorn som främjade utvecklingen av distribuerade system var uppkomsten av snabba lokala nätverk. En annan viktig faktor var tekniska framsteg i persondatorers prestanda och utvecklingen av mjukvara för att stödja distribuerade applikationer. Distribuerade system är kopplade till konceptet webb och internet. Med webbens utveckling, och framväxten av nya områden, interaktioner, behov och tillämpningar, växer konceptet Web 2.0 fram. Denna term myntades av Tim O'Reilly 2004 för att hänvisa till en andra generation i webbens historia baserad på användargemenskaper och ett speciellt utbud av tjänster, såsom sociala nätverk, bloggar, wikis eller folksonomier, som uppmuntrar samarbete och smidighet utbyte av information mellan användare.
De första arkitekturerna som kan betraktas som tjänsteorienterade (SOA) var baserade på CORBA (Common Object Request Broker Architecture), som fungerade som ett abstraktionsskikt för att koppla ihop arkitekturens olika delar och bygga tjänster. Andra tidiga tekniker var DCOM (Distributed Component Object Model) eller RPC (Remote Procedure Protocol). Med behovet av att designa och implementera distribuerade system på webben effektivt uppstår flera utmaningar, några fokuserade på själva utvecklingen (prestanda, användarupplevelse etc.) och andra kompletterar, baserat på tjänsters återanvändbarhet och kompatibilitet. Ur dessa behov uppstår webbtjänster, som tillhandahåller standardiserade mekanismer för att koppla samman olika användare med informationsservrar.
SERVICERITERADE ARKITEKTURER
Enligt SOA (Service Oriented Architecture) är de mjukvaruarkitekturer som definierar användningen av tjänster för att stödja affärskrav, vars mål är att uppnå minsta möjliga koppling mellan mjukvaruagenter. En tjänst är en arbetsenhet som utförs av en tjänsteleverantör för att uppnå ett slutresultat som en tjänstekonsument önskar. Både tjänsteleverantör och tjänstekonsument är roller som spelas av mjukvaruagenter, inte deras ägare. I en allmän mening är en tjänsteorienterad arkitektur en mjukvarulösning som är avsedd att göra det möjligt för ett företag att organisera och använda olika processer. Med SOA är programvaruapplikationer inte längre stora block av funktioner och processer. Istället består dessa applikationer av sammansatta modulära tjänster. Kom ihåg att en tjänst är en enkel mjukvarufunktion (som att avbryta uppspelning på en CD). Det kan köras på begäran av alla system, oavsett operativsystem, plattform, programmeringsspråk eller geografisk plats.
Det som är revolutionerande med SOA är inte själva konceptet, som har funnits länge, utan det faktum att det kan implementeras via WWW (World Wide Web). Precis som webbsidor laddas på vilken plattform som helst, fungerar webbtjänster på liknande sätt oavsett plattform som de är byggda med
universella standarder.
Idén med SOA härrör direkt från objektorienterad programmering, vilket antyder ett förhållande mellan data och dess bearbetning. Således definierar de formellt tjänster genom gränssnitt som är oberoende av den underliggande plattformen och programmeringsspråket. Dessa gränssnitt döljer särdragen i deras implementering, vilket gör dem oberoende av utvecklare och programmeringsspråk. Genom dessa arkitekturer är det möjligt att designa och implementera mycket skalbara system som speglar affärslogik och som samtidigt underlättar interaktion mellan olika proprietära eller tredjepartssystem. Anledningen till att vi vill att någon ska göra jobbet åt oss är för att de är experter. Att använda en tjänst är generellt sett billigare och effektivare än att göra det själv. Så de flesta av oss förstår att vi inte kan vara experter på allt. Samma regel kan tillämpas på att bygga mjukvarusystem.
Gränssnitt är extremt viktiga, om de inte är väldefinierade eller inte fungerar så fungerar inte systemet. Att integrera fler gränssnitt är dyrt och ökar också risken för fel i distribuerade applikationer. Fjärrgränssnitt är den långsammaste delen av de flesta distribuerade applikationer. Med allt detta, istället för att bygga nya gränssnitt för varje applikation, är det mer meningsfullt att återanvända generiska gränssnitt för alla applikationer.
Så eftersom vi bara har ett fåtal generiska gränssnitt tillgängliga måste vi inkludera applikationsspecifik semantik i meddelandena. Vi kan skicka alla typer av meddelanden genom våra gränssnitt, men det finns några regler som ska följas för att säga att en arkitektur är tjänsteorienterad.
– För det första måste meddelanden vara beskrivande, inte instruktiva, eftersom tjänsteleverantören ansvarar för att lösa problemet. Det skulle till exempel likna situationen att gå till en restaurang och berätta för servitören vad du skulle vilja dricka och dina preferenser, men vi bör inte förklara för kocken hur man lagar dina rätter steg för steg.
‐ För det andra kommer tjänsteleverantörer inte att kunna förstå din begäran om deras meddelanden inte är skrivna i ett format, en struktur och ett ordförråd som är begripligt för alla inblandade. Att begränsa ordförrådet och strukturen för meddelanden är alltså en
nödvändig för effektiv kommunikation. Ju mer begränsat budskapet är, desto lättare är det att förstå.
‐ För det tredje är möjligheten till förlängningar av avgörande betydelse. Världen är en plats i ständig förändring, och det är också miljön där programvaran lever. Dessa ändringar kräver motsvarande ändringar av systemprogramvaran, konsumenterna tjänster, leverantörer och de meddelanden de utbyter. Om meddelanden inte kan utökas kommer konsumenter och leverantörer att vara låsta till en specifik version av tjänsten. Begränsningar och utvidgningsmöjligheter är djupt relaterade, du behöver båda, och att öka det ena innebär att minska det andra. Idealet är att uppnå en korrekt balans.
– För det fjärde måste en SOA ha en mekanism som gör det möjligt för konsumenten att upptäcka en tjänsteleverantör inom ramen för en tjänst som konsumenten efterfrågar. Mekanismen måste vara flexibel och får inte vara ett centraliserat register.
‐ Femte, statslös tjänst: Varje meddelande som en konsument skickar till en leverantör måste innehålla all information som krävs för att leverantören ska kunna behandla det. Denna begränsning gör en tjänsteleverantör mer skalbar eftersom leverantören inte behöver lagra tillståndsinformation mellan förfrågningar. Detta kan kallas en "massproduktionstjänst" eftersom varje förfrågan kan hanteras generiskt. Denna begränsning ger också mer synlighet, eftersom alla övervakningsprogram kan inspektera en oberoende begäran och extrahera dess avsikt. Detta möjliggör också enkel återställning från partiella fel eftersom det inte finns några mellanliggande tillstånd, vilket gör tjänsten mer tillförlitlig.
‐ För det sjätte, idempotenta förfrågningar (som inte gör ändringar): dubbletter av förfrågningar som tas emot av en mjukvaruagent har samma effekt som en enskild begäran. Detta krav gör det möjligt för leverantörer och konsumenter att öka den övergripande tillförlitligheten av tjänsten, bara upprepa begäran om något fel har inträffat.
Så vi kan säga att SOA inte är ett verktyg, utan snarare en uppsättning standarder för att bygga nya, mer dynamiska och mindre beroende applikationer. SOA underlättar åtkomst till affärslogik och information mellan olika tjänster på ett systematiskt sätt, och kan även orkestrera flera fjärrtjänster till en enda. Majoriteten av Definitionerna identifierar användningen av webbtjänster, som vi kommer att se i nästa kapitel, vid implementeringen av en tjänsteorienterad arkitektur. Det kan dock implementeras med vilken annan tjänstebaserad teknik som helst.