| Seite 1: | OOP 2008: Entwicklertipps für den SOA-Einstieg |
| Seite 2: | Repository nicht vorrangig |
| Seite 3: | Defizite der Web-Services |
| Seite 4: | Absage an SOA plus EDA |
| Seite 5: | Zwei Beispiele |
Eine lebhafte Diskussion gab es auf der OOP darüber, mit welcher Technik eine SOA-Infrastruktur umgesetzt werden sollte. Hier haben sich aufgrund des Herstellerdrucks der vergangenen Jahre Web-Services trotz aller Unzulänglichkeiten durchgesetzt. Zu viele, untereinander nicht interoperable Standards tummeln sich mittlerweile unter dem Dach von Web-Services, so die Kritik. Bereits die Kombination von Services, die in der WSDL 1.1 beschrieben wurden, ist mit solchen der WSDL 2.0 problematisch. Josuttis rät deshalb, sich an das Basic Profile 1.1 zu halten, das zwar zahlreiche Einschränkungen mit sich bringt und zum Teil noch mit den älteren Versionen der Web-Services-Standards arbeitet, dafür aber eine weitreichende Interoperabilität verspricht. In dem Zusammenhang empfiehlt er auch, die eigentliche Servicebeschreibung nicht in der WSDL vorzunehmen, deren Mittel für den fachlichen und nichtfunktionalen Teil nicht ausreichen. Stattdessen sollte man sich einer eigenen, an das Metamodell angelehnten Notation bedienen und diese dann in die WSDL überführen. Dieses Vorgehen trägt vor allem auch dazu bei, dass SOA-Investitionen geschützt bleiben, selbst wenn die technische Infrastruktur ausgetauscht wird.
Als Alternative zu Web-Services wurde auf der OOP lebhaft über Representational State Transfer (Rest) diskutiert, einen Architekturstil, der dem World Wide Web zugrunde liegt und seit kurzem immer öfter als Basis für SOA ins Gespräch kommt. Leidenschaftlicher Verfechter eines "Restful http-Gebrauchs" war auf der Veranstaltung InnoQ-Chef Tilkov. Seine Vision ist, dass alle Elemente einer Anwendungslandschaft als Ressourcen mit einer eindeutigen ID (Uniform Resource Identifier = URI) gekennzeichnet sind und sich verlinken lassen. Darauf werden dann die vier Rest-Standardmethoden (Get für Lesen, Put für Anlegen, Delete für Löschen, Post für Ändern) angewendet. Einer der technischen Vorteile sei zum Beispiel, dass alle http-Features wie Caching, Compression, Redirection direkt genutzt werden können, während Web-Services, die zu rund 90 Prozent ebenfalls auf http setzen, diese Funktionen außer Acht lassen.
Mit den Rest-Prinzipien würden sich typische High-Level-Ziele von SOA wie lose Kopplung und weitreichende Interoperabilität standardkonform umsetzen lassen, meint Tilkov. Einschränkend fügt er allerdings hinzu, dass Rest keine Standards zur Integration von Altsystemen bietet und dass die Architektur keine diensteorientierten Konzepte unterstützt. Entsprechende Kritik musste sich Tilkov auf der Podiumsdiskussion von Thomas Stahl, b+m Informatik, anhören, der den Rest-Ansatz in den Bereich von objektorientierten anstatt Service-orientierten Modellen rückte und dies als Rückschritt empfindet. Auch Josuttis sieht in Rest eher eine Abfragesprache für Ressourcen, die über IP-Adressen verfügbar sind, und damit eine technische Schnittstelle, die sich noch nicht für SOA eignet.
