|
IBM MQIBM 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 MQLos componentes core de MQ son los siguientes:
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íaMQ soporta mensajerías de los tipos punto-a-punto y Publicar-Suscribir. APILas API directamente soportadas por IBM incluyen las siguientes tecnologías:
API adicionales (no soportadas oficialmente), disponible vía terceros, incluye lo siguiente:
CaracterísticasOne-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ónLos Gestores de colas se comunican con el mundo exterior a través de los siguientes mecanismos:
Comunicación entre Gestores de colasEsto 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:
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 colasTipos de colas:
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. OrdenamientoA 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 colasLa 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. DisponibilidadIBM 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. HistoriaFechas de liberación de la versión
Fin de soporte de la versiónSe debe revisar el sitio web Soporte de Software del IBM Lifecycle para información actualizada.
Base arquitectónica de referenciaCon 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. [cita requerida] 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.[cita requerida] 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.[10] MQ y los servicios webIBM 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. Véase también
Referencias
Enlaces externos
|
Portal di Ensiklopedia Dunia
