OOP 2008: Entwicklertipps für den SOA-Einstieg

SOA ist gut, aber nicht für jeden – zu dieser gemeinsamen Position kamen die Teilnehmer einer Podiumsdiskussion über Service-orientierte Architekturen auf der Kongressmesse OOP 2008 in München. Wenn typische, mit SOA verknüpfte Eigenschaften wie Agilität und Flexibilität nicht erforderlich sind, etwa weil die unternehmensspezifischen Geschäftsprozesse strukturiert, vor allem aber sehr gleichförmig ablaufen, dann sollten Anwender die Hände von einer neuen Architektur lassen. Er habe Situationen erlebt, wo Anwender in ihrer SOA-Euphorie aufwändige BPEL-Services aufgesetzt haben, obwohl einfache Datenbankeingriffe oder Batch-Programme gereicht hätten, meinte Panel-Teilnehmer Stefan Tilkov von der InnoQ GmbH aus Ratingen bei Düsseldorf.

Einen im Vergleich zu Agilität und Flexibilität deutlich pragmatischeren Ansatz in der Beschreibung von SOA-Zielen wählte Diskussionsmoderator Nicolai Josuttis von IT-communication.com in Braunschweig. SOA habe zunächst nichts mit Produkten zu tun, vielmehr handele es sich um ein Konzept beziehungsweise eine Strategie, mit der sich große, verteilte und in der Regel heterogene IT-Systeme besser verwalten lassen. Wer solche Komplexität nicht im Haus hat, sollte auf SOA-Techniken oder Web-Services besser verzichten. Doch oft gibt es keine Alternative, denn spätestens im B-to-B-Umfeld geht es darum, die in verteilten Systemlandschaften unterschiedlich definierten Datentypen so zusammenzubringen, dass sie den diversen Sichten der Fachbereiche konsistent zur Verfügung stehen. Das SOA-Rezept dafür heißt Reduktion von Abhängigkeiten, insbesondere die Trennung von fachlicher und technischer Schicht sowie deren lose Kopplung über APIs. Im Prinzip nichts Neues, so Josuttis, aber immerhin habe der SOA-Hype dazu geführt, dass man nun nicht mehr verzweifelt gegen die Komplexität einer heterogenen IT-Landschaft ankämpft, sondern diese akzeptiert und Wege sucht, mit ihr zu leben.

Schwache Wiederverwendung

Als einen der wesentlichen Treiber, mit dem IT-Umbau nach SOA-Prinzipien zu beginnen, nennt der Experte neben der Pflege und Wartbarkeit komplexer Systeme auch die Software-Entwicklungskosten, die im Vergleich zu traditionell wachsenden Infrastrukturen auf lange Sicht deutlich niedriger ausfallen sollten. Die von Herstellern in diesem Zusammenhang gerne ins Feld geführte Wiederverwendbarkeit von Services eignet sich dagegen kaum als SOA-Motivator. Josuttis zufolge habe sich in zahlreichen SOA-Projekten herauskristallisiert, dass ein Softwareservice (Provider) im Durchschnitt nur von ein bis zwei Nutzern (Consumer) in Anspruch genommen wird, von einer intensiven Mehrfachverwendung also kaum die Rede sein kann.

Bezüglich der Einführung von SOA gab der Berater im Rahmen einer eigenen OOP-Session eine Reihe wertvoller organisatorischer und technischer Tipps. Da SOA die Summe aus Infrastruktur-, Architektur- und Prozessaspekten ist, muss sich dieser Umstand auch in der Zusammensetzung des Projektteams widerspiegeln. Haben Entwickler oder die IT das Sagen, droht ein technischer Überhang, verordnet das Topmanagement SOA, kann das ein teures, aber wenig erfolgreiches Projekt zur Folge haben. Ansonsten gilt das unter Experten bekannte Prinzip: "Think big, start small". Josuttis empfiehlt einen überschaubaren Piloten mit einer kleinen Anzahl von Basisdiensten und Serviceteilnehmern. Erst im nächsten Schritt sollte man Prozesse in Form kombinierter oder orchestrierter Services sowie Prozessregeln einführen.

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.

Defizite der Web-Services

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.

Rest kontra Web-Services

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.

Absage an SOA plus EDA

Bezüglich der Zukunft von SOA erteilten die Diskussionsteilnehmer der Gartner-Formel "SOA plus EDA (Event Driven Architecture) gleich SOA 2.0 oder Advanced SOA" eine klare Absage. EDA sei ein altbekanntes, eigenständiges Architekturkonzept, das unabhängig von SOA existiere, so dass man allenfalls ein optimales Zusammenspiel anstreben könne. Doch auch das berge Gefahren: Regelbasierende Systeme erzeugen Ereignisse, bei denen man in lose gekoppelter Umgebung schnell die Kontrolle darüber verliert, was ein Event auslöst und wie das Gesamtsystem darauf reagiert. An solchen Problemen seien seinerzeit schon die Expertensysteme gescheitert. Eine Forderung an die Hersteller, die mit Complex-Event-Processing-Fähigkeiten werben, ist deshalb die Bereitstellung geeigneter Tracking-Mechanismen, die auch in komplexen Servicelandschaften funktionieren. Doch das ist noch Zukunftsmusik. Oracle-Vertreter Clemens Utschig-Utschig gab in der Diskussion zu, dass EDA heute noch weitgehend branchenspezifisch etwa im Bankenumfeld oder in der Flugsicherung hart implementiert wird. Dort allerdings würde sich EDA auch in einer Servicelandschaft gut dazu eignen, um Was-wäre-wenn-Szenarien aufzusetzen.

Wenig halten die Experten auch von der im Zusammenhang mit SOA inzwischen häufiger ins Spiel gebrachten Service Component Architecture (SCA). Hier handelt es sich um ein Assemblierungsmodell für Komponenten, und zwar unabhängig davon, wie die Funktionen innerhalb der einzelnen Bausteine implementiert wurden. Die Kritik an diesem Vorgehen: SCA fungiere quasi als Mediator zwischen unterschiedlich aufgesetzten Services, und das widerspreche dem Standardisierungsgedanken. Standards seien aber das eigentlich Neue an Themen wie SOA oder EDA. Deshalb müssten Anwender den Mut aufbringen, sich trotz der jeweiligen Unzulänglichkeiten auf eine Norm festzulegen, seien es zum Beispiel Web-Services, Rest oder Corba. Erst dann, wenn man sich auf einen Standard geeinigt hat, sollte man mit der Produktauswahl beginnen.

Function Points: Kunstwährung für SOA

Wer eine SOA-Einführung plant, sollte die Gelegenheit nutzen, gleichzeitig ein Kennzahlensystem aufzusetzen, zumal gerade bei Management-getriebenen Projekten früher oder später die Frage nach dem Erfolg und der Wirtschaftlichkeit der Architektur kommt. Einen Weg dorthin beschrieb auf der OOP Thorsten Janning von der Kegon AG in Wiesbaden. Der für SOA relevante Bereich, aus dem sich die benötigten Zahlen generieren lassen, ist demnach das Anforderungs-Management, der Software-Entwicklungsprozess, die Systemwartung sowie das Release- und Qualitäts-Management. Um objektiv messbare Zahlen zu erhalten, empfiehlt Janning ein Vorgehen nach der von der Nasa Anfang der 80er Jahre entwickelten GQM-Methode (Goal, Question, Metrik). Das heißt, es findet eine Zieldefinition statt, aus der man dann die Fragen ableitet, mit welchen Kennzahlen (Metriken) ein Ziel quantifiziert und qualifiziert werden kann.

Zwei Beispiele

Hier zwei Beispiele zur Ermittlung zielorientierter Kennzahlen für einen SOA-Service nach der GQM-Methode:

Das Ziel: Verbessere die Wartbarkeit von Services.

Die Fragen:

• Welche Komplexität haben die Services? Der Komplexitätsfaktor, also wie viele Services beteiligt sind, lässt sich anhand der Methode Average Component Dependency (ACD) ermitteln.

• Welche Wartungsaufwände (Kosten) werden für den Service benötigt?

• Wie gut ist der Service dokumentiert?

• Welche Fähigkeiten werden benötigt, um den Service zu warten (intern und extern)?

• Wie viel Standardservices werden in einem übergeordneten Gesamtservice eingesetzt?

Das Ziel: Verbessere die Zuverlässigkeit des Service.

Die Fragen:

• Wie viele Fehler treten im Service auf (aktuell, Vorjahr)?

• Wie viele Fehler sind im Service bekannt?

• Welche Ausfallzeiten entstehen durch den Service?

Als Basis für Kennzahlen, mit denen sich viele dieser Fragen beantworten lassen, empfiehlt Janning die Verwendung von Function Points und die Anzahl von Zugriffen auf einen Service. Sie bieten objektiv messbare und nachvollziehbare Werte, die man für eine Management-Entscheidung heranziehen kann. Anhand von Function Points lassen sich beispielsweise die Kosten für die Erstellung, Wartung und Wiederverwendung eines Service ermitteln. Dieses Vorgehen trägt auch dem Umstand Rechnung, dass ein Service nur selten in seiner Gesamtheit wiederverwendet wird, dafür aber mehrere Funktionen daraus. Ein Qualitätsmerkmal für einen Service ist demnach, wie oft seine Funktionen in einem übergeordneten Gesamtservice genutzt werden. So hat etwa ein Basisservice eine höhere Reichweite und damit Wiederverwendung, dafür verursacht er aber auch mehr Wartungsarbeiten. (ue)