Marktforscher von Gartner sagen voraus, dass die effiziente Nutzung von Web-Services Entwicklungsprojekte im Jahre 2005 um 30 Prozent verbilligen wird. Meta Group glaubt, dass wir noch in diesem Jahr erste Web-Services-basierende Implementierungen im EAI-Umfeld erleben. Was halten Sie davon? Befinden sich Web-Services immer noch im Experimentierstadium, oder kann man heute schon damit Projekte durchführen?
Groth: Heute kann ich hier nicht von einem Hype sprechen, dafür sind Web-Services zu wenig auf dem Markt verbreitet. Es handelt sich hierbei um eine Methode, wie man Objekte zu benutzen hat. Man setzt auf Standards, um schneller ein Return On Investment (ROI) bei Projekten zu erzielen. Die Objekt-Technologie ist dadurch einfacher implementierbar und im breiteren Spektrum einsetzbar.
Grözinger: Im Geschäftskundenumfeld spüren wir bereits heute eine ziemlich realistische Erwartungshaltung in Richtung WebServices. Im Bereich Enterprise-Applikations-Integration (EAI) gibt es schon etliche Projekte, bei denen Web-Services eingesetzt werden. Viele Geschäftskunden begreifen erst jetzt, dass es nun eine gemeinsame Basis gibt, wie Information übertragen werden. Diese Anwender hoffen nun, ihre Systeme und Prozesse leichter zu integrieren und dabei auch Kosten zu sparen.
Helling: Ich glaube, dass Web-Services bereits Realität sind, dass es auch schon erste Projekte gibt - nicht nur firmeninterne, sondern auch unternehmensübergreifende. Erkenntnisse der Softwareentwickler werden neu aufgegriffen und besser zur Produktivität geführt. Applikationen werden so eingekapselt, dass auch ein Kaufmann die damit einhergehende Geschäftmöglichkeiten erkennen kann.
Konkow: Hype ist nicht die richtige Beschreibung für Web-Services. Viele Kunden sprechen zwar davon, haben aber keine Ahnung, was diese Dienste wirklich zu leisten imstande sind. Da herrscht noch viel Unsicherheit. Die Aufgabe des Systemintegrators besteht deshalb darin, in Evaluierungsprojekten oder in Präsentationen erst mal den Kunden zu vermitteln, welches Potenzial hinter Web-Services steckt.
Gebhardt: Zum Thema Web-Services gibt es viele Umfragen und genauso viele unterschiedliche Ergebnisse. Laut Forrester wollen nächstes Jahr 60 Prozent aller Kunden Web-Services intern einsetzen. Ich bezweifle das. Es ist vielmehr wichtiger, eine Abgrenzung zu klassischen EAI-Projekten zu ziehen. Entwickler haben in der Vergangenheit häufig ihre Inseln gebaut, und da ist durchaus ein Umdenken notwendig.
Gibt es denn schon tatsächlich Projekte, bei denen das Thema Web-Services eine Rolle spielt?
Groth: Bei einem börsennotierten Unternehmen integrieren wir zurzeit deren Datenbankinfrastruktur - basierend auf Web-Services. Dieses Unternehmen hat es nämlich geschafft, im Laufe seiner Geschichte beinahe 50 unterschiedliche Datenbanksysteme aufzubauen. Und in jeder dieser Datenbanken sind Infos über fast jeden Kunden gespeichert. Das Ganze harmonisieren wir nun mit Hilfe von Web-Services.
Preishuber: Ein derartiges Problem hätte man aber auch anders lösen können. Im Endeffekt sind das bloß Bauch-Entscheidungen für eine "neuere" Technologie. Meiner Ansicht nach fehlt durchaus noch das Wissen, was man eigentlich mit Web-Services wirklich anfangen kann. Hier fehlt noch die Killerapplikation, etwa ein tragbares Device für Routenplanung. Dieses könnte mich zum Beispiel über eine neu errichtete Baustelle und dazu passende Umleitung informieren, sodass ich ohne Stau ans Ziel komme.
Gebhardt: Hier müssen wir uns fragen: Was sind eigentlich Web-Services?
Konkow: Man kann es ein bisschen mit der Entwicklung von Java vergleichen, da gab es am Anfang auch keine Killerapplikation. Dennoch wurde Java implementiert, und aus einer Sprache für Cracks entwickelte sie sich zu einer Plattform für die breite Masse.
Preishuber: Also so kann man es nicht vergleichen! Ich arbeite auch heute nicht mit Java, und insofern schließt man hier mindestens die Hälfte der computerisierten Menschheit aus. Java ist eine Technologie, damit muss ich nicht arbeiten. Aber Web-Services sollten eigentlich für alle da sein.
Grözinger: Auch ich denke, dass man die Thematik Killerapplikation nicht diskutieren sollte, sondern eher die Frage nach den Einsparungspotenzialen. Wenn man mit einem Entwicklungswerkzeug schneller programmieren kann, und das ohne Einbußen an Komplexität der Applikationen, dann ist bereits eine derartige Entwicklungsumgebung die "Killerapplikation" für Geschäftskunden.
Preishuber: Dann müssten die Firmen aber erst mal investieren.
Grözinger: Das genau ist der Punkt! In Verkaufsverhandlungen mit großen Geschäftskunden tau-chen Fragen auf wie: Wo gibt es zurzeit Probleme im Business, und wie kann ich diese Schwierigkeiten lösen? Man kann hier in Richtung Portale und Smart Clients argumentieren. Fast alle Unternehmen setzen beispielsweise Office-Software ein. Wenn ich jetzt diese Applikation, die alle Nutzer schon kennen, einfach mit Web-Services so aufdrehen kann, dass alle wichtigen Business-kritischen Informationen dort integriert sind, dann muss ich die Anwender nicht mehr neu schulen, habe aber plötzlich einen ganz anderen Nutzungsgrad.
Gibt es derartige Anwendungen erst mal nur in Unternehmen?
Grözinger: Das hängt von den Sicherheitsbedürfnissen der Anwender ab. Mit "Web-Services-Security" haben wir zwar einen Sicherheitsstandard veröffentlicht, und auch Sun ist da mit eingestiegen, aber die praktische Implementierung des Standards ist noch nicht verfügbar. Um Web-Services auch über die Plattformgrenzen hinweg nutzen zu können, ist ein noch größerer technischer Aufwand erforderlich. Heute ist so etwas noch nicht ohne weiteres möglich. Aufgrund der sicherheitstechnischen Bedenken werden Web-Services daher vornehmlich nur innerhalb des Unternehmens eingesetzt.
Helling: Erst müssen Erfahrungen mit Web-Services in Unternehmen gesammelt werden, um die eigene Produktivität zu steigern. Denn die Anwendungsintegration hilft letztendlich, die Effizienz von firmeninternen Prozessen zu erhöhen. Außerdem existiert hier ein Einsparungspotenzial in der späteren Softwarewartung. Bei unternehmensübergreifenden Ansätzen ist immer die Budgetfrage zu stellen. Einen geschäftlicher Nutzen muss es schon geben. Und deshalb werden Web-Services dort eingesetzt, wo man Ähnliches ohnehin schon vorhatte.
Konkow: Ich denke ebenfalls, dass die eigentliche Entwicklung aus dem Unternehmen heraus kommen wird, weil draußen noch das Vertrauen fehlt. Bei den über irgendwelche UDDI-Registries angebotenen Diensten im Internet ist der Abrechnungsaspekt noch gar nicht geklärt. Auch zur Sicherheit der von beliebigen Institutionen bereitgestellten Services bleiben noch einige Fragen offen. Von daher glaube ich, dass in dem geschützten und vertrauenswürdigen Bereich innerhalb einer Firma Web-Services leichter zu realisieren sind.
Preishuber: Aber das sind doch keine Argumente! Firmenintern gibt es hierfür jede Menge an Technologien, die schon seit Jahren zur Verfügung stehen und die auch beherrscht werden. Da sehe ich keinen nennenswerten Kostenvorteil.
Konkow: In großen Firmen existiert typischerweise eine sehr heterogene Systemlandschaft. Das ist äußerst schwierig zu integrieren, ohne eine einheitliche Schnittstelle.
Preishuber: Wir sprechen hier alle von Unternehmen mit 10.000 und mehr Mitarbeitern. Das muss aber auch von der mittelgroßen Firmen getragen werden, denn da gibt es ja schon heute verbindliche und weit verbreitete Datenaustausch-Standards, etwa Edifact in der Automobilbranche. Erfolg wird das Ganze nur haben, wenn jeder Web-Services nutzen kann.
Konkow: Aber es lohnt sich ja schon mit einem einzigen ERP-System und einer Datenbank.
Grözinger: Das kommt auf das Business-Modell an. Auch mittelständische Dienstleister mit einer bestimmten Kernkompetenz können ihre Daten und Services im Internet zur Verfügung stellen. Unabhängige Softwareentwickler würden dann auf diese Dienste zurück- greifen. Die dafür notwendige Technologie ist da, nun müssen wir nur noch machbare Business-Modelle entwickeln, dann lassen sich damit ganz interessante Sachen machen. Wir haben beispielsweise einen Web-Service entwickelt, bei dem sich Endkunden unterwegs eine Straßenkarte auf ihr GPS-fähiges Endgerät laden können - passend zum aktuellen Standort. Hier böten sich auch Geschäftsmöglichkeiten für Service-Provider.
Groth: Der Mittelständler kämpft täglich mit der Masse an Anwendungen. Er braucht oft genau so viele Applikationen wie der Konzern, lediglich die Anforderungen an die Skalierbarkeit sind geringer. Deswegen ist die Verfügbarkeit von Software und Daten ein absolutes Top-Thema, und Web-Services in der Architektur von Microsoft und Sun zielen schon darauf hin, Kosten in der Softwareentwicklung und der Integration zu sparen. Auf der anderen Seite gilt es, die Komplexität aus dem Verhau der monolithischen Systemen herauszunehmen.
Helling: Ein Großkunde sieht eher die Kostensenkung als Anknüpfungspunkt für den Launch eines Web-Service-Projektes. Bei der Nutzung derartiger Dienste hat der Mittelständler die gleichen Chancen wie der Großkunde. Gerade im Dienstleistungsbereich werden sich neue Häuser etablieren. Auf der Basis von vorhandenen Web-Services werden diese Anbieter ihre eigenen Mehrwertdienste aufbauen, Elementar-Services von einer Bank oder der Gastronomie draufpacken und zur Verfügung stellen.
Welche Mehrwertdienste?
Helling: Zum Beispiel im Bereich Reise und Touristik. Der mobile Kunde kann sich über diesen Dienst ein Auto mieten, und der Dienstleister kümmert sich um die Verschiebung der Flüge. Und wenn entsprechende Web-Services im Netz verfügbar sind, wird es neue Serviceanbieter geben, die Geschäftspartner und Kunden intelligenter anbinden können - auf eine Art und Weise, wie es bisher mit EDI noch nicht möglich war.
Grözinger: Um ein weiteres Beispiel für Web-Services anzuführen: Unser Partner Terra Map Server hatte ein Kundenprojekt bei der Ruhrgas AG. Der Energieversorger musste alle Gasleitungen und die damit zusammenhängende Infrastruktur kartographieren. Die dortigen IT-Verantwortlichen fingen an, sich eine riesige Datenbank aufzubauen, die fütterten sie mit Informationen aus den Katasterämtern. Zu dieser Datenbank hat Terra Map Server eine Web-Services-Schnittstelle gebaut. Ein Baustellenleiter kann nun herausfinden, ob dort, wo gerade gegraben will, nicht eine Gasleitung oder ein Glasfaserkabel liegt. Ein kleines, mobiles, GPS-fähiges Gerät gibt hierzu seine genaue Position an den Web-Service weiter. Das spart Zeit und Kosten.
Helling: Wenn Informationen ohnehin neu strukturiert werden müssen, um neues Geschäft zu generieren, dann sollte man sich schon Gedanken darüber machen, wie man diese Informationen Kunden über eine standardisierte Schnittstelle zur Verfügung stellen kann.
Preishuber: Ziel muss es doch sein, die Transaktionskosten zu senken. Denn wir sitzen noch immer an der unsäglichen Mensch-Maschine-Schnittstelle, dem Web-Browser, und geben beispielsweise Bestellungen im Online-Shop ein. Heute kann noch nicht jeder Fachhändler aus seinem eigenen Warenwirtschaftssystem heraus beim Distributor bestellen. Distributoren wollen aber nicht, dass so etwas mit Web-Services automatisiert passiert, denn bei geringen Transaktionskosten könnte sich der Wiederverkäufer ein Angebot bei allen Großhändlern einholen und anschließend zum günstigsten Preis bestellen.
Gebhardt: Es gibt also den internen Ansatz, um Kosten senken, Entwicklungszeiten zu verkürzen und den Code mehrfach zu verwenden. Zum anderen stellt sich hier die Frage nach dem passenden Business-Modell. Denn erst konkrete Anwendungen bringen das Thema WebServices wirklich zum Fliegen, von mir aus auch die Anfrage: "Ich bin hier, kann ich hier baggern?". Ich bin der Meinung, dass Web-Services zuerst intern zum Zuge kommen. Neuentwicklungen werden dann vereinheitlicht und damit auch zukunftsträchtig sein. Insellösungen wird es nicht mehr geben.
Groth: Es wird auf jeden Fall diese zwei Sichtweisen geben, nämlich auf interne und externe Optimierung, wobei Letztere die interessantere Option darstellt. Denn sie kann einen Hype erzeugen, der sich intern in die Firmen ausbreitet. Problematisch dabei ist aber, dass das ein Stufenmodell ist. Heutige Web-Services eignen sich hervorragend für Integrationsaufgaben, sind aber für Content-sensitive Dienstleistungen unbrauchbar. Deshalb haben wir so genannte Smart-Web-Services definiert, die eine Stufe oberhalb der heutigen Web-Services anzusiedeln sind. Diese im Internet angebotenen Dienste wissen, wer ich bin, in welcher aktuellen Situation ich mich befinde und welche Aufgaben ich zu erfüllen habe.
Konkow: Da Web-Services gerade im Entstehen sind, geht es erst um Kommunikation. Hierfür gibt es erste Schnittstellen und standardisierte Protokolle. Noch nutzen wir aber gar nicht die eigentlich in Web-Services vorgesehenen Registrierungsfunktionalitäten, also: Wer bietet welchen Service wo an? Dazu kommt es erst im zweiten Schritt, dann wird es auch die angesprochenen Smart-Web-Services geben.
Also befinden wir uns jetzt in der ersten Phase, in der das Ganze nur intern ausprobiert wird? Ist an Anwendungen von externen Geschäftspartnern noch gar nicht zu denken? Und wann könnte es denn so weit sein?
Groth: In der Wertschöpfungskette funktioniert die Sache schon: Als Einkäufer kann ich meine Lieferanten dazu auffordern, sich an einem bestimmten System zu beteiligen.
Am E-Procurement? Aber dazu brauche ich doch keine Web-Services!
Groth: Ja, vielleicht. Aber man könnte doch das Ganze für alle Zulieferertypen generalisieren, dann müsste man nicht für jeden Einzelnen etwas Spezielles aufsetzen.
Konkow: Genau so eine Schnittstelle haben wir bereits gebaut! Eine Instanz verwaltet alle Bestellungen, die Lieferanten nutzen weiterhin ihr ERP-System, können aber über eine Web-Service-Schnittstelle ihre Orders abgleichen. Die bisherige Kommunikation über Fax, E-Mail und Telefon entfällt.
Groth: Das ist ein ganz gutes Beispiel: Ein Distributor bedient unterschiedliche Händler, und diese wiederum haben verschiedene Lieferanten. Wenn man hier nun eine komplette Edifact-Struktur aufbauen würde, käme man sofort in Erklärungsnöte der Art: Wie belege ich welches Feld, wie sieht die Syntax aus, wie nimmt man Konvertierungen vor? Web-Services können sofort alle nutzen, da gibt es keine Diskussionen über das Wie.
Grözinger: Gerade diskutieren wir über Web-Services auf der Prozess- und Anwendungsebene, also: Wie binde ich Zulieferer ein? und Ähnliches. Da hat Herr Wiltscheck sicherlich Recht, das kann man auch mit anderen Technologien realisieren. Derzeit dreht sich die Web-Services-Diskussion noch um die Softwaretechnologie selbst, nach dem Motto: Wie kann ich Anwendungen bauen? Bei dieser Fragestellung rede ich aber nicht unbedingt mit dem Einkäufer darüber, wie er Zulieferer einbinden kann, sondern erkläre dem Softwareentwickler, dass er weniger Werkzeuge und Server braucht und schneller Applikationen entwickeln kann, wenn er die Web-Services-Schnittstelle seines Kunden nutzt.
Preishuber: Ganz so einfach ist es auch wieder nicht. Da gibt es ja noch immer die Drittsoftware, wie Warenwirtschaft, die der Web-Service auch verdauen muss.
Grözinger: Aber genau das ist ja das Interessante an dem Ganzen. Wenn nun alle Produkte auf den gleichen Standards beruhen, gibt es für Anbieter wie Sun, IBM oder Microsoft wenig Differenzierungspotenzial. Mit XML, Soap und weiteren Standards der Web-Services-Initiative existiert nun ein gemeinsamer Nenner. Differenzieren kann man sich nur mit den Werkzeugen drum herum, etwa ob die Dotnet- oder Sun-One-Plattform einen Konnektor zu BS2000 oder SAP liefert. Erst hier kommen die wirklichen Vorteile von Web-Services zur Geltung, und deswegen sollten wir diese Technologie einsetzen.
Groth: Derartige Differenzierungsmerkmale sind doch rein philosophisch! Ein Web-Service sollte auf jeder Plattform laufen, unabhängig davon, wo er entwickelt wurde.
Es spielt also keine Rolle, ob ich meine Web-Services mit Visual Studio Dotnet oder mit Java-Werkzeugen entwickle?
Groth: Heute spielt es noch eine Rolle, weil die Entwicklung auf die Arbeitsplattform abgestimmt ist. Man entwickelt entweder mit Java oder mit Visual Studio und legt sich damit schon fest.
Konkow: Ich würde das nicht unbedingt an irgendwelchen Ent-wicklungswerkzeugen festmachen. Wichtiger ist doch, dass man Legacy-Systeme über eine Schnittstelle allen zur Verfügung stellen kann. Die genannten Entwicklungswerkzeuge kann man ohnehin nicht auf den Mainframes einsetzen.
Preishuber: Wenn heute ein Softwareentwickler mit Visual Studio in 45 Sekunden einen Web-Service erstellen und einbinden kann, dann ist er schon begeistert.
Konkow: Das habe ich auch nicht gesagt! Aber ob man mit Visual Studio so einfach eine Cobol-Anwendung auf dem Host anzapfen kann?
Preishuber: Gläubige Microsoft-Entwickler vertreten da eine etwas andere Philosophie. Sie erhalten vom Kunden den Auftrag, ein Problem zu lösen. Dem Kunden ist es prinzipiell egal, wo diese Anwendung läuft. Er hat zufällig einen Windows-Sever, und deswegen soll die Applikation dort installiert werden. In drei Jahren mag er sich eine Linux-Maschine anschaffen, dann wird er eben etwas Neues entwickeln lassen. "Die Anwendung läuft überall" ist insofern kein starkes Argument.
Helling: Für Web-Services muss man vieles nicht neu erschaffen, und für Dotnet spricht die Sprachunabhängigkeit. Damit kann man auch Legacy-Anwendungen ansprechen, hier ergeben sich deutliche Vorteile durch Produktivitätssteigerung in Integrationsprojekten.
Grözinger: Der These: "Entwicklungswerkzeuge sind weniger wichtig" kann ich nicht zustimmen. Effizienz und Produktivität von Softwareentwicklern ist ein kritischer Punkt. Je intelligenter eine Entwicklungsumgebung ist und je mehr Arbeit sie dem Entwickler abnimmt, umso schneller sind Softwareprojekte über die Bühne gebracht. Das bringt sofort Geld.
Konkow: Ich habe nicht gesagt, Entwicklungsumgebungen sind unwichtig, sondern nur versucht klarzustellen, dass Web-Services nicht an der Entwicklungsumgebung festgemacht werden dürfen. Wichtiger ist doch das Konzept - ob man dafür Sun One oder Microsoft Dotnet verwendet, ist nebensächlich.
Groth: Die These von den gläubigen Microsoft-Entwicklern und ihrer Leistungsfähigkeit ist eindeutig vom Auftraggeber abhängig. Sicherlich kann man innerhalb kürzester Zeit eine Lösung bauen, um ein Problem zu lösen. Aber wenn der Auftraggeber den Entwickler anruft, um ein weiteres Problem zu lösen, dann brechen die Interessenkonflikte erst richtig aus.
Alle möglichen Anwendungen würden also im Netz zur Verfügung stehen, und ich könnte die einfach mieten? Oder wie soll so etwas funktionieren?
Groth: Es wäre sicherlich ein möglicher Ansatz, Software der Community zur Verfügung zu stellen. Wenn alle auf den offenen und transparenten Code zugreifen können, dann fangen sie nicht dauernd an, die Räder neu zu erfinden, sondern können sie weiterentwickeln.
Das passt aber gar nicht in Microsofts Lizenzmodell ...
Grözinger: Lizenzmodelle sind flexibel. Für einen heute verfügbaren Windows-basierenden Applikationsserver existiert bereits ein entsprechendes Konstrukt. Auch Service Provider setzen entsprechende Lizenzmodelle ein. Ob Web-Services sich wirtschaftlich lohnen, hängt davon ab, wie öffentlich sie im Netz verfügbar sind. Wir haben Lizenzmodelle, bei denen Nutzer sich eintragen, einloggen, und dann können sie unsere Services heute schon nutzen.
Groth: Da sind wir uns 100-prozentig einig: Wenn das Thema Sicherheit geklärt ist, dann muss man nicht mehr befürchten, sich ein faules Ei ins Nest zu legen und wirtschaftlichen Schaden zu erleiden. Denn der Name desjenigen, der so etwas verbricht, steht dann im Zertifikat.
Helling: Ich sehe den Faktor Entwicklungsumgebung weniger in der Beschleunigung des klassischen Entwicklungszyklus als in der Effizienzsteigerung, wenn vorhandene Komponenten lediglich eingebunden werden müssen. Das funktioniert, sobald die Schnittstellen leicht zu erkennen und auszuwerten sind. Und die Komponenten müssen natürlich bei der Lösung des Problems helfen.
Gebhardt: Genau für solche Komponenten interessieren sich die Unternehmen. Wir bauen nur die IT-Plattform dafür auf. Web-Services bilden im ersten Schritt eine Brücke zwischen der Java und der Windows-Welt, sodass der Kunde seine Komponenten unabhängig von der Plattform darunter einsetzen kann. Das ist der eigentliche Mehrwert der Web-Services.
Werden Web-Services nur dort zum Einsatz kommen, wo plattformübergreifende Verbindungen nötig sind, also bei größeren Kunden und nicht bei den typischen Mittelständlern, die doch ohnehin nur auf Windows setzen?
Gebhardt: Nein, weil auch dieser Kunde intern einen Nutzen aus Web-Services zieht. Er fängt intern an, bevor später das Business-Modell unternehmensübergreifend zum Zuge kommt. Wenn dieser Kunde nur Microsoft-Technologien einsetzt, dann entwickelt er mit Dotnet. Ein anderes Unternehmen setzt hingegen auf Java. Wenn nun diese zwei Firmen eine Geschäftsverbindung aufbauen wollen, dann können sie das trotzdem tun.
Groth: Der Mittelständler muss mit vielen Unternehmen kommunizieren, die nicht Mittelständler sind, also etwa mit einer Bank, mit seinen Lieferanten und Kunden. Wenn er mit ihnen kommunizieren möchte - was bisher nur schlecht funktionier -, sollte er auf Web-Services setzen.
Also muss der Mittelständler in Web-Services investieren, wenn er den Kontakt zu seinen Geschäftspartnern intensivieren möchte? Lohnt es sich nur in diesem Fall? Denn momentan werden doch einfach nur Anwendungen programmiert, die man auch ohne Web-Services realisieren könnte.
Groth: Was die Road-Map betrifft, ist es tatsächlich so. Die Leistungsfähigkeit von Web-Services wird heute noch gar nicht voll ausgenutzt. Die verfügbaren Dienste sind meist in einem einzigen Verzeichnis aufgeführt, um etwa Integrationsaufgaben zu lösen. Im zweiten Schritt wird die Verzeichnisvielfalt steigen. Bei der nächsten Stufe geht es dann nach draußen, und erst danach werden die schon von mir angesprochenen Smart-Web-Services implementiert.
In welchen Zeithorizont?
Groth: Erste Spezifikationen, um Identität der Nutzer im Netzwerk festzuhalten, sind bereits verabschiedet. Innovative Anbieter fangen schon an, Smart-Web-Services zu bauen. In zwei Jahren werden sie verfügbar und in fünf Jahren selbstverständlich sein.
Grözinger: Unsere Web-Services können Sie schon heute nutzen, und das in einer ansprechenden Vielfalt.
Groth: Wir haben da nur ein kleines Problem, das heißt Passport.
Grözinger: Dass die verschiede-nen Authentifizierungsmechanismen sich gegenseitig identifizieren werden, ist nur eine Frage der Zeit. Dann wird auch Passport mit einer Standardschnittstelle verfügbar sein. Es ist doch für den Kunden bequem, wenn er sich über eine öffentliche Identifizierungsinstanz einloggen kann.
Groth: Aber genau das ist hierbei das zentrale Problem! Ich habe nur eine zentrale Identität und kann keine unterschiedlichen Rollen einnehmen, etwa als Sun-Mitarbeiter, als Clubmitglied oder als Privatperson.
Helling: Das eine ist doch die Authentifizierung, das andere das Erkennen in einer geschäftlichen Transaktion. Hier kommt es auf das CRM-System des Transaktionsabwicklers an. Dieser legt die Kundenbeziehung fest und muss sie während der Geschäftstransaktion korrekt zuordnen.
Groth: Aber die Liberty-Allianz ist genau dazu gegründet worden, damit der Kunde einer Bank, oder einer Fluggesellschaft genau dort landet, wenn er sich ins Netz einloggt. Wenn er noch woanders hin will, dann soll er das von dieser Startseite aus tun. Es geht hier um eine dezentrale Steuerung der Zugangsberechtigungen. Passport ist ein zentrales Angebot der Firma Microsoft, um Zugriff auf unterschiedliche Dienstleistungen zu erhalten. Der Anwender muss sich grundsätzlich erst mal bei Microsoft anmelden. Dieses Modell haben diese Anbieter aber nicht akzeptiert und eine dezentrale Struktur verlangt.
Grözinger: Es wird noch viel mehr unterschiedliche Authentifizierungssysteme geben. Dann wird der Kunde schon irgendwo seinen Schlüssel hinterlassen, um sich zu authentifizieren. Ob das dann Liberty, Passport oder was anderes sein wird, ist letztendlich egal. Wichtig ist, dass sich die unterschiedlichen Authentifizierungssysteme gegenseitig anerkennen.
Groth: Wenn die einzelnen Authentifizierungsservices miteinander reden, dann unterstütze ich das.
Grözinger: Genau das ist das Inhalt der Standardisierungsbemühungen innerhalb der Web-Services-Security-Initiative. Da geht es um eine Erweiterung, die diese Authentifizierungsprozesse identifiziert, damit sich unterschiedliche Systeme gegenseitig trauen. Jetzt gilt es, diesen Standard umzusetzen.
Groth: Das unterstützen wir auch. Es wäre doch schön, wenn der gestresste deutsche Manager auf der Autobahn, linke Spur, 250 Stundenkilometer, sofort all seine Web-Services frei schalten könnte. Denn er braucht zuerst eine Wegbeschreibung, dann seine Termine, und vielleicht sucht er noch ein Restaurant. Wenn er überall ein Passwort eingeben muss, wird er Web-Services nicht akzeptieren. Er braucht eine eindeutige Netzwerkidentität.
Angenommen, das Sicherheitsproblem wäre gelöst und jeder einzelne Anwender könnte sich über ein einziges System im Netz anmelden, um Web-Services zu nutzen. Wie würde er dann für derartige Dienste bezahlen?
Grözinger: Das hat jeder Dienstleistungsanbieter für sich selbst zu lösen. Er muss ein eigenes Billingsystem aufbauen und einen Vertrag mit dem Kunden abschließen. Der wird etwa für eine Monatspauschale bestimmte Dienste nutzen können. Später wird sich die Bezahlung nach der Nutzungsintensität von Web-Services richten.
Preishuber: Das Bezahlproblem ist erstens absolut wichtig und zweitens noch immer ungelöst. Nach wie vor werden nur sehr wenige Geschäfte tatsächlich komplett elektronisch abgewickelt - inklusive Bezahlung. Da Kreditkartenunternehmen bei Internetgeschäften im Zweifel haften müssen, kündigen sie ihre Verträge mit ShopAnbietern. Viele Banken haben erfolglos versucht, proprietäre Payment-Systeme zu entwickeln. Technisch ist Billing noch nicht gelöst, und an der Akzeptanz fehlt es auch.
Grözinger: ... aber dann ist es kein spezielles Web-Services-Problem, sondern ein allgemeines, das man mit herkömmlichen Softwaretechnologien lösen könnte. Web-Services sind erst mal nur dazu da, Software schneller, einfacher und sicherer zu schreiben. Probleme in den daraus hervorgehenden Geschäftsprozessen können immer noch später gelöst werden.
Gibt es denn noch keine Standardisierungsbemühungen, Billing in Web-Services mit einzubeziehen?
Grözinger: Transaktionen sollen schon abgebildet werden, also: Wie vermittelt man Web-Services, dass hinter einem Aufruf eine Transaktion steckt? Das ist noch als Standard zu implementieren. Dann ist der Bezahlvorgang auch über Web-Services gesichert.
Helling: Der Anbieter muss aber nachweisen, dass er den Service tatsächlich erbracht und der Rechnungsempfänger diesen Service wirklich in Anspruch genommen hat. Hier wiederum ist der Gesetzgeber gefordert, er muss die Rahmenbedingungen diktieren, wie ein derartiger Nachweis zu führen ist. Momentan geht die schlechte Zahlungsmoral mit den technischen Lücken in der Nachweisbarkeit einer elektronischen Transaktion einher, sodass bestimmte Dienste kostenlos in Anspruch genommen werden.
Wann wird man denn Web-Services tatsächlich gegen Bezahlung anfordern können?
Helling: In den nächsten zwei, drei Jahren.
Gebhardt: Dem stimme ich zu. Ohne Lösung des Bezahlproblems wird es keinen Fortschritt bei Geschäften im Internet geben.
Groth: Es gibt heute schon Geschäftsmodelle, bei denen Kunden bereit sind, für Dienstleistungen zu bezahlen, etwa beim Mobiltelefonieren. Die akzeptieren es, weil der Bezahlvorgang unmittelbar mit der Nutzung verbunden ist. Wenn man dieses Modell auf die Web-Service-Welt projiziert, findet man sicherlich auch eine Lösung.
Helling: Mit der Zeit nehmen die Vorbehalte ab. Heute gibt man seine Kreditkarte im Restaurant ab und weiß nicht, was der Kellner damit macht. Im Internet ist zu beobachten: Die Hemmungen bezüglich Sicherheit verschwinden, es ist ein Gewöhnungseffekt.
Wird also in drei oder vier Jahren jeder kostenpflichtige Web-Services nutzen können?
Preishuber: Über den Zeitkorridor bin ich mir im Unklaren. Allerdings sehe ich Web-Services als den logischen Endpunkt der Informatikentwicklung. Danach kommt eigentlich nichts mehr. Wenn wir das realisiert haben, was Web-Services uns heute versprechen, dann haben wir alle Probleme gelöst und sind alle arbeitslos. Soweit wird es aber nicht kommen: Wir bekommen zwar Web-Services, müssen aber weiterhin arbeiten, weil es keinen echten Standard geben wird.
Helling: Wirtschaftlich werden sich Web-Services in den nächsten drei bis vier Jahren durchsetzen. Ein "Next Generation Internet" mit neuen Business-Modellen entsteht bereits. Wir werden dann nicht mehr über eine Web-Services-Plattform sprechen. In der Softwareentwicklung wird uns dieser Standard noch recht lange begleiten. Da gibt ist noch jede Menge an Legacy-Anwendungen, die seit 20 Jahren ihr Werk verrichten. Diese Applikationen müssen endlich modernisiert werden.
Grözinger: In drei bis vier Jahren werden sich Web-Services als Technologie immens weiter entwickelt haben. Bis dahin werden wir sicherlich noch das eine oder andere Problem lösen müssen. Danach wird Standardisierung kein Thema mehr sein, und Web-Services werden ihre Praxistauglichkeit unter Beweis gestellt haben. Hauptsächlich große Geschäftskunden werden sie intensiv einsetzen. Zu diesem Zeitpunkt werden auch schon erste Anbieter von öffentlichen Web-Services für die breite Masse auf den Markt treten.
Groth: Ich sehe insgesamt drei Internetwellen auf uns zukommen. Die erste Welle ist das Internet der PC-Systeme, wie wir es heute erleben. Die zweite Welle ist das Internet der Dinge, die einen Computer beinhalten. Da befinden wir uns gerade am Anfang, es geht hier um PDAs oder Maschinen, die aus der Ferne gesteuert werden. Die dritte Welle wird ein Internet der Geräte ohne eigene Computer sein. Entlang dieses Zeitstrahles gibt es insgesamt fünf Funktionstypen: Erstens das klassische Informations-Internet, wie wir es aus seiner Anfangsstruktur her kennen. Als Zweites kam das Transaktionsmodell ins Internet hinein, als das erste Mal Geld im Netz bewegt worden ist. Zurzeit konzentrieren wir uns aufs Content-Management. Das dahinter stehende Modell basiert auf Web-Services. Als nächste Funktion werden wir die Telematik erleben, also die Fernsteuerung von Endgeräten. Der Bosch-Kühlschrank aus dem Erdgeschoss wird mit dem aus dem Obergeschoss kommunizieren. Die fünfte und letzte Funktion heißt "Control", da geht es um sensorische und biometrische Komponenten, die alle IP-fähig sein werden. Diese drahtlos erreichbaren Geräten werden einem fast ständig und überall zur Verfügung stehen.
Wann werden wir das erleben?
Groth: Mit dem "Control"-Internet rechne ich in zirka zehn bis 15 Jahren. Die dahinter steckenden Architekturmodelle werden biologische Strukturen aufweisen, sich also an der DNS und an evolutionären Mustern orientieren. Es werden Systeme sein, die sich selbstständig weiterentwickeln und selbst für ihre eigenen Nachkommen sorgen. Web-Services bilden noch lange nicht das Ende der IT-Evolution.
Konkow: Bei Web-Services sind momentan noch so viele Baustellen offen - die ungenügende Sicherheit, das ungelöste Bezahlungsproblem -, dass erst die Akzeptanz beim Kunden wachsen muss. Hierfür müssten wir in den nächsten zwei bis drei Jahren verbindliche Standards verabschieden. Deswegen glaube ich nicht, dass es in zwei bis drei Jahren bereits die großen Applikationen auf dem Markt geben wird. Sie werden zu dem Zeitpunkt erst so richtig im Entstehen begriffen sein.
Gebhardt: In zwei bis drei Jahren sind Web-Services Commodity. Sie werden zwar nicht final definiert, aber breit etabliert sein. Heute bilden Web-Services lediglich einen Infrastruktur-Baustein. Viele Legacy-Systeme werden in diese neue Welt übergeführt. Web-Services werden weniger zu Integrationsaufgaben herangezogen, sondern eher zur Bereinigung der IT-Infrastruktur. In zwei bis drei Jahren wird es funktionierende Smart-Web-Services auf einer Dotnet-Technologie geben. Die wahre Herausforderung wird darin bestehen, welche Dienste als Web-Services laufen werden, da kommt es auf den Nutzwert an.
Roundtable Web-Services
Die Teilnehmer
Thomas Gebhardt, Manager E-So