Hva er SOA? Serviceorientert Archilæreprinsipper
Hva er SOA (Service Oriented Architecture)?
En tjenesteorientert Architecture (SOA) er et arkitektonisk mønster i dataprogramvaredesign der applikasjonskomponenter gir tjenester til andre komponenter via en kommunikasjonsprotokoll, vanligvis over et nettverk. Prinsippene for tjenesteorientering er uavhengige av ethvert produkt, leverandør eller teknologi.
SOA gjør det bare enklere for programvarekomponenter over ulike nettverk å jobbe med hverandre.
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 laget på, trenger de ingen form for menneskelig interaksjon og trenger heller ingen kodemodifikasjoner. Det sikrer at nettjenestene på et nettverk kan samhandle sømløst med hverandre.
Tjenesteorientert Architecture (SOA) prinsipper
Det er 9 typer SOA-designprinsipper som er nevnt nedenfor
1. Standardisert servicekontrakt
Tjenester følger en tjenestebeskrivelse. En tjeneste må ha en slags beskrivelse som beskriver hva tjenesten går ut på. Dette gjør det lettere for klientapplikasjoner å forstå hva tjenesten gjør.
2. Løs kobling
Less avhengighet av hverandre. Dette er en av hovedkarakteristikkene til webtjenester som bare sier at det skal være minst mulig avhengighet mellom webtjenestene og klienten som påkaller webtjenesten. Så hvis tjenestefunksjonaliteten endres når som helst, bør den ikke bryte klientapplikasjonen eller stoppe den fra å fungere.
3. Tjenesteabstraksjon
Tjenester skjuler logikken de innkapsler fra omverdenen. Tjenesten skal ikke avsløre hvordan den utfører sin funksjonalitet; den skal bare fortelle klientapplikasjonen om hva den gjør og ikke om hvordan den gjør det.
4. Gjenbruk av tjenesten
Logikk er delt inn i tjenester med den hensikt å maksimere gjenbruk. I ethvert utviklingsselskap er gjenbruk 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 webtjeneste er skrevet, bør den kunne fungere med ulike applikasjonstyper.
5. Tjenesteautonomi
Tjenester bør 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.
6. Tjeneste statsløshet
Ideelt sett bør tjenester være statsløse. Dette betyr at tjenester ikke skal holde tilbake informasjon fra en stat til en annen. Dette må gjøres fra enten klientapplikasjonen. Et eksempel kan være en bestilling plassert på en shoppingside. Nå kan du ha en webtjeneste som gir deg prisen på en bestemt vare. Men hvis varene legges i en handlekurv og nettsiden navigerer til siden der du betaler, bør ikke nettjenesten ta ansvaret for prisen på varen som skal overføres til betalingssiden. I stedet må det gjøres av nettapplikasjonen.
7. Tjenesteoppdagbarhet
Tjenester kan oppdages (vanligvis i et tjenesteregister). Vi har allerede sett dette i konseptet til UDDI, som utfører et register som kan inneholde informasjon om nettjenesten.
8. Tjenestekomponerbarhet
Tjenester bryter store problemer inn i små problemer. Man bør aldri bygge inn all funksjonalitet til en applikasjon i én enkelt tjeneste, men i stedet bryte tjenesten ned i moduler med hver sin forretningsfunksjonalitet.
9. Tjenesteinteroperabilitet
Tjenestene bør bruke standarder som lar ulike abonnenter bruke tjenesten. I webtjenester, standarder som XML og kommunikasjon over HTTP brukes for å sikre at den er i samsvar med dette prinsippet.