Mit der Service-oriented Architecture verbindet sich ein Designkonzept, das sich vor allem mit der Interoperabilität von Anwendungen und Diensten beschäftigt. SOA ist kein weiterer IT-Standard, sondern schließt vielmehr zahlreiche vorhandene Standards und Technologien ein. Auch vereint sie wichtige Ansätze und Erfahrungen mit verteilten Objekttechnologien der letzten zwanzig Jahre. Anders als die meist schwammig formulierten und in der Praxis oft ineffzienten Ansätze für Enterprise Application Integration (EAI) soll SOA dem Thema Anwendungsintegration zu mehr Präzision verhelfen sowie ergebnissicherer und praxistauglicher sein. Hersteller und IT-Ingenieure treiben daher die SOA-Debatte seit einiger Zeit voran.
Bei IT-Managern stößt SOA indes auf Misstrauen - zu groß ist die Zahl der in den letzten Jahren erst gepriesenen und dann gescheiterten IT-Allheilmittel. Zu dicht liegen oft Innovationen und Hype beieinander. Wenig hilfreich ist es da, wenn Experten, aber auch manch falscher Prophet, SOA als völlig neuen Ansatz propagieren. Auch schießen wie schon zur Hochkonjunktur von EAI neue SOA-Anbieter wie Pilze aus dem Boden, oder bestehende Unternehmen werden zu SOA-Spezialisten umfunktioniert. Nur gut vorbereitete IT-Mitarbeiter können in dieser zunehmenden Vielfalt noch den langfristigen Nutzen von Produkten in einer spezifischen Situation beurteilen.
Das Durcheinander ist bedauerlich, bedeutet SOA doch einen signifikanten Fortschritt, weil sie Bewährtes konsolidiert und verständlich erklärt. Sie zwingt nicht nur Hersteller, bisherige EAI-Ansätze zu vereinen, sondern bündelt vor allem das Know-how von Unternehmen, die schon lange vor der EAI-Welle SOA-Designansätze und entsprechende Standardtechnologien erfolgreich nutzten. So machte die ABB Kraftwerksleittechnik bereits 1995 verschiedene spezialisierte, lokal eingesetzte Systeme ihrer verteilten Forschungszentren global verfügbar. Hier kam eine Trader- oder Broker-Plattform zum Einsatz, die mittels Corba-Services (Corba = Component Object Request Broker Architecture) erstellt wurde und deren Architektur heute mit Fug und Recht als SOA-konform bezeichnet werden kann, nur dass dieser Designansatz damals Distributed Object Computing (DOC) hieß. Ebenso setzt eine der weltgrößten Banken seit vielen Jahren eine SOA auf Corba-Basis ein, die sogar diverse Mainframe-Systemdienste transparent als SOA-Service einbindet.
SOA-Ansätze finden sich auch in Behörden, Logistikunternehmen und Industriefirmen, die entsprechende Architekturen auf Corba-, J2EE- und EAI-Basis mit Produkten unterschiedlicher Hersteller (zum Teil sogar im selben Unternehmen) erfolgreich umgesetzt haben.
Ein weiteres Beispiel ist die "Integrated Application Platform", die die ITI/TP-Gruppe von Daimler-Chrysler als Trägerplattform für alle künftigen Individualanwendungen entwickelt hat. Mit dem Projekt gehörte das Unternehmen 2004 zu den Gewinnern des Wettbewerbs "Anwender des Jahres" der computerwoche (ausführlich siehe CW 48/04, Seite 34 oder unter www.cowo.de/go/68032).
Oberstes Ziel: Interoperabilität
Technisch entspricht eine SOA einem IT-Architekturstil mit klar formulierten Vorgaben (Vision) und verschiedenen definierten Eigenschaften, sinnvollen Rahmenbedingungen und Einschränkungen. Oberstes Ziel einer SOA ist die Interoperabilität von Anwendungen und Diensten und dadurch auch die Vermeidung von problematischen Daten- und Funktionsredundanzen. Nach diesen Richtlinien werden neue Anwendungen von Grund auf entwickelt beziehungsweise bestehende gekapselt, um die wesentlichen Bestandteile interoperabel und SOA-konform zu gestalten.
Eine allgemeine Servicedefinition, die Daimler-Chrysler beispielsweise in Form eines Blueprints vornahm, dient als Basis für alle Varianten von installierbaren Fachanwendungen wie Web- oder Rich-Client-Anwendungen sowie fachlichen Servicekomponenten wie beispielsweise Diensten zur Prozesssteuerung und für Batch-Verfahren. Diese Servicedefinition entspricht einer standardkonformen Vier-Schichten-Architektur und kann deshalb mittels der Java 2 Enterprise Edition (J2EE) oder .NET implementiert werden, einschließlich der Kapselung existierender Systeme.
Die fachspezifischen, dynamischen Aspekte einer Anwendung liegen in einer klar lokalisierbaren, eindeutig definierten Prozesslogik vor, die eine saubere Trennung der Fachprozessflüsse und atomare Dienste ermöglicht sowie eine Basis für eine Gestaltung und Visualisierung durch Modelle bietet: SOAs sind prozesszentrisch. Die so entstehenden Services sollen beliebig verteilbar, lose gekoppelt, nachrichtengesteuert und dynamisch austauschbar sein entlang einem Softwarebus, der in unserem Beispiel ein Information Broker ist.
Selbstverständlich ist die Entwicklung, Einführung und Pflege einer SOA mit Aufwand verbunden. Dieser rechnet sich jedoch, wenn man die Anzahl von Verbindungen zwischen Systemen mit und ohne SOA betrachtet. Bei einigen wenigen Services oder Systemen ist die direkte Kopplung sicher einfacher als die Einführung einer SOA. Die Erfahrung zeigt, dass es etwa zehnmal mehr kostet, einen einzelnen Dienst als SOA-Service zur Verfügung zu stellen, als eine einfache Direktverbindung zwischen Diensten. Aber schon ab sechs zu verbindenden Systemen und bei wachsender Zahl der Dienste kann SOA erheblich kostengünstiger sein.
Dienste lassen sich austauschen
Ein angenehmer Nebeneffekt von sauber implementierten SOA-Systemen gegenüber Direktverbindungssystemen ist ihre Zustandslosigkeit - jede Nachricht (Message) zwischen SOA-Services ist unabhängig von vorhergehenden Nachrichten. Dies hat unter anderem den erheblichen Vorteil, dass SOA-Services leicht ausgetauscht und dynamisch skaliert werden können. Dadurch sind die Hardwareanforderungen bei SOA deutlich geringer (Ausfallsicherheit, Skalierbarkeit): Umfassende SOA-Systeme müssen nicht auf großen Rechnern oder Mainframes, sondern können auf einer Anzahl von vernetzten Standard-Servern laufen (Load-balanced Cluster). Außerdem lässt sich SOA mit vielen unterschiedlichen Technologien aufbauen. Darin liegen ihre Vorteile, aber eben auch ihre Risiken und Nebenwirkungen - der Mehrwert, den hier ein erfahrener IT-Architekt schafft, ist wie so oft der entscheidende Faktor.