Händelsedriven SOA

Händelsedriven SOA är en form av tjänsteorienterad arkitektur (SOA), som kombinerar intelligensen och proaktiviteten hos händelsedriven arkitektur med de organisatoriska förmågor som finns i tjänsteerbjudanden . Innan händelsedriven SOA orkestrerade den typiska SOA-plattformen tjänsterna centralt, genom fördefinierade affärsprocesser, förutsatt att det som redan skulle ha utlösts definieras i en affärsprocess. Denna äldre metod (ibland kallad SOA 1.0) tar inte hänsyn till händelser som inträffar över eller utanför specifika affärsprocesser. Därför tas inte hänsyn till komplexa händelser, där ett mönster av aktiviteter – både icke-schemalagda och schemalagda – ska utlösa en uppsättning tjänster i traditionell SOA 1.0-arkitektur.

SOA 2.0

SOA 2.0-arkitektur, ("händelsedriven SOA"), låter affärsanvändare övervaka, analysera och berika händelser för att skapa kopplingar mellan olika händelser som först inte verkar vara intuitivt uppenbara. Detta gör dessa berikade händelser synliga för andra, särskilt affärsanalytiker eller marknadschefer, och gör det också möjligt för SOA 2.0-systemet att eventuellt automatisera åtgärder för att ta itu med något unikt mönster.

SOA 2.0 är förmågan att skapa affärshändelser på hög nivå från många systemhändelser på låg nivå. Händelser skapas genom att filtrera realtidsdata (från mellanprogram, applikationer, databaser och webbtjänster, till exempel) och ingjuta den med definierande detaljer såsom beroenden eller orsakssamband som upptäckts genom att korrelera andra händelser.

Om det är tydligt, genom de berikade evenemangen som produceras av en SOA 2.0-miljö, att antalet övergivna varukorgar har eskalerat under de senaste dagarna, kan ett meddelande till marknadsavdelningen initiera forskning om vad konkurrenter har gjort för att få kunder att köpa produkter på annat håll. Fanns det en vanlig produkt i de flesta kundvagnar? Om så är fallet, vilka priser erbjuds av konkurrenterna?

I praktiken bearbetas detta förhållande mellan strömmade händelser genom en kausal vektormotor, som utför en uppslagning baserat på nyligen visade händelser och tilldelar en orsaksvektor till en händelse om ett samband upptäcks. Om A orsakar B, kontrollerar kausalvektormotorn om B:s kausalvektorregelindex innehåller en referens till A. Motorn kan hantera händelser för olika transaktioner samtidigt, kanske i en annan ordning än de inträffade.

Till skillnad från sekventiella eller procedursystem (där klienter måste polla för ändringsförfrågningar), tillåter händelsestyrd SOA system och komponenter att svara dynamiskt, i realtid, när händelser inträffar. SOA 2.0 kompletterar och utökar SOA 1.0 genom att introducera långvariga bearbetningsmöjligheter.

Långvarig bearbetningsförmåga gör det möjligt för arkitekturen att samla in olika asynkrona händelser under en lång tidsperiod och korrelera dessa händelser till orsakssamband. SOA 2.0 händelsemönster kan designas och implementeras för att leta efter händelserelationer som sträcker sig över dagar, veckor eller månader; och när vissa kriterier är uppfyllda, utlösa en affärsprocess för att ta itu med händelsemönstret.

SOA 2.0 händelsedriven programmering är uppbyggd kring konceptet av frikopplade relationer mellan eventproducenter och eventkonsumenter: en eventkonsument bryr sig inte om var eller varför ett event inträffar; snarare är det oroligt att det kommer att åberopas när händelsen har inträffat. System och applikationer som skiljer evenemangsproducenter från evenemangskonsumenter förlitar sig vanligtvis på en evenemangsledare eller kanal. Denna kanal innehåller en händelsekö som fungerar som en mellanhand mellan händelseproducenter och händelsehanterare.

Prototypiskt SOA 2.0-paradigm

Det prototypiska SOA 2.0-paradigmet innehåller fyra väsentliga element:

flera systemhändelser på låg nivå som var för sig inte verkar ha något samband, men genom mönsterdetektering genom att jämföra dessa många händelser blir någon ovanlig eller mindre uppenbar korrelation tydlig;
en viss mängd databerikning genom infusion av relaterad information till varje händelse för att tydligare illustrera hur de många händelserna är relaterade;
ett triggervillkor som när det inte är uppfyllt skapas inte händelsen på affärsnivå, men när triggervillkoret är uppfyllt skapas affärshändelsen på högre nivå;
någon mänsklig eller automatiserad process som anropas när triggerhändelsen nås.

SOA 2.0 Web Services kan komponeras på två sätt: orkestrering och koreografi. Vid orkestrering tar en central process kontroll över de inblandade webbtjänsterna och koordinerar utförandet av olika operationer på de webbtjänster som är involverade i verksamheten. De inblandade SOA 2.0-tjänsterna vet inte (och behöver inte veta) att de ingår i en sammansättning eller en högre affärsprocess. Endast den centrala koordinatorn för orkestreringen vet detta, så orkestreringen är centraliserad med explicita definitioner av operationer och ordningen för anrop av SOA 2.0-tjänster.

Koreografi å andra sidan förlitar sig inte på en central koordinator. Snarare vet varje SOA 2.0-tjänst som är inblandad i koreografin exakt när de ska utföra sina operationer (baserat på definierade triggerkriterier) och vem de ska interagera med. Koreografi är ett samarbete inriktat på utbyte av budskap. Alla deltagare i koreografin måste vara medvetna om affärsprocessen, operationer som ska utföras, meddelanden som ska utbytas och tidpunkten för meddelandeutbyten.

BPEL följer orkestreringsparadigmet. Koreografi omfattas av andra standarder, såsom WSCI (Web Services Choreography Interface) och WS-CDL (Web Services Choreography Description Language).

Flera systemhändelser på låg nivå

Orsakssamband är inneboende i världen omkring oss och är inneboende för vårt beslutsfattande. Den mänskliga intelligensen bearbetar och samlar in dessa relationer snabbare än vad nuvarande konstgjorda beräkningsförmåga kan. Ett av de grundläggande hindren inom artificiell intelligens är frånvaron av en automatiserad förmåga att relatera händelser tillsammans som när en människa använder mänsklig intuition.

Med hjälp av en kausal vektormotor kan uppfattningen av kausalitet förbättras under lämpliga spatiotemporala förhållanden baserat på strukturella och tidsmässiga regler skrivna i motorn. Perception av komplex kausal semantik, såsom additiva, medierade och dubbelriktade kausaliteter måste kodas så att motorn kan skilja mellan händelser som är relaterade och de som bara verkar vara relaterade men i själva verket inte är det.

Motorn använder övervägande kausal vektorförändringshastighet för att koda förhållandet mellan händelserna och etablerar en partiell ordning i vilken den validerar kausaliteten som uppfattas mellan flera händelser. Motorn spelar och spelar upp händelsesekvensen i olika tidsordning för att sluta sig till vad som kan vara relaterade topologiska samband och jämför dessa repriser med regler som förprogrammerats av en analytiker .

Flera systemhändelser på låg nivå bearbetas av Causal Vector Engine och jämförs mot dessa regler för att utlösa affärshändelser på högre nivå. Den gör detta genom en Causality Vector Engine (CVE) konsolapplikation som visar händelser i realtid för affärsanalytiker. Där strömmar av händelser kan observeras när de inträffar, ungefär som en aktiekurs, har CVE-konsolappen flera fönster som listar samma händelser i olika sammanhang, så att affärsanalytikerna kan se vad CVE gör med relationerna mellan dem.

Det sekventiella fönstret visar händelser i datum-tidsstämpelordning, ett eller flera andra fönster i olika ordningsföljder när CVE arbetar genom listan med regler och skapar underförstådda relationer mellan händelserna. Olika knappar och kontroller finns i konsolapplikationen som gör det möjligt för affärsanalytikerna att skapa relationer mellan händelser i farten och definiera regler som svarar på dessa relationer.

Affärsanalytiker kan ingjuta ytterligare definierande detaljer genom en SQL-frågasats kopplad till en regel eller händelsekontext. CVE-appen fungerar ungefär som en modern aktiehandelsapplikation som fondförvaltare använder för att hantera risker. Ett exempel på en CVE-applikation och motor kan ses i SILK.

Databerikning

De flesta Enterprise Service Bus- implementeringar (ESB) innehåller en funktion som kallas " medling ". Till exempel är medlingsflöden en del av WebSphere enterprise service bus intercept. Mule stöder också medlingsflöden. Medlingsflöden ändrar meddelanden som skickas mellan befintliga tjänster och klienter som använder dessa tjänster. Ett medlingsflöde förmedlar eller ingriper för att tillhandahålla funktioner, såsom meddelandeloggning, datatransformation och routing, vanligtvis kan funktionerna implementeras med hjälp av Interception Design Pattern.

När meddelanden passerar genom ESB, berikar ESB de meddelanden som är avsedda för en kanal som övervakar en affärshändelse på hög nivå. Det vill säga, för varje meddelande kan ESB fråga en databas för att erhålla ytterligare information om någon dataenhet i meddelandet. Baserat på kund-ID kan ESB-medlingsflödet till exempel få postnumret som kunden är bosatt i. Eller, baserat på IP-adressen för den ursprungliga begäran från slutanvändaren, kan ESB-medlingsflödet slå upp vilket land, stat eller vilket land län där IP-adressen finns i.

Dessa exempel representerar databerikning, konceptet att tillföra ytterligare värde till befintlig data, baserat på avsikten med att affärshändelsen på hög nivå så småningom ska utlösas.

Medling flödar

Ett ESB- förmedlingsflöde är en av komponenttyperna i en Service Component Architecture ( SCA). Som alla SCA-komponenter får programmet tillgång till ett medlingsflöde genom exporter som det tillhandahåller, och medlingsflödet vidarebefordrar meddelanden till andra externa tjänster via import. Specialtyper av import och export för JMS , kallade JMS-bindningar, gör det möjligt för utvecklare att specificera bindningskonfigurationen och skriva datahanteringskod. Medlingsflödet består av en serie medlingsprimitiver som manipulerar meddelanden när de strömmar genom bussen .

När utvecklarna har kodat den anpassade bindningen för både export och import kan de börja fokusera på medlingsflödeskomponenten. I WebSphere Integration Developer assembly editor görs detta av JMS Custom Binding Mediation Component där varje operation på flödeskomponentens gränssnitt representeras av en begäran och ett svar.

Service Data Objects ) tillhandahåller ett enhetligt ramverk för utveckling av dataapplikationer. Med SDO behöver utvecklare inte vara bekanta med något specifikt API för att komma åt och använda data. Genom SDO arbetar utvecklare helt enkelt med data från flera datakällor, såsom relationsdatabaser, enhets-EJB-komponenter, XML-sidor, webbtjänster, Service Component Architecture och JavaServer Pages-sidor.

Medlingsflöden är helt oberoende av de bindningar som används vid import och export. Faktum är att syftet med att ha en konvertering till en SDO DataObject-instans utanför flödesimplementeringen beror på att medlingsflöden då kan byggas utan kunskap om protokollet och formatet med vilket meddelanden skickas till och från medlingsmodulen.

Triggervillkor på affärsnivå

kundintelligens i realtid, marknadsföringsautomatisering och kundlojalitetslösningar, bland andra funktioner. Affärsobjekt modellerar verkliga enheter i arkitekturen som kunder, konton, lån och resplaner. När tillståndet för ett av dessa objekt ändras och en övervakningsagent märker att denna ändring är betydande (jämfört med listan över kriterier att övervaka), skapas en händelse och skickas till andra övervakningsagenter.

Till exempel kan upptäckten av ett verkligt affärsproblem eller möjlighet leda till ökade intäkter. Om en kund avbryter en order kan extra tillverkningskapacitet minska lönsamheten i produktionsomgången. En SOA 2.0-händelse kunde meddela marknadsavdelningen att den skulle skapa en speciell försäljningskampanj som skulle sälja över överkapaciteten och därigenom återerövra den ursprungliga lönsamma kostnaden per enhet.

Automatisk övervakning av händelser i operativa affärsprocesser när processer körs för att se om några omedelbara åtgärder behöver vidtas antingen inom eller utanför företaget. Dessa övervakningsagenter testar kontinuerligt för specifika affärsförhållanden och förändringar i affärsverksamheten. Vid behov varnar agenterna människor, ger rekommendationer, skickar meddelanden till andra applikationer eller åberopar hela affärsprocesser när sådana förhållanden eller förändringar inträffar.

Resulterande affärsprocess

En utlöst affärsprocess bör direkt stödja intäktstillväxt med kostnadsbegränsning, lyhördhet för affärsförhållanden eller förmåga att utöva nya marknadsmöjligheter. Resulterande affärsprocesser kan också mäta operativa framsteg mot att uppnå mål, kontrollera operativa kostnader genom att kommunicera precis vad som behövs till bara vem som behöver veta, eller rapportera prestandastatus för nyckelprocesser till nyckelbeslutsfattare.

SOA 2.0 konceptuella exempel

Övergiven kundvagn

Till exempel kan du konstruera en CRM-händelse från ett meddelande om "övergiven kundvagn" (analys av transaktionen, kund-ID och tid), använda andra filter för att extrahera värdet av varor i kundvagnen och använda systemets korrelationsmöjligheter för att lägg till orsaksindikatorer som om handelswebbplatsen hade prestandaproblem. Ditt CRM-evenemang kan också innehålla kundvärde eller rankning från kunddatabasen...

Ingenjörsfel

Till ett annat exempel, baserat på de typer av oberoende servicesamtal som tas emot, kan SOA 2.0-plattformen identifiera ett produktdefekt genom att upptäcka det underliggande mönstret för de separata klagomålen, och sedan utlösa en varning till konstruktion eller produktion av den möjliga defekten.

SOA 2.0 implementeringar

En mekanism som kan användas från de flesta SOA 1.0 Enterprise Service Bus- implementeringar är publicerings-/prenumerationsfunktionen . Genom att implementera ESB-funktionalitet som Pub/Sub-meddelanden behövs ingen avancerad kunskap om systemhändelser för att skapa SOA 2.0-meddelandemönster. Efter att ett företag har implementerat många publiceringsfunktioner, kan SOA- mellanvaruanalytiker sätta igång med uppgiften att skapa strategier för vilka av de tillgängliga publiceringsmeddelandena som skulle kunna sättas samman till ett unikt mönster för att upptäcka en SOA 2.0-berikad utlösare.

Causal Vector Engine (CVE) mekanik implementeras enkelt, med en expanderbar vy av SQL-konstruktioner skrivna i lagrade procedurer . Om A orsakar B, och kausalitet måste inträffa inom N antal transaktioner, SQL ORDER BY tidsstämpelsats en resultatuppsättning som ökar en räknare för alla transaktioner som inträffade inom en tidsram, N antal matchande B till förekomst A-transaktioner. Skapandet av ytterligare lagrade procedurer åstadkoms genom CVE-konsolapplikationen eller genom att använda någon standarddatabasutvecklares verktygslåda.

Medicinska tillämpningar

Domänalgoritmer, såsom feber/influensa/infektionsdomänlogik i den citerade referensen, används för att härleda SQL-kod som tillämpar de valda affärsreglerna på användningsfallet. Att använda CVE:er i SOA-miljöer förbättrar verksamhetens smidighet eftersom tillämpningen av SOA 2.0-principer identifierar affärsmöjligheter som annars skulle ha missats eller identifierats mycket senare.

Funktionell magnetisk resonanstomografi (fMRI) med hjälp av Granger kausalitetsanalys (GCA) upptäcker kausala effekter bland hjärnregioner. Resultaten av ett provtest visade positiv orsakseffekt mellan rFIC och den dorsala främre cingulate cortex (dACC).

Oracle Business Intelligence

Oracle CVE Analytical Engine använder en uppsättning teoretiska modeller, som var och en utvärderar en del eller alla data. När en affärsanalytiker konfigurerar orsaksfaktorer anger han/hon kriterier som anger vilka modeller som ska beakta vilken orsaksfaktor.

Se även