Anzeige
Anzeige
Artikel

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.

7 Min.
Artikel merken
Anzeige
Anzeige

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: „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.

Anzeige
Anzeige

Hier sollen die Grundlagen einer SOA nicht wiederholt werden. Es existieren bereits gute Analysen [1]. 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.

Anzeige
Anzeige

Trotz SOA sind die Abhängigkeiten in der Systemlandschaft nicht kleiner geworden und mithin die Flexibilität nicht größer. SOA hat sich wie eine weitere Sedimentschicht auf Ihre Systemlandschaft gelegt und sie vielleicht sogar noch ein wenig komplexer und umständlicher gemacht.

Anzeige
Anzeige

Wieder Wiederverwendung

Wie fast immer bei Paradigmenwechseln in der IT muss auch bei SOA das Versprechen von besserer Wiederverwendung als Begründung herhalten. Das Kunststück für den Architekten ist also die Trennung der stabilen Bestandteile der Software von den sich ändernden. Hier ist den Services die Rolle zugedacht, durch gutes Design möglichst lange unverändert vielen Klienten in unterschiedlichen Geschäftsprozessen ein wohl definiertes Stück Arbeit abzunehmen. Dagegen wird der variable Teil, die Verknüpfung dieser Dienste zu sinnvollen Geschäftsprozessen, in eine Art „obere Verdrahtungsebene“ separiert.

Das Herauslösen der Geschäftsprozesse aus den Anwendungen ist ein ganz wesentlicher Aspekt der Restrukturierung in Richtung SOA. Hierfür ist eine unterstützende Infrastruktur in Form einer so genannten Workflow-Engine in der Regel angemessen. Hier haben sich zwei Standards zur Beschreibung der Workflows etabliert: BPEL und XPDL. Diese Engines nehmen viel Arbeit ab:

Anzeige
Anzeige
  • die Verwaltung der Prozesse (anlegen, modifizieren, löschen, auffinden)
  • Persistierung der Prozesse und ihrer Attribute und Status (Stichwort Wiederanlauf)
  • Transaktionssteuerung
  • (Basisinfrastruktur für die) Fehlerbehandlung
  • Unterstützung für manuelle Arbeitsschritte

Von einer eigenen Implementierung sollte abgesehen werden, es gibt zahlreiche Produkte, auch als Open Source und lizenzkostenfrei (z. B. WfMOpen [2] ). Bei sehr kleinen und einfachen Anwendungen kann man diese Schicht auch hart kodieren. Java ist auch nicht weniger flexibel als BPEL und im laufenden Betrieb ändert erfahrungsgemäß niemand Workflows. Es wäre vermutlich aber Zeitverschwendung, die oben aufgelisteten Features einer Engine zu implementieren.

Workflows sind in ihrer Logik speziell für ein Projekt oder einen Kunden zugeschnitten. Die Substanz Ihrer Anwendungen steckt hingegen in den Services. Sie bilden die Quelle für Wiederverwendung. Pflege und Ausbau dieses „Kapitals“ einer IT-Landschaft hat höchsten Stellenwert.

Komponenten der nächsten Generation

Services, die einen fachlichen Zusammenhang haben, werden sinnvollerweise gruppiert. So entstehen Module oder Komponenten. Auch das ist – wie so vieles bei SOA – nichts Neues: Komplexe Aufgabenstellungen werden partitioniert. Beim Schnitt der Komponenten wird auf hohen inneren Zusammenhang (Kohäsion) geachtet und so die Abhängigkeiten zwischen den Bauteilen minimiert.

Anzeige
Anzeige

Neu ist vielleicht der Aspekt, dass Komponenten (Anwendungen sind zu grob-, einzelne Services zu kleingranular) Ihre Entwicklungseinheiten (Teams, Versionen, Deployments) bestimmen. Eine ordnende Hand – zum Beispiel ein Architektur-Board – stellt dabei sicher, dass der Nutzer der Vision eines flexibel kombinierbaren Baukastens mit Elementen, die aufeinander aufbauen und einander ergänzen, näher kommt. Hier erfordert SOA kein besonderes Tooling und keine spezielle Infrastruktur. Es wird sorgfältig angewendet, was gutes Software Engineering ausmacht. Einheitliche Infrastruktur und Entwicklungswerkzeuge fördern die Homogenität im Baukasten. Der Software-Dienstleister Danet, Arbeitgeber des Autors, setzt hier beispielsweise auf „Mainstream“ und Quasi-Standards im Java-Umfeld (eclipse, cvs, ant, JUnit, J2EE, Hibernate, etc.).

Ein wichtiger Aspekt beim Komponentenbau ist der Fokus auf die Dienste, die sie bereitstellen. Sie stehen im Mittelpunkt und geben einer Komponente erst Ihre Berechtigung. Das ist vielleicht der wesentliche Unterschied zur klassischen Anwendungsentwicklung, wo Schnittstellen oft erst im Nachhinein konzipiert wurden. Konzeption und Dokumentation der Schnittstellen von Komponenten (= Services im engeren Sinne) ist elementar. Wie aber beschreibt man Services? Eindeutig in Signatur und Semantik? Java API (javadoc) ist sprachspezifisch, IDL ist mit Corba aus der Mode gekommen. WSDL (Web Service Definition Language) ist ein pragmatischer Ansatz, wenngleich Experten zu bedenken geben, dass damit nicht alle Aspekte beschrieben werden können.

Zumindest können die Datenstrukturen als Schema (XSD) in allgegenwärtigem XML beschrieben werden. Darüber hinaus ist, gerade zur Klarstellung der Semantik, textuelle Dokumentation – zum Beispiel in Form von Wikis – viel wichtiger als formale Register. Zur Laufzeit wohnen die Komponenten in Service Containern – J2EE Application Server (z. B. JBoss) bieten dazu viel Komfort. Je nach Anwendungsfeld machen auch leichtgewichtigere Alternativen Sinn.

Anzeige
Anzeige

Theoretisch kann das Aufbrechen monolithischer Anwendungen in Komponenten dazu führen, dass die „Make-or-buy Entscheidungen“ nun auf Komponentenebene getroffen werden. So verkündet SAP beispielsweise auf einer letztjährigen JAX Keynote das „versöhnliche Nebeneinander von SAP und Eigenbau dank SOA“. Man darf gespannt sein, wie das in der Praxis aussieht.

Im Konzert

Komplexe Landschaften, zerlegt in Komponenten und Geschäftsprozesse, erfordern wiederum Integration der Bauelemente und die Kommunikation zwischen ihnen. Das ist so gesehen die Kehrseite der Modularisierung und erhöht die Komplexität des Gesamtsystems. Je loser die Kopplung, desto komplizierter gestaltet sich das Zusammenwirken, spätestens dann, wenn nicht nur der Gutfall Betrachtung findet. EAI Lösungen in Form von „Integration Backbones“ mildern das Problem, sollten aber kein Selbstzweck einer SOA Initiative sein. Insbesondere ist es wünschenswert, die Abhängigkeiten Ihrer Services und Komponenten von der Middleware zu minimieren. Dazu gibt es im Wesentlichen zwei Ansätze, so genannte „Invocation Frameworks“ (z. B. WSIF [3] ) und Generatoren, die den Kleber zwischen fachlicher Logik und technischem Kommunikationsmechanismus automatisch erzeugen.

Ein mittlerweile aufgeklärtes Missverständnis ist, dass SOA WebServices, also SOAP über HTTP, erfordere. Das ist nicht so. WebServices ist für Kommunikation über Unternehmensgrenzen hinweg (B2B) meistens die richtige Wahl, innerhalb von Unternehmen in der Regel nicht. Die Firma Danet verwendet dazu drei verschiedene Lösungsmuster: RMI/IIOP für enge Kopplungen zwischen Java Komponenten, XML über JMS für asynchrone, lose Kopplungen und WebServices für externe (B2B) Interfaces. Dabei wurde die Erfahrung gemacht, dass verfügbare Open-Source-Infrastruktur (z. B. Axis, ActiveAQ, JBoss Messaging, Xerces) sehr gut anwendbar ist. Eigenentwicklungen auf dieser Ebene sind für Dienstleister und Lösungshersteller normalerweise nicht sinnvoll. Auf der anderen Seite sind Abhängigkeiten von kommerziellen SOA und EAI Produkten eher hinderlich. In der Praxis wählen große Kunden Integrationsplattformen selbst aus und lassen Dienstleistern kaum Freiraum, während kleinere Kunden die Lizenzkosten kommerzieller Middleware nicht tragen können.

Anzeige
Anzeige

Fazit

Die Analyse einer Domäne und ihre Zerlegung in fachliche Services und Komponenten ist keine einfache Aufgabe. Sie ist aber der Schlüssel für Wiederverwendung und darum geht es im Kern bei SOA. Wer Flexibilität und Wiederverwendung will, sollte sich aber nicht von „Fluchtzielen“ ablenken lassen, die die SOA Tool-Industrie allzu gerne anbietet.

Für bestimmte Projekte mögen ausgefuchste Repositories nötig sein, um hunderte von verschiedenen Artefakten einer SOA Landschaft zu verwalten und vielleicht brauchen manche Unternehmen den 8-spurigen SOA Integration Highway quer durch das Unternehmen. Für die meisten Architekten wird es aber vermutlich zunächst Wichtigeres geben.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Kommentare

Community-Richtlinien

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Kommentar abgeben

Melde dich an, um Kommentare schreiben und mit anderen Leser:innen und unseren Autor:innen diskutieren zu können.

Anmelden und kommentieren

Du hast noch keinen t3n-Account? Hier registrieren

Anzeige
Anzeige