Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

t3n 7

Sinnvolle Modelle und brauchbare Technologien: SOA implementieren mit Open Source

    Sinnvolle Modelle und brauchbare Technologien: SOA implementieren mit Open Source

Glaubt man einschlägigen Veröffentlichungen, ist die Frage, ob SOA nötig ist oder nicht, beantwortet. Nun gehe es darum, wie eine SOA am besten zu erreichen sei. Die Diskussionen um den Nutzen ebben derweil ab und es gilt, schnellstmöglich die Anwendungslandschaften zu strukturieren, sodass die versprochenen Früchte des SOA Paradigmas geerntet werden können. Aus Sicht der Tool-Anbieter ist das Vorgehen klar. Anwender und Dienstleister können sich jedoch einer differenzierten Betrachtung nicht entziehen.

Das A in SOA steht für Architektur. Nun hat der Software-Architekt gelernt, dass gute Architekturen technologieneutral sind. Abhängigkeiten zu Produkten und Tools sollten für Architekturen völlig tabu sein. Oder, wie es Thomas Müller zum Thema Käuflichkeit einer SOA formuliert [1] : „Die IT ist Dienstleister um [Geschäftsprobleme eines Unternehmens] zu lösen, nicht um Technologie zu erstellen, für die es vielleicht mal irgendwann ein Geschäftsproblem geben wird.“ In der Tat darf bezweifelt werden, dass Infrastruktur-Produkte und Entwicklungstools über den Erfolg einer SOA Initiative entscheiden. Da die Frage nach Open oder Closed Source aber nur auf der Ebene von Produkten und Tools sinnvoll gestellt werden kann, scheint sie zunächst von nachrangiger Bedeutung. Es besteht allerdings die Gefahr, dass eine übermäßige Beschäftigung mit dem Thema SOA von der eigentlichen Aufgabenstellung ablenkt.

Hier sollen die Grundlagen einer SOA nicht wiederholt werden. Es existieren bereits gute Analysen [2]. Danach hat SOA im Wesentlichen drei verschiedene Aspekte: Komponenten, Geschäftsprozesse und Integration. Im Zentrum stehen jedoch die Services als „Bürger erster Klasse“. Ernst zu nehmende Auseinandersetzungen mit SOA stellen mittlerweile auch die Wichtigkeit des „richtigen“ Service-Zuschnitts in den Vordergrund. Der hängt nämlich stark vom fachlichen Umfeld (Domäne) ab, in der die IT wirken soll. Ohne eine grundlegende Übereinkunft über die wesentlichen Objekte, ihre Attribute und ihre Beziehungen ist das Design stabiler fachlicher Services nicht möglich – ein anerkanntes fachliches Datenmodell ist Voraussetzung.

Spaghetti auf hohem Niveau

Wer sich nun vor der nicht-trivialen Aufgabe drückt, bleibt in puncto SOA bei der Bereitstellung von Infrastruktur stecken. Es ist in der Tat zu beobachten, dass vor allem IT-getriebene SOA-Projekte einen starken Fokus auf Infrastruktur haben. Damit allein kommen die versprochen Vorteile einer SOA aber nicht zum Tragen. Hier wiederholt sich das „Spaghetti Missverständnis“ der EAI aus der vergangenen Dekade. Es reicht eben nicht, die heterogenen Punkt-zu-Punkt Verbindungen der IT-Landschaft durch einen einheitlichen Kommunikationsmechanismus zu ersetzten. Ohne guten fachlichen Schnitt und ein gemeinsames Verständnis der essenziellen Objekte und Beziehungen werden nur Services mit begrenztem Scope und kurzer Lebensdauer entstehen. Schlimmstenfalls sind die Services nur für einen Klienten in einem bestimmten Kontext nutzbar und werden im nächsten Projekt oder Release wieder ersetzt.

Bitte beachte unsere Community-Richtlinien

Schreib den ersten Kommentar!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Finde einen Job, den du liebst