Datum
29.04.2013
Dieser Beitrag wurde verfasst von:
Der WebSphere Message Broker (WMB) wurde ab Version 9 in IBM Integration Bus (IIB) umbenannt. Mit dieser Namensänderung kamen eine Reihe von neuen Funktionen und eine allgemeine Anpassung des Entwicklungsvorgehens, die eine Migration vom WMB zum IIB etwas komplexer macht, als man das von einem einfachen Versionsupdate vielleicht erwarten würde. In diesem Blogeintrag werden das allgemeine Migrationsvorgehen sowie einige Probleme beschrieben, die dabei auftreten können.
Mögliche Migrationspfade
Grundsätzlich gibt es zwei Möglichkeiten vom WMB zum IIB zu migrieren: Inplace oder Parallel. Bei einer Inplace-Migration wird die neue Version auf dem bestehenden WMB-Server installiert. Die bestehenden WMB-Artefakte und Konfigurationen werden dann über mitgelieferte Werkzeuge auf die neue IIB-Version migriert. Daraufhin kann der IIB mit den migrierten Komponenten gestartet werden.
Bei einer parallelen Installation wird der IIB auf einem separaten System installiert. Die Konfiguration der alten Umgebung wird exportiert und gemeinsam mit den Softwareartefakten auf der neuen eingespielt. Nach erfolgreichen Tests wird die alte Umgebung ab- und die neue eingeschaltet.
Vorteil der Inplace-Migration ist, dass nur ein Server benötigt wird und die IP-Adresse des Servers gleich bleibt. Bei der parallelen Installation muss ein zweiter Server bereitstehen und die IP-Adresse ändert sich oder muss beim Wechsel auf die neue Umgebung auf den neuen Server umgestellt werden.
Allerdings kann bei einer parallelen Installation ausgiebig auf der neuen Umgebung getestet werden – ohne Auswirkungen auf die produktive Umgebung. Die Umschaltung geschieht erst, wenn alles sicher funktioniert. Bei einer Inplace-Migration muss ggf. ein Rollback durchgeführt werden, wenn nach der Migration irgendetwas nicht funktioniert. Daher ist die parallele Installation der empfohlene Weg.
Migration der Softwareartefakte
In BAR-Dateien gepackte Artefakte aus älteren Versionen lassen sich auf dem IIB deployen und sind lauffähig, solange die sonstige Konfiguration der alten Umgebung entspricht. Sobald die Anwendungen jedoch im IBM Integration Toolkit (IIT) geöffnet werden, um verschiedenste Änderungen durchzuführen, müssen die Softwareartefakte migriert werden. Dies geschieht weitgehend automatisch, es gibt jedoch einige Fälle, in denen manuelle Eingriffe nötig sind.
Grafische Mappings
Im Integration Bus wird ein neuer, grafischer Mapping-Editor verwendet, der aus dem WebSphere ESB übernommen wurde. Alte Mapping-Files können weiterhin verwendet werden, solange sie nicht angepasst werden müssen. Sie können im IIT jedoch nur noch mit Lesezugriff geöffnet werden. Vor einer Anpassung ist eine Migration auf das neue Format notwendig. Diese geschieht automatisch über einen Wizard, allerdings müssen die migrierten Mappings manuell in die bestehenden Message Flows eingebunden werden.
Message Sets
Mit Version 8 des Message Brokers wurde DFDL als Modellierungssprache für Nachrichtenformate eingeführt. Die bis dahin verwendeten Message Sets lassen sich im IIT weiter öffnen und bearbeiten, die Erstellung von neuen Message Sets ist jedoch standardmäßig deaktiviert. Wenn ein Umstieg auf DFDL unerwünscht sein sollte, lässt sich dies jedoch ändern.
Anwendungen und Bibliotheken
In früheren Versionen des WMB wurden sämtliche Integrationslösungen in Form von Message Flows einzeln auf dem Broker deployed. Es gab keine Möglichkeit, die Flows in fachlich zusammenhängende Applikationen zu bündeln. Zu diesem Zweck gibt es nun Applikationen und Bibliotheken, die eine Gruppierung von IIB-Softwareartefakten ermöglichen.
Durch diese neuen Konstrukte hat sich auch die Projektstruktur innerhalb des Integration Toolkits stark verändert. Die bisherigen Message Flow Projekte lassen sich weiterhin in das Toolkit importieren und verwenden, es empfiehlt sich jedoch eine manuelle Restrukturierung, um die neuen Funktionen des IIB voll auszunutzen.
Erfahrungen aus Migrationsprojekten
Unsere bisherigen Migrationsprojekte haben gezeigt, dass nicht immer alles so schnell und einfach geht, wie es die Dokumentation behauptet. Da der Integration Bus im Wesentlichen eine Laufzeitumgebung für individuell entwickelte Integrationslösungen ist, gibt es nie zwei identische Kundenszenarien, entsprechend sind auch die auftretenden Probleme recht individuell.
Schwierigkeiten bei der Migration treten vor allem mit selbstentwickelten, von Standards abweichenden Komponenten auf. Außerdem kann es Probleme beim Build- und Deployment geben, wenn es innerhalb eines migrierten Projektes sowohl Komponenten gibt, die vor dem Deployment kompiliert werden müssen, als auch solche, die als Quellcode vorliegen und vom IIB interpretiert werden.
Einen weiteren Fehlerschwerpunkt gibt es bei der Nutzung von Adaptern, z.B. für den Zugriff auf SAP-Systeme, hier kann es zu Kompatibilitätsproblemen mit älteren Adapterversionen kommen, die sich nicht immer automatisch bereinigen lassen.
Sollten Sie ein Update von einer früheren Version des WebSphere Message Brokers oder IBM Integration Bus auf eine aktuelle Version planen, unterstützen wir Sie gerne bei der Durchführung einer möglichst reibungslosen Migration.
Autor
Wolfgang Schmidt