Ein Plädoyer für Open-Source-SOA

25.08.2006
Von Markus Goerg 
Die im Rahmen einer Service-orientierten Architektur geforderte Interoperabilität von Softwarediensten ist nach Meinung unseres Autors Markus Goerg* mit kommerziellen Angeboten kaum in Einklang zu bringen.
Wie können Unternehmen von Service-orientierten Architekturen profitieren? Wo liegen die größten Hürden und was sind die Konzepte der Softwarehersteller wert? Mit diesen Fragen beschäftigt sich der SOA-Expertenrat der COMPUTERWOCHE. Mitglieder des Gremiums sind hochkarätige Spezialisten aus Unternehmen und Forschungsinstituten. Diskutieren Sie mit, veröffentlichen Sie eigene Artikel und stellen Sie Fragen an den Expertenrat unter www.computerwoche.de/soa-expertenrat.
Wie können Unternehmen von Service-orientierten Architekturen profitieren? Wo liegen die größten Hürden und was sind die Konzepte der Softwarehersteller wert? Mit diesen Fragen beschäftigt sich der SOA-Expertenrat der COMPUTERWOCHE. Mitglieder des Gremiums sind hochkarätige Spezialisten aus Unternehmen und Forschungsinstituten. Diskutieren Sie mit, veröffentlichen Sie eigene Artikel und stellen Sie Fragen an den Expertenrat unter www.computerwoche.de/soa-expertenrat.
Damit der Traum einer flexibel anpassbaren IT-Infrastruktur wahr werden kann, ist eine mehrschichtige Architektur notwendig. Die einzelnen Ebenen sind über Standards miteinander verzahnt, jedoch lose gekoppelt.
Damit der Traum einer flexibel anpassbaren IT-Infrastruktur wahr werden kann, ist eine mehrschichtige Architektur notwendig. Die einzelnen Ebenen sind über Standards miteinander verzahnt, jedoch lose gekoppelt.

Die Antwort auf die Herausforderungen einer hochflexiblen IT schleppen Strategen seit einiger Zeit in ihren Moderatoren- koffern in Form von Powerpoints mit sich herum: Service-orientierte Architekturen (SOA). Sie bringen Transparenz in die IT-Landschaft, ermöglichen sozusagen eine Inventur, bieten Flexibilität und schützen Investitionen, indem sich bereits vorhandene, stabil laufende Systemteile wiederverwenden lassen. Die Analysten der Aberdeen Group gehen davon aus, dass allein die Top-2000-Unternehmen weltweit in den kommenden fünf Jahren etwa 53 Milliarden Dol- lar an IT-Ausgaben durch SOA sparen können. Der Grund: Ist eine SOA erst mal implementiert, purzeln die Entwicklungskosten.

Empfehlungen für die Web-Services-Kommunikation

Die WSDL bindet eine Web-Service-Definition zunächst nicht an das Protokoll http/Soap. Damit wird es möglich, die für einen Service am besten geeignete Kommunikationstechnik erst mit dessen Aufruf zu generieren. Dies erlaubt zum Beispiel das Webservice Invocation Framework von Apache. Doch auch mit einem funktionierenden Invocation-Framework ist es nicht sinnvoll, beliebig viele Kommunikationsprotokolle gleichzeitig zu fahren. Je nach Art der Anwendung sollte man drei Kategorien unterscheiden:

Direkte Service-Calls über Remote Method Invocation (RMI) oder optimierte lokale Aufrufe in einem Container. Das erlaubt die Performance-kritische Zusammenarbeit von Komponenten, die in enger Nachbarschaft oder sogar in dem gleichen Service-Container ausgeführt werden können.

JMS-konformes Messaging (XML über JMS), wenn die Verfügbarkeit über lose Kopplung erhöht werden soll. Lose Kopplung steht hier für asynchrone Aufrufe, nicht aber für den Verzicht auf wohl definierte Servicesignaturen. Letzteres würde nur die Integrationsprobleme von der Designzeit in die Laufzeit verschieben. Empfohlene Open-Source-Implementierungen sind hier "ActiveMQ" oder "Jboss Messaging 1.0".

Echte Web-Services, also XML/Soap über http(s), wenn zwischen zwei Partnern eine Distanz besteht, die sich darin äußert, dass man keinen gemeinsamen Zugriff auf einen JMS-Provider hat oder Beschränkungen durch Security unterliegt (Firewall, Port-Freischaltungen). Für B-to-B- Anwendungen ist diese Technik erste Wahl. Das Open-Source-Framework dazu ist "Axis 1.1". So-fern C/C++ unterstützt werden soll, gibt es gute Erfahrungen mit "gSOAP". Jboss kommt mit der integrierten Web-Services-Lösung "JbossWS", die aktuell noch auf Axis basiert, jedoch durch eine eigenen Soap-Stack ersetzt werden soll, was wiederum interessant sein dürfte, wenn der Jboss-Applikations-Server ohnehin verwendet wird.

Was Analysten sagen

Einer aktuellen Umfrage der Aberdeen Group zufolge werden neun von zehn Unternehmen in diesem Jahr Erfahrungen mit SOA sammeln. Befragt wurden die CIOs und IT-Leiter von über 120 Unternehmen weltweit. Sie wollen sich verstärkt mit den Design- und Programmiermodellen von SOA auseinandersetzen. Dabei sagen die Analysten dem Konzept eine große Zukunft voraus: 53 Milliarden Dollar an IT-Kosten können allein die TOP-2000-Companies durch SOA einsparen, indem die Entwicklungsaufwendungen sinken. Bevor das jedoch eintritt, gilt es, Geschäftsprozesse neu zu gestalten und sich mit dem SOA-Paradigma auseinander zu setzen.

Open-Source-Beispiele für SOA-Baukasten

Aufgabe Open-Source-Tool

Messaging (JMS) ActiveMQ, JbossMQ

Web-Service-Framework (WSDL, Soap) Apache Axis

Enterprise Service Bus Celtix, ServiceMix, Mule

Workflow-Engine WfMOpen

Service-Container, App-Server (J2EE) Jboss

Datenbank (SQL, JDBC) MySQL

Modellierung (UML) Eclipse Modelling Framework (EMF), Poseidon CE, Magicdraw

Entwicklungsumgebung Eclipse

Versionsverwaltung CVS, Subersion

Build/Deploy Ant, Maven

Unit-Test jUnit

Hier lesen Sie …

Doch bis geerntet werden kann, ist ein gutes Stück Acker zu bestellen - das sagen die Analysten fairerweise auch. SOA braucht neben den elementaren Teilen wie Service-fähigen Anwendungen und einer neuen Denkweise im Unternehmen vor allem ein stabiles IT-Fundament: einen "Baukasten", dessen Elemente aufeinander aufsetzen und einander ergänzen. Sowohl in horizontaler als auch in vertikaler Richtung müssen die Komponenten miteinander interagieren: vom User-Frontend bis zur Datenbank, zwischen einzelnen Applikationen und innerhalb einer Anwendung. Das Denken in Services ist dabei außerordentlich hilfreich. Die Leistungen der Bausteine werden über ihre veröffentlichten Services definiert.

Die Basisinfrastruktur sorgt dafür, dass eine homogene Anwendung aus den Komponenten überhaupt entstehen kann. In einer IT-Landschaft ist Heterogenität jedoch unvermeidlich - man kann also nicht Homogenität fordern, damit SOA funktioniert. Basiskonzepte wie Log/ Trace, Konfiguration, Monitoring und Administration sowie Nachrichtenaustausch müssen dazu einheitlich sein. Ferner stellt der Baukasten sicher, dass alle Lösungskomponenten miteinander interagieren können und eine gemeinsame Integrationsinfrastruktur (Messaging, Workflow, Adapter-Framework) verwenden. Zu den Aufgaben im Bereich Basisinfrastruktur gehören also die Bereiche Messaging, Workflow, Persistenz, Log/Trace, Konfiguration, Scheduling, Monitoring und Controlling, Frameworks für die Gestaltung von Benutzeroberflächen, Service Container und Application Server. Eine Benutzerverwaltung sowie Internationalisierung und Reporting-Funktionen sind ebenfalls Bestandteile.

Die Optionen

Unternehmen haben grundsätzlich drei Möglichkeiten, eine solche Basisinfrastruktur zu etablieren:

1. selber bauen,

2. die Development- und Integrations-Suite von einem Hersteller kaufen oder

3. ein Framework aus Open-Source-Bausteinen zusammenstellen.

Für die wenigsten Unternehmen ist es unserer Erfahrung nach sinnvoll, ein eigenes Framework zu erstellen. Aufbau und Pflege der Bausteine sind aufwändig, wenn man das volle Spektrum der benötigten Aktivitäten und Artefakte berücksichtigt. Insgesamt rechnet sich ein Engagement auf dieser Ebene in der Regel nicht. Softwareentwicklung gehört für das Gros der Industrie-, Handels- und Dienstleistungsfirmen nicht zum Kerngeschäft.

Die Antwort der Softwareindustrie ist mittlerweile hinreichend bekannt: "Kaufen Sie eine Suite von der Stange." Doch eine kommerzielle Komplettlösung wie namhafte EAI- oder neuerdings SOA/ESB-Offerten haben neben dem Kostenaspekt weitere Nachteile: die kritische Abhängigkeit vom Anbieter und eine zum Teil große Überfrachtung der Pakete. Software, die auf Basis dieser Frameworks entsteht, ist in der Regel in anderen Umgebungen nicht verwendbar. Denn trotz aller Lippenbekenntnisse und Initiativen in Sachen Interoperabilität verstehen Hersteller SOA als Mittel, vor allem Produkte aus dem eigenen Portfolio untereinander austauschbar zu machen. Hinzu kommt, dass diese Werkzeuge nach unseren Erfahrungen aus mehreren Integrationsprojekten eher für den Vertrieb als für eine professionelle Produktion optimiert sind. Auch die Integration der einzelnen Bausteine einer Komplettlösung lässt nicht selten zu wünschen übrig, denn viele führende Hersteller haben ihr eigenes Portfolio durch Zukäufe erweitert. Diese Produkte müssen auch erst einmal in die bestehende Tool-Landschaft transplantiert werden.

Reiche Auswahl

Bleibt Variante drei. Open-Source-Software bietet ausreichend Produkte, um einen SOA-Baukasten zusammenzustellen. Sie fußen auf Standards, die heute eine Vielzahl von Referenzen nachweisen können. Dass Qualität und Zuverlässigkeit von Open-Source-Software hoch sind, hat eine Untersuchung der Stanford University zu Beginn dieses Jahres gezeigt: "Das Viele-Augen-Prinzip, bei dem der Quellcode von zahlreichen Entwicklern begutachtet, geprüft und optimiert wird, ist der Grund für eine geringe Fehlerrate", so das Urteil des Forschungsberichts. Doch zum Nulltarif gibt es das SOA-Framework auf Basis von Open Source nicht.

Was nicht gebraucht wird

Es ist zunächst darauf zu achten, welche Aufgabenstellung zu lösen ist und welche Komponenten dazu benötigt werden. Notwendige Elemente einer SOA sind aus Sicht der Softwarehersteller der Enterprise Service Bus (ESB), Web-Services, eine Registry (UDDI) und eine Workflow-Engine. Nach unserer Meinung ist keiner dieser Bausteine zwingend erforderlich.

Viele SOA-Initiativen zielen zunächst darauf ab, eine Kommunikationsinfrastruktur (Messaging) zu etablieren. Das passiert vor allem dort, wo die IT das SOA-Thema vorantreibt. Es ist zu beobachten, dass SOA nun als Vehikel benutzt wird, um weitere Gelder für solche Bereiche loszueisen, wo der EAI-Hype nach der Einführung großer Middelware-Boliden zum Teil eher ernüchternde Ergebnisse gebracht hat und nicht mehr zieht. Die Festlegung auf ein unternehmensweit einheitliches Messaging, sei es ein Standard wie Java Messaging Service (JMS) oder gar ein Produkt, ist aus unserer Sicht nicht so entscheidend, mitunter sogar kontraproduktiv. Denn die Anforderungen an die Kommunikation können sehr unterschiedlich sein.

Warum sollte es daher verboten werden, Services innerhalb eines Containers, technisch etwa innerhalb einer Java Virtual Machine, direkt aufzurufen, also ohne den Overhead eines XML Mashalling? Was eigentlich vermieden werden soll, so referierte kürzlich Markus Völter, unabhängiger Softwarearchitekt, im Rahmen einer kritischen SOA-Betrachtung auf der Enterprise-Architektur-Konferenz in Wiesbaden, sind Abhängigkeiten bei der Implementierung der Geschäftslogik von Kommunikations- und Integrationsdetails. Denn diese Techniken (etwa MQ-Series, Tuxedo, Corba, Soap oder JMS) sind deutlich kurzlebiger als die Geschäftslogik des Unternehmens.

Abhängigkeiten vermeiden

Die Konsequenz kann also nicht sein, eine Kommunikationstechnik festzulegen und einzufrieren. Vielmehr ist es notwendig, durch einen geeigneten Entwicklungsprozess diese hinderlichen Abhängigkeiten zu vermeiden. Die Protagonisten der Model Driven Architecture (MDA) machen es vor: Die Geschäftslogik sollte plattform- und technologieunabhängig modelliert werden, die konkrete Implementierung sollte über plattformspezifische Modelle und Transformationen generiert werden. Wer seine Entwicklungsmethodik nicht gleich so radikal umstellen möchte, kann zumindest versuchen, erst bei Serviceaufrufen die Bindung an die konkrete Kommunikationstechnik zu generieren.

Was vielen unbekannt ist: Web-Services-Definitionen nach WSDL sind zunächst nicht an http/Soap gebunden. WSDL trennt die Definition der Services von der technischen Bindung an ein Protokoll. Interessant wäre also ein Framework, das es erlaubt, einen Serviceaufruf zu formulieren und dabei die Details der Kommunikation generieren zu lassen. Ein solches Framework gibt es im Open-Source-Lager mit Apaches "WebService Invocation Framework" (WSIF). Neben dem ganzen SOA-Hype scheint WSIF kaum beachtet zu werden. Allerdings mehren sich die Hinweise, dass diese Ideen in aktuellen SOA-Standards (hier JBI/JSR-208) wieder aufgegriffen werden. Web-Services mit Soap über http sind also nur eines von mehreren denkbaren Übertragungsprotokollen und keineswegs die unvermeidbare Grundvoraussetzung für eine SOA - und oft nicht mal die beste Wahl (siehe Kasten: "Empfehlungen für die Web-Services-Kommunikation").

Kommunikationsmuster

Neben der Kommunikationstechnik (Protokoll) bringt auch das Kommunikationsmuster Abhängigkeiten mit sich. Der Code für einen synchronen (blockierenden) Service-Call unterscheidet sich von einem asynchronen (nicht blockierenden) Aufruf, bei dem die Antwort später eintrifft. Kann und will man diese Abhängigkeiten in der Geschäftslogik akzeptieren? Nachdem Einvernehmen darüber besteht, dass eine formale Servicebeschreibung (Signatur) nebst Festlegung der Semantik der Services und ihrer Parameter notwendig ist, wird sich hier ein weiterer Festlegungsbedarf in einer SOA ergeben. Ohne diese Vorgaben muss man sich darauf einstellen, dass alle Spielarten auch genutzt werden (synchron blockierend, asynchron mit und ohne Quittungen, Notifications mit und ohne Quittungen). Da sich prinzipiell alle Muster auf allen Kommunikationstypen implementieren lassen, obwohl die Grundidee des Protokolls gelegentlich eine andere ist, sind die Kommunikationsmuster im Vorfeld als Teil einer SOA abzustimmen.

Java Business Integration (JBI, JSR 208), eine Standardisierungsbemühung der Java-Gemeinde, deren Nutzen eher umstritten ist, hat immerhin erkannt, dass man diese Kommunikations-Patterns definieren muss, da sonst keine Interoperabilität gewährleistet werden kann. JBI definiert folgerichtig ein Profil der unterstützten Muster.

Neben dem Aspekt der Kommunikation und des Messaging wird im Kontext von SOA heftig über Geschäftsprozesse diskutiert: Die Fachabteilungen sollen durch SOA in die Lage versetzt werden, selbst und möglichst ohne Zutun der IT Geschäftsabläufe zu implementieren - selbstredend grafisch, ohne Programmierkenntnisse. So weit die Versprechen der Hersteller. Mag sein, dass dies in Zukunft Realität werden kann, zurzeit ist man jedoch eher geneigt, von einer Fata Morgana zu sprechen. Wichtig ist allerdings, dass man bei der Konzeption einer SOA-fähigen Anwendung unterscheiden muss zwischen möglichst universellen, auf Wiederverwendung in unterschiedlichen Kontexten ausgelegten Services sowie der Verkettung dieser Services, also Workflows als oberster Verdrahtungsebene. Services sind demnach universell, stabil und wiederverwendbar ausgelegt, Workflows dagegen spezifisch für einen Kunden oder eine Anwendung konfiguriert und müssen flexibel änderbar sein. Daher ist unbedingt erforderlich, diese Schichten zu trennen, insbesondere dann, wenn projektübergreifende Lösungsbausteine und kunden- oder projektspezifische Anwendungsteile voneinander isoliert werden müssen. Die Praxis zeigt jedoch, dass die Workflows nie geändert werden, ohne dass es eines neuen oder geänderten Service bedarf.

Gründe für Workflow-Engines

Es gibt jedoch ein gutes Argument dafür, Workflow-Engines einzusetzen: Mitunter können Prozessketten nicht "am Stück" abgearbeitet werden. Beinhalten die Geschäftsprozesse Haltepunkte, an denen auf äußere Ereignisse gewartet werden muss, ist eine Workflow-Engine unverzichtbar. Insbesondere, wenn die Prozesse insgesamt länger laufen (Stunden oder gar Tage). Hier ist es aus zwei Gründen unumgänglich, den Kontext der Geschäftsprozess-Instanz persistent zu speichern. Es muss ein Recovery möglich sein, damit nach einem Wiederanlauf der Anwendung die Daten der noch offenen Prozesse nicht verloren sind. Zweitens geht es um den Ressourcenverbrauch, denn wenn viele offene Instanzen von Geschäftsprozessen verwaltet werden müssen, sollten sich diese nicht alle im Speicher mit allokierten Ressourcen befinden.

Ein Spezialfall von Prozessen mit Haltpunkten sind solche, die manuelle Bearbeitungsschritte, also die Interaktion von Anwendern enthalten. Prozesse, die in diesen Zustand kommen, werden dann in die Arbeitslisten eingereiht, die Sachbearbeiter an einem Frontend zur manuellen Abarbeitung präsentiert bekommen. Im Wesentlichen haben sich zwei relevante Standards für die Entwicklung und Ausführung von Workflow-Engines etabliert: die Business Process Execution Language (BPEL) und die XML Process Definition Language (XPDL). Hierfür eignet sich beispielsweise "WfMOpen", eine Open-Source-Implementierung für eine XPDL-Engine.

Open-Source-Komponenten lassen sich etwa über Standards zusammensetzen, die quasi den Kleber zwischen den Werkzeugen bilden können. So eignet sich XMI für Modelle, die ein Generator-Framework weiterverarbeiten kann. Dass die Werkzeuge in der Praxis gut zusammenpassen, liegt in der Struktur der Open-Source-Landschaft. Niemand tritt hier mit dem Anspruch an, eine Komplettlösung zu liefern. Man ist also darauf angewiesen, miteinander "zu können". Hier sind es die Quasi- oder Industriestandards, an denen man nicht vorbeikommt, wie Eclipse, das die verschiedenen Tools zusammenschweißt.

Vorsicht vor naivem Ansatz

Neben der Auswahl der passenden Technik und Tools ist es entscheidend, dass sich Unternehmen auf SOA und die Verwendung von Open-Source-Tools vorbereiten. Das hat mit dem naiv-visionären SOA-Ansatz (Programme erkunden das Netz, finden in Registries Servicebeschreibungen und erledigen ihre Mission, indem sie zur Laufzeit dynamisch diese Dienste zu komplexen Anwendungen verknüpfen) nicht viel zu tun. Bis eine IT clever genug ist, solche "Wunderwerke" zu erschaffen, sollte sie sich darauf konzentrieren, SOA in der Planung und Implementierung von IT-Strukturen für komplexe Aufgaben zu verstehen und zu testen.

Dabei liegt der Fokus auf der Designphase. Hier wird eher ein Dokumentations- und Diskussionsforum benötigt, in dem Teams ihre Erfahrungen und Lösungsansätze austauschen, Anforderungen klären und Inhalte (Semantik) von Diensten und Parametern dokumentieren können. Empfohlen wird eine Plattform, die alles bietet, was Lösungsarchitekten und -entwickler brauchen, um einen Baustein einsetzen zu können - ein "internes Corporate Wikipedia". Diese Online-Sammlung von Informationen, die sich dadurch auszeichnet, dass jeder unbürokratisch mitarbeiten und Beiträge leisten kann, unterstützt den Change-Prozess besser als ein UDDI. (ue)