MÜNCHEN (COMPUTERWOCHE) - Unter der Bezeichnung "Enterprise-Service-Bus" (ESB) bewerben immer mehr Hersteller von Infrastruktursoftware ein Middleware-Konzept, das den Aufbau serviceorientierter Architekturen (SOA) erlauben soll.

Der derzeit viel disktutierte SOA-Ansatz sieht vor, Anwendungen oder Anwendungsbestandteile künftig als Dienste zu konzipieren, die sich beliebig verteilen und dynamisch zu Geschäftsprozessen verknüpfen lassen. IT-Systeme sollen so ihren monolithischen Charakter verlieren und sich flexibel und frühzeitig an neue Anforderungen und Abläufe an-passen lassen. SOA gibt keine kon-krete technische Implementierung vor, wird aber immer wieder im Zu-sammenhang mit dem Einsatz von Web-Services-Standards bei der An-wendungsintegration gesehen. Eine wachsende Gruppe von Herstellern betrachtet diesen Ansatz jedoch als zu rudimentär und bewirbt stattdes-sen den ESB als physikalische Imp-lementierung einer SOA, die vor al-lem eine umfassendere Prozesssteu-erung zwischen den Anwendungs-dienste ermöglichen soll.

Hinter den derzeit beworbenen ESB-Produkten steckt im Wesentlichen eine Messaging-Lösung, die Systeme lose und flexibel über diverse Messa-ging- und Transportprotokolle sowie Standardschnittstellen verbindet. Un-terstützt werden dabei Standards wie Java Message Service (JMS), die Ja-va Connector Architecture, JDBC, Soap, Active X/COM sowie C oder C++. Hinzu kommen Dienste zur Steuerung asynchroner Prozesse wie Content-basierendem Routing, Me-chanismen 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 Routing und Sicherheitsrichtlinien verwaltet und über das im laufenden Betrieb die Administration des ESB erfolgt.

Manche Marktbeobachter wollen im ESB-Ansatz bereits die Integrations-technik der nächsten Generation se-hen, die eine offene und preisgünsti-gere Alternative zu heutigen Produk-ten für Enterprise Application Integ-ration (EAI) liefern soll. Allerdings ist der ESB derzeit noch eine im Enste-hend befindliche Produktkategorie, für die jeder Hersteller den Akzent auf andere Basistechniken setzt. So orientiert sich beispielsweise die Pro-gress-Tochter Sonic Software mit ihrem Produkt "Sonic ESB" vor allem am JMS-Standard. Iona Technologies wirbt hingegen mit seinen "Artix"-Produkten besonders mit der Mög-lichkeit, alle gängigen Messaging-Produkte sowie Host-Systeme in eine SOA einbinden zu können. Weitere ESB-Produkte sind der "Entire X XML Mediator" der Software AG, die "Web Messaging Platform" von Kenamea oder "Spiritwave" von Spiritsoftware. Zudem werben immer mehr Anbieter wie selbstverständlich damit, den Aufbau von SOAs mit ihren bisheri-gen Infrastrukturprodukten zu

unter-stützen.

Doch nicht nur wegen der konkurrie-renden Implementierung sehen Kriti-ker derzeit nur eine geringe Nachfra-ge nach ESB-Lösungen. Laut Matt Quinn, Chief Architect beim EAI-Anbieter Tibco Software, dient der ESB-Ansatz in erster Linie nur eine technische Integration von Diensten. Fü die Verknüpfung komplexer Ge-schäftsprozesse seien die Produkte nicht ausgelegt. Derweil hofft das ESB-Lager auf die Unterstützung und die Marktmacht der großen Soft-warehäuser. So arbeitet derzeit an einem Messaging-Produkt, das 2004 auf den Markt kommen soll. Manche Marktbeobachter sehen zudem in der nächsten Generation des .NET-Frameworks von Microsoft, Codena-me "Indigo", eine Infrastruktursoft-ware auf Basis von Web-Services-Standards entstehen, die laut Gart-ner-Analyst Roy Schulte Features haben wird, die mit dem ESB-Ansatz vergleichbar sind. Die Auslieferung soll zeitgleich mit dem nächsten Windows-Release "Longhorn" beginnen. (as)