Apsveriet uzņēmumu, kurā jums ir neviendabīgas lietojumprogrammas, kuras, iespējams, piegādā dažādas komandas un kurām ir jāsadarbojas, bet kurām ir šādi ierobežojumi:
- Katra lietojumprogramma nav obligāti veidota, izmantojot to pašu tehnoloģiju, un, iespējams, tā nesarunājas ar citiem, izmantojot savu vietējo izsaukšanas mehānismu, piemēram, J2EE lietojumprogrammu un .Net lietojumprogrammu.
- Vēlams, lai katra lietojumprogramma nepārveidotu savus pieprasījumus formātā, kuru saprot mērķa lietojumprogramma. Turklāt uzņēmumā ir daudz lietojumprogrammu, kas izmanto mērķa lietojumprogrammu.
- Pakalpojuma komponentiem jāizmanto izsaukšanas vai pieprasīšanas mehānisms, kas viņiem ir dabisks. Piemēram, esoša J2EE lietojumprogramma var pieņemt pieprasījumus tikai caur Java Message Service (JMS).
- Uzņēmums virzās uz arhitektūru, kur lietojumprogramma attiecas tikai uz vienu, ko tas zina, un divus, kas tai jānodod kā parametri, ja tas vēlas iegūt citas lietojumprogrammas pakalpojumus uzņēmumā.
Citu ierobežojumu dēļ jums var būt nepieciešama infrastruktūra, kas ļauj neviendabīgām lietojumprogrammām vienmērīgi integrēties, nemainot to dizainu. Uzņēmuma pakalpojumu kopne (ESB) ir viens no veidiem, kā realizēt šādu uzņēmuma integrācijas arhitektūru.
Lai gan katrs uzņēmums, iespējams, izveidos savu ESB savā unikālajā veidā, apsverot ESB definīciju, ir svarīgi paturēt prātā elastību. Nav fiksētas pieejas, lai to izveidotu. Ideja ir izveidot savienojamības slāni, kas optimizētu mijiedarbību starp pakalpojumu patērētājiem un pakalpojumu sniedzējiem, un tas varētu reaģēt uz notikumu, ziņojumu vai pakalpojumu orientētiem kontekstiem.
Šajā rakstā ir apspriesta pieeja paplašināt Java balstītu ESB, kas atbalsta visizplatītākās ESB funkcionālās prasības.
Kopējās ESB prasības
ESB kopīgās prasības ir arī tās visbiežāk izmantotās funkcijas:
- Maršrutēšana: ESB būtu jānodrošina efektīvs un elastīgs maršrutēšanas mehānisms.
- Pārveidošana: Pakalpojuma komponentam nav jāzina mērķa pakalpojuma pieprasījuma formāts, kuru tas var izmantot. Pamatojoties uz pieprasītāju un mērķi, ESB vajadzētu būt iespējai piemērot pieprasījumam atbilstošu pārveidojumu, lai mērķis to saprastu.
- Daudzprotokolu transports: ESB ieviešanai, kas runā tikai ar JMS vai tikai tīmekļa pakalpojumiem, nav lielas vērtības. Tam jābūt pietiekami paplašināmam, lai atbalstītu vairākus ziņojumu protokolus atkarībā no uzņēmuma vajadzībām.
- Drošība: Ja nepieciešams, ESB jāievieš autentifikācija un autorizācija piekļuvei dažādiem pakalpojumu komponentiem.
1. attēlā parādīti galvenie ESB arhitektūras komponenti. Tam ir trīs plaši nodalījumi:
- Uztvērējs: ESB atklāj dažādas saskarnes, kas ļauj klienta lietojumprogrammām nosūtīt ziņojumus ESB. Piemēram, servletīklis varētu saņemt HTTP pieprasījumus ESB. Tajā pašā laikā jums varētu būt MDB (ziņu vadīta pupiņa), kas klausās JMS galamērķi, kur klienta lietojumprogrammas var nosūtīt ziņojumus.
- Kodols: Šī ir galvenā ESB ieviešanas daļa. Tas apstrādā maršrutēšanu un pārveidošanu un piemēro drošību. Parasti to veido MDB, kas saņem ienākošos pieprasījumus un pēc tam, pamatojoties uz ziņojuma kontekstu, piemēro atbilstošo pārveidošanu, maršrutēšanu un drošību. Sīkāku informāciju par maršrutēšanu, transportēšanu, pārveidošanu un drošības informāciju var norādīt XML dokumentā (īsumā aplūkots).
- Dispečers: Visi izejošie pārvadātāji ietilpst šajā ESB daļā. Jebkuru patvaļīgu transporta apstrādātāju (e-pastu, faksu, FTP utt.) Varat pievienot ESB.
Visas šīs ESB daļas ir salīmētas ar XML dokumentu, kurā uzskaitīti visi maršruti, pa kuriem darbojas ESB. Dažādie transporta apstrādes, transformatoru un atkārtoto mēģinājumu politikas un to savienojums ar dažādiem maršrutiem tiek vadīts, izmantojot šo XML dokumentu.
ESBConfiguration.xml
XML saraksts—ESBConfiguration.xml
, kas redzams zemāk, sniedz mums priekšstatu par ESB darbību. Galvenie interesējošie elementi ESBConfiguration.xml
ir šādi:
Pupiņas
: Šis elements satur nulli vai vairākPupa
elementi.Pupa
: Šis elements būtībā nosaka veidu, kā mēs veidojam un konfigurējam aPupa
klasē. Tam ir šādi atribūti:nosaukums
: Unikāls nosaukums, ko var izmantot, lai atsauktos uz šo pupiņu.className
: Pupiņu klases pilnībā kvalificēts nosaukums.
Īpašums
elementi kā bērni. KatrsĪpašums
elementam ir atribūtsnosaukums
kas to identificē un tipa bērna elementuVērtība
kas tur īpašuma vērtību. Šīs īpašības faktiski ir klases JavaBeans stila dalībnieki, kas var konfigurēt pupiņu klasi.Atkārtoti mēģināt
: Šis elements satur nulli vai vairākMēģināt vēlreiz
bērni.Mēģināt vēlreiz
: Šis elements nosaka atkārtota mēģinājuma politiku konkrētam maršrutam. Tam ir atribūtsnosaukums
ko var izmantot, lai uz to atsauktos. Tam ir divi bērnu elementiMaxRetries
unAtkārtoti mēģiniet veikt intervālu
.Maršruts
:EsbConfiguration
saknes elementā var būt nulle vai vairāk šāda veida bērnu elementu. Tas būtībā atspoguļo ESB maršrutu. Tam ir šādi atribūti:nosaukums
: Unikāls nosaukums, ko var izmantot, lai norādītu uz šo maršrutu.retryPolicyRef
: Atsauce uz atkārtotu mēģinājumu politiku. Tam jāatbilstMēģināt vēlreiz
elementanosaukums
atribūts.transformerRef
: Atsauce uz pupiņu, kas apzīmē transformatoru. Tam jāatbilstPupa
elementanosaukums
atribūts.
Maršruts
elementam var būt viens vai vairāki veida bērnu elementiTransportHandlerRef
. Šis bērns būtībā norāda uz pupiņu, kas apzīmē piemērotu transporta apstrādātāju, kas jāizmanto šajā maršrutā, un šīs pupas publisko metodi, kas jāizmanto, lai nosūtītu ziņojumu. Pēc izvēlesMaršruts
elementam var būt viensDeadLetterDestination
bērns, kurš norāda uz citu maršrutu, kas apzīmē beigtu burtu galamērķi.
XML dokumenta paraugs, EsbConfiguration.xml
, parādās zemāk:
qcf-1 myCreditQueue //www.tax.com/calc fails: /// C: /temp/esb/transform/xsl/credit.xsl fails: /// C: / temp / esb / transform / custom / configManager. rekvizīti qcf-1 Redelivery. Quef qcf-1 System.DL.Queue qcf-1 System.Error.Queue qcf-1 Redelivery.Request.Topic 10 100 10 500
ESB uzvedība
The ESBConfiguration.xml
dokuments nosaka mūsu ESB rīcību. The EsbRouter
MDB ielādē šo XML no vietas, kas norādīta izvietošanas aprakstā. Pēc tam tajā ietvertā informācija tiek sakārtota datu struktūrā, kas attēlota 2. attēlā.
The EsbRouter
izmanto šo informāciju (izmantojot EsbConfigManager
), lai atšifrētu atbilstošo maršrutu, piemērojamo transformāciju, ja tāda ir, drošības autorizācijas pārbaudi utt. Svarīgs aspekts, kas jāņem vērā, ir veids, kā Atkarības injicēšanas tehnika kopā ar mantojumu ir izmantota dažādu funkciju atdalīšanai (piemēram, kā multiprotokola ziņojumu transportēšana un ziņojumu pārveidošana), tādējādi ļaujot to ļoti paplašināt un pielāgot.
Kā redzams klases diagrammā, ESB projektā ir divas svarīgas saskarnes: TransformHandler
un TransportHandler
. Tie ļauj rakstīt īpašu pārveidojumu un transporta ieviešanu maršrutētajiem ziņojumiem. Pēc tam šīs ieviešanas klases var savienot ar maršrutiem, izmantojot Pupa
elementi EsbConfiguration
. Piemēram, izlasē EsbConfiguration.xml
dokumentā, šāda pupiņu definīcija norāda pārvadātāju:
myQCF myCreditQueue
Pēc tam uz šo transporta apstrādātāju var atsaukties a Maršruts
mezglā, ievietojot a TransportHandler
bērnam tā:
Piezīme |
---|
Šajā rakstā aprakstītā pieeja izmanto Java saskarnes, lai noteiktu transporta un transformācijas apstrādātājus. Tādējādi jebkuram jaunam apstrādātājam būtu jāievieš vajadzīgā saskarne, kas varētu šķist uzmācīga. Jūs varat viegli modificēt EsbConfigManager izmantot atkarības injekciju, lai izsauktu jebkuru patvaļīgu ieviešanas klases metodi, tādējādi novēršot interfeisa ieviešanas nepieciešamību. Bet kopš EsbRouter vienmēr iet a javax.jms.Ziņojums Piemēram, apstrādātāja ieviešanas klasei jāizmanto tips javax.jms.Ziņojums vienalga. |