Információs rendszerek integrációja a vállalati szolgáltatási busz (ESB) segítségével

A komplex információs rendszerek integrálásának legjobb gyakorlatai közé tartozik a logikai adatpiacok felépítése, valamint a központosított adatcsere-infrastruktúrák létrehozása MDM-rendszerek és vállalati szolgáltatási buszok (ESB, Enterprise Service Bus) segítségével. Megoldásaink, köztük az ArchiGraph.MDM rendszer, alkalmasak az operációs rendszer részeként történő használatra speciális célú Astra Linux Special Edition, valamint Alt Linux.

Miért van szükség integrációs buszra?

Minden olyan vállalat, amely kettőnél több olyan szoftverterméket használ, amelyek átfedő információhalmazokkal működnek, tudja, mi az ára, ha nem kommunikál egymással. Az ERP, CRM és más vállalati alkalmazások közötti nem szinkronizált ügyféllisták vagy termékskálák és egyéb információk folyamatos idő-, erőforrás- és hírveszteséggel járnak a vállalatnál. Az egyetlen helyes megoldás erre a problémára egy vállalati szolgáltatási busz (ESB) megvalósítása a törzsadat-kezelő (MDM) rendszerrel együtt.

A rendszeres információfeltöltésen és -átalakításon (ETL), szolgáltatásorientált architektúrán (SOA) alapuló megoldások csak átmeneti megoldást nyújtanak az ilyen problémákra, számos hátránnyal járnak, és korlátozzák az informatikai infrastruktúra növekedését.

Az integrációs busz megvalósítása

Az integrációs busz bevezetésekor felmerül a különböző információs rendszerekben jelenlévő, azonos objektumokra vonatkozó információk szerkezetének feltérképezése (összehasonlítása). Ezt a problémát úgy kell megoldani, hogy minden alkalmazáshoz hozzunk létre egy közös, semleges, információs modell. Egy ilyen modell a leghatékonyabban szemantikai technológiákkal valósítható meg. Az optimális megvalósítási eredmények érdekében a modell kidolgozásához professzionális adattervező szükséges.

A megvalósítási projekt fontos része a csatlakozók (programozási interfészek) megvalósítása minden adatcserében érintett alkalmazáshoz. Szakembereink tapasztalattal rendelkeznek a szoftverek széles skálájának csatlakozóinak fejlesztésében és csatlakoztatásában különböző platformokon.

Integrációs projekteket partnereinkkel együtt hajtunk végre IBM WebSphere MQ, Integration Service Bus, WSO2 Message Broker, Apache Synapse és Business Semantics buszmegoldások alapján.

Az integrációs busz megvalósítására irányuló projektet gyakran a vállalati információs architektúra általános újratervezésének részeként hajtják végre.

2005

Enterprise Service Bus – „költségvetési” megközelítés az integrációs problémák megoldására

Készítette: külföldi oldalak anyagai alapján
Fordítás: Intersoft Lab

Folytatva az olvasók megismertetését az integráció különféle megközelítéseivel, úgy döntöttünk, hogy egy viszonylag új és nagyon vonzó technológiára összpontosítunk - a vállalati szolgáltatási buszra (Enterprise Service Bus, rövidítés: ESB).

Mi az Enterprise Service Bus, és hogyan hasonlítható össze a DWH, OLAP és XML Connoisseurs Club Magazine korábbi számaiban tárgyalt vállalati alkalmazásintegrációval (EAI)? A kialakult hagyomány szerint először e terület szakértőinek adjuk át a szót.

A Gartner elemzői az ESB-t egy új típusú, integráló köztes szoftverként határozzák meg funkcionalitás mások már létező típusok köztes támogatás. Az Enterprise Service Bus a SOAP (Simple Object Access Protocol) protokoll megvalósításával és a Web Services Description Language (WSDL) és az Univerzális leírás, felderítés és integráció (UDDI) specifikáció használatával támogatja a webszolgáltatásokat. Univerzális leírás, észlelés és integráció). Számos vállalati szolgáltatási busz más kommunikációs stílusokat is támogat, beleértve a garantált kézbesítést, valamint a közzétételt és az előfizetést. Az ezen buszok által nyújtott szolgáltatások olyan "hozzáadott értéket" biztosítanak, amellyel a könnyű üzenetküldő köztes szoftverek nem rendelkeznek - üzenetvizsgálatot, átalakítást, tartalomalapú útválasztást, biztonságot, szolgáltatás-felderítést a szolgáltatásorientált architektúrához, terheléselosztást és regisztrációt biztosítanak. Egyes szolgáltatások a buszbázisba vannak beépítve, mások beépülő modulokban futnak. Ezenkívül a buszok támogatják az XML-t és más üzenetformátumokat.

Miért olyan vonzó a vállalati szolgáltató busz? Először is a viszonylagos olcsósága. Az ESB termékek általában megfizethető, vagy ahogy mondani szokták, „költségvetésű” megoldások.

Valójában manapság növekszik a kereslet az integrációs technológiák iránt. És míg korábban az EAI-termékek bevezetése a stratégiai célok elérésével járt, és ezért hosszú távon kifizetődő volt, addig a Ebben a pillanatban A vállalatoknak, amelyekkel szembe kell nézniük, taktikai jellegűek, és új megközelítéseket igényelnek. A „modern üzleti valóság” felhívta a figyelmet azokra a területekre, ahol az EAI-szállítók hagyományosan gyengék – az átalakítás, a fejlesztőközpontú programozás (például a Java) és a külső technológiákkal való integráció. Mindez az "előkészített termékeny talaj" egy új termékkategória - az ESB - megjelenéséhez.

A vállalati szolgáltató busz erényeiről szólva érdemes idézni Roy Schulte, a Gartner alelnökének és kutatási osztályának tagjának szavait: „A szokásos szoftver a középső réteg már nem tudja támogatni az új alkalmazásokat, amelyek szolgáltatás-orientált (Service Oriented Architecture, röv. SOA) és eseményvezérelt architektúrát (Event Driven Architecture, rövidítés EDA), webszolgáltatásokat és üzleti folyamatkezelést használnak. Ez a fő oka annak, hogy az információs rendszerek építészeinek és menedzsereinek vállalati információs infrastruktúrájukat ESB-kkel kell kiaknázni.”

A Gartner vezető elemzője az ESB-szállítók csoportjait emeli ki. Az ESB-termékek első csoportjára utal, amelyeket „költségvetésű” integrációs megoldásként pozicionálnak, és amelyek a legalkalmasabbak az összetett alkalmazások és a SOA támogatására. A második csoportba a webszolgáltatások piacára szánt termékek tartoznak, végül az utolsóba tartoznak szoftver, amely EDA támogatást nyújt. Roy Schulte szerint az ESB-piac sűrűsödni fog a következő években a webszolgáltatások, valamint a többprotokoll- és eseményvezérelt megoldások iránti növekvő kereslet miatt.

Érdekes módon számos vállalatnál az ESB-t nem termékkategóriaként, hanem architektúraként kezelik. Például az IBM-nél a vállalati szolgáltatási busz „architektúra mintának” számít.

Így kijelenthető, hogy még mindig nincs egyértelmű definíció arra vonatkozóan, hogy mi az ESB. Valójában a vita két kérdés körül forog:

  1. Az ESB architektúra (és olyan, amelyet nem is kell szabványosítani), "egyoldalú megközelítés" vagy önálló termék.

    Bár számos olyan szállító számára előnyös, akik jelenleg nem rendelkeznek kész megoldással, ha az Enterprise Service Bus-ról mint architektúráról beszélnek, a jelenlegi helyzet olyan, hogy az ügyfeleknek szüksége van termékeikre, hogy ESB-funkciókat kínáljanak. Ezért a következő két évben az ESB-képességeket kínáló gyártók számának növekedésére kell számítanunk.

  2. Mi a helye és jövője az ESB termékeknek, nevezetesen, hogy a vállalati szolgáltatásbusz egy fejlettebb üzenetsor-e, amely egyszerű XML-transzformációt, valamint útválasztást és üzenetküldést tesz lehetővé, vagy lehetővé teszi-e az alkalmazás adapterek, az automatizálás és az üzleti folyamatok modellezése Az ESB-t sikeresen lecserélik az EAI-ra.

Jelenleg ezekre a kérdésekre nincs végleges válasz.

Érdemes azonban hangsúlyozni, hogy bár az Enterprise Service Bus-szal kapcsolatban nincs egyértelműség, az egyértelmű, hogy az ESB nyílt szabványos megközelítése jelentősen csökkentheti a beszerzési és bevezetési költségeket.

Vegye figyelembe, hogy a "szolgáltatás" szó a "vállalati szolgáltatási busz" kifejezésben központi szerepet játszik. Így a Forrester Research elemzői az ESB-t "a köztes szoftver rétegének tekintik, amellyel hozzáférhet az alapvető (újrafelhasználható) üzleti szolgáltatásokhoz". A SOA lehetővé teszi a legtöbb funkció "szolgáltatásként" való megjelenítését egy vállalati szolgáltatási buszban, amely továbbítja, átalakítja és érvényesíti a bemeneti és kimeneti adatokat XML formátum kapott ezektől a szolgáltatásoktól.

ESB és XML

Igazságtalan lenne, ha nem hangsúlyoznánk az XML különleges szerepét – az XML az integráció alapja. Ha valaki elfogadja, hogy az XML inkább „ábécé”, mint egyszerű nyelv, akkor világossá válik, hogy a teljes integráció megköveteli az üzleti folyamatok összehangolását, az XML-átalakítások kezelését, valamint az XML-üzenetek érvényesítését és továbbítását a szervezeten belül. Mindezek a funkciók képezik az Enterprise Service Bus alapját.

Az XML egy adatkészlet átfogó ábrázolását tudja biztosítani. A nyelv népszerűsége nagy rugalmasságának és bővíthetőségének tudható be. Valójában az XML szintaxis lehetővé teszi a különféle adatok feldolgozásához szükséges speciális XML-sémák modernizálását és fejlesztését.

A továbbítandó adatmennyiség rohamos növekedése ugyanakkor komoly nehézségeket okoz a vállalati információs struktúra működésében. Tehát az XML képességeit használó első integrációs projektek "élő" bizonyítékai voltak ennek a nyelvnek az ígéretének, de mostanra bizonyos problémák vannak az XML dokumentumok számának, méretének és összetettségének növekedésével. A fennálló nehézségek fő okai a következők (nem megfelelő skálázhatóság):

  • Teljes dokumentum elemzése: Általában a teljes dokumentumokat kívánja elemezni, még akkor is, ha annak csak egy részét kell kinyerni az útválasztáshoz és szűréshez. Ha a dokumentumok nagyok lesznek, a várakozási idő megnő.
  • Újraszkennelés. A dokumentumokat gyakran újraelemzik – az üzleti folyamat minden szakaszában, vagyis ugyanazok a dokumentumok többször is beszkennelhetők. Mivel ez a gyakorlat rendkívül erőforrás-igényes, a teljesítmény és az áteresztőképesség csökken.
  • Egyszálú végrehajtás. Ebben az esetben a következő feldolgozási lépés nem indítható el, amíg az aktuális be nem fejeződik; ennek eredményeként a késleltetés növekszik, mert az egész folyamat a leglassabb lépéstől függ.

A méretezhetőség hiányának kiküszöbölése érdekében olyan feldolgozási architektúra használata javasolt, amely támogatja a következő szolgáltatásokat:

  • Document Streaming – Biztosítja, hogy az XML dokumentumok feldolgozása megtörténjen az egyes elemek beérkezésekor, pl. alacsony késleltetést biztosít. Ez a megközelítés lehetővé teszi a nagy üzenetek ugyanolyan hatékony feldolgozását, mint a kicsiket.
  • Szelektív feldolgozás, amely igen jelentős teljesítménynövekedést ér el azzal, hogy a teljes XML dokumentum helyett csak a releváns töredékeket dolgozza fel.
  • Többszálú feldolgozás, amelyben a processzor kezeli a csatornán a szekvenciális lépések igazítását, az egyes lépések párhuzamos végrehajtását és az azonos lépések terheléselosztását több XML fragmentum feldolgozásakor.
  • Az egyetlen szkennelés, amelyben ahelyett, hogy ugyanazon dokumentum szerkezetét a kezdetektől ismételten leolvasnák, az összes szükséges töredéket egyetlen átvitelben kinyerik.

A fenti funkciók az Enterprise Service Bus segítségével – speciális kódolás és konfiguráció nélkül – megvalósíthatók.

Mi a különbség a vállalati szolgáltatásbusz (ESB) és az üzenetközvetítők (például a RabbitMQ) között?

Ennek eredményeként a nem kielégítő teljesítmény problémája megoldható.

Következtetés

Külföldi internetes kiadványokban megjelent publikációk és vezető kutatócégek elemzőinek becslései alapján a vállalati szolgáltatási busz már nem csak új technológia nagy lehetőségekkel. A Gartner azt jósolja, hogy 2005-ben a legtöbb nagyvállalat az ESB-t fogja használni. Az IDC úgy véli, hogy a vállalati szolgáltatási busznak "forradalmasítania kell" Információs technológiaés rugalmas és méretezhető elosztott feldolgozást tesz lehetővé.

A nyílt szabványok (és különösen az XML) támogatása valóban olcsó, de hatékony megoldást jelent, és garantálja a befektetés gyors megtérülését, i.e. magas arány ROI. Ahogy Steve Craggs, az Integrációs Konzorcium alelnöke megjegyzi: "Az ESB az integráció alapja, rugalmas és testreszabható környezetet biztosít, amely lehetővé teszi az integrációs projektek gyümölcsöző, sikeres és szisztematikus megvalósítását."

Ennek ellenére továbbra is fennáll a bizonytalanság a "vállalati szolgáltatási busz" kifejezés kétértelműségével kapcsolatban. Ma az ESB a SOA megvalósításához szükséges technológiát jelenti. Pontosan ezt az álláspontot képviseli a ZapThink, a szolgáltatás-orientált architektúra fejlesztésére és alkalmazására szakosodott cég. Ezzel kapcsolatban a ZapThink elemzői arra figyelmeztetnek, hogy ha 2005-ben nem dolgozzák ki a vállalati szolgáltatási busz valódi és konkrét definícióját, az ESB kifejezés "örökre elhagyja a SOA lexikont". Ami magát a SOA-t illeti, arról a következő cikkben lesz szó.

Publikációk

  1. Beth Gold-Bernstein kritikus fontosságú az ESB a jövője szempontjából?
  2. Nigel Thomas és Warren Buckley felemelkedése az ESB-től.
  3. Az Integrációs Konzorcium honlapján megjelent anyagok.

Mi az ESB és SOA¶

A rendszerrendszer-gondolkodás kiváló leírása
Nick Coghlan, Core Python fejlesztő

ben is kapható Catala, Deutsch, angol, Francais, Italiano, Nederlands, portugálok, törökés 中文 .

Az ESB rövidítés és a hozzá tartozó SOA zavart okozhat. Az ESB az Enterprise Service Bus rövidítése. SOA – Szolgáltatásorientált architektúra.

Ezek a nevek keveset jelentenek, ezért a következők többet tartalmaznak teljes körű információ közérthető nyelven, túlzott vállalati szókincs nélkül.

Minden igazság¶

Képzeljük el, mi történik, amikor bejelentkezik bankja front-end alkalmazásába:

  1. Megjelenik a neved
  2. Megjelenik a számlaegyenlege
  3. Hitel- és betéti kártyái megjelenítése
  4. Lehet, hogy van egy lista a befektetési alapjairól
  5. Ezenkívül megkapja az előre kalkulált hitelek listáját, amelyek érdekelhetik

Nagy valószínűséggel azt mondhatjuk, hogy ezek az információk mind hozzátartoznak különböző rendszerekés alkalmazások, amelyek mindegyike valamilyen interfészen keresztül szolgáltat adatokat (HTTP, JSON, AMQP, XML, SOAP, FTP, CSV vagy bármilyen más):

  1. Linuxot és Oracle-t futtató CRM-ből
  2. z/OS mainframe-en futó COBOL rendszerből
  3. azt mondják, hogy ez az információ egy mainframe rendszertől származik, de ezek a srácok túl hallgatagok ahhoz, hogy bármi mást mondjanak, mint azt, hogy a CSV-t preferálják minden mással szemben
  4. a Windowson futó PHP és Ruby keverékéből
  5. Linuxon és Solarison futó PostgreSQL-ből, Pythonból és Java-ból

A kérdés az, hogy hogyan lehet elérni, hogy a frontend alkalmazás beszéljen az 1-5 rendszerekkel? Hát, dehogy.

Ez alapvető fontosságú annak biztosításához, hogy az ilyen környezetek több rendszeren túl is skálázhatók legyenek. Nem kényszeríted őket arra, hogy közvetlenül kommunikáljanak egymással.

Az alábbi diagramon egy másik rendszer által nyújtott szolgáltatás minden egyes hívása eltérő vastagságú és stílusú vonallal látható:

Figyeljük meg, még csak nem is jelenítettünk meg magas szintű folyamatokat (az App1 meghívja az App2-t és az App3-at vagy az App5-öt attól függően, hogy az App6 korábbi válasza sikeres volt-e, így az App4 később át tudja venni az App2 által generált adatokat, de csak akkor, ha az App1 nem tiltja stb.).

Azt is vegye figyelembe, hogy nem szerverekről beszélünk – mindegyik rendszer 10 fizikai szerveren futhat, így legalább 60 fizikai komponens kommunikál egymással.

Néhány probléma azonban nyilvánvalóvá válik.

Hogyan lehet szétválasztani az interfészt? Hogyan kell ütemezni a letöltést? Hogyan koordinálja a frissítéseket vagy az ütemezett leállásokat, amikor az egyes alkalmazásokat különböző fejlesztőcsapatok, szállítók vagy részlegek kezelik, és az eredeti fejlesztők fele már elhagyta a vállalatot?

Ha úgy gondolja, hogy képes kezelni 6 alkalmazást, mit szólna 30-hoz?

Kibírod a 400-at? És 2000 óta? Minden alkalmazás saját egyedi ökoszisztéma lehet, amelynek futtatásához tucatnyi szerverre vagy más eszközre van szükség, így ez 20 000 mozgó alkatrészt jelent a kontinensek között, mindenféle technikai és kulturális határokkal. És mindezek a részek folyamatosan és megállás nélkül üzeneteket akarnak váltani mindenféle leállás nélkül. (A sémától megkíméljük.)

Van egy nagyszerű neve ennek a helyzetnek – rendetlenség.

Hogyan lehet megoldani a helyzetet?¶

Az első lépés annak felismerése, hogy a helyzet nem irányítható. Ez lehetővé teszi, hogy megoldást keressen anélkül, hogy erős bűntudatot érezne. Nos, megtörtént, nem tudtad, hogyan csináld jobban, de van rá esély, hogy mindez javítható.

Ez szervezeti változásokat hozhat az IT megközelítésében, de egy másik lépés, hogy ne feledjük, hogy a rendszerek és alkalmazások nem csupán az adatok megosztásáról szólnak. Úgy tervezték, hogy támogassák az üzleti folyamatokat, függetlenül az üzlettől, legyen az banki, hangfelvételek, radareszközök, bármi.

Ha ezt a két pontot egyértelműen meghatározza saját maga számára, megkezdheti a rendszerek tervezését vagy újratervezését a szolgáltatások köré.

A szolgáltatás egy érdekes, újrafelhasználható és atomszerű dolog, amelyet egy rendszer biztosít más, használni kívánó alkalmazások számára, de a szolgáltatás soha nem kerül közvetlenül egy az egybe. Ez a lehető legrövidebb és legtartalmasabb leírás.

Ha egy adott rendszerfunkció megfelel ennek a három követelménynek:

  • énérdekes (érdekes)
  • Rújrahasználható (újrafelhasználható)
  • A tomikus (atomi)

akkor jó esély van rá, hogy a rendszert szolgáltatásként ki lehet és kell kitenni más rendszerekhez, de soha nem lehet közvetlenül csatlakoztatni.

Vizsgáljuk meg az IRA megközelítését néhány példával.

Változó Megjegyzések
Környezet Villamos cég CRM rendszere
Funkcionalitás Azon ügyfelek listájának visszaküldése, akik aktívak voltak az önkiszolgáló portálon 2012 harmadik negyedévében
Ez érdekes? Igen, elég érdekes. Ez felhasználható mindenféle hasznos jelentés és statisztika készítésére.
Lehetséges Nem, annyira nem. Bár ez lehetővé teszi a létrehozást
többször magas szintű konstrukciók, például statisztikák az egész évre vonatkozóan,
használat? egyértelmű, hogy 2018-ban erre nem lesz szükségünk.
Ez atomos? Valószínűleg igen.

Ha már vannak hasonló szolgáltatások más negyedévekre, akkor az egész évet megtekintheti.
Hogyan lehet ebből IRA-t csinálni?
  • Kényszerítse az időszak tetszőleges kezdő és záró dátumát, ahelyett, hogy csak a negyedévet határozná meg.
  • Önkényes alkalmazások fogadásának kényszerítése, nem csak a portálon. Lehetővé teszi az alkalmazás számára, hogy bemeneti paraméterként információt fogadjon.
Változó Megjegyzések
Környezet e-kereskedelmi webhely
Funkcionalitás Minden olyan információt vissza kell adni, amelyet a megadott felhasználóról valaha gyűjtöttek
Ez érdekes? Általában igen. Ha hozzáfér az egészhez, mindig kiválaszthatja, amire szüksége van.
Lehetséges Furcsa módon nem igazán. Csak néhányan lesznek
többször pályázatokat, ha van, kit érdekel
használat? teljesen minden információt felhasználni.
Ez atomos? Határozottan nem. A funkcionalitásnak ez a szörnyetege logikusan több tucat kisebb részből áll össze.
Hogyan lehet ebből IRA-t csinálni?
  • Oszd több kisebb részre. Gondolja át, mi jellemzi a vásárlót – van címe, telefonszáma, kedvenc terméke, a kapcsolatfelvétel preferált módjai stb. Ezen elemek mindegyikét független szolgáltatássá kell alakítani.
  • Használja az ESB-t összetett szolgáltatások létrehozásához atomi szolgáltatásokból.
Változó Megjegyzések
Környezet Bármilyen CRM rendszer, bárhol
Funkcionalitás Frissítse a CUST_AR_ZN oszlopot a C_NAZ_AJ táblázatban, miután valaki létrehozott egy fiókot
Ez érdekes? Abszolút érdektelen. Ez a CRM rendszer belső funkciója. Józan észnél senki sem akar ilyen alacsony szintű funkcionalitással foglalkozni.
Lehetséges Igen valószínűleg. fiók keresztül hozható létre
többször több csatorna, tehát úgy tűnik, hogy ez valami több
használat? használt.
Ez atomos? Úgy tűnik, igen. Ez egy táblázat egy oszlopának egyszerű frissítése.
Hogyan lehet kivenni
ez az IRA? Ne is próbálj szolgáltatást csinálni belőle. Nem érdekes. Senki sem akar konkrét oszlopokra és táblázatokra egyetlen rendszerben gondolni. Ez egy trükkös része egy CRM-rendszernek, és bár újrafelhasználható és atomos, nem érdemes szolgáltatást építeni belőle. Ez a tiéd és a CRM, a te felelősséged, hogy gondolkodj rajta, ne kényszeríts másokat is ennek elviselésére
Változó Megjegyzések
Környezet Mobilszolgáltató
Funkcionalitás Előre fizetett kommunikációs kártya feltöltése a számlázásban
Ez érdekes? Rendkívül. Mindenki szeretné használni, szöveges üzeneteken, IVR-en, IM-en, portálokon, ajándékkártya stb.
Lehetséges Igen. Számos magas szintű rendezvényen vehet részt
többször folyamatokat.
használat?
Ez atomos? Igen, a hívóalkalmazás szempontjából a kártya feltölthető vagy nem. Az a tény, hogy a számlázás ezt több lépésben valósítja meg, nem fontos. Üzleti szempontból ez atomszerű, oszthatatlan szolgáltatás, amit a számlázás nyújt.
Hogyan lehet kivenni Ez már IRA.
ez az IRA?

Ha csak egy kicsit is programozott az elmúlt 50 évben, akkor nyilvánvalóvá válik számodra, hogy egy szolgáltatás nyújtása olyan, mintha egy API-t biztosítanál egy másik kódrészletben. Az egyetlen különbség az, hogy Ön nem egy rendszer almoduljaival foglalkozik, hanem az egyes rendszerek teljes környezetének szintjén dolgozik.

Szolgáltatások elérhetősége ESB-ben és SOA-ban¶

Most, hogy tudja, hogy a rendszerek nem kommunikálnak közvetlenül, és megértette, mi a szolgáltatás, elkezdheti hatékonyan használni az ESB-t.

Most az ESB feladata, hogy integrált rendszerszolgáltatásokat nyújtson és hívjon elő. Így a legtöbb esetben csak egy hozzáférési módot, egy interfészt kell meghatározni az egyes rendszerek és az ESB között.

Tehát ha, mint a fenti diagramon, 8 rendszere van, akkor 16 interfésze van (mindegyik irányban egy) létrehozásához, karbantartásához, kezeléséhez és szolgáltatásához.

Az ESB nélkül 56 interfészt kell létrehoznia és kezelnie (feltételezve, hogy minden rendszer beszél egymással).

Nincs további 40 interfész, ami kevesebb elvesztegetett időt és több pénzt takarít meg. Ez az egyik oka annak, hogy a pénteki napjai kevésbé lesznek stresszesek.

Ez a tény önmagában arra készteti Önt, hogy fontolja meg az ESB bevezetését.

Ha az egyik rendszert átírják, átadják egy másik tulajdonosnak, felosztják részlegek vagy gyártók között, akkor az ESB-s srácok feladata lesz a megfelelő változtatások elvégzése. Ezt a többi rendszer sem veszi észre, mivel az ESB-vel való interfészük érintetlen marad.

Ha elkezdi rendszeresen igénybe venni az IRA-szolgáltatásokat, elkezdhet gondolkodni az összetett szolgáltatásokon.

Emlékszel a fenti „adj nekem bármit, amit megtehetsz erről az ügyfélről” szolgáltatásra?

Nem volt jó ötlet ilyet létrehozni, de időnként olyan ügyfélalkalmazásokba ütközhet, amelyeknek összesíteniük kell az információkat. Az ESB srácok felelősek lesznek ezért, és az ő feladatuk lesz kiválasztani a legjobb atomi szolgáltatásokat, hogy egy összetett szolgáltatást építsenek ki az adott ügyfélrendszerhez, amelyhez az adott összetett adatkészlet szükséges.

Idővel az egész szervezet kezdi felismerni, hogy már nem adatbázistáblákról, fájlokról, csomagokról, függvényekről, szubrutinokról vagy rekordokról van szó. Most egy olyan architektúráról beszélünk, amely az ESB-alkalmazások által nyújtott érdekes, újrafelhasználható és atomi szolgáltatások köré épül.

Az emberek többé nem fogják azt hinni, hogy az alkalmazások és a rendszerek üzeneteket küldenek egymásnak. Az ESB-t egyablakos átjárónak fogják tekinteni olyan érdekes szolgáltatásokhoz, amelyeket saját rendszereik használhatnak. És azt sem fogják ellenőrizni, hogy ki mit biztosít, a rendszereik csak az ESB-vel foglalkoznak.

Időt, türelmet és összehangolt erőfeszítéseket igényel, de megvalósítható.

De vigyázz…¶

A legtöbb A legjobb mód rombolja le a SOA teljes koncepcióját – telepítse az ESB-t, és várja el, hogy a problémák maguktól megoldódnak. Bár nagyszerű ötlet, sajnos egy ESB telepítése nem lesz elég.

A legjobb esetben, ha megpróbál valamit elrejteni a szőnyeg alá, ahogy az alábbi ábrán látható, semmire sem vezet:

Az informatikusok utálni fogják a rendszert, és bár a vezetők kezdetben eltűrik az ESB-t, mint új megoldást, végül nevetség tárgyává válik. „Mi, ez ugyanaz az új ezüstgolyó? Hahaha.”

Az ilyen következmények elkerülhetetlenek, ha az ESB nem része egy nagyobb fejlesztési tervnek.

Tehát az ESB csak bankoknak és hasonlóknak való?¶

Egyáltalán nem. azt jó döntés minden olyan helyzetben, ahol több adatforrás és többféle hozzáférési módszer összehangolt munkájára van szükség az érdekes eredmény eléréséhez.

Például a legfrissebb hőmérsékleti értékek összegyűjtése és több csatornán való közzététele, például e-mail-riasztások és iPhone-alkalmazások, jól illeszkedik egy integrációs platformhoz.

Egy kritikus alkalmazás összes példányának időnkénti ellenőrzése és működésének figyelése, és ha nem is fut mindegyik, egy konfigurált szkript futtatása és szöveges üzenet küldése a rendszergazdáknak is nagyszerű.

Bármi, amit egy világos, jól meghatározott környezetbe kell integrálni, valószínűleg jól illeszkedik egy ESB szolgáltatáshoz. De mint mindig, a döntés, hogy valami valóban alkalmas-e az integrációra, tapasztalattal jön.

vállalati szolgáltató busz

Természetesen a Zato csapata segíthet.

De azt hallottam, hogy a SOA XML, SOAP és webszolgáltatás.

Igen, egyesek azt szeretnék, ha ezt elhiggye.

Ha azok az emberek vagy szállítók, akikkel dolgozott, BASE64-kódolású CSV-fájlt küldtek SAML2-védett SOAP-üzenetben, akkor érthető, hogy miért kapta ezt a benyomást.

Az XML-nek, a SOAP-nak és a webszolgáltatásoknak megvannak a használati esetei, de mint minden másnak, ezekkel is vissza lehet élni.

A SOA az érthető és kezelhető architektúráról szól. Az, hogy egy szolgáltatás használhat-e SOAP-ot, gyakorlatilag lényegtelen. A SOA mint architektúra-megközelítés akkor is érvényes marad, ha egyáltalán nem használunk SOAP-szolgáltatást.

Ha egy építész egy gyönyörű épületet tervez, nem tudja túlságosan befolyásolni a belső tér színét.

Tehát nem, a SOA nem XML, SOAP és webszolgáltatás. Használhatók, de csak egy részét képezik, nem az alapot.

Az elveszett kollégák figyelmébe ajánlhatja ezt a cikket, hogy megértsék, mi az a SOA.

További részletek¶

Ez a fejezet csak az alapokat tárgyalja, ennek ellenére alapos megértést kell adnia arról, hogyan nézzen ki az ESB és a SOA, és mi kell a sikerhez.

Az itt nem tárgyalt egyéb témák közé tartozik (de nem kizárólagosan):

  • Hogyan kaphat támogatást a vezetőktől az ESB bevezetéséhez
  • SOA-építészek és elemzőcsapatok összeállítása
  • A kanonikus adatmodell (CDM) ábrázolása egy szervezetben
  • Kulcsteljesítménymutatók (KPI-k) – most, hogy van egy közös és egységes módszere a szolgáltatások nyújtására a rendszerek között, el kell kezdenie megfigyelni és elemezni, hogy valójában mit is nyújtanak Önnek
  • Business Process Management (BPM) – hogyan és mikor válasszunk BPM platformot a szolgáltatásmenedzsmenthez (a válasz nem túl korai, először tanulja meg, hogyan kell szép és hasznos szolgáltatásokat felépíteni)
  • Mi a teendő API nélküli rendszerekkel? Például, ha az ESB közvetlen hozzáférést kap az adatbázisaihoz (a válasz más, nincs aranyszabály)

Szóval mi az a Zato?¶

A Zato egy Python nyelven írt ESB- és alkalmazásszerver, amely köztes szoftverek és háttérrendszerek építésére használható. Ez a szoftver nyitva van forráskód kereskedelmi és közösségi támogatással. A Python pedig egy egyszerűségéről és hatékonyságáról ismert programozási nyelv.

A Python és a Zato használatával növelheti a termelékenységet és kevesebb időt veszíthet.

Zato-t írták pragmatikusok pragmatikusoknak. Ez nem egy újabb sebtében felépített rendszer, amelyet egy gyártó az ESB/SOA hírverés nyomán épített fel.

Valójában a Zato az ilyen rendszerek által okozott "tüzek eloltásában" szerzett gyakorlati tapasztalatok alapján készült. Valójában a Zato szerzői annyi időt töltöttek az ilyen környezetek elleni küzdelemben, hogy gyakorlatilag immunissá váltak minden tűzesetre.

Ez az a kovács, ahonnan a Zato a világra jött, ezért olyan teljesítményt és könnyű használhatóságot tud nyújtani, amely más hasonló megoldásokban nem található meg.

Ott találkozunk itt!

(Enterprise Service Bus) a vállalat elosztott információs környezetének kialakítására szolgál. Szoftver biztosítja az összes integrált alkalmazás interakcióját egy központban, kombinálva a meglévő információforrásokat és központosított adatcserét biztosítva a különböző alkalmazások között. információs rendszerek.

Enterprise Service Data Bus DATAREON ESB hatékony eszköz az információcsere stabilitásának és teljességének biztosítására, az információs rendszer általános teljesítményének növelésére és az adminisztráció munkaerőköltségének csökkentésére.

Enterprise Service Bus

Szoftver DATAREON ESB hivatalosan szerepel az orosz elektronikus programok egységes nyilvántartásában számítógépek valamint állami és önkormányzati intézmények által megvásárolható adatbázisok (https://reestr.minsvyaz.ru/).

A kisvállalatok 2-3 információs rendszerének integrálására a DATAREON egy DATAREON ESB - DATAREON MQ alapú szoftverterméket kínál.

A DATAREON ESB funkcionalitása

Vállalati szolgáltatási adatbusz segítségével megoldott feladatok

  • Adatátvitel különböző információs rendszerek között (irányított vagy pont-pont)
  • Egységes információs tér kialakítása heterogén környezetben
  • Elosztott rendszer felépítése eseménymodell alapján a következő lehetőségek között:
    • alkalmazások építése végpontok közötti üzleti folyamatokkal az eseménymodell alapján;
    • rendszer létrehozása az üzleti alkalmazások szinkronizálásával különféle információs rendszerekben
  • Nyugta méretezhető vezérlő architektúra vállalati/holding szinten
  • Telepítés adatcsere rendszerek szállítási rétegben és üzleti logikai szinten
  • Az információáramlás kiépítésének feladatának delegálása elemző osztályok
  • Az integrációs séma általános összetettségének csökkentéseés a követelmény csökkentése sávszélesség csatornák
  • Az általános stabilitás növelése adatátviteli réteg
  • Csökkentett tranzakciós költségek a különböző osztályok közötti adatcsere során
  • Csökkentett összköltség az információs rendszer karbantartása és támogatása.

A DATAREON ESB Enterprise Service Bus előnyei

  • Gyors integráció
  • Magas megbízhatóság
  • Az erőforrások újrafelhasználásának képessége

), korábban Axelot Datareon ESB néven, elosztott vállalati információs környezet kialakítására tervezték. A szoftvertermék biztosítja az összes integrált alkalmazás interakcióját egy központban, kombinálva a meglévő információforrásokat és központi adatcserét biztosítva a különböző információs rendszerek között.

A Datareon ESB Enterprise Data Service Bus az információcsere stabilitásának és teljességének biztosítására, az információs rendszer általános teljesítményének növelésére és adminisztrációjának munkaerőköltségének csökkentésére szolgál.

A Datareon ESB szoftvertermék hivatalosan is szerepel az elektronikus számítógépekhez és adatbázisokhoz készült orosz programok egységes nyilvántartásában, amelyet állami és önkormányzati intézmények vásárolhatnak meg.

Funkcionalitás

  • Különféle szabványok és integrációs forgatókönyvek támogatása
  • Az Eclipse ökoszisztémával való integrációs környezet központosított kezelése
  • Adatátalakítás (többlépcsős adattranszformációs algoritmusok különféle feltételek szabályozásával)
  • Bármilyen méretű adatátvitel (függőleges és vízszintes méretezés)
  • Egyszerű integráció az 1C:Enterprise 8 platformon alapuló termékekkel
  • Biztonságos adatátvitel biztosítása
  • A teljes adathálózat állapotának diagnosztikája, monitorozása

Megoldandó feladatok

  • Adatátvitel különböző információs rendszerek között (útválasztással vagy ponttól pontig)
  • Egységes információs tér kialakítása heterogén környezetben
  • Elosztott rendszer felépítése az eseménymodell alapján a következő lehetőségek szerint:
    • alkalmazások építése végpontok közötti üzleti folyamatokkal az eseménymodell alapján;
    • rendszer létrehozása az üzleti alkalmazások szinkronizálásával különféle információs rendszerekben
  • Skálázható vállalati / holding szintű menedzsment architektúra beszerzése
  • Adatcsere-rendszer kiépítése szállítási szinten és üzleti logikai szinten
  • Az információáramlás kiépítésének feladatának átruházása az elemző osztályokra
  • Az integrációs séma általános összetettségének csökkentése és a csatornák sávszélesség-igényének csökkentése
  • Az adatátviteli réteg általános stabilitásának növelése
  • A tranzakciós költségek csökkentése a különböző részlegek közötti adatcsere során

2017

Axelot Datareon ESB 2.1.0.0

Az AXELOT Datareon ESB megoldás felkerült az Arany Alkalmazásfejlesztési kompetenciák listájára – ez a tény megerősíti a termék kiváló minőségét és a Microsoft termékekkel való kompatibilitását.

Az AXELOT Datareon ESB számos kulcsfontosságú előnyt biztosít a vállalkozások számára:

  • Integrációs lehetőség;
  • Az erőforrások megbízhatósága és újrafelhasználhatósága;
  • Méretezhető vállalati / holding szintű menedzsment architektúra beszerzése;
  • Az információáramlás kiépítésének feladatának átruházása az elemző osztályokra;
  • Az integrációs séma általános összetettségének csökkentése és a csatorna sávszélesség követelményének csökkentése;
  • Az adatátvitel szállítási rétegének általános stabilitásának növelése;
  • A tranzakciós költségek csökkentése a különböző részlegek közötti adatcsere során;
  • Az információs rendszer fenntartásának és karbantartásának teljes költségének csökkentése.

A rendszer főbb jellemzői:

  • Nagy számú csatlakozó különféle rendszerek: 1С:Enterprise 8, SOAP szolgáltatások, REST szolgáltatások, MS SQL, IBM DB2, Oracle DB, PostgreSQL, SharePoint, OData, TCP, Siemens TeamCenter és mások;
  • Plugin mechanizmus a csatlakozók független fejlesztéséhez;
  • Különféle programozási nyelvek és technológiák támogatása interakciós forgatókönyvek kidolgozásakor: 1C:Enterprise 8, JavaScript, T-SQL;
  • Többlépéses adatátalakítási forgatókönyvek beállítása vizuális leképezési mechanizmusok és tetszőleges XSLT-transzformációk segítségével;
  • Dolgozik vele különféle formátumok adatok (XML, JSON, XLS, DBF, CSV, Base64 és mások);
  • Információs csomagok statikus és dinamikus útválasztása;
  • Nagy sebességű interakció és hibatűrés: csökkentett követelmények a hálózati sávszélességre, a terheléselosztásra, az információs tartományok elkülönítésére, az integrációs csomópontok állapotának figyelésére;
  • Eseménymodell támogatás, szinkron és aszinkron hívások, garantált kézbesítés;
  • Az előfizetői rendszerek integrációs forgatókönyveinek megváltoztatása (kirakodási/betöltési, átalakítási és útválasztási mechanizmusok) "hot" módban anélkül, hogy le kellene őket állítani (beleértve az 1C:Enterprise 8 platform konfigurációit is);
  • Minden integrációs folyamat diagnosztikája és felügyelete, hibakeresési és nyomkövetési információs csomagok.

Különös figyelmet fordítanak az alkalmazások integrációjára az 1C:Enterprise 8 platformon. A szállítás egy speciális alrendszert tartalmaz, amely az 1C:Enterprise 8 platform bármely szabványos konfigurációjába be van építve, és minden szükséges mechanizmust biztosít a gyors és kényelmes integráció beállításához és adminisztrációjához. AXELOT: Az ESB Service Data Bus kölcsönhatásba lép az 1C:Enterprise 8 platform konfigurációjával SOAP és REST szolgáltatásokon keresztül.

Az "AXELOT: ESB Service Data Bus" szerverkomponenseket C++ nyelven fejlesztették ki. Az "AXELOT: ESB Service Data Bus" adminisztrációja és konfigurálása az Eclipse fejlesztőkörnyezetben történik, és az "1C: Enterprise 8" platformon az "1C: Enterprise Development Tools" alatti rendszerek fejlesztésével együtt hajtható végre. Az „AXELOT: ESB Service Data Bus” többplatformos és támogatja Operációs rendszer MS Windows és Linux.

Az AXELOT Datareon ESB egy teljesen orosz fejlesztés, és folyamatban van az elektronikus számítógépekhez és adatbázisokhoz készült orosz programok egységes nyilvántartásába való felvétele, amelyet állami és önkormányzati intézmények megvásárolhatnak bizonyos problémák megoldására.

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álható rendszerekből”;

  • „megvalósított folyamatokból”.

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

Megközelítés "integrálható rendszerek felől"

Ebben az esetben az integrációs buszt egyfajta szállításnak tekintjük, amely az üzenetküldési protokollok útválasztását és egyeztetését végzi. Minden üzenet a láncon megy keresztül: a forrásrendszer adapterének bemeneti csatornája -> útválasztó -> a vevőrendszer kimeneti csatornája. Az ezen összetevők és az egyes 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 (egy közös tranzakció használata minden forrásrendszerre, vagy az adatok átvitele minden egyes forrásrendszer a tranzakcióban).

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

  2. Új vevőrendszerek egyszerű csatlakoztatása: egy új vevőrendszer csatlakoztatásához elegendő az adatokat megadni az útválasztási táblázatban.

  3. Az 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 a integrált rendszerek adapterei).

  4. Könnyű támogatási megoldás. Mivel minden üzenet egyetlen útválasztón halad át, az üzenettovábbítás és az üzenetek közötti függőségek minden logikája megvalósítható egy helyen - ebben az útválasztóban.

  5. A rendszer megosztása a fejlesztők között. Mivel a rendszermag és az összes adapter független egymástól (a kommunikáció csak dedikált és leírt interfészeken keresztül történik), a 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 üzenettovábbítási logika megvalósítására alkalmazható, pl. ha vannak olyan szabályok a függőségek nyomon követésére és az átalakításokra, amelyek az összes vagy a legtöbb üzenetre közösek. Ha különböző típusok az üzenetek teljesen más függőségi nyomon követési és cserekezelési logikával rendelkeznek, vagy adapterekre kell áthelyezni, ami kiküszöböli 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 a megvalósítás bonyolultsága ez a megközelítés jelentősen megnő.

  3. A megoldás teljesítménye romolhat. Például, ha egy üzenetet külön tranzakcióban kell továbbítani az egyes fogadórendszerekhez, akkor a forrásrendszert, a kernel- és a vevőrendszereket sorok szerint kell elválasztani. Ezek a sorok a rendszer szűk keresztmetszetévé válhatnak.

Megközelítés "megvalósított folyamatokból"

Ebben az esetben minden üzleti folyamatot külön-külön vizsgálunk, amelyekben több rendszer közötti adatcsere szükséges. 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 üzenet egy vagy több fogadórendszerhez kerül továbbításra, miközben nemcsak szállítási funkciókat valósítanak 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 a saját, külön cserelogika megvalósítását 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, pontosabban 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 egy másik cserefolyamat 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. Általában az üzenettípusok száma 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 külön 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 komponenseinek fejlesztőinek munkájától függenek.

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


  1. Szerezze be elemzőktől az integrált rendszerek és üzenettípusok listáját és leírását.

  2. Szerezze be az elemzőktől az integrációt igénylő rendszereket magában foglaló üzleti folyamatok listáját és leírását.

  3. Ha a folyamatok triviálisak, és sokkal kevesebb rendszer van, mint az üzenettípus, az adatcsere túlnyomórészt aszinkron, és egy üzenetet több rendszerbe is át kell vinni, akkor az első megközelítést választjuk. Döntse el a tranzakciókezelési szabályzatot.

  4. Ha a folyamatok túlnyomóan szinkron cserét jelentenek, míg a folyamatok összetettek, pl. egy üzenet továbbítása a fogadó rendszerekben történő feldolgozás eredményétől függ, akkor a második megközelítést választjuk. Egy másik érv e megközelítés mellett az a tény, hogy az üzenettípusok száma összemérhető az integrált rendszerek számával.

Világosan meg kell érteni, 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óak, modern vállalati szerviz abroncsok ( ESB) lehetővé teszi ezt.

Tetszett a bejegyzés -

Ezzel a cikkel szeretném megnyitni az IBM WebSphere ESB-nek (a továbbiakban: ESB) szentelt ciklust a termék fejlesztésével összefüggésben. És először is 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ény-orientált üzenetküldést biztosít a különböző információs rendszerek között.
Természetesen speciális szoftverek nélkül is (talán még valami általánost kell majd fejleszteni) erre a megközelítésre építve lehet vállalati rendszert építeni, és ami ennek hatására történik, azt szervizbusznak nevezhetjük. De az IBM termékében nem csak egy kész berendezés található a központosított üzenetküldéshez és ennek a folyamatnak a vezérléséhez, hanem teljes készlet rugalmas szolgáltatás-orientált alkalmazások fejlesztésének lehetőségei kifejezetten ESB számára. Összefoglalva, az IBM WebSphere ESB alábbi szolgáltatásai és előnyei emelhetők ki:

  • Az építészeti kapcsolatok rendje és egységessége
  • Központosított menedzsment
  • Szerveroldali alkalmazáskonfiguráció
  • A Service Component Architecture (SCA) technológia bevezetése 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 adatok átalakítását, a biztonságot és az üzenetek garantált kézbesítését. Az összes szolgáltatáshoz való hozzáférés egyetlen ponton keresztül 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 szerverkapacitás 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 az interakciós modell felépítésében. vállalati rendszerek hatékony integrációs eszközként (értsd: az ESB az IBM WebSphere Application Server kiegészítőjeként).
Valójában ez megköveteli az ESB-től, mivel ez egy „szolgáltatás-gyűjtőpont” - ha olyan szolgáltatásra van szüksége, amely más szolgáltatásokkal működik (esetleg külső), akkor a szolgáltatások közötti integráció a leglogikusabban az ESB-n történik. . Külső vagy heterogén szolgáltatások esetén a "csomagolót" ESB szolgáltatássá teheti. Szemléltessük egy kicsit az "egyedülálló ház" 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 benne. Ha egy nagyvállalat rendszereinek komplexumáról beszélünk, akkor azt minden bizonnyal nagy méretű rendszernek nevezhetjük. Természetesen mindig találhat egy adminisztrátort, akinek a fejében több száz szerver interakciójának diagramja vagy egy csomó független dokumentáció kötete áll a fejében. szoftver modul, amely leírja, hogy mivel és hogyan kölcsönhatásba lép.


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

Központosított menedzsment
Mindig kényelmesebb központilag konfigurálni a rendszereket – legyen szó konfigurációról, szerver áthelyezéshez való alkalmazkodásról, hibatűrésről, terheléselosztásról, hibakezelésről vagy felügyeletről és elemzésről.


Például egy adatbázis-szerver áthelyezésekor nem kell belemenni az összes meglévő alkalmazásszerver konfigurációjába, és különösen az egyes alkalmazások beállításaiba - elég, ha az ESB-ben van egy környezeti változó, amely meghatározza az adatbázist. címet, és akkor a változtatásokat csak egy ponton kell végrehajtani.
Vagy ha valamelyik külső rendszer hosszabb 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ályozni kell az egyidejű kérések számát bármely rendszerhez, vagy figyelni kell ezeket a kéréseket, elemezni kell a terhelést, keresni kell a szűk keresztmetszeteket - el kell mennie az üzenetkezelési központba - az ESB szerverkonzolra.

Szerver oldali konfiguráció
A szolgáltatások "egyedülálló háza" a konfiguráció szempontjából számos hasznos cél elérését teszi lehetővé. Az első a konfiguráció újrafelhasználása (hasonlóan a kód és modul újrafelhasználásához, ami nagyon hasznos a SOA-ban), mert különböző modulokés az alkalmazások ugyanazokat az adatbázis-kapcsolati paramétereket, erőforrásokat, hitelesítési paramétereket, környezeti változókat és így tovább használhatják.


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

Ha mindezeket az előnyöket kihasználja, az alkalmazások megkapják az igazi kaméleon képességeit – annyira rugalmasak, hogy a munkakörnyezet részévé válnak, és egyúttal hozzák a fontos funkcionalitásukat.

Az IBM WebSphere ESB alatti 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 nem csak futniuk kell, hanem fejleszteni és véglegesíteni is kell, ezeket az érdekességeket nem szabad kihagyni:

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

Nagyon kényelmes egy ilyen modulstruktúra fejlesztése, ellenőrzése, fejlesztése, megváltoztatása és karbantartása. A komponensekben megvalósított funkcionalitás atomitása lehetővé teszi, hogy a komponensek egészén működjenek anélkül, hogy a kódszintre lemennének. Másrészt logikailag szükséges a komponens implementációk tranzakciós kontextusban történő végrehajtása miatt.
Minden összetevőnek van interfésze(i), amelyek megvalósítását biztosítja. Így az összetevők összekapcsolásával nem kell ismerni őket belső jellemzők– elég, ha megvalósítják a szükséges interfészeket.
Ezen az architektúrán keresztül minden párhuzamos munkát igénylő feladat is megoldható, "kézi" áramlásvezérlés nélkül (például több komponenst is kezdeményezhet aszinkron hívások késleltetett válasszal).
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 ennek megfelelően külső szolgáltatásokat igénybe venni; A Mediation Flow komponens alacsony szintű hozzáférést biztosít a más összetevők által váltott üzenetekhez, és különféle átalakításokat tesz lehetővé heterogén interfészekkel végzett munka során.
Az interfészek mellett az IBM üzleti objektum keretrendszer nagyon hasznos szolgáltatásokat is nyújt. Az xsd sémák által képviselt ü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 a webszolgáltatások leírására szolgáló wsdl sémába. Vagyis ha például az "A" modul webszolgáltatás formájában biztosítja a funkcionalitását, akkor használatához elég, ha a "B" modul csatlakoztatja az interfészt és a kész BO-kat, és képes lesz teljes mértékben működik egy ilyen szolgáltatással anélkül, hogy további java objektumokat hozna létre az adatátvitelhez. A BO ​​az adatbázissal való adatcsere során is kényelmesen használható, ha ezeket az adatokat más komponensek is felhasználják (ez persze ellenkezik a „DAO” mintával, de kiküszöböli a felesleges java objektumokat és az adatátírási műveleteket „oda-vissza” ).

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 az összetevőkkel interfészeken és referenciákon keresztül történik, programozási kó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ármelyiken a megfelelő interfészek. A következő ábra bemutatja, hogyan adható hozzá egy exportálás SCA-kötéssel egy olyan komponenshez, amely már HTTP, JMS és webszolgáltatásként teszi elérhetővé a felületét.


Az előnyök nyilvánvalóak – rugalmasság, sokoldalúság, kód-újrafelhasználás, 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ásigényes és gyorsabb, mint más protokollok.

Konfiguráció
A szerver és az alkalmazás konfigurálása a kiszolgáló IBM konzolján keresztül történik.
Az ESB, mint általában az IBM WebSphere, jó néhány speciális funkcióval és melléktermékkel rendelkezik. Például, ha ugyanazt az importálást és exportálást használja, menet közben is 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 működik; de a tranzakciós kapcsolat már egy témában a teljes cikkhez), állítsa be a hitelesítési paramétereket, csatlakoztasson 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 az összetevők végrehajtásának automatikus megismétlése hiba esetén). Beállíthatja az összetevők nyomkövetését menet közben, 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 más dolgot is beállíthat a Java2EE specifikációja szerint, amely néha meglehetősen szigorúan az IBM Application Serverben van implementálva.

A fentiek mindegyike megerősíti, hogy az ESB kényelmes, hatékony és rugalmas integrációs berendezés, 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áltuk fel:

10 éve ismerem személyesen a SOA-t, ez idő alatt kialakult bennem egy egyértelmű asszociációs lánc: a SOA alapja az adatbusz, nos, az adatbusz óta, akkor integrációs projektekről beszélünk.

Nem fogom felkavarni a történelmet, mindannyian emlékszünk, hogyan fejlődött a maga idejében az integráció: egy hosszú és fájdalmas út a pont-pont koncepciótól az integrációs rétegben dedikált adatmodellel rendelkező buszig. Ma már a Neoflex Integra integrációs termékről beszélünk, amelynek van analógja orosz piac még nincs bankautomatizálás, hogy az analitika kezdeti szakasza nagymértékben csökkenthető legyen, és egyben azonnal értékelhető legyen egy jövőbeni integrációs projekt eredménye.

A Neoflex Integra a banknál végrehajtott 450., sőt 455. integrációs projekt után jelent meg. Nehéz pontosan meghatározni. De megpróbáltuk kiszámolni a munkatársaink integrációs gyakorlatára fordított embernapokat, és ez nagyjából 137 évnek bizonyult. Az integráció mindig is a Neoflex munkájának egyik fő területe volt, így nem kell meglepődni egy ilyen adaton. Ezalatt két dolgot sikerült megértenünk. Először is, a hitelintézetekben lévő tájak minősíthetők. Másodszor, sok a közös az integrációs projektek között, legalábbis az elemzési szakaszban. Az alapot egy általános kanonikus modell formájában különítettük el, amely alkalmazásobjektumokat és a köztük lévő kapcsolatokat tartalmazza, az atomi szolgáltatásokat üzleti folyamatokká egyesítve egy pénzügyi szervezet tevékenységi területén. Fantasztikusnak tűnik, de most már kész „részletek” halmazával érkezhetünk a bankba, és ezek alapján alakíthatunk ki egy jövőbeli integrációs modellt. A Neoflex Integra új termék, a The Retail Finance márciusi számában jelentettük be. De ma már kijelenthetjük, hogy ez lehetővé teszi az integrációs projekt megvalósításának körülbelül negyedével történő lerövidítését, ráadásul a bank többé nem vesz „disznót a zsebben”, mint korábban, fizet egy nagyon határozott eredmény. Térjünk azonban vissza a SOA-hoz, és akit érdekel egy integrációs termék téma, annak november 20-án az „Új Neoflex Integra termék: a projektélmény kvintesszenciája” című webináriumra hívom.

Tehát mi lesz ezután, hogyan fog fejlődni a SOA, megmarad-e az adatbusz, és ugyanolyan megtisztelő helyet foglal-e el, mint most a hitelvilágban, és ha tágabban nézzük, akkor nem csak a hitelszervezet? Messziről kezdem, általánosságban a SOA-ról, hogy mi a sorsa ennek a koncepciónak a bankszektorban. Valójában egy bank számára az a megfelelő informatikai architektúra, amely képes kielégíteni üzleti igényeit. Minél nagyobb a bank, annál magasabbak a kérések. A többágú, földrajzilag elosztott struktúrájú Oroszországban van elég nagy bank, de még ők sem mindig engedhetik meg maguknak a minőségi SOA-tájt, és nem csak azért, mert nagyon drága, hanem azért is, mert óriási kockázatot jelent. A SOA-projektek nem mindig végződnek jól. Termékünkkel a kockázatok, egyben a SOA-ba való belépés küszöbének csökkentését tervezzük.

Ne gondolja, hogy a SOA-környezet egy csőüzlet. A Neoflex projektek azt mutatják, hogy nincsenek nem integrálható rendszerek. A bankok általában apránként kezdenek új tájat kialakítani, kezdve a számukra legfontosabb területekkel, de mostanában olyan léptékkel találkozunk, amilyenre eddig nem volt példa. Ez a VTB24 bank egyik projektjén történt. A vállalat az Oracle SOA Suite-on alapuló univerzális banki szolgáltatások réteg létrehozásán dolgozott. A megoldás több mint 600 szolgáltatást tartalmazott, amelyek minden kommunikációs csatornán biztosítják a bank munkáját minden ügyféllel. Az Oracle munkatársai szerint egy ilyen nagy és összetett döntésre Oroszországban nem fognak emlékezni. És ha ez sikerült, akkor más projektek tisztán technikailag megvalósíthatók.

Az egységes logikai réteg kialakításának és az informatikai tér optimalizálásának szükségességét leginkább a nagyszámú lakossági projektet lebonyolító bankok tapasztalják. Az ügyfélkiszolgálás gyorsasága itt döntő jelentőségű, a SOA gyakorlatban alkalmazott technikák pedig a gyorsabb adatáramlás miatt ezt jelentősen növelhetik. Ezért az olyan vezető bankok, mint a VTB24, a Probusinessbank ( Életcsoport), amellyel szintén dolgozunk, hosszú távú SOA átmeneti programokat fogadott el valamikor. Hogy a kisebb szervezetek követik-e példájukat, azt nehéz megmondani: a válság végül is az. De a tisztán gyakorlati megfontolások a következők. Ha megpróbálunk feltételes határt húzni a SOA-ra szorulók és az egyszerűbb megoldásokkal boldogulók között, akkor ez a határ a piaci stagnálás kezdete előtt megközelítőleg a legjobb 400 bankon ment át.

A bankautomatizálás más területein a kész funkcionalitás használatának maximalizálásának koncepciója, vagy a termékkoncepció sikeresen gyökeret vert a rendszerek komponensesítését követően. Szerintem a SOA nem lehet kivétel. De ez a jövő kérdése. Mindeközben sok bank teljesen más valóságban él, és nem az a kérdés, hogy melyik integrációs terméket használják, hanem az, hogy melyik buszt valósítsák meg. Szálljunk le a mennyből a földre.

Mi a teendő az IBM WebSphere ESB-vel?

Az IBM WebSphere ESB kétségtelenül piacvezető az integrációs buszok között mind a projektek számát, mind a megvalósítások számát tekintve. A 10 integrációs projektből 8 az IBM WebSphere ESB-n valósul meg. És csak az elmúlt 2 évben a helyzet kezdett kissé megváltozni, és más nagy globális szállítók mozgása is megjelent a piacon. Nem szeretném ezeket a cikk keretein belül összehasonlítani, mivel enélkül elegendő számú összehasonlítás és elemző tanulmány létezik ebben a témában. Cikkem azoknak szól, akik egy időben tettek egy lépést a SOA felé, és tették ezt az IBM WebSphere ESB-vel együtt. És komolyan kellett aggódniuk: hirtelen, mint a hó a fejükön, a tavalyi hír, hogy az IBM 2014 óta megváltoztatta az integrációs szoftverek termékcsaládját, és az IBM Web Sphere ESB-t már nem fejlesztik, és ennek támogatása A komplexumot csak nemrégiben hosszabbították meg 2018 áprilisáig. Korábban 2014-re tervezték befejezni.

Ezzel kapcsolatban egyre több ügyfelünk, aki ezt az integrációs platformot használta, elkezdett kérdéseket feltenni arról, hogy mi vár rájuk.

Csodák nem történnek, és nem vagyok varázsló, de két módot szeretnék ajánlani:

1. Kezdjen el gondolkodni egy másik platform használatán, amelyre az IBM a jövőben tippel – az Integration Bus (korábbi Message Broker).

Nyilvánvaló előnyei vannak az IBM WebSphere ESB-vel szemben: teljesítmény és megbízhatóság. Ezzel a platformmal is van elég projekt és implementáció, és valaki már a kezdetektől ezt választotta integrációs busznak.

Fő technológiai jellemzője a Message Queuing (MQ) belső alkalmazása átvitelként, amely garantált üzenetkézbesítést és ennek eredményeként megbízhatóságot biztosít számunkra.

2. Már most, amikor integrációs megoldást fejleszt az IBM WebSphere ESB-n, próbálja meg elkülöníteni a megvalósítási szinteket, hogy létrehozza új kód nem az IBM WebSphere ESB-n, hanem más komponenseken, amelyeknek az integrációs megoldásban való felhasználása megfelel a további evolúciós stratégiának. Nem sok megfelelő termék van az IBM-től, csak 2-3. Az egyik, véleményem szerint, a legígéretesebb az IBM WebSphere Data Power, az integrációs problémák megoldására szolgáló hardver- és szoftverrendszer, amely nagy teljesítményt és tanúsított biztonságot nyújt. Ennek a terméknek az előnyei kategóriájában a legmagasabb teljesítmény, valamint a külső és belső biztonsági feladatok széles skálájának megoldására való képesség.

A mai napig több mint lenyűgöző eredményeket értünk el az IBM Data Power egyik kísérleti projektjéből, amely a Renaissance Credit Banknál fejeződött be: másodpercenként 40 kérést dolgoznak fel 5000 egyidejű kapcsolattal, és 1 kérés feldolgozási ideje kevesebb, mint 1 ms. Érdemes megjegyezni, hogy a CPU terhelés a tesztek során 5% volt!

Az IBM Data Power használata segít elválasztani az integrációs megoldás rétegeit az IBM WebSphere ESB és az IBM DataPower között, így amikor az IBM WebSphere ESB-t egy új integrációs busszal cseréli le, például az IBM Integration Busszal, akkor nem kell újra elkészítenie a részt. az IBM DataPower számára.

Ez a hibrid buszos megközelítés más gyártók termékei alapján is megvalósítható, pl. nem csak az IBM. Ugyanis sok gyártó termékeinek fejlesztése gyakran ugyanabba az irányba halad, de ez egy külön beszélgetés témája.

Hogyan nézzen ki egy integrációs adatbusz a közeljövőben?

Itt csak arra szeretném rávezetni, hogy az általam leírt javaslatok nagyon jól megfelelnek a gumiabroncs ötletének, amelyre, úgy gondolom, a jövőben kerül sor. A „hibrid” busz koncepciójának bevezetésével és a technológiák kombinálásával megoldást érünk el különféle integrációs problémákra. Sőt, mind a szoftverek kombinálásáról, mind a „tiszta” szoftverek szoftver- és hardverrendszerek segítségével történő hígításáról van szó.

Manapság nagyon nehéz egyetlen termékkel is kielégíteni egy vállalkozás összes követelményét. A régi, jól bevált „best of breed” elv tehát tökéletesen alkalmazható az integrált gumiabroncsokra.

Vegyünk több terméket, kombináljuk őket egy közös feladattal, válasszuk szét a komponenseket közöttük, „ültessétek” egy közös integrációs adatmodellre, és nem csak multifunkcionális megoldást kapnak, hanem meg is védik magukat a „termékfüggőségtől”.

Így találtunk kettőt egyszerű megoldások, amelyek mindegyikének megvannak a maga előnyei:

· Az IBM WebSphere ESB az IBM Integration Busszal kombinálva SOA platformok építésére, összetett alkalmazások és informatikai környezetek integrálására szolgál;

Nagy teljesítményű IBM termék A könnyű konfigurálhatósággal jellemezhető DataPower egyszerű kérések feldolgozására és többfunkciós biztonság biztosítására szolgál.

Kétségtelenül a hibrid buszok jelentik a jövőt, hacsak nincs adatbuszunk a felhőben, még ha ez most valószínűtlennek is tűnik. Erre a kérdésre egy-két év múlva visszatérünk. Egyetértesz?

A BPM-rendszerek blokkját itt szándékosan nem vettük figyelembe, mert. ez egy külön kiterjedt téma.