Zudem benötigen Web-Services laut Stal weitere "Zutaten" als da wäre eine plattformunabhängige Laufzeitumgebung (Virtual Machine), um Informationen und Dienste wirklich für jeden Client von jedem Ort aus verfügbar zu machen. Weiter sollten sich neue Dienste aus bestehenden Komponenten erstellen lassen und sowohl Code als auch Dateninteroperabilität bieten. Web-Server sollten als Gateway für Web-Seiten und Dienste gleichermaßen fungieren können.

Außerdem, so Stal, müssten Web-Services auch Kontextinformationen verwenden, austauschen und sich durch sie anpassen und steuern lassen. Dies könnten zum Beispiel Informationen über Ort, Transaktionen und den Aufrufer des Dienstes sein. Höherwertige Dienste wie die umstrittenen ".NET Myservices" sind schließlich ebenso sinnvoll wie Workflow-Engines für Web-Services sowie Konnektoren und Middleware wie J2EE, Corba oder COM+ für die Einbindung von Legacy-Code. Web-Services machen daher heutige Middleware nicht obsolet, sondern vielmehr immer wichtiger.

Allerdings ist der breite Einsatz von Web-Services in der Praxis noch selten. So gaben von den rund 200 Zuhörern des Vortrags lediglich einige wenige an, solche Dienste schon einmal benutzt zu haben. Und auch eine großangekündigte Herstellerpräsentation einer Web-Services-basierenden Auftragsabwicklung über mehrere Systeme verschiedener Anbieter gelang zumindest am ersten Messetag nur zum Teil und zeigte eher die Probleme mit den neuen Standards.

Zu den Pionieren gehört daher die Hypo-Vereinsbank (HVB). In seinem Vortrag berichtete Projektleiter Markus Wagner von seinen Erfahrungen bei der Erstellung eines Präsentations-Frameworks für Web-Anwendungen. Seiner Ansicht nach bringe der Einsatz von XML, insbesondere in Verbindung mit Soap, deutliche Vorteile bei der Kommunikation, da sich Anwendungen zum Beispiel entkoppeln ließen. Die Perfomance und der Entwicklungsaufwand lassen sich dabei verringern, in dem Komprimierungsverfahren - in diesem Fall "Wap Binary XML" (Wbxml) - die Netzlast reduzieren und beim Parsen und Erzeugen von XML-Schnittstellen eine durchgängige XML-Implementierung verwendet wird.

Schwächen in Soap

Dem Team fielen aber um Wagner auch Schwachpunkte an Soap auf: So ist es weder möglich, Aufrufe während einer Transaktion zu starten, noch mehr als einen Aufruf gleichzeitig zu machen. Ferner konnten nur "einfache" Datentypen übertragen werden, das heisst, wenn eine Methode ein Objekt schickt oder erwartet, muss dieses erst in XML erzeugt beziehungsweise serialisiert werden.