Datum
18.10.2011
Dieser Beitrag wurde verfasst von:
Was kann man an einem fast perfekten Produkt, wie WebSphere MQ noch verbessern? Das habe ich mich vor der IBM WebSphere Technical Conference 2011 gefragt und war verblüfft, was für Neuerungen die IBM Entwickler aus Hursley & Co diesmal auf die Beine gestellt haben. Dies ist der erste Teil eines zweiteiligen Blogeintrages.
Es ist nun möglich bis zu 128 WebSphere MQ Installationen gleichzeitig auf einem System zu betreiben. Diese hohe Zahl wird wohl in den seltensten Fällen benötigt, es gibt aber viele Anwendungsfälle, in denen man mehr als eine WebSphere MQ Installation benötigt. Der erste Anwendungsfall besteht darin, dass man eine WebSphere MQ Installation in der Version 7.1 installiert hat, auf der ein Queue Manager läuft. Nun möchte man die Version 7.1.0.1 installieren, möchte aber sicher gehen, dass man bei jeglichen Problemen, die auf die neue Version zurückzuführen sind, schnell wieder auf die alte, lauffähige Version wechseln kann.
Der zweite Anwendungsfall besteht darin, die Downtime des Queue Managers und damit verbunden die Downtime der Applikationen, die diesen Queue Manager nutzen bei einer Migration, so gering, wie möglich zu halten. Früher musste die alte WebSphere MQ Installation erst komplett entfernt werden, bevor eine neue Version aufgespielt werden konnte. Während des ganzen Prozesses mussten alle Applikationen inaktiv sein. Nun ist es aber möglich die Installation und Konfiguration von der neuen WebSphere MQ Version schon durchzuführen, während die andere WebSphere MQ Version noch aktiv ist. Die Applikationen müssen lediglich für die Zeit inaktiv sein, in der die Queue Manager mit der neuen Installation assoziiert werden. Hierfür wird pro Queue Manager nur ein Befehl benötigt und geht dementsprechend schnell.
Ein weiterer Anwendungsfall, ist der, dass unterschiedliche WebSphere MQ Versionen gleichzeitig auf einem System betrieben werden sollen.
Wesentliche Neuerung in WebSphere MQ 7.1 im Security Bereich sind die Channel Authentication Records. Dieses Feature muss zuerst für den entsprechenden Queue Manager mittels eines MQSC Befehles aktiviert werden. Jedem MQ Channel können eine oder mehrere Channel Authentication Records zugewiesen werden. In einem Channel Authentication Record wird definiert, welcher User basierend auf den vom Client angegebenen Informationen an das Berechtigungssystem weitergeleitet wird.
So kann beispielweise hinterlegt werden, dass der MQ Client, der sich mit der User ID „Administrator“ von dem System mit der IP Adresse „10.0.0.2“ verbindet die Rechte des Users „mqm“ bekommen soll. Als weitere Parameter stehen der DN im SSL Zertifikat sowie der Name des Remote Queue Managers zur Verfügung. Die für einen Channel definierten Authentication Records können komfortabel über einen MQSC Befehl abgefragt werden. Bis jetzt mussten zur Umsetzung von User-Mappings MQ Exits wie zum Beispiel Block IP genutzt werden. Da bei der Umsetzung der Mappingsvorschriften allerdings auf die Angaben des MQ Clients vertraut wird, sollten damit nur firmenintern Zugriffsrechte gesetzt werden. Bei der Kommunikation mit externen Partnersystemen sollte weiterhin mutual Authentication mittels SSL zur Authentifizierung eingesetzt werden.
Im Bereich der Autorisierung können Zugriffsrechte auf Queues und Topics nun direkt mittels MQSC Befehlen zugewiesen werden. Bis jetzt musste dafür immer der separate Befehl setmqaut genutzt werden. Die folgende Grafik verdeutlicht auf welcher Ebene diese so genannte Access Control List die Autorisierung vornimmt.
Um eine Konfiguration eines Queue Managers zu speichern war bisher das SupportPac MS03, besser bekannt als saveqmgr, nötig. Ab der WebSphere MQ Version 7.1 gibt es nun den integrierten Befehl „dmpmqcfg“, welcher die Aufgaben des SupportPacs erfüllt und nicht mehr separat heruntergeladen werden muss.