Enterprise Service Bus eint Multi-Kulti der Applikationen

Über Middleware-Funktionen soll ESB sicherstellen, dass unterschiedliche Anwendungen als Webservices integriert werden können

Aus den Anlagen, die man hat, das Beste machen – ein solcher Rat kann von Erziehungsberechtigten an orientierungslose Halbwüchsige gerichtet sein oder von IT-Beratern und -Analysten stammen, die DV-Verantwortlichen eine serviceorientierte Architektur (SOA) ans Herz legen. In beiden Fällen bleibt die Frage: Wie denn nur?
Im Fall der IT geht das über drei Komponenten: Standards sollen davon abhalten, in die falsche Richtung zu marschieren; Services sollen verhindern, Wertvolles auszuschließen; und über Integrations-Broker vermeidet man Kommunikationsbrüche. Das alles vereint ein Enterprise Service Bus (ESB) in sich. Deshalb kann ein solches System alle anderen Integrationswerkzeuge einbeziehen und vor allem ersetzen. Das aber erklärt den Einstieg von IBM, Bea, Software AG und Seebeyond in das Geschäft.

Die Deutsche Post AG hat sich für ‘Artix’ entschieden, das ESB-Produkt des irischen Anbieters Iona. Mit Hilfe der Middleware soll eine Service-orientierte Plattform aufgebaut werden, die als globale Infrastruktur für Web- und Enterprise-Services der Post inklusive des Paketdienstes DHL dient. Schon jetzt sei das ESB-System in das Service-BackBone eingebunden, das sich seit fünf Jahren in einem eigenen Architekturprogramm entwickelt hat, teilt der Dienstleister mit. Das Projektmaß geht eindeutig über den Status einer Pilotanwendung hinaus. Vielmehr sollen schrittweise Services als kritische Anwendungssysteme ein Bestandteil der Plattform werden.

“Es handelt sich hierbei durchaus um ein Projekt mit hohem Risiko”, wertet Massimo Pezzini, Analyst des Marktforschungsunternehmens Gartner, das Post-Vorhaben. Bis jetzt experimentieren die meisten Unternehmen noch mit der Umwandlung von Anwendungen in Services herum. Es gibt kaum Erfahrungen mit dem Aufbau von unternehmensweiten Service-Infrastrukturen. “Aber einer muss ja der erste sein”, kommentiert der Marktbeobachter lapidar.

Message plus Service

Auch das ESB-Konzept ist noch jung, so dass sich die Experten darüber streiten, was eigentlich einen Enterprise Service Bus ausmacht. Denn der Begriff wurde erst vor ein paar Jahren von Gartner-Analysten geprägt. Demnach stellt ein ESB Middleware-Funktionen zur Verfügung, die die Umwandlung von Anwendungen in Services mit Hilfe von Webservice-Standards derart ergänzen sollen, dass eine einzige Software-Infrastruktur genügt, um alle Systeme integrieren zu können. Dazu gehören Dienste wie ‘Publish and Subscribe’, Versionierung, Unterstützung verschiedener Protokolle und ‘Message Queing’ sowie alles was sonst zur Skalierbarkeit, Sicherheit, Administration und Verfügbarkeit des Gesamtsystems beiträgt.

Die Beschreibung bleibt damals wie heute unpräzise, wie etwa Lawrence Wilkes, Analyst beim Marktforschungs- und Beratungsunternehmen CBDI sagt. Er fragt noch heute, ob ESB eigentlich eine Architektur, ein Produkt oder beides ist und stellt fest, dass einige Produkte, die unter diesem Genre-Begriff auf den Markt kommen, nicht einmal IT-Services unterstützen.

Anbieter laufen um die Wette

Außerdem charakterisieren bisher weitgehend unbekannte, jedoch stark spezialisierte Firmen wie Cape Clear Software, Systinet, Sonic und Polars Lake das ESB-Umfeld. Insgesamt gibt es etwa 14 Produkte auf dem Markt. Diese können zwar laut Pessini auf gut funktionierende ESBs verweisen, mit denen sich nutzbringend und sicher geschäftsunkritische Service-Strukturen implementieren lassen.

Doch zugleich verberge sich hier das Risiko, dass die Zukunft dieser Anbieter kaum zu kalkulieren sei. Selbst Iona, schon 1991 als Universitätsgesellschaft des Trinity College in Dublin gegründet und krisenerfahren, steckte noch vor kurzem in der finanziellen Bredouille. Erst im Oktober konnte der Softwarehersteller für das abgeschlossene Vierteljahr etwa mit Hilfe des Post-Deals die Rückkehr zu schwarzen Zahlen bekannt geben.

Doch nun wird es ernst. Microsoft, Bea Systems, einige EAI-Anbieter (EAI = Enterprise Application Integration), IBM und die Software AG stellen ihre Interpretation des ESB-Themas vor. ‘Indigo’ lautet der Projektname für die ESB-Architektur von Microsoft. Es soll 2006/2007 Bestandteil des neuen Betriebssystems ‘Longhorn’ werden. ‘Quicksilver’ bezeichnet das ESB-Projekt bei BEA Systems. BEA-Chef Alfred Chuang beschreibt den Message Broker plus Web-Service-Management, der vermutlich 2005 auf den Markt gelangt, als “Brücke zwischen der J2EE-Welt und jedem anderen Teil der IT-Landschaft: MQ, Websphere, SAP und Mainframes zum Beispiel”.

Aus alt mach neu

Im Gegensatz dazu verkauft Seebeyond mit ‘E-Insight’ bereits ein ESB-Produkt. Das Unternehmen zählt zu den nach Analystenmeinung vom Aussterben bedrohten EAI-Anbietern. Ihre Produkte bieten alles das, was eines Tages ESBs können sollen. Allerdings werden Applikationen mit Hilfe von Adaptern beziehungsweise Konnektoren in ein proprietäres Bussystem oder einen Server eingeklinkt.

Da ESBs auf Webservice-Standards basieren wie Simple Object Access Protocol (Soap), die Extended Markup Language (XML) und die Schnittstellenbeschreibungssprache Web Service Description Language (WSDL), sind sie jedoch im Vergleich zu den EAI-Systemen preisgünstiger. Zudem entfallen die aufwendigen Adapter, da sich die Applikationen leicht in Services umwandeln und in das Bussystem einklinken lassen.

So komme es, dass sich schon heute Anwenderunternehmen zurecht für ein ESB-Produkt entschieden, obwohl bis jetzt ein solches gemeinhin nur ein Subset der EAI-Funktionalität bieten könne, erläutert Gartner-Analyst Pezzini. Somit arbeiteten alle EAI-Hersteller mit Hochdruck an der Entwicklung eigener ESB-Produkte. E-Insight von Seebeyond qualifiziert er jedoch als “das aktuelle EAI-Produkt des Herstellers in anderer Verpackung” ab.

Die Software AG schnürt Pakete

Auch die Software AG (SAG) scheint gut darin, Bekanntem ein neues Gesicht zu verleihen. ‘Entire X’ bezeichnete bisher die gesamte SAG-Integrationsfamilie. Jetzt gibt es die so genannten ‘Integration Packages’: ‘Enterprise Information Integrator’, ‘Enterprise Legacy Integrator’, ‘Enterprise Process Manager’ und ‘Enterprise Service Integrator’, das eigentliche Toolset für eine ESB-Implementierung.

Der Service Integrator stellt etwa Konnektivitätsfunktionen bereit. Die interne Kommunikation basiert in der Regel auf Java Messaging Services (JMS). Darüber hinaus kann der Bus aber auch traditionelle Message-orientierte Middelware (MOM) ansprechen, Dotnet-Anwednungen einbinden und verfügt über eine E-Mail-Schnittstelle. Zu den weiteren Eigenschaften gehören ein Content-basiertes Routing und die Transformationsdienste zur Unterstützung verschiedener XML-Formate. Dazu werden die XML-Beschreibungen und Metadaten in der SAG-eigenen Datenbank ‘Tamino’ gespeichert.

Auch die anderen Packages ergänzen beziehungsweise erweitern die ESB-Funktionalität. Zum Beispiel ermöglicht der Legacy-Integrator CICS- und IMS-Transaktionen, bildschirmbasierte 3270- und 5250-Anwendungen, Batch-Applikationen, sowie Cobol-, Natural-, PL/1- RPG-, C- und C++-Programme.

Die Auswahl zeigt bereits, dass ein Anwenderunternehmen, das mit Hilfe eines ESB-Produktes eine Service-orientierte Architektur umsetzen will, viel mehr braucht als ein Bussystem. So füllt der Bus bei IBM lediglich eine Lücke in der ‘Webshere’-Familie, ab Version 6.0. Er dient insbesondere dazu, Webshere-Anwendungen per Messaging einfacher und bis zu fünf mal schneller miteinander zu verbinden. Zum Beispiel dient das ESB-Modul als Kommunikationsschiene zwischen den einzelnen Services des Application Servers: Interaction Services, die der User in der Regel als Portal wahrnimmt, Process Services für die Choreografie der Prozesse, sowie Services für den Applikations- und Datenzugriff.

IBM puzzelt

Das zugrunde liegende Messaging-System ‘JMS Provider’ ist in Java implementiert und mit den Messaging-Produkt der IBM ‘Websphere MQ’ (früher MQ Series) interoperabel. Persistente, also dauerhafte Nachrichten werden entweder in der Embedded-Datenbank ‘Cloudscape’ gespeichert oder in externen Datenbanken via JDBC-Treiber (JDBC = Java Database Connector). Wie Horst Rerecha von IBMs österreichischem Referenzkunden Raiffeisen Informatik erläutert, kann er sich sogar vorstellen, auf Dauer in vielen Szenarien sein bisheriges Messaging-System MQ durch den in Websphere integrierten ESB zu ersetzen: “Erstens könnte ich mir MQ sparen und das neue Bussystem hat das Potenzial, zum Backbone zu werden.”

Damit wäre der Bankdienstleister in der Tat sehr fortschrittlich. Nach einer Untersuchung des Marktforschungsunternehmens IDC in Westeuropa stufen zwar mehr als 40 Prozent der Befragten die Integration als ‘wichtig’ ein, 26 Prozent sogar als ‘sehr wichtig’. Webservices aber wird wohl ein Großteil nie benutzen. In Spanien liegt die Adaption am höchsten. Dort setzen mehr als die Hälfte Webservices produktiv ein.

In Deutschland liegt die Rate am unteren Ende, bei nicht einmal 30 Prozent. Mindestens 40 Prozent geben zudem an, sie hätten auch keine Pläne zur Verwendung. Bei der Frage nach dem Einsatz von Service-orientierten Architekturen und zusammengesetzten (‘composite’) Applikationen fallen die Werte erwartungsgemäß niedrig aus. Denn das Konzept hat das Gros der Unternehmen noch gar nicht erreicht. Allerdings liegt Deutschland leicht vorne bei jeweils knapp 20 Prozent.

Dennoch sehen die meisten Anlaysten in ESBs die Middleware der Zukunft. Gartner empfahl im November dieses Jahres: “Im kommenden Jahr sollte jeder Hersteller eines Applikations-Servers, MOM oder sonstiger Integerations-Suites, der etwas auf sich hält, eine ESB-Stratgegie vorweisen können und bis zum Ende von 2006 ein Produkt auf dem Markt haben.”