IBM MQ
# IBM MQ

IBM MQ es una familia de productos de middleware de mensajería que IBM lanzó en diciembre de 1993. IBM MQ fue originalmente llamado MQSeries, y fue rebautizado como WebSphere MQ en 2002 para unificar un conjunto de productos en la suite WebSphere. En abril de 2014, volvió a cambiar de nombre a IBM MQ. Los productos que está 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.

MQ permite que aplicaciones independientes y potencialmente no concurrentes en un sistema distribuido puedan comunicarse con seguridad con otras, usando mensajes. MQ está disponible sobre un gran número de plataformas (tanto IBM como no IBM), incluyendo z/OS (mainframe), OS/400 (IBM System i o AS/400), TPF, UNIX (AIX, HP-UX, Solaris), HP NonStop, OpenVMS, Linux, y Windows de Microsoft.

## Componentes MQ

Los componentes core de MQ son los siguientes:

* Mensaje: Los mensajes son colecciones de datos binarios o de carácter (para caso ASCII o EBCDIC) que tienen algún significado para un programa participante. Al igual que en otros protocolos de comunicaciones, acciones de almacenamiento, encaminamiento, y entrega de información son añadidas al mensaje antes de que transmisión y retirados del mensaje antes de su entrega a la aplicación receptora.
* Cola: Las colas de mensajes son objetos que almacenan mensajes en una aplicación.
* Gestor de colas: Se refiere a un servicio del sistema que provee un contenedor lógico para la cola de mensajes. Es responsable de transferir los datos a otro gestor de colas vía canales de mensajería. A pesar de que no es estrictamente requerido para los middleware de mensajería, sí lo es para IBM MQ. Los gestiones de colas gestionan almacenamiento, temporalidad de eventos, triggering, y todas las otras funciones no directamente relacionadas al propio movimiento de datos.

Los programas integrados con IBM MQ usan una interfaz de programa de aplicación (API) consistente y compatible a través de todas las plataformas para las que está disponible.

## Tipos de mensajería

MQ soporta mensajerías de los tipos punto-a-punto y Publicar-Suscribir.

## API

Las API directamente soportadas por IBM incluyen las siguientes tecnologías:

* IBM Message Queue Interface (MQI) para C, COBOL, PL/I, Java, Rexx, RPG, y C++
* Java Servicio de mensaje (JMS)
* XMS para C/C++ y .NET
* .NET
* Transferencia de Estado Representacional
* SOAP

API adicionales (no soportadas oficialmente), disponible vía terceros, incluye lo siguiente:

* Perl (desarrollado por Hildo Biersma), disponible de CPAN.
* Python (lenguaje de programación) interfaz PyMQI (originalmente desarrollado por Les Smithson), disponible de PyPI
* Windows PowerShell

## Características

One-time delivery: MQ realiza entregas de una sola vez. Esta calidad del servicio típicamente previene pérdida de mensajes o duplicidades.

Mensajería asíncrona: MQ provee a los diseñadores de aplicaciones un mecanismo para conseguir una arquitectura sin dependiente del tiempo. Los mensajes se pueden enviar de una aplicación a otra, sin importar sin las aplicaciones están en ejecución al mismo tiempo. Si una aplicación receptora de mensajes no está en ejecución cuando un enviador envía un mensaje, el Gestor de colas contendrá el mensaje hasta que el receptor lo pida. El orden de todos los mensajes queda preservado, por defecto, esto es en orden FIFO de recepción en la cola local dentro de la prioridad del mensaje.

Transformación de datos: Por ejemplo, de Big Endian a Little Endian, o EBCDIC a ASCII. Esto se consigue a través del uso de salidas de datos del mensaje. Las salidas son aplicaciones compiladas que se ejecutan en el Gestor de colas anfitrión, y son ejecutados por el software IBM MQ en el momento que se requiere la transformación de los datos.

Framework de arquitectura dirigido por mensajes: IBM MQ permite recibir mensajes para gatillar la ejecución de otras aplicaciones.

Gama de API: Se implementa el Java Message Service (JMS) API estándar, y también tiene su propio API propietario, conocido como la interfaz de encolamiento de mensajes (MQI), el cual precedió al JMS en algunos años de existencia. A partir de la versión 8.0.0.4, MQ también soporta la API MQ Light.

Clustering: Múltiples implementaciones MQ comparten el procesamiento de mensajes, proporcionando equilibrado de carga.

## Comunicación

Los Gestores de colas se comunican con el mundo exterior a través de los siguientes mecanismos:

* Bindings: Una conexión directa de software. Generalmente más rápida, pero limitada a los programas que corren en el mismo anfitrión físico que el Gestor de colas.
* Una conexión de red o "cliente": Las aplicaciones que utilizan una conexión cliente puede conectarse a un Gestor de colas en cualquier otro anfitrión en la red. La localización física del Gestor de colas es entonces irrelevante, mientras sea alcanzable a través de la red.

### Comunicación entre Gestores de colas

Esto se apoya 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; un segundo canal es requerido para devolver los datos. En una red basada en TCP/IP, un canal envía o recibe datos en un puerto específico.

Tipos de canal:

* Canal de envío: Tiene un destino definido y está asociado con una cola de transmisión específica (el mecanismo por el cual los mensajes esperan la transmisión sobre el canal).
* Canal de recepción: Recibe los datos desde cualquier otro Gestor de colas con una canal de envío del mismo nombre.

Cuando un canal de recepción recibe un mensaje, este es examinado para ver qué Gestor de colas y Cola es la destinataria. En el evento de un fallo en la comunicación, MQ puede restablecer automáticamente una conexión en cuanto se resuelve el problema.

El listener es la interfaz de red de la aplicación hacia el Gestor de colas. El listener detecta conexiones desde canales entrantes, y gestiona la conexión de los canales de envío hacia los canales de recepción. En una red TCP/IP, el listener "escuchará" las conexiones en un puerto específico.

### Transmisión de datos de una cola a otro Gestor de colas

Tipos de colas:

* Cola local: representa la localización de los datos que están almacenados y a la espera de su procesamiento.
* Cola remota: representa una cola en otro Gestor de colas. La misma define la cola de destina, el cual es un elemento del mecanismo de encaminamiento de mensajes.
* Clúster de colas: representa una cola que es alcanzable vía cualquier Gestor de colas en su clúster.

Un mensaje es colocado 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 es transmitido a través del canal remoto. Si la transmisión es exitosa, el mensaje queda eliminado de la cola de transmisión. En la recepción del mensaje, el Gestor de colas receptor examina los mensajes para determinar si es mensaje es para sí mismo o si debe ir a otro Gestor de colas. Si el Gestor de colas es el receptor, la cola requerida será revisada, y si existe, el mensaje es colocado en esta cola. Si no, el mensaje es colocado en la dead letter queue. MQ tiene características para gestionar de forma eficiente la transmisión de datos sobre una variedad de medios de comunicación. Por ejemplo, los mensajes pueden ser agrupados juntos hasta una cola alcance una profundidad en particular.

### Ordenamiento

A pesar de que la cola es FIFO, está ordenada sobre la base de la recepción en la cola local, no el compromiso del mensaje desde el enviador. Los mensajes pueden ser priorizados, y por defecto, la cola está priorizado por orden de llegada. Las colas solo estarán en secuencia de adición si el mensaje es añadido localmente. Se puede usar el agrupamiento de mensajes para asegurar que un conjunto de mensajes está en un orden específico. A la par, en caso la secuencia sea crítica, es responsabilidad de la aplicación el colocar la secuencia de datos en el mensaje o implementar un mecanismo de handshaking vía una cola de retorno. En la realidad, el ordenamiento será mantenido en configuraciones normales.

### El registro (log)

El otro elemento de un Gestor de colas es el registro de log. Cuando el mensaje es colocado en una cola o se realiza un cambio en la configuración, los datos también son registrados en el log. Ante un evento de fallo, el log es usado para recrear objetivos dañados y recrear mensajes. Solo los mensajes persistentes son recreados cuando un ocurre un fallo, los mensajes no persistentes se pierden. Los mensajes no persistentes pueden ser enviados a través de un canal configurado con un modo rápido, en el que la entrega no está asegurada en el caso de un fallo en el canal.

MQ soporta tanto registro en log circular y lineal.

### Recuperación de mensajes de las colas

La información puede ser recuperada desde las colas, bien vía polling de la cola para revisar por datos disponibles en intervalos apropiados, o bien, alternativamente, MQ puede provocar un evento, permitiendo a la aplicación cliente responder a la entrega de un mensaje.

## Disponibilidad

IBM MQ ofrece una variedad de soluciones para proveer disponibilidad sobre las aplicaciones que se desarrollen:

Replicated Dato Queue Director (RDQM / 'Easy HA'- MQ Advanced on distributed only): Replicación síncrona entre tres servidores que comparten entre todos una dirección de IP flotante.

Clúster de Gestor de colas: Los grupos de dos o más gestores de colas sobre uno o más servidores son definidos como un clúster, proporcionando interconexión automática, y permitiendo que las colas se compartan entre ellas para equilibrado de carga y redundancia.

Compartición de grupos de colas (solo z/OS ): En un entorno de colas compartidas, una aplicación puede conectar a cualquiera de los Gestores de colas dentro del grupo de compartición de colas. Dado que todos los Gestores de colas en el grupo de compartición de colas pueden acceder al mismo conjunto de compartido colas, la aplicación no depende de la disponibilidad de un Gestor de colas en particular. Esto da una gran disponibilidad si un Gestor de colas se detiene, porque todos los otros Gestores de colas en el grupo puede continuar procesando la cola.

Multi-instance Queue Maganers (disponibles desde v7.0.1): Instancias del mismo Gestor de colas son configurados en dos o más servidores con sus colas y sus metadatos residiendo en un almacenamiento compartido. Al iniciar múltiples instancias, una instancia se vuelve la instancia activa y las otras se ponen en espera. Si la instancia activa falla, una instancia en espera que se esté ejecutando en un servidor diferentes, automáticamente toma el control.

## Historia

### Fechas de liberación de la versión

| Nombre de versión | Fecha de liberación |
| - | - |
| IBM MQ 9.1 LTS | 27 de julio de 2018 |
| IBM MQ encima Nube de IBM | 13 de marzo de 2018 |
| IBM MQ para HPE Nonstop 8.0 | 23 de junio de 2017 |
| IBM MQ 9.0 LTS | 2 de junio de 2016 |
| IBM MQ 8.0 | 23 de mayo de 2014 |
| WebSphere MQ 7.5 | 15 de junio de 2012 |
| WebSphere MQ 7.1 | Noviembre 2011 |
| WebSphere MQ 7.0 z/OS | Junio 2008 |
| WebSphere MQ 7.0 (Distribuido, iSeries) | Mayo 2008 |
| WebSphere MQ 6.0 z/OS | Junio 2005 |
| WebSphere MQ 6.0 (Distribuido, iSeries) | Mayo 2005 |
| WebSphere MQ 5.3 z/OS | Junio 2002 |
| WebSphere MQ 5.3 (Distribuido, iSeries) | Junio, julio, Oct, Nov 2002 |
| MQSeries 5.2 (distribuido) | Diciembre de 2000 |
| MQSeries Para OS/390 V5.2 | Noviembre de 2000 |
| MQSeries Para CUANDO/400 V5.1 | Julio-agosto de 2000 |
| MQSeries Para OS/390 V2.1 | Febrero de 1999 |
| MQSeries 5.1 | Abril (NT), junio de 1999 |
| MQSeries Para CUANDO/400 V4.2 | Febrero de 1998 |
| MQSeries 5.0 | Octubre de 1997 |
| MQSeries Para MVS/ESA 1.2 | 29 de agosto de 1997 |
| MQSeries Para MVS 1.1.4, | Junio de 1996 |
| MQSeries 2.2 (Sol OS/Solaris, DC/OSx) | Junio, julio de 1996 |
| MQSeries 2.0 Windows NT | 2Q 1996 |
| MQSeries 2.2 (HP, SCO) | 4Q 1995 |
| MQSeries Para MVS 1.1.3 | Mayo de 1995 |
| MQSeries 2.0 (OS/2, AIX) | Febrero de 1995 (el principio del fin de ezBridge) |
| MQM/400 V3 | 4Q 1994 |
| ezBridge Tramita para MQSeries 3.0 | Julio 1994 |
| MQSeries Para MVS 1.1.2 | Junio 1994 |
| MQM/400 V2.3 | Febrero/abril 1994 |
| ezBridge Tramita para MQSeries | Marzo, Sept, Nov, DSA |
| MQSeries Para MVS V1.1.1 | 31 de diciembre de 1993 |

### Fin de soporte de la versión

Se debe revisar el sitio web Soporte de Software del IBM Lifecycle para información actualizada.

| Nombre de versión | Disponibilidad general | Fin de Comercialización | Fin de Soporte |
| - | - | - | - |
| IBM MQ 9.1 | 23-Jul-2018 | - | - |
| IBM MQ 9.0 | 02-Jun-2016 | 17-Sep-2021 | 30-Sep-2021 |
| IBM MQ 8.0 | 13-Jun-2014 | 17-Apr-2020 | 30-Apr-2020 |
| WebSphere MQ 7.5 | 06-Jul-2012 | 16-Dec-2016 | 30-Apr-2018 |
| WebSphere MQ 7.1 | 25-Nov-2011 | 12-Jul-2016 | 30-Apr-2017 |

### Base arquitectónica de referencia

Con el advenimiento de las computadoras, IBM vio una oportunidad de aplicar nueva tecnología a la necesidad para el switching de mensajes.

A inicios de la década de 1960, IBM comercializaba el IBM 7740 Communication Control System y el IBM 7750 Programmed Transmission Control, los cuales eran sistemas programables de switching de mensajes.

El Sistema de IBM/360 estuvo anunciado en abril de 1964 y con llegada de métodos de acceso de comunicación como BTAM y QTAM (Basic and Queued Telecommunications Access Methods). En 1971, TCAM (Telecommunications Access Method), ofrecía a sus usuarios una forma más avanzada de switching o encaminamiento de mensajes. TCAM fue ampliamente aceptado, especialmente en industrias financieras y de seguros. TCAM soportaba mensajería asíncrona, al igual que posteriormente MQ. TCAM 3.0 añadió el guardado en disco de las colas de mensajes para su recuperación poco después, como con MQ. Un programa de alto nivel de PL/I podría se usar para acceder a datasets transitorios (colas dinámicas de mensajes). La lectura de un mensaje de un dataset transitorio resultó en que el mensaje es removido de la cola, como con un READ non-browse con MQ.

A finales de la década de 1970, los sistemas de gestión transaccional llegaron, cada uno intentando conseguir una posición de liderazgo en la industria. Dentro de IBM, CICS e IMS fueron escogidos como productos estratégicos para dirigir la necesidad para la gestión de transacciones. Tanto CICS como IMS, tuvieron sus propias versiones de switching de mensajes, IMS como un sistema de colas en el front-end y CICS como su facilidad de Datos Transitorios como una posible base para el switching de mensajes.

CICS se estableció como un popular sistema de administración de transacciones entre los años 1968 y 1971. Aquellos usuarios que había adoptado TCAM para su gestión de capacidades de mensajería, ahora querían un uso combinado de TCAM con CICS. En diciembre de 1971, IBM anunció soporte CICS de TCAM como parte del producto estándar CICS/OS, para ser entregado en diciembre de 1972. Para clientes interesados, esto les permitió utilizar TCAM para su gestión de mensajería y también tener terminales conectadas a TCAM o interfaces de computadoras con aplicaciones CICS en línea.

En enero de 1973, TCAM continuó siendo soportado por la versión estándar 2.3 de CICS/OS. No obstante, el soporte de TCAM fue omitido desde la liberación inicial de CICS/VS, anunciado en febrero de 1973 y entregado en junio de 1974. Cabe precisar que muchos clientes de CICS-TCAM no estuvieron conformes con aquella dirección que llevó el producto.

Con la presión considerable de los clientes de CICS-TCAM, el soporte CICS de TCAM fue restablecido en el producto CICS/VS 1.1, en septiembre de 1974. Además del anterior soporte DCB, con este restablecimiento del soporte de TCAM, CICS empezó a soportar el acceso TCAM vía VTAM, también conocido como el soporte ACB. El soporte ABC de CICS TCAM fue descontinuado en la versión 3 en 1990.

En 1992, IBM anunció un nuevo producto nuevo llamado MQSeries. Este nombre de marca fue más tarde rebautizado como WebSphere MQ (a veces acortado a WMQ) en 2002 para apoyar el nombre familiar WebSphere y el producto. En 2014, fue nuevamente renombrado como IBM MQ. MQ era para ser la extensión de la funcionalidad de TCAM desde sistemas sólo de IBM a todas las demás plataformas. MQ tiene una arquitectura que habilidad a sistemas heterogéneos la comunicación entre ellos (ejemplo: IBM, HP, Sol, Tándem, etc.). MQ puede ser utilizado con sistemas CICS para enviar y recibir datos a/de cualquier otro sistemas MQ elegible. MQ Puede ser usar para inicializar trabajo en un sistema CICS o una transacción CICS puede inicializar trabajo en otro sistemas CICS o no CICS.

En la actualidad, IBM MQ soporta 80 entornos diferentes y se ha convertido en el líder de entrega asegurada y switching/enrutamiento de mensajes en la industria.

## MQ y los servicios web

IBM MQ puede ser utilizado como una base para la creación de arquitecturas orientadas a servicios. Varias opciones de producto adicionales existen para ayudar a convertir aplicaciones legacy como backend de servicios web a través del uso de MQ. Empresas más grandes y heterogéneas a menudo aparecen como federación de dominios autónomos en cierta manera basados en líneas de negocio, funcionales o áreas de gobierno. En tales entornos, algunos servicios pueden ser compartidos o reutilizados solo dentro de un dominio único, mientras que otros podrían ser compartidos o reutilizados a otros servicios de la empresa. IBM MQ proporciona el medio por el cual exista la comunicación entre líneas de negocio o otros dominios separados de negocio.

Un producto relacionado en la familia de productos IBM MQ, llamada IBM Integration Bus (anteriormente WebSphere Message Broker), habilita un conjunto diverso y robusto de extensiones a arquitecturas basadas en colas. Utilizando el IBM Integration Bus, los usuarios pueden implementar un front-end basado en servicios web, completo con soporte a archivos WSDL que pueden interactuar con cualquier otra aplicación basada en colas.

