SOA-Risiken werden gern verschwiegen

24.08.2005
Von Stefan Grasmann

Doch auch die auf den ersten Blick trivial erscheinende Client-Seite eines Web-Service hält ausreichend Komplexität parat: Serviceaufrufe erfolgen im Normalfall über mehr oder weniger zuverlässige Netzwerke mit variablen Latenzzeiten, die stark vom aktuellen Datenaufkommen abhängen. Deshalb sollte die Faustregel gelten, Web-Services möglichst asynchron aufzurufen. Dies verschafft der Client-Seite die Möglichkeit, die Zeit bis zur Antwort des Service sinnvoll zu nutzen. Das ist besonders wichtig, wenn der Service von einem User Interface aus aufgerufen wird, um die Benutzeroberfläche nicht einzufrieren, bis die Antwort des Service eintrifft.

Asynchroner Aufruf erfordert Multithreading

SOA wird kommen, da sind sich die Experten einig. Bis jedoch Geschäftslogik als Web-Service veröffentlicht und nicht nur als Punkt-zu-Punkt-Dienst verwendet werden kann, bedarf es noch einiger Standardisierungsarbeiten.
SOA wird kommen, da sind sich die Experten einig. Bis jedoch Geschäftslogik als Web-Service veröffentlicht und nicht nur als Punkt-zu-Punkt-Dienst verwendet werden kann, bedarf es noch einiger Standardisierungsarbeiten.

Implementiert man die Service-aufrufe asynchron, so bewirkt dies aber, dass typische Clients mit mehreren Aufgaben gleichzeitig umgehen können müssen - man spricht von Multithreading. Diese Nebenläufigkeit mehrerer Programmteile muss der Entwickler wiederum in seinem Code synchronisieren. Für viele Client-Entwickler stellt die solide Umsetzung von Multithreading eine neue Herausforderung dar, weil die zeitlichen Abläufe plötzlich einen entscheidenden Einfluss auf das Programmverhalten haben. Die Komplexität im Client steigt weiter an, wenn man sich über Offline-Fähigkeiten oder den Umgang mit Versionswechseln der verwendeten Services Gedanken macht.

Auswirkungen auf Beschreibung von Use Cases und Tests