Ota mukautettava ESB käyttöön Java-sovelluksella

Tarkastellaan yritystä, jossa sinulla on heterogeenisiä sovelluksia, mahdollisesti eri tiimien toimittamia, joiden on oltava vuorovaikutuksessa toistensa kanssa, mutta joilla on seuraavat rajoitteet:

• Kukin sovellus ei välttämättä ole rakennettu samaa tekniikkaa käyttäen, eikä se välttämättä puhu muille natiivin kutsumekanisminsa avulla, esim. J2EE-sovellus ja .Net-sovellus.
• Kunkin sovelluksen ei tulisi mieluiten muuttaa pyyntöjään kohdesovelluksen ymmärtämään muotoon. Lisäksi yrityksellä on monia sovelluksia, jotka käyttävät kohdesovellusta.
• Palvelukomponenttien tulisi käyttää heille luontaista kutsu- tai pyyntömekanismia. Esimerkiksi olemassa oleva J2EE-sovellus voi ottaa vastaan ​​pyyntöjä vain Java Message Service (JMS) -palvelun kautta.
• Yritys on siirtymässä kohti arkkitehtuuria, jossa sovellus koskee itse vain yhtä, mitä se tietää, ja toista, mitä sen tulisi siirtää parametreina, kun se haluaa hankkia toisen sovelluksen palveluja yrityksessä.

Muut rajoitteet saattavat edellyttää, että sinulla on infrastruktuuri, joka mahdollistaa heterogeenisten sovellusten integroimisen saumattomasti muuttamatta niiden suunnittelua. Yrityspalveluväylä (ESB) on yksi tapa toteuttaa tällainen yritysintegraatioarkkitehtuuri.

Vaikka kukin yritys todennäköisesti luo ESB: n omalla ainutlaatuisella tavalla, on tärkeää pitää mielessä joustavuus harkittaessa ESB: n määritelmää. Sellaisen rakentamiseen ei ole kiinteää lähestymistapaa. Ajatuksena on luoda yhteyskerros, joka optimoi palvelujen kuluttajien ja palveluntarjoajien välisen vuorovaikutuksen, joka pystyy vastaamaan tapahtuma-, viesti- tai palvelukeskeisiin tilanteisiin.

Tässä artikkelissa käsitellään lähestymistapaa laajennettavan Java-pohjaisen ESB: n rakentamiseen, joka tukee yleisimpiä ESB: n toiminnallisia vaatimuksia.

Yhteiset ESB-vaatimukset

ESB: n yleiset vaatimukset ovat myös sen yleisimmin käytetyt ominaisuudet:

1. Reititys: ESB: n olisi tarjottava tehokas ja joustava reititysmekanismi.
2. Muutos: Palvelukomponentin ei pitäisi tarvita tietää kohdepalvelun pyyntömuotoa, johon se voi vedota. ESB: n olisi pyynnön tekijän ja kohteen perusteella voitava soveltaa pyyntöön asianmukaista muunnosta, jotta kohde voi ymmärtää sen.
3. Usean protokollan kuljetus: ESB-toteutus, joka puhuu vain JMS: stä tai vain verkkopalveluista, ei ole kovin arvokas. Sen tulisi olla riittävän laajennettava tukemaan useita viestiprotokollia yrityksen tarpeista riippuen.
4. Turvallisuus: Tarvittaessa ESB: n tulisi valvoa todentamista ja valtuutusta pääsyyn eri palvelukomponenteihin.

Kuvassa 1 on ESB: n tärkeimmät arkkitehtoniset komponentit. Siinä on kolme laajaa osastoa:

1. Vastaanotin: ESB paljastaa erilaisia ​​rajapintoja, joiden avulla asiakasohjelmat voivat lähettää viestejä ESB: lle. Esimerkiksi servlet saattaa vastaanottaa ESB: n HTTP-pyyntöjä. Samaan aikaan sinulla voi olla MDB (viestiohjattu papu) kuuntelemassa JMS-kohdetta, johon asiakasohjelmat voivat lähettää viestejä.
2. Ydin: Tämä on suurin osa ESB: n täytäntöönpanosta. Se hoitaa reitityksen ja muunnoksen sekä käyttää tietoturvaa. Tyypillisesti se koostuu MDB: stä, joka vastaanottaa saapuvat pyynnöt ja soveltaa sitten viestikontekstin perusteella asianmukaista muunnosta, reititystä ja suojausta. Yksityiskohdat reitityksestä, kuljetuksesta, muunnoksesta ja suojaustiedoista voidaan määrittää XML-dokumentissa (keskustellaan pian).
3. Lähettäjä: Kaikki lähtevät kuljetusten käsittelijät kuuluvat tämän ESB: n piiriin. Voit kytkeä minkä tahansa mielivaltaisen kuljetuksen käsittelijän (sähköposti, faksi, FTP jne.) ESB: hen.

Kaikki nämä ESB: n osat on liimattu yhteen XML-asiakirjalla, jossa luetellaan kaikki reitit, joilla ESB toimii. Erilaiset kuljetuskäsittelijät, muuntajat ja uudelleenkäynnistyskäytännöt ja niiden yhteys eri reitteihin johdetaan kaikki tämän XML-asiakirjan kautta.

ESBConfiguration.xml

XML-luettelo -ESBConfiguration.xml, joka näkyy alla - antaa meille jonkinlaisen käsityksen ESB: n toiminnasta. Tärkeimmät kiinnostavat tekijät ESBConfiguration.xml ovat seuraavat:

1. Pavut: Tämä elementti sisältää nollan tai enemmän Papu elementtejä.
2. Papu: Tämä elementti määrittelee pohjimmiltaan tavan luoda ja konfiguroida a Papu luokassa. Sillä on seuraavat määritteet:
   • nimi: Ainutlaatuinen nimi, jota voidaan käyttää viittaamaan tähän pavuun.
   • luokan nimi: Papuluokan täysin hyväksytty nimi.
   Jokaisella pavulla voi olla nolla tai enemmän Omaisuus elementtejä lapsina. Jokainen Omaisuus elementillä on attribuutti nimi joka tunnistaa sen ja tyypin lapsielementin Arvo jolla on kiinteistön arvo. Nämä ominaisuudet ovat itse asiassa luokan JavaBeans-tyylisiä jäseniä, jotka voivat määrittää papuluokan.
3. Yritä uudelleenPolitiikat: Tämä elementti sisältää nollan tai enemmän Yritä uudelleen politiikkaa lapset.
4. Yritä uudelleen politiikkaa: Tämä elementti määrittää uudelleenyrityskäytännön tietylle reitille. Sillä on attribuutti nimi jota voidaan käyttää viittaamaan siihen. Siinä on kaksi nimettyä lapsielementtiä MaxRetries ja Yritä uudelleen.
5. Reitti: Esb-kokoonpano root-elementti voi sisältää nolla tai useampaa tämän tyyppistä alielementtiä. Se edustaa periaatteessa reittiä ESB: lle. Sillä on seuraavat määritteet:
   • nimi: Ainutlaatuinen nimi, jota voidaan käyttää viittaamaan tälle reitille.
   • yritä uudelleenPolicyRef: Viittaus uudelleenyrityskäytäntöön. Sen pitäisi vastata Yritä uudelleen politiikkaa elementin nimi määritteen.
   • muuntajaRef: Viittaus papuun, joka edustaa muuntajaa. Sen pitäisi vastata Papu elementin nimi määritteen.
   Reitti elementillä voi olla yksi tai useampi tyyppinen alielementti TransportHandlerRef. Tämä lapsi viittaa pohjimmiltaan papuun, joka edustaa asianmukaista kuljetuskäsittelijää, jota tulisi käyttää tällä reitillä, ja kyseisen pavun julkiseen metodinimiin, johon tulisi vedota viestin lähettämiseksi. Vaihtoehtoisesti Reitti elementillä voi olla yksi KuollutKirjeKohde lapsi, joka osoittaa toiselle reitille, joka edustaa kuollut kirjainta.

XML-asiakirjan malli, EsbConfiguration.xml, näkyy alla:

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

ESB: n käyttäytyminen

ESBConfiguration.xml asiakirja sanelee ESB: n käyttäytymisen. EsbRouter MDB lataa tämän XML: n sijainnista, joka on määritetty asennuskuvaimessa. Sen sisältämät tiedot on sitten järjestetty alla olevassa kuvassa 2 kuvattuun tietorakenteeseen.

EsbRouter käyttää näitä tietoja (via EsbConfigManager) tarkoituksenmukaisen reitin, mahdollisen muunnoksen, suojauksen valtuutustarkistuksen jne. salaamiseksi. Tärkeää on huomioida se, miten riippuvuuden injektiotekniikkaa ja perintöä on käytetty erottamaan eri toiminnot (kuten kuten moniprotokollisten viestien siirto ja viestimuunnos) ESB, mikä mahdollistaa sen olevan erittäin laajennettavissa ja muokattavissa.

Kuten luokkakaaviosta käy ilmi, ESB: n suunnittelussa on kaksi tärkeää rajapintaa: TransformKäsittelijä ja KuljetusKäsittelijä. Niiden avulla voit kirjoittaa tietyn muunnoksen ja siirtototeutuksen reititetyille viesteille. Nämä toteutusluokat voidaan sitten yhdistää reittien kautta Papu elementtejä Esb-kokoonpano. Esimerkiksi näytteessä EsbConfiguration.xml seuraavassa papun määritelmässä määritetään kuljetuksen käsittelijä:

   myQCF myCreditQueue 

Tähän kuljetuskäsittelijään voidaan sitten viitata kohdassa a Reitti solmu lisäämällä a KuljetusKäsittelijä lapsi sille näin: