Coulouris definerte distribuerte systemer som "systemer der maskinvare- og/eller programvarekomponenter som eksisterer i et datanettverk kommuniserer og koordinerer sine handlinger ved å utveksle meldinger".
Dette konseptet har blitt populært de siste årene på grunn av flere faktorer. Den første faktoren som fremmet utviklingen av distribuerte systemer var fremveksten av høyhastighets lokalnettverk. En annen viktig faktor var det teknologiske fremskritt i ytelsen til personlige datamaskiner og utviklingen av programvare for å støtte distribuerte applikasjoner. Distribuerte systemer er knyttet til konseptet web og internett. Med utviklingen av nettet, og fremkomsten av nye områder, interaksjoner, behov og applikasjoner, dukker konseptet Web 2.0 opp. Dette begrepet ble laget av Tim O'Reilly i 2004 for å referere til en andre generasjon i historien til nettet basert på brukerfellesskap og et spesielt utvalg tjenester, som sosiale nettverk, blogger, wikier eller folksonomier, som oppmuntrer til samarbeid og rask utveksling av informasjon mellom brukere.
De første arkitekturene som kan betraktes som tjenesteorienterte (SOA) var basert på CORBA (Common Object Request Broker Architecture), som fungerte som et abstraksjonslag for å koble sammen de forskjellige elementene i arkitekturen og bygge tjenester. Andre tidligere teknologier var DCOM (Distributed Component Object Model) eller RPC (Remote Procedure Protocol). Med behovet for å effektivt designe og implementere distribuerte systemer på nettet, oppstår flere utfordringer, noen fokusert på selve utviklingen (ytelse, brukeropplevelse, etc.) og andre komplementære, basert på gjenbrukbarhet og kompatibilitet av tjenester. Fra disse behovene oppstår Web Services, som gir standardiserte mekanismer for å koble forskjellige brukere sammen med informasjonsservere.
SERVICE-ORIENTERTE ARKITEKTURER
I følge SOA (Service Oriented Architecture) er programvarearkitekturer som definerer bruken av tjenester for å støtte forretningskrav, hvis mål er å oppnå minst mulig kobling mellom programvareagenter. En tjeneste er en arbeidsenhet utført av en tjenesteleverandør for å oppnå et sluttresultat ønsket av en tjenesteforbruker. Både tjenesteleverandør og tjenesteforbruker er roller som spilles av programvareagenter, ikke programvareeiere. I en generell forstand er en tjenesteorientert arkitektur en programvareløsning som skal gjøre det mulig for en virksomhet å organisere og bruke ulike prosesser. Med SOA er programvareapplikasjoner ikke lenger massive blokker av funksjoner og prosesser. I stedet består disse applikasjonene av sammensatte modulære tjenester. Husk at en tjeneste er en enkel programvarefunksjon (som å kansellere en CD). Den kan kjøres på forespørsel av ethvert system, uavhengig av operativsystem, plattform, programmeringsspråk eller geografisk plassering.
Det som er revolusjonerende med SOA er ikke selve konseptet, som har eksistert lenge, men det faktum at det kan implementeres over WWW (World Wide Web). På samme måte som nettsider lastes inn på en hvilken som helst plattform, fungerer netttjenester på samme måte uavhengig av plattform ettersom de er bygget med
universelle standarder.
Ideen om SOA stammer direkte fra objektorientert programmering, som antyder et forhold mellom data og behandlingen av dem. Dermed definerer de formelt tjenester gjennom grensesnitt som er uavhengige av den underliggende plattformen og programmeringsspråket. Disse grensesnittene skjuler særegenhetene ved implementeringen, noe som gjør dem uavhengige av utvikler og programmeringsspråk. Gjennom disse arkitekturene er det mulig å designe og implementere svært skalerbare systemer som reflekterer forretningslogikken og som samtidig letter samspillet mellom ulike proprietære eller tredjepartssystemer. Grunnen til at vi vil at noen andre skal gjøre jobben for oss, er fordi de er eksperter. Å bruke en tjeneste er vanligvis billigere og mer effektivt enn å gjøre det selv. Så de fleste av oss forstår at vi ikke kan være eksperter på alt. Den samme regelen kan brukes for å bygge programvaresystemer.
Grensesnitt er veldig viktig, hvis de ikke er godt definert eller ikke fungerer, fungerer ikke systemet. Integrering av flere grensesnitt er kostbart og øker også potensialet for feil i distribuerte applikasjoner. Eksterne grensesnitt er den tregeste delen av de fleste distribuerte applikasjoner. Med alt dette, i stedet for å bygge nye grensesnitt for hver applikasjon, er det mer fornuftig å gjenbruke generiske grensesnitt for alle applikasjoner.
Så siden vi bare har noen få generiske grensesnitt tilgjengelig, må vi inkludere applikasjonsspesifikk semantikk i meldingene. Vi kan sende alle slags meldinger gjennom grensesnittene våre, men det er noen regler som må følges for å si at en arkitektur er tjenesteorientert.
– For det første må meldingene være beskrivende, ikke instruktive, da tjenesteleverandøren er ansvarlig for å løse problemet. Det vil for eksempel ligne på situasjonen med å gå på restaurant og fortelle servitøren hva du vil drikke og dine preferanser, men vi bør ikke forklare kokken hvordan du tilbereder rettene dine, trinn for trinn.
‐ For det andre vil ikke tjenesteleverandører kunne forstå forespørselen din hvis meldingene deres ikke er skrevet i et format, en struktur og et vokabular som er forståelig for alle involverte. Derfor er det å begrense ordforrådet og strukturen til meldinger
nødvendig for effektiv kommunikasjon. Jo smalere budskapet er, jo lettere å forstå.
– For det tredje er muligheten for forlengelser av vital betydning. Verden er et sted i stadig endring, og det samme er miljøet der programvaren lever. Disse endringene krever tilsvarende endringer i systemprogramvaren, forbrukere av tjenester, leverandører og meldingene de utveksler. Hvis meldinger ikke kan utvides, er forbrukere og leverandører låst til en bestemt versjon av tjenesten. Begrensninger og utvidbarhet er dypt relatert, du trenger begge deler, og å øke det ene betyr å redusere det andre. Det ideelle er å oppnå en riktig balanse.
– For det fjerde må en SOA ha en mekanisme som gjør at forbrukeren kan oppdage en tjenesteleverandør i sammenheng med en tjeneste som forbrukeren søker etter. Mekanismen bør være fleksibel og ikke et sentralisert register.
- For det femte, statsløs tjeneste: Hver melding som en forbruker sender til en leverandør må inneholde all informasjon som er nødvendig for at leverandøren skal kunne behandle den. Denne begrensningen gjør en tjenesteleverandør mer skalerbar, siden leverandøren ikke trenger å lagre tilstandsinformasjon mellom forespørsler. Dette kan kalles en "masseproduksjonstjeneste" da hver forespørsel kan håndteres generisk. Denne begrensningen gir også mer synlighet, ettersom all overvåkingsprogramvare uavhengig kan inspisere en forespørsel og trekke ut intensjonen. Dette gir også mulighet for enkel gjenoppretting fra delvise feil siden det ikke er noen mellomtilstander, noe som gjør tjenesten mer pålitelig.
- For det sjette, idempotente forespørsler (ingen endringer): dupliserte forespørsler mottatt av en programvareagent har samme effekt som en enkeltforespørsel. Dette kravet lar leverandører og forbrukere øke den generelle påliteligheten til tjenesten, bare gjenta forespørselen hvis det var noen feil.
Så vi kan si at SOA ikke er et verktøy, men et sett med standarder for å bygge nye applikasjoner, mer dynamiske og mindre avhengige. SOA forenkler tilgang til forretningslogikk og informasjon på tvers av flere tjenester på en systematisk måte, og kan også orkestrere flere eksterne tjenester for å komponere en enkelt. mest av definisjonene identifiserer bruken av webtjenester, som vi vil se i neste kapittel, i implementeringen av en tjenesteorientert arkitektur. Det kan imidlertid implementeres ved hjelp av hvilken som helst annen tjenestebasert teknologi.