Key Visual - Manage Your Business Integration
 

Okt

18

What's new in Message Broker V8?

By Frank Erbsen on Tu, Oct/18/2011 : 12:14

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?

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.

Weitere Informationen sind hier zu finden.

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.
Margin
Blog-Autor
Frank Erbsen
Frank Erbsen
Software Engineer
+49 221 97343-47
Margin
Informationen
7.0.1  7.0.2  8.0  Absatzmarkt  Active MQ  Active  Administration  Agile Lösungen  Agility  AMS  Analyst  Analytics  Anbindung  Anforderungen  Anwenderkonfernz  Apache  Application Server  API Management  API  AS2  ASP  Automatisierung  b2b  B2B Integration  Basic  Big Data  Blogreihe  Bluemix  Blueworks  BPM  Broker  BRMS  Bus  Business Process Management  Business Rules  Buzzword  Camel  Cast Iron  Cloud API  Cloud Computing  Cloud Integration  Cloud  Commerce  Compliance  Conference  Connect:Direct  CPLEX  CXF  DataPower  Decision Server Insights  Deployer  Deployment  Development  DFDL  Digitalisierte Prozesse  Digitalisierung  Domino  DSI  e-Fachverfahren  ersteinrichtung  Edi  Edition  Einführung  Einsatz  Entscheidung  Entwicklung  ESB  Excel  Fahrplanoptimierung  Features  Federated Connectivity  File Transfer  Filetransfer  Finance  FTE  gentran  gis  Geschäftsprozesse  Go Live  Google  Governance  Hardware ESB  Hosting  Hybrid-Cloud  Hybrid Cloud  Hybrid  IBM Blueworks  IBM BPM  IBM Integration Bus  IBM InterConnect  IBM  ILOG DOC  ILOG LNP  ILOG Transportation Analyst  ILOG  Impact  Infrastruktur  Installation  Integration as a Service  Integration Bus  Integration  Integrator  Interoperabilität  IT-Business-Alignment  Konfiguration  Linear  LNP  Logistik  monitoring  M2M  Manage File Transfer  Management  Marktplatz  Mathematik  Mediation  Message Broker  Messages  Messagesight  Messaging  MFT  Migration  Modellierung  MQ  MQTT  Multicast  Muster  Nachlese  Neuerungen in V7.0.1  Neuerungen  off-premise  on-premise  ODM  ODME  Öffentliche Verwaltung  Open Source  Operational Decision Management  Optimierung  OPL  OSGi  Outsourcing  PaaS  Pattern Integration  Pattern  Patterns  Performance  Portfolio  Praxis  Private  Process Server  Produktionsplanung  Prozessautomatisierung  Prozessintegration  Prozessmodelierung  Prozessoptimierung  PureSystem  Qualität  Real Time  Regelmanagement  Rollen  Routenplanung  Routing  ROI  SaaS API  SaaS Integration  SaaS  Salesforce  Schwerpunktanalyse  Script  SCM  Security  Service Federation Management  Servicemix  SFM  SI  Slotting  SoapUI  SOA Cloud Symposium  SOA  SPSS  Standard  Standardplattform  Standardtool  Standortoptimierung  Sterling Integrator  Sterling  SugarCRM  Symposium  Template  TIP  TM1  TOSCA  Transportation  Transportoptimierung  Übersicht  Umstieg  Unix  Update  vergleich  Vorteile  worklight  workload  wtc  Wartung  Websphere  Websphere: Rollen  WebService Security  WebSphere Enterprise Service Bus  WebSphere ESB  WebSphere MessageBroker  WebSphere Technical Conference  WebSphere  WESB  Workloads  WODM  XAR