Web-Services: Evolution statt Revolution

26.04.2002
MÜNCHEN (COMPUTERWOCHE) - Kaum eine Technologie wurde in der letzten Zeit über alle Hersteller- und Analystenlager hinweg so einhellig zum Trend erklärt wie XML-basierende Web-Services. Doch IT-Spezialisten machten im Gespräch mit CW-Redakteur Sascha Alexander deutlich, dass man in der Praxis noch am Anfang steht.

CW: Wozu sind Web-Services eigentlich gut?

Völter: Ziel ist die Integration von Anwendungen und Geschäftsprozessen zwischen Unternehmen weltweit. In der Praxis kommen Web-Services derzeit jedoch vor allem in geschlossenen Anwendungsumgebungen wie Intranets und Extranets vor, wo vorhandene und dem Entwickler bekannte Anwendungen integriert werden sollen, ohne dass dafür die diversen Registrierungsdienste wie UDDI nötig sind.

CW: Warum genügen dafür nicht vorhandene Technologiestandards wie Java/Remote-Method-Invocation (RMI) oder die Component Object Request Broker Architecture (Corba)?

Kocher: Standardtechnologien wie Corba oder auch Microsofts Component Object Model (COM) sind proprietär und verlangen eine enge Kopplung der Anwendungen. Heute wollen wir aber sehr unterschiedliche Systeme flexibel miteinander integrieren.

Marktplatzteilnehmer können nicht erst ihre diversen Protokolle aushandeln oder sagen, wie ein Objekt auszusehen hat, sondern hier sind offene und standardisierte Dienste nötig. Mit den Web-Services ist genau diese Hoffnung verbunden. So baut sich SOAP aus den Web-Standards HTTP und XML auf.

Starke: Technisch gesehen gibt es schon alles, was wir für die Anwendungsintegration brauchen. Doch die Entwicklung beispielsweise eines Corba-Service ist komplex, und ein RoI lässt sich nur langfristig erzielen. Web-Services versprechen hier eine einfachere Anwendungsintegration mit Mitteln, die jeder Programmierer in wenigen Tagen durchdringen und verstehen kann.

Oltmanns: Für Web-Services spricht, dass Anwender anders als bei Corba auf einen breiten Herstellersupport zählen können. Auch ist es ein Gewinn, dass man mit den Tools schneller und einfacher eine Web-Service-Anwendung erstellen kann als bei der lernintensiven COM- oder Distributed-COM-(DCOM-) Programmierung.

CW: Reichen die Basiskomponenten SOAP, WSDL und UDDI schon aus, um leistungsfähige Web-Services zu entwickeln?

Oltmanns: Wenn Sie heute ein Projekt starten, müssen Sie dem Vorstand eine Value Proposition machen. Bei der Auswahl der Technik haben Sie dabei oft gar keine Wahl zwischen Corba, Java oder Web-Services, weil schon eine Infrastruktur existiert, die weiter zu verwenden ist. In einem Projekt bei einem Automobilhersteller müssen wir derzeit elf Vorsysteme per Prozessintegration koppeln, im Einzelnen Host-, Datenbank- und Web-Anwendungen. Hierbei nutzen wir an einigen Stellen auch SOAP und WSDL mit dem Argument, dass wir per Web-Services künftig externe Zulieferer einfacher in die geschlossene Umgebung einbinden können.

Völter: Wir haben Web-Services bisher da verwendet, wo wir Client, Server, Anbieter und Benutzer unter Kontrolle haben. Sie helfen uns etwa, um von Java- auf Microsoft-Anwendungen zuzugreifen. Dies ist eine sehr willkommene Alternative zu bisherigen Bridges von Corba oder Java zu DCOM.

Starke: Die Integration von Microsoft-Anwendungen mit J2EE-Servern (J2EE= Java 2 Enterprise Edition) ist auch bei uns eines der Projekte, wo wir Web-Services einsetzen. Beide Welten zu verbinden war bisher unter Zeit- und Kostenaspekten schwierig. Einer unserer Kunden aus der Versicherungsbranche hatte eine Microsoft-Anwendung bisher nicht integriert, weil er nur standardisierte Techniken nutzen wollte - Java/COM-Bridges fallen durch dieses Raster durch. Anfang des Jahres haben wir dann SOAP und WSDL benutzt, um eine große Microsoft-Anwendung zu integrieren. Es ist eine reine Intranet-Lösung - die derzeitige Killeranwendung für Web-Services. Ich habe hier Aufrufer und Service-Provider unter Kontrolle und benötige keine externen Registries wie UDDI.

CW: Hersteller werben damit, dass die Generierung von Web-Services mit Hilfe von Toolkits und Entwicklungsumgebungen eine triviale Angelegenheit sei. Aber wie lassen sich die Dienste anschließend im Enterprise Computing richtig einsetzen?

Starke: Entwicklungs-Tools kommen erst dann zum Einsatz, wenn die künftige Architektur dokumentiert ist. Web-Services sind dabei wirklich nur eine Kommunikationsoption zwischen Anwendungen. Ich muss vorab entscheiden, ob ich verteilte Komponenten über Corba, Java-RMI oder eben Web-Services verbinde. Ebenso muss ich mit den Anwendern zuvor über Transaktionslasten und Sicherheitsfragen bereits gesprochen haben. Was nützt es mir, wenn ich Web-Services einsetze, aber später die Maschine die XML-Transformationslast nicht handhaben kann?