Praxisbericht: „Web Services vermehren sich wie Karnickel“

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.