Undersöker Red Hat JBoss BRMS-implementeringsarkitekturer för regler och händelser (del I)

(Artikelgäst författad tillsammans med John Hurlocker, Senior Middleware Consultant på Red Hat i Nordamerika)


Under veckans tips &tricks kommer vi att sakta ner och titta närmare på eventuellt rött Hat JBoss BRMS distributionsarkitekturer.

När vi talar om implementeringsarkitekturer syftar vi på de alternativ du har för att distribuera ett regel- och/eller händelseprojekt i ditt företag.

Detta är den faktiska runtime-arkitekturen som du behöver planera för i början av dina designfaser, för att avgöra för ditt företag och din infrastruktur vad det bästa sättet skulle vara att distribuera din kommande applikation. Det kommer med största sannolikhet också att ha en effekt på hur du designar den faktiska applikationen som du vill bygga, så att vara medveten om dina alternativ bör bidra till att dina projekt blir framgångsrika.

Detta kommer att vara en serie i flera delar som kommer att introducera implementeringsarkitekturerna i etapper, med start denna vecka med de två första arkitekturerna.

Möjligheterna

En regeladministratör eller arkitekt arbetar med applikationsteam för att designa runtime-arkitekturen för regler och beroende på organisationens behov kan arkitekturen vara någon av följande arkitekturer eller en hybrid av designen nedan.

I den här serien kommer vi att presentera fyra olika implementeringsarkitekturer och diskutera en designtidsarkitektur samtidigt som vi ger fördelarna och nackdelarna för var och en för att möjliggöra utvärdering av var och en för dina egna behov.

De grundläggande komponenterna i dessa arkitekturer som visas i de medföljande illustrationerna är:

• JBoss BRMS-server
• Regelutvecklare/affärsanalytiker
• Versionskontroll (GIT)
• Implementeringsservrar (JBoss EAP)
• Kunder som använder din app

Illustration 1:Regler i tillämpningen

Regler som används i applikationen

Den första arkitekturen är den mest grundläggande och statiska av alla alternativ du har för att distribuera regler och händelser i din företagsarkitektur.

Ett deployerbart regelpaket (t.ex. JAR) ingår i din applikations distribuerbara artefakt (t.ex. EAR, WAR).

I den här arkitekturen fungerar JBoss BRMS-servern som ett arkiv för dina regler och ett designtidsverktyg.
Illustration 1 visar hur JBoss BRMS-servern är och förblir helt frånkopplad från driftsättnings- eller körtidsmiljön.

Proffs

• Typiskt bättre prestanda än att använda en regelexekveringsserver eftersom regelexekveringen sker inom samma JVM som din applikation

Nackdelar

• Har inte möjlighet att skicka regeluppdateringar till produktionsapplikationer
  • kräver en fullständig ombyggnad av programmet
  • kräver en fullständig omtestning av applikationen (Dev – QA – PROD)

Illustration 2:KieScanner distribution

Regler skannade från applikation

En andra arkitektur som du kan använda för att modifiera den tidigare,
är att lägga till en skanner till din applikation som sedan övervakar efter nya regel
och händelseuppdateringar och drar in dem när de distribueras i ditt företag arkitektur.

JBoss BRMS API innehåller en KieScanner som övervakar regelförrådet
för nya regelpaketversioner. När en ny version är tillgänglig
kommer den att hämtas av KieScanner och laddas in i din applikation,
som visas i illustration 2.

Cool Store-demoprojektet ger ett exempel som visar användningen av JBoss BRMS KieScanner , med ett exempel på implementering som visar hur du skannar ditt regellager efter det senaste nybyggda paketet.

Proffs

• Du behöver inte starta om dina applikationsservrar
  • I vissa organisationer kan implementeringsprocessen för applikationer vara mycket lång.
  • detta låter dig skicka regeluppdateringar till dina applikationer i realtid

Nackdelar

• Behöver skapa en distributionsprocess för att testa regeluppdateringarna med applikationen/apparna
  • risk att trycka in felaktig logik i applikation(er) om processen ovan inte testas noggrant

Nästa

Nästa gång kommer vi att gräva i de två återstående implementeringsarkitekturerna som ger dig en Execution Server-distribution och en hybrid implementeringsmodell att utnyttja flera element i en enda arkitektur. Slutligen kommer vi att täcka en designtidsarkitektur som dina team kan använda när de skapar och underhåller reglerna och händelserna i ditt företag.