Service bus adatcsere a különböző rendszerek között. Mi az ESB, Enterprise Service Bus. Szinkron vagy aszinkron

ESB (Enterprise Service Bus)- szó szerint „vállalati szolgáltatási buszként” fordítható. Az ESB egy nagyon valós szoftverterméket ír le, amelynek célja a szolgáltatás lehívásának egyszerűsítése azáltal, hogy kezeli az összes interakciót a szolgáltatás fogyasztójától a szolgáltatóig és vissza. A két leggyakrabban hivatkozott ESB-képesség az üzenetfordítás és az üzenet-útválasztás. A SOA architektúrában az ESB-nek az a kritikus feladata, hogy biztosítsa az interoperabilitást a hálózaton lazán csatolt szolgáltatások rendszerei között. A Gartner elemzői az ESB-t egy új típusú, integráló köztes szoftverként határozzák meg funkcionalitás más, már létező köztes szoftvertípusok. Az Enterprise Service Bus támogatja a webszolgáltatásokat a SOAP (Simple Object Access Protocol) megvalósításával és a WSDL (Web Services Description Language) és UDDI (Universal Description, Discovery and Integration) specifikációkkal. Univerzális leírás, felderítés és integráció.

Az ESB alapvető funkciói

• Interakciós felületek biztosítása
• Üzenetküldés és továbbítás
• Adatkonverzió
• Esemény érzékelők
• Politikamenedzsment

ESB architektúra

Az ESB architektúra lényege a közös integrációs infrastruktúra megosztása az összes üzenetküldő alapú vállalati alkalmazás között. Minden alkalmazás egy ponton keresztül működik együtt, ami szükség esetén biztosítja a hívások, adatkonverzió és tranzakciók biztonságát. Ebben az esetben az alkalmazásintegráció célja egyetlen modul (vagy adapter) létrehozása, amely az alkalmazás ESB-hez való „csatlakoztatásáért” felel. Az üzenetek utólagos feldolgozását és más rendszerekbe történő továbbítását az ESB önállóan végzi a megállapított üzleti szabályok alapján. Ez a megközelítés kiváló rugalmasságot, egyszerű skálázást és migrációt biztosít, így ha a buszhoz csatlakoztatott alkalmazások egyikét lecserélik, nem kell újrakonfigurálni a többit.

Előnyök és hátrányok

Az ESB előnyei a következők:

• Szállás szervezése meglévő rendszerek gyorsabban és olcsóbban elkészül.
• Fokozott rugalmasság.
• Az ESB általánosan elfogadott szabványokon alapul.
• Nagy mennyiségű konfiguráció elérhetősége az integrációhoz.

Az ESB hátrányai a következők:

• A megvalósítás bonyolultsága
• Nagy erőforrásokat igényel.

Enterprise Service Bus fejlesztése

A webszolgáltatások megkülönböztető jellemzője, hogy a fogyasztó képes dinamikusan kommunikálni a szolgáltatóval. Mindez két fő funkciónak köszönhető:

• Észlelhetőség. A webszolgáltatók automatikusan karbantartott címtárakba gyűjthetők. Így a fogyasztó lehetőséget kap egy ilyen címtár böngészésére, hogy megtalálja a kívánt szolgáltatás szolgáltatóját.
• Önleírás. Egy webszolgáltatás géppel olvasható módon képes leírni önmagát. Így két vagy több szolgáltató felismerhető ugyanannak a szolgáltatásnak, még akkor is, ha azok teljesen eltérő módon vannak megvalósítva, mert a leíró felületeik azonos leírásnak felelnek meg.

A webszolgáltatások e funkcionalitása alapvetően különbözik a meglévő integrációs megközelítésektől, amelyekben az interfészeket a fordításkor és a fogyasztó szolgáltatókkal való kommunikációja idején határozták meg. Az üzenetformátumok nem voltak leíró jellegűek, ennek követésére nem kényszeríthetőek, így belső megállapodáson alapultak, aminek következtében a címzett nem tudta feldolgozni a feladó által létrehozott struktúrát.

A webszolgáltatások önleírása megkönnyítette az integrációt a követendő felületek deklarálásával. A dinamikus szolgáltatásfelderítésnek köszönhetően a fogyasztó megszabadult egy adott szolgáltatótól való függéstől konkrét címet Ez a lehetőség azonban meghozta a maga problémáit. Meglehetősen nehéz volt megoldani azt a problémát, hogy a fogyasztót a fordítási időben egyszer s mindenkorra össze kell kötni a szolgáltatóval, és futás közben minden hívással új szolgáltatót kell keresni. Az ESB ezután egy másik lehetőséget javasolt – lehetővé tenni a fogyasztó számára, hogy egyszer dinamikusan lépjen kapcsolatba egy proxyszolgáltatással, miközben több szolgáltatót és jövőbeli szolgáltatót is használhat a proxyszolgáltatáson keresztül. Mindez azt jelenti, hogy az ESB szolgáltatásokat tesz elérhetővé a fogyasztók számára, és lehetővé teszi a fogyasztók számára, hogy programozottan találjanak szolgáltatásokat.

Service Gateway

Az úgynevezett szolgáltatási átjáró a szinkron ESB sarokköve. Közvetítőként működik a szolgáltatók és a fogyasztók között, miközben bróker segítségével segíti a szinkronhívások lebonyolítását. Ez az átjáró hozzáférést biztosít az összes ismert szolgáltatáshoz és mindegyik proxy szolgáltatásához, így egyfajta „egyablakos” a fogyasztó számára, aki bármely, az átjáró által ismert szolgáltatótól szeretne bármely szolgáltatást hívni. Amikor a webszolgáltatásokat egy átjáró koordinálja, képesek önmeghatározásra. Minden szolgáltatás WSDL használatával teszi közzé a felületét, amely a következő négy részből áll:

• A porttípusok a webszolgáltatás által végrehajtott műveletek halmaza.
• Üzenetek – vagyis a kérések és válaszok formátuma
• Típusok – a webszolgáltatás által használt adattípusok
• Kommunikáció – a művelet hívásának címe

Az átjáró webszolgáltatások, pontosabban azok proxyszolgáltatásai szintén felfedezhetők. Az átjáró ezt a lehetőséget UDDI szolgáltatás formájában biztosítja. A szolgáltatáshívás címének megtalálásához a fogyasztó lekérdezi az átjáró UDDI-szolgáltatásától a kívánt WSDL-művelethez tartozó szolgáltatók listáját, és visszakapja az átjáró proxyszolgáltatási címét ehhez a művelethez.

Üzenetbusz

Az Message Bus minta az aszinkron ESB alapja. Az üzenetbusz olyan üzenetcsatornák gyűjteménye, amelyek kérés-válasz csatornapárként vannak konfigurálva. Mindegyik pár olyan szolgáltatást jelent, amelyet a buszon használó fogyasztó hívhat. A fogyasztó üzenetet küld a szolgáltatás kéréssorába, majd meghallgatja a válaszsort, hogy megkapja az eredményt. A fogyasztó valójában nem tudja, hogy ki nyújtja a szolgáltatást. A szolgáltatók is csatlakoznak az üzenetbuszhoz, és meghallgatják a kérésüzeneteket. Ha több szolgáltató létezik, verseny alakul ki közöttük, illetve a fogyasztók között egy adott kérés fogadásáért. Az üzenetbusz által végrehajtott üzenetrendszer üzenetkezelőként működik, és elosztja a kéréseket a szolgáltatóknak, optimalizálva ezt az elosztást a terheléstől, a hálózati késésektől stb. függően. Miután a szolgáltató megkapta a kérést, végrehajtja a szolgáltatást, és sorba állítja az eredményt egy üzenetsor válaszokat, vagyis a szolgáltató és a fogyasztó soha nem tudja egymás tartózkodási helyét. Ez az üzenetbusz az ESB lényege.

Ha ezen a ponton elvégzi az IT-infrastruktúra auditját, egy tipikus diagnózis a következőképpen fog kinézni:

1) A meglévő informatikai infrastruktúra túl sok (néha rejtett és rosszul dokumentált) összekapcsolást tartalmaz a rendszerek között, ezért sok jóváhagyást és módosítást igényel bármilyen, akár minimális változtatáskor.

2) Nincs egyetlen vezérlőegység, amely a különféle információs rendszerek frissítéséért és adatszolgáltatásáért felelős.

3) Nincs ellenőrzés a cserefolyamatok felett: nincs egységes környezet az adatcseréhez információs rendszerek.

4) Van egy „Technológiai Állatkert”: sokféle információs rendszer és adatcsere-protokoll használatos, sok csatlakozó (gyakran megrendelésre vagy önállóan fejlesztve) stb.

Egy sor ilyen probléma megoldása a Service Oriented Architecture (SOA) koncepcióján alapuló IT infrastruktúra kiépítésére való átállásban rejlik, amelynek kulcseleme az Integration Service Bus. A gumi az szoftver, amely lehetővé teszi számos platform és alkalmazás kombinálását, valamint a köztük lévő interakció megszervezését szolgáltatások alapján. Ugyanakkor nem mindegy, hogy milyen technológiákra épülnek a rendszerek és szolgáltatásaik, ez lehet JAVA, .NET vagy más platform.

Az integrációs busz általában a következő funkciókat látja el:

Üzenetátalakítás, valamint üzenettovábbítás, algoritmikus továbbítás, sorba állítás és követés;

Üzenetek kezelése módokban: szinkron, aszinkron, pont-pont, közzététel-előfizetés;

XML és SOAP üzenetek támogatása;

Több rendszer összekapcsolása kész adaptereken és API-kon keresztül új adapterek írásához;

A szolgáltatások hangszerelése (automatikus elhelyezés, koordináció és menedzsment).

Elméletileg az Integration Service Bus architektúrája így néz ki:

1. ábra Integrációs buszt használó architektúra

Az integrációs busz bevezetésekor az új – megvásárolt és önállóan fejlesztett – rendszerek integrálása rendkívül leegyszerűsödik. A szolgáltatások már nem monolitikus alkalmazások, hanem egyedi szolgáltatásokra vannak lebontva. Például: a „hitelkérelem megfontolása” összetett szolgáltatás a következő „egységszolgáltatásokra” osztható fel:

• Adja meg az ügyfél adatait
• Ellenőrizze, hogy létezik-e rekord egy adott ügyfélhez
• Szerezze meg az ügyfélfiókok listáját
• Szerezze meg az ügyfél által használt szolgáltatások listáját
• Szerezzen összesített adatokat a hitelfizetési előzményekről
• Adatok lekérése a jelentéshez
• Számlaegyenleg lekérése
• Számítsa ki a hitelminősítést
• Jelentés létrehozása a menedzser általi felülvizsgálatra
• Frissítse a fiók adatait
• Értesítés létrehozása az ügyfél számára

Ne feledje, hogy egyes „egységszolgáltatások” más összetevő műveletekben is használhatók, ami integritást ad a rendszerhez, megkönnyíti a karbantartást és csökkenti a kockázatot.

Például egy bank ügyfélkapuja egy oldalon egyesíti a folyószámla-jelentéseket, a jelzáloghitel-fizetési jelentéseket és a hitelkártya-kivonatokat. Ugyanakkor a számlaadatok, a jelzáloghitel-fizetési adatok és a hitelkártya adatok is átvehetők különböző rendszerekből. A CRM adatok alapján egy adott ügyfél számára potenciálisan érdekes ajánlat jeleníthető meg ugyanazon az oldalon.

Az integrációs busz bevezetésének eredményeként a meglévő és megvalósult üzleti folyamatok keretein belül megvalósul az adatcsere átláthatósága, lehetőség nyílik a dolgozók és részlegek hatékonyságának és termelékenységének növelésére, valamint az ügyfél minőségének javítására. elégedettség, valamint a Bank informatikai infrastruktúrájának kialakításának és fenntartásának költségeinek csökkentése.

Az alábbi ábra bemutatja, hogyan változik a bank informatikai rendszereinek interakciója az integrációs busz bevezetése után.

Rajz2 A bank informatikai architektúrája a busz bevezetése előtt és után

Jelenleg az integrációs buszok piacán meglehetősen széles a választék. A kereskedelmi rendszerek és a nyílt forráskódú termékek egyaránt bemutatásra kerülnek. forráskód. Az integrációs buszok oroszországi bevezetésében vezető gyártói közül kiemelhetjük az IBM-et és az Oracle-t; A TIBCO a vezető külföldi szállítók közé sorolható.

Nézzük meg az integrációs buszok bevezetését több nagy nemzetközi bankban.

A Chinatrust Commercial Bank integrációs buszt használ termékei és szolgáltatásai támogatására. Az integrációs buszon alapuló szolgáltatás-orientált architektúra több mint hetven rendszert integrál több platformon, mint például: automatizált banki rendszer, hálózati banki rendszer, jelzálog-rendszer, lottórendszer, munkafolyamat automatizálási rendszer, interaktív hangmenü stb. Valós időben olyan szolgáltatások váltak elérhetővé, mint az adatok összesítése, számlaösszesítés, bejövő és kimenő átutalások, átutalások, értesítések (az eseményalapú kommunikációs funkció engedélyezve van) és egyebek. Az új rendszerek integrálásának költségei átlagosan 30..40%-kal csökkentek.

Jelenleg a bank integrációs busza napi 100 000 tranzakciót támogat a vállalati szektorban és 50 000 tranzakciót a lakossági szektorban. Az online banki tranzakciók száma napi 150 000-ről 1 200 000-re nőtt.

A szingapúri-malajziai OCBC bank a közelmúltban öt évre tűzte ki célul, hogy 25%-kal növelje a működési hatékonyságot, és 30%-kal csökkentse az új szoftverfelületek fejlesztési költségeit. Az első SOA-alapú szolgáltatás 2006-ban indult. Hat hónap után 116 egységszolgáltatás futott, amelyek mindegyike használható volt összetett szolgáltatásokban. 50 egyedi szolgáltatás több komponens részét képezte. Az integrációs folyamatok támogatására a bank Integrációs Kompetencia Központot hozott létre. Az OCBC úgy véli, hogy a SOA kulcsszerepet játszik a kitűzött célok elérésében.

Japánban rendkívül erős a verseny az internetes banki szolgáltatások terén. Sumishin Net Bank, Ltd. célul tűzte ki, hogy a többi pénzintézetnél rövidebb időn belül széles termékskálát kínáljon a piacra. E cél elérése érdekében a banknak szigorúan meg kellett felelnie műszaki szabványok rákényszerítik a japán bankszektort, és ezzel egyidejűleg versenyelőnyöket fejlesztenek ki. Tíz felhasználásával szolgáltatás-orientált architektúrát fejlesztettek ki szoftver termékek, beleértve az integrációs buszt is. Mindössze 18 hónappal az új szolgáltatási vonal elindítása után körülbelül 600 milliárd jent (körülbelül 6 milliárd dollárt) fektettek be a bankba, és 400 000 számlát nyitottak. Hihetetlen rugalmasságot sikerült elérni az új szolgáltatások hozzáadásakor. Fejlesztésük költsége jelentősen csökkent.

Oroszországban az integrációs buszokat számos nagyvállalat használja, beleértve a távközlési szolgáltatókat, a bankszektort, valamint az e-kormányzati rendszerek komplexumában. Orosz Föderáció. Az integrációs buszok megvalósítása általában történik rendszerintegrátorok. Különösen az AMT-GROUP cégünk, amely a cnews.ru szerint bekerült a bankoknak IT-szolgáltatásokat nyújtó Top 20 orosz vállalat közé, sikeres tapasztalattal rendelkezik az integrációs buszokkal való munka és azok megvalósítása terén a különböző tevékenységi területeken, beleértve a bankszektort is. . Szakembereink széleskörű tapasztalattal rendelkeznek az integrációs buszokon alapuló szolgáltatás-orientált architektúrák létrehozásában, beleértve az üzleti folyamatok auditálását és azok későbbi automatizálását, az integrált rendszerek csatlakozóinak létrehozását és a munkakörnyezet optimalizálását.

A cikk nyílt forrásból származó anyagokat használ:
http://www.tibco.com/multimedia/ss-ctcb_tcm8-15110.pdf
http://www.eawriter.com/images/case_studies/TIBCO_2.pdf
http://www-01.ibm.com/software/success/cssdb.nsf/CS/JSTS-7V4BWP?OpenDocument&Site=corp&cty=en_us

Becslés:

4 15

Az integráció során vállalati rendszerek Felmerül a referenciaadatok kezelésének feladata. A probléma megoldására gyakran használják a törzsadatkezelést (MDM). Az MDM egy „referencia” referenciaadatokat, az úgynevezett „arany rekordokat” tartalmazó adattár. Az MDM könyvtárai tiszta, teljes és következetes adatokat tartalmaznak.

Az MDM-et gyakran használják a központosított címtárkezelés platformjaként. A referenciaadatok bevitele és érvényesítése az MDM-ben történik, majd onnan replikálódik az informatikai rendszerekbe. Ennek a megközelítésnek több problémája is van

• Teremt referencia modell Az összes rendszerhez illeszkedő adat nem olyan egyszerű.
• A referenciaadatok megszakadnak az alkalmazásoktól.
• Az MDM-ből származó adatok replikálása gyakran jelentős rendszermódosításokat igényel. A kész rendszerek esetében az ilyen módosítások nagyon drágák lehetnek.

Egy másik megközelítés az, hogy minden üzleti rendszer helyben tárolja a címtárakat és megszervezi az adatbevitelt. A rendszerek közötti üzenetváltáskor az integrációs busz az egyik rendszer formátumáról egy másik formátumára transzformációt hajt végre. Ezzel párhuzamosan a referenciaadatok átalakulása is megtörténik.

Átalakítás az integrációs buszon.

A második megközelítést alkalmazzuk. Az üzleti rendszerek közötti összes interakció az integrációs buszon keresztül történik. A busz (esetünkben az Oracle Service Bus) a Beszállítói rendszer által küldött üzenetet a Fogyasztói rendszer által megértett üzenetté alakítja át. Ez az átalakítás magában foglalja a könyvtárak értékeinek leképezését.

A rendszerek közötti könyvtárak leképezésére vonatkozó adatok egy relációs adatbázisban, esetünkben az Oracle-ben tárolódnak. A táblázatok rögzítik, hogyan lehet értéket szerezni egy másik rendszerben az egyik rendszer könyvtárértékéből. Vagyis valamiféle szerkezet:

(forrásrendszer, forrásérték, érvényes_induló, érvényes_ig, célrendszer, célérték)

A könyvtárak adatai nagyon ritkán változnak, de nagyon gyakran használják. Annak érdekében, hogy ne minden alkalommal hozzáférjünk az adatbázishoz, a könyvtárak a buszon vannak gyorsítótárazva, és olyan formátumban, amelyet a busz azonnal használhat.

A gyorsítótárazáshoz használjuk. Ez egy nagyon-nagyon fizetős termék. Ebben az esetben azonban az összes megafunkciója nincs kihasználva, így ingyenes megoldással (például hazelcast) helyettesíthető. A koherenciáról bővebben olvashat. Ezenkívül a különböző Oracle Suite-ok tartalmazzák a koherencia licencét.

A gyorsítótár használatának nyilvánvaló előnyei vannak:

• az adatok a memóriában tárolódnak
• az adatokat szerializált formában tároljuk
• az adatok indexelhetők
• az adatbázissal való szinkronizálás aszinkron módon is végrehajtható

A gyorsítótár elosztását és a csomópontok közötti szinkronizálást maga a koherencia végzi. Amikor egy kiszolgálót hozzáadnak vagy eltávolítanak, a fürt újra kiegyensúlyozza az adatokat a csomópontok között.

Az elosztott gyorsítótár-leképezés séma referenciaadatokhoz használatos. Amikor az Oracle Service Bus elindul, egy gyorsítótár jön létre a JVM-en belül, amely az adatokat a memóriában tárolja. Minden fizikai szervernek van egy koherencia-kiszolgálója, amely könyvtárakat tárol (a memóriában és a lemezen), és szinkronizálva van az adatbázissal.

Az átalakítás során az OSB munkafolyamat Java-kiíráson keresztül éri el a koherenciát. Enterprise Java Bean híváson keresztül is elérhető.

Ezzel a cikkel egy sorozatot szeretnék nyitni az IBM WebSphere ESB-nek (a továbbiakban: ESB) a termék fejlesztésének összefüggésében. És mindenekelőtt jobban meg kell ismerkednie az ilyen típusú technológiákkal.
A vállalati szolgáltatásbusz (enterprise service bus) egy köztes szoftver, amely a szolgáltatás-orientált architektúra elvei alapján központosított és egységes eseményvezérelt üzenetküldést biztosít a különböző információs rendszerek között.
Természetesen erre a megközelítésre építve fel lehet építeni egy vállalati rendszert speciális szoftverek nélkül (esetleg még valami általánost kell fejleszteni), és az így létrejött terméket szervizbusznak nevezni. Az IBM terméke azonban nem csak kész berendezéssel rendelkezik a központosított üzenetküldéshez és ennek a folyamatnak a vezérléséhez, hanem a rugalmas szolgáltatás-orientált alkalmazások fejlesztéséhez, kifejezetten az ESB-hez is. Ennek eredményeként az IBM WebSphere ESB következő képességeit és előnyeit emelhetjük ki:

• Az építészeti kapcsolatok rendje, egységessége
• Központosított irányítás
• Szerveroldali alkalmazáskonfiguráció
• A Service Component Architecture (SCA) technológia megvalósítása a szolgáltatásorientált architektúra elveinek szellemében
• A kifejlesztett programkód protokollfüggetlensége
• Széles busz- és alkalmazáskonfigurációs lehetőségek

Ugyanakkor az ESB biztosítja a tranzakciók ellenőrzését, az adatkonverziót, a biztonságot és az üzenetek garantált kézbesítését. Az összes szolgáltatási szolgáltatás egyetlen ponton keresztüli elérése lehetővé teszi a szolgáltatási kommunikáció központi konfigurálását. A hibaeseményeket központilag is kezelheti a tömeges hibakezeléshez.
A klasszikus ESB összeállítás topológia egy olyan fürt, amely vízszintes skálázhatóságot és hibatűrést biztosít. A hivatalos ajánlások szerint a fürttagok számának növelése hatékonyabban növeli a teljesítményt, mint a szerver teljesítményének növelése egy önálló topológiában. Ezenkívül a fürt újraindítható (vagy egy része meghibásodhat) a szolgáltatás leállítása nélkül.
Az ESB-t általában szolgáltatási rétegként használják az IBM BPM-ben, de vezető szerepet játszhat a vállalati rendszerek közötti interakciós modell felépítésében, mint hatékony integrációs eszköz (az ESB-t az IBM WebSphere Application Server kiegészítőjeként). .
Ez valójában az ESB-től megköveteli, mivel ez egy „szolgáltatás-gyűjtőhely” - ha olyan szolgáltatásra van szüksége, amely más szolgáltatásokkal is működik (esetleg külsővel), akkor a leglogikusabb hely a szolgáltatások közötti integrációhoz az ESB. Külső vagy heterogén szolgáltatások esetén ESB szolgáltatással csomagolhatja. Röviden szemléltessük az „egyedülálló lakás” használatának kényelmét a szolgáltatásokhoz:

Rendelés
Minél nagyobb a rendszer, annál fontosabb a rend és az egységesség. Ha egy nagyvállalat rendszereinek komplexumáról beszélünk, akkor azt mindenképpen rendszernek nevezhetjük nagy méretű. Természetesen mindig találhat olyan rendszergazdát, akinek a fejében van egy diagram több száz szerver interakciójáról, vagy egy csomó, nem kapcsolódó dokumentáció minden szoftvermodulhoz, amely leírja, hogy mi és hogyan működik együtt.


De sokkal könnyebb egy olyan szolgáltatással (ESB) rendelkezni, amely lehetővé teszi, hogy minden interakció önmagán keresztül történjen. Ezzel a megközelítéssel az interakciós architektúra egy része minden alrendszerben már egyértelmű – a rendszerek, szerverek és alkalmazások közötti kapcsolatokban nincs rendetlenség: minden az ESB-hez kapcsolódik, az ESB pedig mindenhez.

Központosított irányítás
Mindig kényelmesebb a központilag konfigurálni a rendszereket – legyen szó konfigurációról, a szerverek mozgatásához való alkalmazkodásról, hibatűrésről, terheléselosztásról, hibakezelésről vagy monitorozásról és elemzésről.


Például egy adatbázis-kiszolgáló áthelyezésekor nem kell belemenni az összes meglévő alkalmazáskiszolgáló és beállítás konfigurációjába konkrét alkalmazások konkrétan elég egy környezeti változó az ESB-ben, amely megadja az adatbázis címét, és ekkor már csak egy ponton kell változtatásokat végrehajtani.
Illetve, ha valamelyik külső rendszer hosszú ideig nem volt elérhető, és egyetlen kérés sem veszne el, akkor a meghiúsult események feldolgozására szolgáló szolgáltatást használhatja a kézbesítetlen üzenetek „bedobására”, amikor ez kényelmes.
Ha szabályoznia kell az egyidejű kérések számát bármely rendszerhez, vagy figyelnie kell ezeket a kéréseket, elemeznie kell a terhelést, meg kell keresnie a szűk keresztmetszeteket, akkor lépjen az üzenetkezelési központba - az ESB szerver konzoljára.

Szerver oldali konfiguráció
A szolgáltatások „egyetlen otthona” konfigurációs szempontból több hasznos célt is megvalósít. Először is ezt újrafelhasználás konfiguráció (hasonlóan a SOA-ban nagyon hasznos kód és modul újrafelhasználásához), mivel a különböző modulok és alkalmazások ugyanazokat az adatbázis-kapcsolati paramétereket, erőforrásokat, hitelesítési paramétereket, környezeti változókat stb.


Másodszor, a szerveroldali konfigurálás során az alkalmazás működési környezete az, amely nagyban befolyásolhatja azt, amely lehetővé teszi az alkalmazások átvitelét a különböző áramkörök között (teszt és gyártás), hangolást és akár hibák javítását az alkalmazás módosítása nélkül.

Mindezen előnyök kihasználásával az alkalmazások kaméleonszerűvé válnak – annyira rugalmasak, hogy részévé válnak annak a környezetnek, amelyben működnek, miközben továbbra is fontos funkciókat biztosítanak.

Az IBM WebSphere ESB-n futó alkalmazások rugalmassága azonban nem korlátozódik arra a környezetre, amelyben futnak. A fejlesztési képességek ehhez nagyban hozzájárulnak. Mivel a rendszereknek nemcsak elérhetőnek kell lenniük, hol futniuk kell, hanem fejleszteni és finomítani is kell, ezeket az érdekességeket nem lehet kihagyni:

SCA
Ez az architektúra azon az elven alapul, hogy egy komponens szolgáltatásként biztosítja a funkcionalitását, amely elérhető más összetevők számára. Egy modulon belül a komponensek programblokkok(java kód), amelyek teljes mértékben megvalósítanak néhány, a megfelelő interfész által leírt funkciót. A komponensek végrehajtási logikája úgy valósul meg, hogy interfészeken és hivatkozásokon alapuló struktúrába kapcsoljuk őket (Partner Reference).

Ez a modulstruktúra nagyon kényelmesen fejleszthető, tesztelhető, fejleszthető, módosítható és karbantartható. A komponensekben megvalósított funkcionalitás atomitása lehetővé teszi a komponensek egészének működtetését anélkül, hogy a kódszintre süllyedne. Másrészt logikailag szükséges a komponensek tranzakciós kontextusban történő megvalósítása miatt.
Minden összetevőnek van interfésze(i), amelyek megvalósítását biztosítja. Így a komponensek összekapcsolásakor nem kell ismerni a belső tulajdonságaikat - elég, ha megvalósítják a szükséges interfészt.
Ezzel az architektúrával is megoldható minden párhuzamos munkát igénylő feladat, „kézi” szálkezelés nélkül (például késleltetett válasz mellett több komponens aszinkron hívása is lehetséges).
A nem java összetevők, például az Exportálás és az Importálás típusok lehetővé teszik a szolgáltatások nyújtását külső használat vagy használja külső szolgáltatások illetőleg; A Közvetítési folyamat összetevő alacsony szintű hozzáférést biztosít a többi összetevő között váltott üzenetekhez, és lehetővé teszi különféle átalakulások amikor heterogén interfészekkel dolgozik.
Az interfészek mellett az IBM üzleti objektum keretrendszere nagyon hasznos lehetőségeket biztosít. Az xsd diagramokkal ábrázolt üzleti objektumok (BO) objektumokként használhatók adatátvitelre az interfészeken, mind az összetevők között, mind a modulok közötti kommunikációhoz. Közvetlenül integrálva vannak például egy wsdl sémába a webszolgáltatások leírására. Vagyis ha például az „A” modul webszolgáltatás formájában biztosítja a funkcionalitását, akkor a használatához a „B” modulnak csak interfészt és kész BO-kat kell csatlakoztatnia, és már teljes mértékben működni fog. egy ilyen szolgáltatással anélkül, hogy további java objektumokat hozna létre az adatátvitelhez. A BO ​​akkor is kényelmesen használható, ha adatbázissal cserélünk adatot, ha ezeket az adatokat más komponensek is felhasználják (ez természetesen ellenkezik a „DAO” mintával, de kiküszöböli a felesleges java objektumokat és az adatok „oda-vissza” átírási műveleteit). ).

A programkód protokollfüggetlensége
Mint látható, a kód protokollfüggetlensége az Export és Import összetevők használatával érhető el. Mivel a kommunikáció ezekkel a komponensekkel interfészeken és hivatkozásokon keresztül történik, a programkód teljesen független az interakcióhoz használt protokolltól. Ugyanaz a funkcionalitás könnyen elérhetővé tehető tetszőleges számú támogatott protokollon és bármely szükséges interfészen keresztül. A következő ábra egy SCA-kötésű export hozzáadását mutatja be egy olyan összetevőhöz, amely már HTTP, JMS és webszolgáltatásként teszi elérhetővé az interfészét.


Az előnyök nyilvánvalóak - rugalmasság, sokoldalúság, kód újrafelhasználása, fejlesztési és módosítási sebesség.
Az SCA-kötés egyébként egy speciális protokollt használ, és ugyanazon a szerveren/fürtön belüli modulok közötti kommunikációra szolgál. Az ezen az összerendelésen keresztüli kommunikáció kevésbé erőforrás-igényes és gyorsabb, mint más protokollok.

Konfiguráció
A szerver és az alkalmazások konfigurálása a szerver IBM konzolján keresztül történik.
Az ESB, mint általában az IBM WebSphere, meglehetősen sok speciális képességgel és műtermékkel rendelkezik. Például, ha ugyanazt az importálást és exportálást használja, „menet közben” konfigurálhatja a megfelelő szolgáltatások végpontjait. A szolgáltatáshívásokhoz különféle szabályokkal konfigurálhat házirend-készleteket (például telepítheti a WS-AT mechanizmus támogatását, amely lehetővé teszi egy webszolgáltatás meghívását ugyanabban a tranzakcióban, amelyben az ügyfél fut; de a tranzakciós kapcsolat témát a teljes cikkhez), állítsa be a hitelesítési paramétereket, kapcsolja össze a tanúsítványokat stb.
A konfiguráción keresztül beállíthat bizonyos mechanizmusokat a kivételes helyzetekre való automatikus reagáláshoz (például hiba esetén az összetevők végrehajtásának automatikus megismétlése). Menet közben konfigurálhatja az összetevők nyomkövetését vagy módosíthatja a naplózási szinteket. Hibaesemény-kezelő szolgáltatás is elérhető, amely szándékosan használható tömeges hibakezelésre.
És természetesen sok minden mást is beállíthat a Java2EE specifikáció szerint, amelyet néha meglehetősen szigorúan az IBM Application Server implementál.

A fentiek mindegyike az ESB-t kényelmes, hatékony és rugalmas integrációs eszköznek minősíti, bár nem mindig könnyű megtanulni. A jövőben csak meg kell tanulnod használni.

A cikkben a következő képeket használjuk:

Véleményem szerint kétféle megközelítés létezik a vállalati integrációs busz felépítésére:

• „integrált rendszerekből”;


• "a megvalósítás alatt álló folyamatokból."

Nézzük ezeket a megközelítéseket részletesebben.

Az „integrálható rendszerek” megközelítés

Ebben az esetben az integrációs buszt egyfajta szállításnak tekintjük, amely az üzenetváltási protokollok útválasztását és egyeztetését végzi. Minden üzenet végighalad a láncon: a forrásrendszeradapter bemeneti csatornája -> útválasztó -> a fogadó rendszer kimeneti csatornája. Az ezen összetevők és a konkrét technológiák közötti kommunikáció típusa attól függ, hogy az egy forrásrendszerből érkező üzeneteknek lehet-e több célrendszere, a várható terheléstől és az adatok integritását biztosító megközelítéstől (közös tranzakció használata minden forrásrendszerre, vagy minden egyes forrásrendszerbe a saját tranzakciójában kerül át.

1. Rendszerfüggőség, nem üzenettípusok. Az integrált rendszerek száma jellemzően többszöröse a továbbított üzenettípusok számának.


2. Új vevőrendszerek egyszerű csatlakoztatása: új vevőrendszer csatlakoztatásához egyszerűen vigye be az adatokat az útválasztási táblázatba.


3. Integrációs megoldás felügyeleti rendszerének egyszerű kivitelezése: a felügyeleti rendszer adatai egy helyen - a routerben - generálhatók (ez a pont azonban csak fenntartással fogadható el, mivel vannak olyan adatok, amelyek csak adapterekben keletkeznek integrált rendszerek).


4. A megoldás egyszerű támogatása. Mivel minden üzenet egyetlen útválasztón halad át, az üzenetek továbbítására és az üzenetek közötti függőségek nyomon követésére szolgáló összes logika egy helyen – ebben az útválasztóban – megvalósítható.


5. A rendszer megoszthatósága a fejlesztők között. Mivel a rendszermag és az összes adapter egymástól független (a kommunikáció csak dedikált és leírt interfészeken keresztül történik), fejlesztésük feladatai megoszthatók a programozók között, ami lehetővé teszi az integrációs megoldás létrehozásának és megvalósításának folyamatának párhuzamosítását.

1. A megoldás csak az egységes üzenetátadási logika megvalósítására alkalmazható, pl. ha az összes vagy a legtöbb üzenetre közösek a függőségi nyomon követési és átalakítási szabályok. Ha különböző típusok az üzenetek teljesen más logikával rendelkeznek a függőségek követésére és a cserék kezelésére, vagy át kell vinni az adapterekre, ami semlegesíti a 4-es előnyt, vagy egyáltalán nem lehet megvalósítani.


2. Ez a séma alkalmas aszinkron csere megvalósítására. Szinkron vagy vegyes csere esetén e megközelítés megvalósításának bonyolultsága jelentősen megnő.


3. A megoldás teljesítménye csökkenhet. Például, ha egy üzenetet minden célrendszerhez külön tranzakcióban kell továbbítani, akkor a forrásrendszert, a kernelt és a célrendszereket sorokkal kell elválasztani. Ezek a sorok a rendszer szűk keresztmetszetévé válhatnak.

Folyamat alapú megközelítés

Ebben az esetben minden olyan üzleti folyamatot, amely több rendszer közötti adatcserét igényel, külön vizsgálunk. Busz eszközök ezt a cserét. A cserefolyamatot elindító esemény egy üzenet fogadása a forrásrendszertől. A forrásrendszertől kapott üzenetet egy vagy több fogadó rendszernek továbbítják, és nem csak a szállítási funkciókat valósítják meg, hanem az üzenetfeldolgozás eredményét is figyelik, és a továbbított üzenetet másokkal korrelálják.

Ennek a megközelítésnek a következő előnyei vannak:

1. Rugalmasság. Ez a megközelítés lehetővé teszi, hogy saját külön cserelogikát valósítson meg minden egyes üzenettípushoz. Ez a logika meglehetősen nem triviális lehet.


2. Az aszinkron és a szinkron csere megvalósításának összetettsége megközelítőleg azonos.


3. A szálak függetlensége, vagy inkább ebben az esetben helyesebb folyamatokról beszélni. Az egyik cserefolyamat végrehajtása során meghozott technikai döntések nem befolyásolják a másik végrehajtásának összetettségét.

Ennek a megközelítésnek a következő hátrányai vannak:

1. Az üzenettípusoktól való függés. Az üzenettípusok száma jellemzően sokszorosa az integrált rendszerek számának. Amikor új forrásrendszert csatlakoztatunk a buszhoz, az üzeneteket típusonként kell irányítani, és minden üzenettípushoz saját cserefolyamatot kell megvalósítani.


2. Ha ugyanazt a cserelogikát több típusú üzenethez kell megvalósítani, akkor lehetséges a kód- és/vagy buszbeállítások megkettőzése.


3. Az üzenettovábbítási folyamatok a rendszeradapterektől függenek, és függhetnek egymástól, valamint a szolgáltatási folyamatoktól. Az ilyen függőségek jelenléte csökkenti az integrációs megoldás fejlesztési és megvalósítási folyamatának párhuzamosítási fokát. Egyes komponensek fejlesztői az integrációs megoldás más összetevőit fejlesztők munkájának eredményeitől függenek.

A megközelítés kiválasztása a következő algoritmus szerint történik:

1. Az elemzőktől listát és leírást kaphat az integrált rendszerekről és üzenettípusokról.


2. Az elemzőktől listát és leírást kaphat azokról az üzleti folyamatokról, amelyek integrálást igénylő rendszereket foglalnak magukban.


3. Ha a folyamatok triviálisak, és sokkal kevesebb rendszer van, mint üzenettípus, akkor a csere túlnyomórészt aszinkron, és egy üzenet több rendszerbe történő átvitele is szükséges - az első megközelítést választjuk. Mi döntünk a tranzakciókezelési szabályzatról.


4. Ha a folyamatok túlnyomórészt szinkron cserét tartalmaznak, és a folyamatok összetettek, pl. az üzenet továbbítása a fogadó rendszerekben való feldolgozás eredményétől függ, akkor a második megközelítést választjuk. E megközelítés mellett szólhat az is, hogy az üzenettípusok száma összemérhető az integrált rendszerek számával.

Világosan meg kell értenünk, hogy ezek a megvalósítási módok nem dogmák, nem szükséges csak az első vagy csak a második megközelítést választani. Mindig kombinálhatók, modern vállalati szolgáltató buszok ( E.S.B.) lehetővé teszi ezt.

tetszett az üzenet...