Liegt der Fokus beim Message Broker V8 auf neuen Features oder die Erweiterung bestehender Features? Bringen diese für Message Broker Entwickler und Administratoren Produktivitätsgewinne mit sich, die eine Migration auf V8 rechtfertigen?
What's new in Message Broker V8?
Wissensbeitrag
Schwerpunkte in der Message Broker Administration
Im Administrationsbereich treten häufig bei dem Versuch Message Broker Build- und Deploymentprozesse zu automatisieren Schwierigkeiten auf, beziehungsweise wenn es um die Verwaltung und das Monitoring großer Message Broker Landschaften geht.
Im Toolingbereich wurde bereits in der Version 7 die Administration-View und Message Broker Development-View in einer View zusammengefasst, welches nervigem hin und her springen ein jähes Ende bereitete. Message Broker V8 geht darüber weit hinaus. Mittels der Web Administration Console können nun über eine Webkonsole Message Broker Instanzen administriert werden. Dabei ist die Web Administration Console, nur eine Möglichkeit, mit der REST Management API und der erweiterten CMP (Message Broker Java API) stehen einem auch die Möglichkeiten zur Verfügung eigene Lösungen zu implementieren. Derzeit können mittels der REST Management API u.a. Informationen zu Execution Groups und Message Flows abgefragt und Eigenschaften dieser beiden Message Broker Objekte verändert werden. In Zukunft soll wohl auch die Erstellung und das Deployment von Message Broker Archiven (BAR Dateien) möglich sein. Um ersteres zu erzielen, soll der Compileprozess von Message Broker Artefakten aus dem Development Prozess vollständig eliminiert werden. Im Message Broker Toolkit 7 muss derzeit die Kompilierung von Messageflow-Dateien und Messageset-Dateien manuell angestoßen werden. Dabei werden die erstellten MSGFLOW-Dateien und MSET-Dateien in CMF-Dateien und XSDZIP-Dateien übersetzt. Im Message Broker V8 sollen Messageflows (MSGFLOW-Datei) und Messagesets (MSET-Datei) Dateien nun direkt in einem ZIP-Archiv gepackt und anschließend deployt werden können. In dem Mapping Node erstellte Maps werden nun vor ihrem Deployment nicht in ESQL übersetzt sondern nativ deployt. Dies bringt besonders im Bereich Debugging viele Vorteile.
Im Monitoring-Bereich stehen nun mit dem Transaction Viewer, dem Activity Log und dem Capture & Replay Feature stark verbesserte Möglichkeiten zur Problemfindung zur Verfügung. Mittels des Activity Logs kann nachvollzogen werden, welche Schritte eine Message innerhalb eines Messageflows durchläuft. Treten Performance-Probleme auf, können zu den einzelnen Ressourcen (JMS Provider, JDBC Datenbankanbindung), aber auch zu den einzelnen Nodes Performancekennziffern abgefragt werden. Die unterstützten Ressourcen werden dabei schrittweise ausgebaut werden.
Derzeit wird die Migration von V6.1 nach V7 und danach V8 empfohlen.
Schwerpunkte im Message Broker Development
Im Development Bereich wird mit dem .NET Compute Node nun auch .NET Entwicklern die Umsetzung von Datenkonvertierungen möglich. Bei Klick auf einen .NET Compute Node, wird der Quellcode automatisch in Visual Studio geöffnet.
Die in Message Broker V7 eingeführten Patterns wurden erweitert. Mit den Configurable Services steht nun die Möglichkeit zur Verfügung für ein spezifisches Integrationsszenario fixe Verbindungsinformationen und feste Verbindungsinformationen voneinander zu trennen. Sie ähneln damit den Konfigurationseigenschaften in WebSphere Cast Iron. Mittels der Configurable Services kann unter anderem die Migration von Message Broker Artefakten zwischen unterschiedlichen Staging Umgebungen vereinfacht werden.
Der bisherige Subflow-Support im Message Broker wurde aus meiner Sicht grundlegend verbessert. Subflows können nun separat von Main-Flows deployt werden. Bei dem Deployment eines Main-Flows wird automatisch geprüft ob die referenzierten Subflows bereits deployt wurden. Nutzen mehrere Main-Flows dieselben Subflows muss dieser nurnoch genau einmal deployt und gewartet werden. Da allerdings der Scope von Subflows auf Execution Groups beschränkt ist, bleibt abzuwarten wie viele Kunden bereit sind eine bessere Wartbarkeit gegen eine abgeschwächte Isolierung von Integrationsszenarien einzutauschen.
Bei der Bündelung von Message Broker Artefakten wird nun zwischen Message Broker Applications und Ressources unterschieden. In Resources können Dinge gebündelt werden, die von mehreren Applications genutzt werden. Kurzgefasst ähnelt eine Message Broker Application einer ausführbaren Datei und eine Ressource einer Programmbilbliothek.
In Bezug auf WS-* Support kann der Message Broker V8 mit einigen Neuerungen aufwarten. Die Auslagerung dieser Informationen auf Flow Konfigurationsebene wurde dabei beibehalten. Neben WS-Security, welches unter anderem die Verschlüsselung einzelner Payloadanteile sowie Authentifizierung und Autorisierung erlaubt, wird nun auch WS-RM unterstützt. Mittels WS-RM kann die Transportzuverlässigkeit von SOAP/HTTP bedeutend erhöht werden. SOAP/HTTP mit WS-RM stellt damit eine interessante Alternative gegenüber SOAP/JMS dar. Auch der Support für SOAP Attachments wurde erweitert.
Einen von WebSphere TX bekannten Weg, schlägt nun auch der Message Broker mit den sogenannten Industry Packs ein. Mittels des Healthcare Connectivity Packs wird nun das Format HL7 out-of-the box unterstützt. Weitere Industry Packs sind bereits geplant. Ein ähnliches Vorgehen ist auch bei WebSphere Cast Iron mit den Adaptern für industriespezifische SaaS Lösungen zu beobachten.
Aber auch die Unterstützung proprietärer Formate soll grundlegend verändert werden. Mit DFDL (Data Format Description Language) wird wohl langfristig der MRM Parser abgelöst werden. Im Gegensatz zu MRM ist DFDL ein allgemeiner Standard, der langfristig auch in anderen IBM ESB Produkten unterstützt wird. Damit wird aus meiner Sicht langfristig erstmals eine Seitwärtsmigration zwischen den drei IBM ESB Produkten möglich werden.
Die Migration von Message Broker V7 zu Message Broker V8 Projekten wurde stark vereinfacht. Diese wird nun automatisch beim Öffnen der bestehenden Projekte im Message Broker Toolkit V8 durchgeführt.
Message Broker V8 Versionen
- Der Message Broker V8 wird in drei verschiedenen Versionen geliefert werden
- Den Message Broker Express, welcher erlaubt genau eine Execution Group zu erstellen und eine beschränkte Auswahl an Nodes zur Verfügung stellt.
- Den Message Broker Standard, welcher erlaubt genau eine Execution Group zu erstellen und alle Nodes zur Verfügung stellt.
- Den Message Broker Advanced, der keine Limitierung bezüglich der Execution Groups besitzt.
- Der Message Broker V8 soll ab dem 9.Dezember 2011 zur Verfügung stehen.
Fazit
Insgesamt wird wohl schon anhand der hier getroffenen Auswahl deutlich, dass der Message Broker mit vielen interessanten Neuerungen aufwarten kann. Ob die Neuanschaffung vom Message Broker V8 sich lohnt, kann allerdings nicht pauschal beantwortet werden.
Erfahren Sie mehr
Wissen
Brave New Message Broker
Wissen
Message Broker: Kleines Fixpack mit großer Wirkung
Wissen
IBM Integration Bus 9 – Der neue Message Broker
Wissen
Migration WebSphere Message Broker
Wissen
Auf Kamelen durch die Wüste der Integration - Teil 2
Wissen
Mediation mittels Transformation und Routing
Technologie
Apache Lösungen
Technologie
WebSphere MQ & Message Broker Migration
Wissen
Aus zwei mach eins – Das „neue“ IBM Integration Bus
Blog
Deno – Das müsst ihr über die Laufzeitumgebung wissen
Wissen
IBM ODM-Services automatisiert testen
Wissen
What's New - WebSphere MQ File Transfer Edition 7.0.2
Wissen
Best Practices für die Einarbeitung in Connect:Direct
Wissen
Wiederverwendung bei der Integrationsentwicklung
Wissen
Einführungsworkshop in Apache Integrationslösungen
Technologie
25.02.25
Broker Architektur
Wissen
Qualität der Messagingsysteme
Technologie
Services für Apache Camel
Wissen
Auf Kamelen durch die Wüste der Integration
Technologie
25.02.25