Kommende Softwarearchitekturen sind nach Ansicht von Experten so konzipiert, dass eigenständige Anwendungen oder Anwendungsteile beliebig verteilt sind und sich dynamisch zu Geschäftsprozessen verbinden lassen. Eine solche serviceorientierte Architektur (SOA) wird in der aktuellen Diskussion meist mit Web-Services assoziiert, da sie die benötigte Plattformunabhängigkeit und Flexibilität sowie Standards wie XML bieten (siehe CW 20/03, Seite 10).
Offen ist hingegen, wie Prozesse in einer SOA zwischen Web-Services verlässlich gesteuert werden könnten. Hierbei sind Aspekte wie Transaktionssicherheit, asynchrone Kommunikation, Skalierbarkeit einer Anwendung sowie Datensicherheit zu klären. Zwar könnte dies beispielsweise ein zentral implementierter Service übernehmen, Analysten wie Gartner und eine wachsende Zahl von Herstellern favorisieren hingegen die Implementierung eines ESB als Infrastruktur einer SOA.
Der ESB stellt im Wesentlichen eine Messaging-Infrastruktur, die über Web-Services-Adapter sowie Standard-Schnittstellen und Protokolle wie Java Message Service, Java Connector Architecture, JDBC, das Simple Object Access Protocol (etwa über JMS), Active X/COM, C, C++ erreichbar ist. Hinzu gesellen sich Dienste zur Steuerung asynchroner Prozesse wie Content-basierendem Routing, Mechanismen wie "Store and forward", "Publish and subscribe" sowie das Transformieren von XML-Nachrichten mit Hilfe von XSLT-Prozessoren. Das Herzstück stellt ein Repository, das einheitliche Metadaten für das Routing und Sicherheitsrichtlinien verwaltet und über das im laufenden Betrieb die Verwaltung und Kontrolle der Middleware erfolgt. Ein SOA-Prozess entsteht, indem die Middleware intern semantische Kriterien einer Nachricht auswertet und dynamisch die Abläufe koordiniert. Die Definition von Prozessketten erfolgt zur Entwicklungszeit mit Hilfe entsprechender Tools.
Eine ESB-Lösung ist nach Ansicht der Marktforscher der Gartner Group eine Lowend-Alternative zu Produkten für Enterprise Application Integration (EAI), etwa von Tibco, Seebeyond, Microsoft, Webmethods oder Vitria. Sie bietet beispielsweise keine Standardadapter oder Prozessbibliotheken, könnte aber für Projekte, die einen "Overkill" an Features einer typischen EAI-Lösungen vermeiden wollen, attraktiv sein, und nutzt vor allem statt proprietärer Schnittstellen Web-Services. Über Letztere sollen sich Funktionen externer Anwendungen kapseln sowie weitere Dienste und Umgebungen (etwa für System-Management) einbinden lassen. Als erste Ansätze für ESB gelten laut Gartner Produkte wie "Sonic ESB 5.0" von Sonic Software, der "Entire-X XML Mediator" der Software AG, die "Web Messaging Platform" von Kenamea oder "Spiritwave" von Spiritsoftware.
Brücke zwischen Appservern
Das Einsatzgebiet von ESB-Produkten sehen die Analysten dort, wo eine standardisierte Kommunikations- und Serviceplattform zwischen inkompatiblen Applikations-Servern oder EAI-Lösungen nötig ist. "Entwickler sollten sich ESB anschauen, wenn sie Web-Services oder Standards wie COM, .NET, Java oder Cics mit anderen Programm-zu-Programm-Verbindungen in einer gemeinsamen Umgebung einsetzen wollen und eine asynchrone Kommunikation benötigen", heißt es in einem Bericht. Gartner geht davon aus, dass bis zum Jahr 2006 rund zehn Prozent aller neuen Integrationslösungen mit Hilfe eines ESB-Produkts aufgebaut sein könnten. Allerdings seien ESB-Produkte bisher wenig praxiserprobt und ihre Skalierbarkeit und Verfügbarkeit unbekannt.
Abb: Enterprise Service Bus
Basierend auf einer Messaging-Middleware sollen künftig verteilte Anwendungen miteinander kommunizieren können. Quelle: Sonic Software