Programmēšana

Ieviesiet pielāgojamu ESB ar Java

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:

  1. Maršrutēšana: ESB būtu jānodrošina efektīvs un elastīgs maršrutēšanas mehānisms.
  2. 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.
  3. 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.
  4. 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:

  1. 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.
  2. 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).
  3. 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:

  1. Pupiņas: Šis elements satur nulli vai vairāk Pupa elementi.
  2. Pupa: Šis elements būtībā nosaka veidu, kā mēs veidojam un konfigurējam a Pupa 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.
    Katrai pupiņai var būt nulle vai vairāk Īpašums elementi kā bērni. Katrs Īpašums elementam ir atribūts nosaukums kas to identificē un tipa bērna elementu Vē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.
  3. Atkārtoti mēģināt: Šis elements satur nulli vai vairāk Mēģināt vēlreiz bērni.
  4. Mēģināt vēlreiz: Šis elements nosaka atkārtota mēģinājuma politiku konkrētam maršrutam. Tam ir atribūts nosaukums ko var izmantot, lai uz to atsauktos. Tam ir divi bērnu elementi MaxRetries un Atkārtoti mēģiniet veikt intervālu.
  5. 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āatbilst Mēģināt vēlreiz elementa nosaukums atribūts.
    • transformerRef: Atsauce uz pupiņu, kas apzīmē transformatoru. Tam jāatbilst Pupa elementa nosaukums atribūts.
    The Maršruts elementam var būt viens vai vairāki veida bērnu elementi TransportHandlerRef. Š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ēles Maršruts elementam var būt viens DeadLetterDestination 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.
$config[zx-auto] not found$config[zx-overlay] not found