Datum
22.10.2012
Dieser Beitrag wurde verfasst von:
Anfang Oktober wurde Fixpack 1 für WebSphere Message Broker Version 8 veröffentlicht. Eigentlich erwartet man bei einer Version 8.0.0.1 keine riesigen Veränderungen zu Version 8.0.0.0, die IBM hat mit diesem unscheinbaren Update jedoch eine Reihe interessanter neuer Funktionen eingeführt und diese auf der diesjährigen WebSphere Technical Convention in Berlin vorgestellt.
Der folgende Blogeintrag beschäftigt sich mit einigen dieser Neuerungen, die andeuten könnten, wohin sich der Message Broker in Zukunft entwickelt.
Bis einschließlich Broker Version 7 gab es zwischen den in einer Execution Group deployten Softwareartefakten keine Hierarchie, das bedeutet es war nicht ersichtlich, welche Message Flows, Message Sets, Mappings, usw. fachlich zusammengehören.
Um diese Schwäche auszugleichen, wurde Version 8.0 um die Möglichkeit erweitert, fachlich zusammengehörige Objekte zu Applikationen und Libraries zu bündeln, die dann als Einheit deployed, sowie gestartet und gestoppt werden können. Zusätzlich dazu, wird nun mit Version 8.0.0.1 ein neues Service-Konzept eingeführt, das es ermöglicht, eine Message Broker Applikation mit einer wohldefinierten Webservice-Facade zu versehen.
Anstatt wie bisher direkt auf die SOAP-Schnittstellen einzelner Message Flows zuzugreifen, bieten die neuen Services Zugriff auf die Operationen einer vollständigen Message Broker Applikation. Alle fachlich zusammenhängenden Operationen sind somit in einer Service-Facade gebündelt. Die Erstellung der Service-Definition, die danach in Form einer WSDL-Datei vorliegt, geschieht über eine Benutzeroberfläche, deren Look & Feel sich an der vergleichbaren Funktion des WebSphere ESB’s orientiert, in dem Mediationen auf ähnliche Weise beschrieben werden.
Die aktuelle Implementierung des Service-Konzepts im Message Broker hat noch gewisse Einschränkungen, so kann z.B. pro WSDL-Datei nur ein Binding verwendet werden, der Funktionsumfang soll jedoch in zukünftigen Versionen ständig weiterentwickelt und erweitert werden. Das Fixpack liefert auch gleich ein paar Anwendungsmöglichkeiten in Form von Patterns für die neuen Services mit. Diese werden in den folgenden Abschnitten beschrieben.
Mobile Anwendungen gewinnen heutzutage immer mehr an Bedeutung. Da der Message Broker darauf ausgelegt ist, verschiedenste Schnittstellen für den Zugriff auf Backend-Systeme zu bieten, ist es eigentlich ein logischer Schritt, ihn auch für die Anbindung von mobilen Applikationen an Backend-Systeme zu nutzen.
Mit Worklight hat die IBM nun ein Produkt im Portfolio, mit dem diese Integration erstaunlich einfach umzusetzen ist. Ab Version 8.0.0.1 bietet der Message Broker vier neue Patterns an, die dazu dienen, Message Broker Services in diversen, mobilen Nutzungsszenarien einzusetzen.
Dabei werden über die Patterns nicht nur die Message Broker Objekte erzeugt, der notwendige Worklight-Adapter wird ebenfalls gleich miterstellt und kann ohne weitere Anpassung auf einem Worklight-Server deployed werden. Der Zugriff auf die eigentliche Message Broker Applikation geschieht per HTTP über die neue Service-Schnittstelle.
Die automatisch erstellte, mobile Webapplikation eignet sich vielleicht nicht für den produktiven Einsatz, sie bietet jedoch einen einfachen Zugriff auf alle, vom Broker-Service bereitgestellten Operationen und kann daher als Ausgangspunkt für die Entwicklung einer funktional und auch optisch ansprechenderen Applikation genutzt werden.
Dank der neuen Services, sowie der mit Version 8.0 eingeführten REST-API, nähert sich der Message Broker immer mehr den WebSphere-Produkten an, die auf dem WebSphere Application Server (WAS) aufsetzen.
So gibt es z.B. ein neues WAS-Addon, dass die Ausführung einfacher administrativer Aufgaben für den Message Broker, von der WAS-Adminkonsole aus ermöglicht. Fügt man dieser Ansicht einen Broker hinzu, so hat man Zugriff auf dessen Execution Groups, sowie die enthaltenen Services, die von dort aus z.B. direkt gestartet und gestoppt werden können.
Da der WAS nun eine direkte Sicht auf Broker-Objekte hat können auf einfachem Wege auch andere Funktionen des Application-Servers in Verbindung mit dem Broker genutzt werden. So wurde z.B. ein neues Kommunikations-Pattern zwischen WAS und Message Broker vorgestellt, das von dem bisher verbreiteten Vorgehen (WAS –>WebSphere MQ per JMS–>Message Broker) abweicht und eine Kommunikation zwischen dem WAS und dem Message Broker per HTTP über die Service-Facaden der Broker-Applikationen verwendet.
Ein damit umsetzbarer Anwendungsfall ist, dass alle Aufrufe an den Broker-Service über den WAS geleitet werden. Damit stehen dem Broker sämtliche Funktionen des Application Servers zur Verfügung (z.B. Security, Load Balancing und Hochverfügbarkeit). Der WAS leitet die Kommunikation dann per http an den Broker-Service weiter. Da die Message Broker Services den eingebetteten Listener der Execution Groups verwenden und nicht den globalen Broker-Listener, kommt diese Kommunikation vollkommen ohne WebSphere MQ aus.
Fazit
Bislang war der Message Broker weitgehend vom WebSphere Application Server entkoppelt und die Kommunikation zwischen diesen beiden Produkten geschah größtenteils über WebSphere MQ. Mit dem Fixpack 1 nähert sich der Message Broker nun langsam der “WebSphere-Welt” an. Broker können von der WAS-Adminkonsole aus administriert werden und über die neuen Services kann der Message Broker nun von den Features des Application Servers profitieren. Zusätzlich sollte damit auch die Integration zwischen dem Message Broker und anderen WebSphere-Produkten, wie z.B. dem Process Server deutlich einfacher sein, auch wenn dieser Anwendungsfall auf der WebSphere Technical Convention nicht ausdrücklich erwähnt wurde.
Das Service-Konzept im WebSphere Message Broker 8.0.0.1 ist sicher noch nicht perfekt, es erweitert den Broker jedoch schon jetzt, in seiner ersten Version um ein paar spannende Funktionen und es wird interessant sein, wie sich diese Verschmelzung von WAS und Message Broker in nächster Zeit entwickelt und ob die Integration mit Worklight dazu beitragen kann, dass sich der Broker als zentrale Komponente bei der Verbindung von Backend-Systemen mit dem mobilen Web etablieren kann.