Izvedite prilagodljiv ESB z Javo

Razmislite o podjetju, v katerem imate heterogene aplikacije, ki jih morda izvajajo različne skupine, ki morajo medsebojno sodelovati, vendar imajo naslednje omejitve:

• Vsaka aplikacija ni nujno zgrajena z isto tehnologijo in se morda ne bo pogovarjala z drugimi z uporabo lastnega mehanizma za klicanje, npr. Aplikacija J2EE in aplikacija .Net.
• Po možnosti vsaka aplikacija ne bi smela pretvoriti svojih zahtev v obliko, ki jo razume ciljna aplikacija. Poleg tega ima podjetje veliko aplikacij, ki uporabljajo ciljno aplikacijo.
• Komponente storitve bi morale uporabljati mehanizem priklica ali zahteve, ki jim je naraven. Na primer, obstoječa aplikacija J2EE lahko sprejema zahteve samo prek storitve Java Message Service (JMS).
• Podjetje se premika k arhitekturi, pri kateri se aplikacija ukvarja samo z enim, tem, kar ve, in dve, s tem, kaj naj posreduje kot parametre, ko želi dobiti storitve druge aplikacije znotraj podjetja.

Druge omejitve lahko zahtevajo, da imate infrastrukturo, ki heterogenim aplikacijam omogoča nemoteno integracijo brez spreminjanja njihove zasnove. Vodilo za storitve podjetja (ESB) je eden od načinov za uresničitev takšne arhitekture integracije podjetja.

Čeprav bo vsako podjetje verjetno ustvarilo svoj ESB na svoj edinstven način, je pri obravnavi opredelitve ESB pomembno upoštevati prožnost. Nobenega fiksnega pristopa ni. Ideja je imeti povezovalni sloj, ki optimizira interakcije med potrošniki storitev in ponudniki storitev, ki se lahko odziva na kontekst, usmerjen v dogodke, sporočila ali storitve.

Ta članek obravnava pristop k izdelavi razširljivega ESB, ki temelji na Javi in ​​podpira najpogostejše funkcionalne zahteve ESB.

Skupne zahteve ESB

Skupne zahteve ESB so tudi najpogosteje uporabljene funkcije:

1. Usmerjanje: ESB bi moral zagotoviti učinkovit in prilagodljiv mehanizem usmerjanja.
2. Preoblikovanje: Komponenti storitve ne bi bilo treba poznati oblike zahteve ciljne storitve, ki bi jo lahko poklicala. Na podlagi prosilca in cilja bi moral biti ESB sposoben uporabiti ustrezno preoblikovanje zahteve, tako da jo lahko razume.
3. Multiprotokol transport: Implementacija ESB, ki govori samo o sistemu JMS ali samo o spletnih storitvah, ni velika vrednost. Moral bi biti dovolj razširljiv, da podpira več protokolov sporočil, odvisno od potreb podjetja.
4. Varnost: ESB bi moral po potrebi uveljaviti preverjanje pristnosti in pooblastila za dostop do različnih komponent storitve.

Slika 1 prikazuje glavne arhitekturne komponente ESB. Ima tri široke predelke:

1. Sprejemnik: ESB izpostavlja različne vmesnike, ki odjemalskim aplikacijam omogočajo pošiljanje sporočil ESB. Na primer, strežniški programček lahko prejema zahteve HTTP za ESB. Hkrati bi lahko poslušali MDB (bean, ki ga poganjajo sporočila) na destinaciji JMS, kjer lahko odjemalske aplikacije pošiljajo sporočila.
2. Jedro: To je glavni del izvajanja ESB. Obravnava usmerjanje in preoblikovanje ter uporablja varnost. Običajno je sestavljen iz MDB-ja, ki prejme vhodne zahteve in nato na podlagi konteksta sporočila uporabi ustrezno transformacijo, usmerjanje in varnost. Podrobnosti o usmerjanju, prevozu, preoblikovanju in varnostnih informacijah lahko določite v dokumentu XML (o njem bomo kmalu razpravljali).
3. Pošiljatelj: V ta del ESB spadajo vsi upravljavci izhodnega prevoza. V ESB lahko priključite poljubnega upravljavca prevoza (e-pošta, faks, FTP itd.).

Vsi ti deli ESB so zlepljeni z dokumentom XML, ki navaja vse poti, na katerih deluje ESB. Različni usmerjevalniki transporta, transformatorji in ponovni poskusi ter njihova povezava z različnimi potmi so ožičeni prek tega dokumenta XML.

ESBConfiguration.xml

Seznam XML—ESBConfiguration.xml, ki je prikazan spodaj - nam daje nekaj idej o delovanju ESB. Glavni elementi zanimanja za ESBConfiguration.xml so naslednje:

1. Fižol: Ta element vsebuje nič ali več Fižol elementi.
2. Fižol: Ta element v bistvu določa način ustvarjanja in konfiguriranja a Fižol razred. Ima naslednje lastnosti:
   • ime: Edinstveno ime, ki se lahko uporablja za sklicevanje na ta fižol.
   • className: Popolnoma kvalificirano ime razreda fižola.
   Vsak fižol ima lahko nič ali več Nepremičnina elementi kot otroci. Vsak Nepremičnina element ima atribut ime ki ga identificira in podrejeni element tipa Vrednost ki vsebuje vrednost nepremičnine. Te lastnosti so pravzaprav člani razreda v slogu JavaBeans, ki lahko konfigurirajo razred bean.
3. RetryPolicies: Ta element vsebuje nič ali več RetryPolicy otroci.
4. RetryPolicy: Ta element določa politiko ponovnega poskusa za določeno pot. Ima atribut ime ki se lahko uporabi za sklicevanje nanjo. Ima dva podrejena elementa z imenom MaxRetries in RetryInterval.
5. Pot: The EsbConfiguration root element lahko vsebuje nič ali več podrejenih elementov te vrste. V bistvu predstavlja pot za ESB. Ima naslednje lastnosti:
   • ime: Enolično ime, s katerim se lahko sklicujete na to pot.
   • retryPolicyRef: Sklic na pravilnik o ponovnem poskusu. Moral bi se ujemati z RetryPolicy elementov ime atribut.
   • transformator: Sklic na fižol, ki predstavlja transformator. Moral bi se ujemati z Fižol elementov ime atribut.
   The Pot element ima lahko enega ali več podrejenih elementov tipa TransportHandlerRef. Ta otrok v bistvu kaže na fižol, ki predstavlja ustreznega upravljavca prevoza, ki ga je treba uporabiti za to pot, in ime javne metode tega fižola, ki ga je treba uporabiti za pošiljanje sporočila. Neobvezno Pot element lahko ima enega DeadLetterDestination otrok, ki kaže na drugo pot, ki predstavlja cilj mrtve črke.

Vzorec XML dokumenta, EsbConfiguration.xml, se prikaže spodaj:

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

ESB vedenje

The ESBConfiguration.xml dokument narekuje vedenje našega ESB. The EsbRouter MDB naloži ta XML z mesta, določenega v njegovem deskriptorju razmestitve. Informacije, ki jih vsebuje, se nato organizirajo v podatkovno strukturo, prikazano na sliki 2 spodaj.

The EsbRouter uporablja te podatke (prek EsbConfigManager) za dešifriranje ustrezne poti, preoblikovanje, ki ga je treba uporabiti, preverjanje varnostnega pooblastila itd. Pomembno je omeniti način, kako je bila tehnika vbrizga odvisnosti skupaj z dedovanjem uporabljena za ločitev različnih funkcij (npr. (večprotokolski prenos sporočil in preoblikovanje sporočil) ESB, kar mu omogoča, da je zelo razširljiv in prilagodljiv.

Kot prikazuje diagram razredov, sta v zasnovi ESB dva pomembna vmesnika: TransformHandler in TransportHandler. Omogočajo vam, da za preusmerjena sporočila napišete posebno transformacijo in transport. Te izvedbene razrede lahko nato povežete s potmi prek Fižol elementi v EsbConfiguration. Na primer v vzorcu EsbConfiguration.xml Naslednja definicija zrna določa upravljavca prevoza:

   myQCF myCreditQueue 

Ta vodnik za prevoz je nato naveden v a Pot vozlišče z vstavitvijo a TransportHandler otrok do njega takole: