En serviceorientert arkitektur (SOA) er et arkitektonisk mønster i design av programvare der applikasjonskomponenter gir tjenester til andre komponenter via en kommunikasjonsprotokoll, vanligvis over et nettverk. Prinsippene for serviceorientering er uavhengige av ethvert produkt, leverandør eller teknologi.
SOA gjør det bare lettere for programvarekomponenter over forskjellige nettverk å samarbeide.
Webtjenester som er bygget i henhold til SOA-arkitekturen har en tendens til å gjøre webtjenesten mer uavhengig. Nettjenestene selv kan utveksle data med hverandre, og på grunn av de underliggende prinsippene de er opprettet på, trenger de ikke noen form for menneskelig interaksjon og trenger heller ingen kodendringer. Det sørger for at nettjenestene i et nettverk kan samhandle med hverandre sømløst.
SOA er basert på noen viktige prinsipper som er nevnt nedenfor
- Standardisert servicekontrakt - Tjenester følger en tjenestebeskrivelse. En tjeneste må ha en slags beskrivelse som beskriver hva tjenesten handler om. Dette gjør det lettere for klientapplikasjoner å forstå hva tjenesten gjør.
- Løs kobling - Mindre avhengighet av hverandre. Dette er en av de viktigste egenskapene til webtjenester som bare sier at det skal være minst mulig avhengighet mellom webtjenestene og klienten som påkaller nettjenesten. Så hvis tjenestefunksjonaliteten endres når som helst, bør den ikke bryte klientapplikasjonen eller hindre den i å fungere.
- Service Abstraction - Tjenester skjuler logikken de innkapsler fra omverdenen. Tjenesten skal ikke avsløre hvordan den utfører funksjonaliteten; det skal bare fortelle klientapplikasjonen om hva den gjør og ikke om hvordan den gjør det.
- Gjenbrukbarhet - Logikk er delt inn i tjenester med den hensikt å maksimere gjenbruk. I ethvert utviklingsselskap er gjenbrukbarhet et stort tema fordi man åpenbart ikke vil bruke tid og krefter på å bygge den samme koden igjen og igjen på tvers av flere applikasjoner som krever dem. Derfor, når koden for en nettjeneste er skrevet, bør den ha muligheten til å jobbe med forskjellige applikasjonstyper.
- Tjenesteautonomi - Tjenester skal ha kontroll over logikken de innkapsler. Tjenesten vet alt om hvilken funksjonalitet den tilbyr, og bør derfor også ha full kontroll over koden den inneholder.
- Tjenestestatsløshet - Ideelt sett bør tjenester være statsløse. Dette betyr at tjenester ikke skal holde informasjon fra en stat til en annen. Dette må gjøres fra klientapplikasjonen. Et eksempel kan være en ordre plassert på et shoppingnettsted. Nå kan du ha en webtjeneste som gir deg prisen på et bestemt element. Men hvis varene blir lagt til i en handlekurv og websiden navigerer til siden der du utfører betalingen, bør ikke ansvaret for prisen på varen som skal overføres til betalingssiden gjøres av nettjenesten. I stedet må det gjøres av webapplikasjonen.
- Tjenesteoppdagbarhet - Tjenester kan oppdages (vanligvis i et tjeneregister). Vi har allerede sett dette i konseptet med UDDI, som utfører et register som kan inneholde informasjon om nettjenesten.
- Servicekomposibilitet - Tjenester deler store problemer i små problemer. Man bør aldri legge inn all funksjonalitet i en applikasjon i en enkelt tjeneste, men i stedet dele tjenesten ned i moduler hver med en egen forretningsfunksjonalitet.
- Serviceinteroperabilitet - Tjenester bør bruke standarder som gjør det mulig for ulike abonnenter å bruke tjenesten. I webtjenester brukes standarder som XML og kommunikasjon via HTTP for å sikre at det er i samsvar med dette prinsippet.