Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

12.04.2002 - 

CW-Roundtable zum Technologietrend

Web-Services: Evolution statt Revolution

MÜNCHEN - 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?

Oltmanns: Web-Services setzen ein sauberes Design voraus und müssen vorhandene Geschäftsprozesse abbilden. Zudem lässt sich die Mehrheit heutiger Unternehmensanwendungen kaum in Komponenten zerlegen. Wer SAP verwendet, hat da schon Glück, weil die Produktarchitektur bereits modular ist und BAPI-Schnittstellen bietet. Diese lassen sich relativ einfach mit einem Web-Services-Wrapper versehen.

Völter: Web-Services und bisherige Komponententechnologie sind zwei völlig verschiedene Paar Schuhe. Komponenten haben den Vorteil, dass ich bestimmte Funktionen an den Container eines Applikations-Servers auslagern kann, etwa Transaktionsverwaltung und Sicherheit. Web-Services können diese Funktionalität der Komponenten über ein weiteres Kommunikationsprotokoll einem Client zur Verfügung stellen. Das Problem ist nur, dass ich derzeit noch keine Sicherheitsinformationen transportieren oder Transaktionen abwickeln kann. Deshalb lassen sich Web-Services bisher nur für relativ einfache, zustandslose Zugriffe auf Dienste-APIs verwenden.

CW: Das Marketing suggeriert, dass die angebotenen Basiskomponenten für Web-Services identisch implementiert und daher leicht zu verwenden sind. Tatsächlich sind die Spezifikationen aber noch im Fluss, und erst kürzlich wurde mit der Web Services Interoperability Group (www.ws-i.org) ein Konsortium geschaffen, das eben die Standardisierung künftig sicherstellen soll.

Starke: Mit der Spezifikation von Soap begann eine Kooperation auf technischer Basis zwischen feindlich gesinnten Herstellern etwa von Microsoft mit Sun und IBM. Beide Lager kommen von dieser Schiene nicht mehr herunter. Deshalb muss man sich über die Zukunft der Spezifikationen nicht grundsätzlich sorgen, zumal Anwender und unabhängige Gremien an der Formulierung der Standards mitwirken.

Völter: Es würde ja schon reichen, wenn man sich auf Dauer auf den kleinsten gemeinsamen Nenner einigen könnte.

CW: Ein Ziel mit Web-Services ist ein dynamisches E-Business, in dem Dienste auch über das Web kommunizieren. Aspekte wie Transaktionen, Sicherheit, Quality of Service, Verfügbarkeit und Authentifizierung sind jedoch bisher nur ansatzweise geklärt. Gibt es schon Kunden, die trotzdem den Sprung ins weite Web wagen?

Hohneck: Es gibt erste, aber recht unspektakuläre Anwendungen. So etwa im Einkauf oder in straff organisierten Lieferketten. Aber viele Unternehmen sind sehr vorsichtig, einen Teil ihrer Geschäftslogik derart zu exponieren. In kleineren Unternehmen sehen wir zudem den Trend zu Zusammenschlüssen in lokalen Marktplätzen. Dort können die Teilnehmer im kleinen Rahmen ihre eigenen Standards definieren.

CW: Werden XML-Initiativen wie Rosettanet oder Ebxml, die eine Standardisierung von Geschäftsabläufen im Web anstreben, mit dem Web-Services-Konzept verschmelzen?

Starke: Organisationen wie Ebxml arbeiten noch langsamer als deutsche Behörden. Ich bezweifle, dass wir in den nächsten zwei Jahren verwertbare Ergebnisse sehen werden. Auch die Versprechungen der Marketiers, dass Web-Services künftig vollautomatisch untereinander kommunizieren können, höre ich mit Skepsis. Es wird keine weltweiten Standards geben, die vorschreiben, was eine Rechnung oder ein Artikel ist. Wir sprechen in unseren Projekten mit großen Handelsorganisationen, die die Aktivitäten Hunderter von Handelsunternehmen bündeln, und die sagen uns, dass es häufig nicht kosteneffektiv ist, sich in langwierigen Abstimmungen auf gemeinsame Definitionen zu einigen.

Völter: Vor zehn Jahren wurde versucht, über Corba-Task-Forces Business-Standards zu spezifizieren. Das hat aber nur wenige Unternehmen interessiert. Seit Jahren wird davon geredet, dass sich Komponenten wiederverwenden lassen sollen. Auch das funktioniert nicht, sondern es werden nur die Container weiterbenutzt, weil sich niemand auf die fachlichen Gemeinsamkeiten einigen kann. Letztlich sind es also nichttechnische Probleme, die da gelöst werden müssen, und das geht nur sehr langsam voran.

Kocher: Nicht nur die Artikel müssten einheitlich beschrieben werden, sondern auch die Geschäftsprozesse, um etwa festzulegen, welche Reihenfolge und welche Schritte eine Transaktion umfasst. Alle Beteiligten müssten dazu den selben Business-Flow haben.

Hohneck: Durch das Herausgeben von Geschäftslogik mache ich mich auch abhängig von Ereignissen, die anderswo ablaufen und automatisch zu Transaktionen und Geschäftsvorfällen in meinen Systemen führen. Je mehr Web-Services ich verwende, desto mehr Hoheit über meine Geschäftsprozesse gebe ich her.

CW: Also sind Web-Services zunächst einmal ein weiterer interessanter Ansatz für die interne Anwendungsintegration. Was soll denn nun ein CIO oder IT-Chef in dieser Situation praktisch machen?

Hohneck: Web-Services können uns helfen, an bestimmten Punkten in der Architektur die Anwendungskommunikation zu vereinfachen. Das ist aber nicht trivial. Es gibt eine ganze Beraterbranche, die schon damit beschäftigt ist, interne Systeme miteinander zu integrieren.

Oltmanns: In meiner kontrollierten Intranet-Umgebung habe ich schon jetzt andere Technologien. Web-Services bringen mir vor allem dann etwas, wenn ich die Firmengrenzen überschreite und mit Partnern gemeinsame Geschäftsprozesse abbilden kann. Dies sind aber weit reichende Entscheidungen, die letztlich der CIO und die Geschäftsleitung treffen. IT und Fachabteilungen müssen deshalb Szenarien entwickeln, in denen Web-Services einen Mehrwert für die Produktion, Entwicklung oder die Beschaffung bringen, um sich in der Firmenleitung Gehör zu verschaffen.

Starke: Mein Rat ist: Nehmt Web-Services in euren Technologiebaukasten für Enterprise Application Integration (EAI) auf und erweitert so die Werkzeugpalette. Derzeit muss man aber noch mit Schwächen einzelner Implementierungen etwa zwischen Microsoft Soap und Apache leben und seine Architektur daraufhin kontrollieren. Umfangreiche Prototypen sind deshalb notwendig. Grundsätzlich ist aber Einsatz von XML kein Problem: Tools zur Verarbeitung von XML-Dokumenten sind schon heute stabil und ausgereift.

CW: Kann die IT mit Web-Services Geld sparen?

Kocher: Sie sind für viele Aufgaben die wesentlich einfachere Methode, um Dienste oder Anwendungen zu integrieren. Werden Web-Services erst einmal breit eingesetzt, wird es viel Know-how, Support und auch eine wesentlich bessere Tool-Unterstützung geben als etwa bei Corba. So gibt es heute bereits (neben den Toolkits für Web-Services) auch schon spezielle Werkzeuge wie "XML Spy", die über einen Soap-Debugger verfügen.

Hohneck: Wenn die Anforderungen nicht zu hoch sind, können Web-Services Einsparungen bringen. Doch im Moment fehlt es an Ideen, wie ich auch mit kleinen schnellen Implementierungen einen Nutzen erzielen kann.

CW: Welche neuen Geschäftsmodelle wären denn denkbar? Wird es Web-Services-Provider geben, wie Microsoft hofft?

Oltmanns: Das ist bestimmt ein Trend. Momentan fehlen aber die Geschäftsideen. Sich die aktuelle Temperatur in Athen übermitteln zu lassen oder online einen Tisch im Restaurant zu reservieren ist aus Business-Sicht nicht besonders attraktiv

Es diskutierten:Gernot Starke, IT-Strategien und Softwarearchitekturen, Bluecarat, Köln.

Markus Völter, Vorstand Mathema AG, Erlangen.

Hartmut Kocher, Geschäftsführer Cortex Brainware Consulting und Training, Pullach.

Peter Hohneck, Intelligence Mysap Solutions, Walldorf.

Peter Oltmanns, Geschäftsführer Chorus Gesellschaft für Informations- und Kommunikationstechnologie, München

WEB-SERVICESWeb-Services versprechen einen mit Hilfe der Extensible Markup Language (XML) definierten Standard-Kommunikationsmechnismus zwischen verteilten, lose gekoppelten Anwendungen. Ein Web-Service kann vorhandene Geschäfts- und Systemfunktionalität oder neu entwickelte komponentenbasierende Anwendungen beschreiben und lässt sich im Internet, Intranet oder Extranet einsetzen und registrieren. Das Kommunikationsmodell kann synchron oder asynchron sein.

Bisher sind drei Kernstandards für Web-Services veröffentlicht worden:

- Die Web Services Description Language (WSDL) beschreibt die Schnittstellen-Definitionen eines Web-Service. Sie bezeichnet das Format der Anforderungs- und Antwort-Nachrichtenströme, mit denen Funktionsaufrufe an andere Programm-Module abgesetzt werden.

- Das Simple Object Access Protocol (Soap) ist ein mit XML-Syntax arbeitendes Kommunikationsprotokoll zwischen Web-Services-Anwendungen, die Dienste nachfragen oder anbieten. Das Protokoll verwendet als Transportmedium in erster Linie HTTP und ist unabhängig von der verwendeten Programmiersprache, dem Objektmodell sowie dem jeweiligen Betriebssystem.

- Universal Description, Discovery and Integration (UDDI) ist ein Industrievorschlag für verteilte Web-basierende "Dienstekataloge", die als Web-Services bereitgestellt werden. Es basiert auf XML und Soap und stellt ein Verzeichnis von Adress- und Produktdaten sowie Anwendungs-Schnittstellen der verschiedenen Web-Services-Anbieter zur Verfügung.

Neben diesen Basisdiensten bearbeiten derzeit Industrie und Standardorganisationen wie Apache oder Oasis zahlreiche ergänzende Spezifikationen für Web-Services. Eine gute Übersicht findet sich unter http://www.xml.com/pub/a/2002/01/09/soap.html.