Convenciones de nomenclatura de objetos WebSphere MQ

Question

¿Cuáles son las pautas recomendadas para las convenciones de nombres de WebSphere MQ para gestores de colas, colas (locales, remotas, transmisoras, colas de mensajes urgentes ...), canales, etc. Encontré una en IBM developerWorks pero buscando ver si hay algo más integral por ahí. Gracias.

Answer 1

Esto suena como un buen tema para una nueva columna Mission:Messaging pero escribiré aquí la versión condensada. Prefacio mi respuesta al señalar que muchas de mis recomendaciones son contrarias a las que puede encontrar en otros lugares. En algunos casos, esto se debe a que la forma en que MQ se usa comúnmente ha cambiado a lo largo de los años. En otros casos, es porque la sabiduría convencional nunca funcionó bien para empezar. (Por ejemplo, los canales de clúster denominados TO.QMGR). En todos los casos, prefiero las convenciones que se aplican al mayor número de situaciones. Eso significa que, por lo general, es posible encontrar excepciones a estas reglas para casos específicos, pero no obstante son ampliamente aplicables.

Algunas reglas generales
Lo siguiente se aplica a todos los tipos de objetos.

Utilice el carácter de punto . como separador.
Las reglas de autorización analizan los nombres usando caracteres de punto como separadores. Por ejemplo, el nombre de la cola MY.EXAMPLE.QUEUE.NAME coincidiría con las reglas como MY.*.*.* o MY.**, pero no con MY.* porque los puntos representan los caracteres del separador de nodos de nombre. Hágase un favor y use puntos en lugar de caracteres de subrayado como los separadores de nodo de nombres consistentemente.

Use nombres procesadores de máquina.
Cuando tiene 5 gestores de colas y algunos cientos de objetos, puede realizar fácilmente toda su administración manualmente con WMQ Explorer o runmqsc. Sin embargo, llega un punto en el que la coherencia, la confiabilidad, la repetibilidad y la eficiencia exigen que configure algunas de sus operaciones rutinarias o emplee instrumentación para responder a eventos de red. Más que nada, esto significa eliminar la ambigüedad en los nombres.

Por ejemplo, si crea una convención de nomenclatura que los nombres de los canales deben parecerse a SRCQMGR.DESTQMGR entonces es posible que una secuencia de comandos para leer un nombre de canal o RCVRSDR y derivar los nombres de los dos gestores de colas que conecta. Sin embargo, ¿qué hace el script con un nombre de canal como GA.PAYROLL.OPS? ¿Es el gestor de colas GA.PAYROLL que se conecta al administrador de colas OPS? ¿O es el administrador de colas GA que se conecta al administrador de colas PAYROLL.OPS? Un humano podría ser capaz de decirlo instantáneamente en función del contexto, pero los guiones son notorios por hacer lo que le dices en lugar de lo que pretendías. Situaciones similares surgen cuando los nombres de cola tienen calificadores dependientes de la posición tanto al principio como al final del nombre y una cantidad variable de nodos.

Pegue con los nombres MAYÚSCULAS.
Esto es para compatibilidad en todas las plataformas, y en particular z/OS. Si bien es cierto que más tiendas de z/OS usan mayúsculas y minúsculas, también es cierto que todavía hay muchos sistemas que solo aceptan nombres MAYÚSCULAS. Si bien es fácil decir "esto no se aplica a mí", he visto muchos casos en los que alguien tuvo problemas para comunicarse con un nuevo socio comercial debido a nombres incompatibles. Después de todo, la capacidad de interactuar con casi cualquier plataforma es una de las razones principales para usar WMQ en primer lugar.

No incluir atributos del objeto en el nombre
En un mundo SOA, colas y temas diferentes tipos de destino y, a menudo son intercambiables. Algo que pone mensajes a lo que cree que es una cola no necesariamente lo sabe (¡o le importa!) Si realmente van a una cola o un tema. Una cola que tiene una aplicación que está escuchando en ella para mensajes puede ser alimentada por una suscripción administrativa que realmente está enlazando publicaciones de uno o más temas.

Lo que realmente nos importa es la naturaleza de los mensajes, qué función desempeñan, no si nos estamos conectando a una cola local o una cola de alias. Por lo tanto, agregar calificadores como .QA, .QL, .TPC (para el tema) y así sucesivamente no tiene sentido. Del mismo modo, agregar .RCVR a un nombre de canal absorbe 5 caracteres útiles que podrían haberse utilizado mejor para describir el nombre de QMgr. Peor aún, estas prácticas hornean la topología en los nombres de los objetos, haciendo que el sistema sea menos flexible y más frágil.

nombres de los canales

Point-to-Point Channel nombres
Use nombres como SRCQMGR.DESTQMGR para RCVR, RQSTR, SDR y SVR canales. Esto está sesgada hacia los idiomas que se leen de izquierda a derecha porque la intención es describir el flujo de datos de un QMGR a otra QMGR

canales de racimo
Use nombres como CLUSNAME.QMNAME. La antigua sabiduría dice que usa nombres como TO.QMNAME, pero si alguna vez implementa clústeres superpuestos, esto hace que se use el mismo canal para múltiples clústeres. Eso es malo porque nunca puede realizar el mantenimiento en un clúster sin afectar al otro. El uso de CLUSNAME.QMNAME asegura que cada QMgr tenga un canal CLUSRCVR dedicado para cada clúster en el que participe.

canales de cliente
La excepción a los "no incluyen atributos del objeto en el nombre" es posiblemente el canal SVRCONN. Esto se debe a que los canales están muy vinculados a la capa física en lugar de lógica de la red. Así que poner el nombre de QMgr en un nombre de canal SVRCONN generalmente está bien. No me opongo demasiado si la gente también quiere agregar .SVRCONN al final.

Lo que hay que recordar sobre los canales de cliente es que si utiliza una tabla de definición de canal de cliente (CCDT), entonces el índice único en esa tabla es el nombre del canal. Eso significa que no puede tener el mismo nombre de canal en múltiples QMgrs y aún así usar un CCDT. Como el CCDT es una forma de configurar los detalles del canal SSL/TLS, a menudo no se lo aprecia al máximo hasta que aparece el proyecto "vamos a asegurar WMQ". Al usar nombres de canales únicos para los canales SVRCONN desde el principio, puede hacer que la red sea a prueba del futuro. Por lo general, estos nombres se parecen al APP.QMNAME o para que sea obvio que no se trata de un clúster o canal punto a punto, APP.QMNAME.SVRCONN o similar.

nombres de los gestores de colas

No hay puntos en los nombres QMGR
Una implicación de las reglas anteriores es que en racimo y del gestor de colas nombres deben contener sólo un nodo y por lo tanto nunca debe contener un carácter .. Esto se debe a que los nombres de los canales generalmente se derivan de los nombres del clúster y/o QMgr. Por lo tanto, en el ejemplo anterior, un nombre de canal RCVR como GA_PAYROLL.OPS le diría a humanos y scripts que el canal en cuestión conecta un QMgr llamado GA_PAYROLL con un QMgr llamado OPS.

Nombres de 9 caracteres o menos nombres de los canales
sólo pueden ser de 20 caracteres. Reste uno para el separador de puntos, divida entre dos y redondee hacia abajo para obtener un máximo de 9 caracteres para los gestores de colas. Si hay una posibilidad de que el usuario puede configurar diferentes canales para las clases de servicio (para grandes vs mensajes pequeños, por ejemplo, a continuación, colocar de nuevo a 8 caracteres o menos para los nombres QMGR. Esto lleva a QM1.QM2.A, QM1.QM2.B, etc.

Los nombres de QMgr reflejan la capa física
En un mundo orientado a servicios, realmente nos importan los nombres de destino como colas y temas. Nos importan menos los nombres de los gestores de colas porque son solo soporte de vida para colas y temas. No importa tanto acerca de que QMgr se conectan, siempre que puedan enviar solicitudes y recibir respuestas. WMQ llena muy convenientemente el nombre de la respuesta QMgr en las solicitudes salientes, por lo que Es raro que una aplicación necesite saber al respecto.

Por otro lado, los administradores deben conocer el nombre de QMgr. En los primeros días era común nombrar QMgrs para el servidor host. Más tarde se convirtió en la moda de nombrarlos para las aplicaciones que hospedaban. Ahora, en el mundo de SOA, la mensajería es una infraestructura y, por lo general, no está asociada a ninguna aplicación, por lo que el péndulo ha retrocedido. Proporcione al QMgr un nombre único que sea significativo para un administrador.

¡Nunca vuelva a utilizar los nombres de QMgr!
Desafortunadamente es muy común "mover" un QMgr de un lugar a otro o tener un QMgr primario y de recuperación de desastres con el mismo nombre. Esta práctica generalmente significa que una parte de la aplicación depende del nombre QMgr y, por lo tanto, es "más fácil" reutilizar el nombre. IBM introdujo el QMID como una forma de abordar algunos de los problemas introducidos al reutilizar los nombres de QMgr. El caso de uso típico es que un nodo se reconstruye y el QMgr una vez allí también se reconstruye desde cero. El clúster sabe que es un nuevo QMgr porque el QMID ha cambiado, pero el nombre utilizado para el enrutamiento y otras operaciones sigue siendo el mismo.

Aunque esto ayudó en ese caso de uso limitado, no aborda los problemas cuando ambos QMgrs con el mismo nombre están en línea al mismo tiempo. Tampoco aborda el problema de que una Autoridad certificadora acreditada no emita certs múltiples con el mismo Nombre distinguido que obliga a reutilizar el mismo certificado para múltiples QMgrs.

Recuerda que los QMgrs son solo soporte de vida para colas y temas, e idealmente serán anónimos para las aplicaciones que los utilizan. Elija una convención de nomenclatura que le permita girar nuevos QMgrs con nombres únicos por cientos o miles, si es necesario, para que no tenga que volver a utilizar los nombres de QMgr.

Otros objetos

utilizar nombres de intención de revelar
O, para decirlo de otra manera, el nombre del objeto para lo que hace y no lo que es . Por ejemplo, si tenía la costumbre (como muchas personas) de incluir calificadores como .QL para colas locales y .QA para alias, entonces cualquier cambio en la topología afectará las aplicaciones que usan esas colas. En su lugar, nombre las colas para las funciones que representan.

Ir a la izquierda a derecha, más genérica a nombres más específicos de objetos
, especialmente colas, debe construirse de forma jerárquica a partir de la clasificación más genérica y proceder a la clasificación más específica. Por ejemplo, muchas tiendas usan APP.FUNC.SUBFUNC.VER donde APP es la ID de la aplicación propietaria, luego uno o más nodos con la función y subfunción. Muchas tiendas agregan un calificador de versión al final para que las nuevas versiones de un servicio puedan migrar a sus clientes en horarios diferentes en lugar de cambiar el servicio en la cola existente y hacer que todos los clientes cambien al mismo tiempo.

Lo que lee los mensajes de propietario de la cola
Si tengo un extremo de servicio representada por una cola entonces hay una relación muchos-a-uno entre las cosas que podrían llamar al servicio de lo que ofrece el servicio. La cola está asociada con el servicio y la cosa que proporciona ese servicio. Los clientes son más o menos anónimos. Por lo tanto, si se puede decir que cualquiera de las aplicaciones de los interesados ​​"posee" la cola, es la aplicación del proveedor de servicios la que consume mensajes.

Lo que publica el mensaje posee el tema. Más o menos
La relación no es tan directa con los temas. Aquí son los consumidores de mensajes que generalmente son anónimos. En ese sentido, si el nombre del tema refleja cualquier aplicación, lo más probable es que sea el editor. Sin embargo, incluso los editores pueden ser anónimos, o al menos puede haber muchos de ellos y no todos publicando al mismo tiempo. Con los temas, tiene mucho más sentido que los nodos del árbol de temas estén estructurados para la jerarquía de datos o funcionalidad que representan. Estos nombres tienden a coincidir con los nombres de las aplicaciones de publicación, por lo que a veces el editor "posee" el tema tanto por casualidad como por cualquier otra cosa.

Ponga calificadores de posición de la izquierda
Cuando los nombres tienen un número variable de calificadores, poner los posicionales de la izquierda, donde las secuencias de comandos y automatización pueden analizar ellos. Algunas tiendas donde los calificadores de finalización y que comienzan son calificados posicionalmente al utilizar puntos de subrayado para separadores en la sección variable del nombre como APP.FUNC.SUBFUNC1_SUBFUNC2.VER. Los scripts y autorizaciones siempre ven un número fijo de nodos en el nombre, pero este enfoque puede ser frágil si alguien olvida y crea un nombre con un nodo adicional o dos.

Otras lecturas
Esto resume la mayor parte de las reglas generales, pero algunos de la filosofía detrás de ellos ha sido capturado en la Misión: la columna de mensajería.En particular:

• Embracing cultural change in the WebSphere MQ community
• Migration, failover, and scaling in a WebSphere MQ cluster
• El artículo Planning for SSL on the WebSphere MQ network discute distinguido estándares de nombres que se aplican a WMQ