Estoy creando una solución para consumir diferentes servicios (o API) de diferentes sitios web populares. ¿Debo usar un ESB?

Answer 1

Personalmente, mi principal intuición es “depende de la naturaleza y dirección del flujo de datos”.

Déjame elaborar. Los ESB hacen que sea realmente fácil lidiar con el protocolo y la transformación o traducción de datos. Por ejemplo, puede hacer que un ESB escuche en un socket personalizado con un protocolo propietario en un extremo, y luego lo traduzca en llamadas RESTful API a través de HTTP a otro servicio en el otro extremo. O bien, puede hacer que sondee una carpeta o un buzón de correo electrónico y luego envíe un mensaje JMS cada vez que llegue un nuevo archivo o correo electrónico.

En cualquier caso, la dirección es hacia el ESB, luego hacia otro servicio. El ESB tiene que estar siempre encendido, escuchando constantemente o sondeando y barajando mensajes de aquí para allá.

Al consumir servicios web y API populares (como Facebook o Google), por experiencia, es la aplicación la que inicia la conexión, envía algunos comandos o datos y recibe una respuesta en la misma conexión. Por supuesto, hay excepciones en las que las respuestas no son “en banda” y se espera que su aplicación proporcione un servicio web propio como devolución de llamada.

En general, sin embargo, es la aplicación la que envía cosas a la API y luego devuelve los datos.

En tales casos, para reducir la complejidad de lidiar con múltiples API similares, es suficiente tener una capa de abstracción para proteger su aplicación de los detalles de cada API. Piense en cómo funcionan ODBC o JDBC: presentan una API unificada y abstracta para bases de datos relacionales, y en su mayor parte su aplicación puede funcionar con PostgreSQL, MS SQL Server, MySQL u Oracle sin tener que conocer el protocolo de línea de cada uno.

Si eso es todo lo que necesita, entonces diría que un ESB es innecesario. Si bien puede mantener las conexiones abiertas (y agrupadas, para el rendimiento), en general las llamadas a la API son bajo demanda y están bajo el control de la aplicación.

Sí, puede tener un ESB ejecutándose entre su aplicación y los servicios de terceros para realizar la transformación y la traducción. Incluso puede ejecutar algunos ESB integrados en su aplicación (no es necesario un proceso independiente o abrir sockets).

Pero a menos que el ESB tenga filtros o transformadores listos para usar, entonces estará escribiendo el código para abstraer las llamadas API de todos modos, así que realmente no veo la necesidad de la complejidad adicional del marco ESB.

La abstracción de API y la transformación de datos no es tan difícil de escribir a mano (y un diseño adecuado puede ser más elegante y eficaz para su dominio particular que las abstracciones genéricas), y existen bibliotecas existentes para crear y administrar grupos de recursos si los necesita.

tl; dr: a menos que el ESB tenga claramente componentes que pueda usar de fábrica (o proporcionados por proveedores externos), entonces probablemente no tenga la pieza arquitectónica adicional.