Datum
26.10.2009
Dieser Beitrag wurde verfasst von:
Neuerungen in WebSphere Message Broker V7. 0
Der WebSphere Message Broker ist das „Schweizer Taschenmesser“ unter den ESB-Produkten der IBM. Wenn die Anforderungen an Konnektivität und Transformationen aufgrund der Heterogenität einer IT-Umgebung durch andere ESBs wie z.B. den WebSphere ESB.
Die IBM wird Anfang November die neue Version 7 des Message Brokers veröffentlichen. Auf der diesjährigen Websphere and Transaction & Messaging Technical Conference in Hamburg wurde diese das erste Mal der Öffentlichkeit vorgestellt und die neuen Features in einer Reihe von Vorträgen, Labs und Live Demos präsentiert. Im Folgenden möchte ich einige dieser neuen Funktionen und Verbesserungen zur aktuellen Version kurz vorstellen.
Vereinfachte Architektur
Anstatt den Message Broker nur um ein paar neue Funktionen wie z.B. neue Knoten zur Entwicklung von Message Flows zu erweitern, lag der Schwerpunkt bei WMB V7 in einem Redesign der Architektur. Bislang bestand der Broker aus unzähligen Komponenten, darunter neben der Broker Runtime selbst einem Queue Manager, der Broker-Datenbank, dem Config-Manager und optional einem User Name Server zur Publish-Subscribe-Unterstützung. Bis auf den Queue Manager fallen in Version 7 all diese Zusatzkomponenten weg.
Administrationswerkzeuge wie z.B. das Message Broker Toolkit oder die mitgelieferten Kommandozeilentools verbinden sich ab sofort nicht mehr mit einem Config-Manager, sondern direkt mit dem Broker. Durch das Wegfallen der Broker-Datenbank besteht keine Abhängigkeit mehr zu DB2, was die Installation vereinfacht und eine mögliche Fehlerquelle bei der Einrichtung beseitigt. Message Broker V7 nutzt die Publish-Subscribe-Funktionen von WebSphere MQ V7 und erweitert diese z. B. um inhaltsabhängige Verteilung der Nachrichten. Der eigene User Name Server, der bisher zur Authentisierung der Nutzer in Publish-Subscribe-Szenarien diente wird nicht mehr benötigt, da die entsprechenden MQ-Funktionen jetzt vom Broker mitbenutzt werden. Die Verwendung der MQ-Funktionen führt jedoch auch dazu, dass die neue Message Broker Version als einzige noch vorhandene Produktabhängigkeit WebSphere MQ in Version 7 voraussetzt.
Auch beim Deployment gibt es ein paar Veränderungen. Message Broker 7 bietet die Möglichkeit die Message Flows innerhalb einer Execution Group unabhängig voneinander zu starten und zu beenden. Des Weiteren ist es zukünftig möglich, einzelne Message Flows direkt in eine Execution Group zu deployen, ohne sie vorher in eine BAR-Datei verpacken zu müssen.
Patternbasierte Entwicklung
Auch für die eigentlichen Entwicklungsprozesse haben sich die Message Broker Entwickler etwas Neues ausgedacht. Anstatt wie bisher nach dem „Bottom Up“-Prinzip vorzugehen und einen Message Flow aus einzelnen Komponenten Schrittweise aufzubauen, unterstützt das Message Broker Toolkit mit der neuen, patternbasierten Entwicklung nun einen „Top Down“-Ansatz, indem fast fertige, wieder verwendbare Vorlagen für häufig auftretende Anwendungsfälle, zur automatischen Erzeugung von Message Flows verwendet werden können. Auf diese Weise lassen sich im Idealfall Entwicklungsprozesse beschleunigen und so ein schnellerer ROI erreichen.
Um dies zu ermöglichen verfügt das Toolkit für WMB7 über einen „Patterns Explorer“, in dem vordefinierte Patterns aus verschiedenen Kategorien gewählt werden können. Zu jedem Pattern gibt es eine ausführliche Beschreibung und ein Schaubild, um mögliche Anwendungsfälle und die genaue Funktionsweise des Patterns zu erläutern. Hat der Entwickler ein zu seinem Problem passendes Pattern gefunden, muss er noch eine Reihe von Parametern einstellen, wie z.B. Queue Manager Namen, Präfixe zum einhalten von Namenskonventionen oder auch Logging-Optionen. Ist dies geschehen wird automatisch ein Message Flow generiert, der das beschriebene Pattern mit den vom Entwickler eingegebenen Parametern implementiert. Als weitere Hilfestellung wird nach der Erzeugung des Message Flows eine Zusammenfassung angezeigt, die den erstellten Message Flow beschreibt und Anweisungen gibt, welche weiteren Schritte erforderlich sind um den neu erzeugten Flow in Betrieb zu nehmen (z.B. Erstellen von Queues, Überwachung von Logging-Queues).
In der aktuellen Version, die im November veröffentlicht werden soll gibt es acht vordefinierte Patterns, diese Zahl soll jedoch stetig ansteigen. Neue Patterns können in Form von Eclipse-Plugins nachinstalliert werden, bislang besteht jedoch keine Möglichkeit für die User, eigene Patterns zu erstellen. Es gibt jedoch Pläne, eine „Pattern Capture“-Funktion zu entwickeln, die es dem User ermöglicht, aus eigenen Message Flows Patterns zu konstruieren.
Neue und verbesserte Knoten
Auch wenn der Fokus bei der Entwicklung der neuen Message Broker Version auf der Architektur lag, bietet sie eine Reihe von neuen Knoten und Verbesserungen an vorhandenen Knoten, die den Message Broker um sinnvolle Funktionen erweitern.
Die neuen SCA-Knoten ermöglichen eine direkte Anbindung des Message Brokers an den WebSphere Process Server. Der Message Broker Flow kann dabei sowohl als SCA-Endpunkt auftreten, als auch andere SCA-Endpunkte aufrufen.
Über die Sequence- und Resequence Knoten können Nachrichten, die in einer beliebigen Reihenfolge eintreffen, anhand einer konfigurierbaren Sequenznummer sortiert werden, bevor eine Weiterverarbeitung erfolgt. Dies ist immer dann nützlich, wenn eine Verarbeitung von Nachrichten in einer bestimmten Reihenfolge geschehen muss, die Nachrichtensequenz aber beispielsweise auf dem Transportweg nicht garantiert werden kann. Die Sequenznummer wird innerhalb der Nachricht gespeichert und kann flexibel festgelegt werden (z.B. fortlaufende Nummern, Timer-basiert,…).
Der PHP Compute Node war zwar schon für die aktuelle Version verfügbar, allerdings wurde die Plattformunterstützung und Performance verbessert. PHP ist eine weit verbreitete und leicht zu erlernende Scriptsprache, daher eignet sie sich gut als Ergänzung zu den vorhandenen ESQL und Java Compute Nodes.
Weitere, bereits vorhandene Knoten wurden ebenfalls verbessert. So können die Registry- und Endpoint-Lookup-Knoten zur Abfrage von Informationen aus WSRR-Verzeichnissen ab sofort neben Web Service Beschreibungen, auch auf in Form von MQ Service Definitions beschriebene MQ Services zugreifen. In WMB7 unterstützen die FileInput-Knoten auch SFTP. Die häufig verwendeten Adapter-Knoten für Anwendungen wie SAP, Siebel und PeopleSoft wurden ebenfalls verbessert und um neue Funktionen erweitert.
Verbesserte Entwicklungs- und Administrationstools
Neben der Funktionalität wurde auch an der Benutzerfreundlichkeit der Entwicklungs- und Administrationswerkzeuge gearbeitet. Im Message Broker Toolkit gibt es ab sofort nur noch eine Perspektive. Das ständige Umschalten zwischen der Development- und Administration-Ansicht entfällt. Das neue Deployment-Log erleichtert die Fehlersuche, falls beim deployen mal etwas schief läuft, und „Sticky Notes“ ermöglichen es, innerhalb des Message Flow Editors Kommentare anzubringen.
Der Message Broker Explorer, das bereits bekannte Plugin für den MQ Explorer wurde zu einem vollwertigen Administrationswerkzeug ausgebaut. Es verfügt jetzt über umfangreiche Monitoring- und Reporting-Funktionen. So lassen sich z.B. Nutzungsdaten für verschiedene Komponenten erfassen. Diese Daten werden ausgewertet und im MB Explorer grafisch dargestellt. Beispiele für überwachbare Komponenten sind die JVM (Speichernutzung, Threadanzahl, Heap Statistik,…), Parser (Speichernutzung, Nachrichtenelemente erstellt/gelöscht,…) und SOAP/HTTP( geöffnete Sockets, gesendete und empfangene Bytes).
Fazit
Die neuen Features und Verbesserungen im Message Broker 7 sind für mich ein großer Schritt in die richtige Richtung. Wenn man z.B. das neue Toolkit in Aktion sieht freut man sich fast darauf die aktuelle Version bald deinstallieren zu dürfen. Die vereinfachte Architektur und das Wegfallen von Abhängigkeiten zu anderen Anwendungen könnte die Installation und Konfiguration deutlich vereinfachen und auch die neuen Knoten erweitern den Message Broker um eine Reihe nützlicher Funktionen.
Die patternbasierte Entwicklung wirkt wie eine sinnvolle Erweiterung. Die einzelnen Patterns sind gut dokumentiert und die Werkzeuge zur Erzeugung von Pattern-Instanzen wirken gut durchdacht und ermöglichen es, innerhalb kurzer Zeit komplexe Message Flows zu generieren. Allerdings ist die in der aktuellen Version verfügbare Anzahl von Patterns noch sehr gering und es bleibt abzuwarten, ob die Pattern-Bibliothek wirklich so schnell anwächst wie versprochen, und diese Patterns dann tatsächlich eine gute „Out of the Box“-Lösung für reale Anwendungsfälle darstellen.
Einordnung Cloud Computing
Einordnung Cloud Computing
Das heutige Buzzword ist „Cloud Computing“ – ein neues Hype-Thema, getrieben von Herstellern und Analysten. Aber SOA und Cloud Computing können viel zur zukünftigen Gestaltung der Geschäftswelt beitragen.
Worüber reden wir hier eigentlich? Buzzword-Bingo? Oder echter Nutzen?
Wahrscheinlich zutreffende These: Wer ständig hohle Begriffe verwendet, landet bei bedeutungslosen Ergebnissen – mit entsprechenden Auswirkungen auf Erfolg und Reputation.
Doch was ist „Cloud Computing“? Ist es wirklich? Innovativ? Nur eine aktuelle Welle? Eine zukünftige Welle? Kosteneffizient? Interoperable? Findet es heute Verwendung? Bringt es Nutzen? Ja, z.B. bei IBM, Amazon, Google, …!
Können Unternehmen (auch mittelständische!) schon heute von den verfügbaren Modellen, Diensten und Anwendungen profitieren? Ja, denn auch „private Cloud“-Ansätze auf Basis von etablierten Virtualisierungslösungen werden heute in mittelständischen Unternehmen untersucht und „public Clouds“ können genutzt werden: zum Beispiel mittels Amazon EC2 dynamische WebSphere Application Server Workloads für intensive Softwaretest von eigenen J2EE Applikationen auf Pay-per-Use Basis zu nutzen. Schneller Nutzen ohne hohe Kosten.
Also was ist „Cloud Computing“? Ist es Grid Computing? Organic Computing? Utility Computing? Oder Software-as-a-service? Oder – gar SOA?
Nein – „Cloud Computing“ ist anders – mehr –
In Kürze: “Cloud Computing ist ein Service-Management Modell (Plattform), welche eine transparente Infrastruktur mit geringen Managementkosten zur Verfügung stellt.“
Cloud Computing ist bisher nicht allgemeingültig oder gar eindeutig definiert. Jedoch existieren eine Reihe von Definitionsansätzen:
Exkurs: Zitate zur Cloud Definition aus Sekundärquellen – in der rechten Marginalie.
Demzufolge geht Cloud Computing über andere gegenwärtig diskutierte Ansätze (siehe oben) und Konzepte (Virtualisierung, Konsolidierung) hinaus.
Nutzbarkeit und Wert
Aber hier soll nicht weiter auf die allgemeine Cloud Thematik eingegangen werden, sondern auf die Nutzbarkeit und den Wert den dieser Ansatz für Unternehmen haben kann.
Dieser wird jedoch im Wesentlichen durch die spätere Software bestimmt, welche die Geschäftprozesse unterstützt und so die Menschen produktiv und effektiv ihre Arbeitet gestalten lässt. Diese Anwendungen sollten so flexibel und agil reagieren können, wie dies auch die Menschen – wenn Sie denn hinreichend motiviert sind – es täglich unter Beweis stellen. Die Softwareindustrie stellt heute Anwendungssysteme zur Verfügung, welche diese Agilität besitzen. Die zugrunde liegende Software Architektur orientiert sich an der etablierten Arbeitsteilung und Dienstestruktur und fasst dies über die Serviceorientierte Architektur (SOA) zusammen. Reale Umsetzung nutzen heute die seit über einer Dekade bestehenden Erfahrungen in der asynchronen Kommunikation – wenn sinnvoll – an heutigen Standards orientiert. Damit entstanden (und entstehen weiterhin täglich) Integrationslandschaften, die auf stabilen Enterprise Service Bus Implementierungen fußen und diese SOA in einen praktischen Nutzen für Unternehmen umsetzten.
Wenn doch die Cloud alles transparent macht – wieso sollte es dann Implikationen auf die Anwendungssysteme geben?
Dazu erlauben Sie die Frage, ob Sie die Aufwände kennen, welche Unternehmen in die Nutzung von Legacy-Anwendungen (z.B. Cobol oder RPG basiert) und Plattformen (z.B. Mainframes, AS400- oder Tandem-Systeme) in der heutigen verteilten, heterogenen Welt vornehmen mussten? Worin war und ist dies begründet? Einerseits in den wertvollen Bestandslösungen, die einen Investitionsschutz erfordern und andererseits in den Chancen, welche in der Nutzung innovativer Techniken liegen. Da passten nun die ehemaligen und heutigen, bzw. zukünftigen Modelle, z.B. in der Softwarearchitektur, nicht zusammen. Vielfach erfolgreich umgesetzte Lösungskonzepte sehen hier heute die oben genannten SOA Konzepte und Realisierungen vor.
Wolkige Herausforderungen
Nun stehen mit den wolkigen Versprechungen neuartige Konstellationen ins Haus, welche die Kommunikation von Anwendungen innerhalb einer Cloud und über die Grenzen hinweg vor neue Herausforderungen stellt. Warum?
Weil – und bitte verzeihen Sie, dass nun ein bisschen an der Oberfläche der Details gekratzt werden muss – z.B. ein sinnvolles Programmiermodells (REST) für die Cloud nicht mit den Konzepten des üblichen SOA Programmiermodell (SOAP) übereinstimmt. Sollte uns dies sorgen? Ist eines schlechter oder besser? Nein! Nur angepasst auf die Umgebung – und das ist gut so!
SOAP ist eine Weiterentwicklung des XML-RPC und stellt damit die standardisierte Interprozesskommunikation analog zum altenehrwürdigen Remote Procedure Protocol in der SOA zur Verfügung – sprich für die verteilte, heterogene Welt.
REST steht für Representational State Transfer und bezeichnet einen Architekturstil in dem jede Ressource eigenständig (mit einer eigenen URI) verfügbar ist. Enorm erfolgreich im World Wide Web. REST sieht wohldefinierte Operationen vor, die auf alle Ressourcen angewendet werden können (z.B. GET, POST, PUT und DELETE).
Eine SOA kann ebenso RESTful sein, wobei hier ein Mapping von logischen Ressourcen und Diensten notwendig ist (REST handelt mit Ressourcen, nicht mit Services). Eine architekturelle Wahl, keine Implementierungsentscheidung.
Dieses (einfache) Beispiel zum Programmiermodell ist nur eine der Implikationen, die durch ein anderes Betriebs- und Managementmodell zu betrachten sind.
Allgemein sind wesentliche Überlegungen zur Interopearbilität von Multi-tier Anwendungslandschaften zu tätigen und für die eigene Situation zu bewerten. Ob von operativer Seite oder gar hinsichtlich der End-to-End Prozessverfolgung, sprich Nachrichtenverfolgung über die Grenzen der eigen- und fremdbetriebenen Systeme hinweg. Die gute Nachricht: dazu gibt es heute bereits Lösungen, da dies z.B. im Bereich von verteilten Integrationsumgebungen (federated ESBs) hinsichtlich der Inter-/Intra-ESB Interaktionen und des Government, sprich der Ansätze zu Domain-bezogenen Service Registries, in konkreten Projekten erarbeitet wurde.
Die schlechte Nachricht: es wird durch Connectivity-as-a-Service oder Integration-as-a-Service Ansätze nicht weniger komplex – die gute Nachricht dazu im Kontext der schlechten: die konsequente Arbeit der letzen Jahre im Bereich SOA hilft hierzu die richtigen Antworten zu formulieren.
Doch nur Buzzword-Bingo?
Aber was hat das mit der heutigen Praxis zu tun? Wie steht es mit dem Nutzen? Dazu ein Beispiel eines Kunden:
Er hat seine Integrationslandschaft – sein Rückgrat seiner SOA – seit Jahren bei einem großen Outsourcing Partner im Betrieb und wechselt nun diesen. Dabei stellt er fest, dass viele der Applikationen Abhängigkeiten von anderen haben, welche nicht im Detail dokumentiert oder bewusst bekannt und damit auch nicht automatisiert sind. Somit muss nun eine entsprechende Analyse diese Details zusammentragen, die Implikationen und Abhängigkeiten bewerten, für den Übergang die notwendigen Infrastrukturbedingungen schaffen und den Aufbau im neuen Environment automatisiert generieren.
Wie sähe eine Lösungsmöglichkeit mit einer Private Cloud heute aus: Die oben beschriebenen Abhängigkeiten, etc würden heute in der privaten Cloud konfiguriert sein und im eigenen Rechenzentrum oder beim alten Partner betrieben werden – als elastische Workloads. Beim Wechsel könnte dies logisch als Einheit transferiert werden oder gar bei saisonalen Erfordernissen zusätzlich verteilt werden.
Kann dies nicht schon heute so erfolgen? Ja – zum Teil – über Virtualisierungslösungen (z.B. mit Systemen wie VMware, oder den entsprechenden IBM Hypervisors auf System p oder z, …)
Warum nur zum Teil, bzw. warum wird es nicht mehr und stringent genutzt? Weil viel Aufwand in die Erstellung der „Verskriptung“ zum Aufbau der Umgebung, zur Installation der Applikationsserver, zum automatischen Hoch- und Runterfahren der (Anwendungs-)Systeme, etc. zu stecken ist. – Viel Gelegenheit für Fehlersituationen, geringe Wiederverwendbarkeit in anderen Umbegungen – Viel Arbeit!
“Take this labour out!” – von Regenmachern und Wolkenbrüchen
Also braucht es auf die Virtualisierungslösungen aufbauende Konzepte und Produkte und hier setzt Cloud Computing an. Wenn dann noch die Applikationsschicht automatisiert verteilbar ist und die Services korrekt, sicher, zuverlässig und performant kooperieren können, kommen wir der schönen, neuen SOA/Cloud Welt einen Schritt näher. Die Architekturimplikationen sind mannigfach – doch SOA birgt die notwendigen Antworten und im Bereich des Deployments gibt es nun einen weiteren Schritt der helfen kann, das Platform-as-a-Service Versprechen einzulösen.
Die zum Thema Cloud Computing passende Produktankündigung auf der Impact 2009 in Las Vegas war WebSphere Cloudburst. Bei der IBM WebSphere CloudBurst Appliance handelt es sich um ein Komplettsystem, um die Installation und Inbetriebnahme (Roll Out) von neuen Applikationen in einer Cloud Infrastruktur zu vereinfachen und zu beschleunigen (Minuten vs. Wochen) und damit dieses Deployment produktiv und zuverlässig abzuwickeln. Die Grundlage hierfür ist, dass mit dieser Appliance die Images von virtuellen Maschinen komplett gemanagt werden können (insbesondere wichtig: die geschützte Speicherung), solange sie WebSphere Application Server Hypervisor Edition zur Grundlage haben. Diese Images repräsentieren also spezielle WebSphere Anwendungen.
Ist das reell? Reell ist die Anforderung, und die Umsetzung von Szenarien – wie im obigen Kundenbeispiel beschrieben, wird zeigen in welcher Konstellation dies Arbeit, Zeit und Kosten spart.
Es gab weitere Cloud Offerings auf der Impact – BlueWorks als cloud-basiertes Werkzeug zur Modellierung von Geschäftsprozessen und deren weitere Übersetzung in IT-gerechte Arbeitschritte, um unkompliziert diese Techniken auszuprobieren. Und IBMs Innov8 (gesprochen Innovate), ein „ernsthaftes Spiel“ zur Simulation realer Geschäftsabläufe, sowie weitere mit dem Cloud Computing zusammenhängende SaaS Ansätze wie z.B. LotusLive. Auf diese Punkte gehen wir zu einem späteren Zeitpunkt ein.
Schluss
SOA und Cloud Computing werden helfen, Verbraucher und Herausgeber von Diensten zusammenzubringen. Wie beschrieben kann dies enorme Implikationen auf die Art haben, wie wir Systeme bauen aber auch unsere Organisationen führen, denn solch eine Technologie kann neue unternehmerische Ansätze und organisatorische Transformationen ermöglichen.
P.S. Die Möglichkeiten an Flexibilität und Agilität die nun im Cloud Computing versprochen werden, lassen die Cloud als Erweiterung der SOA in die physische Welt erscheinen – ja, insofern „wächst SOA in die Cloud“ hinein!
