Eligiendo un sistema de mensajería: WebSphere MQ vs. el Bus de Integración de Servicio de WebSphere Application Server

WebSphere Application Server incluye una variedad de proveedores de JMS que pueden ser usados por aplicaciones. Este artículo compara el sistema de mensajería de WebSphere MQ con el sistema de mensajería del Bus de Integración de Servicio incorporado en WebSphere Application Server. El artículo resalta un número de factores a considerar al elegir un sistema de mensajería, para ayudarle a tomar una decisión informada sobre su sistema de mensajería y proveedor de SMJ.

Graham Wallis, Senior Technical Staff Member, IBM

Graham Wallis photoGraham Wallis es un Miembro Sénior del Personal Técnico en Hursley, en el Reino Unido, y es responsable de los componentes de mensajería en WeSphere Application Server y los productos incorporados en él. Graham ha estado con IBM durante 22 años y ha trabajado en una variedad de tecnologías, incluyendo comunicaciones de datos, procesamiento paralelo, mensajería asíncrona y alta disponibilidad.



12-03-2012

Introducción

Si usted usa IBM® WebSphere® Application Server para desplegar una aplicación que use Java™ Message Service (JMS), la aplicación puede usar una variedad de proveedores de JMS. Este artículo compara dos de los proveedores de JMS disponibles en WebSphere Application Server y los sistemas de mensajería con los que esos proveedores se relacionan: WebSphere MQ y el Bus de Integración de Servicio (SIBus) incorporado en WebSphere Application Server.

¿Qué es JMS?

JMS es un estándar que especifica cómo las aplicaciones de Java envían y reciben mensajes. La especificación de JMS define la interfaz de programación de aplicaciones (API) usada por una aplicación para acceder a un sistema de mensajería, con el beneficio de que una aplicación que usa la API de JMS estándar debe ser portable entre distintas implementaciones de JMS. La especificación de JMS está limitada en ámbito a la API.

¿Qué es un proveedor de JMS?

Una implementación de la API de JMS es conocida como un proveedor de JMS. Cada proveedor correlaciona las operaciones de la API en un sistema de mensajería que establece conexiones hacia otros sistemas y les transmite mensajes. Aunque el Proveedor de JMS es una correlación con un sistema de mensajería, no necesariamente incluye el sistema de mensajería. El sistema de mensajería bien puede soportar otras APIs, asegurando así una separación entre los conceptos del sistema de mensajería y el proveedor de JMS.

Figura 1. Rol del proveedor de JMS
Rol del proveedor de JMS

¿Cómo una aplicación se vuelve asociada con un proveedor de JMS?

Para una aplicación de JMS desplegada en WebSphere Application Server, la elección del proveedor de JMS está gobernada por la configuración de recursos de JMS administrados - como la Fábrica de Conexión de JMS y la Fila de JMS - que generalmente son buscados en el espacio de nombres de JNDI del servidor de aplicaciones. Cuando configura estos recursos de JMS, usted usa definiciones proporcionadas por el proveedor de JMS que desea que la aplicación utilice. La configuración de los recursos dicta entonces qué sistema de mensajería manejará la conexión de la aplicación y transmitirá los mensajes de la aplicación.

Aunque ofrece portabilidad, JMS no garantiza la interoperabilidad. Como se mencionó anteriormente, la especificación de JMS está limitada en su ámbito a la API, y por lo tanto no define un "formato de conexión" estándar para cómo los mensajes deben ser estructurados, ni tampoco especifica un "protocolo de conexión" estándar para definir la conversación entre los puntos finales de mensajería. Pero la mensajería generalmente involucra al menos una aplicación más con la cual usted pretende intercambiar mensajes. Para que la comunicación sea posible, la elección del proveedor de JMS y el sistema de mensajería asociado debe ser compatible con el sistema de mensajería usado por las otras aplicaciones.

Proveedores de JMS en WebSphere Application Server

Figura 2. Proveedores de JMS en WebSphere Application Server
Proveedores de JMS en WebSphere Application Server

WebSphere Application Server proporciona tres opciones para configurar proveedores de JMS:

Proveedor de mensajería predeterminado

El proveedor de mensajería predeterminado es una elección popular, ya que usa el sistema de mensajería de SIBus incorporado en el tiempo de ejecución para WebSphere Application Server V6 o posterior. Está escrito en Java y se ejecuta dentro de un proceso de WebSphere Application Server. La administración del SIBus está integrada con el sistema de administración de WebSphere Application Server, por lo que puede usar la consola o comandos de scripts para configurarla. El SIBus le permite construir un "bus" dentro de una célula de WebSphere. Los servidores o clústeres dentro de la célula puede unirse al bus, y cada servidor o clúster que es un miembro del bus ejecuta un motor de mensajería en proceso. Los motores de mensajería se descubren y se conectan unos con otros, y envían y reciben mensajes enviados por aplicaciones.

Proveedor de JMS de WebSphere MQ

El proveedor de JMS de WebSphere MQ se correlaciona con el sistema de mensajería de WebSphere MQ. WebSphere MQ no es parte de WebSphere Application Server, sino un producto separado que se ejecuta en muchas plataformas distintas y soporta una variedad de lenguajes de programación y APIs. El proveedor de JMS de WebSphere MQ es una elección popular, ya que WebSphere MQ es el producto de middleware orientado a mensajería (MOM) más utilizado en la industria. Ha estado disponible durante muchos años y es ampliamente utilizado para integrar aplicaciones en plataformas distintas. El artefacto clave de tiempo de ejecución en WebSphere MQ es llamado un gestor de fila. Para obtener más información sobre WebSphere MQ, vea el centro de información de WebSphere MQ V7.

Ya que WebSphere MQ no es parte de WebSphere Application Server, sus gestores de fila se ejecutan en procesos separados y son administrados en forma separada. El proveedor de JMS de WebSphere MQ permite a una aplicación conectarse a un gestor de fila o fila compartiendo un grupo, mediante una conexión de cliente de WebSphere MQ.

Proveedor de mensajería externo genérico

Su organización puede usar un producto de mensajería externo, en cuyo caso puede configurar WebSphere Application Server para que use el proveedor de mensajería externo. Siendo menos común que las primeras dos opciones, puede personalizarse para correlacionarse a un sistema de mensajería arbitrario. Debido a su naturaleza genérica, la configuración del proveedor de mensajería externo se basa en un sistema flexible pero de alguna manera primitivo para configurar las propiedades.

Decidiendo qué sistema de mensajería usar

La elección del proveedor de JMS es generalmente impulsada por la elección del sistema de mensajería. Algunas veces, su organización ya ha elegido un sistema de mensajería y hecho una inversión significativa para implementarlo, así que ese es el sistema de mensajería que necesitará usar. En otros casos, la elección de un sistema de mensajería sigue estando abierta y requiere una comparación funcional de los dos principales sistemas de mensajería alternativos, así como una investigación de las características requeridas por las aplicaciones en sus aplicaciones.

Decidiendo usar WebSphere MQ

Si su organización ya usa WebSphere MQ, probablemente tenga una inversión significativa en infraestructura instalada, habilidades, procedimientos administrativos y posibilidades de supervisión, y es normalmente inteligente capitalizar esa inversión al continuar usando WebSphere MQ para la mensajería. En muchas organizaciones grandes, un equipo de mensajería experimentado de administradores de WebSphere MQ dentro del departamento de TI tiene la habilidad de suministrar rápida y eficientemente recursos de mensajería para su uso. Más aún, si WebSphere MQ es usado por la otra aplicación o servicio con el cual su aplicación de JMS se comunicará, entonces es la elección natural como el sistema de mensajería para su aplicación de JMS. La otra aplicación también puede estar usando la API de JMS, pero no tiene que, ya que una aplicación de WebSphere MQ escrita en otro lenguaje puede intercambiar mensajes con una aplicación de JMS.

Conectándose directamente a un WebSphere MQ existente

Asuma que, con base en las consideraciones anteriores, usted elige usar WebSphere MQ. En la mayoría de los casos, la mejor forma de conectar una aplicación de JMS de WebSphere Application Server a un gestor de fila de WebSphere MQ es configurar WebSphere Application Server para que se conecte directamente a WebSphere MQ. La conexión directa es el método más simple y popular, y usa el proveedor de JMS de WebSphere MQ incluido en WebSphere Application Server. Usted simplemente usa las interfaces de administración de WebSphere Application Server para configurar los recursos de JMS ofrecidos por el proveedor de JMS de WebSphere MQ. Estos recursos son típicamente del tipo Fábrica de Conexión de JMS, Fila de JMA, Tema de JMS o Especificación de Activación de JMS.

Conectándose indirectamente a un WebSphere MQ existente

Hay dos circunstancias en las cuales podría usar WebSphere MQ como el sistema de mensajería con el enfoque indirecto y menos común para conectar WebSphere Application Server con WebSphere MQ. La conexión indirecta requiere una configuración más compleja que el enfoque directo, pero tiene dos escenarios de uso que puede encontrar relevantes. En ambos casos, WebSphere Application Server es configurado para usar el proveedor de mensajería predeterminado para conectar la aplicación con el SIBus, que a su vez está configurado para conectarse a WebSphere MQ.

Usando WebSphere MQ indirectamente para almacenar y reenviar

Suponga que tiene una aplicación de WebSphere Application Server desplegada en un servidor que es físicamente remoto desde el gestor de fila. Si la aplicación usa el proveedor de JMS de WebSphere MQ para conectarse directamente a WebSphere MQ, se conectaría al gestor de fila usando una conexión sincrónica, y por lo tanto los mensajes podrían ser transmitidos sólo cuando todo - el servidor de aplicaciones, la red y el gestor de fila - esté disponible. Un corto en la red evitaría que la aplicación enviara mensajes al gestor de fila y podría evitar que la aplicación hiciera cualquier trabajo útil, reduciendo la disponibilidad general. Una forma de mitigar el riesgo de dicho corto es co-ubicar el gestor de fila con la aplicación, pero eso podría no ser práctico o costeable. Una mitigación alternativa es conectar la aplicación con el SIBus, usando un bus al que el servidor de aplicaciones pertenezca, de forma que el servidor de aplicaciones contendrá un motor de mensajería para el bus. La interacción entre la aplicación y el motor de mensajería será local y sincrónica, y los mensajes pueden ser almacenados por el motor de mensajería hasta que pueda reenviarlos en forma asíncrona hacia el sistema remoto, cuando la red esté disponible. La aplicación puede entonces enviar mensajes aún cuando no haya conectividad con otros sitios, permitiendo a la aplicación funcionar durante un corto de red.

Usando WebSphere MQ indirectamente para acceder a un grupo de intercambio de fila (QSG) de WebSphere MQ antes de la V7.0.1

Este segundo escenario involucra el uso de un QSG alojado por los gestores de fila en WebSphere MQ antes de la V7.0.1. Un QSG es un recurso proporcionado sólo para WebSphere MQ en z/OS, en el cual múltiples gestores de fila operan concurrentemente en el mismo conjunto de filas. Imagine que su aplicación necesita conectarse al QSG para enviar o recibir un mensaje como parte de una transacción distribuida. Por ejemplo, una unidad de trabajo para la aplicación puede incluir recibir un mensaje de solicitud, actualizar una base de datos y transmitir un mensaje de respuesta. Las operaciones en la base de datos y en el gestor de fila deben ser realizadas dentro de una transacción distribuida, usando un protocolo de confirmación de dos fases. Al igual que con cualquier protocolo de dos fases, si la conexión entre la aplicación y el gestor de fila se rompe cuando una transacción ha sido preparada pero que aún no ha sido confirmada o regresada, entonces la transacción estará en duda. Antes de WebSphere MQ V7.0.1 el coordinador de transacción debe reconectarse al mismo gestor de fila para resolver la transacción en duda. El proveedor de JMS de WebSphere MQ no tiene una forma de mantener la afinidad para recuperación en un QSG. Sin embargo, puede hacer que el QSG sea miembro de un SIBus. Configure la aplicación para que use el proveedor de mensajería predeterminado y conectarse así al SIBus y a dirigir el mensaje a un destino que represente una fila dentro del QSG. SIBus gestiona la afinidad dentro del QSG y puede resolver transacciones en duda.

El enfoque anterior es sólo necesario antes de WebSphere MQ V7.0.1 porque a partir de esa versión la aplicación puede conectarse usando el nombre de QSG y usar la unidad GROUP de disposición de recuperación. El coordinador de transacción puede reconectarse a cualquier gestor de fila en el QSG para recuperar una transacción en duda.

Decidiendo usar un SIBus

Como se describió anteriormente, tal vez quiera usar un sistema de mensajería existente que esté bien establecido en su empresa, o usar el mismo sistema de mensajería que otra aplicación o servicio con el cual su aplicación de JMS se comunicará. Estas consideraciones pueden llevarlo a elegir un SIBus como el sistema de mensajería.

El SIBus realiza dos roles - es un sistema de mensajería soportando aplicaciones de JMS y el transporte asíncrono para un número de productos de Gestión de Proceso Empresarial basados en Java de IBM. Su organización puede ya estar usando un SIBus en cualquiera de estos roles, en cuyo caso puede ser mejor capitalizar las habilidades, el conocimiento y los procedimientos existentes. Para conectar la aplicación al SIBus, configure los recursos de JMS de la aplicación usando el proveedor de mensajería predeterminado.

Eligiendo entre WebSphere MQ y un SIBus

Si su organización no tiene una infraestructura de mensajería existente o si está migrando desde otros sistemas de mensajería hacia WebSphere MQ o un SIBus, entonces su elección de sistema de mensajería debe ser influenciada por las consideraciones descritas a continuación. La consideración más importante es seleccionar el sistema de mensajería que tenga las características operacionales que usted requiere. La elección del proveedor de JMS es lo siguiente. Después de que ha seleccionado su sistema de mensajería, sus opciones son similares a aquellas descritas anteriormente. Normalmente usted usaría el proveedor de mensajería predeterminado para conectarse a un SIBus, o usaría el proveedor de JMS de WebSphere MQ para conectarse directamente a WebSphere MQ.

Entorno del tiempo de ejecución y plataforma

Si su aplicación se está ejecutando en un entorno de Java EE de WebSphere Application Server, entonces su integración con WebSphere Application Server hace que un SIBus sea el ajuste natural. Si su entorno es heterogéneo (incluyendo WebSphere Application Server y otras tecnologías que no son de Java) entonces use WebSphere MQ. Por ejemplo, si está usando WebSphere Message Broker o CICS, entonces WebSphere MQ es una elección natural. La plataforma física en la cual se están ejecutando sus aplicaciones generalmente no es un factor significativo, ya que el SIBus y WebSphere MQ soportan una amplia gama de plataformas.

Lenguaje de programación

WebSphere MQ soporta una amplia gama de lenguajes de programación. El soporte de programación de SIBus consiste principalmente de JMS, aunque el SIBus sí soporta C, C++ y C# mediante los Clientes de Servicio de Mensajería de IBM para C/C++ y .NET, conocidos como XMS. Para obtener más información, vea el artículo de developerWorks Introduciendo XMS -- La API del Servicio de Mensajería de IBM.

Herramientas de supervisión

WebSphere MQ es un producto bien establecido con una enorme base de instalación y una amplia gama de soporte de herramientas, incluyendo muchas herramientas excelentes de supervisión y gestión de IBM y de terceros.

Integración vs. aislamiento

El SIBus usa el tiempo de ejecución, la consola y las interfaces de comandos de WebSphere Application Server, lo que puede ser un beneficio debido a la integración de la configuración y la administración entre WebSphere Application Server y el sistema de mensajería. Alternativamente, tal vez prefiera usar WebSphere MQ, y que no se ejecuta en el proceso de WebSphere Application Server. Como resultado, puede descargar el procesamiento de mensajes en un grupo de procesos separados aislado de WebSphere Application Server, de forma que no afecte el almacenamiento dinámico u otros recursos que sean importantes para el proceso de WebSphere Application Server y sus aplicaciones desplegadas. El aislamiento también puede simplificar los ajustes y puede reducir el tiempo de inicio del servidor de aplicaciones.

Alta disponibilidad (HA)

Una consideración clave para la HA es el tiempo de inactividad experimentado cuando ocurre una falla. Tanto el SIBus como WebSphere MQ pueden iniciarse rápidamente de un estado de desactivado temporal en el cual tengan filas relativamente vacías, pero WebSphere MQ normalmente se iniciará más rápidamente cuando haya un alto volumen de mensajes almacenados.

La forma en que detecta las fallas y orquesta los reinicios depende de qué sistema de mensajería use. La migración tras error de SIBus y WebSphere MQ puede ser gestionada por una infraestructura de clúster de HA, tal como High Availability Cluster Multi-Processing (HACMP) o Veritas Cluster Server (VCS). Un clúster de HA externo puede ser una buena solución al integrar el sistema de mensajería en la gestión de recursos en su ambiente de producción. Cuando no necesite esa integración, SIBus y WebSphere MQ tienen soporte adicional de HA que evita la necesidad de la agrupación de clúster externa.

Un motor de mensajería de SIBus automáticamente explota el soporte de HA incorporado en un clúster de Despliegue de Red (ND) de WebSphere Application Server. Por lo tanto, la HA es muy fácil de configurar, y es lo predeterminado en un miembro de bus en clúster.

WebSphere MQ V7.0.1, o posterior, tiene un mecanismo de HA integrado que permite a dos máquinas ejecutar instancias cooperativamente de un gestor de fila y realizar una migración tras error perfecta cuando sea necesario.

En los límites de su entorno, cuando su sistema de mensajería interactúa con el sistema de mensajería en otra organización tal como un asociado de negocios, los gestores de fila remotos o los motores de mensajería se conectarán a los suyos usando una dirección IP. Es importante mantener la correlación entre esa dirección IP y el gestor de fila de WebSphere MQ o motor de mensajería de SIBus con el cual está asociada. Un esquema de direccionamiento simple ayuda a aislar a sus asociados externos de su topología de red, ya que evita que necesiten configurar y mantener salidas de canal o listas de búsqueda que reflejen su topología. La afinidad puede ser mantenida con una infraestructura de clúster de HA de alguna manera más fácilmente con WebSphere MQ que con un SIBus.

Perfil del tráfico de mensajes

Si está usando mensajes grandes, entonces WebSphere MQ puede ser una mejor opción. WebSphere MQ tiene un límite de arquitectura en el tamaño de mensaje de 100 MB, y WebSphere MQ posee y controla su memoria y puede ser ajustado de acuerdo al perfil de mensaje. Un SIBus no tiene un límite de arquitectura, y el máximo empírico es de 40 MB en sistemas de 32-bits y de 80 MB en sistemas de 64-bits. Ya que no hay un límite duro, un SIBus no es tan bien aislado de las demandas colocadas en el almacenamiento dinámico de la JVM por aplicaciones u otros servicios. Para un SIBus, una compilación de grandes mensajes (como cuando un enlace está inactivo) colocará mucho estrés en el almacenamiento dinámico de la JVM.

Rendimiento y escalabilidad

Desde septiembre de 2011, el rendimiento de mensajes persistentes de WebSphere MQ es aproximadamente el doble de rápido que los mensajes persistentes de SIBus. Hay muy poca diferencia para mensajes no persistentes.

WebSphere MQ soporta la agrupación en clúster de gestores de fila para un rendimiento mejorado y escalabilidad de administración. Hay muchos ejemplos de clústeres de producción que contienen miles de gestores de fila. La agrupación en clúster de WebSphere MQ es extremadamente flexible, soportando un paralelismo selectivo de filas de clúster, permitiéndole ajustar a la medida el número de instancias de cada fila de clúster en forma independiente. Los motores de mensajería pueden ser agrupados en clúster dentro de un clúster de WebSphere Application Server para rendimiento y escalabilidad administrativa. Sin embargo, un clúster de WebSphere Application Server tiene un límite de escalabilidad mucho más bajo que un clúster de WebSphere MQ y, si una fila es asignada a un miembro de bus de clúster de WebSphere Application Server, es particionada en todos los motores de mensajería en el clúster - usted no puede ubicar selectivamente las particiones.

Costo

El SIBus es un componente de WebSphere Application Server y por lo tanto no genera ningún costo adicional, mientras que WebSphere MQ es un producto licenciado en forma separada. Desde septiembre de 2011, ambos productos son vendidos en un modelo de precios basado en la capacidad, y para formar una comparación significativa usted necesita calcular la capacidad aproximada que necesitaría para cada producto. Los informes de rendimiento disponibles de IBM pueden ayudarle con esta comparación.

Conclusión

Este artículo introdujo los conceptos que sustentan el JMS, los proveedores de JMS y los sistemas de mensajería, y presentó un número de factores a considerar al decidir qué sistema de mensajería y qué proveedor de JMS usar para soportar una aplicación de JMS. Puede haber razones organizacionales o de compatibilidad para usar WebSphere MQ o un SIBus, o tal vez pueda elegir basado enteramente en las características funcionales de cada sistema de mensajería, que fueron resumidas anteriormente. En situaciones donde es preferible usar WebSphere MQ, generalmente debería configurar su aplicación para conectarse directamente a WebSphere MQ usando el Proveedor de JMS de WebSphere MQ en WebSphere Application Server. En otras situaciones donde es preferible usar un SIBus, usted debería usar el proveedor de mensajería predeterminado.

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=800890
ArticleTitle=Eligiendo un sistema de mensajería: WebSphere MQ vs. el Bus de Integración de Servicio de WebSphere Application Server
publish-date=03122012