IBM MQ

IBM MQ es una familia de productos middleware orientados a mensajes que IBM lanzó en diciembre de 1993. Originalmente se llamaba MQSeries y pasó a llamarse WebSphere MQ<. /i> en 2002 para unirse al conjunto de productos WebSphere. En abril de 2014, pasó a llamarse IBM MQ. Los productos incluidos en la familia MQ son IBM MQ, IBM MQ Advanced, IBM MQ Appliance, IBM MQ para z/OS e IBM MQ en IBM Cloud. IBM MQ también tiene opciones de implementación en contenedores.

MQ permite que aplicaciones independientes y potencialmente no simultáneas en un sistema distribuido se comuniquen de forma segura entre sí mediante mensajes. MQ está disponible en una gran cantidad de plataformas (tanto IBM como no IBM), incluidas z/OS (mainframe), IBM i, Transaction Processing Facility, UNIX (AIX, HP-UX, Solaris), HP NonStop, OpenVMS, Linux. y Microsoft Windows.

Componentes MQ

Los componentes principales de MQ son:

• Mensaje: Los mensajes son colecciones de datos binarios o de carácter (por ejemplo, ASCII o EBCDIC) que tienen algún significado para un programa participante. Como en otros protocolos de comunicación, la información de almacenamiento, enrutamiento y entrega se añade al mensaje antes de la transmisión y se despoja del mensaje antes de la entrega a la aplicación receptora.
• Queue: Las colas de mensajes son objetos que almacenan mensajes en una aplicación.
• Queue Manager: un servicio de sistema que proporciona un contenedor lógico para la cola del mensaje. Es responsable de transferir datos a otros administradores de colas a través de canales de mensajes. Aunque no es estrictamente necesario para el middleware orientado al mensaje, es un requisito para el MQ IBM. Los gestores de cola manejan el almacenamiento, los problemas de tiempo, el desencadenante y todas las demás funciones no directamente relacionadas con el movimiento real de datos.

Los programas integrados con IBM MQ utilizan una interfaz de programa de aplicación (API) coherente en todas las plataformas.

Tipos de mensajes

MQ admite mensajería punto a punto y de publicación-suscripción.

API

Las API admitidas directamente por IBM incluyen:

• IBM Interfaz de búsqueda de mensajes (MQI) para C, COBOL, PL/I, Java, Rexx, RPG y C++
• Java Message Service (JMS)
• XMS para C/C++ y. NET
• . NET
• Transferencia estatal
• SOAP

También hay API adicionales (no compatibles oficialmente) disponibles a través de terceros, entre ellas:

• Interfaz perl (desarrollado y contribuido por Hildo Biersma), disponible desde CPAN.
• Interfaz de Python (lengua de programación) PyMQI (originally developed by Les Smithson), available from PyPI
• Windows Power Shell

Características

Entrega única: MQ utiliza la entrega única y única. Esta calidad de servicio normalmente evita la pérdida o duplicación de mensajes.

Mensajería asincrónica: MQ proporciona a los diseñadores de aplicaciones un mecanismo para lograr una arquitectura que no dependa del tiempo. Se pueden enviar mensajes de una aplicación a otra, independientemente de si las aplicaciones se están ejecutando al mismo tiempo. Si una aplicación receptora de mensajes no se está ejecutando cuando un remitente le envía un mensaje, el administrador de colas retendrá el mensaje hasta que el receptor lo solicite. Se conserva el orden de todos los mensajes; de forma predeterminada, esto es en orden de recepción FIFO en la cola local dentro de la prioridad del mensaje.

Transformación de datos: p.e. De Big Endian a Little Endian, o de EBCDIC a ASCII. Esto se logra mediante el uso de salidas de datos de mensajes. Las salidas son aplicaciones compiladas que se ejecutan en el host del gestor de colas y son ejecutadas por el software IBM MQ en el momento en que se necesita la transformación de datos.

Marco de arquitectura basada en mensajes: IBM MQ permite la recepción de mensajes para "activar" otras aplicaciones para ejecutar.

Gama de API: implementa la API estándar Java Message Service (JMS) y también tiene su propia API patentada, conocida como Message Queuing Interface (MQI), que precedió al JMS durante varios años. en existencia. A partir de la versión 8.0.0.4, MQ también admite la API MQ Light.

Agrupación en clústeres: varias implementaciones de MQ comparten el procesamiento de mensajes, lo que proporciona equilibrio de carga.

Comunicación

Los gestores de colas se comunican con el mundo exterior a través de:

• Bindings: una conexión de software directa. Generalmente más rápido, pero limitado a programas que se ejecutan en el mismo host físico que el gerente de la cola.
• Una conexión de red o "cliente": las aplicaciones que utilizan una conexión cliente pueden conectarse a un administrador de cola en cualquier otro host en la red. La ubicación física del administrador de la cola es irrelevante, siempre y cuando sea accesible sobre la red.

Comunicación entre administradores de colas

Esto se basa en un canal. Cada gestor de colas utiliza uno o más canales para enviar y recibir datos a otros gestores de colas. Un canal es unidireccional; Se requiere un segundo canal para devolver datos. En una red basada en TCP/IP, un canal envía o recibe datos en un puerto específico.

Tipos de canales:

• Canal de envío: tiene un destino definido y se asocia con una cola de transmisión específica (el mecanismo por el cual se solicitan mensajes esperando la transmisión en el canal).
• Canal receptor: recibe datos de cualquier otro administrador de cola con un canal de envío del mismo nombre.

Cuando un canal receptor recibe un mensaje, se examina para ver a qué administrador de colas y cola está destinado. En caso de una falla de comunicación, MQ puede restablecer automáticamente una conexión cuando se resuelva el problema.

El escucha es la interfaz de red de la aplicación con el administrador de colas. El oyente detecta conexiones de canales entrantes y gestiona la conexión de los canales de envío a los canales de recepción. En una red TCP/IP, el oyente "escuchará" para conexiones en un puerto específico.

Transmitir datos a una cola en otro administrador de colas

Tipos de cola:

• Local queue: representa la ubicación donde se almacenan los datos esperando el procesamiento.
• Cargos remotos: representa una cola en otro administrador de la cola. Definen la cola de destino, que es un elemento del mecanismo de enrutamiento para mensajes.
• Cuota de racimo: representa una cola que es accesible a través de cualquier gestor de cola en su grupo.

Un mensaje se coloca en una cola remota. Los mensajes van a una cola de transmisión de almacenamiento temporal asociada con un canal. Al colocar un mensaje en una cola remota, el mensaje se transmite a través del canal remoto. Si la transmisión es exitosa, el mensaje se elimina de la cola de transmisión. Al recibir un mensaje, el gestor de colas receptor lo examina para determinar si es para sí mismo o si debe ir a otro gestor de colas. Si es el administrador de colas receptor, se verificará la cola requerida y, si existe, el mensaje se colocará en esta cola. De lo contrario, el mensaje se coloca en la cola de mensajes no entregados. MQ tiene funciones para gestionar la transmisión eficiente de datos a través de una variedad de medios de comunicación. Por ejemplo, los mensajes se pueden agrupar hasta que una cola alcance una profundidad determinada.

Hacer pedidos

Aunque la cola es FIFO, se ordena en función de la recepción en la cola local, no de la confirmación del mensaje por parte del remitente. Los mensajes se pueden priorizar y, de forma predeterminada, la cola se prioriza por orden de llegada. Las colas solo estarán en secuencia de adición si el mensaje se agrega localmente. La agrupación de mensajes se puede utilizar para garantizar que un conjunto de mensajes esté en un orden específico; aparte de eso, si la secuencia es crítica, es responsabilidad de la aplicación colocar datos de secuencia en el mensaje o implementar un mecanismo de protocolo de enlace mediante una devolución. cola. En realidad, los pedidos se mantendrán en configuraciones sencillas.

El registro

El otro elemento de un administrador de colas es el registro. A medida que se coloca un mensaje en una cola o se realiza un cambio de configuración, los datos también se registran. En caso de falla, el registro se utiliza para recrear objetos dañados y recrear mensajes. Sólo se recrean los mensajes persistentes cuando se produce un error; los mensajes "no persistentes" Los mensajes se pierden. Los mensajes no persistentes se pueden enviar a través de un canal configurado en modo rápido, en el que la entrega no está asegurada en caso de una falla del canal.

El MQ soporta la tala circular y lineal.

Recuperar mensajes de colas

La información se puede recuperar de las colas sondeando la cola para verificar los datos disponibles a intervalos adecuados o, alternativamente, MQ puede desencadenar un evento, permitiendo que una aplicación cliente responda a la entrega de un mensaje.

Disponibilidad

IBM MQ ofrece una variedad de soluciones para satisfacer la disponibilidad:

Administrador de colas de datos replicados (RDQM / 'Easy HA'- MQ Advanced solo en versión distribuida): Replicación síncrona entre tres servidores que comparten una dirección IP flotante.

Clústeres de gestores de colas: Los grupos de dos o más administradores de colas en una o más computadoras se definen en un clúster, lo que proporciona interconexión automática y permite compartir colas entre ellos para equilibrio de carga y redundancia.

Grupos de uso compartido de colas (solo z/OS): En un entorno de cola compartida, una aplicación puede conectarse a cualquiera de los gestores de colas dentro del grupo de cola compartida. Dado que todos los gestores de colas del grupo de uso compartido de colas pueden acceder al mismo conjunto de colas compartidas, la aplicación no depende de la disponibilidad de un gestor de colas concreto. Esto proporciona una mayor disponibilidad si un gestor de colas se detiene porque todos los demás gestores de colas del grupo de compartición de colas pueden continuar procesando la cola.

Multi-Instance Queue Managers (disponible desde v7.0.1):Las instancias del mismo administrador de cola están configuradas en dos o más computadoras con sus colas y meta datos que residen en almacenamiento compartido. Al iniciar múltiples instancias, una instancia se convierte en la instancia activa y las otras instancias se vuelven standbys. Si la instancia activa falla, una instancia de espera que se ejecuta en un ordenador diferente automáticamente toma el control.

Historia

Fechas de lanzamiento de la versión

Fechas de fin de soporte de la versión

La siguiente tabla se aplica al software MQ. El dispositivo MQ tiene fechas de ciclo de vida diferentes para el firmware y el hardware que las que aparecen en la tabla.

Referencia arquitectónica de fondo

Con el advenimiento de las computadoras, IBM vio la oportunidad de aplicar nuevas tecnologías a la necesidad de cambiar mensajes.

A principios de la década de 1960, IBM comercializó el sistema de control de comunicación IBM 7740 y el control de transmisión programado IBM 7750, que eran sistemas de conmutación de mensajes programables.

El Sistema IBM/360 fue anunciado en abril de 1964 y con él se presentaron métodos de acceso a las comunicaciones como BTAM y QTAM (métodos de acceso a las telecomunicaciones básicas y deseadas). En 1971, TCAM, el Método de Acceso a las Telecomunicaciones, ofreció a sus usuarios una forma más avanzada de conmutación de mensajes o enrutamiento de mensajes. TCAM fue ampliamente aceptado, especialmente en las industrias financieras y de intermediación. Soportó mensajería asincrónica, como con el MQ posterior. TCAM 3.0 agregó en colas reutilizables de mensajes de disco para la recuperación poco después, como con MQ. Se podría utilizar un programa PL/I de alto nivel para acceder a los conjuntos de datos TRANSIENT (con colas de mensajes dinamicos). La lectura de un mensaje de un conjunto de datos transitorio resultó en que el mensaje se retiraba de la cola, como con un READ sin crecimiento con el MQ.

A finales de la década de 1970, surgieron los sistemas de gestión de transacciones, cada uno de los cuales intentaba alcanzar una posición de liderazgo en la industria. Dentro de IBM, se eligieron CICS e IMS como productos estratégicos para abordar la necesidad de gestión de transacciones. Tanto en CICS como en IMS, cada uno tenía su versión de conmutación de mensajes, siendo IMS un sistema frontal en cola y CICS teniendo su función de datos transitorios como posible base para la conmutación de mensajes.

CICS se estableció como un popular sistema de gestión de transacciones en el período 1968-1971. Aquellos usuarios que habían adoptado TCAM por sus capacidades de manejo de mensajes ahora querían un uso combinado de TCAM con CICS. En diciembre de 1971, IBM anunció el soporte CICS de TCAM como parte del producto CICS/OS-Standard, que se entregaría en diciembre de 1972. A los clientes interesados, esto les permitió utilizar TCAM por sus ventajas en el manejo de mensajes y también tener terminales conectados a TCAM. o las computadoras interactúan con aplicaciones en línea CICS.

En enero de 1973, TCAM continuó siendo compatible con CICS/OS-Standard Versión 2.3. Sin embargo, el soporte de TCAM se omitió en la versión inicial de CICS/VS, anunciada en febrero de 1973 y entregada en junio de 1974. No hace falta decir que muchos clientes de CICS-TCAM no estaban contentos con esa dirección del producto.

Con una presión considerable por parte de los clientes de CICS-TCAM, el soporte CICS de TCAM se restableció en el producto CICS/VS 1.1, a partir de septiembre de 1974. Además del soporte DCB anterior, con este restablecimiento del soporte TCAM, CICS comenzó a Admite el acceso a TCAM a través de VTAM, también conocido como soporte ACB. El soporte de CICS TCAM ACB se suspendió a partir del producto CICS/ESA Versión 3 en 1990.

En 1992, IBM anunció un nuevo producto llamado MQSeries. Este nombre de marca fue renombrado posteriormente a WebSphere MQ (a veces acortado a WMQ) en 2002 para apoyar el nombre de la familia WebSphere y el producto. En 2014, se cambió el nombre de CCM IBM. MQ iba a ser la extensión de la funcionalidad TCAM de los sistemas IBM-únicamente a todas las otras plataformas. MQ tiene una arquitectura que permite a los sistemas heterogéneos comunicarse entre sí (por ejemplo, IBM, HP, Sun, Tandem, etc.). MQ se puede utilizar con sistemas CICS para enviar y recibir datos de cualquier otro sistema compatible con MQ. MQ se puede utilizar para iniciar el trabajo en un sistema CICS o una transacción CICS puede iniciar el trabajo en otro sistema CICS o no CICS.

IBM MQ ahora admite 80 entornos diferentes y se ha convertido en el producto de enrutamiento/conmutación de entrega segura de mensajes líder en la industria.

MQ y servicios web

IBM MQ se puede utilizar como base para crear arquitecturas orientadas a servicios. Existen varias opciones de productos adicionales para ayudar a convertir programas heredados en servicios web funcionales mediante el uso de MQ. Las empresas más grandes y heterogéneas a menudo aparecen como una federación de dominios algo autónomos basados en líneas de negocio, áreas funcionales o de gobernanza. En dichos entornos, algunos servicios pueden compartirse o reutilizarse sólo dentro de un único dominio, mientras que otros pueden compartirse o reutilizarse en toda la empresa. IBM MQ proporciona los medios por los cuales existe la comunicación entre líneas de negocio o dominios de negocio separados.

Un producto relacionado en la familia de productos IBM MQ, llamado IBM App Connect Enterprise (anteriormente IBM Integration Bus/WebSphere Message Broker) permite un conjunto diverso y sólido de extensiones para arquitecturas basadas en colas. Utilizando IBM Integration Bus, los usuarios pueden implementar una interfaz de servicios web, completa con soporte de archivos WSDL que puede interactuar con cualquier aplicación basada en colas.