Coulouris definieerde gedistribueerde systemen als “systemen waarin hardware- en/of softwarecomponenten die in een computernetwerk bestaan, communiceren en hun acties coördineren door berichten uit te wisselen”.
Dit concept is de afgelopen jaren door verschillende factoren populair geworden. De eerste factor die de ontwikkeling van gedistribueerde systemen bevorderde, was de opkomst van lokale hogesnelheidsnetwerken. Een andere belangrijke factor was de technologische vooruitgang in de prestaties van personal computers en de ontwikkeling van software ter ondersteuning van gedistribueerde applicaties. Gedistribueerde systemen zijn gekoppeld aan het concept van web en internet. Met de evolutie van het web en de opkomst van nieuwe gebieden, interacties, behoeften en toepassingen ontstaat het concept van Web 2.0. Deze term werd in 2004 door Tim O'Reilly bedacht om te verwijzen naar een tweede generatie in de geschiedenis van het web, gebaseerd op gebruikersgemeenschappen en een speciaal scala aan diensten, zoals sociale netwerken, blogs, wiki's of folksonomies, die samenwerking en wendbaarheid aanmoedigen. uitwisseling van informatie tussen gebruikers.
De eerste architecturen die als service-georiënteerd (SOA) kunnen worden beschouwd, waren gebaseerd op CORBA (Common Object Request Broker Architecture), die fungeerde als een abstractielaag om de verschillende elementen van de architectuur met elkaar te verbinden en services te bouwen. Andere vroege technologieën waren DCOM (Distributed Component Object Model) of RPC (Remote Procedure Protocol). Met de noodzaak om gedistribueerde systemen op het web efficiënt te ontwerpen en te implementeren, ontstaan er verschillende uitdagingen, waarvan sommige gericht zijn op de ontwikkeling zelf (prestaties, gebruikerservaring, enz.) en andere complementair zijn, gebaseerd op de herbruikbaarheid en compatibiliteit van diensten. Uit deze behoeften komen webservices voort, die gestandaardiseerde mechanismen bieden om verschillende gebruikers met informatieservers te verbinden.
SERVICEGERICHTE ARCHITECTUUR
Volgens SOA (Service Oriented Architecture) zijn het softwarearchitecturen die het gebruik van services definiëren ter ondersteuning van zakelijke vereisten, met als doel een zo minimaal mogelijke koppeling tussen softwareagenten te bereiken. Een dienst is een werkeenheid die door een dienstverlener wordt uitgevoerd om een door een dienstconsument gewenst eindresultaat te bereiken. Zowel de serviceprovider als de serviceconsument zijn rollen die worden gespeeld door softwareagenten, niet door hun eigenaren. In algemene zin is een servicegerichte architectuur een softwareoplossing die bedoeld is om een bedrijf in staat te stellen verschillende processen te organiseren en te gebruiken. Met SOA zijn softwareapplicaties niet langer enorme blokken functies en processen. In plaats daarvan bestaan deze toepassingen uit samengestelde modulaire diensten. Houd er rekening mee dat een service een eenvoudige softwarefunctie is (zoals het annuleren van het afspelen op een cd). Het kan door elk systeem op aanvraag worden uitgevoerd, ongeacht het besturingssysteem, platform, programmeertaal of geografische locatie.
Het revolutionaire aan SOA is niet het concept zelf, dat al heel lang bestaat, maar het feit dat het via het WWW (World Wide Web) kan worden geïmplementeerd. Net zoals webpagina's op elk platform worden geladen, werken webservices op een vergelijkbare manier, ongeacht het platform waarop ze zijn gebouwd
universele normen.
Het idee van SOA komt rechtstreeks voort uit objectgeoriënteerd programmeren, wat een relatie suggereert tussen gegevens en de verwerking ervan. Ze definiëren diensten dus formeel via interfaces die onafhankelijk zijn van het onderliggende platform en de programmeertaal. Deze interfaces verbergen de eigenaardigheden van hun implementatie, waardoor ze onafhankelijk zijn van de ontwikkelaar en programmeertaal. Via deze architecturen is het mogelijk om zeer schaalbare systemen te ontwerpen en te implementeren die de bedrijfslogica weerspiegelen en tegelijkertijd de interactie tussen verschillende eigen systemen of systemen van derden vergemakkelijken. De reden dat we willen dat iemand het werk voor ons doet, is omdat zij experts zijn. Het gebruik van een dienst is over het algemeen goedkoper en effectiever dan het zelf doen. De meesten van ons begrijpen dus dat we niet in alles experts kunnen zijn. Dezelfde regel kan worden toegepast op het bouwen van softwaresystemen.
Interfaces zijn uiterst belangrijk: als ze niet goed gedefinieerd zijn of niet werken, werkt het systeem niet. Het integreren van meer interfaces is duur en vergroot ook de kans op fouten in gedistribueerde applicaties. Externe interfaces vormen het langzaamste onderdeel van de meeste gedistribueerde applicaties. Met dit alles is het, in plaats van nieuwe interfaces voor elke applicatie te bouwen, zinvoller om generieke interfaces voor alle applicaties te hergebruiken.
Omdat we dus maar een paar generieke interfaces beschikbaar hebben, moeten we applicatiespecifieke semantiek in de berichten opnemen. We kunnen elk type bericht via onze interfaces verzenden, maar er zijn enkele regels die moeten worden gevolgd om te zeggen dat een architectuur servicegericht is.
– Ten eerste moeten berichten beschrijvend zijn en niet leerzaam, aangezien de dienstverlener verantwoordelijk is voor het oplossen van het probleem. Het zou bijvoorbeeld vergelijkbaar zijn met de situatie waarin je naar een restaurant gaat en de ober vertelt wat je wilt drinken en wat je voorkeuren zijn, maar we moeten de kok niet stap voor stap uitleggen hoe hij je gerechten moet bereiden.
‐ Ten tweede zullen dienstverleners uw verzoek niet kunnen begrijpen als hun berichten niet zijn geschreven in een formaat, structuur en woordenschat die voor alle betrokkenen begrijpelijk zijn. Het beperken van de woordenschat en structuur van berichten is dus een
noodzakelijk voor effectieve communicatie. Hoe beperkter de boodschap, hoe gemakkelijker deze te begrijpen is.
‐ Ten derde is de mogelijkheid tot uitbreiding van cruciaal belang. De wereld verandert voortdurend, en dat geldt ook voor de omgeving waarin software leeft. Deze veranderingen vereisen overeenkomstige veranderingen aan de systeemsoftware, consumenten van diensten, aanbieders en de berichten die zij uitwisselen. Als berichten niet uitbreidbaar zijn, zijn consumenten en providers gebonden aan een specifieke versie van de dienst. Beperking en uitbreidbaarheid zijn nauw met elkaar verbonden; je hebt beide nodig, en het vergroten van het ene betekent het verkleinen van het andere. Het ideaal is om een juist evenwicht te bereiken.
– Ten vierde moet een SOA een mechanisme hebben waarmee de consument een dienstverlener kan ontdekken in de context van een door de consument gezochte dienst. Het mechanisme moet flexibel zijn en mag geen gecentraliseerd register zijn.
‐ Ten vijfde, staatloze dienst: elk bericht dat een consument naar een aanbieder stuurt, moet alle informatie bevatten die de aanbieder nodig heeft om het te verwerken. Deze beperking maakt een serviceprovider schaalbaarder omdat de provider geen statusinformatie tussen verzoeken hoeft op te slaan. Dit kan een “massaproductiedienst” worden genoemd, omdat elke aanvraag generiek kan worden afgehandeld. Deze beperking zorgt ook voor meer zichtbaarheid, omdat elke monitoringsoftware een onafhankelijk verzoek kan inspecteren en de bedoeling ervan kan achterhalen. Dit maakt ook een eenvoudig herstel van gedeeltelijke storingen mogelijk, aangezien er geen tussenliggende toestanden zijn, waardoor de service betrouwbaarder wordt.
‐ Ten zesde, idempotente verzoeken (die geen wijzigingen aanbrengen): dubbele verzoeken ontvangen door een softwareagent hebben hetzelfde effect als één enkel verzoek. Deze vereiste stelt aanbieders en consumenten in staat de algehele betrouwbaarheid van de service, door simpelweg het verzoek te herhalen als er een fout is opgetreden.
We kunnen dus zeggen dat SOA geen hulpmiddel is, maar eerder een reeks standaarden voor het bouwen van nieuwe, dynamischere en minder afhankelijke applicaties. SOA vergemakkelijkt de toegang tot bedrijfslogica en informatie tussen verschillende services op een systematische manier, en kan ook verschillende services op afstand orkestreren om één enkele service te vormen. De meerderheid van De definities identificeren het gebruik van webservices, dat we in het volgende hoofdstuk zullen zien, bij de implementatie van een servicegerichte architectuur. Het kan echter worden geïmplementeerd met behulp van elke andere servicegebaseerde technologie.