Différences entre les passerelles API et les ESB? [fermé]

20

La société pour laquelle je travaille évalue des solutions middleware pour la gouvernance, le comptage et la sécurité des services Web. Actuellement, nous utilisons un bus de service d'entreprise (ESB) à cette fin, mais certains gars sympas de la gestion ont décidé de déployer un middleware de gestion d'API.

J'ai fait des recherches sur ces solutions de gestion des API (aka API Gateway) mais je n'ai pas pu trouver la différence entre elles et les ESB réels. J'ai évalué certains livres blancs de Mule, WSO2, Oracle, etc., mais les fonctionnalités offertes par les deux produits semblent être presque les mêmes. La question est, que peut faire une gestion d'API qu'un ESB ne peut pas faire et vice versa? Quelle valeur peut être ajoutée à une infrastructure informatique en remplaçant un ESB pour une passerelle API?

integration middleware dliber
la source
4
En quoi la question «Quelle est la différence entre une passerelle API et un ESB» est-elle hors sujet pour une discussion en génie logiciel?
Francisco d'Anconia

Réponses:

21

La raison pour laquelle vous obtenez les concepts mélangés est que les vendeurs les vendent dans un package. Mais ce sont certainement des concepts distincts.

Une passerelle API fournit un point d'accès central pour gérer, surveiller et sécuriser l'accès à vos services Web exposés publiquement. Cela vous permettrait également de consolider les services sur des points de terminaison disparates comme s'ils venaient tous d'un seul hôte. Par exemple, supposons que vous disposiez de dix points de terminaison de service différents qui faisaient tous partie d'une seule "suite" de services. Plutôt que d'informer les consommateurs de votre service d'utiliser service1.yourcompany.com pour un service et service2.yourcompany.com pour un autre et ainsi de suite, vous pouvez plutôt les faire tous pointer vers api.yourcompany.com/service1 ou api.yourcompany.com / service2 et la passerelle seraient responsables de la redirection des demandes vers les points de terminaison appropriés.

Un ESB est un «bus» interne qui permet aux applications et aux services de communiquer entre eux de manière non couplée. Toutes les applications peuvent se connecter au bus et recevoir tout message les intéressant lorsqu'elles sont publiées par une autre application. Ils peuvent également publier leurs propres messages qu'une autre application peut écouter et répondre. Les applications ne sont pas responsables de la connexion directe entre elles, elles publient leurs messages sur le bus et toutes les parties intéressées écoutent et réagissent.

Logiquement, la passerelle API n'est pas un remplacement pour un ESB mais plutôt une amélioration pour une architecture orientée services.

Michael Brown
la source
1
Je pense que l'argument en faveur de l'utilisation des ESB est le même. Les ESB sont des points d'accès centraux et peuvent effectuer l'équilibrage de charge, la surveillance, la mesure et la sécurité des services à partir de différents points de terminaison. Vous pouvez également transmettre l'URL de l'ESB aux consommateurs au lieu de l'URL des services individuels. Jusqu'à présent, rien de nouveau.
dliber
ESB est une API Gateway interne destinée à une consommation externe.Si vous souhaitez utiliser une API Gateway en interne au lieu d'un ESB, je suppose qu'il n'y a rien pour vous arrêter.
Michael Brown
C'est exactement le point. Il existe un chevauchement des fonctionnalités des ESB et des plates-formes d'API. Vous pouvez déployer un ESB pour l'accès externe ou une plate-forme API pour l'accès interne. Si leurs fonctionnalités sont les mêmes, quel est l'avantage d'utiliser l'un au lieu de l'autre? Qu'est-ce qui les rend si différents pour que vous puissiez utiliser l'un au lieu de l'autre (ou les deux ensemble) et apporter une réelle valeur ajoutée à votre entreprise?
dliber
Une chose qu'un ESB est conçu pour un trafic à volume élevé. Il possède généralement un protocole propriétaire ou non compatible avec Internet. Une passerelle API est conçue pour traduire entre les protocoles Internet (SOAP, JSON, XML, HL7) et placer les requêtes sur l'ESB. Fondamentalement, vous POUVEZ utiliser la passerelle pour les communications entre vos services internes, ce qui ne la rend pas nécessairement la plus adaptée.
Michael Brown