Programovanie

Implementujte prispôsobiteľný ESB s programom Java

Zvážte podnik, v ktorom máte heterogénne aplikácie, ktoré prípadne dodávajú rôzne tímy a ktoré musia navzájom komunikovať, ale majú nasledujúce obmedzenia:

  • Každá aplikácia nemusí byť nevyhnutne vytvorená pomocou rovnakej technológie a nemusí hovoriť s ostatnými pomocou svojho natívneho vyvolávacieho mechanizmu, napríklad aplikácie J2EE a .Net.
  • Výhodne by každá aplikácia nemala transformovať svoje požiadavky do formátu, ktorému rozumie cieľová aplikácia. Okrem toho má podnik mnoho aplikácií, ktoré používajú cieľovú aplikáciu.
  • Komponenty služby by mali používať mechanizmus vyvolania alebo vyžiadania, ktorý je pre nich prirodzený. Napríklad existujúca aplikácia J2EE môže prijímať požiadavky iba prostredníctvom služby Java Message Service (JMS).
  • Podnik sa uberá smerom k architektúre, kde sa aplikácia zaoberá iba jedným, tým, čo vie, a dvoma, čím by mala prejsť ako parametre, keď chce v rámci podniku získať služby inej aplikácie.

Ďalšie obmedzenia môžu vyžadovať, aby ste mali infraštruktúru, ktorá umožňuje heterogénnym aplikáciám bezproblémovú integráciu bez zmeny ich dizajnu. Zbernica podnikových služieb (ESB) je jedným zo spôsobov realizácie takejto architektúry podnikovej integrácie.

Aj keď každý podnik pravdepodobne vytvorí svoj ESB svojim vlastným jedinečným spôsobom, je dôležité mať na pamäti flexibilitu pri zvažovaní definície ESB. K ich vybudovaniu neexistuje pevný prístup. Cieľom je vytvoriť vrstvu prepojenia, ktorá optimalizuje interakcie medzi spotrebiteľmi služieb a poskytovateľmi služieb a ktorá bude schopná reagovať na kontexty zamerané na udalosti, správy alebo služby.

Tento článok pojednáva o prístupe k budovaniu rozšíriteľného ESB založeného na prostredí Java, ktorý podporuje najbežnejšie funkčné požiadavky ESB.

Spoločné požiadavky na ESB

Bežné požiadavky na ESB sú tiež jeho najbežnejšie používané vlastnosti:

  1. Smerovanie: ESB by mal poskytovať efektívny a flexibilný mechanizmus smerovania.
  2. Transformácia: Komponent služby by nemal potrebovať poznať formát požiadavky cieľovej služby, ktorú by mohla vyvolať. Na základe žiadateľa a cieľa by mal byť ESB schopný uplatniť na žiadosť príslušnú transformáciu, aby jej cieľ porozumel.
  3. Multiprotokolová preprava: Implementácia ESB, ktorá hovorí iba s JMS alebo iba s webovými službami, nemá veľkú hodnotu. Mal by byť dostatočne rozšíriteľný na podporu viacerých protokolov správ v závislosti od potrieb podniku.
  4. Zabezpečenie: V prípade potreby by ESB mala vynútiť autentifikáciu a autorizáciu pre prístup k rôznym komponentom služby.

Obrázok 1 zobrazuje hlavné architektonické komponenty ESB. Má tri široké priehradky:

  1. Prijímač: ESB sprístupňuje rôzne rozhrania, ktoré umožňujú klientskym aplikáciám odosielať správy na ESB. Napríklad servlet môže prijímať požiadavky HTTP na ESB. Zároveň by ste mohli mať MDB (fazuľa riadenú správami) počúvajúcu na cieľovom mieste JMS, kde môžu klientske aplikácie odosielať správy.
  2. Jadro: Toto je hlavná časť implementácie ESB. Zaoberá sa smerovaním a transformáciou a uplatňuje bezpečnosť. Spravidla sa skladá z MDB, ktorý prijíma prichádzajúce požiadavky, a potom na základe kontextu správy použije príslušnú transformáciu, smerovanie a zabezpečenie. Podrobnosti o smerovaní, transporte, transformácii a bezpečnostných informáciách je možné určiť v dokumente XML (o ktorom sa čoskoro hovoríme).
  3. Dispečer: Všetci obsluhovatelia odchádzajúcej dopravy spadajú pod túto časť ESB. K ESB môžete pripojiť ľubovoľný obslužný program na prepravu (e-mail, fax, FTP atď.).

Všetky tieto časti ESB sú navzájom spojené dokumentom XML, ktorý obsahuje zoznam všetkých trás, na ktorých ESB funguje. Rôzne politiky manipulácie s transportom, transformátory a pokusy a ich pripojenie k rôznym trasám sú všetky prepojené prostredníctvom tohto dokumentu XML.

ESBConfiguration.xml

Zoznam XML -ESBConfiguration.xml, ktorá sa zobrazuje nižšie - poskytuje určitú predstavu o fungovaní ESB. Hlavné prvky záujmu v ESBConfiguration.xml sú tieto:

  1. Fazuľa: Tento prvok obsahuje nulu alebo viac Bean prvkov.
  2. Bean: Tento prvok v zásade definuje spôsob, akým vytvárame a konfigurujeme a Bean trieda. Má nasledujúce atribúty:
    • názov: Jedinečný názov, ktorým sa dá odkazovať na túto fazuľu.
    • className: Plne kvalifikovaný názov triedy fazule.
    Každá fazuľa môže mať nulu alebo viac Nehnuteľnosť prvky ako deti. Každý Nehnuteľnosť prvok má atribút názov ktorá ho identifikuje a podradený prvok typu Hodnota ktorá drží hodnotu vlastnosti. Tieto vlastnosti sú v skutočnosti členmi triedy v štýle JavaBeans, ktorí môžu nakonfigurovať triedu bean.
  3. Pravidlá opakovania: Tento prvok obsahuje nulu alebo viac RetryPolicy deti.
  4. RetryPolicy: Tento prvok definuje politiku opakovania pre danú trasu. Má prívlastok názov tým sa dá na to odkazovať. Má dva podradené prvky pomenované MaxRetries a RetryInterval.
  5. Trasa: EsbConfiguration koreňový prvok môže obsahovať nula alebo viac podradených prvkov tohto typu. V zásade predstavuje cestu pre ESB. Má nasledujúce atribúty:
    • názov: Jedinečný názov, ktorým sa dá odkazovať na túto trasu.
    • retryPolicyRef: Odkaz na politiku opakovania. Mal by sa zhodovať s RetryPolicy elementov názov atribút.
    • transformátorRef: Odkaz na fazuľu, ktorá predstavuje transformátor. Mal by sa zhodovať s Bean elementov názov atribút.
    The Trasa prvok môže mať jeden alebo viac podradených prvkov typu TransportHandlerRef. Toto dieťa v podstate ukazuje na fazuľu, ktorá predstavuje vhodný obslužný program transportu, ktorý by sa mal použiť pre túto trasu, a na verejný názov metódy tejto fazule, ktorá by sa mala vyvolať na odoslanie správy. Prípadne Trasa prvok môže mať jeden DeadLetterDestination dieťa, ktoré ukazuje na inú cestu predstavujúcu cieľ v mŕtvom liste.

Vzorový dokument XML, EsbConfiguration.xml, sa zobrazuje nižšie:

                              qcf-1 myCreditQueue //www.tax.com/calc súbor: /// C: /temp/esb/transform/xsl/credit.xsl súbor: /// C: / temp / esb / transform / custom / configManager. vlastnosti qcf-1 Redelivery.Queue qcf-1 System.DL.Queue qcf-1 System.Error.Queue qcf-1 Redelivery.Request.Topic 10 100 10 500 

Správanie ESB

The ESBConfiguration.xml dokument určuje správanie našej ESB. The EsbRouter MDB načíta tento XML z umiestnenia uvedeného v jeho deskriptore nasadenia. Informácie, ktoré obsahuje, sa potom usporiadajú do štruktúry údajov znázornenej na obrázku 2 nižšie.

The EsbRouter používa tieto informácie (cez EsbConfigManager) na dešifrovanie príslušnej trasy, prípadnej transformácie, kontroly bezpečnostnej autorizácie atď. Je potrebné si uvedomiť, ako sa na oddelenie rôznych funkcií (napríklad ako prenos viacerých protokolov a transformácia správ) ESB, čo umožňuje jeho vysokú rozšíriteľnosť a prispôsobiteľnosť.

Ako ukazuje diagram tried, v dizajne ESB sú dve dôležité rozhrania: TransformHandler a TransportHandler. Umožňujú vám napísať konkrétnu transformáciu a implementáciu transportu pre smerované správy. Tieto implementačné triedy potom môžu byť prepojené s trasami cez Bean prvky v EsbConfiguration. Napríklad vo vzorke EsbConfiguration.xml dokument, nasledujúca definícia fazule špecifikuje obslužný program prepravy:

   myQCF myCreditQueue 

Na tento manipulátor prepravy sa potom dá odkazovať v a Trasa uzol vložením a TransportHandler dieťa takto:

Poznámka
Prístup popísaný v tomto článku používa rozhrania Java na definovanie obslužných rutín transportu a transformácie. Každý nový obslužný program by teda musel implementovať požadované rozhranie, ktoré by sa mohlo zdať rušivé. Môžete ľahko upraviť EsbConfigManager použiť aplikáciu Dependency Injection na vyvolanie ľubovoľnej metódy implementačnej triedy, čím sa eliminuje potreba implementácie rozhrania. Ale keďže EsbRouter vždy prejde a javax.jms.Message inštancia, vaša trieda implementácie obslužného programu musí používať typ javax.jms.Message každopádne.
$config[zx-auto] not found$config[zx-overlay] not found