Herzen für Unternehmensabläufe

Zerbrechlich, unflexibel, teuer zu pflegen. Das sind nicht die Wörter, mit denen führende Hersteller ihre Produkte beschrieben sehen wollen. Aber in Zeiten, in denen Organisationen hohes Interesse an Begriffen wie Geschwindigkeit und Agilität zeigen, sind sie konfrontiert mit Systemen, die anscheinend aus bröckligem Zement gebaut sind. Applikationen, die so entwickelt wurden, als ob sich niemals etwas ändern würde, werden teurer und träger, sobald eine Organisation versucht, sie neuen Geschäftszielen anzupassen. Automation funktioniert selten, denn Systeme verlangen menschliche Eingriffe und Neuentwicklungen. Das Ausrichten der Technik an den Geschäftszielen schlägt häufig fehl, weil es Integrationsprobleme gibt.

Die Lösung heißt Serviceorientierung. Service oder Dienstleistung sind etwas, was Geschäftsleute verstehen. Die Antwort der IT ist SOA (serviceorientierte Architektur). Sich schnell entwickelnde XML- und Web-Service-Standards revolutionieren die Art, in der Entwickler Systeme erzeugen und sie über verteilte Netzwerke integrieren. Keine proprietäre Sprache und keine Objektmodelle mehr. Mit sich ausbreitender SOA-Adaption transformiert die Revolution Werkzeuge für BPM (Business-Process-Management), EAI (Enterprise-Application-Integration) und nachrichtenorientierte Middleware.

Web-Services lassen sich mit reifer Technik entwickeln, aber um das zu erreichen, von dem Geschäftsführer träumen, benötigt SOA eine eigene Engine. Und diese Engine ist der Enterprise-Service-Bus, kurz ESB. Ein ESB verschmilzt mehrere Techniken, die SOA-Verteilungen dazu befähigen, Geschäftsprozesse wiederzuverwenden und Prozesse sowie Beziehungen zwischen Applikationen durch Konfiguration statt durch Codierung zu ändern. Zu den Kernaufgaben eines ESB zählen Messaging, Datenfransformierung, Routing, Web-Services- und Protokollunterstützung sowie Service-Orchestrierung.

EAI als erste Referenz
Die IT muss verstehen, wie ESB eine neue Technikkombination beschreibt, selbst wenn einige Komponenten bereits Teil größerer Suites sind. Die Ausrichtung von ESB auf SOA und verteilte Netzwerke geht weit über eine Marktplatzierung hinaus. Um zu sehen, wo und wie ESB-Produkte anders sind, hilft am besten ein Blick auf das, was ESB bei der Applikations-Middleware vorausging: EAI.

Bevor das Web kam, war EAI eine Variante zu speziell programmierten Punkt-zu-Punkt-Kommunikations- und Informationszugriffsroutinen, die für viel Spaghetti-Code sorgten. Unter diesem Problem litten Organisationen, die versuchten, viele große, interne Legacy-Applikationen und verpackte Applikationen zu integrieren. Die Integration über Systeme erforderte benutzerdefinierte, sich wiederholende und fehleranfällige Transformationsprogramme. Die EAI-Anbieter offerierten ein Modell für zentrale Transformation, Sicherheit und andere Funktionen. Ein Hub kommunizierte mit auf Objekten basierenden Adaptern, die existierende Applikationen umhüllten, damit sie teilhaben konnten am Datenaustausch mit anderen Applikationen (durch den Hub).

EAI besiegte zwar nie den Spaghetti-Code oder Punkt-zu-Punkt-Wettbewerber, aber es zeigte einen Weg, der die Applikationsintegration von einer Ad-hoc-Lösung auf eine abstraktere Ebene führte. Dort konnten sich die Entwickler auf die Implementierung von Komponenten und auf die Objektmodellierung konzentrieren. So half EAI der objektgesteuerten Architektur beim Start. Entwickler nutzten die Object-Management-Group-(OMG-) und Unified-Modelling-Language-Standards (UML) sowie applikationsunabhängige Datenmodelle, um Systeme zu erzeugen, die auf Plattformen ausführbar waren.

Führende EAI-Hersteller implementierten die »CORBA«-Spezifikation der OMG in ihren Architekturen, um mehr Standardinteroperabilität zwischen verteilten Knoten zu erhalten. Corba-Systeme (und Microsofts »DCOM«-Systeme) unterstützten ausschließlich objektorientierte RPC-Kommunikation, eine Rolle, die sich grob mit dem vergleichen lässt, was Soap mit XML-Dokumenten über Http und andere Internetprotokolle tut. IBM/Rational und andere Hersteller modernisieren ihre UML und ihre auf MDA basierenden Entwicklungs- sowie Architekturwerkzeuge, um sie mit SOA und Web-Diensten arbeiten zu lassen.

Der nächste Schritt
Plötzlich präsentierte das Internet eine Szenerie, in der Tausende unbekannter Clients versuchten, über das Web mit Servern zu kommunizieren. Ein neues Modell für verteiltes Computing war gefragt: Web-Services.

Der Web-Services-Stack verdankt Corba viel. Zahlreiche Dinge entsprechen dem, was Corba einführte. Die Resultate sind aber noch nicht vollständig vergleichbar. Beispielsweise erreichen Web-Services nicht die Performance von Corba-Systemen, und sie benötigen eine vollständige Unterstützung von Transaktionsverarbeitungs-Eigenschaften – einige ESBs versuchen dies zu korrigieren, haben dabei aber nur geringen Erfolg. Der Mainstream zielt ohnehin auf eine andere Ebene verteilten Computings, als Corba ins Auge fasste. SOA beschreibt ein Netzwerk unabhängiger, wiederverwendbarer Dienste, die sich auf der Basis offener Web-Standards finden und nutzen lassen.

Die IT liebt die Kontrolle, die das Hub-Modell bietet. Viele IT-Abteilungen würden diese Kontrolle gern beim Umzug zu SOA mitnehmen. Leider widersprechen der zentrale Hub-Ansatz und die langsamere Natur der modellgetriebenen Entwicklungsmethoden bei Corba und EAI dem heutigen Agilitätsziel. Auch hat Corba XML nicht leicht angenommen. Soap, WSDL, Uddi und Web-Services generell sind exakt deshalb in Fahrt gekommen, weil die Menschen das Potenzial von XML als Datenverteilungs-Middleware als Variante zu Corba erkannt haben.

EAI-Anbieter sind zu Wohlstand gekommen, weil sie hohe Preise für neue Services und Hub-Aufrüstungen verlangen konnten. Also überrascht es nicht, dass auch die Kosten das Interesse an SOA forcieren. EAI-Projekte sind dafür bekannt, dass sie Budgets sprengen, weil die Systeme Spezialisten für die Entwicklung und Pflege erfordern. SOA erleichtert es Unternehmen oder Abteilungen, mit eigener Service- und Applikationsentwicklung voranzuschreiten, solange sie an ESB- und Web-Services-Standards festhalten.

Nachrichtübermittler
Mit Messaging befähigt der ESB die SOA, mehr Arten des Computings zu unterstützen als simple Soap/Http-Web-Services über TCP/IP-Netzwerke. Nachrichtenorientierte Middleware nutzt eine Queue, um Daten- und Inhaltskommunikationen zu organisieren, zu priorisieren und den Transaktionsstatus zwischen verteilten Systemen auszutauschen. ESB nutzt dies, um locker miteinander verbundene Services zu unterstützen. Messaging bildet auch die Basis für ereignisgesteuertes Computing; ein ESB dient als Backbone, von dem aus das System auf Ereignisse oder Statusänderungen in Applikationen lauscht und Prozessintelligenz einsetzt, um automatisch zu reagieren.

Eine der ersten Aufgaben purer ESB-Produkte und der EAI-Produkte, die sich allmählich in ESBs verwandeln, ist es, die Kompatibilität mit älteren nachrichtenorientierten Middleware-Systemen zu bieten. So kann eine SOA XML- und Nicht-XML-Welten integrieren und eine Message-Queuing-Fähigkeit nutzen, um den Zugriff auf Applikationen, Datenbanken und Verzeichnisse zu verwalten.

Eine Schlüsselentwicklung ist der Java-Messaging-Service (JMS) 1.1, eine Programmierschnittstelle innerhalb der J2EE-1.4-Spezifikation. Applikations-Server-Provider wie BEA, IBM, Oracle und SAP stehen unter Druck, ihre konventionelle Middle-Tier-Rolle an den SOA-Stil des verteilten Computings anzupassen. Einige haben bereits JMS-Komponenten einfließen lassen.

Es ist Spannung auf dem Markt, und diese Spannung reflektiert die größere Debatte, wie ein ESB als SOA-Zentralbestandteil zu etablieren sei, als Kontrollpunkt für Kommunikationen, Serviceanforderungen, Transformation und Mediation, Sicherheit und andere Dinge.

Sehr wahrscheinlich werden drei Faktoren das aktuelle Bild von ESB-Messaging ändern. Erstens: Microsofts Windows-Communication-Foundation (Indigo) und Biztalk-Server, die Schlüsselelemente von .Net-SOA, können zu klareren Produkten für ESB führen. Zweitens: Nicht sämtliche Geschäfte benötigen oder wollen den kompletten ESB-Kram, und damit könnte Open-Source Aufmerksamkeit erregen. Drittens: Neue Oasis-Web-Services-Standards für zuverlässiges Messaging und Routing könnten JMS verdrängen.

Wiederverwendbarkeit als Ziel
Wird ESB Organisationen, die ESB implementieren, ein wenig näher an den Heiligen Gral der Wiederverwendbarkeit heranführen? Ja, falls ESB zwei Dinge tun kann: Zuerst muss ESB Messaging erfolgreich einführen und weit mehr locker verbundene Services erlauben, als simple Web-Services bieten. Die zweite Aufgabe ist, die Suche nach Wiederverwendbarkeit von der Code-Ebene auf eine höhere Abstraktionsebene zu hieven.
dj@networkcomputing.de