Diferencia entre el sistema RPC y Enterprise Service Bus

Question

¿Cuál es la diferencia entre un sistema RPC, como Twitter Finagle, y un Enterprise Service Bus, como Mule? ¿Qué tipo de problemas son buenos para resolver?

Answer 1

voy a tratar de responder a esta como una explicación suave, en lugar de una avería técnica de características:

Se puede decir que Finagle es una biblioteca de mensajería asíncrona que permite que los servicios se conecten entre sí libremente (sin estar estrechamente ligados a los estándares de integración del sistema arquitectónico) al tiempo que admiten múltiples protocolos.

Desde el Finagle página web:

Finagle es una pila de red para la JVM que se puede utilizar para construir asíncrona llamada a procedimiento remoto (RPC) de los clientes y servidores en Java, Scala, o cualquier lenguaje de JVM-organizada . Finagle proporciona un amplio conjunto de herramientas independientes del protocolo.

Un Enterprise Service Bus (ESB), por otro lado, es una arquitectura de mensajería asíncrona que normalmente cumple con los estándares y protocolos de la industria. Un ESB promueve un sistema donde el flujo de mensajes es controlado y enrutado entre sistemas, y donde los servidores pueden registrar su servicio y los clientes pueden registrar qué mensajes les interesan. Los servicios ofrecidos por los servidores pueden registrarse y versionarse.

Por lo general, encontrará que Finagle se usa en algún lugar entre un sitio web y servicios de back-end. Pero, normalmente encontrará un ESB dentro de una gran empresa, donde es responsable de integrar sistemas como finanzas, soporte, ventas, etc.

Ambas soluciones ofrecen mensajería asíncrona y almacenamiento en memoria intermedia para varias extensiones, pero no están diseñadas para resolver el el mismo problema. Para ESB, probablemente pienses 'estricto, empresarial', pero para Finagle probablemente pienses 'flexible, web'.

Esperanza esto ayuda

Actualización:

No del todo relacionado, pero si usted está explorando este espacio, me gustaría ver Kafka estos días.

Answer 2

Tanto resolver problemas completamente diferentes:

• Un ESB es un middleware intermediación que proporciona transformación de mensaje y de encaminamiento, de adaptación de protocolos y otras operaciones de valor añadido (como orquestación, entrega garantizada, filtrado idempotente ...) . Se ubica entre sus consumidores y proveedores de servicios y de forma transparente (es decir, sin ningún cambio en el consumidor o proveedor) proporciona sus diferentes características.
• Un sistema RPC proporciona tecnologías de cliente y servidor para realizar operaciones RPC.

Answer 3

RPC y ESB son dos patrones arquitectónicos. Si bien RPC suele ser una solicitud-respuesta y de naturaleza síncrona, un ESB trabaja sobre el concepto de mensajería (explicación simplificada) y de naturaleza asincrónica. ESB es la base de cualquier implementación de SOA. ESB permite el acoplamiento flojo promoviendo así una verdadera agilidad. Un ejemplo simplificado desde la perspectiva de implementación es el siguiente:

Un servicio web es un RPC típico. El consumidor está estrechamente vinculado al productor y cualquier cambio en el contrato por parte del productor requerirá cambios en el lado del consumidor.

En ESB, el consumidor del servicio no invoca directamente al productor del servicio. Simplemente coloca el mensaje en el bus y, de acuerdo con las reglas (mediador), el productor del servicio apropiado lo manejará. Si el consumidor del servicio y el productor del servicio hablan en diferentes formatos, ESB ofrece la posibilidad de realizar la transformación (como formatear el código postal como xxxxx-xxxx, dividir el nombre en nombre y apellido, etc.).

Esto es solo una explicación simplificada. Para obtener más información, consulte los siguientes enlaces:

Why do developers need an Enterprise Service Bus?

Enterprise Service Bus