Coulouris definerede distribuerede systemer som "systemer, hvor hardware- og/eller softwarekomponenter, der findes i et computernetværk, kommunikerer og koordinerer deres handlinger ved at udveksle meddelelser".
Dette koncept er blevet populært i de senere år på grund af flere faktorer. Den første faktor, der fremmede udviklingen af distribuerede systemer, var fremkomsten af højhastigheds-lokalnetværk. En anden vigtig faktor var det teknologiske fremskridt i ydeevnen af personlige computere og udviklingen af software til at understøtte distribuerede applikationer. Distribuerede systemer er knyttet til konceptet om internettet og internettet. Med udviklingen af nettet og fremkomsten af nye områder, interaktioner, behov og applikationer dukker konceptet Web 2.0 op. Dette udtryk blev opfundet af Tim O'Reilly i 2004 for at henvise til en anden generation i internettets historie baseret på brugerfællesskaber og en særlig række tjenester, såsom sociale netværk, blogs, wikier eller folksonomier, der tilskynder til samarbejde og hurtig udveksling af information mellem brugere.
De første arkitekturer, der kan betragtes som serviceorienterede (SOA) var baseret på CORBA (Common Object Request Broker Architecture), som fungerede som et abstraktionslag til at forbinde de forskellige elementer i arkitekturen og bygge tjenester. Andre tidligere teknologier var DCOM (Distributed Component Object Model) eller RPC (Remote Procedure Protocol). Med behovet for effektivt at designe og implementere distribuerede systemer på nettet, opstår der flere udfordringer, nogle med fokus på selve udviklingen (ydelse, brugeroplevelse osv.) og andre komplementære, baseret på genanvendelighed og kompatibilitet af tjenester. Ud fra disse behov opstår Web Services, som giver standardiserede mekanismer til at forbinde forskellige brugere med informationsservere.
SERVICEORIENTERET ARKITEKTUR
Ifølge SOA (Service Oriented Architecture) er softwarearkitekturer, der definerer brugen af tjenester til at understøtte forretningskrav, hvis mål er at opnå den mindst mulige kobling mellem softwareagenter. En service er en arbejdsenhed, der udføres af en tjenesteudbyder for at opnå et slutresultat, som en serviceforbruger ønsker. Både serviceudbyder og serviceforbruger er roller, der spilles af softwareagenter, ikke softwareejere. I en generel forstand er en serviceorienteret arkitektur en softwareløsning, der skal gøre det muligt for en virksomhed at organisere og gøre brug af forskellige processer. Med SOA er softwareapplikationer ikke længere massive blokke af funktioner og processer. I stedet består disse applikationer af samlede modulære tjenester. Husk, at en tjeneste er en simpel softwarefunktion (som at annullere en cd). Det kan køres efter behov af ethvert system, uanset operativsystem, platform, programmeringssprog eller geografisk placering.
Det revolutionerende ved SOA er ikke selve konceptet, som har eksisteret længe, men det faktum, at det kan implementeres over WWW (World Wide Web). På samme måde som websider indlæses på enhver platform, fungerer webtjenester på samme måde uanset platform, da de er bygget vha.
universelle standarder.
Ideen om SOA stammer direkte fra objektorienteret programmering, som antyder et forhold mellem data og dets behandling. Således definerer de formelt tjenester gennem grænseflader, der er uafhængige af den underliggende platform og programmeringssprog. Disse grænseflader skjuler de særlige kendetegn ved deres implementering, hvilket gør dem uafhængige af udvikler- og programmeringssprog. Gennem disse arkitekturer er det muligt at designe og implementere yderst skalerbare systemer, der afspejler forretningslogikken og samtidig faciliterer interaktionen mellem forskellige proprietære eller tredjepartssystemer. Grunden til, at vi vil have en anden til at gøre arbejdet for os, er fordi de er eksperter. At bruge en tjeneste er normalt billigere og mere effektivt end at gøre det selv. Så de fleste af os forstår, at vi ikke kan være eksperter i alt. Den samme regel kan anvendes til at bygge softwaresystemer.
Grænseflader er meget vigtige, hvis de ikke er veldefinerede eller ikke virker, fungerer systemet ikke. Det er dyrt at integrere flere grænseflader og øger også risikoen for fejl i distribuerede applikationer. Fjerngrænseflader er den langsomste del af de fleste distribuerede applikationer. Med alt dette, i stedet for at bygge nye grænseflader til hver applikation, giver det mere mening at genbruge generiske grænseflader til alle applikationer.
Så da vi kun har få generiske grænseflader til rådighed, skal vi inkludere applikationsspecifik semantik i meddelelserne. Vi kan sende enhver form for besked gennem vores grænseflader, men der er nogle regler, der skal følges for at sige, at en arkitektur er serviceorienteret.
– For det første skal beskederne være beskrivende, ikke vejledende, da tjenesteudbyderen er ansvarlig for at løse problemet. For eksempel ville det svare til situationen med at gå på restaurant og fortælle tjeneren, hvad du gerne vil drikke og dine præferencer, men vi skal ikke forklare kokken, hvordan du tilbereder dine retter trin for trin.
‐ For det andet vil tjenesteudbydere ikke være i stand til at forstå din anmodning, hvis deres meddelelser ikke er skrevet i et format, en struktur og et ordforråd, som alle involverede kan forstå. Det er således en begrænsning af ordforrådet og strukturen af meddelelser
nødvendig for effektiv kommunikation. Jo snævrere budskabet er, jo lettere at forstå.
- For det tredje er muligheden for forlængelser af vital betydning. Verden er et sted i konstant forandring, og det samme er miljøet, som software lever i. Disse ændringer kræver tilsvarende ændringer i systemsoftware, forbrugere af tjenester, udbydere og de beskeder, de udveksler. Hvis beskeder ikke kan udvides, er forbrugere og udbydere låst til en bestemt version af tjenesten. Begrænsninger og udvidelsesmuligheder er dybt relaterede, du har brug for begge dele, og at øge det ene betyder at reducere det andet. Det ideelle er at opnå en korrekt balance.
– For det fjerde skal en SOA have en mekanisme, der gør det muligt for forbrugeren at finde en tjenesteudbyder i forbindelse med en tjeneste, som forbrugeren efterspørger. Mekanismen bør være fleksibel og ikke et centraliseret register.
- For det femte, statsløs tjeneste: Hver besked, som en forbruger sender til en udbyder, skal indeholde alle de oplysninger, der er nødvendige for, at udbyderen kan behandle den. Denne begrænsning gør en tjenesteudbyder mere skalerbar, da udbyderen ikke behøver at gemme tilstandsoplysninger mellem anmodninger. Dette kan kaldes en "masseproduktionsservice", da hver anmodning kan håndteres generisk. Denne begrænsning giver også mere synlighed, da enhver overvågningssoftware uafhængigt kan inspicere en anmodning og udtrække dens hensigt. Dette giver også mulighed for nem genopretning fra delvise fejl, da der ikke er nogen mellemtilstande, hvilket gør tjenesten mere pålidelig.
- For det sjette, idempotente anmodninger (uden ændringer): duplikerede anmodninger modtaget af en softwareagent har samme effekt som en enkelt anmodning. Dette krav giver udbydere og forbrugere mulighed for at øge den overordnede pålidelighed af service ved blot at gentage anmodningen, hvis der var nogen fejl.
Så vi kan sige, at SOA ikke er et værktøj, men et sæt standarder til at bygge nye applikationer, mere dynamiske og mindre afhængige. SOA letter adgangen til forretningslogik og information på tværs af flere tjenester på en systematisk måde og kan også orkestrere flere fjerntjenester til at sammensætte en enkelt. mest af definitionerne identificerer brugen af Web Services, som vi vil se i næste kapitel, i implementeringen af en serviceorienteret arkitektur. Det kan dog implementeres ved hjælp af enhver anden servicebaseret teknologi.