IBM MQ es una familia de productos middleware orientados a mensajes que IBM lanzó en diciembre de 1993. Originalmente se llamaba MQSeries y en 2002 pasó a llamarse WebSphere MQ para unirse a la suite de productos WebSphere . En abril de 2014, pasó a llamarse IBM MQ . Los productos que se incluyen en la familia MQ son IBM MQ, IBM MQ Advanced, IBM MQ Appliance, IBM MQ for z/OS e IBM MQ on IBM Cloud. IBM MQ también tiene opciones de implementación en contenedores.
MQ permite que aplicaciones independientes y potencialmente no concurrentes 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 .
Los componentes principales de MQ son:
Los programas integrados con IBM MQ utilizan una interfaz de programa de aplicación (API) consistente en todas las plataformas.
MQ admite mensajería punto a punto y de publicación-suscripción .
Las API admitidas directamente por IBM incluyen:
También hay API adicionales (no compatibles oficialmente) disponibles a través de terceros, entre las que se incluyen:
Entrega única : MQ utiliza la entrega única. Esta calidad de servicio generalmente 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. Los mensajes se pueden enviar 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 manera predeterminada, este es el orden de recepción FIFO en la cola local dentro de la prioridad del mensaje.
Transformación de datos : por ejemplo, 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 que ejecuta el software IBM MQ en el momento en que se necesita la transformación de datos.
Marco de arquitectura basado en mensajes : IBM MQ permite la recepción de mensajes para "activar" la ejecución de otras aplicaciones.
Gama de API : Implementa la API estándar de Java Message Service (JMS) y también tiene su propia API, conocida como Message Queuing Interface (MQI), que precedió a JMS durante varios años. A partir de la versión 8.0.0.4, MQ también admite la API MQ Light.
Agrupamiento : múltiples implementaciones de MQ comparten el procesamiento de mensajes, lo que proporciona equilibrio de carga.
Los gestores de colas se comunican con el mundo exterior a través de:
Esto depende de 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:
Cuando un canal receptor recibe un mensaje, se examina para ver a qué gestor de colas y a qué cola está destinado. En caso de que se produzca un fallo de comunicación, MQ puede restablecer automáticamente una conexión cuando se resuelva el problema.
El receptor es la interfaz de red de la aplicación con el gestor de colas. El receptor detecta las conexiones de los canales entrantes y gestiona la conexión de los canales de envío con los canales de recepción. En una red TCP/IP, el receptor "escuchará" las conexiones en un puerto específico.
Tipos de cola:
Un mensaje se coloca en una cola remota. El mensaje va 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 administrador de colas receptor examina el mensaje para determinar si el mensaje es para sí mismo o si debe ir a otro administrador de colas. Si el administrador de colas receptor es el administrador de colas receptor, se verificará la cola requerida y, si existe, el mensaje se coloca en esta cola. Si no, el mensaje se coloca en la cola de mensajes no entregados . MQ tiene características para administrar la transmisión eficiente de datos a través de una variedad de medios de comunicación. Por ejemplo, los mensajes se pueden agrupar juntos hasta que una cola alcance una profundidad particular.
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 en 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; además, si la secuencia es crítica, es responsabilidad de la aplicación colocar los datos de la secuencia en el mensaje o implementar un mecanismo de protocolo de enlace a través de una cola de retorno. En realidad, el orden se mantendrá en configuraciones sencillas.
El otro elemento de un gestor 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 fallo, el registro se utiliza para recrear objetos dañados y mensajes. Solo se recrean los mensajes persistentes cuando se produce un fallo; los mensajes "no persistentes" se pierden. Los mensajes no persistentes se pueden enviar a través de un canal configurado en modo rápido, en el que no se garantiza la entrega en caso de fallo del canal.
MQ admite tanto el registro circular como el lineal.
Se puede recuperar información de las colas sondeando la cola para verificar si hay datos disponibles en intervalos adecuados o, alternativamente, MQ puede activar un evento, lo que permite que una aplicación cliente responda a la entrega de un mensaje.
IBM MQ ofrece una variedad de soluciones para satisfacer la disponibilidad:
Administrador de cola de datos replicados (RDQM / 'Easy HA' - MQ Advanced solo en distribuidos): replicación sincrónica entre tres servidores que comparten una dirección IP flotante.
Clústeres de administradores de colas: 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 que las colas se compartan entre ellos para equilibrar la carga y lograr 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 administradores de colas dentro del grupo de uso compartido de colas. Debido a que todos los administradores 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 administrador de colas en particular. Esto brinda mayor disponibilidad si un administrador de colas se detiene porque todos los demás administradores de colas del grupo de uso compartido de colas pueden continuar procesando la cola.
Gestores de colas de varias instancias (disponibles a partir de la versión 7.0.1): se configuran instancias del mismo gestor de colas en dos o más equipos, y sus colas y metadatos residen en un almacenamiento compartido. Al iniciar varias instancias, una se convierte en la instancia activa y las demás se convierten en instancias de reserva. Si la instancia activa falla, una instancia de reserva que se ejecuta en un equipo diferente toma el control automáticamente.
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 se indican en la tabla. [11]
Con la llegada de las computadoras, IBM vio la oportunidad de aplicar nueva tecnología a la necesidad de conmutación de mensajes.
A principios de la década de 1960, IBM comercializó el sistema de control de comunicaciones IBM 7740 y el control de transmisión programado IBM 7750, que eran sistemas de conmutación de mensajes programables.
El IBM System/360 se anunció en abril de 1964 y con él llegaron los métodos de acceso a las comunicaciones como BTAM y QTAM (Basic and Queued Telecommunications Access Methods). 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 corretaje. Admitía mensajería asincrónica, como con el posterior MQ. TCAM 3.0 agregó colas de mensajes de disco reutilizables para recuperación poco después, como con MQ. Se podía utilizar un programa PL/I de alto nivel para acceder a conjuntos de datos TRANSIENT (colas de mensajes dinámicos). La lectura de un mensaje de un conjunto de datos transitorio resultó en la eliminación de ese mensaje de la cola, como con una LECTURA sin exploración con MQ.
A finales de los años 70, surgieron los sistemas de gestión de transacciones, cada uno de los cuales intentaba alcanzar una posición de liderazgo en la industria. En 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 de colas de interfaz y CICS con su función de datos transitorios como posible base para la conmutación de mensajes. [ cita requerida ]
CICS se estableció como un sistema de gestión de transacciones popular 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 de CICS para TCAM como parte del producto CICS/OS-Standard, que se entregaría en diciembre de 1972. Para los clientes interesados, esto les permitió utilizar TCAM por sus ventajas en el manejo de mensajes y también tener terminales o computadoras conectadas a TCAM que interactúen con aplicaciones en línea de CICS. [ cita requerida ]
En enero de 1973, TCAM siguió recibiendo soporte de la versión estándar 2.3 de CICS/OS. Sin embargo, la compatibilidad con TCAM se omitió en la versión inicial de CICS/VS, anunciada en febrero de 1973 y entregada en junio de 1974. Huelga decir que muchos clientes de CICS-TCAM no estaban contentos con esa dirección del producto.
Debido a la considerable presión de los clientes de CICS-TCAM, el soporte de CICS para 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 de TCAM, CICS comenzó a admitir el acceso a TCAM a través de VTAM, también conocido como soporte ACB. El soporte de CICS TCAM ACB se interrumpió a partir del producto CICS/ESA versión 3 en 1990.
En 1992, IBM anunció un nuevo producto llamado MQSeries. Esta marca fue posteriormente renombrada como WebSphere MQ (sin embargo, su nombre corto oficial siguió siendo MQ) en 2002 para dar soporte al nombre de la familia WebSphere y al producto. En 2014, fue renombrado IBM MQ. MQ iba a ser la extensión de la funcionalidad TCAM de los sistemas exclusivos de IBM a todas las demás plataformas. MQ tiene una arquitectura que permite que los sistemas heterogéneos se comuniquen entre sí (por ejemplo, IBM, HP, Sun, Tandem, etc.). MQ se puede utilizar con sistemas CICS para enviar y recibir datos hacia/desde cualquier otro sistema elegible para 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 soporta 80 entornos diferentes y se ha convertido en el producto líder de conmutación/enrutamiento de entrega asegurada de mensajes en la industria. [12]
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 gobierno. En dichos entornos, algunos servicios pueden compartirse o reutilizarse solo 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 empresariales separados.
Un producto relacionado de la familia de productos IBM MQ, denominado 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. Mediante IBM Integration Bus, los usuarios pueden implementar un front-end de WebServices, completo con soporte de archivos WSDL que puede interactuar con cualquier aplicación basada en colas.
