Vad är SOA? Serviceinriktad Architecture Principer

Vad är SOA (Service Oriented Architecture)?

En tjänsteorienterad Architecture (SOA) är ett arkitektoniskt mönster i design av programvara där applikationskomponenter tillhandahåller tjänster till andra komponenter via ett kommunikationsprotokoll, vanligtvis över ett nätverk. Principerna för tjänsteorientering är oberoende av någon produkt, leverantör eller teknologi.

SOA gör det bara lättare för programvarukomponenter över olika nätverk att arbeta med varandra.

Webbtjänster som är byggda enligt SOA-arkitekturen tenderar att göra webbtjänsten mer oberoende. Webbtjänsterna själva kan utbyta data med varandra och på grund av de underliggande principerna som de är skapade på behöver de ingen form av mänsklig interaktion och behöver inte heller några kodändringar. Det säkerställer att webbtjänsterna i ett nätverk kan interagera med varandra sömlöst.

Serviceinriktad Architecture (SOA) principer

Det finns 9 typer av SOA-designprinciper som nämns nedan

1. Standardiserat serviceavtal

Tjänsterna följer en tjänstebeskrivning. En tjänst måste ha någon form av beskrivning som beskriver vad tjänsten handlar om. Detta gör det lättare för klientapplikationer att förstå vad tjänsten gör.

2. Lös koppling

Less beroende av varandra. Detta är en av de viktigaste egenskaperna hos webbtjänster som bara säger att det ska vara så mindre beroende som möjligt mellan webbtjänsterna och klienten som anropar webbtjänsten. Så om tjänstens funktionalitet ändras vid någon tidpunkt bör den inte bryta klientapplikationen eller stoppa den från att fungera.

3. Tjänsteabstraktion

Tjänster döljer logiken de kapslar in från omvärlden. Tjänsten ska inte avslöja hur den utför sin funktionalitet; den ska bara berätta för klientapplikationen om vad den gör och inte om hur den gör det.

4. Återanvändbarhet för tjänster

Logik är uppdelad i tjänster med avsikten att maximera återanvändningen. I alla utvecklingsföretag är återanvändning ett stort ämne eftersom man uppenbarligen inte skulle vilja lägga tid och ansträngning på att bygga samma kod om och om igen över flera applikationer som kräver dem. När koden för en webbtjänst väl är skriven bör den därför kunna fungera med olika applikationstyper.

5. Serviceautonomi

Tjänster bör ha kontroll över logiken de kapslar in. Tjänsten vet allt om vilken funktionalitet den erbjuder och bör därför också ha fullständig kontroll över koden den innehåller.

6. Service Statslöshet

Helst ska tjänster vara statslösa. Detta innebär att tjänster inte ska undanhålla information från en stat till en annan. Detta skulle behöva göras från antingen klientapplikationen. Ett exempel kan vara en beställning som görs på en shoppingsajt. Nu kan du ha en webbtjänst som ger dig priset på en viss vara. Men om varorna läggs till i en varukorg och webbsidan navigerar till sidan där du gör betalningen, bör ansvaret för priset på varan som ska överföras till betalningssidan inte göras av webbtjänsten. Istället måste det göras av webbapplikationen.

7. Upptäckbarhet av tjänster

Tjänster kan upptäckas (vanligtvis i ett tjänsteregister). Vi har redan sett detta i konceptet med UDDI, som utför ett register som kan hålla information om webbtjänsten.

8. Tjänstens sammansättning

Tjänster bryter stora problem i små problem. Man bör aldrig bädda in all funktionalitet i en applikation i en enda tjänst utan istället dela upp tjänsten i moduler var och en med en separat affärsfunktionalitet.

9. Tjänstens interoperabilitet

Tjänsterna bör använda standarder som tillåter olika abonnenter att använda tjänsten. I webbtjänster, standarder som XML och kommunikation över HTTP används för att säkerställa att den överensstämmer med denna princip.