Mikä on esb, yrityspalvelubussi. Integraatioväylä on keskeinen elementti pankin tietotilan rakentamisessa

Tällä artikkelilla haluan avata IBM WebSphere ESB:lle (jäljempänä ESB) omistetun syklin tämän tuotteen kehittämisen yhteydessä. Ja ensinnäkin sinun on tutustuttava tämän tyyppisiin teknologioihin.
Yrityspalveluväylä (yrityspalveluväylä) - väliohjelmisto, joka tarjoaa keskitetyn ja yhtenäisen tapahtumakeskeisen viestinnän erilaisten välillä. tietojärjestelmä palvelukeskeisen arkkitehtuurin periaatteilla.
Tietysti on mahdollista, jopa ilman erikoisohjelmistoa (ehkä jotain yleistä täytyy vielä kehittää), rakentaa tälle lähestymistavalle pohjautuva yritysjärjestelmä, ja mitä sen seurauksena tapahtuu, voidaan kutsua palveluväyläksi. Mutta IBM:n tuotteessa ei ole vain valmiita laitteita tämän prosessin keskitettyyn viestintään ja ohjaukseen, vaan myös täydellinen joukko valmiuksia joustavien palvelusuuntautuneiden sovellusten kehittämiseen erityisesti ESB:tä varten. Yhteenvetona voidaan korostaa seuraavia IBM WebSphere ESB:n ominaisuuksia ja etuja:

  • Arkkitehtonisten suhteiden järjestys ja yhtenäisyys
  • Keskitetty hallinta
  • Palvelinpuolen sovelluskokoonpano
  • Service Component Architecture (SCA) -teknologian käyttöönotto palvelukeskeisen arkkitehtuurin periaatteiden hengessä
  • Kehitetyn ohjelmakoodin protokollariippumattomuus
  • Laajat väylä- ja sovelluskokoonpanovaihtoehdot
Samaan aikaan ESB tarjoaa transaktioiden hallinnan, tietojen muuntamisen, turvallisuuden ja taatun viestien toimituksen. Pääsy kaikkiin palveluihin yhden pisteen kautta mahdollistaa palveluviestinnän konfiguroinnin keskitetysti. Voit myös hallita virhetapahtumia keskitetysti joukkovirheiden käsittelyä varten.
Klassinen ESB-kokoonpanotopologia on klusteri, joka tarjoaa horisontaalisen skaalautuvuuden ja vikasietoisuuden. Virallisten suositusten mukaan klusterin jäsenten määrän lisääminen lisää suorituskykyä tehokkaammin kuin palvelinkapasiteetin lisääminen erillisessä topologiassa. Lisäksi klusteri voidaan käynnistää uudelleen (tai osa siitä saattaa epäonnistua) palvelua pysäyttämättä.
ESB:tä käytetään yleensä palvelukerroksena IBM BPM:ssä, mutta sillä voi hyvinkin olla johtava rooli vuorovaikutusmallin rakentamisessa. yritysten järjestelmät tehokkaana integrointilaitteena (tarkoittaa ESB:tä lisäosana IBM WebSphere Application Serverin yli).
Tämä itse asiassa vaaditaan ESB:ltä, koska tämä on "palvelujen keräyspiste" - jos tarvitset palvelun, joka toimii muiden palvelujen kanssa (ehkä ulkoisten), näiden palvelujen välinen integrointi tapahtuu loogisimmin ESB:ssä. . Ulkoisille tai heterogeenisille palveluille voit tehdä "kääreestä" ESB-palvelun. Havainnollistetaan hieman "yksitalon" käytön mukavuutta palveluissa:

Tilaus
Mitä suurempi järjestelmä, sitä tärkeämpää järjestystä ja yhtenäisyyttä siinä on. Jos puhumme suuren yrityksen järjestelmäkompleksista, sitä voidaan varmasti kutsua suureksi järjestelmäksi. Tietenkin voit aina löytää järjestelmänvalvojan, joka pitää mielessä satojen palvelimien vuorovaikutuskaavion tai joukon riippumattomia dokumentaatioita jokaiselle ohjelmistomoduulille, jossa kuvataan, mitä se on vuorovaikutuksessa ja miten.


Mutta on paljon helpompaa saada palvelu (ESB), jonka avulla voit suorittaa kaiken vuorovaikutuksen itsensä kautta. Tällä lähestymistavalla osa vuorovaikutusarkkitehtuurista missä tahansa alijärjestelmässä on jo selvä - järjestelmien, palvelimien ja sovellusten välisessä viestinnässä ei ole sotkua: kaikki on kytketty ESB:hen ja ESB on kytketty kaikkeen.

Keskitetty hallinta
Järjestelmät on aina kätevämpää konfiguroida keskitetysti - olipa kyse sitten konfiguroinnista, palvelimen siirtoon mukautumisesta, vikasietoisuudesta, kuormituksen tasapainotuksesta, virheiden käsittelystä tai seurannasta ja analytiikkasta.


Esimerkiksi tietokantapalvelinta siirrettäessä sinun ei tarvitse päästä kaikkien olemassa olevien sovelluspalvelimien kokoonpanoon ja asetuksiin erityisiä sovelluksia erityisesti riittää, että ESB:ssä on yksi ympäristömuuttuja, joka määrittää tietokannan osoitteen, jolloin muutokset on tehtävä vain yhdessä kohdassa.
Tai jos jokin ulkoisista järjestelmistä ei ollut käytettävissä pitkään aikaan, eikä ainuttakaan siihen lähetettyä pyyntöä pitäisi hukata, voit käyttää palvelua epäonnistuneiden tapahtumien käsittelyyn ja "heittää sisään" perille toimittamattomia viestejä silloin, kun se sopii.
Jos sinun on säädettävä samanaikaisten pyyntöjen määrää mihin tahansa järjestelmään tai valvottava näitä pyyntöjä, analysoitava kuormitusta, etsittävä pullonkauloja - sinun on mentävä viestien ohjauskeskukseen - ESB-palvelinkonsoliin.

Palvelinpuolen kokoonpano
Palvelujen "yksittäinen asunto" mahdollistaa konfiguroinnin kannalta useiden hyödyllisten tavoitteiden saavuttamisen. Ensimmäinen on kokoonpanon uudelleenkäyttö (samanlainen kuin koodin ja moduulin uudelleenkäyttö, mikä on erittäin hyödyllistä SOA:ssa), koska eri moduulit ja sovellukset voivat käyttää samoja tietokantayhteysparametreja, resursseja, todennusparametreja, ympäristömuuttujia ja niin edelleen.


Toiseksi palvelinpuolella konfiguroitaessa siihen voi suurelta osin vaikuttaa sovellusympäristö, jonka avulla voit siirtää sovelluksia eri piirien välillä (testaus ja tuotanto), virittää ja jopa korjata bugeja tekemättä muutoksia sovellukseen.

Jos hyödynnät kaikkia näitä etuja, sovellukset saavat todellisen kameleontin kyvyn – ne ovat niin joustavia, että niistä tulee osa työympäristöä ja samalla ne tuovat mukanaan tärkeät toiminnallisuutensa.

Mutta IBM WebSphere ESB -sovellusten joustavuus ei rajoitu ympäristöön, jossa ne toimivat. Kehitysvalmiudella on suuri panos tähän. Koska järjestelmillä ei tarvitse olla vain paikka toimia, vaan niitä on myös kehitettävä ja viimeisteltävä, näitä mielenkiintoisia kohtia ei pidä jättää huomiotta:

SCA
Tämä arkkitehtuuri perustuu periaatteeseen, että komponentti tarjoaa toiminnallisuutensa muiden komponenttien käytettävissä olevana palveluna. Yhden moduulin sisällä komponentit ovat ohjelmalohkoja (java-koodia), jotka toteuttavat täysin jonkin vastaavan rajapinnan kuvaaman toiminnallisuuden. Komponenttien suorituslogiikka toteutetaan linkittämällä ne rakenteeksi rajapintojen ja viitteiden avulla (Partner Reference).

Tällaista moduulirakennetta on erittäin kätevä kehittää, tarkistaa, kehittää, muuttaa ja ylläpitää. Komponentteihin toteutetun toiminnallisuuden atomiteetti mahdollistaa komponenttien käytön kokonaisuutena ilman kooditasolle menemistä. Toisaalta se on loogisesti välttämätöntä komponenttitoteutusten suorittamisen vuoksi tapahtumakontekstissa.
Jokaisella komponentilla on käyttöliittymä(t), jotka se toteuttaa. Siten komponentteja toisiinsa kytkettäessä ei tarvitse tietää niiden sisäisiä ominaisuuksia - riittää, että ne toteuttavat tarvittavat rajapinnat.
Tämän arkkitehtuurin avulla voit myös ratkaista kaikki rinnakkaistyötä vaativat tehtävät ilman "manuaalista" vuonohjausta (voit esimerkiksi soittaa asynkronisia kutsuja useille komponenteille viivästetyllä vastauksella).
Ei-java-komponentit, kuten vienti- ja tuontityypit, antavat sinun tarjota palveluita ulkoiseen käyttöön tai käyttää ulkoisia palveluita. Mediation Flow -komponentti tarjoaa matalan tason pääsyn muiden komponenttien välittämiin viesteihin ja mahdollistaa erilaisia ​​muunnoksia käytettäessä heterogeenisiä rajapintoja.
Liitäntöjen lisäksi IBM:n liiketoimintaobjektikehys tarjoaa erittäin hyödyllisiä ominaisuuksia. Liikeobjekteja (BO), joita edustavat xsd-skeemat, käytetään olioina tiedonsiirtoon liitännöissä sekä komponenttien välillä että moduulien välisessä tiedonsiirrossa. Ne on integroitu suoraan esimerkiksi wsdl-skeemaan verkkopalveluiden kuvaamista varten. Eli jos esimerkiksi moduuli "A" tarjoaa toiminnallisuutensa verkkopalvelun muodossa, sen käyttämiseen riittää, että moduuli "B" yhdistää käyttöliittymän ja valmiit BO:t, ja se pystyy täysin toimimaan tällaisen palvelun kanssa luomatta ylimääräisiä java -objekteja tiedonsiirtoa varten. BO:ta on kätevä käyttää myös vaihdettaessa tietoja tietokannan kanssa, jos muut komponentit käyttävät näitä tietoja (tämä tietysti on vastoin "DAO"-mallia, mutta se eliminoi tarpeettomat Java-objektit ja tietojen uudelleenkirjoitustoiminnot "edestakaisin" ).

Ohjelmakoodin protokollariippumattomuus
Kuten näet, koodin protokollariippumattomuus saavutetaan käyttämällä Export- ja Import-komponentteja. Koska viestintä näiden komponenttien kanssa kulkee rajapintojen ja viitteiden kautta, ohjelmakoodi on täysin riippumaton vuorovaikutuksessa käytetystä protokollasta. Samat toiminnot voidaan helposti asettaa saataville useissa tuetuissa protokollissa ja missä tahansa halutussa liitännässä. Seuraavassa kuvassa näkyy, kuinka SCA-sidonnalla varustettu vienti lisätään papulle, joka jo paljastaa käyttöliittymänsä HTTP-, JMS- ja verkkopalveluna.


Edut ovat ilmeiset - joustavuus, monipuolisuus, koodin uudelleenkäyttö, kehitys- ja muokkausnopeus.
Muuten, SCA-sidonta käyttää erityistä protokollaa ja on tarkoitettu kommunikointiin saman palvelimen/klusterin sisällä olevien moduulien välillä. Viestintä tämän sidoksen kautta on vähemmän resursseja ja nopeampaa kuin muut protokollat.

Kokoonpano
Palvelimen ja sovelluksen konfigurointi tehdään palvelimen IBM-konsolin kautta.
ESB:llä, kuten IBM WebSpherellä yleensä, on useita erityisominaisuuksia ja artefakteja. Esimerkiksi käytettäessä samaa tuontia ja vientiä, voit määrittää vastaavien palveluiden päätepisteet lennossa. Palvelukutsuja varten voit määrittää käytäntöjoukkoja erilaisilla säännöillä (voit esimerkiksi asentaa tuen WS-AT-mekanismille, jonka avulla voit kutsua verkkopalvelua samassa tapahtumassa, jossa asiakas toimii; mutta tapahtumatoiminta on jo koko artikkelin aihe), aseta todennusparametrit, yhdistä varmenteita ja paljon muuta.
Konfiguroinnin avulla voit määrittää joitain mekanismeja automaattista reagointia varten poikkeuksellisiin tilanteisiin (esimerkiksi komponenttien suorittamisen automaattinen toistaminen virheiden sattuessa). Voit määrittää komponenttien jäljityksen lennossa tai muuttaa kirjaustasoja. Saatavilla on myös vikatapahtumien hallintapalvelu, jota voidaan tarkoituksella käyttää joukkovirheiden käsittelyyn.
Ja tietysti monia muita asioita voi konfiguroida Java2EE-spesifikaatioiden mukaan, joka on toteutettu, joskus melko tiukasti, IBM Application Serverissä.

Kaikki yllä oleva vahvistaa, että ESB on kätevä, tehokas ja joustava integrointilaite, vaikkakaan ei aina helppo oppia. Tulevaisuudessa sinun tarvitsee vain opetella käyttämään sitä.

Artikkelissa on käytetty seuraavia kuvia:

Mielestäni on olemassa kaksi lähestymistapaa yritysintegraatioväylän rakentamiseen:


  • "integroitavista järjestelmistä";

  • "toteutetuista prosesseista".

Katsotaanpa näitä lähestymistapoja yksityiskohtaisemmin.

Lähestymistapa "integroitavista järjestelmistä"

Tässä tapauksessa integraatioväylää pidetään eräänlaisena siirtona, joka suorittaa viestintäprotokollien reitityksen ja neuvottelun. Kaikki viestit kulkevat ketjun läpi: lähdejärjestelmän sovittimen tulokanava -> reititin -> vastaanotinjärjestelmän lähtökanava. Näiden komponenttien ja tiettyjen teknologioiden välisen viestinnän tyyppi riippuu siitä, voiko yhdestä lähdejärjestelmästä tulevilla viesteillä olla useita kohdejärjestelmiä, odotetusta kuormituksesta ja lähestymistavasta tietojen eheyden varmistamiseksi (käyttämällä yhteistä tapahtumaa kaikille lähdejärjestelmille tai siirretään tietoja jokainen tapahtumansa lähdejärjestelmä).

  1. Riippuvuus järjestelmistä, ei viestityypeistä. Yleensä integroitujen järjestelmien määrä on useita kertoja pienempi kuin lähetettyjen viestityyppien määrä.

  2. Uusien vastaanotinjärjestelmien liittämisen helppous: Uuden vastaanotinjärjestelmän liittämiseksi riittää, että syötät tiedot reititystaulukkoon.

  3. Integraatioratkaisun valvontajärjestelmän helppokäyttöisyys: tiedot valvontajärjestelmään voidaan luoda yhteen paikkaan - reitittimeen (tämä kohta voidaan kuitenkin hyväksyä vain varauksin, koska siellä on dataa, joka syntyy vain integroitujen järjestelmien sovittimet).

  4. Helppokäyttöinen tukiratkaisu. Koska kaikki viestit kulkevat yhden reitittimen läpi, kaikki viestien välityksen ja viestien välisen seurannan riippuvuudet voidaan toteuttaa yhdessä paikassa - tässä reitittimessä.

  5. Järjestelmän jakaminen kehittäjien kesken. Koska järjestelmäydin ja kaikki sovittimet ovat toisistaan ​​riippumattomia (viestintä tapahtuu vain omistettujen ja kuvattujen rajapintojen kautta), niiden kehittämistehtävät voidaan jakaa ohjelmoijien kesken, mikä mahdollistaa integraatioratkaisun luomis- ja toteutusprosessin rinnakkaistamisen.


  1. Ratkaisu soveltuu vain yhtenäisen sanomanvälityslogiikan toteuttamiseen, ts. jos riippuvuuksien ja muunnosten seurantaan on olemassa sääntöjä, jotka ovat yhteisiä kaikille tai useimmille viesteille. Jos erilaisia ​​tyyppejä Viesteissä on täysin erilainen riippuvuuden seuranta- ja vaihdon hallintalogiikka, se on joko siirrettävä sovittimiin, mikä eliminoi edun 4, tai sitä ei voida toteuttaa ollenkaan.

  2. Tämä menetelmä soveltuu asynkronisen vaihdon toteuttamiseen. Synkronisen tai sekavaihdon tapauksessa tämän lähestymistavan toteuttamisen monimutkaisuus lisääntyy merkittävästi.

  3. Ratkaisun suorituskyky saattaa heikentyä. Esimerkiksi, jos viesti lähetetään kullekin vastaanottajajärjestelmälle erillisessä tapahtumassa, lähdejärjestelmän, ytimen ja vastaanottojärjestelmän erottaminen jonojen mukaan on tarpeen. Näistä jonoista voi tulla järjestelmän pullonkaula.

Lähestymistapa "toteutetuista prosesseista"

Tällöin tarkastellaan jokaista liiketoimintaprosessia erikseen, jossa vaaditaan tiedonvaihtoa useiden järjestelmien välillä. Bussi toteuttaa tämän vaihdon. Tapahtuma, joka aloittaa vaihtoprosessin, on viestin vastaanottaminen lähdejärjestelmästä. Lähdejärjestelmästä vastaanotettu sanoma välitetään yhdelle tai useammalle vastaanottajajärjestelmälle, jolloin ei toteuteta vain siirtotoimintoja, vaan myös viestien käsittelyn tulosta seurataan ja lähetettyä viestiä korreloidaan muiden kanssa.

Tällä lähestymistavalla on seuraavat edut:


  1. Joustavuus. Tämän lähestymistavan avulla voit toteuttaa oman erillisen vaihtologiikkasi kullekin viestityypille. Tämä logiikka voi olla melko ei-triviaali.

  2. Sekä asynkronisen että synkronisen vaihdon toteutuksen monimutkaisuus on suunnilleen sama.

  3. Säikeiden riippumattomuus, tarkemmin tässä tapauksessa on oikeampaa puhua prosesseista. Yhden vaihtoprosessin toteutuksen aikana tehdyt tekniset päätökset eivät vaikuta toisen toteutuksen monimutkaisuuteen.

Tällä lähestymistavalla on seuraavat haitat:


  1. Riippuvuus viestityypeistä. Yleensä viestityyppien määrä on monta kertaa suurempi kuin integroitujen järjestelmien lukumäärä. Uutta lähdejärjestelmää kytkettäessä väylään on tarpeen reitittää sanomat tyypeittäin ja toteuttaa erillinen vaihtoprosessi jokaiselle sanomatyypille.

  2. Jos sama vaihtologiikka täytyy toteuttaa useille sanomatyypeille, niin koodin ja/tai väyläasetusten kopiointi on mahdollista.

  3. Viestinvälitysprosessit riippuvat järjestelmäsovittimista ja voivat olla riippuvaisia ​​toisistaan ​​sekä palveluprosesseista. Tällaisten riippuvuuksien esiintyminen vähentää integraatioratkaisun kehittämis- ja toteutusprosessin rinnakkaisuuden astetta. Joidenkin komponenttien kehittäjät ovat riippuvaisia ​​integraatioratkaisun muiden komponenttien kehittäjien työn tuloksista.

Lähestymistavan valinta suoritetaan seuraavan algoritmin mukaan:


  1. Hanki luettelo ja kuvaus integroiduista järjestelmistä ja viestityypeistä analyytikoilta.

  2. Hanki analyytikoilta luettelo ja kuvaus liiketoimintaprosesseista, joihin liittyy integrointia vaativia järjestelmiä.

  3. Jos prosessit ovat triviaaleja ja järjestelmiä on paljon vähemmän kuin sanomatyyppejä, vaihto on pääosin asynkronista ja yksi viesti on myös siirrettävä useaan järjestelmään, valitaan ensimmäinen lähestymistapa. Päätä tapahtumanhallintakäytännöstä.

  4. Jos prosessit edellyttävät pääasiassa synkronista vaihtoa, kun taas prosessit ovat monimutkaisia, ts. viestin kulku riippuu sen käsittelyn tuloksista vastaanotinjärjestelmissä, niin valitsemme toisen lähestymistavan. Toinen argumentti tämän lähestymistavan puolesta on se, että viestityyppien lukumäärä on verrattavissa integroitujen järjestelmien määrään.

On ymmärrettävä selvästi, että nämä toteutustavat eivät ole dogmia, ei ole tarpeen valita vain ensimmäistä lähestymistapaa tai vain toista. Niitä voi aina yhdistää, modernit yrityshuoltorenkaat ( ESB) antaa sinun tehdä niin.

Tykkäsin postauksesta -

ESB (Enterprise Service Bus)- kirjaimellisesti voidaan kääntää "yrityspalveluväyläksi". ESB kuvaa hyvin todellista ohjelmistotuotetta, jonka tavoitteena on yksinkertaistaa palvelun kutsumista hallitsemalla kaikkea vuorovaikutusta matkalla palvelun kuluttajasta palveluntarjoajaan ja päinvastoin. ESB:n kaksi yleisimmin mainittua ominaisuutta ovat viestimuunnos ja sanoman reititys. ESB:lle SOA-arkkitehtuurissa on uskottu tärkein tehtävä varmistaa järjestelmien yhteentoimivuus verkon löyhästi kytketyistä palveluista. Gartnerin analyytikot määrittelevät ESB:n nimellä uusi tyyppi ohjelmisto keskitaso, joka yhdistää toiminnallisuutta muita jo olemassa olevia väliohjelmistotyyppejä. Enterprise Service Bus tukee Web-palveluita toteuttamalla SOAP-protokollan (Simple Object Access Protocol) ja käyttämällä WSDL (Web Services Description Language) -spesifikaatiota ja Universal Description, Discovery and Integration (UDDI) -spesifikaatiota. Yleiskuvaus, tunnistus ja integrointi).

ESB:n päätoiminnot

  • Vuorovaikutusrajapintojen tarjoaminen
  • Viestien lähettäminen ja reititys
  • Tietojen muuntaminen
  • Tapahtuma-anturit
  • Politiikan hallinta

ESB-arkkitehtuuri

ESB-arkkitehtuurin perustana on ajatus yhteisen integraatioinfrastruktuurin käyttämisestä kaikille viestintäpohjaisille yrityssovelluksille. Kaikki sovellukset ovat vuorovaikutuksessa yhden pisteen kautta, mikä tarvittaessa varmistaa puheluiden, datan muuntamisen ja tapahtumien turvallisuuden. Tässä tapauksessa sovellusten integroinnin tavoitteena on luoda yksi moduuli (tai sovitin), joka vastaa sovelluksen "liittämisestä" ESB:hen. Viestien myöhemmän käsittelyn ja niiden reitityksen muihin järjestelmiin ESB suorittaa vakiintuneiden liiketoimintasääntöjen perusteella itsenäisesti. Tämä lähestymistapa tarjoaa erinomaisen joustavuuden, helpon skaalauksen ja siirrettävyyden, joten jos yksi väylään liitetyistä sovelluksista vaihtuu, muita ei tarvitse konfiguroida uudelleen.

Hyödyt ja haitat

ESB:n edut ovat:

  • Olemassa olevien järjestelmien ylläpito on nopeampaa ja halvempaa.
  • Joustavuuden lisääminen.
  • ESB perustuu maailmanlaajuisesti tunnustettuihin standardeihin.
  • Suuren määrän konfiguraatioita integrointia varten.

ESB:n haittoja ovat mm.

  • Toteutuksen monimutkaisuus
  • Vaatii suuria resursseja.

Enterprise Service Bus -kehitys

Web-palvelujen erottuva piirre on, että kuluttajalla on kyky sitoutua dynaamisesti palveluntarjoajaan. Kaikki tämä tapahtuu kahden päätoiminnon ansiosta:

  • Havaittavuus. Verkkopalveluntarjoajat voidaan koota automaattisesti ylläpidettäviin hakemistoihin. Näin ollen kuluttajalle annetaan mahdollisuus selata tällaista hakemistoa löytääkseen halutun palvelun tarjoajan.
  • Itsekuvaus. Verkkopalvelu pystyy kuvailemaan itseään koneellisesti luettavalla tavalla. Näin ollen on mahdollista tunnistaa kaksi tai useampi saman palvelun tarjoaja, vaikka ne olisi toteutettu aivan eri tavalla, koska niiden kuvaavat rajapinnat vastaavat samaa kuvausta.

Tämä verkkopalveluiden toiminnallisuus eroaa olennaisesti olemassa olevista integrointimenetelmistä, joissa rajapinnat määriteltiin käännösaikana ja kuluttajan ja palveluntarjoajan kommunikoinnin aikana. Viestimuodot olivat ei-kuvaavia, joten niitä ei voitu pakottaa noudattamaan tätä muotoa, joten ne perustuivat sisäiseen käytäntöön, jolloin vastaanottaja ei voinut käsitellä lähettäjän luomaa rakennetta.

Itsekuvaavat verkkopalvelut helpottavat integraatiota ilmoittamalla noudatettaviksi rajapintoja. Dynaamisen palvelun löytämisen avulla kuluttaja kuitenkin vapautui riippuvuudesta tietystä palveluntarjoajasta, jolla oli tietty osoite, ja tämä kyky loi omat ongelmansa. Oli melko vaikeaa ratkaista kysymystä kuluttajan yhdistämisestä palveluntarjoajaan lopullisesti käännösaikana ja mahdollisesti uuden palveluntarjoajan löytämisestä jokaisen puhelun yhteydessä ajon aikana. Sitten ESB keksi toisen vaihtoehdon - antaa kuluttajalle mahdollisuuden ottaa dynaamisesti yhteyttä välityspalvelimeen kerran, samalla kun hän voi käyttää useita palveluntarjoajia ja palveluntarjoajia, jotka saattavat ilmestyä tulevaisuudessa tämän välityspalvelun kautta. Kaikki tämä tarkoittaa, että ESB tarjoaa palveluita kuluttajien soitettaviksi ja antaa kuluttajille mahdollisuuden löytää palveluja ohjelmallisesti.

Palveluyhdyskäytävä

Ns. palveluyhdyskäytävä on synkronisen ESB:n kulmakivi. Se toimii välittäjänä palveluntarjoajien ja palvelun kuluttajien välillä ja helpottaa synkronisten puheluiden käsittelyä välittäjän avulla. Tämä yhdyskäytävä tarjoaa pääsyn kaikkiin tunnettuihin palveluihin ja kunkin välityspalvelinpalveluihin, joten se on eräänlainen "yksi ikkuna" kuluttajalle, joka haluaa soittaa mihin tahansa palveluun mistä tahansa yhdyskäytävän tuntemasta palveluntarjoajasta. Kun verkkopalveluita koordinoi yhdyskäytävä, ne kuvaavat itseään. Jokainen palvelu paljastaa käyttöliittymänsä WSDL:n avulla, joka koostuu seuraavista neljästä osasta:

  • Porttityypit ovat joukko toimintoja, joita verkkopalvelu suorittaa.
  • Viestit - eli pyyntöjen ja vastausten muoto
  • Tyypit – Web-palvelun käyttämät tietotyypit
  • Linkit - osoite operaatioon kutsumiseen

Gateway-verkkopalvelut ja tarkemmin sanottuna niiden välityspalvelinpalvelut ovat myös löydettävissä. Yhdyskäytävä tarjoaa tämän ominaisuuden UDDI-palvelun muodossa. Löytääkseen palvelun kutsuosoitteen kuluttaja kysyy yhdyskäytävän UDDI-palvelulta halutun WSDL-operaation tarjoajaluetteloa ja vastaanottaa takaisin yhdyskäytävän välityspalvelimen osoitteen tälle toiminnolle.

Viestibussi

Message Bus -kuvio on asynkronisen ESB:n perusta. Viestiväylä on joukko viestikanavia, jotka on konfiguroitu pyyntö-vastauskanavien pareiksi. Jokainen pari edustaa palvelua, johon linja-autoa käyttävä kuluttaja voi soittaa. Kuluttaja lähettää viestin palvelun pyyntöjonoon ja kuuntelee sitten vastausjonoa saadakseen tuloksen. Kuluttaja ei todellakaan tiedä, kuka palvelun tarjoaa. Palveluntarjoajat ovat myös yhteydessä viestiväylään ja kuuntelevat pyyntöviestejä. Kun palveluntarjoajia on useita, niiden välillä sekä kuluttajien välillä käydään kilpailua tietyn pyynnön vastaanottamisesta. Sanomaväylän toteuttama viestijärjestelmä toimii sanomavälittäjänä ja jakaa pyynnöt palveluntarjoajille optimoiden jakelun kuormitusasteen, verkon viiveiden jne. mukaan. Kun palveluntarjoaja on vastaanottanut pyynnön, se suorittaa palvelun ja laittaa tuloksen viestissä jonossa vastaukset, eli palveluntarjoaja ja kuluttaja eivät koskaan tiedä toistensa sijaintia. Tämä viestiväylä on ESB:n ydin.

Nykyaikaiset sovellukset toimivat harvoin erillään; sovellus ei voi tehdä mitään merkityksellistä ilman, että se on vuorovaikutuksessa muiden sovellusten kanssa. Palvelukeskeinen arkkitehtuuri integroi sovelluksia yhteistä työtä ja nopeuttaa heidän työtä jakamalla sovelluksen osiin, jotka voidaan yhdistää toisiinsa. SOA-malli (palvelun kuluttajat soittavat palveluntarjoajille) saattaa vaikuttaa yksinkertaiselta, mutta kaksi tärkeää ongelmaa ilmenee:

  1. Miten kuluttaja löytää sen palvelun tarjoajan, johon hän haluaa vedota?
  2. Kuinka kuluttaja voi nopeasti ja luotettavasti kutsua palvelua hitaassa ja epäluotettavassa verkossa?

Osoittautuu, että näihin molempiin ongelmiin on olemassa suora ratkaisu - lähestymistapa, jota kutsutaan yrityspalveluväyläksi (ESB). ESB yksinkertaistaa palvelun kutsumista sekä kuluttajan että palveluntarjoajan kannalta hallitsemalla kaikkia niiden välisiä monimutkaisia ​​vuorovaikutuksia. ESB ei ainoastaan ​​helpota sovellusten (tai niiden osien) soittamista palveluun, vaan auttaa niitä myös välittämään tietoja ja levittämään tapahtumailmoituksia. ESB-suunnittelu toteuttaa monia tunnustettuja suunnittelumalleja ja standardispesifikaatioita.

Kirjoitin tämän artikkelin auttaakseni sinua kehittäjänä ymmärtämään, miksi ESB on hyödyllinen ja tarpeellinen osa sovellusten integrointia, mukaan lukien SOA. Tämä artikkeli ei kata määritelmiä tai tuotteita, vaan keskittyy ESB:n ominaisuuksiin ja toimintoihin, joita sinun ei tarvitse ottaa käyttöön itse. Tässä artikkelissa kerrotaan, mitä ESB tekee hyväksesi.

Soittopalvelut

Auttaakseni sinua ymmärtämään sovellusten ja SOA-integraation, aloitan tarkastelemalla Web-palvelujen toimintaa. Verkkopalvelut ovat ainoa tapa toteuttaa palvelukutsu. Tämä ei ehkä ole edes paras tapa, mutta se on tällä hetkellä standardoiduin lähestymistapa, ja verkkopalvelut auttavat todella suunnittelussa, mitä aion tehdä.

Ensin minun on selitettävä terminologia. Verkkopalvelu on paljon kuin toiminto prosessiohjelmointissa: sillä on nimi, parametrit ja tulos. Nimi on Uniform Resource Identifier(URI - Uniform Resource Identifier), joka tarjoaja Web Services -palvelua käytetään tarjoamaan verkkopalvelu saataville päätepiste. Web-palveluntarjoaja käyttää päätepisteen URI-osoitetta osoitteena Web-palvelun paikallistamiseen ja kutsumiseen. SISÄÄN pyyntö on tietty toiminto ja parametrit, jotka kuluttaja välittää verkkopalveluun, kun päätepistettä kutsutaan. Palvelun suorittamisen jälkeen päätepiste lähettää vastaus takaisin kuluttajalle, joka ilmoittaa onnistumisesta (tai virheestä) ja sisältää palvelun tuloksen. Toisin sanoen kuluttaja soittaa palveluntarjoajan päätepisteeseen, lähettää pyynnön ja saa vastauksen takaisin.

Nykyinen määritelmä web-palvelun toteuttamiselle on WS-I Basic Profile 1.1, joka koostuu "SOAP 1.1 over HTTP 1.1" -protokollasta, joka on kuvattu Web Services Description Language (WSDL) 1.1:ssä (katso linkki itse spesifikaatio). "SOAP over HTTP" -kohdassa kuluttaja käynnistää palvelun käyttämällä HTTP-pyynnössä HTTP:n kautta välitettyä SOAP-pyyntöä. Kuluttaja estää synkronisesti HTTP-socketin ja odottaa HTTP-vastausta, joka sisältää SOAP-vastauksen. Päätepisteen API kuvataan sen WSDL:llä, kuluttajan ja palveluntarjoajan välisellä sopimuksella.

Nyt kun ymmärrät terminologian, katsotaanpa, miten kuluttaja toimii soittaessaan palveluun: synkroniset ja asynkroniset puhelut.

Synkronisten ja asynkronisten puheluiden vertailu

Kuluttaja voi soittaa palveluun synkronisesti tai asynkronisesti. Kuluttajan näkökulmasta ero on seuraava:

  • Synkroninen. Kuluttaja käyttää yhtä säiettä soittaakseen palveluun; säie lähettää pyynnön, estää palvelun ollessa käynnissä ja odottaa vastausta;
  • Asynkroninen. Kuluttaja käyttää kahta säiettä soittaakseen palveluun; yksi - lähettää pyynnön, toinen - saada vastaus.

Käsitteet asynkroninen Ja synkroninen sekoitetaan usein käsitteisiin johdonmukainen Ja rinnakkain. Jälkimmäiset käsitteet viittaavat järjestykseen, jossa eri tehtävät suoritetaan, kun synkroninen Ja asynkroninen käsitellä tapaa, jolla säie suorittaa yksittäisen tehtävän, kuten yksittäisen palvelun soittamisen. hyvällä tavalla Synkronisen ja asynkronisen puhelun eron ymmärtäminen on otettava huomioon vikasietoisuuden vaikutukset:

  • Synkroninen. Jos kuluttaja kaatuu eston aikana palvelun ollessa käynnissä, hän ei voi muodostaa yhteyttä kyseiseen palveluun uudelleen käynnistyksen jälkeen, joten vastaus menetetään. Kuluttajan tulee toistaa pyyntö ja toivoa, ettei hätätilannetta ole;
  • Asynkroninen. Jos kuluttajalla on hätätilanne odottaessaan vastausta pyyntöön, kuluttaja voi uudelleenkäynnistyksen jälkeen jatkaa vastauksen odottamista, eli vastaus ei katoa.

Failover ei ole ainoa ero synkronisten ja asynkronisten puhelujen välillä, mutta jos yrität määrittää käyttämäsi puhelun tyylin, vikasietotilan tarkastelu auttaa sinua tekemään sen.

Nyt kun tiedät kuinka valita vuorovaikutustapa palvelua vedettäessä, katsotaanpa vaihtoehtoja kuluttajan yhdistämiseksi palveluntarjoajaan. Kuluttaja voi valita seuraavista liitäntävaihtoehdoista:

  1. Synkroninen suora puhelu;
  2. Synkroninen puhelu välittäjän (välittäjä) kautta;
  3. Asynkroninen puhelu välittäjän (välittäjä) kautta.

Harkitsen jokaista vaihtoehtoa erikseen.

Synkroninen suora puhelu

"SOAP over HTTP" -menetelmä Web-palvelun kutsumisessa on suora: kuten funktion kutsuminen, kuluttaja tietää päätepisteen osoitteen ja kutsuu sitä suoraan. Jotta puhelu onnistuisi, verkkopalvelun on oltava käynnissä, kun kuluttaja soittaa päätepisteeseen, ja sen on vastattava ennen kuluttajan aikakatkaisua. Jos verkkopalvelu otetaan käyttöön uuteen paikkaan (esimerkiksi toiseen Internet-toimialueeseen), kuluttajalle on ilmoitettava uudesta päätepisteen URI:sta. Kun otetaan käyttöön useita samantyyppisiä palveluntarjoajia, kunkin palveluntarjoajan päätepisteellä on oltava erilainen URI. Tietyn palveluntarjoajan valitsemiseksi kuluttajan on tiedettävä jokainen tällainen URI.

Harkitse esimerkiksi yksinkertaista verkkopalvelua osakekurssien saamiseksi: kuluttaja lähettää osakesymbolin ja saa takaisin sen nykyisen arvon. Tällaista palvelua voivat tarjota eri välittäjäyritykset, joilla jokaisella on oma URI. Verkkopalvelun URI:n löytäminen on kana ja muna -ongelma. Jos kuluttaja tietäisi päätepisteen sijainnin, hän voisi pyytää palvelun osoitteen, mutta mikä on osoite, joka kuluttajan on tiedettävä voidakseen pyytää osoitetta.

Tämän ongelman ratkaisemiseksi UDDI (Universal Description Discovery and Integration) -spesifikaatio kuvaa Web-palvelun, joka on hakemisto (samanlainen kuin puhelinluettelo) muiden Web-palvelujen löytämiseksi. Ajatuksena on ottaa käyttöön UDDI-palvelu kuluttajan hyvin tuntemaan osoitteeseen; Kuluttaja voi käyttää UDDI:tä muiden verkkopalvelujen etsimiseen.

Osakekurssipalvelutilanteessa kuluttaja tietää UDDI-palvelun osoitteen, joka puolestaan ​​tietää pörssikurssipalveluiden osoitteet (ks. kuva 1).


Kuvassa 2 näkyy, kuinka kuluttaja etsii UDDI-palvelun avulla pörssikurssipalvelun tarjoajien päätepisteen ja soittaa jollekin niistä. Prosessi tapahtuu seuraavan algoritmin mukaan:

  1. Kuluttaja kysyy UDDI:lta luetteloa palveluntarjoajista;
  2. Kuluttaja valitsee palveluntarjoajan päätepisteen UDDI:lta saadusta luettelosta;
  3. Kuluttaja kutsuu tätä päätepisteeksi.

Huomaan, että palveluntarjoajan valinnan algoritmi riippuu täysin kuluttajasta; tässä esimerkissä kuluttaja yksinkertaisesti valitsee luettelon ensimmäisen. Todellisessa tilanteessa tämä valinta voi olla vaikeampaa.

Huomautan myös, että koska palvelun päätepiste voi muuttua, kuluttajan on joka kerta, kun hän haluaa kutsua palvelua, kysyttävä uudelleen UDDI ja analysoitava, ovatko palveluntarjoajan tiedot muuttuneet. Tarve kysyä UDDI:ta jokaisessa palvelupuhelussa aiheuttaa lisäkustannuksia, varsinkin normaalitilanteessa, jossa palveluntarjoajan tiedot eivät muutu.

Synkroninen välityspalvelinpuhelu

Suoran kutsun haittana on, että kuluttajan on tiedettävä palveluntarjoajan päätepisteen URI voidakseen kutsua palvelua. Se käyttää UDDI:ta hakemistona tämän URI:n etsimiseen. Jos palveluntarjoajia on useita, UDDI sisältää useita URI:ita ja kuluttajan on valittava niistä yksi. Jos toimittaja muuttaa päätepisteen URI:tä, sen on rekisteröidyttävä uudelleen UDDI-palvelimeen, jotta UDDI voi tallentaa uuden URI:n. Kuluttajan on pyydettävä UDDI:ta uudelleen saadakseen uusi URI. Pohjimmiltaan tämä tarkoittaa, että joka kerta, kun kuluttaja haluaa kutsua palvelua, hänen on kysyttävä UDDI:ltä päätepisteiden URI:t ja valittava niistä yksi. Tämä johtaa merkittävään vaivannäköön kuluttajalle säännöllisissä UDDI-kyselyissä ja palveluntarjoajan valintatoiminnoissa. Tämä lähestymistapa pakottaa myös kuluttajan valitsemaan palveluntarjoajan jollain tavalla, ilmeisesti vastaavalta listalta.

Yksi tapa yksinkertaistaa ongelmaa on ottaa käyttöön välittäjä, joka toimii välittäjänä Web-palvelun kutsumisessa. Kuluttaja ei enää soita suoraan palveluntarjoajan palveluun, vaan soittaa välittäjän välityspalveluun, joka puolestaan ​​soittaa palveluntarjoajan palveluun. Kuluttajan on tiedettävä välityspalvelimen päätepisteen URI ja siksi hän etsii osoitteen UDDI:n avulla, mutta tässä tapauksessa UDDI palauttaa vain yhden URI:n, eikä kuluttajan tarvitse tehdä valintaa. Kuluttaja ei välttämättä edes tiedä, että päätepiste on välityspalvelu; se tietää vain, että se voi käyttää tätä URI:tä verkkopalveluun soittamiseen. Välittäjä yhdistää kuluttajan palveluntarjoajiin (ks. kuva 3).


Välityspalvelimen URI:n on oltava vakaa: kun kuluttaja käyttää UDDI:ta saadakseen välityspalvelimen URI:n ensimmäisen kerran, kun palvelua kutsutaan, kuluttaja voi käyttää tätä URI:ta uudelleen peräkkäisissä puheluissa (ainakin kunnes välityspalvelinpalvelu lopetetaan). Sillä välin välityspalvelin pitää kirjaa palveluntarjoajista, heidän URI:istaan ​​(jotka voivat vaihdella puhelujen välillä), niiden saatavuudesta (epäonnistuiko viimeinen puhelu), niiden lataamisesta (kuinka kauan viimeinen puhelu kesti) ja niin edelleen. Välityspalvelu voi valita kullekin puhelulle parhaan palveluntarjoajan, mikä vapauttaa kuluttajan. Kuluttaja yksinkertaisesti soittaa samaan välityspalveluun joka kerta ja se sovittaa yhteen eri palveluntarjoajien kanssa.

Kuvassa 4 on kaavio siitä, kuinka kuluttaja käyttää välittäjää soittaessaan palveluun. Työn algoritmi on seuraava:

  1. Kuluttaja kysyy UDDI:lta luetteloa palveluntarjoajista. UDDI:sta palautettu URI on itse asiassa välityspalvelin. UDDI palauttaa vain yhden URI:n, ei useita, koska välittäjällä on vain yksi välityspalvelin jokaista palvelua kohden;
  2. Kuluttaja käyttää palvelua proxy-URI:n avulla;
  3. Välityspalvelin valitsee palveluntarjoajan käytettävissä olevien palveluntarjoajien luettelosta;
  4. Välityspalvelin soittaa valitun palveluntarjoajan päätepisteeseen.

Huomaa, että palveluntarjoajan valinta on jätetty kuluttajan käsistä – se valinta toteutetaan välittäjän välityspalvelussa. Tämä helpottaa kuluttajan elämää. Loppujen lopuksi välityspalvelun valintaprosessi ei saa olla erilainen kuin kuluttajan käyttämä prosessi. Koska UDDI-palvelin ja välityspalvelin on kuitenkin kapseloitu välittäjään, tietyt toiminnot voidaan toteuttaa helposti, kuten UDDI-tietojen tallentaminen välimuistiin ja välityspalvelun UDDI-palvelimelta ilmoitusten vastaanottaminen, että välimuistin tiedot ovat vanhentuneita.

Huomaa myös, että koska välityspalvelinosoite on vakaa, kuluttajan ei tarvitse jatkuvasti pyytää UDDI:ta jokaisessa palvelupuhelussa. Toisin sanoen kuluttajan tarvitsee vain pyytää UDDI:tä kerran, tallentaa välimuistipalvelun osoite välimuistiin ja käyttää sitä soittaessaan palveluun uudelleen. Tämä vähentää huomattavasti palveluun soittamisen yleiskustannuksia.

Asynkroninen puhelu välityspalvelimen kautta

Synkronisen lähestymistavan haittana on, että kuluttajan on odotettava palvelun valmistumista - säiettä on estettävä palvelun ajaksi. Jos palvelu on käynnissä pitkään, kuluttaja voi lakata odottamasta vastausta. Kun kuluttaja tekee pyynnön (ja jos toimivia palveluntarjoajia ei ole tai ne ovat ylikuormitettuja), hän ei voi odottaa. Ja kuten edellä mainittiin, jos kuluttajalla on hätätilanne estotyön aikana, myös uudelleenkäynnistyksen jälkeen vastaus katoaa ja puhelua on yritettävä uudelleen.

Yleinen ratkaisu tähän ongelmaan on, että kuluttaja soittaa palveluun asynkronisesti. Tällä lähestymistavalla kuluttaja käyttää yhtä säiettä pyynnön lähettämiseen ja toista säiettä vastauksen vastaanottamiseen. Eli kuluttajan ei tarvitse estää työtä odottaessaan vastausta, vaan hän voi tehdä muuta työtä sillä välin. Näin ollen kuluttaja on paljon vähemmän herkkä palvelun kestoon palveluntarjoajan luona.

Välittäjä, jonka avulla kuluttaja voi kutsua verkkopalvelua asynkronisesti, on toteutettu käyttämällä viestintäjärjestelmää, joka käyttää viestijonoja pyynnön lähettämiseen ja vastauksen vastaanottamiseen. Synkronisen välityspalvelimen tapaan viestijonojen pari toimii yhtenä osoitteena, jota kuluttaja käyttää palvelun kutsumiseen, riippumatta mahdollisten kuuntelevien tarjoajien määrästä (katso kuva 5).


Tämä lähestymistapa käyttää Request-Reply-mallia Web-palvelun käynnistämiseen. WS-I BP 1.1:ssä määritellyn HTTP-protokollan sijaan siirtotoiminnot voivat nyt suorittaa viestijonoja. SOAP-pyyntö ja vastaus ovat samat kuin WS-I BP:ssä, mutta ne on kääritty viestiviesteihin.

Kuvassa 6 näkyy, kuinka kuluttaja käynnistää palvelun asynkronisesti välittäjän kautta seuraavan algoritmin avulla:

  1. Kuluttaja lähettää SOAP-pyynnön viestinä pyyntöjonoon. Kuluttaja lopettaa ja voi käyttää lankaa muiden tehtävien suorittamiseen;
  2. Jokainen palveluntarjoaja on pyyntöjonon kuluttaja, mikä tekee heistä kilpailevia kuluttajia. Viestijärjestelmä määrittää, mikä palveluntarjoaja voi vastaanottaa viestin, ja varmistaa, että vain yksi palveluntarjoaja vastaanottaa sen. Kuinka tämä käytännössä toimii, riippuu viestintäjärjestelmän toteutuksesta;
  3. Voittava palveluntarjoaja vastaanottaa viestin pyyntöjonosta;
  4. Palveluntarjoaja suorittaa palvelun;
  5. Palveluntarjoaja lähettää SOAP-vastauksen viestinä vastausjonoon. Nyt palveluntarjoaja on lopettanut työnsä ja voi käyttää säiettään muihin tehtäviin (esimerkiksi odottamaan seuraavaa pyyntöä);
  6. Kuunteleva lanka, kuluttaja, saa viestin, joka sisältää SOAP-vastauksen.

Huomaa, että palveluntarjoajan valintaominaisuus on nyt otettu käyttöön viestintäjärjestelmässä, mikä helpottaa kuluttajan elämää. Huomaa myös, että jos kuluttajalla on hätätilanne pyynnön lähettämisen jälkeen (ja vaikka vastaus olisi tuolloin valmis), viestijärjestelmä pitää vastauksen vastausjonossa, kunnes kuluttaja on taas toiminnassa.

Huomaa myös, että kuluttaja ei käytä UDDI:tä pyyntö- ja vastausjonojen etsimiseen. Tällä hetkellä ei ole olemassa vakiopalvelua jonoosoitteiden parin palauttamiseen, joten kuluttajan täytyy vain tietää nämä osoitteet. Ne joko koodataan kuluttajaohjelmaan tai ne luetaan asetustiedostosta. Tulevaisuudessa joko laajenna UDDI:tä tai määritä vastaava palvelu, jota kuluttaja voi pyytää määrittämään jonoparin tietyn palvelun käynnistämiseksi.

Nyt tiedät palveluiden soittamisen yhteystyyppivaihtoehdot. Katsotaanpa muita integrointiominaisuuksia, jotka voivat myös olla hyödyllisiä, ja sitten kuinka kehittää ESB, joka tarjoaa meille nämä ominaisuudet.

Muut integrointivaihtoehdot

ESB tarjoaa myös mahdollisuuden mennä palvelukutsuja pidemmälle ja integroida sovelluksia ja SOA:n osia muiden teknologioiden avulla. Palvelupuhelu on lähes aina kaksisuuntaista toimintaa, eli pyyntö lähetetään kuluttajalta palveluntarjoajalle ja vastaus lähetetään päinvastaiseen suuntaan. Muut integraatiotekniikat toimivat yksisuuntaisina toimintoina, joissa lähettäjä välittää tietoa vastaanottajalle eikä odota vastausta; vastaanottaja yksinkertaisesti saa tiedon ilman vastausta.

Tiedonsiirto

Joskus sovelluksen tarvitsee vain siirtää tietoja toiselle sovellukselle ilman, että sen tarvitsee kutsua vastaanotinproseduuria ja varmasti odottamatta tulosta. Lähettäjän ei tarvitse kertoa vastaanottajalle mitä tehdä tiedoilla; se yksinkertaisesti tuo tiedot saataville.

Palvelukutsulla voidaan siirtää tietoja, mikä vastaa setter-menetelmän kutsumista, mutta tiedonsiirto tapahtuu RPC-periaatteen mukaisesti. Todellisuudessa tietojen siirtäminen on enemmän kuin tiedostojen siirtoa: lähettäjä vie tiedot ja vastaanottaja tuo tiedot ilman, että vastaanottajalle nimenomaisesti kerrotaan, mitä tiedoilla tulee tehdä. Tämä muistuttaa enemmän dokumenttityyppistä SOAP-viestiä kuin RPC-tyylistä viestiä.

ESB:n käyttö tiedonsiirrossa parantaa kykyä löytää vastaanottaja ja siirtää tiedot turvallisesti. Lähettäjän ei tarvitse tietää kuinka löytää vastaanottaja, sen tarvitsee vain tietää kuinka löytää ESB ja luottaa siihen, että se löytää vastaanottajan. ESB vastaa myös luotettavasta tiedonsiirrosta. Lähettäjä voi yksinkertaisesti lähettää tiedot ESB:lle ja olla varma, että ne lähetetään.

Lisätietoja tiedonsiirtotekniikasta on asiakirjaviestimallissa (lisätietoja on kirjassa " ", johon linkki on " " -osiossa).

Tapahtuma-ilmoitus

Joskus yhden sovelluksen muutoksesta on ilmoitettava muille sovelluksille. Jos kuluttaja esimerkiksi vaihtaa osoitetaan yhdessä hakemuksessa, on ilmoitettava muille sovelluksille, joilla on oma tietokanta, jotta he voivat korjata tietueensa.

Jälleen kerran yksi sovellus voi soittaa palveluun toisessa sovelluksessa ilmoittaakseen muutoksesta, mutta tähän lähestymistapaan liittyy kolme ongelmaa. Kaksi ensimmäistä ongelmaa ovat samat kuin tiedonsiirrossa. Ensinnäkin palvelupuhelu on liian tarkka siinä suhteessa, että se kertoo vastaanottajalle, mitä tiedoilla tehdä, ja toiseksi se on taipumus olla kaksisuuntainen, jolloin lähettäjä odottaa vastausta (jopa asynkronisesti), jota se ei todellakaan halua. tee..

Kolmas ja tärkein seikka soitettaessa palveluun ilmoittamaan tapahtumasta on, että palveluun soittaminen on luonnostaan ​​yksi-yhteen, kuluttaja-palveluntarjoaja prosessi, kun taas tapahtumailmoitus on pohjimmiltaan yksi-moneen prosessi." on tarkoitettu kaikille kiinnostuneille vastaanottajille. Palvelupuhelun avulla lähettäjän olisi seurattava kaikkia kiinnostuneita vastaanottajia ja soitettava palveluun jokaisesta erikseen. Tämä ilmoituslähetys on parasta jättää välittäjän tehtäväksi lähettäjän ja vastaanottajan välillä.

ESB:n käyttäminen tapahtumien ilmoittamiseen parantaa sen kykyä pitää luetteloa kiinnostuneista vastaanottajista ja varmistaa, että ilmoitus toimitetaan kaikille. Sen avulla vastaanottaja voi lähettää ilmoituksen vain kerran ja olla varma, että se toimitetaan kaikille kiinnostuneille vastaanottajille riippumatta siitä, keitä he ovat. Koska tämä toiminto on yksisuuntainen, lähettäjä saattaa tehdä muuta työtä ilmoitusten toimittamisen aikana ja ilmoitukset voidaan toimittaa rinnakkain.

Lisätietoja viestintätekniikasta on Event Message -mallissa (katso jälleen kirjaa "Enterprise Integration Patterns", johon viitataan " " -osiossa).

Enterprise Service Bus -kehitys

Nyt tiedät eron soittamalla suoraan palveluntarjoajan verkkopalveluun ja käyttämällä välittäjää. Opit myös, kuinka välittäjä voi sallia kuluttajan soittaa palveluun synkronisesti tai asynkronisesti.

Välittäjästä käytetään usein nimitystä ESB. Joten miten ESB sopii jo hyväksyttyihin malleihin ja kuvioihin?

Itsekuvaus ja löydettävyys

Se, mikä erottaa verkkopalvelut muista integrointimenetelmistä, on se, että kuluttaja voi sitoutua dynaamisesti palveluntarjoajaan. Tämän tarjoavat seuraavat kaksi päätoimintoa:

  • itsekuvaus. Verkkopalvelu kuvaa itseään koneellisesti luettavalla tavalla. Kaksi tai useampi saman palvelun tarjoaja on välittömästi tunnistettavissa, vaikka ne olisi toteutettu täysin eri tavoin, koska niiden kuvaavat rajapinnat vastaavat samaa kuvausta;
  • Havaittavuus. Verkkopalveluntarjoajat voidaan järjestää automaattisesti ylläpidettyihin hakemistoihin. Kuluttaja voi selata tällaista hakemistoa löytääkseen haluamansa palvelun tarjoajan.

Tämä verkkopalveluiden toiminnallisuus eroaa suuresti olemassa olevista integrointimenetelmistä. Niissä rajapinnat määriteltiin käännöshetkellä sekä kuluttajan ja palveluntarjoajien välisen viestinnän aikana. Viestimuotoja ei ilmaistu kuvailevasti. Ne perustuivat sisäiseen käytäntöön eivätkä voineet pakottaa tätä muotoa, minkä seurauksena vastaanottaja ei pystynyt käsittelemään lähettäjän luomaa rakennetta.

Web-palvelujen itsekuvauskyky yksinkertaisti integraatiota ilmoittamalla noudatettaviksi rajapintoja. Dynaaminen palveluiden löytäminen vapautti kuluttajan riippuvuudesta tietystä palveluntarjoajasta, jolla on tietty osoite, mutta tämä ominaisuus loi myös omat ongelmansa. Pitäisikö kuluttajan etsiä palveluntarjoajia kerran vai jatkuvasti?

Oli vaikea ratkaista ristiriitaa sen välillä, että kuluttaja sitoi palveluntarjoajaan lopullisesti käännöshetkellä ja mahdollisesti uuden palveluntarjoajan löytäminen joka kerta, kun sitä kutsuttiin ajon aikana. ESB ehdotti kolmatta, kompromissivaihtoehtoa, jotta kuluttaja voisi ottaa dynaamisesti yhteyttä välityspalveluun kerran ja silti käyttää useita palveluntarjoajia ja palveluntarjoajia, jotka voivat tulla tulevaisuudessa välityspalvelun kautta.

Näin ESB ei ainoastaan ​​tarjoa palveluita kuluttajien soitettaviksi, vaan tarjoaa myös mahdollisuuden etsiä palveluita ohjelmallisesti.

Palveluyhdyskäytävä

Synkronisen ESB:n perusta on ns. palveluyhdyskäytävä, joka toimii välittäjänä palvelun kuluttajien ja tarjoajien välillä helpottaen synkronisten puheluiden välitettyä käsittelyä. Se tarjoaa pääsyn kaikkiin tunnettuihin palveluihin ja kunkin niistä välityspalveluihin. Siten yhdyskäytävä tarjoaa "yhden ikkunan" kuluttajalle, joka haluaa soittaa mihin tahansa palveluun mistä tahansa yhdyskäytävän tuntemasta palveluntarjoajasta.

Jos yhdyskäytävän koordinoimat palvelut ovat verkkopalveluita, ne ovat itsekuvaavia. Jokainen palvelu ilmoittaa käyttöliittymänsä WSDL:n avulla, joka koostuu seuraavista neljästä osasta:

  1. Porttityypit– Verkkopalvelun suorittamien toimintojen joukko. Porttityyppi voi olla stockBrokerServices porteilla/toiminnoilla, kuten getQuote.
  2. Viestit– Pyyntö- ja vastausmuoto, kuten getQuoteRequest (joka sisältää osakesymbolin) ja getQuoteResponse (joka sisältää hinnan).
  3. Tyypit– Verkkopalvelun käyttämät tietotyypit, kuten symboli ja hinta (tai vain xs:string ja xs:decimal).
  4. Liitännät– Toiminnon kutsumisosoite, esimerkiksi http://stockbroker.example.com/getQuote.

Tällaiset yhdyskäytäväverkkopalvelut (tai tarkemmin sanottuna niiden välityspalvelinpalvelut) ovat myös löydettävissä. Yhdyskäytävä tarjoaa tämän ominaisuuden UDDI-palveluna, kuten aiemmin mainittiin. Löytääkseen palvelun kutsuosoitteen kuluttaja kysyy yhdyskäytävän UDDI-palvelulta luetteloa halutun WSDL-toiminnon tarjoajista ja saa takaisin yhdyskäytävän välityspalvelimen osoitteen kyseiselle toiminnolle.

Viestibussi

Asynkroninen ESB perustuu hyvin tunnettuun Message Bus -kuvioon, joka on kuvattu kirjassa " Yritysintegraatiomallit", johon viitataan osiossa " ". Viestiväylä on joukko viestikanavia (tunnetaan myös jonoina tai aiheina), jotka on tyypillisesti määritetty pyyntö-vastauskanavien pareiksi. Jokainen pari edustaa palvelua, jonka kuluttaja voi kutsua Tämä kuluttaja lähettää viestin palvelun pyyntöjonoon ja sitten (asynkronisesti) kuuntelee vastausjonosta tulosta, jonka se tietää, mikä tulos vastaa hänen nimenomaista pyyntöään, koska tuloksella on oikea korrelaatiotunnus.

Palveluun soittava kuluttaja ei todellakaan tiedä, kuka palvelun tarjoaa. Palveluntarjoajat ovat myös yhteydessä viestiväylään ja kuuntelevat pyyntöviestejä. Jos palveluntarjoajia on useita, ne kilpailevat keskenään kuluttajina tietyn pyynnön vastaanottamisesta. Viestiväylän toteuttama sanomajärjestelmä toimii sanomanhallinnana ja jakaa pyyntösanomia palveluntarjoajille optimoiden tämän jakelun jollain tavalla kuormitustasosta, verkon viiveistä ja niin edelleen riippuen. Kun palveluntarjoaja vastaanottaa pyynnön, se suorittaa palvelun ja liittää tuloksen sanomaan ehdolliseen vastausjonoon. Toisin sanoen palveluntarjoaja ja kuluttaja eivät koskaan tiedä suoraan toistensa sijaintia; he tietävät vain viestiväylän ja vastaavien kanavien osoitteet ja voivat kommunikoida jaettujen kanavien kautta.

Tällainen viestiväylä on ESB:n ydin, eikä tässä ole mitään uutta. Sovellusintegraattorit ovat käyttäneet tätä tekniikkaa yli vuosikymmenen ajan käyttämällä viestijonotuotteita, kuten WebSphere® MQ ja TIBCO Enterprise Message Service. Ja itse asiassa usein sanotaan, että jos käytät yritysviestintätuotteita, sinulla on ESB. IBM:n asiakkaat ovat käyttäneet näitä ominaisuuksia jo jonkin aikaa WebSphere Business Integration Message Brokerin ja WebSphere MQ:n kanssa.

Onko ESB siis vain viestiväylä? Ei, viestiväylä on ehdottomasti asynkronisen ESB:n selkäranka, mutta täysi ESB on enemmän. ESB:llä on ominaisuuksia, joita viestiväylällä ei koskaan ollut: edellä mainitut itsekuvaus- ja löydettävyysominaisuudet.

Paras viestibussi

Joten jos viestiväylä ei ole täysi ESB, mitä muuta ESB tekee?

Perinteisen viestiväylätekniikan haittana on itsekuvauskyvyn puute. Kuluttajan näkökulmasta moniin palveluihin vetoamiseen on monia kanavia. Mutta mitä näistä kanavista tarvitaan, jotta kuluttaja voi vedota haluamaansa palveluun? Kuluttaja ei voi yksinkertaisesti lähettää pyyntöä millekään pyyntökanavalle; sen on tiedettävä oikea kanava, jota käytetään tietyn palvelun kutsumiseen. Muussa tapauksessa hän voi ostaa lentolipun halutun kirjan sijaan. Lisäksi jopa sen jälkeen, kun kuluttaja on määrittänyt (jollakin tavalla) oikean kanavan (ja kanavan, jolla vastausta kuunnellaan), hänen on tiedettävä datamuoto, jossa pyyntö lähetetään (ja missä tietomuodossa hän odottaa vastausta).

Kuten aiemmin mainittiin, synkronisten Web-palveluiden osalta tämän ongelman ratkaisee WSDL, joka on tällä hetkellä muunnos standardista myös asynkronisten palvelujen kuvaamiseen. Pyyntökanavaan liittyvän WSDL:n tulee kuvata, mitä palvelua kanava tarjoaa, sekä pyyntösanoman muoto, joka kuluttajan tulee tarjota. WSDL:n tulisi luultavasti määrittää myös vastauskanava, jota kuluttajan tulee kuunnella saadakseen vastauksen, ja odotetun vastausviestin muoto. Tällä tavalla kutsuva sovellus voi jäsentää ohjelmallisesti palvelun kutsun kanavaparin ja määrittää, tarjoavatko ne haluttua palvelua käyttämällä haluttuja pyyntö- ja vastausviestimuotoja.

Itsekuvaavat palvelukanavat tuovat esiin toisen ongelman, nimittäin etsintäongelman, jonka synkroniset Web-palvelut ratkaisevat UDDI:n kanssa. Kuten aiemmin mainittiin, kuluttaja kysyy UDDI-palvelimelta Web-palveluntarjoajan osoitetta ja palvelin palauttaa kyseisen palveluntarjoajan URL-osoitteen. Kuluttaja käyttää tätä URL-osoitetta soittaakseen palveluun.

ESB tarvitsee vastaavan hakemistopalvelun, jossa on UDDI-tyyppinen API, jonka avulla kuluttaja voi tiedustella halutun WSDL-toiminnon toteuttavan palvelun osoitetta. ESB palauttaa vastaavan pyyntö- ja vastauskanavaparin osoitteen. Eli ESB-asiakkaan, kuten UDDI-asiakkaan, ei tarvitse tietää mitään muuta kuin seuraavaa:

  1. WSDL, joka kuvaa palvelua, johon se haluaa soittaa.
  2. ESB-hakemistopalvelun osoite (joka voidaan johtaa ESB-juuriosoitteesta).

Tämä riittää löytämään palvelun pyyntö- ja vastauskanavat ja aloittamaan palvelun kutsumisen. Lisäksi tämä hakemistopalvelu on vain yksi ESB:n tarjoama palvelu, ikään kuin pääpalvelu muiden palvelujen löytämiseen.

Synkroninen vai asynkroninen?

Palvelun kuluttajat kohtaavat keinotekoisen valinnan kahden vuorovaikutustavan välillä: synkronisen tai asynkronisen. Tämän ongelman ratkaisemiseksi monet ESB:t tukevat molempia tiloja ja voivat itse asiassa tarjota kaksi soittomallia samalle palvelulle. Tässä tapauksessa kuluttaja voi pyytää palvelun osoitetta kaksi vaihtoehtoa: yksi synkroniselle tilalle, toinen asynkroniselle. Kuluttaja voi sitten valita itselleen parhaiten sopivan soittomallin. Mallista riippumatta sama palvelu on käynnissä, vaikka palveluntarjoajan erityinen esiintymä voi vaihdella.

Toisin sanoen ESB on parempi kuin perinteinen viestiväylä, koska ESB tekee palvelusta myös itsekuvaavan ja tarjoaa hakemistopalvelun muiden palvelujen löytämiseksi. Juuri tätä ESB-rakennustuotteiden toimittajat pyrkivät tarjoamaan.

Johtopäätös

Kuten olet nähnyt, palvelua voi kutsua millä tahansa seuraavista tavoista:

  1. Suoraan ja synkronisesti;
  2. Samanaikaisesti välittäjän kautta;
  3. Asynkronisesti välittäjän kautta.

Enterprise Service Bus on välittäjä, joka tukee palvelun kutsumista sekä synkronisessa että asynkronisessa tilassa. Se mahdollistaa myös tietojen ja tapahtumailmoitusten siirron sovellusten välillä. Se auttaa kuluttajia löytämään palveluntarjoajia ja hallitsee niiden välisen vuorovaikutuksen yksityiskohtia.

Synkroninen ESB on palveluyhdyskäytävä, joka toimii useiden palvelujen keskuskoordinaattorina. Asynkroninen ESB on viestiväylä, jonka palvelut tukevat myös Web-palveluiden itsekuvaus- ja löydettävyysominaisuuksia. Tällä hetkellä on olemassa standardeja ja malleja synkronisen ESB:n ja viestiväylän toteuttamiseksi, mikä yksinkertaistaa asynkronista ESB:tä. ESB:n täyden potentiaalin hyödyntämiseksi tarvitaan lisästandardeja.

Integrointiväylä tiedot on suunniteltu rakentamaan komposiittisovelluksia, jotka käyttävät erilaisia ​​standardeja ja eri periaatteille rakennettuja vuorovaikutustekniikoita. Erityistä huomiota kiinnitetään sovellusten integrointiin 1C:Enterprise-alustalla.

Tuki erilaisille standardeille ja integraatioskenaarioille integrointitietoväylän avulla

Usein komposiittisovelluksia rakennettaessa joutuu kohtaamaan tilanteen, jossa erityyppisiä sovelluksia suunnitellaan erilaisille standardeille ja integraatiomalleille. Ei myöskään ole harvinaista, että olemassa olevien sovellusten integrointimekanismien muuttaminen on mahdotonta tai työlästä useista syistä: kehittäjän puute, lähdekoodi jne. Integrointiväylän avulla voit yhdistää tällaiset sovellukset yhdeksi kokonaisuudeksi, piilottaa erot integraatiossa tyypillisten liittimien mekanismien ja asetusten tasolla, joka tuo sovellusten vuorovaikutuksen yhteen hallittuun integrointijärjestelmään.

DATAREON ESB:ssä on seuraavan tyyppiset liittimet:

  • SOAP-palveluliitin, mukaan lukien 1C:Enterprise 8 -verkkopalvelut
  • REST-palveluliitin, mukaan lukien 1C:Enterprise 8 -verkkopalvelut
  • MS SQL -liitin
  • IBM DB2 -liitin
  • Oracle liitin
  • PostgreSQL-liitin
  • SharePoint-liitin
  • OData 1C -liitin
  • TCP-liitin
  • Siemens Team Center -liitin
  • SAP-liitin ja muut.

Kaikilla liittimillä on mahdollisuus parametrisesti määrittää yhteys lähdejärjestelmään ja olla vuorovaikutuksessa sen kanssa.

Saatavilla olevien liittimien luettelo laajenee jatkuvasti, koko luettelo kannattaa tarkistaa DATAREONista.

DATAREON ESB sisältää mekanismin, jonka avulla voit itsenäisesti kehittää erilaisia ​​liittimiä Java-kielellä tai .Net-alustan kielillä. Tällä tavalla voidaan toteuttaa mikä tahansa mukautettu skenaario yhteyden muodostamiseksi lähdejärjestelmiin.

Ladataan...
Yläosa