Suche

Top Ten ESB: Viele ESBs, viele Möglichkeiten

Eclipse Swordfish

Swordfish versteht sich als Framework, mit dem es möglich ist, sich seinen eigenen, auf JBI basierenden ESB zu erstellen. So ist zumindest das Versprechen. Swordfish ist daher sehr auf Flexibilität ausgelegt. Das Projekt wurde u. a. von der Firma Sopera ins Leben gerufen, die Swordfish auch innerhalb ihres eigenen Produkts verwendet. Swordfish eignet sich dann ganz besonders, wenn eine sehr spezielle Lösung benötigt wird und man sich gerne seinen „eigenen“ ESB schaffen möchte.

OpenESB/GlassFish

Der OpenESB ist eine weitere Implementierung der JBI-Spezifikation und da dieser von Sun (heute Oracle) initiiert wurde, eng mit dem IDE NetBeans und dem GlassFish Application Server verknüpft. Er wird mit einem auf BPEL basierenden grafischen Tooling zur Erstellung von Services ausgeliefert und erleichtert dem Entwickler so die Arbeit. Allerdings ist anzumerken, und das betrifft nicht nur den OpenESB, dass sich die Entwicklung im Business Process Management weg von BPEL hin zu BPMN bewegt. Trotzdem setzen doch noch einige ESB-Anbieter bei der Orchestrierung der Services im ESB auf diese Prozessmodellierungssprache (Featuretabelle).

Enterprise Support wird nur für die zertifizierte Variante, den GlassFish ESB, geboten. Bei der Entscheidung für oder gegen den Einsatz von OpenESB/GlassFish ESB sollte die enge Verzahnung mit den Produkten von Sun bedacht werden. Das kann, wenn hohe Flexibilität vom ESB verlangt wird, durchaus ein limitierender Faktor sein. Anderseits bringt die Nähe zu Sun beim professionellen Support Vorteile. Deshalb ergibt sich als einfachstes Szenario Folgendes: OpenESB/GlassFish sollte bei einer SOA-Initiative in einem gerade erst entstehenden IT-Umfeld, das sich dem ESB anpassen kann, eingesetzt werden. Im Vergleich zu dezidierten Integrationsplattformen wie Mule ESB oder JBoss ESB scheint OpenESB nicht flexibel genug für eine umfassende EAI und/oder SOA in heterogenen, gewachsenen IT-Landschaften zu sein. Wer den Aufwand nicht scheut: Um das Funktionsspektrum zu erweitern, können natürlich via JBI auch die Komponenten anderer ESBs angebunden werden.

Mule ESB

Mule ist mehr als ein reiner ESB. Mule ist eine auf Java aufbauende Integrationsplattform. Diese Plattform ist wegen ihrer modularen Konstruktion äußerst flexibel und skalierbar und eignet sich für umfangreiche EAI und/oder SOA-Aufgaben ebenso wie für Eigenentwicklungen, die auf den Modulen des Mule ESB aufsetzen. Allerdings ist es für den professionellen Einsatz praktisch unumgänglich, einen Support-Vertrag zu schließen, da man sonst nicht in den Genuss einiger wichtiger Tools kommt, die für umfangreiche Umgestaltungen einer Systemlandschaft unerlässlich sind. In der Community-Edition fehlen also vor allem die Management-Console und einige wichtige Konnektoren (z. B. JDBC). Zur Konfiguration des ESB wird ein eigener XML-Dialekt verwendet; es gibt aber nur wenig Tooling-Funktionalität, die den Anwender dabei grafisch unterstützt. Szenarien im lizenzierten Enterprise-Einsatz: der Mule ESB als Integrationsplattform zur Harmonisierung von heterogenen, gewachsenen IT-Systemen oder als reiner ESB.

Petals ESB

Petals ESB ist ein auf Java basierender ESB, der die JBI-Spezifikation implementiert. Neben dem reinen ESB bietet bereits die Community-Edition viele Tooling-Funktionalitäten, eine eigene IDE sowie eine Monitoring-Lösung, die die Definition und Auswertung von Key Performance Indicators (KPI) ermöglicht. Mule ESB etwa stellt seine Monitoring-Lösung nur Enterprise-Kunden zur Verfügung und OpenESB hat dafür zwar eine JBI-API, aber kein eigenes Tool. Petals ist, nicht nur wegen seines Monitoring-Tools, besonders für den Einsatz in verteilten und großen Umgebungen geeignet. Die Architektur von Petals selbst ist verteilt – im Gegensatz zur MOM-Architektur mit ihrem zentralen Message-Container -, was die Ausfallsicherheit noch einmal erheblich erhöht. Wer keinen Support braucht, Lizenzkosten scheut und über eine eigene IT-Abteilung mit genug Personalressourcen verfügt, für den kommt Petals ESB in Frage, da er auch noch mit Komponenten der anderen JBI ESBs ausgebaut werden kann.

Sopera ASF

Sopera ASF (Advanced Service Factory) nutzt einen ServiceMix-Kern, der auch in dem von Sopera initiierten Eclipse Swordfish integriert ist. Sopera ASF ist sehr stark modular aufgebaut, wobei gerade die Community-Edition besonders auf Open-Source-Komponenten setzt, die man aufgrund der zum Einsatz kommenden JBI-Spezifikationen recht einfach austauschen und kombinieren kann. Sopera ASF übernimmt allerdings nur für sein zertifiziertes Komplettpaket den Support. Genauso wie Petals ESB und ServiceMix ist Sopera ASF besonders gut in verteilten Umgebungen einzusetzen, weil auch hier die ESB-Architektur selbst verteilt ist. Im konkreten Fall bedeutet das: Die ESB-Funktionalitäten laufen nicht im zentralen Bus ab, sondern sind in Form von so genannten Service Backbone Libraries in die angeschlossenen Clients integriert.

Synapse/WSO2

Synapse ist ein einfach gestrickter ESB, der auf Apache Axis2 basiert. Als einziger Kandidat im Rennen setzt Synapse für die Umsetzung seiner ESB-Funktionalitäten ausschließlich auf Web Services. Zur Konfiguration des ESB wird – wie auch bei Mule – ein eigener XML-Dialekt verwendet. Legacy-Systeme lassen sich wegen der Ausrichtung auf Web Services nur schwer anbinden. Das Einsatzgebiet dieses ESB ist also auf Umgebungen begrenzt, in denen das Web-Service-Paradigma bereits weitgehend umgesetzt ist. EIPs kommen zum Einsatz, der ESB skaliert gut und schont aufgrund seiner Einfachheit die Ressourcen.

Fazit

Den ESB selber bauen und an die ganz konkreten Bedürfnisse anpassen, Lizenzkosten vermeiden und auf Support verzichten? Möglichst hohe Flexibilität beim Einsatz oder sich an einen Hersteller binden? Heterogene, gewachsene Systeme mit einer mächtigen Integrationsplattform in den Griff bekommen? Oder bereits beim Unternehmens-Startup das IT-System um einen ESB herum konfigurieren und strikt nach dem SOA-Gedanken ausrichten? Auf JBI setzen oder nicht? Nach Evaluation der zehn ESBs ist zumindest eines klar geworden: Die Eigenschaften der verglichenen Systeme sind so vielfältig wie die möglichen Einsatzszenarios. Dafür sind die Freiheiten bei der Kombination von verschiedenen Lösungen umso größer – offene Sourcecodes und JBI machen es möglich. Gerade aber deshalb sind im Open-Source-Bereich auf der Suche nach einem geeigneten Enterprise Service Bus ausführliche Recherche und das Sich-Bewusstmachen der gestellten Anforderungen von entscheidender Bedeutung. Der Open-Source-ESB-Vergleich soll Ihnen dabei helfen.

Jörg Wissmeier ist Consultant der Nürnberger Ancud-IT-Beratung GmbH in den Bereichen ESB/SOA und BPM.

Adrian Kraus ist Texter und Webdesigner bei der Nürnberger Ancud-IT-Beratung GmbH.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.