Differenze tra gateway API ed ESB? [chiuso]

Chiuso. Questa domanda è fuori tema . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che sia in argomento per Software Engineering Stack Exchange.

Chiuso 5 anni fa .

La società per cui lavoro sta valutando alcune soluzioni middleware per la governance, la misurazione e la sicurezza dei servizi web. Attualmente stiamo utilizzando un Enterprise Service Bus (ESB) per questo scopo, ma alcuni bravi ragazzi del management hanno deciso di implementare un middleware di gestione API.

Ho studiato un po 'queste soluzioni di gestione API (aka API Gateway) ma non sono riuscito a trovare la differenza tra loro e gli ESB effettivi. Ho valutato alcuni white paper di Mule, WSO2, Oracle ecc., Ma le funzionalità offerte da entrambi i prodotti sembrano essere quasi le stesse. La domanda è: cosa può fare una gestione API che un ESB non può fare e viceversa? Quale valore può essere aggiunto a un'infrastruttura IT sostituendo un ESB per un gateway API?

integration middleware

— dliber
fonte

Qual è la domanda "Qual è la differenza tra un gateway API e un ESB" fuori tema per una discussione di ingegneria del software?

— Francisco d'Anconia,

Il motivo per cui si stanno confondendo i concetti è che i venditori li vendono in un pacchetto. Ma sono sicuramente concetti separati.

Un gateway API fornisce un punto di accesso centrale per la gestione, il monitoraggio e la protezione dell'accesso ai servizi Web esposti pubblicamente. Consentirebbe inoltre di consolidare i servizi su endpoint diversi come se provenissero tutti da un singolo host. Ad esempio, supponiamo che tu abbia avuto dieci diversi endpoint di servizio che facevano tutti parte di una singola "suite" di servizi. Invece di informare i consumatori del tuo servizio di utilizzare service1.yourcompany.com per un servizio e service2.yourcompany.com per un altro e così via, puoi invece farli puntare a api.yourcompany.com/service1 o api.yourcompany.com / service2 e il gateway sarebbero responsabili del reindirizzamento delle richieste agli endpoint appropriati.

Un ESB è un "bus" interno che consente alle applicazioni e ai servizi di comunicare tra loro in modo non accoppiato. Tutte le applicazioni possono essere agganciate al bus e possono ricevere qualsiasi messaggio che le interessa quando pubblicate da un'altra applicazione. Possono anche pubblicare i propri messaggi che un'altra applicazione può ascoltare e rispondere. Le applicazioni non sono responsabili della connessione diretta tra loro, pubblicano i loro messaggi sul bus e tutte le parti interessate ascoltano e reagiscono.

Logicamente, il gateway API non sostituisce un ESB, ma piuttosto un miglioramento per un'architettura orientata ai servizi.

— Michael Brown
fonte

Credo che l'argomento per l'utilizzo degli ESB sia lo stesso. Gli ESB sono punti di accesso centrali e possono eseguire il bilanciamento del carico, il monitoraggio, la misurazione e la sicurezza dei servizi da endpoint diversi. È inoltre possibile trasmettere agli utenti l'URL dell'ESB anziché l'URL dei singoli servizi. Finora, niente di nuovo.

— Dliber

ESB è il gateway API interno è destinato al consumo esterno. Se si desidera utilizzare un gateway API internamente anziché un ESB, suppongo che non ci sia nulla che ti fermi.

— Michael Brown,

Questo è esattamente il punto. Esiste una sovrapposizione di funzionalità di ESB e piattaforme API. È possibile distribuire un ESB per l'accesso esterno o una piattaforma API per l'accesso interno. Se le loro caratteristiche sono le stesse, quali sono i vantaggi dell'utilizzo dell'uno anziché dell'altro? Cosa li rende così diversi da permetterti di utilizzare l'uno anziché l'altro (o entrambi insieme) e fornire valore reale alla tua azienda?

— Dliber

Una cosa che un ESB è progettato per traffico ad alto volume. Di solito ha un protocollo proprietario o non internet. Un gateway API è progettato per tradurre tra i protocolli Internet (SOAP, JSON, XML, HL7) e collocare le richieste su ESB. Fondamentalmente, PUOI utilizzare il gateway per le comunicazioni tra i tuoi servizi interni, che non lo rende necessariamente il migliore.

— Michael Brown,