Vállalati buszjárat

Az enterprise service bus ( ESB ) egy köztes számítási módszer . Célja elsősorban az olyan alkalmazások kommunikációjának lehetővé tétele, amelyeket nem úgy terveztek, hogy működjenek együtt (például két integrált felügyeleti szoftvercsomag különböző kiadóktól).

Roy Schulte a Gartner Inc.- től a következőképpen írja le: „Az ESB egy új architektúra, amely kihasználja a webszolgáltatásokat, az üzenetközpontú rendszereket, az intelligens útválasztást és az átalakítást. Az ESB könnyű, mindenütt jelen lévő integrációs gerincként működik, amelyen keresztül a szoftveres szolgáltatások és az alkalmazás-összetevők áramlanak . ”

Az ESB a vállalati alkalmazásintegráció (EAI) új generációjának tekinthető, amely olyan szabványokra épül, mint az XML , a Java Message Service (JMS) vagy akár a webes szolgáltatások. A legfontosabb különbség az EAI-val szemben az, hogy az ESB teljes körűen elosztott integrációt kínál a szolgáltató konténerek használatával. Ezek a „mini-szerverek” tartalmazzák az integrációs logikát, és a hálózat bármely pontján eldobhatók.

Alapelvek

BSE mint közvetítő az ügyfelek és a szolgáltatást nyújtó az alapja a következő elvek alapján:

Az ESB kifejezést először a Sonic Software kiadó (a Progress Software Corporation leányvállalata) használta. Bizonyos szempontból az ESB-k az EAI fejlődését jelentik, különösen a nagy volumenű (a kezelések potenciálisan elosztva vannak) teljesítmény és a biztonság (a - központi forma lehetséges „egyetlen hibapont” elkerülése) miatt, bár a legújabb EAI / ESB javult ebben a két kérdésben.

Építészet

A buszszolgáltató vállalat, amint a neve is mutatja, olyan busz architektúrával rendelkezik, amely ellentétben áll az első EAI-k központjával és a küllős architektúrájával . Ez az ESB-t rendkívül elosztott megoldássá teszi. Ennek az architektúrának az összetevőit a következő ábra szemlélteti.

A BÉT-nek négy alapítványa van:

Hozzáadható ehhez az architektúrához:

Felhasználási eset

Alkalmazáson belüli használat

Ez egy korlátozott felhasználású eset, szinte mindig nyílt forráskódú ESB-vel, könnyű és könnyen kivitelezhető. Megtalálható olyan alkalmazásokban, amelyekben nagy az agilitás iránti igény, ami igazolja az ESB-n való átjutás okozta további teljesítményköltségeket, vagy a többprotokollos felületet kínáló alkalmazásokban (például fehér címkés szoftvercsomagokhoz); a szolgáltatási fogyasztói modul ezután egy másik alkalmazásban / rendszerben van.

Taktikai használat

A taktikai felhasználás megfelel annak az ESB-nek, amelyet egy entitáson / osztályon belül használnak annak érdekében, hogy az egész szervezet számára elérhetővé tegyék az újrafelhasználható szolgáltatásokat. A kiszolgáltatott szolgáltatások a következőkből származhatnak:

  1. Belső SOA architektúrán alapuló új alkalmazások (a szolgáltatások elérhetősége a jelenlegi szabványokon keresztül)
  2. Meglévő alkalmazások, amelyekben az alkalmazáskód egy részét újra felhasználják a szolgáltatások leleplezéséhez (a szolgáltatások ismertetése a jelenlegi szabványok alapján)
  3. Tól hagyományosoknak rendszerek , például mainframe vagy AS400 (kiállítási szolgáltatások specifikus csatlakozók)

Stratégiai felhasználás

A stratégiai elképzelés megfelel az ESB használatának a silók közötti kommunikáció megteremtésére, annak érdekében, hogy leleplezzék a transzverzális üzleti folyamatok által használt szolgáltatásokat. A taktikai nézetekhez hasonlóan a szolgáltatások különféle forrásokból származhatnak, vagy akár a taktikai BSE-ből, amely az egyes silókban létezhet.

Külső kommunikáció

Ebben a felhasználási esetben az ESB célja, hogy az üzleti tevékenységen kívüli szolgáltatásokat tárja fel. Az ilyen típusú használat során a biztonsági szempontokra különös figyelmet kell fordítani. Emiatt szokás nem belső (taktikai vagy stratégiai) ESB-t használni, hanem egy ESB-t a külsővel folytatott kommunikációra szánni. A külső kommunikációra szánt ESB általában egy DMZ-be kerül .

A BÉT érdekei

Fogalmak egységesítése ESB-kkel támogatás szabványok, mint az XML , JMS , JCA , Jmx és sok vonatkozó szabványok Web Services . Ez a meglévő rendszerek gyorsabb, gazdaságosabb és rugalmasabb integrációját jelenti. Intelligencia továbbítása Az ESB-k automatizálják az üzleti tranzakciók útvonalát az XML dokumentum tartalma és a bevett üzleti szabályok alapján. Ezért már nem szükséges ezt a funkciót beprogramozni az alkalmazáskódba. Szolgáltatás architektúrája Az ESB-k által biztosított funkciók különálló speciális szolgáltatásként valósulnak meg (átalakítási szolgáltatás, intelligens útválasztási szolgáltatás, naplózási szolgáltatás stb.). Ezek a kis konténerekben megvalósított szolgáltatások egymástól függetlenül, szelektív módon telepíthetők. Elosztott architektúra Az ESB szolgáltatásarchitektúrája sokkal több modularitással van elosztva, mint egy monolit architektúra, ami lehetővé teszi a pontos és rugalmas választ a méretezhetőségi kérdésekben felmerülő skálázhatósági igényekre . Megbízhatóság Az ESB-k lehetővé teszik az architektúrák egyedi meghibásodás nélküli felépítését (SPOF). Tehát amikor az egyik szerver leáll, a rendszer többi része tovább működhet. A telepítés rugalmassága Az ESB-k lehetővé teszik az elosztott konfigurációs, telepítési és felügyeleti szolgáltatások központosítását a vállalat egész területén. Ezenkívül lehetővé teszi a vállalat szolgáltatásainak egymástól független méretezését és kezelését. A megvalósítások átláthatósága lehetővé teszi a szolgáltatások frissítését, áthelyezését vagy cseréjét a kód megváltoztatása nélkül.

Szabványok

A BÉT a következő szabványokon alapulhat:

A JBI szabvány fontos, de nem nyeri el az összes játékos (különösen az IBM és a BEA) támogatását. Ezért a kiadók gyakran felajánlják saját szolgáltatási konténerüket.

Saját termékek

Ingyenes termékek

Lásd is

Megjegyzések és hivatkozások

  1. Enterprise Service Bus , David Chappell
  2. Gartner Inc. meghatározása
  3. "  Home - SRCI  " , az SRCI-n (hozzáférés : 2020. szeptember 13. ) .
  4. http://wso2.com/products/enterprise-service-bus/
  5. https://blog.octo.com/apache-camel-un-framework-pour-les-integrer-tous/
  6. https://zato.io/
  7. „  CodePlex Archive  ” , a CodePlex Archive-on (hozzáférés : 2020. szeptember 13. ) .
  8. (in) "  NServiceBus  " egy adott szoftver felett (hozzáférés: 2020. szeptember 13. ) .