Hvad er SOA? Serviceorienteret ArchiTecture Principper
Elias Hall
Hvad er SOA (Service Oriented Architecture)?
En serviceorienteret Architecture (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 med hinanden.
Webtjenester, der er bygget i henhold til SOA-arkitekturen, har en tendens til at gøre webtjenesten mere uafhængig. Webtjenesterne selv kan udveksle data med hinanden, og på grund af de underliggende principper, som de er skabt på, har de ikke brug for nogen form for menneskelig interaktion og heller ingen kodeændringer. Det sikrer, at webtjenesterne på et netværk kan interagere med hinanden problemfrit.
Serviceorienteret Architecture (SOA) principper
Der er 9 typer af SOA-designprincipper, som er nævnt nedenfor
1. Standardiseret servicekontrakt
Tjenester overholder en servicebeskrivelse. En tjeneste skal have en form for beskrivelse, der beskriver, hvad tjenesten går ud på. Dette gør det lettere for klientapplikationer at forstå, hvad tjenesten gør.
2. Løs kobling
Less afhængighed af hinanden. Dette er et af de vigtigste kendetegn ved webtjenester, som blot siger, at der skal være så mindre afhængighed som muligt mellem webtjenesterne og den klient, der påberåber sig webtjenesten. Så hvis servicefunktionaliteten ændres på et hvilket som helst tidspunkt, bør den ikke bryde klientapplikationen eller stoppe den i at fungere.
3. Service Abstraktion
Tjenester skjuler den logik, de indkapsler fra omverdenen. Tjenesten bør ikke afsløre, hvordan den udfører sin funktionalitet; den skal bare fortælle klientapplikationen, hvad den gør og ikke om, hvordan den gør det.
4. Service Genbrugelighed
Logik er opdelt i tjenester med det formål at maksimere genbrug. I enhver udviklingsvirksomhed er genbrugelighed et stort emne, fordi man åbenbart ikke vil bruge tid og kræfter på at bygge den samme kode igen og igen på tværs af flere applikationer, som kræver dem. Når først koden til en webtjeneste er skrevet, bør den derfor kunne arbejde med forskellige applikationstyper.
5. Tjenesteautonomi
Tjenester bør 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.
6. Service Statsløshed
Ideelt set bør tjenester være statsløse. Det 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 afgivet på en shoppingside. Nu kan du få en webservice, som giver dig prisen på en bestemt vare. Men hvis varerne lægges i en indkøbskurv, og websiden navigerer til siden, hvor du foretager betalingen, bør ansvaret for prisen på varen, der skal overføres til betalingssiden, ikke varetages af webservicen. I stedet skal det gøres af webapplikationen.
7. Serviceopdagbarhed
Tjenester kan opdages (normalt i et serviceregister). Det har vi allerede set i konceptet med UDDI, som udfører et register, som kan indeholde oplysninger om webtjenesten.
8. Tjenestesammensætning
Tjenester deler store problemer op i små problemer. Man bør aldrig integrere al funktionalitet af en applikation i én enkelt tjeneste, men i stedet opdele tjenesten i moduler med hver sin forretningsfunktionalitet.
9. Tjenesteinteroperabilitet
Tjenester bør bruge standarder, der tillader forskellige abonnenter at bruge tjenesten. I webtjenester, standarder som XML og kommunikation over HTTP bruges til at sikre, at den er i overensstemmelse med dette princip.
