En serviceorienteret arkitektur (SOA) er et arkitektonisk mønster i computersoftwaredesign, hvor applikationskomponenter leverer tjenester til andre komponenter via en kommunikationsprotokol, typisk over et netværk. Principperne for serviceorientering er uafhængige af ethvert produkt, leverandør eller teknologi.
SOA gør det bare nemmere for softwarekomponenter over forskellige netværk at arbejde sammen.
Webtjenester, der er bygget i henhold til SOA-arkitekturen, har tendens til at gøre webservice mere uafhængig. Webtjenesterne selv kan udveksle data med hinanden, og på grund af de underliggende principper, som de oprettes på, har de ikke brug for nogen form for menneskelig interaktion og har heller ikke brug for kodeændringer. Det sikrer, at webservices på et netværk kan interagere med hinanden problemfrit.
SOA er baseret på nogle nøgleprincipper, som er nævnt nedenfor
- Standardiseret servicekontrakt - Services overholder en servicebeskrivelse. En tjeneste skal have en slags beskrivelse, der beskriver, hvad tjenesten handler om. Dette gør det lettere for klientapplikationer at forstå, hvad tjenesten gør.
- Løs kobling - Mindre afhængighed af hinanden. Dette er et af de vigtigste kendetegn ved webtjenester, der bare siger, at der skal være så mindre afhængighed som muligt mellem webtjenesterne og klienten, der påberåber sig webtjenesten. Så hvis servicefunktionaliteten ændres på et hvilket som helst tidspunkt, bør den ikke bryde klientapplikationen eller forhindre den i at fungere.
- Service Abstraktion - Tjenester skjuler logikken, de indkapsler, for omverdenen. Tjenesten bør ikke afsløre, hvordan den udfører dens funktionalitet; det skal bare fortælle klientapplikationen om, hvad det gør, og ikke om, hvordan det gør det.
- Servicegenanvendelighed - Logik er opdelt i tjenester med det formål at maksimere genbrug. I ethvert udviklingsfirma er genanvendelighed et stort emne, fordi man naturligvis ikke vil bruge tid og kræfter på at opbygge den samme kode igen og igen på tværs af flere applikationer, der kræver dem. Derfor, når koden til en webservice er skrevet, skal den have evnen til at arbejde med forskellige applikationstyper.
- Tjenesteautonomi - Tjenester skal have kontrol over den logik, de indkapsler. Tjenesten ved alt om, hvilken funktionalitet den tilbyder, og bør derfor også have fuld kontrol over den kode, den indeholder.
- Service statelessness - Ideelt set bør tjenester være statsløse. Dette betyder, at tjenester ikke bør tilbageholde oplysninger fra den ene stat til den anden. Dette skal gøres fra enten klientapplikationen. Et eksempel kan være en ordre, der placeres på et shoppingsted. Nu kan du have en webservice, der giver dig prisen på en bestemt vare. Men hvis varerne tilføjes til en indkøbskurv, og websiden navigerer til den side, hvor du foretager betalingen, bør ansvaret for prisen på den vare, der skal overføres til betalingssiden, ikke udføres af webservicen. I stedet skal det gøres af webapplikationen.
- Tjenesteopdagbarhed - Tjenester kan opdages (normalt i et service-register). Vi har allerede set dette i konceptet med UDDI, der udfører et register, der kan indeholde oplysninger om webservicen.
- Servicekomposibilitet - Tjenester deler store problemer i små problemer. Man skal aldrig integrere al applikationsfunktionalitet i en enkelt tjeneste, men i stedet opdele tjenesten i moduler hver med en separat forretningsfunktionalitet.
- Serviceinteroperabilitet - Tjenester skal bruge standarder, der giver forskellige abonnenter mulighed for at bruge tjenesten. I webtjenester bruges standarder som XML og kommunikation via HTTP for at sikre, at det overholder dette princip.