Das in Alpharetta, Georgia, ansässige Startup-Unternehmen Flamenco hat seinen Dienst Anfang Oktober in Betrieb genommen. Es verfolgt einen Peer-to-Peer-Ansatz, in dem der Service-Provider nur den Verbindungsaufbau zwischen zwei Applikationen kontrolliert. Dazu sind einige Voraussetzungen zu erfüllen. Beide Anwendungen müssen kompatibel zum Soap-Standard (Soap = Simple Objects Access Protocol) und jeweils als Web-Service im Flamenco-Netz definiert worden sein, inklusive Angaben darüber, wer zu welchen Bedingungen darauf zugreifen darf. Auf den beteiligten Rechnern aller Beteiligten muss eine von Flamenco zur Verfügung gestellte Proxy-Komponente laufen, die die Verbindung zum zentralen Netz-Management-System aufnimmt. Ferner verlangt der Betreiber eine Einrichtungspauschale in Höhe von 100000 Dollar.
Sind all diese Startbedingungen erfüllt, können Anwender Verbindungen zwischen zwei Endpunkten konfigurieren. Flamencos zentraler Dienst richtet den Übertragungsweg ein und gibt ihn frei, wenn es die von den Partnern definierten Regeln erlauben. In der Folge kommunizieren die Anwendungen direkt miteinander. Übertragen auf die Web-Services-Modelle von Herstellern wie Sun, Microsoft und IBM, leistet Flamenco ähnliche Dienste wie der Verzeichnisdienst UDDI. Über diese Vermittlung hinaus übernimmt Flamenco aber auch Zertifizierungs- und Registrierungsdienste, zeichnet den Netzverkehr auf und wertet ihn für kostenpflichtige Web-Services aus. Der Betreiber selbst verdient an der Zahl der geschalteten Verbindungen.
Es geht nur mit SoapBereits im Juli startete Grand Central seinen Dienst, der ebenfalls unter der Web-Services-Flagge läuft und nutzungsabhängig abgerechnet wird, jedoch einen zentralen Ansatz verfolgt. Der Betreiber unterhält derzeit in den USA insgesamt acht Knotenpunkte, die als Schaltzentrale für Kommunikation zwischen zwei Soap-kompatiblen Applikationen dienen. Anders als der Flamenco-Ansatz sieht Grand Central aber keine direkte Interaktion zwischen den entfernten Web-Komponenten beziehungsweise Anwendungen vor, sondern übernimmt jeweils die Requests des Absenders, verarbeitet sie auf den eigenen Servern und reicht sie zum Adressaten weiter. In der Praxis soll sich dieser Vorgang folgendermaßen abspielen:
Web-Services in der PraxisEin Hersteller benötigt für seine Produktion bestimmte Teile von seinem Zulieferer. Idealerweise könnte also das Bestellwesen des einen die Auftragsannahme des anderen direkt ansprechen und dort einen Produktionsprozess in Gang setzen. Weil die jeweils verwendeten Datenformate inkompatibel zueinander sind, scheitert jedoch die direkte Kommunikation zwischen den Anwendungen. Hier kommt der Dienstleister Grand Central ins Spiel und übernimmt die Konvertierung der Daten. Die Leistung von Grand Central geht dort über reine Applikationsintegration hinaus, wo nicht nur Daten konvertiert, sondern weitere Aktionen angestoßen werden. So könnten in dem Szenario etwa vor der Auftragsbestätigung Applikationen ausgelöst werden, die unter Berücksichtigung der aktuellen Rohmaterialpreise Kosten errechnen. Die Regeln dafür vereinbaren die Anwender und speichern sie auf Grand-Central-Rechnern.
Welches der beiden Modelle sinnvoller erscheint, ist kaum zu sagen. Problematisch ist jedoch, dass der ursprünglich universelle Ansatz von Web-Services auf der Strecke bleibt. Applikationen können zwar unternehmensübergreifend, aber immer nur über den einen Serviceanbieter kommunizieren. Nicht einfach für beide Startups dürfte es zudem sein, bis zur Reife des Web-Service-Marktes zu überleben. Gartner-Marktforscher Daryl Plummer rechnet nicht vor dem Jahr 2003 mit breiter Akzeptanz.
Abb: Provider als Vermittler von Web-Services
Der zentrale Ansatz sieht vor, alle Anforderungen dem Provider zu übergeben, der sie auf seinen Rechnern bearbeitet und vermittelt. Quelle: CW