Escuché hablar sobre NServiceBus , pero realmente no he entendido qué es. Afirman ser "El bus de servicios de código abierto más popular para .net".
Entonces; ¿Qué es un "autobús de servicio" y cuándo lo necesito?
Escuché hablar sobre NServiceBus , pero realmente no he entendido qué es. Afirman ser "El bus de servicios de código abierto más popular para .net".
Entonces; ¿Qué es un "autobús de servicio" y cuándo lo necesito?
Respuestas:
Puede pensar en un bus de servicio como Ethernet de SOA.
En primer lugar, introduce un lenguaje de identificación de cosas, como una dirección IP en Ethernet. Este nombre no es algo inherentemente físico.
A continuación, tiene algo físico involucrado en cada nodo, como una cola en el caso de un bus para admitir comunicaciones semiconectadas, o una tarjeta Ethernet en la metáfora.
Más allá de lo físico, existe la parte de "protocolo" de la comunicación, como la pila OSI para Ethernet. Con el bus, estas son las bibliotecas cliente utilizadas por el código de la aplicación.
En última instancia, puede considerar que un bus de servicio proporciona el siguiente nivel superior de abstracción para la construcción de sistemas distribuidos. También puede usarlo para la comunicación cliente-servidor para brindarle mensajería unidireccional duradera, así como para que el servidor envíe notificaciones al cliente.
Específicamente, encontrará que NServiceBus es bastante liviano y fácil de usar una vez que haga las paces con el uso de la tecnología de cola: su elección de RabbitMQ, MSMQ, tablas SQL regulares, Amazon SQS, Azure Storage Queues y Azure Service Bus.
Consulte el artículo de Wikipedia sobre Enterprise Service Bus .
Un Service Bus actúa como una capa más de abstracción en la búsqueda interminable de implementar una buena Arquitectura Orientada a Servicios. El Service Bus puede manejar parte del trabajo pesado que se encuentra detrás de una buena arquitectura orientada a servicios como mensajería, enrutamiento y coordinación de servicios.
Si no está seguro de por qué querría algo así, le sugiero que lea sobre lo que hace una buena arquitectura orientada a servicios. El libro que realmente me abrió los ojos y demostró la diferencia entre solo tener servicios web y tener una verdadera arquitectura orientada a servicios fue la arquitectura orientada a servicios de Thomas Erl : conceptos, tecnología y diseño.
Este término se introdujo con SOA, que en cierto modo es el sucesor (como palabra de moda ) de EAI .
¿Cuándo lo necesitas? Buena pregunta. Viene con mucha complejidad.
Una regla empírica podría funcionar si resuelve más problemas de los que causa.
Ser serio si tiene un entorno heterogéneo y desea alinear (diferentes) aplicaciones (utilizando diferentes tecnologías) con los procesos comerciales. Entonces podría ser útil usar BPEL (pero esto presenta problemas por migración) para orquestación y coreografía.
EDITAR: Lo que no está en wikipedia, es práctica: un ESB puede adaptarse usando conectores especiales, aplicaciones de terminal antiguas para usar con Corba o Java Enterprise, eso es lo que se entiende por interoperabilidad. El inconveniente son los más de 100 "estándares" en torno a SOAP que no cooperan sin un enorme esfuerzo.
Definitivamente lo necesita si tiene que interconectar sistemas de TI dentro de los seis meses posteriores a la fusión de 2 grandes compañías de seguros.