IBM MQ

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 los datos. En una red basada en TCP/IP, un canal envía o recibe datos a través de un puerto específico.

Tipos de canales:

• Canal de envío : tiene un destino definido y está asociado a una cola de transmisión específica (el mecanismo mediante el cual los mensajes se ponen en cola a la espera de ser transmitidos por el canal).
• Canal receptor : recibe datos de cualquier otro gestor de colas con un canal emisor del mismo nombre.

Cuando un canal receptor recibe un mensaje, lo examina para determinar a qué gestor de colas y cola está destinado. En caso de fallo de comunicación, MQ puede restablecer automáticamente la conexión una vez resuelto el problema.

El oyente es la interfaz de red de la aplicación con el gestor de colas. El oyente detecta las conexiones de los canales entrantes y gestiona la conexión de los canales emisores con los receptores. En una red TCP/IP, el oyente estará a la espera de conexiones en un puerto específico.

Tipos de cola:

• Cola local : representa la ubicación donde se almacenan los datos a la espera de ser procesados.
• Cola remota : representa una cola en otro gestor de colas. Define la cola de destino, que es un elemento del mecanismo de enrutamiento de mensajes.
• Cola de clúster : representa una cola a la que se puede acceder a través de cualquier gestor de colas en su clúster.

Un mensaje se coloca en una cola remota. El mensaje va a una cola de transmisión de almacenamiento temporal asociada a 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 la cola receptora lo examina para determinar si el mensaje es para sí mismo o si debe ir a otro administrador de cola. Si el administrador de la cola receptora encuentra la cola requerida, se verificará y, si existe, el mensaje se coloca en ella. De lo contrario, el mensaje se coloca en la cola de mensajes no entregados . MQ tiene funciones 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 hasta que una cola alcance una profundidad determinada.

Aunque la cola es FIFO (primero en entrar, primero en salir), se ordena según la recepción en la cola local, no según la confirmación del mensaje por parte del remitente. Los mensajes pueden priorizarse y, por defecto, la cola se prioriza según el orden de llegada. Las colas solo se ordenarán secuencialmente si el mensaje se agrega localmente. Se puede usar la agrupación de mensajes para asegurar que un conjunto de mensajes se encuentre en un orden específico; además, si el orden es crítico, es responsabilidad de la aplicación incluir los datos de secuencia en el mensaje o implementar un mecanismo de confirmación mediante una cola de retorno. En la práctica, el orden se mantendrá en configuraciones sencillas.

El otro elemento de un gestor de colas es el registro . Cuando 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 los objetos dañados y los mensajes. Solo se recrean los mensajes persistentes cuando se produce un fallo; los mensajes no persistentes se pierden. Los mensajes no persistentes pueden enviarse 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.

La información se puede recuperar de las colas consultando periódicamente la cola para comprobar si hay datos disponibles, o bien MQ puede activar un evento, lo que permite que una aplicación cliente responda a la entrega de un mensaje.

La siguiente tabla se aplica al software MQ. El dispositivo MQ tiene fechas de ciclo de vida diferentes tanto para el firmware como para el hardware que las que se muestran en la tabla. ^{[ 15 ]}

Con la llegada de los ordenadores, IBM vio la oportunidad de aplicar nuevas tecnologías 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 sistema de control de transmisión programada IBM 7750, que eran sistemas programables de conmutación de mensajes.

El IBM System/360 se anunció en abril de 1964, y con él llegaron métodos de acceso a la comunicación como BTAM y QTAM (Métodos Básicos y de Cola de Acceso a las Telecomunicaciones). En 1971, TCAM ( Método de Acceso a las Telecomunicaciones ) ofreció a sus usuarios una forma más avanzada de conmutación o enrutamiento de mensajes. TCAM tuvo una gran aceptación, especialmente en los sectores financiero y de corretaje. Admitía mensajería asíncrona, al igual que el posterior MQ. TCAM 3.0 añadió poco después colas de mensajes en disco reutilizables para su recuperación, al igual que MQ. Se podía utilizar un programa PL/I de alto nivel para acceder a conjuntos de datos TRANSIENT (colas de mensajes dinámicas). La lectura de un mensaje de un conjunto de datos transitorio provocaba su eliminación de la cola, como ocurría con una lectura sin exploración en MQ.

A finales de la década de 1970, surgieron los sistemas de gestión de transacciones, cada uno buscando posicionarse como líder en el sector. Dentro de IBM, CICS e IMS fueron elegidos como productos estratégicos para satisfacer la necesidad de gestión de transacciones. Tanto CICS como IMS contaban con su propia versión de conmutación de mensajes: IMS era un sistema de colas de interfaz y CICS utilizaba su funcionalidad de datos transitorios como base para la conmutación de mensajes.

CICS se consolidó como un sistema de gestión de transacciones muy popular entre 1968 y 1971. Los usuarios que habían adoptado TCAM por sus capacidades de gestión de mensajes ahora deseaban combinar TCAM con CICS. En diciembre de 1971, IBM anunció la compatibilidad de CICS con TCAM como parte del producto CICS/OS-Standard, que se lanzaría en diciembre de 1972. Para los clientes interesados, esto les permitía aprovechar las ventajas de TCAM en la gestión de mensajes y, además, conectar terminales o computadoras con TCAM a las aplicaciones en línea de CICS.

En enero de 1973, CICS/OS-Standard versión 2.3 seguía ofreciendo soporte para TCAM. Sin embargo, este soporte se omitió en la versión inicial de CICS/VS, anunciada en febrero de 1973 y lanzada en junio de 1974. Como era de esperar, muchos clientes de CICS-TCAM no quedaron satisfechos con esta decisión.

Debido a la considerable presión de los clientes de CICS-TCAM, la compatibilidad de CICS con TCAM se restableció en el producto CICS/VS 1.1 en septiembre de 1974. Además de la compatibilidad previa con DCB, con este restablecimiento de la compatibilidad con TCAM, CICS comenzó a admitir el acceso a TCAM a través de VTAM, también conocido como compatibilidad con ACB. La compatibilidad de CICS TCAM ACB se suspendió a partir de la versión 3 del producto CICS/ESA en 1990.

En 1992, IBM anunció un nuevo producto llamado MQSeries. Esta marca se renombró posteriormente a WebSphere MQ (aunque su nombre abreviado oficial siguió siendo MQ) en 2002 para respaldar la familia de productos WebSphere. En 2014, se renombró a IBM MQ. MQ se concibió como la extensión de la funcionalidad TCAM de los sistemas exclusivos de IBM a todas las demás plataformas. MQ cuenta con una arquitectura que permite la comunicación entre sistemas heterogéneos (por ejemplo, IBM, HP, Sun, Tandem, etc.). MQ puede utilizarse con sistemas CICS para enviar y recibir datos desde y hacia cualquier otro sistema compatible con MQ. MQ puede utilizarse para iniciar tareas en un sistema CICS, o bien una transacción CICS puede iniciar tareas en otro sistema, ya sea CICS o no.

IBM MQ ahora admite 80 entornos diferentes y se ha convertido en el producto líder de conmutación/enrutamiento de entrega garantizada de mensajes en la industria. ^{[ 16 ]}