OASIS SOA referensmodell

OASIS Referensmodell för Service Oriented Architecture ( SOA-RM ) är ett abstrakt ramverk för att förstå betydande enheter och relationer mellan dem inom en tjänsteorienterad miljö, och för utveckling av konsekventa standarder eller specifikationer som stöder den miljön. Den är baserad på förenande koncept för SOA och kan användas av arkitekter som utvecklar specifika tjänsteorienterade arkitekturer eller för att träna och förklara SOA.

I detta sammanhang ses en referensmodell som en plats för att tillhandahålla en gemensam semantik som kan användas entydigt över och mellan olika SOA-implementeringar. Förhållandet mellan referensmodellen och speciella arkitekturer, teknologier och andra aspekter av SOA illustreras nedan från specifikationen.

Beskrivning

Historia

OASIS SOA Reference Model, är en produkt av OASIS SOA Reference Model (SOA-RM) Technical Committee (TC). Före detta initiativ hade det inte funnits någon standarddefinition av SOA. SOA-RM TC chartrades i februari 2005 för att utveckla en kärnreferensmodell för att vägleda och främja skapandet av specifika tjänsteorienterade arkitekturer, och för att publicera en referensmodell för SOA, såväl som en eller flera referensarkitekturer baserade på referensen. Modell. Referensmodellen godkändes som en OASIS-standard av OASIS-medlemmar i oktober 2006.

OASIS SOA-RM TC började arbeta med en kompletterande referensarkitektur under den sista godkännandeperioden för referensmodellen, och OASIS Reference Architecture Foundation for Service Oriented Architecture (SOA-RAF) godkändes som en OASIS-kommittéspecifikation i december 2012.

Även om OASIS SOA-referensmodellen har välkomnats på vissa håll, diskuterades även många andra SOA-specifikationer under den tidsperiod då SOA-RAF utvecklades. Ett samarbete för att "harmonisera" de individuella insatserna inleddes med OASIS , The Open Group och Object Management Group (OMG) under perioden 2008-2009. Även om diskussionerna fann uppenbar gemensamhet, var harmonisering utom räckhåll vid den tiden, och slutprodukten var ett gemensamt dokument Navigering i SOA Open Standards Landscape Around Architecture som publicerades i juli 2009. Dessutom innehåller bilaga C till SOA-RAF en sammanfattning av andra SOA-standardiseringsinsatser. Diskussionerna har fortsatt fram till idag. Nedan (och i själva SOA-RM) diskuteras hur flera referensarkitekturer kan härledas från en enda referensmodell.

Nuvarande status

SOA-RM TC förblir aktiv och fortsätter diskussioner om ämnen som service och granularitet i gränssnittet. Ytterligare kommittéanteckningar kan bli resultatet av dessa diskussioner.

Huvudkoncept

OASIS definition av SOA

Enligt SOA-RM-specifikationen är SOA ett paradigm för att organisera och använda distribuerade funktioner som kan vara under kontroll av olika ägardomäner. Det ger ett enhetligt sätt att erbjuda, upptäcka, interagera med och använda förmågor för att producera önskade effekter som överensstämmer med mätbara förutsättningar och förväntningar. SOA-RM-specifikationen bygger sin definition av SOA kring konceptet "behov och möjligheter", där SOA tillhandahåller en mekanism för att matcha behov hos tjänstekonsumenter med kapacitet som tillhandahålls av tjänsteleverantörer.

Service

Det centrala konceptet i referensmodellen är tjänsten , som referensmodellen definierar enligt följande: En mekanism för att möjliggöra åtkomst till en eller flera funktioner, där åtkomsten tillhandahålls med ett föreskrivet gränssnitt och utövas i enlighet med begränsningar och policyer som specificeras enligt tjänstebeskrivningen.

Följande är de huvudsakliga begreppen som referensmodellen definierar kring tjänster. Synlighet, interaktion och verklig världseffekt tar upp de dynamiska aspekterna av tjänster (interaktioner med tjänster), medan de återstående koncepten tar upp statiska aspekter:

Tjänstebeskrivning: Den information som behövs för att använda, eller överväga att använda, en tjänst. Syftet med beskrivningen är att underlätta interaktion och synlighet mellan deltagare i tjänsteinteraktioner, särskilt när deltagarna befinner sig i olika ägardomäner.
Synlighet: Förmågan för de med behov och de med förmågor att kunna interagera med varandra. Synlighet innefattar inte bara att det finns en tjänst utan också att det finns tillräcklig konsumentkännedom om leverantören och leverantörskännedom om konsumenten att vilja har etablerats mellan parterna att initiera eller fortsätta interaktionen. Detta görs vanligtvis genom att tillhandahålla beskrivningar för sådana aspekter som funktioner och tekniska krav, relaterade begränsningar och policyer och mekanismer för åtkomst eller svar.
Interaktion: Avser interaktionen mellan tjänsteleverantörer och konsumenter. Typiskt förmedlat av meddelandeutbyte, fortskrider en interaktion genom en serie informationsutbyten och åberopade åtgärder. Resultatet av en interaktion är en verklig världseffekt.
Real World Effect: Det faktiska resultatet av att använda en tjänst. Detta kan vara återlämnande av information eller förändring av tillståndet för enheter (kända eller okända) som är involverade i interaktionen.
Exekveringskontext: Uppsättningen av tekniska och affärsmässiga element som bildar en väg mellan de med behov och de med kapacitet och som fastställer villkoren under vilka tjänsteleverantörer och konsumenter kommer att interagera. Alla interaktioner är förankrade i ett visst exekveringssammanhang, vilket tillåter tjänsteleverantörer och konsumenter att interagera och ger en beslutspunkt för alla policyer och avtal som kan vara i kraft.
Kontrakt och policy: En policy representerar en begränsning eller ett villkor för användningen, distributionen eller beskrivningen av en ägd enhet enligt definitionen av en deltagare, medan ett kontrakt representerar ett avtal mellan två eller flera parter. Referensmodellen är främst inriktad på konceptet policyer och kontrakt som de gäller tjänster.

Exempel på SOA

Följande exempel är hämtat från SOA-RM-specifikationen och inkluderar de huvudsakliga begreppen som beskrivs ovan samt andra begrepp som referensmodellen definierar, inom parentes och kursiv stil:

Ett elföretag har kapacitet att generera och distribuera el (den underliggande förmågan) . Ledningarna från elföretagets distributionsnät (tjänsten) ger möjlighet att leverera el för att stödja typisk användning för en privatkonsuments hus (tjänstefunktionalitet) , och en konsument får tillgång till el som genereras ( utgången av att anropa tjänsten) via ett vägguttag (tjänstgränssnitt) .
För att kunna använda elektriciteten måste en konsument förstå vilken typ av kontakt som ska användas, vad är spänningen på strömförsörjningen och möjliga gränser för belastningen; Verktyget förutsätter att kunden endast kommer att ansluta enheter som är kompatibla med den tillhandahållna spänningen och belastningen som stöds; och konsumenten i sin tur antar att kompatibla konsumentenheter kan anslutas utan skada eller skada ( servicetekniska antaganden) .
En privat- eller företagsanvändare kommer att behöva öppna ett konto hos bolaget för att kunna använda utbudet ( servicebegränsning) och bolaget kommer att mäta användningen och förväntar sig att konsumenten ska betala för användningen till det pris som föreskrivs ( servicepolicy) . När konsumenten och bolaget kommer överens om begränsningar och policyer (serviceavtal) kan konsumenten ta emot el med hjälp av tjänsten så länge som eldistributionsnätet och husanslutningen förblir intakta (t.ex. en storm som slår ner kraftledningar skulle störa distributionen) och konsumenten kan få betalning skickad (t.ex. en check via post eller elektronisk överföring av pengar) till verktyget ( tillgänglighet) .
En annan person (t.ex. en besökare i någon annans hus) kan använda ett avtalat försörjning utan någon relation till bolaget eller något krav på att även uppfylla den initiala servicebegränsningen (t.ex. att nåbarhet endast kräver intakt eldistribution) men skulle ändå förväntas vara kompatibel med tjänstens gränssnitt.
I vissa situationer (till exempel överdriven efterfrågan) kan ett företag begränsa utbudet eller införa strömavbrott ( servicepolicy) . En konsument kan lämna in ett formellt klagomål om detta inträffade ofta (konsumentens underförstådda policy) .
Om verktyget krävde att varje enhet skulle anslutas till sin utrustning, skulle den underliggande förmågan fortfarande finnas där, men detta skulle vara en helt annan tjänst och ha ett helt annat tjänstegränssnitt.

SOA och processer

Även om referensmodellen införlivar begreppet processer genom sitt processmodellkoncept, är omfattningen av denna aspekt av referensmodellen avsiktligt inte helt definierad. Till exempel behandlar referensmodellen inte orkestrering av flera tjänster, även om orkestrering och koreografi kan vara en del av processmodellen. Detta beror på att referensmodellens fokus ligger på att modellera vad tjänster är och vilka nyckelrelationer som är involverade i modelleringstjänster. Det är tänkt att det kan finnas framtida arbete på detta område, även om källan till det arbetet ännu inte har definierats.

Sekundära begrepp

OASIS definition av referensmodell

Enligt SOA-RM-specifikationen är en referensmodell ett abstrakt ramverk för att förstå betydelsefulla relationer mellan entiteterna i någon miljö. Det möjliggör utveckling av specifika referens- eller konkreta arkitekturer med hjälp av konsekventa standarder eller specifikationer som stödjer den miljön. En referensmodell består av en minimal uppsättning förenande begrepp, axiom och relationer inom en viss problemdomän och är oberoende av specifika standarder, teknologier, implementeringar eller andra konkreta detaljer. En referensmodell för SOA är därför ett abstrakt ramverk för att förstå betydande relationer mellan SOA-enheterna.

Referensmodell vs. Referensarkitektur

SOA-RM-specifikationen ger en tydlig distinktion mellan en referensmodell och en referensarkitektur och beskriver förhållandet mellan dem. En referensarkitektur är ett arkitektoniskt designmönster som indikerar hur en abstrakt uppsättning mekanismer och relationer realiserar en förutbestämd uppsättning krav. En eller flera referensarkitekturer kan härledas från en gemensam referensmodell för att adressera olika syften/användningar som referensmodellen kan riktas mot. SOA-RM-specifikationen ger en analogi som involverar design av bostäder för att illustrera förhållandet mellan en referensmodell och en referensarkitektur, samt hur referensarkitekturer kan användas för att härleda konkreta arkitekturer.