Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

20.01.2005

Software ist ein Service

Richard Hubert
Service-orientierte Architekturen (SOA) sollen die Grundlage für flexiblere, dynamisch konfigurierbare Software-Infrastrukturen der Zukunft bilden.

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.

Von Vorteil ist es da, dass viele SOA-Elemente den Experten seit Jahren vertraut sind. So kann der erfahrene IT-Architekt dann auch die wichtigen Kompromisse, Designnuancen, Risiken und Chancen einer SOA erklären. Aber sein eigentlicher Job wird auch künftig darin bestehen, in der jeweiligen Situation die unterschiedlichsten Einflussfaktoren präzise zu ermitteln und dann die für den Anwendungsfall und Kunden optimale Lösung zu finden. Dabei ist beispielsweise zu klären, wie die Services zuzuschneiden sind, um die Komplexität - die größte Problemquelle - zu verringern. Und das ist nur einer von vielen Faktoren, die der IT-Architekt berücksichtigen muss. Grundsätzlich ist für den Projekterfolg eine realistische Herangehensweise ebenso entscheidend wie erfahrene IT-Architekten und geschulte Teams. Wegen der Unterschiede zu traditioneller Softwareprogrammierung ist es zudem ratsam, sich gemeinsam mit Werkzeugexperten zunächst ein Verständnis für die Entwicklung und Pflege von SOAs zusammen zu erarbeiten, um das Projekt auf eine stabile Basis zu stellen. (as)