Enterprise busstjeneste

Den enterprise service bus ( ESB ) er en mellomvaredatabehandlingsteknikk . Hensikten er fremfor alt å tillate kommunikasjon av applikasjoner som ikke er designet for å fungere sammen (for eksempel to integrerte programvarepakker for administrasjon fra forskjellige utgivere).

Roy Schulte fra Gartner Inc. beskriver det slik: “ESB er en ny arkitektur som utnytter webtjenester, meldingsorienterte systemer, intelligent ruting og transformasjon. ESB fungerer som en lett, allestedsnærværende integrasjonsgraden som programvaretjenester og applikasjonskomponenter flyter gjennom . ”

ESB kan betraktes som en ny generasjon av enterprise application integration (EAI) bygget på standarder som XML , Java Message Service (JMS) eller til og med webtjenester. Den største forskjellen med EAI er at ESB tilbyr full distribuert integrering gjennom bruk av servicecontainere. Disse “mini-serverne” inneholder integreringslogikken og kan slippes av hvor som helst i nettverket.

Prinsipper

BSE som megler mellom klienter og tjenesteleverandører er basert på følgende prinsipper:

Begrepet ESB ble først brukt av utgiveren Sonic Software (et datterselskap av Progress Software Corporation). På en måte utgjør ESBs en evolusjon av EAI, spesielt på grunn av ytelse i tilfelle store volumer (behandlingene er potensielt distribuert) og sikkerhet (unngå potensialet 'Single Point of failure' i en sentral form), selv om de siste EAI / ESB har forbedret disse to problemene.

Arkitektur

Busselskapet har, som navnet antyder, en bussarkitektur som kontrasterer den med navet og snakearkitekturen til de første EAIene . Dette gjør ESB til en høyt distribuert løsning. Komponentene i denne arkitekturen er illustrert i følgende figur.

BSE har fire fundament:

Kan legges til i denne arkitekturen:

Bruk sak

Bruk innen applikasjon

Dette er en begrenset brukssak, nesten alltid implementert med en åpen kildekode ESB, lett og enkel å implementere. Det finnes i applikasjoner med et sterkt behov for smidighet, noe som rettferdiggjør de ekstra ytelseskostnadene som er forårsaket av å gå gjennom en ESB, eller i applikasjoner som tilbyr et flerprotokollgrensesnitt (for for eksempel programvarepakker med merkelapper) tjenesteforbrukermodulen er da i et annet program / system.

Taktisk bruk

Taktisk bruk tilsvarer en ESB som brukes i en enhet / avdeling for å gjøre gjenbrukbare tjenester tilgjengelige for hele enheten. De utsatte tjenestene kan komme fra:

  1. Nye applikasjoner basert på en intern SOA- arkitektur (eksponering av tjenester via gjeldende standarder)
  2. Eksisterende applikasjoner der en del av applikasjonskoden blir gjenbrukt for å eksponere tjenester (eksponering av tjenester via gjeldende standarder)
  3. Fra legates systemer som mainframes eller AS400 (utstillingstjenester gjennom spesifikke kontakter)

Strategisk bruk

Den strategiske visjonen tilsvarer bruken av ESB for å etablere kommunikasjon mellom siloer, for å avsløre tjenester som brukes av tverrgående forretningsprosesser. Som med det taktiske synet, kan tjenester komme fra en rekke kilder, eller til og med fra den taktiske BSE som kan eksistere i hver av siloene.

Ekstern kommunikasjon

I dette brukstilfellet er ESB ment å eksponere tjenester for bruk utenfor virksomheten. Ved denne typen bruk må sikkerhetsaspektene være gjenstand for særlig oppmerksomhet. Av denne grunn er det vanlig å ikke bruke en intern ESB (taktisk eller strategisk), men å dedikere en ESB for kommunikasjon med utsiden. En ESB for ekstern kommunikasjon vil vanligvis bli plassert i en DMZ .

BSE interesser

Standardisering av begreper ESB støtter standarder som XML , JMS , JCA , JMX og mange standarder knyttet til webtjenester . Dette innebærer en raskere, mer økonomisk og mer fleksibel integrering av systemene på plass. Ruteinformasjon ESB automatiserer ruting av forretningstransaksjoner basert på XML- dokumentinnhold og etablerte forretningsregler. Det er derfor ikke lenger nødvendig å programmere denne funksjonaliteten i applikasjonskoden. Tjenestearkitektur Funksjonalitetene som tilbys av ESBene er implementert som distinkte spesialiserte tjenester (transformasjonstjeneste, intelligent rutetjeneste, loggtjeneste osv.). Disse tjenestene implementert i små containere kan distribueres uavhengig av hverandre, på en selektiv basis. Distribuert arkitektur ESB-servicearkitekturen er distribuert med mye mer modularitet enn en monolitisk arkitektur, noe som gjør det mulig å gi en presis og fleksibel respons på skalerbarhetsbehovene i skalerbarhetsproblemer . Pålitelighet ESBer gjør det mulig å bygge arkitekturer uten individuelt feilpunkt (SPOF). Så når en server går ned, kan resten av systemet fortsette å fungere. Fleksibilitet i distribusjon ESB-er gir muligheten til å sentralisere distribuert konfigurasjon, distribusjon og administrasjonstjenester på tvers av virksomheten. I tillegg tillater det å skalere og administrere tjenestene til selskapet uavhengig av hverandre. Gjennomsiktigheten til implementeringene gjør at tjenester kan oppgraderes, flyttes eller erstattes uten å måtte endre koden.

Standarder

BSE kan være basert på følgende standarder:

JBI- standarden er viktig, men vinner ikke støtte fra alle spillere (spesielt IBM og BEA). Av denne grunn tilbyr utgivere ofte sin egen servicecontainer.

Proprietære produkter

Gratis produkter

Se også

Merknader og referanser

  1. Enterprise Service Bus , David Chappell
  2. Definisjon fra Gartner Inc.
  3. "  Hjem - SRCI  " , på SRCI (åpnet 13. september 2020 ) .
  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  ” , på CodePlex Archive (åpnet 13. september 2020 ) .
  8. (in) "  NServiceBus  " over bestemt programvare (åpnet 13. september 2020 ) .