Serviceinriktad programmering

Serviceorienterad programmering (SOP) är ett programmeringsparadigm som använder "tjänster" som enheten för datorarbete, för att designa och implementera integrerade affärsapplikationer och affärskritiska program. Tjänster kan representera steg i affärsprocesser och därför är en av huvudapplikationerna för detta paradigm kostnadseffektiv leverans av fristående eller sammansatta affärsapplikationer som kan "integreras inifrån och ut". Det främjar i sig tjänsteorienterad arkitektur (SOA), men det är inte samma sak som SOA. Medan SOA fokuserar på kommunikation mellan system som använder "tjänster", tillhandahåller SOP en ny teknik för att bygga smidiga applikationsmoduler med hjälp av in-memory-tjänster som arbetsenhet.

En minnestjänst i SOP kan på ett transparent sätt externiseras som en webbtjänstoperation . På grund av språk- och plattformsoberoende webbtjänststandarder omfattar SOP alla befintliga programmeringsparadigm, språk och plattformar. I SOP kretsar designen av programmen kring semantiken för serviceanrop, logisk routing och dataflödesbeskrivning över väldefinierade tjänstegränssnitt. Alla SOP-programmoduler är inkapslade som tjänster och en tjänst kan vara sammansatt av andra kapslade tjänster på ett hierarkiskt sätt med praktiskt taget obegränsat djup till denna tjänstestackhierarki. En sammansatt tjänst kan också innehålla programmeringskonstruktioner av vilka några är specifika och unika för SOP. En tjänst kan vara en extern komponent från ett annat system som nås antingen genom att använda webbtjänststandarder eller något proprietärt API via en insticksmekanism i minnet.

Medan SOP stöder de grundläggande programmeringskonstruktionerna för sekvensering, urval och iteration, är den differentierad med en rad nya programmeringskonstruktioner som ger inbyggd inbyggd förmåga inriktad på datalistmanipulation, dataintegration, automatiserad multithreading av tjänstemoduler , deklarativ kontexthantering och synkronisering av tjänster. SOP-design gör det möjligt för programmerare att semantiskt synkronisera exekveringen av tjänster för att garantera att den är korrekt, eller att deklarera en tjänstemodul som en transaktionsgräns med automatiskt commit/rollback-beteende.

Semantiska designverktyg och runtime-automatiseringsplattformar kan byggas för att stödja de grundläggande koncepten för SOP. Till exempel kan en virtuell tjänstemaskin (SVM) som automatiskt skapar tjänsteobjekt som arbetsenheter och hanterar deras sammanhang designas för att köras baserat på SOP-programmets metadata lagrad i XML och skapad av ett automatiseringsverktyg för designtid. I SOA-termer är SVM både en tjänsteproducent och en tjänstekonsument.

Fundamentala koncept

SOP-koncept ger en robust bas för ett semantiskt förhållningssätt till programmeringsintegration och applikationslogik. Det finns tre betydande fördelar med detta tillvägagångssätt:

  • Semantiskt kan det höja abstraktionsnivån för att skapa sammansatta affärsapplikationer och därmed avsevärt öka lyhördheten för förändringar (dvs. affärsflexibilitet) .
  • Ger upphov till en sammanslagning av tekniker för integration och utveckling av mjukvarukomponenter under ett enda koncept och minskar således komplexiteten i integrationen avsevärt. Detta enhetliga tillvägagångssätt möjliggör "integrering inifrån och ut" utan att behöva replikera data, vilket avsevärt minskar kostnaden och komplexiteten för den övergripande förklaringen.
  • Automatisera multi-threading och virtualisering av applikationer på granulär nivå (arbetsenhet).

Följande är några av nyckelbegreppen för SOP:

Inkapsling

I SOP är in-memory mjukvarumoduler strikt inkapslade genom väldefinierade tjänstegränssnitt som kan externiseras på begäran som webbtjänstoperationer. Denna minimala inkapslingsenhet maximerar möjligheterna till återanvändning inom andra minnestjänstmoduler såväl som över befintliga och äldre programvarutillgångar. Genom att använda tjänstegränssnitt för att dölja information utökar SOP de serviceorienterade designprinciper som används i SOA för att uppnå separation av problem mellan tjänstemoduler i minnet.

Servicegränssnitt

Ett tjänstegränssnitt i SOP är ett objekt i minnet som beskriver en väldefinierad mjukvaruuppgift med väldefinierade in- och utdatastrukturer . Tjänstegränssnitt kan grupperas i paket. Ett SOP-tjänstgränssnitt kan externiseras som en WSDL- operation och en enda tjänst eller ett paket med tjänster kan beskrivas med WSDL. Dessutom kan tjänstegränssnitt tilldelas en eller flera tjänstegrupper baserat på delade egenskaper.

I SOP fungerar runtime-egenskaper som är lagrade på servicegränssnittets metadata som ett kontrakt med tjänstens virtuella maskin (SVM). Ett exempel på användningen av runtime-egenskaper är det i deklarativ tjänstsynkronisering . Ett tjänstegränssnitt kan deklareras som ett helt synkroniserat gränssnitt, vilket innebär att endast en enda instans av den tjänsten kan köras vid varje given tidpunkt. Eller så kan den synkroniseras baserat på det faktiska värdet av nyckelindata vid körning, vilket innebär att inga två tjänsteinstanser av den tjänsten med samma värde för sina nyckelindata kan köras samtidigt. Dessutom kan synkronisering deklareras över tjänstegränssnitt som tillhör samma tjänstegrupp. Till exempel, om två tjänster, "Kreditkonto" och "Debitkonto", tillhör samma synkroniseringstjänstgrupp och synkroniseras i inmatningsfältet kontonamn, kan inga två instanser av "Kreditkonto" och "Debetkonto" med samma kontonamn köras på samma gång.

Tjänsteuppropare

En tjänsteanropare gör tjänsteförfrågningar. Det är ett instickbart gränssnitt i minnet som abstraherar platsen för en tjänsteproducent samt kommunikationsprotokollet, som används mellan konsumenten och producenten när de går över datorminnet, från SOP-runtime-miljön som en SVM. Producenten kan vara igång (dvs. i minnet), utanför processen på samma servermaskin eller virtualiserad över en uppsättning nätverksanslutna servermaskiner. Användningen av en tjänsteanropare i SOP är nyckeln till platstransparens och virtualisering. En annan viktig egenskap hos tjänsteuppropsskiktet är möjligheten att optimera bandbredd och genomströmning vid kommunikation mellan maskiner. Till exempel är en "SOAP Invoker" standardtjänstanroparen för fjärrkommunikation mellan maskiner som använder webbtjänststandarderna . Denna invoker kan bytas ut dynamiskt om till exempel producenten och konsumenten vill kommunicera genom ett packat proprietärt API för bättre säkerhet och effektivare användning av bandbredd.

Servicelyssnare

En tjänstavlyssnare tar emot tjänsteförfrågningar. Det är ett instickbart gränssnitt i minnet som abstraherar kommunikationsprotokollet för inkommande tjänsteförfrågningar som görs till SOP-runtime-miljön såsom SVM. Genom detta abstrakta lager kan SOP-runtimemiljön praktiskt taget bäddas in i minnesadressen för vilken traditionell programmeringsmiljö eller applikationstjänst som helst.

Serviceimplementering

I SOP kan en tjänstemodul antingen implementeras som en Composite eller Atomic tjänst. Det är viktigt att notera att tjänstemoduler byggda genom SOP-paradigmet har en extrovert karaktär och kan på ett transparent sätt externiseras genom standarder som SOAP eller något eget protokoll.

Semantiskt baserat förhållningssätt

En av de viktigaste egenskaperna hos SOP är att den kan stödja en helt semantisk baserad strategi för programmering. Dessutom kan detta semantiskt baserade tillvägagångssätt läggas in i en visuell miljö som är byggd ovanpå ett helt metadatadrivet lager för att lagra tjänstegränssnittet och tjänstemoduldefinitionerna. Dessutom, om SOP-körtiden stöds av en SVM som kan tolka metadatalagret, kan behovet av automatisk kodgenerering elimineras. Resultatet är en enorm produktivitetsökning under utveckling, enkel testning och betydande smidighet i driftsättningen.

Tjänstimplementering: sammansatt tjänst

En sammansatt tjänstimplementering är den semantiska definitionen av en tjänstemodul baserad på SOP-tekniker och koncept. Om du tittar inuti en svart-boxad gränssnittsdefinition av en sammansatt tjänst, kan du se andra tjänstegränssnitt kopplade till varandra och kopplade till SOP-programmeringskonstruktioner. En sammansatt tjänst har en rekursiv definition som betyder att vilken tjänst som helst inuti ("inre tjänst") kan vara en annan atomär eller sammansatt tjänst. En inre tjänst kan vara en rekursiv referens till samma innehållande sammansatta tjänst.

Programmeringskonstruktioner

SOP stöder de grundläggande programmeringskonstruktionerna för sekvensering, urval och iteration samt inbyggt förhandsbeteende. Dessutom stöder SOP semantiska konstruktioner för automatisk datamappning , översättning, manipulation och flöde över inre tjänster i en sammansatt tjänst.

Sekvensering

En tjänst inom definitionen av en sammansatt tjänst (en "inre tjänst") sekvenseras implicit genom den semantiska anslutningen av inbyggda framgångs- eller misslyckandeportar i andra inre tjänster med dess inbyggda aktiveringsport. När en inre tjänst körs framgångsrikt kommer alla inre tjänster som är anslutna till dess framgångsport att köras härnäst. Om en inre tjänst misslyckas kommer alla tjänster som är anslutna till dess felport att köras härnäst.

Urval

Logiskt urval åstadkoms genom datadrivna förgreningskonstruktioner och andra konfigurerbara konstruktioner. I allmänhet är konfigurerbara konstruktioner tjänster inbyggda i SOP-plattformen med ingångar och utgångar som kan anta ingångs-/utgångsformen för andra anslutna tjänster. Till exempel kan en konfigurerbar konstruktion som används för att filtrera utdata från tjänster ta en lista över försäljningsorder, inköpsorder eller någon annan datastruktur, och filtrera dess data baserat på användardeklarerade filteregenskaper lagrade i gränssnittet för den instansen av filterkonstruktionen . I det här exemplet blir strukturen som ska filtreras indata för den speciella instansen av filterkonstruktionen och samma struktur som representerar den filtrerade datan blir utdata från den konfigurerbara konstruktionen.

Iteration

En sammansatt tjänst kan deklareras till loop. Slingan kan vara bunden av ett fast antal iterationer med en valfri inbyggd fördröjning mellan iterationerna och den kan avslutas dynamiskt med en "service exit with success" eller "service exit with failure"-konstruktion inuti den sammansatta loopingtjänsten. Vidare kan vilket tjänstegränssnitt som helst automatiskt köras i en loop eller " foreach "-läge, om det är försett med två eller flera ingångskomponenter vid automatisk förberedelse. Detta beteende stöds vid designtid när en dataliststruktur från en tjänst är ansluten till en tjänst som tar en enda datastruktur (dvs. icke-plural) som indata. Om en runtime-egenskap för det sammansatta tjänstgränssnittet deklareras att stödja "foreach" parallellt, kan runtime-automationsmiljön automatiskt flertråda slingan och köra den parallellt. Detta är ett exempel på hur SOP-programmeringskonstruktioner ger inbyggd avancerad funktionalitet.

Datatransformation, kartläggning och översättning

Datakartläggning , översättning och transformationskonstruktioner möjliggör automatisk överföring av data över inre tjänster. En inre tjänst är förberedd att köras när den är aktiverad och alla dess indataberoenden är lösta. Alla förberedda inre tjänster inom en sammansatt tjänst körs i en parallell skur som kallas en "hypercykel". Detta är ett av sätten med vilka automatisk parallellbehandling stöds i SOP. Definitionen av en sammansatt tjänst innehåller en implicit riktad graf över inre tjänstberoenden. Runtime-miljön för SOP kan skapa en exekveringsgraf baserat på denna riktade graf genom att automatiskt instansiera och köra inre tjänster parallellt när det är möjligt.

Undantagshantering

Undantagshantering är ett körtidsfel i Java. Undantagshantering i SOP åstadkoms helt enkelt genom att ansluta felporten för inre tjänster till en annan inre tjänst, eller till en programmeringskonstruktion. Konstruktionerna "Avsluta med misslyckande" och "avsluta med framgång" är exempel på konstruktioner som används för undantagshantering. Om ingen åtgärd vidtas på felporten för en tjänst, kommer den yttre (överordnade) tjänsten automatiskt att misslyckas och standardutmatningsmeddelanden från den misslyckade inre tjänsten kommer automatiskt att bubbla upp till standardutgången för föräldern.

Transaktionsgräns

En sammansatt tjänst kan deklareras som en transaktionsgräns . Runtimemiljön för SOP skapar och hanterar automatiskt en hierarkisk kontext för sammansatta tjänsteobjekt som används som en transaktionsgräns. Detta sammanhang begår automatiskt eller återställs automatiskt vid framgångsrikt genomförande av den sammansatta tjänsten.

Serviceersättning

Särskilda sammansatta tjänster, så kallade kompensationstjänster, kan kopplas till vilken tjänst som helst inom SOP. När en sammansatt tjänst som deklareras som en transaktionsgräns misslyckas utan ett undantag som hanterar routing, skickar SOP runtime-miljön automatiskt kompensationstjänsterna som är associerade med alla inre tjänster som redan har körts framgångsrikt.

Serviceimplementering: atomtjänst

En atomtjänst är en förlängning i minnet av SOP-runtime-miljön genom ett servicenative interface (SNI) det är i huvudsak en plug-in-mekanism. Till exempel, om SOP är automatiserad genom en SVM, laddas en serviceplugin dynamiskt in i SVM när någon tillhörande tjänst förbrukas. Ett exempel på en serviceplugin skulle vara en SOAP communicator plug-in som i farten kan översätta alla indata från tjänsten i minnet till en SOAP-förfrågan från webbtjänsten, skicka den till en tjänsteproducent och sedan översätta motsvarande SOAP-svar på utdata i minnet på tjänsten. Ett annat exempel på en serviceplugin är en standarddatabas SQL-plugin som stöder dataåtkomst, modifiering och frågeoperationer. Ett ytterligare exempel som kan hjälpa till att fastställa den grundläggande betydelsen av atomära tjänster och serviceplugin är att använda en serviceinvoker som en serviceplugin för att transparent virtualisera tjänster över olika instanser av en SOP-plattform. Denna unika virtualisering på komponentnivå kallas "tjänstnätvirtualisering" för att skilja den från traditionell applikation eller virtualisering på processnivå .

Övergripande oro

SOP erbjuder betydande möjligheter att stödja övergripande problem för alla applikationer som byggs med hjälp av SOP-tekniken. Följande avsnitt definierar några av dessa möjligheter:

Serviceinstrumentering

SOP runtime-miljön kan systematiskt tillhandahålla inbyggd och optimerad profilering, loggning och mätning för alla tjänster i realtid.

Deklarativ och kontextkänslig tjänstcaching

Baserat på deklarerade nyckelinmatningsvärden för en tjänsteinstans, kan utdata från en icke tidskänslig inre tjänst cachelagras av SOP-runtimemiljön när den körs i kontexten av en viss sammansatt tjänst. När en tjänst cachelagras för särskilda nyckelinmatningsvärden, hämtar SOP-runtimemiljön de cachade utgångarna som motsvarar de nyckelinmatade ingångarna från dess tjänstcache istället för att konsumera tjänsten. Tillgängligheten av denna inbyggda mekanism för SOP-applikationsutvecklaren kan avsevärt minska belastningen på back-end-system.

Serviceutlösare

SOP tillhandahåller en mekanism för att associera en speciell typ av sammansatt tjänst, triggertjänst, till vilken annan tjänst som helst. När den tjänsten konsumeras skapar och konsumerar SOP-plattformen automatiskt en instans av den associerade triggertjänsten med en kopia i minnet av ingångarna från den triggande tjänsten. Denna förbrukning är inte störande för utförandet av den utlösande tjänsten. En tjänstutlösare kan deklareras att köras vid aktivering, misslyckande eller framgångsrikt slutförande av den utlösande tjänsten.

Kommunikation mellan tjänstemän

Förutom möjligheten att anropa vilken tjänst som helst, är Service Request Events och Shared Memory två av de inbyggda SOP-mekanismerna för kommunikation mellan tjänster. Konsumtionen av en tjänst behandlas som en händelse i SOP. SOP tillhandahåller en korrelationsbaserad händelsemekanism som resulterar i företräde för en körande komposit som har deklarerat, genom en "vänta"-konstruktion, behovet av att vänta på att en eller flera andra tjänstekonsumtionshändelser ska inträffa med specificerade indatavärden. Exekveringen av den sammansatta tjänsten fortsätter när tjänster konsumeras med specifika korrelationsnyckelingångar associerade med väntekonstruktionen. SOP tillhandahåller också ett delat minnesutrymme med åtkomstkontroll där tjänster kan komma åt och uppdatera en väldefinierad datastruktur som liknar in-/utdatastrukturen för tjänster. Den delade minnesmekanismen inom SOP kan nås programmässigt via tjänstegränssnitt.

Tjänsten åsidosätter

I SOP hanteras anpassningar genom en uppfinningsrik funktion som kallas Service Overrides. Genom denna funktion kan en tjänstimplementering statiskt eller dynamiskt åsidosättas av en av många möjliga implementeringar under körning. Denna funktion är analog med polymorfism i objektorienterad programmering . Varje möjlig åsidosättningsimplementering kan associeras till en eller flera åsidosättningskonfigurationsportföljer för att hantera aktivering av grupper av relaterade åsidosättningar genom olika SOP-applikationsinstallationer vid tidpunkten för driftsättningen .

Provisionering av konsumentkonton

Utvalda tjänster kan distribueras säkert för extern programmatisk konsumtion av ett presentationslager ( GUI ) eller andra applikationer. När tjänstekonton väl har definierats, hanterar SOP-runtime-miljön automatiskt åtkomst genom mekanismer för tillhandahållande av konsumentkonton.

säkerhet

SOP-runtimemiljön kan systematiskt tillhandahålla inbyggd autentisering och servicebehörighet . I auktorisationssyfte behandlas SOP-utvecklingsprojekt, konsumentkonton, paket och tjänster som resurser med åtkomstkontroll. På detta sätt kan SOP-runtimemiljön ge inbyggd auktorisering. Standarder eller proprietär auktorisering och kommunikationssäkerhet anpassas genom tjänsteöverstyrningar, plug-in invoker- och tjänstavlyssnarmoduler.

Virtualisering och automatisk multithreading

Eftersom alla artefakter av SOP är väl inkapslade tjänster och alla SOP-mekanismer, såsom delat minne, kan tillhandahållas som distribuerbara tjänster, kan storskalig virtualisering automatiseras av SOP-runtime-miljön. Dessutom ger den hierarkiska tjänstestacken av en sammansatt tjänst med flera exekveringsgrafer associerade med dess inre tjänster, på varje nivå, enorma möjligheter för automatiserad multi-threading till SOP-runtime-miljön.

Historia

Termen serviceorienterad programmering publicerades första gången 2002 av Alberto Sillitti, Tullio Vernazza och Giancarlo Succi i en bok som heter "Software Reuse: Methods, Techniques, and Tools." SOP, som beskrivits ovan, återspeglar vissa aspekter av användningen av termen som föreslagits av Sillitti, Vernazza och Succi.

Idag är SOP-paradigmet i de tidiga stadierna av mainstreamadoption. Det finns fyra marknadsdrivkrafter som driver detta antagande:

  • med flera kärnor : på grund av problem med värmeavledning med ökande processorklockhastigheter över 4 GHz, har ledande processorleverantörer som Intel vänt sig till flerkärnig arkitektur för att leverera ständigt ökande prestanda. Se artikeln "The Free Lunch Is Over " Denna förändring i design tvingar fram en förändring i hur vi utvecklar våra programvarumoduler och applikationer: applikationer måste skrivas för samtidighet för att kunna använda flerkärniga processorer och att skriva samtidiga program är en utmaning uppgift. SOP ger en inbyggd möjlighet för automatisk multithreading .
  • Applikationsvirtualisering : SOP främjar inbyggd mikrokontroll över platstransparens för tjänstekomponenterna i alla tjänstemoduler . Detta resulterar i automatisk och granulär virtualisering av applikationskomponenter (mot en hel applikationsprocess) över ett kluster eller rutnät av SOP-runtime-plattformar.
  • Tjänsteorienterad arkitektur (SOA) och efterfrågan på integrerade och sammansatta applikationer: i början kommer antagandet av SOP att följa adoptionskurvan för SOA med en liten eftersläpning. Detta beror på att tjänster som genereras genom SOA enkelt kan monteras och konsumeras genom SOP. Ju mer webbtjänster sprids, desto mer är det vettigt att dra fördel av SOP:s semantiska natur. Å andra sidan, eftersom SOA är inneboende i SOP, ger SOP ett kostnadseffektivt sätt att leverera SOA till vanliga marknader.
  • Programvara som en tjänst (SaaS): kapaciteten hos de nuvarande SaaS-plattformarna kan inte hantera anpassnings- och integrationskomplexiteten som krävs av stora företag. SOP kan avsevärt minska komplexiteten i integration och anpassning. Detta kommer att driva SOP in i nästa generations SaaS-plattformar.

Se även

externa länkar

Hämtad från " https://en.wikipedia.org/w/index.php?title=Service-oriented_programming&oldid=1140544347 "