Was bei der Diskussion allerdings oft vergessen wird, sind die gravierenden Risiken, die man sich auf zahlreichen Ebenen des Software-Engineering einhandelt, wenn man allzu euphorisch und schlecht vorbereitet auf den SOA-Zug aufspringen will. Die Gefahren lauern in fast allen Disziplinen - umso wichtiger ist die intensive Beschäftigung mit dem Thema bei allen Beteiligten vom Programmierer bis hin zum Entscheider.
Entwickler erwartet eine radikal veränderte Welt
Die Welt des Entwicklers verändert sich an einer Service-Schnittstelle radikal. Vieles, was in einer lokal arbeitenden, objektorientierten Welt noch praktikabel war, ist Gift für performante Web-Service-Lösungen. Das fängt schon bei den zu übertragenden Daten an: Man bevorzugt an Service-Schnittstellen wenige, grob granulare Aufrufe mit vielen Daten vor "Chatty Interfaces" wie sie für lokale Objekte gerne verwendet werden.
Services machen regen Gebrauch von XML-Sprachen. XML wird verwendet, um festzulegen, wo ein Service zu finden ist (UDDI), um Service-Schnittstellen zu definieren (WSDL), und vor allem auch, um Daten zu transportieren (Soap). XML ist aber als Lingua franca mit all ihren Standards entgegen der landläufigen Meinung und trotz ihrer Beliebtheit alles andere als trivial. Jeder, der sich einmal genauer mit den Feinheiten von XML-Schema und XML-Namespaces oder komplexen XSLT-Skripten befasst hat, kann dies nur bestätigen. Immerhin versuchen die Hersteller aktueller WS-Entwicklungs-Tools, diese Komplexität weitestgehend zu kapseln. Ob es jedoch eine gute Idee ist, wenn die Schnittstellen-Definition eines Web-Service in XML formuliert und veröffentlicht wird, dem Entwickler aber verborgen bleibt, scheint fraglich. Erste Erfahrungen aus der Praxis zeigen: Zumindest Entwickler, die für die Server-Seite des Service verantwortlich zeichnen, werden früher oder später zu XML- und XML-Schema-Profis - ob sie wollen oder nicht.