Die Organization for the Advancement of Structured Information Standards (OASIS) hat ihr im August 2006 erschienenes Referenz Modell für die Service Oriented Architecture zu einem OASIS Standard erhoben. Das ist die höchste Stufe, die ein solches Modell in OASIS erhalten kann. Das Referenz Modell soll Grundlage sein für künftige Referenzarchitekturen und Implementierungen. An der Entwicklung dieses Modells beteiligt waren unter anderem Firmen wie Adobe, Boeing, BEA Systems, Capgemini, Fujitsu, General Motors, NEC und Software AG.
Wer von dem neuen Referenzmodell eine konkrete Anleitung zur Implementierung von Service Oriented Architecture erwartet oder gar eine Festlegung auf eine bestimmte Technologie, wird von dem von der OASIS vorgelegten SOA Referenz Modell enttäuscht sein. Das Dokument bleibt auf einer sehr abstrakten Ebene.
Und das ist gut so. Wer den Markt beobachtet, wird sehen, dass jeder Anbieter, der eine neue Architektur in seinem Produkt einführt, es als SOA anpreist. Und auch wenn das Produkt keine neue Architektur erhalten hat, wird dennoch mit SOA geworben und Module zu Services umbenannt. Das geht, weil der Begriff der Service Oriented Architecture in der Gefahr steht, zum Modewort zu verkommen, und damit die Ernsthaftigkeit und Herausforderung dieses Ansatzes in der Software Technologie untergraben wird. Daher wird es Zeit, in einem ersten Schritt Definitionen der mit SOA verbundenen Begriffe zu liefern und diese in ein Gesamtkonzept einzuordnen. Genau das tut dieses Referenzmodell. Das ist im ersten Schritt auch viel wichtiger als irgendwelche SOA Implementierungen zu einem Standard zu erheben.
Was aber beinhaltet das Referenzmodell? Für den, der sich schon länger mit SOA beschäftigt hat, sicherlich nicht viel Neues, aber doch sehr stringent zu einem Modell zusammengefügt.
Das grundlegende Bild dieses Modells ist das des Marktes, auf dem sich Angebot und Nachfrage, Bedürfnisse und Leistungsfähigkeit begegnen. Beide Seiten müssen voneinander wissen und auch bereit und in der Lage sein, untereinander zu interagieren. Dazu gehört auch, dass das Angebot klar beschrieben ist. Hier wird auch ein interessanter Vergleich zum objektorientierten Ansatz gezogen, der mit seinem Klassenmodell Strukturen von Attributen und Methoden beschreibt, aber für die semantische Bedeutung dieser Strukturelemente allenfalls in Kommentaren Platz hat. Im Gegensatz dazu gehört es essentiell zur SOA, dass die Beschreibung eines Service die Struktur des In- und Outputs und auch deren semantische Bedeutung beinhaltet. Diese Interaktion zwischen Nachfragenden und Anbietenden oder in der Sprache des Referenzmodells zwischen consumer und provider geschieht in einem spezifischen Kontext und beruht auf gemeinsam geschlossenen Vereinbarungen und auf Regelwerken (policies), die jede Seite für sich selbst definiert. Diese Interaktion wird eingegangen, um eine Wirkung zu erzielen. Diese Wirkung kann in der Übermittlung einer Information (Beispiel Datenbankabfrage), in der Veränderung eines für beide Seiten zugänglichen Status (Beispiel Ticketreservierung) oder in der Kombination von beiden bestehen.
Die abstrakte Ebene eines Referenzmodells wird konsequent eingehalten und technische Fragestellungen werden so vollständig ausgeblendet.
Allerdings an einer Stelle haben es sich die Verfasser sehr leicht gemacht. Der Prozesscharakter, der in der SOA eine wichtige Rolle spielt, indem nicht nur die einzelne Interaktion betrachtet wird, sondern die Interaktionen als Bestandteil eines Prozesses, wird ausdrücklich ausgeblendet. Deutlich wird in dem Referenzmodell gesagt, dass Orchestrierung und Choreographie nicht zum Modell hinzugehören. Das hilft sicherlich, um das Modell übersichtlich zu halten und sich auf den Charakter der Interaktion zwischen consumer und provider zu fokussieren. Aber es beschneidet auch einen wichtigen Inhalt und eine entscheidende Herausforderung von SOA: Wie können die vielen Dienste in sinnvoller Weise und prozessorientiert genutzt werden?
In der realen Welt der Implementierung ist das neben den technischen Herausforderungen häufig eine entscheidende Fragestellung. Darauf gibt das Referenzmodell keine Antwort. (CJ)
Metadata