Beneficios de un bus de servicio empresarial

Question

¿Dónde puedo encontrar información sobre los usos y beneficios de un bus de servicios empresariales (ESB)?

Estoy buscando información sobre:

1. Los tipos de problemas que ESB ayuda a resolver.
2. Las alternativas a un ESB y las compensaciones al seleccionar entre ellas.
3. lo que debe hacer como desarrollador para crear sistemas compatibles con ESB

Busco un nivel de detalle más fino que solo Wikipedia o folletos de marketing en línea de los proveedores.Idealmente, algún código de ejemplo ayudaría a aclarar lo que implica aprovechar un ESB.La información desde una perspectiva .NET o Java sería la más útil.

Gracias.

Answer 1

Para ESB o no a ESB para empezar, escrito por el creador de mula .

Answer 2

ESB son una buena manera de poner en práctica .

tipos de problemas que un ESB ayuda a resolver

• Usted tiene un número de protocolos desea normalizar a un único protocolo (por ejemplo, FTP, correo electrónico, SOAP, XMPP, etc, para un sistema de mensajería), por ejemplo, ActiveMQ. Esto le permite desacoplar la implementación de los servicios de protocolo.
• ¿Quieres una manera consistente para conectar los servicios en esta arquitectura para que puedan escuchar los mensajes, mensajes de proceso y generar mensajes (Mensaje puntos finales, adaptadores de canal, etc.).
• Es posible que desee un recipiente logrado implementar estos diversos componentes en (por ejemplo ServiceMix, Mule)
• Es posible que desee una serie de componentes prediseñados y adaptadores en varios protocolos (por ejemplo ServiceMix, Mula y Camel tienen una gran cantidad de componentes prediseñados).
• Usted puede requerir flujos de trabajo de larga ejecución. Gestión de procesos de negocio es a menudo algo que se proporciona junto con un ESB (Apache ODE se conecta a un número de código abierto ESB).

Alternativas a un ESB

Las alternativas dependen en realidad el problema que estamos tratando de resolver.

• Para proporcionar servicios distribuidos, la gente suele utilizar servidores de aplicaciones que exponen servicios a través de algún punto a punto protocolo RPC (como EJB más de RMI o Servicios Web a través de HTTP). Así, en lugar de poner un mensaje en un 'bus', un cliente llama directamente a un servidor.
• Para responder a protocolos específicos, sólo podría construir un cliente que responde a dicho protocolo, por ejemplo, escribir una aplicación que escucha los mensajes de correo electrónico con JavaMail o uno que escucha XMPP usando Smack. Si su problema está limitado a uno o dos protocolos no puede valer la pena traer a un ESB completa.

Lo que hay que hacer como desarrollador para construir sistemas compatibles ESB-

Esto dependerá de la ESB selecciona, aunque dado que la mayoría de los buenos están diseñados para llamar a cabo en todo tipo de protocolos, así como POJOs anfitrionas, no hay mucho que debe necesita hacer construir sistemas compatibles ESB . Vale la pena tratar de hacer que su código asíncrono.

Para ejemplos, Apache Camel tiene probablemente la configuración más sucinta, aquí hay un tutorial .

Answer 3

tres ventajas clave:

• Un autobús ofrece una manera para que los puntos finales conectarse entre sí sin tener que hablar directamente entre sí. Es simplifica las comunicaciones de los criterios de valoración, ya que sólo tienen que ajustarse a una interfaz de comunicación estándar, el bus. (Esto es con cualquier técnica de autobuses, no sólo ESB)
• Un ESB proporciona un solo lugar para obtener algunas métricas clave de punto final:. La frecuencia, la disponibilidad y el rendimiento
• Un ESB tiende a proporcionar más de una interfaz de comunicación. Sin embargo, un desarrollador sólo tiene que elegir el que más fácil de obtener y recibir los datos desde el bus.

Sin embargo, asegúrese de que los proporcionará valor de negocio para su situación. Tener un ESB es añadir otro complejidad a su empresa. Lo ideal es que no debe elegir esta basado en unas pocas aplicaciones, pero toda la organización. Sólo debe haber un la producción en agrupaciones ESB para la organización.

Alternativas:

• Sólo tiene que conectar las cosas entre sí directamente, especialmente si los protocolos de comunicación son los mismos. Esto es bueno para los clústeres de aplicación sencilla y no requiere pensar demasiado. Sin embargo, como su número de aplicaciones crezca, el mantenimiento de las interconexiones se hace difícil.
• Otra alternativa es una aplicación MQ. Esto le proporcionará una manera de empujar a los datos sin tener en torno a las interconexiones complejas, pero luego se ven obligados a usar sólo un canal de comunicación. Afortunadamente para Java, tienen el estándar JMS.

La practicidad:

he indicado las posibles alternativas. Pueden parecer mal al principio, pero no quiere decir que no se puede empezar de esa manera. Personalmente, escribo cosas para hablar con el control remoto directamente sin pasar por un ESB para asegurarse de que funciona sin tener que preocuparse demasiado acerca de los problemas de integración.

Si usted no tiene un ESB, le sugiero que trate mula para el desarrollo y WebSphere ESB para la prueba y producción. Yo tiendo a usar dos productos que supuestamente siguen las normas para asegurarnos de mantener los vendedores honestos y asegurarse de que sus promotores son conformes a las normas que impiden inadvertida dependencia de un proveedor.

Al final, simplemente responder a la siguiente pregunta: ¿Es el momento de añadir el bit de complejidad para simplificar otras complejidades su empresa vale la pena el costo en el largo plazo

Answer 4

Además de los sitios que ya se han mencionado. Usted debe leer este artículo sobre " No utilice un ESB, a menos que sea absolutamente necesario ". Fue escrito por el director de tecnología de MuleSource, uno de la fuente abierta más popular del ESB disponible. No es exactamente una respuesta a su pregunta, más de hacer un punto a preguntarse "¿Necesito un ESB"?

Answer 5

Hay una decente serie de 3 partes más en IBM respecto ESB que está orientado bastante concepto y proveedores específicos (en su mayor parte). He encontrado un montón de cosas buenas en ESB por hurgar sitio de IBM. También hay algo de información decente y vídeos y otras cosas más en el href="http://www.microsoft.com/biztalk/en/us/esb-guidance.aspx" rel="nofollow noreferrer"> sitio de BizTalk .

Answer 6

Consulte esta Hanselminutes podcast de . Responde a algunas preguntas que realmente debería preguntarse antes de la implementación de un bus de servicio.

Answer 7

Un bus de servicios empresariales (ESB) es una arquitectura de software de middleware que proporciona servicios fundamentales para arquitecturas más complejas. Por ejemplo, un ESB incorpora las funciones necesarias para implementar una arquitectura orientada al servicio (SOA). En un sentido general, un ESB puede ser pensado como un mecanismo que gestiona el acceso a aplicaciones y servicios (especialmente las versiones anteriores) para presentar una interfaz única, simple y consistente a través del lado del cliente basada en formularios Web o de los usuarios finales extremos delanteros.

En esencia, ESB hace para servicios distribuidos heterogéneos de back-end y las aplicaciones y los usuarios de front-end heterogéneos distribuidos y consumidores de información lo que el middleware se supone realmente que hacer: ocultar la complejidad, simplificar el acceso, permitirá a los desarrolladores usar formas genéricas, canónicas de consulta , el acceso y la interacción, el manejo de los datos complejos en el fondo. La clave del atractivo de ESB, y posiblemente también su éxito en el futuro, reside en su capacidad para apoyar la integración de servicios y la aplicación gradual como impulsada por los requerimientos del negocio, no como gobernado por la tecnología disponible.

http://searchsoa.techtarget.com/definition/enterprise-service-bus

Enterprise Service Bus (Producto)

WSO2 Enterprise Service Bus (ESB) 4.7.0 documentación! WSO2 ESB es una, 100% fuente rápida de peso ligero abierto y fácil de usar ESB distribuido bajo la licencia Apache v2.0 Software. WSO2 ESB permite a los administradores y desarrolladores de sistemas configurar convenientemente el enrutamiento de mensajes, la mediación, la transformación, la tala, la programación de tareas, la conmutación por error, balanceo de carga, y mucho más. Es compatible con los más comúnmente utilizados patrones de integración empresarial (CIE) y permite el cambio de transporte, concurso completo, la mediación basada en reglas, y la mediación basada en la prioridad de los requisitos de integración avanzada. El tiempo de ejecución ESB está diseñado para ser completamente asíncrona no bloqueante, y la transmisión basa en el motor de mediación Apache Synapse.

WSO2 ESB se desarrolla en la parte superior de la plataforma revolucionaria WSO2 Carbon, un marco basado en OSGi que proporciona la modularidad sin problemas a través de su SOA componentización. Incluye muchas características y componentes opcionales (add-ons) se puede instalar en el ESB, y se puede quitar fácilmente las características que no sean necesarios en su entorno, lo que le permite personalizar por completo y adaptar WSO2 ESB para satisfacer sus necesidades exactas de SOA.

Arquitectura infraestructura de aplicaciones en las empresas puede ser inherentemente complejo, que comprende cientos de aplicaciones completamente diferentes semántica. Algunas de estas aplicaciones se hecha a la medida, algunos son adquiridos a terceros, y algunos pueden ser una combinación de ambos y puede funcionar en diferentes entornos de sistema.

La integración entre estas aplicaciones heterogéneas es de vital importancia para la empresa. Los distintos servicios pueden estar usando diferentes formatos de datos y protocolos de comunicación. ubicaciones físicas de servicios pueden cambiar arbitrariamente. Todas estas limitaciones significan sus aplicaciones están todavía fuertemente acoplados entre sí. Un ESB puede ser utilizado para aflojar estos acoplamientos entre diferentes servicios y consumidores de servicios.

WSO2 ESB ESB es un hecho y derecho, lista para la empresa. Está construido sobre el proyecto Apache Synapse, que se construye a partir del proyecto Apache Axis2. Todos los componentes se construyen como paquetes OSGi.

Answer 8

Tome un vistazo a mi presentación " donde elegir - ¿Cómo elegir el derecho ESB ".

explico cuándo usar un ESB, Integration Suite, o simplemente un marco de integración (como Apache Camel). También discuto las diferencias entre los ESB de código abierto y propietarias.

Answer 9

hay cero razón para utilizar un ESB. No lo haga. La complejidad innecesaria. ¿Por qué ir a través de un intermediario cuando se puede ir directo? La gente ESB le dirá que un punto a otro es malo, pero de alguna manera punto a punto hacia y desde la ESB es buena.

Answer 10

La primera pregunta que hay que preguntarse es ¿por qué necesita un ESB?

ESB se utiliza generalmente en el Evento SOA arquitecturas distribuidas, que parecen estar en boca de todos hoy en día. Antes de pasar a ESB permítanme recordarles de Fowler Primera Ley de Martin de la distribución de sistemas:

http://martinfowler.com/bliki/FirstLaw.html

"Mi Primera Ley de Diseño de objetos distribuida:. No distribuir sus objetos (Desde P de EAA)

El capítulo correspondiente está disponible en línea ".

Cuando estás construir un nuevo sistema, el aspecto más importante es que es a prueba de futuro, que significa un fácil escalabilidad y facilidad de mantenimiento. Si usted construye su sistema en torno al concepto de los servicios sueltos con un contrato estática definida distribuidos en un entorno de red, puede "ocultar" la arquitectura que desea para ese servicio en particular, debido a que las interfaces son todavía allí.

ESB se estrecha relación con Asyn sistemas de mensajería, por lo que antes de empezar a saltar en ese tipo de aplicación, saber que una arquitectura no tiene que ser homogénea, es decir todos los servicios se ejecutarán de la misma manera, ¡No iniciar el mayor error que distribuye su sistema desde el principio, sólo se debe distribuir como sea necesario para escalar, no antes de la mano. Lo que hay que asegurarse, sin embargo, es que sus servicios deben ser capaces de distribuirse fácilmente en caso de necesidad, sin romper cualquier contrato, lo que significaría cambios a los clientes de dicho servicio.

En cuanto a los beneficios de la ESB, que son los mismos que SOA, ESB añade el contexto de los mensajes Asyn (eventos) operaciones.

Answer 11

En primer lugar permítanme explicar SOA . Que se trata de construir una arquitectura como un conjunto de módulos de software reutilizables expuestos como “Servicios” con interfaces bien definidas. Los servicios facilitan el acoplamiento débil y resúmenes de sus detalles de implementación de los clientes.

SOA podría terminar arriba desordenado si cada componente pidió a los servicios directamente. Por lo tanto, presenta los siguientes problemas comunes.

• ¿Cómo se encuentra el que los servicios se utilizan y cuáles no?
• ¿Cómo encuentras los clientes mediante un servicio en particular?
• ¿Cómo usted rueda a cabo cambios a un servicio o exponer nuevas versiones a los servicios existentes sin interrupción?
• ¿Cómo apoya la compatibilidad hacia atrás para los clientes más antiguos que invocan interfaces de servicios de mayor edad
• ¿Cómo se realiza el registro, auditoría, cumplimiento de seguridad, etc en todos los servicios para el tráfico interno / externo?

La ESB es la solución a cuestiones antes mencionadas. ESB ...

• Ayuda trae el fin
• ¿Puede hacer cumplir estrictamente las políticas corporativas
  • por ejemplo. Seguridad, estrangulación, auditoría, etc aplica consistentemente
• virtualiza los extremos de servicio
  • Facilitar el control de versiones, actualizaciones flexibles, HA / equilibrio de carga, etc.
• realizar el enrutamiento, la mediación, transformación, etc.

Algunos casos de uso de la muestra se pueden encontrar aquí . Tenga en cuenta que son de sitio de desarrolladores de AdroitLogic y estrictamente acoplados con UltraESB, ESB de AdroitLogic.