servicios integracion ejemplos ejemplo java .net architecture esb

java - integracion - esb oracle



Beneficios de un servicio de bus empresarial. (13)

Además de los sitios que ya fueron mencionados. Deberías leer este artículo en " No uses un ESB a menos que tengas que hacerlo ". Fue escrito por el CTO de MuleSource, uno de los ESB de código abierto más populares disponibles. ¿No es exactamente una respuesta a su pregunta, más de hacer un punto para preguntarse "¿Necesito un ESB"?

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

Estoy buscando información sobre:

  1. Los tipos de problemas y ESB ayudan a resolver.
  2. las alternativas a un ESB - y las compensaciones en la selección entre ellos
  3. lo que debe hacer como desarrollador para construir sistemas compatibles con ESB

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

Gracias.

Echa un vistazo a este podcast de Hanselminutes . Responde algunas preguntas que realmente debería hacerse antes de implementar un bus de servicio.

Eche un vistazo a mi presentación " Spoiled for Choice - Cómo elegir el ESB correcto ".

Explico cuándo usar un ESB, Integration Suite o solo un Framework de integración (como Apache Camel). También discuto las diferencias entre el código abierto y los ESB propietarios.

Hay una serie decente de 3 partes en IBM con respecto a ESB, que está bastante orientada a los conceptos y es independiente del proveedor (en su mayor parte). Encontré muchas cosas buenas en ESB al buscar en el sitio de IBM. También hay información y videos y cosas decentes en el sitio de BizTalk .

La primera pregunta que debe hacerse es ¿por qué necesita un ESB?

ESB se usa generalmente en las arquitecturas distribuidas de Event SOA, que parecen ser una palabra de moda en la actualidad. Antes de saltar a ESB, permítame recordarle la Primera Ley de Sistemas de Distribución de Martin''s Fowler:

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

"Mi primera ley de diseño de objetos distribuidos: no distribuya sus objetos (de P de EAA).

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

Cuando construye un nuevo sistema, el aspecto más importante es que está preparado para el futuro, lo que significa fácil escalabilidad y facilidad de mantenimiento. Si construye su sistema en torno al concepto de servicios perdidos con contrato definido estático distribuido en un entorno de red, puede "ocultar" la arquitectura que desea para ese servicio en particular, porque las interfaces aún están allí.

ESB está estrechamente relacionado con los sistemas de mensajería asyn, por lo tanto, antes de comenzar a utilizar ese tipo de implementación, sepa que una arquitectura no tiene que ser homogénea, es decir, que todos los servicios se implementen de la misma manera, no comience el error más grande que es Distribuyendo su sistema desde el principio, solo debe distribuirlo como necesite para escalar, no antes. Sin embargo, lo que debe asegurarse es que sus servicios deberían poder distribuirse fácilmente si fuera necesario, sin romper ningún contrato, lo que significaría cambios para los clientes de ese servicio.

En cuanto a los beneficios de ESB, son los mismos que SOA, ESB agrega el contexto de las operaciones de mensajes asyn (eventos).

Los ESB son una buena manera de implementar patrones de integración empresarial .

Tipos de problemas que un ESB ayuda a resolver.

  • Tiene una serie de protocolos que le gustaría normalizar a un solo protocolo (por ejemplo, FTP, correo electrónico, SOAP, XMPP, etc. a un sistema de mensajería), por ejemplo, ActiveMQ. Esto le permite desacoplar la implementación de servicios del protocolo.
  • Desea una forma consistente de conectar servicios en esta arquitectura para que puedan escuchar mensajes, procesar mensajes y generar mensajes (puntos finales de mensajes, adaptadores de canal, etc.).
  • Es posible que desee un contenedor administrado para implementar estos diversos componentes (por ejemplo, ServiceMix, Mule)
  • Es posible que desee una serie de componentes y adaptadores precompilados en varios protocolos (por ejemplo, ServiceMix, Mule y Camel tienen muchos componentes preconstruidos).
  • Es posible que necesite flujos de trabajo de larga ejecución. Business Process Management es a menudo algo que se proporciona junto con un ESB (Apache ODE se conecta a una serie de ESB de código abierto).

Alternativas a un ESB

Las alternativas realmente dependen del problema que estás tratando de resolver.

  • Para proporcionar servicios distribuidos, las personas a menudo utilizan servidores de aplicaciones que exponen servicios a través de algún protocolo RPC punto a punto (como EJBs sobre RMI o Servicios Web sobre HTTP). Entonces, en lugar de poner un mensaje en un ''bus'', un cliente llama directamente a un servidor.
  • Para responder a protocolos específicos, puede crear un cliente que responda a ese protocolo, por ejemplo, escribiendo una aplicación que escuche correos electrónicos utilizando JavaMail o uno que escuche XMPP utilizando Smack. Si su problema está limitado a uno o dos protocolos, puede que no valga la pena traer un ESB completo.

Lo que debe hacer como desarrollador para construir sistemas compatibles con ESB

Esto dependerá del ESB que seleccione, aunque dado que la mayoría de los buenos están diseñados para llamar a todo tipo de protocolos, así como a los POJO de host, no hay mucho que deba hacer para crear sistemas compatibles con ESB. Vale la pena tratar de hacer su código asíncrono.

Por ejemplo, Apache Camel probablemente tiene la configuración más breve, aquí hay un tutorial .

No hay ninguna razón para usar un ESB. No lo hagas Complejidad innecesaria. ¿Por qué pasar por un intermediario cuando puedes ir directo? La gente de ESB le dirá que punto a punto es malo, pero de alguna manera punto a punto y desde ESB es bueno.

Primero déjame explicar SOA . 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 flexible y resumen los detalles de implementación de los clientes.

SOA podría terminar desordenado si cada componente llamara directamente a los servicios. Por lo tanto, tiene siguientes problemas comunes.

  • ¿Cómo encuentra qué servicios se utilizan y cuáles no?
  • ¿Cómo encuentras a los clientes usando un servicio particular?
  • ¿Cómo se implementan las actualizaciones en un servicio o se exponen las nuevas versiones a los servicios existentes sin interrupciones?
  • ¿Cómo se admite la compatibilidad con versiones anteriores para clientes antiguos que invocan interfaces de servicio más antiguas?
  • ¿Cómo realiza el registro, la auditoría, la aplicación de la seguridad, etc. en todos los servicios para el tráfico interno / externo?

El ESB es la solución a los problemas anteriores. ESB ...

  • Ayuda a poner en orden
  • Puede hacer cumplir estrictamente las políticas corporativas
    • Ej. Seguridad, regulación, auditoria, etc. aplicada consistentemente.
  • Virtualiza los puntos finales del servicio.
    • Facilite el control de versiones, actualizaciones flexibles, HA / equilibrio de carga, etc.
  • Realizar enrutamiento, mediación, transformación, etc.

Algunos ejemplos de casos de uso se pueden encontrar here . Tenga en cuenta que son del sitio de desarrolladores de AdroitLogic y estrictamente acoplados con UltraESB, el ESB de AdroitLogic.

Tres ventajas clave:

  • Un bus proporciona una forma para que los puntos finales se conecten entre sí sin tener que hablar directamente entre ellos. Simplifica las comunicaciones para los puntos finales, ya que solo tienen que ajustarse a una interfaz de comunicación estándar, el bus. (Esto es con cualquier bus técnico, no solo con ESB)
  • Un ESB proporciona un lugar único para obtener algunas métricas de punto final clave: frecuencia, disponibilidad y rendimiento.
  • Un ESB tiende a proporcionar más de una interfaz de comunicación. Sin embargo, un desarrollador solo tiene que elegir el más fácil de obtener y recibir los datos del bus.

Sin embargo, asegúrese de que proporcionen valor comercial para su situación. Tener un ESB está agregando otra complejidad a su empresa. Idealmente, no debería elegir esto en función de algunas aplicaciones, sino de toda la organización. Debe haber un solo clúster ESB de producción para la organización.

Alternativas:

  • Simplemente conecte las cosas entre sí directamente, especialmente si los protocolos de comunicación son los mismos. Esto es bueno para clústeres de aplicaciones simples y no requiere demasiada reflexión. Sin embargo, a medida que crece el número de aplicaciones, es difícil mantener las interconexiones.
  • Otra alternativa es una implementación de MQ. Esto le proporcionará una forma de transferir datos sin tener interconexiones complejas, pero luego se verá obligado a usar solo un canal de comunicación. Afortunadamente para Java, tienen el estándar JMS.

Sentido práctico:

He indicado las posibles alternativas. Pueden parecer maliciosos al principio, pero no quiere decir que no puedas comenzar de esa manera. Personalmente escribo cosas para hablar directamente con el control remoto sin pasar por un ESB para asegurarme de que funcione sin preocuparme demasiado por los problemas de integración.

Si no tiene un ESB, le sugiero que pruebe Mule para el desarrollo y WebSphere ESB para la prueba y la producción. Tiendo a usar dos productos que supuestamente siguen los estándares para asegurarnos de que mantenemos a los proveedores honestos y para asegurarnos de que sus desarrolladores cumplan con los estándares que evitan el bloqueo involuntario de proveedores.

Al final, solo responda la siguiente pregunta: ¿es el momento de agregar el poco de complejidad para simplificar otras complejidades que su empresa vale el costo a largo plazo?

Un bus de servicio empresarial (ESB) es una arquitectura de software para middleware que proporciona servicios fundamentales para arquitecturas más complejas. Por ejemplo, un ESB incorpora las características necesarias para implementar una arquitectura orientada a servicios (SOA). En un sentido general, se puede considerar a un ESB como un mecanismo que gestiona el acceso a las aplicaciones y servicios (especialmente las versiones heredadas) para presentar una interfaz única, simple y coherente para los usuarios finales a través del lado del cliente basado en web o formularios. frente termina.

En esencia, ESB ofrece servicios y aplicaciones back end heterogéneos distribuidos, usuarios front-end heterogéneos y consumidores de información distribuidos, lo que el middleware realmente debe hacer: ocultar complejidad, simplificar el acceso, permitir a los desarrolladores utilizar formas genéricas y canónicas de consulta, acceso y Interacción, manejo de los detalles complejos en el fondo. La clave para el atractivo de ESB, y posiblemente también su éxito futuro, radica en su capacidad para soportar el servicio incremental y la integración de la aplicación según los requisitos del negocio, no según la tecnología disponible.

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

Bus de Servicio Empresarial WSO2 (Producto)

Documentación de WSO2 Enterprise Service Bus (ESB) 4.7.0! WSO2 ESB es un ESB rápido, ligero, 100% de código abierto y fácil de usar distribuido bajo la Licencia de software Apache v2.0. WSO2 ESB permite a los administradores y desarrolladores del sistema configurar de manera conveniente el enrutamiento de mensajes, la mediación, la transformación, el registro, la programación de tareas, la conmutación por error, el equilibrio de carga y más. Es compatible con los patrones de integración empresarial (EIP) más utilizados y permite la conmutación de transporte, eventos, mediación basada en reglas y mediación basada en prioridades para requisitos de integración avanzados. El tiempo de ejecución de ESB está diseñado para ser completamente asíncrono, sin bloqueo y transmisión basada en el motor de mediación de Apache Synapse.

WSO2 ESB se desarrolla sobre la revolucionaria plataforma WSO2 Carbon, un marco basado en OSGi que proporciona una modularidad perfecta a su SOA a través de la creación de componentes. Incluye muchas funciones y componentes opcionales (complementos) que puede instalar en el ESB, y puede eliminar fácilmente las funciones que no se requieren en su entorno, lo que le permite personalizar completamente y adaptar el WSO2 ESB para satisfacer sus necesidades exactas de SOA.

La infraestructura de aplicaciones de arquitectura en las empresas puede ser intrínsecamente compleja, ya que comprende cientos de aplicaciones con semánticas completamente diferentes. Algunas de estas aplicaciones se construyen a medida, otras se adquieren de terceros, y algunas pueden ser una combinación de ambas y pueden operar en diferentes entornos de sistema.

La integración entre estas aplicaciones heterogéneas es vital para la empresa. Diferentes servicios pueden estar utilizando diferentes formatos de datos y protocolos de comunicación. Las ubicaciones físicas de los servicios pueden cambiar arbitrariamente. Todas estas restricciones significan que sus aplicaciones aún están estrechamente acopladas. Se puede utilizar un ESB para aflojar estos acoplamientos entre diferentes servicios y consumidores de servicios.

WSO2 ESB es un ESB completo y listo para la empresa. Se basa en el proyecto Apache Synapse, que se construye utilizando el proyecto Apache Axis2. Todos los componentes están construidos como paquetes OSGi.