Repository nicht vorrangig

Für entbehrlich, zumindest zu diesem Zeitpunkt, hält er das von Herstellern im Rahmen von SOA dringend empfohlene Repository, in dem die fachlichen Beschreibungen der Services hinterlegt sind, sowie eine Registry, in der die technischen Details zum Servicebetrieb gesammelt werden. Stattdessen reiche meist ein einfaches zentrales Verwaltungs-Tool. Viel wichtiger sei dagegen von Anfang an die Verwendung eines Metamodells, denn nur so erhalte der Entwickler eine Vorstellung von der Mächtigkeit seiner Service-Schnittstellen.

Was den Lebenszyklus eines Service betrifft, so ist dieser mit einer entscheidenden Ausnahme dem in der traditionellen Softwareentwicklung ähnlich: Der Anforderungsaufnahme entspricht das Identifizieren eines Service, es folgt die Modellierung beziehungsweise das Design, die Implementierung über Codegeneratoren, der Test und die Auslieferung. Die in der klassischen Entwicklung aufgrund eines Change-Requests vorgenommene Änderung eines Programms sollte es in einem aktiven Service jedoch nicht geben. "Änderungen an den Services einer SOA sind im Grunde nie rückwärtskompatibel", warnt Josuttis. Der Grund: Ist ein Service in Betrieb und wird nachträglich etwa mit weiteren Datentypen angereichert, müssen alle bei der Codierung erzeugten Bibliotheken neu kompiliert werden. Das gelingt in der Praxis offensichtlich nicht immer, so dass die Gefahr besteht, dass der Service einem Consumer nicht mehr zur Verfügung steht. Mit Ausnahme von Bugfixes, die keine Auswirkungen auf Service-Schnittstellen haben, wird daher dringend empfohlen, für Änderungen einen neuen Service aufzusetzen und den alten gegebenenfalls außer Betrieb zu nehmen. Damit geht auch die Notwendigkeit einher, Serviceaufrufe zu protokollieren, um einen Nutzer über die geplante Abschaltung eines Service informieren zu können.