Įdiegti pritaikomą ESB su „Java“

Apsvarstykite įmonę, kurioje turite nevienalyčių programų, kurias galbūt teikia skirtingos komandos, kurios turi bendrauti tarpusavyje, tačiau turi šiuos apribojimus:

• Kiekviena programa nebūtinai sukurta naudojant tą pačią technologiją ir gali nekalbėti su kitais, naudojant savo vietinį iškvietimo mechanizmą, pvz., J2EE programą ir .Net programą.
• Geriausia, jei kiekviena programa neturėtų pakeisti savo užklausų į tikslinės programos suprantamą formatą. Be to, įmonė turi daug programų, naudojančių tikslinę programą.
• Paslaugos komponentai turėtų naudoti jiems natūralų iškvietimo ar užklausų mechanizmą. Pvz., Esama „J2EE“ programa gali priimti užklausas tik per „Java Message Service“ (JMS).
• Įmonė eina link architektūros, kurioje programa pati rūpinasi tik vienu, ką ji žino, ir dviem, ką ji turėtų perduoti kaip parametrus, kai nori gauti kitos įmonės įmonėje paslaugas.

Kiti apribojimai gali pareikalauti turėti infrastruktūrą, leidžiančią nevienalytėms programoms sklandžiai integruotis nekeičiant jų dizaino. Įmonės paslaugų magistralė (ESB) yra vienas iš būdų realizuoti tokią įmonės integracijos architektūrą.

Nors kiekviena įmonė greičiausiai sukurs savo ESB savo unikaliu būdu, svarstant ESB apibrėžimą svarbu nepamiršti lankstumo. Nėra fiksuoto požiūrio į jo statybą. Idėja yra turėti ryšio sluoksnį, kuris optimizuotų paslaugų vartotojų ir paslaugų teikėjų sąveiką, kuris galėtų reaguoti į įvykius, pranešimus ar į paslaugas orientuotus kontekstus.

Šiame straipsnyje aptariamas išplėstinio „Java“ pagrindu sukurto ESB kūrimo metodas, palaikantis dažniausiai pasitaikančius ESB funkcinius reikalavimus.

Bendrieji ESB reikalavimai

ESB bendri reikalavimai taip pat yra dažniausiai naudojamos funkcijos:

1. Maršrutas: ESB turėtų sukurti veiksmingą ir lanksčią maršruto nustatymo mechanizmą.
2. Transformacija: Aptarnavimo komponentui nereikia žinoti tikslinės paslaugos, kuria jis gali pasinaudoti, užklausos formato. Remdamasis prašytoju ir tikslu, ESB turėtų sugebėti pritaikyti užklausai tinkamą transformaciją, kad taikinys galėtų ją suprasti.
3. Daugiaprotokolinis transportas: ESB diegimas, kuriame kalbama tik apie JMS arba tik su interneto paslaugomis, neturi didelės vertės. Tai turėtų būti pakankamai išplėsta, kad būtų palaikomi keli pranešimų protokolai, atsižvelgiant į įmonės poreikius.
4. Saugumas: Jei reikia, ESB turėtų patvirtinti prieigą prie skirtingų paslaugų komponentų ir suteikti prieigą prie jų.

1 paveiksle parodyti pagrindiniai ESB architektūros komponentai. Jame yra trys platūs skyriai:

1. Imtuvas: ESB atskleidžia skirtingas sąsajas, leidžiančias kliento programoms siųsti pranešimus ESB. Pavyzdžiui, servletas gali priimti HTTP užklausas ESB. Tuo pačiu metu jūs galite turėti MDB (pranešimais pagrįstą pupelę), klausantį JMS paskirties vietos, kur kliento programos gali siųsti pranešimus.
2. Šerdis: Tai yra pagrindinė ESB įgyvendinimo dalis. Jis tvarko maršrutus ir transformacijas bei taiko saugumą. Paprastai jis susideda iš MDB, kuris gauna gaunamas užklausas ir tada, remdamasis pranešimo kontekstu, taiko atitinkamą transformaciją, maršrutą ir saugumą. Išsamią informaciją apie maršruto parinkimą, transportavimą, transformavimą ir saugumą galima nurodyti XML dokumente (aptariama netrukus).
3. Dispečeris: Visi išvykstamojo transporto tvarkytojai patenka į šią ESB dalį. Į ESB galite prijungti bet kurį savavališką transporto tvarkytuvą (el. Paštą, faksą, FTP ir kt.).

Visos šios ESB dalys suklijuojamos XML dokumentu, kuriame išvardyti visi maršrutai, kuriais veikia ESB. Skirtingi transporto tvarkymo įrenginiai, transformatoriai ir pakartotinių bandymų politika bei jų ryšys su skirtingais maršrutais yra sujungiami per šį XML dokumentą.

ESBConfiguration.xml

XML sąrašas—ESBConfiguration.xml, kuris pateikiamas žemiau, suteikia mums keletą idėjų apie ESB veikimą. Pagrindiniai ES dominantys elementai ESBConfiguration.xml yra šie:

1. Pupelės: Šiame elemente yra nulis ar daugiau Pupelė elementai.
2. Pupelė: Šis elementas iš esmės apibrėžia mūsų kūrimo ir konfigūravimo būdą Pupelė klasė. Jis turi šiuos atributus:
   • vardas: Unikalus pavadinimas, kurį galima naudoti norint nurodyti šią pupelę.
   • className: Pilnai kvalifikuotas pupelių klasės pavadinimas.
   Kiekvienoje pupelėje gali būti nulis ar daugiau Nuosavybė elementai kaip vaikai. Kiekvienas Nuosavybė elementas turi atributą vardas kad jį ir vaiko tipo elementą identifikuoja Vertė kad turi turto vertę. Šios savybės iš tikrųjų yra „JavaBeans“ stiliaus klasės nariai, galintys sukonfigūruoti pupelių klasę.
3. „RetryPolicies“: Šiame elemente yra nulis ar daugiau Pakartoti politiką vaikai.
4. Pakartoti politiką: Šis elementas apibrėžia pakartotinio nurodyto maršruto politiką. Jis turi atributą vardas kuri gali būti naudojama jai nurodyti. Jame yra du vaikų elementai, pavadinti „MaxRetries“ ir „RetryInterval“.
5. Maršrutas: „EsbConfiguration“ šakniniame elemente gali būti nulis ar daugiau šio tipo antrinių elementų. Iš esmės tai yra ESB kelias. Jis turi šiuos atributus:
   • vardas: Unikalus pavadinimas, kurį galima naudoti nurodant šį maršrutą.
   • retryPolicyRef: Nuoroda į pakartojimo politiką. Jis turėtų atitikti Pakartoti politiką elementas vardas atributas.
   • transformatoriusRef: Nuoroda į pupelę, vaizduojančią transformatorių. Jis turėtų atitikti Pupelė elementas vardas atributas.
   Maršrutas elementas gali turėti vieną ar kelis tipo antrinius elementus TransportHandlerRef. Šis vaikas iš esmės nurodo pupelę, atstovaujančią tinkamam transporto tvarkytojui, kuris turėtų būti naudojamas šiame maršrute, ir tos pupelės viešąjį metodo pavadinimą, kuris turėtų būti naudojamas norint išsiųsti pranešimą. Pasirinktinai Maršrutas elementas gali turėti vieną DeadLetterDestination vaikas, nurodantis kitą maršrutą, nurodantį negyvų raidžių paskirtį.

XML dokumento pavyzdys, EsbConfiguration.xml, rodomas žemiau:

                              qcf-1 myCreditQueue //www.tax.com/calc failas: /// C: /temp/esb/transform/xsl/credit.xsl failas: /// C: / temp / esb / transform / custom / configManager. ypatybės „qcf-1“ pristatymas. „Qcf-1“ eilutė „System.DL.Queue qcf-1“ sistema. Klaida. „Qcf-1“ eilės pristatymas. „Request“. 10 100 10 500 eilutė. 

ESB elgesys

ESBConfiguration.xml dokumentas diktuoja mūsų ESB elgesį. „EsbRouter“ MDB įkelia šią XML iš vietos, nurodytos jos diegimo apraše. Tada joje esanti informacija yra suskirstyta į duomenų struktūrą, pavaizduotą 2 paveiksle.

„EsbRouter“ naudojasi šia informacija (per „EsbConfigManager“), norint iššifruoti tinkamą maršrutą, transformaciją, jei tokia bus, saugumo patvirtinimo patikrinimą ir tt kaip daugiaprocesinių pranešimų persiuntimas ir pranešimų transformavimas) ESB, tokiu būdu leidžiant jį labai išplėsti ir pritaikyti.

Kaip rodo klasės diagrama, ESB projekte yra dvi svarbios sąsajos: „TransformHandler“ ir TransportHandler. Jie leidžia jums parašyti specifinį nukreiptų pranešimų transformavimą ir transportavimą. Šios įgyvendinimo klasės gali būti sujungtos su maršrutais per Pupelė elementai „EsbConfiguration“. Pavyzdžiui, imtyje EsbConfiguration.xml Šiame pupelių apibrėžime nurodomas transporto tvarkytojas:

   „myQCF myCreditQueue“ 

Šis transporto prižiūrėtojas gali būti nurodytas a Maršrutas mazgas įterpiant a TransportHandler vaikas taip: