SOA auf Basis von Open-Source leicht gemacht

Bleibt Variante drei: Open-Source-Software bietet ausreichend Kandidaten, um einen SOA-Baukasten zu gestalten. „Die Produkte fußen auf Standards, die heute eine Vielzahl von Referenzen nachweisen können“, wie Danet-Mann Görg erklärt. Dass die Qualität und die Zuverlässigkeit von Open-Source-Software hoch sind, hat eine Untersuchung der Standford-Universität zu Beginn dieses Jahres gezeigt: „Das Viele-Augen-Prinzip, beim der Quellcode von zahlreichen Entwicklern begutachtet, geprüft und optimiert wird, ist 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, wie auch IT-Architekt Görg weiß: „Es ist zunächst darauf zu achten, welche Aufgabenstellung es zu lösen gilt und welche Komponenten dazu benötigt werden. Wie wählt man die aus und integriert sie? Diese Fragen müssen beantwortet werden. Notwendige Elemente einer SOA sind aus Sicht der Softwarehersteller ESB, WebServices, (UDDI) Registry und eine Workflow-Engine. Nach der Meinung von Görg ist keine dieser Bausteine zwingend für eine SOA.

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 dort loszueisen, wo der EAI-Hype nach der Einführung großer Middelware-Boliden zum Teil eher ernüchternde Erfahrungen gebracht hat. Die Festlegung auf ein unternehmensweit einheitliches Messaging – sei es ein Standard wie Java Messaging Service (JMS) oder sogar ein Produkt -, sei laut Görg jedoch nicht entscheidend – mitunter sogar kontraproduktiv. Denn die Anforderungen an die Kommunikation können sehr unterschiedlich sein.

Die Geschäftlogik sollte plattform- und technologieunabhängig modelliert werden (PIM), und konkrete Implementierungen sollten über plattform-spezifische Modelle (PSM) und Transformationen generiert werden. Wer seine Entwicklungsmethodik nicht gleich so radikal umstellen möchte, kann zumindest versuchen, bei Serviceaufrufen die Bindung an die konkrete Kommunikationstechnik zu generieren. Was vielen unbekannt ist: Web-Services-Definitionen nach WSDL sind erst mal nicht an HTTP/SOAP gebunden. Vielmehr trennt WSDL die Definition der Services von der technischen Bindung an ein Protokoll. Interessant wäre jetzt ein Framework, das es erlaubt, einen Service-Aufruf zu formulieren und dabei die Details der Kommunikation generieren zu lassen. Einen solches Framework gibt es im Open-Source-Lager: 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.

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äftsprozesse zu implementieren. Selbstredend grafisch, ohne Programmierkenntnisse. So weit die Versprechen der Hersteller. „Mag sein, dass dies in Zukunft Realität werden könnte – zurzeit ist die Vision in der Praxis eher eine Fata Morgana“, wie Lösungsarchitekt Görg erklärt. Wichtig ist allerdings, dass man bei der Konzeption einer Anwendung in einer SOA unterscheiden muss: einerseits zwischen möglichst universellen, auf Wiederverwendung in unterschiedlichen Kontexten ausgelegten Services und anderseits der Verkettung dieser Services, also Workflows, als oberster Verdrahtungsebene.