Praxisbericht: „Web Services vermehren sich wie Karnickel“

Web Services sorgen zeitweise eher für Negativ-Schlagzeilen. Reihenweise lassen Analysten die Vision von standardisierten Komponenten sterben, die sich nahtlos, per Web und auf Abruf zu Anwendungen zusammenfügen. Von Sicherheitslücken und fehlenden Lösungen ist die Rede. Doch die Anwender sind durchaus angetan, sehen Potenzial und gehen die Probleme an.

„Web Services haben die Tendenz, sich wie Karnickel zu vermehren“, beschrieb Mario Jeckle, Projektleiter Web Services aus der Ulmer Forschungs- und Entwicklungsabteilung von Daimler Chrysler eine seiner Schwierigkeiten verschmitzt. Jeckle und sein Team haben für den Automobilkonzern einen Prototyp für den Zugriff und die Verwaltung von Sachnummern gebaut. Eine solche Anwendung sei für eine Erprobung von Web Services ideal, weil nahezu alle Konzernbereiche sowie alle Zulieferer sich über die eindeutigen Teilenummern verständigen. Somit haben das Sachnummern-Recherchemodul und das Stücklistensystem unglaublich viele Schnittstellen. Bis jetzt fehlen jedoch vor allem für die Kommunikation mit kleineren Zulieferern „leichtgewichtige, plattformunabhängige Clients“.

Die neue Web Service-Applikation könnte das ändern. Statt vieler Schnittstellen programmierte das Jeckle-Team nur eine und probierte den Service auf .Net- und Java-Plattformen aus. Sogar mobile Clients bezogen sie in den Test ein, um etwa dem Meister vor Ort, den Zugang per Handheld zu ermöglichen. „Die Plattformunabhängigkeit funktioniert tatsächlich“, zeigte sich Jeckle begeistert.

Dass es dennoch kein konzernweites Roll-out gibt, liegt daran, dass sich Daimler Chrysler noch an einer weit reichenden Strategie für den Einsatz Web Services arbeitet. Zahlreiche Fragen sind offen. Zum Beispiel fehlen Erfahrungen damit, wie sich Web Services unter Belastung verhalten. Zwar habe die Forschungsabteilung bei Daimler Chrysler bereits Versuche angestellt, die positiv stimmten, doch der letzte Beweis für Robustheit und Skalierbarkeit fehle, so Jeckle.

In punkto Sicherheit sind nach Ansicht des Forschers genügend Spezifikationen da, doch mangele es an der konsequenten Umsetzung bei den Softwareherstellern. Die Standards seinen nicht oder nur unvollständig implementiert.

Eine weitere Schwäche besteht laut Jeckle darin, Web Services eindeutig zu kategorisieren. Trotz öffentlicher UDDI-Verzeichnisse (UDDI = Universal Description, Discovery and Integration) gibt es kein eindeutiges Raster, das die Web Services klassifizieren könnte In den gelben Seiten, die häufig zum Vergleich mit UDDI-Registries herangezogen werden, stehen Bäcker unter Bäcker und nicht unter Konditoren. Einige Firmen behelfen sich bei der Verwahrung der Web Services mit intern geltenden Schemata. Das jedoch widerspricht dem Standard-Gedanken. Inwieweit Web Services somit tatsächlich den Aufwand für die Entwicklung und Pflege von Schnittstellen verringern, muss sich erst noch zeigen, so Jeckle.

Dass Web Services im Einzelfall jedoch eine preiswerte und praktikable Alternative zu traditioneller Programmierung und Architektur sein können, beweist ein Projekt bei dem Importeur für Pflanzen und Tonware Irßlinger GmbH, Meßkirch-Igelswies. Es ging um die Einbindung eines Online-Shopsystems in das proprietäre Warenwirtschaftssystem.

Der Großhändler bildet heute die Bestellprozesse direkt im Internet ab. Dazu gehören etwa der Zugang zu kundenindividuellen Vereinbarungen und Katalogen sowie die Angebotszusammenstellung mit Preisen und Frachtberechnung.

Zunächst aber hatte es ausgesehen, als wäre das mit dem mittlerweile über zehn Jahre alte Legacy-System nicht zu schaffen. Ein neues sollte her, erzählte Frank Sauer, Leiter des Irßlinger-Projekts von der Darmstädter Software AG, die hier mit Data Access Worldwide aus den Niederlanden zusammengearbeitet hat. Die Implementation hätte rund zwei Jahren gedauert. Die heutige Lösung konnte in nur drei Monaten aufgezogen werden. Den Aufwand schätzt Sauer auf 120 Manntage.

Weil die Kunden in der Regel kein System haben, das aus Web Services basiert, haben die Darmstädter einen HTML-Client gebaut. Aber intern packt eine Kommunikationsschicht die Anfrage in das Datenaustauschformat XML und ruft über das Simple Object Access Protocol (SOAP) ein Modul aus dem WWS-System auf: zur Preisermittlung, Abfrage von Lagerbeständen und getätigten Bestellungen. Auch die Antwort erfolgt per Web Service. Allein die Stammdaten befinden sich aus Performance-Gründen in einem Daten-Cache, der zirka einmal pro Stunde über ein XML-File aktualisiert wird.

Der Kundenkreis, der die Online-Bestellung nutzt, besteht aus 20 bis 30 Unternehmen. Manche loggen sich morgens ein und füllen über den Tag verteilt immer einmal wieder ihren Warenkorb auf, um abends ihre Bestellung aufzugeben. Dadurch ist die Session immer wieder unterbrochen. Die Software AG ermöglichte Irßlinger deshalb, die Daten persistent zu speichern. Andere bevorzugen ein verkürztes Bestellverfahren.

Bricht jedoch eine Transaktion ab, muss der Kunde von vorne beginnen. Ein weiterer Sicherungsmechanismus habe sich bei der Anzahl der Kunden und Bestellungen nicht gelohnt, erläutert Sauer.

Mehr Aufwand muss Uwe Spiegel in die Web Service-Abwicklung der Portale T-Motion und T-Info stecken. Er arbeitet als Leiter des Bereichs Authorized Java Center der T-Systems Multimedia Solutions GmbH, Dresden.

Die Web Services erlauben beispielsweise Dienste von Drittanbietern für den Surfer transparent in die Auskunfts- und Informationsportale einzubinden. Nach Auskunft von Spiegel wird bei einem Wechsel zu einem Drittanbieter über die Web Service-Schnittstelle die User-Session anonymisiert übergeben. Bei einem Rücksprung in das Portal findet sich der Nutzer an der Stelle wieder, von der er gestartet ist, die Session-Informationen gehen also mit zurück. Der Nutzer kann deshalb ohne einen Bruch in der Navigation weitersurfen. Informationen nicht mehrfach manuell einzugeben, erübrigt sich.

Herkömmliche Verfahren anstelle von Web Services taugen laut Spiegel nicht: „Schließlich ist die Systemumgebungen der Geschäftspartner nicht zwingend identisch mit denen von T-Info und T-Motion“, sagte er. „Man braucht aber einheitliche Schnittstellen.“

Zudem funktionierten die Tools und Integrations-Komponenten für ein Gros der Anwendungsfälle schon erstaunlich gut. So lasse sich beispielsweise aus der technischen Beschreibung der Schnittstelle mit Hilfe der Web Service Description Language (WDSL) zumeist ohne weiteren einen Client-Proxy generieren. Das vereinfache das Programmieren erheblich.

Allerdings gibt es in Details der Implementierung immer noch Probleme. „In einem unserer letzten Projekte hatten wir es der Übertragung von verschlüsselten Datensätzen zu tun“, berichtet er. „Hier war eine manuelle Implementierung der gesamten SOAP-Kommunikation auf Grund von Problemen mit dem SOAP-Service Provider notwendig.“

Positiv wertet Spiegel die Möglichkeit, Web Services „über .http zu tunneln“. Denn auf diese Weise lassen sich die Dienste über den für Web-Sites offenen Port 80 durch Firewalls schleusen – mit anderen Worten: Die Kommunikation zwischen Plattformen hinter Firewalls vereinfacht sich.

Genau das beschreibt Frank Daske, Projektleiter bei Portamundi, Nürnberg, als offenes Problem. Die Firma nutzt Web Services in Kundenprojekten sowie für das Kernsystem seines Produkts „Content XXL“, ein Content-Management System für den Mittelstand. Mit Hilfe von Rich Site Summary (RSS) organisiert Portamundi zum Beispiel das Zusammenfassen von Site-Inhalten, um mit dem Content Nachrichten zu füllen. Web Services werden aber auch für multimediale Microsites, etwa in Flash-Auftritten, benutzt. Die Datenhaltung kann völlig getrennt davon etwa in einem betriebswirtschaftlichen System erfolgen.

Normalerweise steht Port 80 für das Lesen von .http-Sites offen, erläutert Daske. Web Services offerieren aber nicht nur einen lesenden, sondern auch schreibenden Zugriff. Dieses Risiko muss dann intern abgefangen werden. Dafür gibt es laut Daske jedoch noch keine ultima ratio. Der Austausch von zertifizierten Web Services etwa ist in vielen Fällen zu aufwendig und setzt voraus, dass sich diejenigen kennen, die sich gegenseitig mit Web Services versorgen.

Daske wünscht sich zudem eine neue Produktkategorie – eine Art Repository, das die Regeln zur Verwendung von Web Services verwaltet und als zentrale Drehscheibe für die Dienste fungiert. Zum Beispiel würden diese Regeln Events abfangen: Was passiert, wenn statt einer Bestellung 100 oder 1000 auf einmal eingehen? Welche Maßnahmen werden eingeleitet, wenn ein Web Service ausfällt? Wo ist Ersatz?

Beim Swiss Interbank Clearing und Payserve Card Service fallen die Web Services nicht aus. Erstellt hat sie das Züricher Unternehmen Otego für zwei Finanzanwendungen und zwar mit Open-Source-Mitteln. Im ersten Fall nutzen mittlerweile 74 Banken die neue zentrale Clearing-Anwendung der Schweiz. Kunde im zweiten Fall ist das Schweizer Verarbeitungscenter für Kredit-, Debit- und Wertkarten. Gegenstand des Projekts ist die Schnittstelle zum Sperren von Debitkarten. Die implementierten Web Services haben für die Institute und Banken teure EDI-Verfahren abgelöst.

Das Beratungs- und Marktforschungsunternehmen Gartner Group hat die Clearing-Lösung genauer untersucht. Obwohl das Projekt bereits im Jahr 2000 initiiert wurde, haben die Analysten errechnet, dass sich ein Return on Investment innerhalb von 24 Monaten einstellt. Sie bestätigen zudem, dass das System seit der ersten Inbetriebnahme im April 2001 mit fünf Pilotanwendern voll funktionsfähig gearbeitet habe. Otego-Geschäftsführer Massimo Sonego betont zudem, dass es sich bei den Anwendungen um zeitkritische Abläufe handle.

Im Jahr 2006, prognostizieren die Gartner-Experten, wird mehr als 60 Prozent der weltweiten Zahlungsverkehrs unter den Finanzhäusern auf Web Services basieren. Geht es nach Michael Stal, Senior Principal Engineer bei der Siemens AG, Bereich Corporate Technology, funktionieren noch ganz andere Bereiche mit Web Services. Aktuell arbeitet er daran, Kleinstgeräte in der Fertigung, Sensoren und Aktoren per Web-Service mit Steuereinheiten kommunizieren zu lassen. Das ist das Ende klassischer, teurer Leitstände in der Automation. Aber auch an der Verbindung bisher getrennter Unternehmensbereiche, etwa von Produktion und betriebswirtschaftlichen Systemen arbeitet der Spezialist.

Wie für alle Anwender haben Web Services einen evolutionären Charakter. Mit einer Anwendung – keiner kritischen aber möglichst schnittstellenreichen- lässt sich anfangen. Der erste Schritt besteht darin, Funktionen als Service anzubieten. Erst der nächste große Sprung besteht darin, diese Services zu kompletten Workflow-Anwendungen zusammenzubinden.