Befürchtungen, dass Web-Services die Middleware ins Abseits drängen, gehen von einem Gegensatz aus, den es so eigentlich nicht gibt. Denn auch Web-Services sind nichts anderes als plattformunabhängige Middleware, auf Basis des Datenstandards XML. Genau wie es auch mit herkömmlicher Middleware möglich war, sollen Web-Services Business-Anwendungen von ihrer Plattform abstrahieren und über eine plattformunabhängige Schnittstelle miteinander verknüpfen. Neu sind allerdings die Standards, über die sich Web-Services definieren: Neben XML sind Soap für Funktionsaufrufe, WSDL für Schnittstellenbeschreibungen, UDDI als Verzeichnisstandard und das Web-Protokoll HTTP für alle Aufrufe über das Internet beteiligt.

Bis auf ein paar neue Standards bleibt also alles beim Alten? Nicht ganz, denn genau diese allgemein akzeptierten, herstellerübergreifenden Internet-Standards bieten die entscheidenden Vorteile von Web-Services gegenüber herkömmlicher Middleware: Die Integration von Anwendungen ist nicht mehr auf kompatible Applikationen auf beiden Seiten angewiesen, wie es zum Beispiel bei Message-orientierter Middleware der Fall ist. Dadurch wird besonders die Inter Enterprise Integration (IEI) vereinfacht. Anwendungen können mit Web-Services künftig viel leichter als Dienste für Kunden oder Partner via Internet zur Verfügung gestellt werden.

Corba scheitert an der Firewall

Wer mit herkömmlicher Middleware Dienste über das Internet anbieten wollte, scheiterte meist an der Firewall. Corba beispielsweise ist zwar eine plattformunabhängige Middleware, verwendet aber dynamische Ports bei der Kommunikation, sodass der Aktionsradius nur schwer über die Unternehmensgrenzen ausgedehnt werden konnte. Andere Systeme wie etwa Electronic Data Interchange (EDI) sind zwar in der Lage, Geschäftsdaten zwischen verschiedenen Unternehmen auszutauschen, stellen aber lediglich eine datenorientierte anstelle einer prozessorientierten Integration dar und sind für die unternehmensinterne Integration ungeeignet. Web-Services hingegen basieren auf einfachen, schnell erzeugbaren und plattformunabhängigen Schnittstellen. Diese Schnittstellen können dann auf einfache Weise für prozessorientierte Integration wie beispielsweise bei ebXML definiert zur Business-to- Business-Integration aufgegriffen werden.

Lückenhafte Standards

Der Weg für Web-Services als Standard-Technik ist derzeit aber noch mit zahlreichen Baustellen bestückt: Standards für Sicherheit, Transaktionen, Load Balancing und Fail Over, die bei Middleware-Produkten selbstverständlich sind, werden für Web-Services erst noch entwickelt. Wann die beteiligten Firmen sich auf gemeinsame Standards einigen, ist noch nicht absehbar. Es wird also noch eine ganze Zeit lang eine Koexistenz von klassischer Middleware und Web-Services geben. Diese Situation ist nicht ungewöhnlich, denn auch bisher gab es keine Middleware, die für alle Integrationsprobleme gleichermaßen geeignet war. Message-orientierte Middleware oder Object Request Broker (ORB), asynchrone oder synchrone Ansätze: Je nach Aufgabenstellung waren stets unterschiedliche Lösungen gefordert.

Beim Zusammenspiel von Web-Services und klassischer Middleware sind verschiedene Szenarien denkbar. Eine sinnvolle Arbeitsteilung könnte zum Beispiel so aussehen: Unternehmensinterne Anwendungen werden mit klassischer Middleware gekoppelt, um zum Beispiel die Geschäftsprozesse in einzelnen Unternehmensabteilungen zu verknüpfen. Web-Services setzen eine Ebene höher an und verknüpfen diese entstandenen Integrationsinseln über Abteilungs- oder Unternehmensgrenzen hinweg.

Ein Beispiel aus der Praxis veranschaulicht diese Verzahnung der verschiedenen Integrationsansätze: Als sich die Schweizer Großbank Credit Suisse Group mit der Versicherungsgesellschaft Winterthur zusammenschloss, sollten die Versicherungsprodukte auch über das Credit-Suisse-Multichannel-Banking angeboten werden. Die Voraussetzungen dafür waren günstig, denn beide Unternehmen haben ihre Softwarearchitektur bereits vor der Fusion serviceorientiert aufgebaut. Das heißt: Mainframe-Anwendungen wurden mit Corba angebunden und können damit an andere Applikationen angekoppelt werden. Auf Grundlage dieser serviceorientierten Architektur ist es ohne großen Aufwand zu schaffen, Web-Services zu erstellen, welche die Versicherungsprodukte in den neuen Vertriebskanal integrieren. Denn mittlerweile gibt es Tools, die einfach die Funktionalität von Corba-Objekten über Web-Services zugänglich machen.

Neben der Verknüpfung von Anwendungen zwischen Unternehmen können Web-Services auch zur Integration von internen Unternehmensprozessen eingesetzt werden. Dabei muss aber im Einzelfall geprüft werden, welche Integrationsvariante sinnvoller ist. Ein mögliches Entscheidungskriterium ist hier die Granularität des Datenstroms: Müssen viele kleine Datenpakete in kurzen Abständen übertragen werden, sind klassische Middleware-Lösungen oft besser geeignet, da sie diese Lastanforderung heute noch besser verarbeiten können. Anders sieht es aus, wenn nur einzelne, größere Datenportionen zwischen den Anwendungen ausgetauscht werden müssen. Bei eher lockeren Verbindungen zwischen Applikationen können Web-Services eine kostengünstige Alternative sein.

Von IIOP auf Soap

Denkbar ist auch, bereits vorhandene Middleware-Verbindungen durch Web-Services zu ersetzen. Technisch ist es möglich, die vorhandene Architektur einer Corba-Umgebung zu nutzen und dann vom Corba-Protokoll IIOP zum Web-Service-Protokoll Soap zu wechseln. Die bestehende Architektur bleibt stabil, lediglich das Protokoll ändert sich. Mehraufwand entsteht allerdings durch die Umwandlung von Daten in das XML-Format. Ob es sinnvoll ist, bestehende Integrationslösungen durch Web-Services zu ersetzen, hängt von der konkreten Situation ab. Solange Anwendungen nicht als Dienste nach außen angeboten werden sollen, besteht oft noch gar keine Notwendigkeit, zu Web-Service-Standards zu migrieren. Gerade wenn es um unternehmenskritische Anwendungen geht, die auf höchste Verfügbarkeit und Performance angewiesen sind, gilt in vielen Fällen noch der Satz: "Never touch a running system." Mit wachsender Leistungsfähigkeit der Infrastrukturen wird sich das aber ändern: Web-Services werden dann bei der Performance keine Nachteile mehr gegenüber etablierten Middleware-Lösungen haben - vorausgesetzt, die entsprechenden Standards für Load Balancing, Failover, Transaktionen oder Guaranteed Delivery werden bis dahin von allen Beteiligten unterstützt.

Zukunftsträchtige Lösung

In einem sind sich die meisten Experten sicher: Web-Services sind die universelle Integrationslösung der Zukunft, da sie vollständige Interoperabilität zwischen Plattformen und Programmiersprachen ermöglichen können und standardisierte, wiederverwendbare Schnittstellen bereitstellen. Unternehmen sollten sich daher bald mit der neuen Technologie beschäftigen und sie in Projekten bereits heute testen. Klassische Middleware-Architekturen werden aber mittelfristig nicht verschwinden. Bei der Integration von Geschäftsprozessen kommt es also künftig darauf an, die Stärken von Middleware und Web-Services zu kombinieren. (wm)

*Uwe Lehr ist Geschäftsführer Zentral- und Osteuropa bei der Iona Technologies GmbH in Weiterstadt.

Angeklickt

Als Middleware werden Technologien bezeichnet, die Verbindungen zwischen verschiedenen Applikationen herstellen können. Klassische Verfahren wie Corba und COM sind teilweise bereits seit zehn Jahren im Einsatz. Web-Services werden als die kommende Technologie zur Integration von Anwendungen betrachtet, da sie auf allgemein akzeptierten Standards wie XML basieren. Bis Web-Services bei Performance und Sicherheit die gleiche Zuverlässigkeit wie klassische Middleware erreichen, wird allerdings noch einige Zeit vergehen. Solange gilt also künftig der Grundsatz: Middleware und Web-Services - nur gemeinsam sind sie stark.

Abb: Die Integrationsplattform

Web-Services werden künftig als universelle Integrationslösung fungieren. Dabei sind sie eher eine Ergänzung denn ein Ersatz für Middleware. Quelle: Iona Technologies