Een servicegeoriënteerde architectuur (SOA) is een architectonisch patroon in het ontwerpen van computersoftware waarin applicatiecomponenten diensten verlenen aan andere componenten via een communicatieprotocol, doorgaans via een netwerk. De principes van servicegerichtheid zijn onafhankelijk van welk product, leverancier of technologie dan ook.
SOA maakt het alleen eenvoudiger voor softwarecomponenten over verschillende netwerken om met elkaar samen te werken.
Webservices die zijn gebouwd volgens de SOA-architectuur hebben de neiging om webservices onafhankelijker te maken. De webservices kunnen zelf gegevens met elkaar uitwisselen en vanwege de onderliggende principes waarop ze zijn gemaakt, hebben ze geen enkele vorm van menselijke interactie nodig en ook geen codewijzigingen. Het zorgt ervoor dat de webservices op een netwerk naadloos met elkaar kunnen communiceren.
SOA is gebaseerd op enkele kernprincipes die hieronder worden genoemd
- Gestandaardiseerd servicecontract - Services voldoen aan een servicebeschrijving. Een dienst moet een soort beschrijving hebben die beschrijft waar de dienst over gaat. Dit maakt het voor clienttoepassingen gemakkelijker om te begrijpen wat de service doet.
- Losse koppeling - Minder afhankelijkheid van elkaar. Dit is een van de belangrijkste kenmerken van webservices die alleen stelt dat er zo min mogelijk afhankelijkheid moet zijn tussen de webservices en de client die de webservice aanroept. Dus als de servicefunctionaliteit op enig moment in de tijd verandert, mag dit de clienttoepassing niet breken of stoppen met werken.
- Service-abstractie - Services verbergen de logica die ze voor de buitenwereld bevatten. De service mag niet laten zien hoe het zijn functionaliteit uitvoert; het moet de clienttoepassing gewoon vertellen wat het doet en niet hoe het het doet.
- Herbruikbaarheid van services - Logica is onderverdeeld in services met de bedoeling hergebruik te maximaliseren. In elk ontwikkelingsbedrijf is herbruikbaarheid een groot onderwerp, omdat men natuurlijk geen tijd en moeite zou willen besteden aan het steeds opnieuw bouwen van dezelfde code voor meerdere applicaties die ze nodig hebben. Als de code voor een webservice eenmaal is geschreven, moet deze dus met verschillende applicatietypen kunnen werken.
- Autonomie van services - Services moeten controle hebben over de logica die ze bevatten. De dienst weet alles van welke functionaliteit het biedt en zou dus ook volledige controle moeten hebben over de code die het bevat.
- Staatloosheid van diensten - Idealiter zouden diensten staatloos moeten zijn. Dit betekent dat diensten geen informatie mogen achterhouden van de ene staat naar de andere. Dit zou moeten worden gedaan vanuit de clienttoepassing. Een voorbeeld kan een bestelling zijn die op een winkelsite is geplaatst. Nu kunt u een webservice hebben die u de prijs van een bepaald artikel geeft. Maar als de artikelen aan een winkelwagentje worden toegevoegd en de webpagina navigeert naar de pagina waar u de betaling doet, mag de webservice niet verantwoordelijk zijn voor de prijs van het artikel dat naar de betaalpagina moet worden overgebracht. In plaats daarvan moet het worden gedaan door de webapplicatie.
- Detecteerbaarheid van services - Services kunnen worden ontdekt (meestal in een serviceregister). We hebben dit al gezien in het concept van de UDDI, dat een register uitvoert dat informatie over de webservice kan bevatten.
- Service Composability - Services breken grote problemen op in kleine problemen. Men moet nooit alle functionaliteit van een applicatie in één enkele service integreren, maar in plaats daarvan de service opsplitsen in modules met elk een afzonderlijke bedrijfsfunctionaliteit.
- Service-interoperabiliteit - Services moeten standaarden gebruiken waarmee verschillende abonnees de service kunnen gebruiken. In webservices worden standaarden als XML en communicatie via HTTP gebruikt om ervoor te zorgen dat deze aan dit principe voldoet.