Ziel einer Service Oriented Architecture (SOA) ist eine hochflexible Applikations-Infrastruktur, die an wechselnde Anforderungen anpassbar ist. Die Technologie wiederverwendbarer Services ist aber nur der Anfang. Der Mehrwert entsteht erst durch die effektive Steuerung der darauf aufbauenden Geschäftsprozesse. Das grundlegende Modell einer service- oder auch komponentenorientierten Architektur scheint auf den ersten Blick so neu nicht. Bisherige, weitgehend proprietäre Lösungsansätze konnten jedoch das Versprechen einer flexiblen Architektur nicht einlösen. Konzeptionell sind in einer komponentenorientierten Architektur die wesentlichen Funktionen einer Applikation als Software-Einheiten organisiert, die über Schnittstellen für andere Systeme zugänglich gemacht werden.
Als typische Vertreter solcher frühen SOA-Ansätze gelten Microsofts Komponentenmodell COM/DCOM oder auch der objektorientierte Kommunikationsstandard CORBA. Beide verbuchten jedoch kaum mehr als Teilerfolge. Während CORBA zu komplex war, die Objekte zu stark miteinander verzahnte und viele Hersteller ihre „eigenen“ CORBA-Varianten erstellten, konnte COM/DCOM letztendlich die Hürde der Plattformabhängigkeit nicht nehmen.
Abbildung 1: Der Geschäftsprozess RFQ (Request for Quotation; die Aufforderung, ein Angebot abzugeben) greift im Rahmen einer SOA-Architektur auf vorhandene ERP- und CRM-Applikationen zurück und verpackt sie zu einem neuen Service. (Quelle: Vitria)
Abbildung 2: Ein lang laufender Geschäftsprozess wie Order Fulfillment kann als Set von Services bereitgestellt werden. (Quelle: Vitria)
Im Vergleich zu DCOM und CORBA versprechen Web-Services den Aufbruch zu neuen Horizonten. Auf Grund allgemein akzeptierter Internet-Standards ermöglichen sie auch die Integration von Applikationen, die früher nur schwer einzubinden waren. Das Prinzip der Web-Services ist einfach: Ein Service-User (Client) fordert von einem Service-Provider (Server) Dienste an, die dieser durch die Abarbeitung bestimmter Funktionen bereitstellt. Wichtig dabei ist, über welche Eigenschaften Web-Service-User und Web-Service-Provider verfügen müssen, damit beide sich verstehen.
Für die Kommunikation zwischen beiden führt das Modell der Web-Services-Funktionen ein, damit der Server seinen Dienst über die XML-basierte Beschreibungssprache WSDL (Web Service Description Language) zur Verfügung stellt. WSDL kümmert sich – unabhängig vom darunter liegenden Kommunikationsprotokoll – um die Definition einer strukturierten Form der Kommunikation. Die WSDL-Spezifikation geht von einer abstrakten Interaktion zwischen Service-Provider und Service-User aus, bei der Provider und User Nachrichten übermitteln. Jede Message verfügt über strukturierte Inhalte. Einzelne Übertragungen oder auch einzelne Nachrichten haben die Form von Operationen – konkretisiert als Funktionsaufruf mit Rückgabewert.
Eine serviceorientierte Infrastruktur ist mehr als Web-Services
Web-Services liefern damit eine geeignete Technologie, um serviceorientierte Architekturen zu realisieren. Die Gleichung „SOA = Web-Services“ ist jedoch unzulässig. Denn Service-orientierte Architekturen lassen sich auch mit anderen Technologien wie CORBA oder Enterprise Java Beans implementieren.
Eine SOA ist weniger eine Technologie, sondern vielmehr ein konzeptionelles Modell zur effizienten Realisierung komplexer IT-Infrastrukturen. Dieser umfassendere Ansatz lässt sich an Hand einiger Kernmerkmale beschreiben:
• Von einem Service (einer Software-Einheit) existiert jeweils nur eine Instanz.
• Services sind untereinander lose gekoppelt. Damit sie mit anderen Komponenten effizient zusammenarbeiten können, müssen sie „eigenständig“ sein.
• Der Nachrichtenaustausch zwischen Services sollte so einfach wie möglich und deskriptiv sein sowie XML-Dokumente und XML-Schemata nutzen; diese sind deutlich flexibler als herkömmliche Remote Procedure Calls.
• Wo immer es möglich ist, sollten Services zusätzlich zu synchronem auch asynchrones Messaging beherrschen, um so langlaufende Geschäftsprozesse zu unterstützen.
In mancherlei Hinsicht erinnert eine SOA an den industriellen Fertigungsprozess. Insbesondere im Automobilbau setzen Unternehmen bei der Produktplanung und -entwicklung auf die System- und Modulbildung. Als Module gelten komplette und funktionsfähige Komponenten, die einbaufähig geliefert werden. Ein Bremssystem, die Klimaanlage oder der Fahrzeugantrieb entstehen, indem Funktionen aus mehreren Baugruppen, Komponenten und Modulen zusammenwirken. Derartige Standardkomponenten – die ja auch typisch sind für weite Teile einer Service-orientierten Architektur – lassen sich auftragsneutral vorfertigen. Die auftragsabhängigen Bausteine (beim Automobil beispielsweise die Ausstattung, die Farbe und das Zubehör) müssen abhängig von bestimmten Ereignissen individuell geordert werden.
Einer der großen Vorteile von Web-Services besteht darin, dass sie unabhängig von Programmiersprachen sind. In dieser Sichtweise ähneln sich die Zielsetzungen von Web-Services und CORBA (Common Object Request Broker Architecture). Beide befassen sich mit verteilten Applikationen. Während CORBA auf die Interface Definition Language (IDL) setzt, bauen die Web-Services auf das XML-basierende SOAP (Simple Object Access Protocol) auf. Allerdings müssen die im Rahmen von CORBA implementierten Dienste bereits während der Entwicklung einer Applikation hart kodiert werden, die SOAP-Aufrufe dagegen erfolgen erst zur Laufzeit. Dies macht SOAP weit flexibler. Solange ein Web-Service die SOAP-Message (das XML-Dokument) erfassen kann, spielt es für ihn keine Rolle, auf welcher Plattform der Service entwickelt wurde und nun abläuft. Auch wenn CORBA in komplexen Anwendungsszenarien noch immer leistungsfähiger als Web-Services ist, hat es sich wegen seiner Schwerfälligkeit nie als breit unterstützter Standard durchgesetzt. Während heute nahezu jeder Anbieter von Business-Software die wichtigsten Web-Services-Protokolle unterstützt, bietet kaum einer standardisierte CORBA-Schnittstellen, um seine Applikationen mit anderen zu verbinden.
Solch eine ereignisgesteuerte Konstellation lässt sich recht gut mit einer asynchronen, lose gekoppelten SOA abbilden und letztlich auch steuern. Voraussetzung dafür sind Methoden und Verfahren, um die Nachricht (eine Message) vom Auftreten eines bestimmten Events zu veröffentlichen beziehungsweise empfangen zu können – mit dem Fachterminus: Publish and Subscribe.
Abbildung 3: Business Process Management ermöglicht die Einbindung verschiedener Architekturmodelle: asynchron, synchron und Batch-orientiert. (Quelle: Vitria)
Eine derartige Nachrichteninfrastruktur wie sie die Integrationsplattform Vitria:BusinessWare mit ihrer Communicator-Komponente bietet, sorgt für eine Übertragung von Daten in einem konsistenten Format über Kommunikationskanäle (Channels). Als Backbone für die Nachrichtenübertragung kommt es auf eine hohe Servicequalität durch Service Level Agreements (SLAs), garantierte Leistung, vollständige Transaktionsverarbeitung, Persistenz der Daten und geordnete Datenwiederherstellung an. Durch eine zielgerichtete Erweiterung werden so aus Integrationsplattformen, die ihre Praxistauglichkeit bereits im EAI-Umfeld unter Beweis gestellt haben, moderne Service-orientierte Architekturen.
Abbildung 4: Das konzeptionelle Modell von Web-Services, bei dem ein Client die Services einer anderen Applikation aufruft. (Quelle: Vitria)
Ein ereignisgesteuertes Modell innerhalb einer SOA sollte langlaufende Transaktionen unterstützen, bei denen im zeitlichen Ablauf von Geschäftsprozessen wie einer Auftragsbearbeitung eine Vielzahl von Events zu analysieren und miteinander zu verknüpfen sind. Resümee: Eine serviceorientierte Architektur baut in vielerlei Hinsicht auf den EAI-Fundamenten auf und erweitert sie um moderne Technologien wie Web-Services. Die synchrone, häufig serviceorientierte Einbindung von Web-Services wird dabei um eine asynchrone ereignisgesteuerte Integration ergänzt.
SOA als Design-Prinzip
Serviceorientierte Architekturen bilden zentrale Orientierungsmuster für Integrationsvorhaben. Eines der wichtigsten Prinzipien dabei ist, mit einem möglichst geringen Aufwand eine höchstmögliche Flexibilität bei der Integration zu erreichen. Daher sind auch die Bemühungen um die Standardisierung von SOA im Rahmen der Web-Services so wichtig.
Die Integrationsarbeit ist aber nicht dadurch gelöst, dass eine serviceorientierte Architektur zum Leitprinzip erkoren wird. Vielmehr beginnt dann erst die Arbeit, denn die Herausforderung lautet: Wie kann eine bestehende Systemlandschaft in eine Service-Architektur überführt werden? Häufig sind die bestehenden Systeme nämlich noch gar nicht servicefähig. Hier bleibt auch weiterhin die Aufgabe, eine Integration der bestehenden Applikationen zu erreichen. Die Vorgabe lautet nun, die Anwendungen einem übergeordneten Prozessablauf als Ressource (Service) bereitzustellen.
Abbildung 5: Der Order Request eines Client stößt einen in mehrere Web-Services untergliederten Prozess an. (Quelle: Vitria)
Die dazu notwendigen Techniken und Methoden stellt ein Integrationsserver wie Vitria:BusinessWare bereit. Gerade die Kombination aus Service- und Message-basierter Integration liefert den Mehrwert. Web-Services bieten sich hier als hervorragende Lösung für Fragen rund um Low-Level-Connectivity-Probleme an. In dieser Perspektive stellt eine serviceorientierte Architektur ein Umdenken in der Entwicklung von Anwendungen dar. Die Schaffung von Software-Komponenten, die als Dienste über ein standardisiertes Interface universell eingesetzt werden können, bietet eine Reihe von Vorteilen.
Einer der zentralen Punkte ist die Flexibilität beim Aufbau einer Integrationslösung durch Konzentration auf den Geschäftsprozess. Durch die Kapselung einer bestehenden Systemlandschaft als Service ist zugleich ein höherer Grad an Wiederverwendung gewährleistet. Zugleich ergibt sich damit die Möglichkeit, Änderungen im Organisationsablauf von Prozessen schneller umsetzen zu können. Um weitgehend standardisierte Integrationsaufgaben zu implementieren, bietet sich der Einsatz vorkonfigurierter Lösungen an. Beispiele dafür sind Straight Through Processing für die Wertpapierabwicklung, Integrated Order Management für Telekommunikationsanbieter oder Lösungen für die Abwicklung von Schadensmeldungen in der Versicherungsbranche. Abgerundet wird eine umfassende SOA, die sich nicht nur auf den Einsatz der Web-Services beschränkt, durch die Nutzung einer Geschäftsprozess-Automatisierung und -Steuerung, die unabhängig von den ausführenden Systemen ist. Durch diese Entkopplung wird eine höhere Flexibilität bei der Umsetzung von Integrationslösungen erreicht.
Fachautor: Thomas Egeling ist Systems Engineer bei Vitria Technology
