SOA verpasst Betriebssystemen den Todesstoß

IT-Manager und Techniker werden sie gleichermaßen lieben: Die Service-orientierte Architektur, kurz SOA. Denn SOA soll IT-Träume wahr werden lassen: Flexibilität, Wiederverwendbarkeit, Einfachheit, Wartbarkeit, Universalität, Integrität, Konsistenz – und alles für weniger Geld als jede Alternative. Das gibt es doch gar nicht? “Doch”, sagt Anne Thomas Manes, Analystin der Burton Group, die bis ins Detail aufzeigen kann, wie ein Unternehmen dorthin gelangt. Das bewies sie auch dem Publikum im Januar auf der Münchner Entwicklerkonferenz OOP.
Vor dem ersten Schritt jedoch steht eine Definition. SOA ist zu begreifen als eine Architektur, in der Funktionen aus dem Geschäftsleben als Set vielfach nutzbarer Services dargestellt sind, eine Art Design-Stil. Spezifische Techniken, Programmiersprachen, Applikationen sind dafür unnötig. Aber: Web-Services bieten sich als Integrationstechnik an, weil diese auf standardisierten Internet-Formaten und -Protokollen beruhen. Die sind frei verfügbar und daher kostengünstig zu verwenden.

Web-Services können der Einstieg sein

Web-Services nutzen den Informationsraum zwischen miteinander verbundenen Ressourcen, sind selbst eine Web-Ressource und über die URLs (Universal Resource Locator) zu finden. Eine Applikation bietet als Service anderen ihre Funktionalität zur Benutzung über eine Web-Schnittstelle an. Diese kann von verschiedenen Anwendungen in unterschiedlicher Weise genutzt werden, zum Beispiel eine Bestellung: Der Kunde ordert Ware aus dem Internet-Store, der Außendienstmitarbeiter einen Statusbericht über das Vertriebsportal, der Buchhalter verlangt nach Analysen seiner Zahlen aus der Tabellenkalkulation und das Marketing nach Details aus einer Kundenhistorie. Bei der herkömmlichen applikationszentrierten Vorgehensweise verfügte jede Anwendung über eine eigene Bestellroutine. Ein Bestellservice erübrige es, so Manes, das Rad jedes Mal neu zu erfinden. Nur so erklärt sich die Devise des Chief Information Officer (CIO) einer großen Bostoner Bank: Nichts wird zweimal entwickelt.

Die Mehrfachnutzung wird ermöglicht durch eine Abstraktionsschicht, die zwischen dem Service-Interface und dem Code liegt, der den Service implementiert. Es handelt sich um eine Art Vertrag, der maschinenlesbar ist und das Interface definiert, das den Client-Code generiert. Angesiedelt ist dieser Kontrakt beim Service-Provider, der den Service anbietet. Er enthält quasi die Bedingungen, unter denen sich der Service-Kunde andocken kann, also ein ‘bind’ zustande kommt. ‘Lose Kopplung’ heißt dieses Prinzip, das erlaubt, dass sich der Code hinter dem Vertrag ändern kann, ohne dass die Verbindung unterbrochen wird. Neben den Rollen des Service-Providers und des Service-Kunden gibt es noch eine dritte, die des Service-Brokers, des Vermittlers. Der Service-Provider meldet dort seine Funktion an, der Service-Kunde fragt dort Funktionen ab. Den Rollen entsprechen keine handelnden Personen, sondern interagierende Programme.

Dreierkiste mit Vorteilen

Die Vorteile dieser Dreiecksbeziehung liegen laut Manes auf der Hand. Die Anzahl an Funktionen reduziert sich und damit auch der Aufwand für die Erstellung und Wartung. Zugleich erhöht sich die Konsistenz; statt vieler potenzieller Fehlerquellen gibt es nur noch wenige. Zugleich erlaubt die Abstraktion von Code schneller und einfacher durchzuführende Änderungen. Schließlich ersetzen Nutzungsregeln, etwa darüber, wie ein Security-Service zu verwenden ist, harte, in eine Applikation eingebrannte Codierung.

So manch einer dürfte sich bei der bisherigen Beschreibung an frühere objektorientierte Architekturen erinnert fühlen: Common Object Request Broker Architecture (Corba) von der Object Managment Group (OMG), Distributed Common Object Model (DCOM) von Microsoft, Remote Method Invocation (RMI), Java Enterprise Edition Version 2 ( J2EE), Remote Procedure Call (RPC) und Distributed Computing Environment (DCE). Tatsächlich können diese Infrastrukturen Services unterstützen, aber an spezifische Technik oder sogar an den durchgängigen Einsatz von Produkten eines Herstellers gebunden. Obwohl Corba ein OMG-Standard ist, haben sich die Anwender entweder an IBM oder Iona oder Borland binden müssen.

DCOM beispielsweise nutzt das DCE-RPC-Protokoll. Die Kommunikation funktioniert mit Hilfe von TCP/IP (Transmission Control Protocol/Internet Protocol) und nutzt einen vordefinierten Port für den Erstkontakt. Für jede weitere Interaktion aber werden die Ports dynamisch angewiesen. Das aber verursacht Probleme, wenn die Kommunikation über Unternehmensgrenzen, also über Firewalls hinweg stattfindet. Auch Corba und RMI funktionieren ähnlich.

Die Schlüsseltechniken, mit denen sich Web Services implementieren lassen, sind inzwischen hinlänglich bekannt: das Datenaustauschformat Extended Markup Language (XML), die XML-Schemata, mit denen sich beschreiben lässt, was für Nachrichten zwischen den Services hin- und her gehen, das Simple Object Access Protocol (Soap), sowie die Beschreibungssprache für die Erstellung der Interfaces (WSDL).

Web-Service-Systeme kommunizieren mit Hilfe von XML und nutzen zumeist Soap. Das heißt, die Soap-Requests sind in Text eingebettet, die im Gegensatz zu Binärinformationen leicht eine Firewall passieren. Zudem basiert die Kommunikation auf HTTP (HyperText Transfer Protocol)  über TCP/IP statt, nutzt also einen bereits definierten Port.

Ein Service-Framework entsteht

Ein Web-Service-Framework basiert somit auf bekannten und weit verbreiteten Internet-Infrastruktur-Komponenten wie TCP/IP, Domain Name System (DNS) und URLs. Zudem lassen sich RPC-Features mit solchen aus Message-orientierter Middleware (MOM) mischen. Diese Flexibilität und der einfache Umgang damit prädestinieren Web-Services für verschiedene Aufgaben: Punkt-zu-Punkt-Verbindungen, Einbindung in Portale, Enterprise Application Integration (EAI), Business Process Management (BPM) und Workflow – auch im Zusammenhang mit Knowledge-Management, im Reporting und bei der Analyse.

Um jedoch eine Service-Architektur aufzubauen, bedarf es der Registrierung bei einem Broker. Diese Vermittlerfunktion übernehmen UDDI-Mechanismen (Universal Discription Discovery and Integration). Dadurch funktioniert der automatische Abruf durch andere Web Services. “Ohne UDDI bleiben Web-Services bloße Middleware”, stellt Manes klar. Das Verzeichnis ist selbst ein Web-Service, der auf andere referenziert.

Einschränkungen gibt es dennoch, muss auch die Analystin einräumen. So gelten öffentliche UDDI als unsicher und ungeprüft. Zum Beispiel gelangte man beim Aufruf von Oracle-Services nicht auf die angegebenen, sondern auf Porno-Seiten. Sie rät zum Aufbau privater Registraturen, die von Geschäftspartnern oder von Konzernen gepflegt werden. Allerdings erweisen sich die öffentlichen UDDIs als die Plätze, an denen etwa semantische Branchenstandards wie HRXML für den Bereich Human Ressource hinterlegt und abgerufen werden.