Servizio di autobus aziendale

L' Enterprise Service Bus ( ESB ) è una tecnica di elaborazione middleware . Il suo scopo è soprattutto quello di consentire la comunicazione di applicazioni che non sono state progettate per funzionare insieme (ad esempio due pacchetti software di gestione integrata di diversi editori).

Roy Schulte di Gartner Inc. lo descrive come segue: “ESB è una nuova architettura che sfrutta servizi web, sistemi orientati ai messaggi, instradamento e trasformazione intelligenti. ESB funge da spina dorsale di integrazione leggera e onnipresente attraverso la quale fluiscono i servizi software e i componenti delle applicazioni " .

ESB può essere considerato come una nuova generazione di Enterprise Application Integration (EAI) costruita su standard come XML , Java Message Service (JMS) o anche servizi web. La principale differenza con EAI è che ESB offre un'integrazione completamente distribuita attraverso l'uso di contenitori di servizi. Questi "mini-server" contengono la logica di integrazione e possono essere rilasciati ovunque sulla rete.

I principi

La BSE come mediatore tra clienti e fornitori di servizi si basa sui seguenti principi:

Il termine ESB è stato utilizzato per la prima volta dall'editore Sonic Software (una sussidiaria di Progress Software Corporation). In un certo senso, gli ESB costituiscono un'evoluzione degli EAI, in particolare per motivi di performance in caso di grandi volumi (i trattamenti sono potenzialmente distribuiti) e di sicurezza (evitando il potenziale 'Single Point of failure' di a - modulo centrale), sebbene i più recenti EAI / ESB hanno migliorato questi due problemi.

Architettura

La società di servizi di autobus ha, come suggerisce il nome, un'architettura di autobus che la contrasta con l'architettura hub e spoke dei primi EAI . Ciò rende ESB una soluzione altamente distribuita. I componenti di questa architettura sono illustrati nella figura seguente.

La BSE ha quattro basi:

Può essere aggiunto a questa architettura:

Caso d'uso

Uso intra-applicazione

Questo è un caso d'uso limitato, quasi sempre implementato con un ESB open source, leggero e facile da implementare. Si trova in applicazioni con una forte esigenza di agilità, che giustifica il costo aggiuntivo delle prestazioni causato dal passaggio attraverso un ESB, o in applicazioni che offrono un'interfaccia multiprotocollo (per pacchetti software white label, ad esempio); il modulo consumatore del servizio si trova quindi in un'altra applicazione / sistema.

Uso tattico

L'uso tattico corrisponde a un ESB utilizzato all'interno di un'entità / dipartimento al fine di rendere disponibili servizi riutilizzabili per l'intera entità. I servizi esposti possono provenire da:

  1. Nuove applicazioni basate su un'architettura SOA interna (esposizione dei servizi tramite gli standard attuali)
  2. Applicazioni esistenti in cui parte del codice dell'applicazione viene riutilizzata per esporre i servizi (esposizione dei servizi tramite gli standard attuali)
  3. Dai sistemi dei legatari come mainframe o AS400 (servizi espositivi tramite connettori specifici)

Uso strategico

La visione strategica corrisponde all'utilizzo di ESB per stabilire la comunicazione tra silos, al fine di esporre i servizi utilizzati dai processi aziendali trasversali. Come per la visione tattica, i servizi possono provenire da una varietà di fonti, o anche dalla BSE tattica che può esistere in ciascuno dei silos.

Comunicazione esterna

In questo caso d'uso, l'ESB ha lo scopo di esporre i servizi per l'utilizzo al di fuori dell'azienda. In questo tipo di utilizzo, gli aspetti di sicurezza devono essere oggetto di particolare attenzione. Per questo motivo, è consuetudine non utilizzare un ESB interno (tattico o strategico), ma dedicare un ESB per le comunicazioni con l'esterno. Un ESB per la comunicazione esterna verrà solitamente posizionato in una DMZ .

Interessi della BSE

Standardizzazione dei concetti Gli ESB supportano standard come XML , JMS , JCA , JMX e molti standard relativi ai servizi Web . Ciò implica un'integrazione più rapida, più economica e più flessibile dei sistemi in atto. Intelligenza di instradamento Gli ESB automatizzano l'instradamento delle transazioni commerciali in base al contenuto del documento XML e alle regole aziendali stabilite. Non è quindi più necessario programmare questa funzionalità nel codice dell'applicazione. Architettura del servizio Le funzionalità fornite dagli ESB sono implementate come servizi specializzati distinti (servizio di trasformazione, servizio di routing intelligente, servizio di registrazione, ecc.). Questi servizi implementati in piccoli contenitori possono essere distribuiti indipendentemente l'uno dall'altro, in modo selettivo. Architettura distribuita L'architettura del servizio ESB è distribuita con molta più modularità rispetto a un'architettura monolitica, il che consente di fornire una risposta precisa e flessibile alle esigenze di scalabilità riscontrate nei problemi di scalabilità . Affidabilità Gli ESB consentono di creare architetture senza SPOF ( individual point of failure ). Quindi, quando un server si arresta, il resto del sistema può continuare a funzionare. Flessibilità di implementazione Gli ESB offrono la possibilità di centralizzare i servizi di configurazione, distribuzione e gestione distribuiti in tutta l'azienda. Inoltre, consente di scalare e gestire i servizi dell'azienda indipendentemente l'uno dall'altro. La trasparenza delle implementazioni consente di aggiornare, spostare o sostituire i servizi senza dover modificare il codice.

Standard

La BSE può essere basata sui seguenti standard:

Lo standard JBI è importante, ma non ottiene il supporto di tutti i giocatori (IBM e BEA in particolare). Per questo motivo, gli editori spesso offrono il proprio contenitore di servizi.

Prodotti proprietari

Prodotti gratuiti

Vedi anche

Note e riferimenti

  1. Enterprise Service Bus , David Chappell
  2. Definizione di Gartner Inc.
  3. "  Home - SRCI  " , su SRCI (accesso 13 settembre 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  " , su CodePlex Archive (accesso 13 settembre 2020 ) .
  8. (in) "  NServiceBus  " su Particular Software (accesso 13 settembre 2020 ) .