Enterprise Service Bus steuert Services
Transparenz für SOA
Die Forderungen nach Flexibilität und Agilität haben die IT an ihre Grenzen geführt: Monolithische Systeme waren für die neuen Anforderungen zu starr, ihre Alternativen zu komplex. Mit der SOA scheint sich nun eine neue, businessorientierte Sichtweise durchzusetzen. Der Enterprise Service Bus (ESB) sorgt dabei für eine transparente Infrastruktur.
Die beste Zeit der IT war doch das Monolithikum. Damals beherrschten große, geschlossene Systeme
die Welt, Hard- und Software waren genau aufeinander abgestimmt, sodass zuverlässige und
hochleistungsfähige Anwendungen möglich waren, die kaum Wünsche offen ließen – zumal die Anwender
genügsam und die Kosten gewaltig waren. Seit etwa 15 Jahren hat sich jedoch das Klima für die
monolithischen Systeme massiv verändert. Die Unternehmen sahen sich mit neuen Herausforderungen
konfrontiert und zögerten nicht, diese an die IT weiterzureichen: verstärkte internationale
Aktivitäten, Unternehmenszusammenschlüsse und Ausgründungen, neue Geschäftsmodelle, neue
Kostenstrukturen, neue Organisationsformen, neue Technik – und alles ändert sich in immer kürzerer
Zeit. Um dies nicht nur abzubilden, sondern auch noch aktiv anzuschieben, muss die IT vor allem
eines sein: flexibel und agil. Also genau das, was die bewährten monolithischen Systeme wirklich
nicht sind.
Eine Zeit lang hat die IT versucht, sich aus der Affäre zu ziehen. Es gab beispielsweise kleine,
handlichere Monolithen, Maßanfertigungen für bestimmte Aufgaben, und es gab standardisierte
Monolithen, die man nicht anforderungsspezifisch entwickelte, sondern im fertigen Zustand
auslieferte und dann konfigurierte. Wo die Monolithen aufgelöst wurden, war der Preis der
Flexibilität allerdings eine kaum mehr zu beherrschende Komplexität, sodass oft nicht das
Leistungsniveau der alten monolithischen Systeme gehalten werden konnte. Außerdem waren die
verschiedenen Komponentenmodelle nicht miteinander kompatibel, sodass unternehmensübergreifende
Lösungen schwierig blieben. Unterdessen eilte die Unternehmenswirklichkeit der IT immer weiter
davon.
Eine Lösung zeichnet sich seit etwa drei Jahren ab, sie wiegt umso schwerer als nennenswerte
Gegenstimmen oder gar Gegenentwürfe, wie sie sonst fast jeden neuen Ansatz begleiten, im Grunde
ausgeblieben sind. Diese Lösung besteht nicht in einer – wieder einer – neuen Technik, sondern in
einem neuen Konzept von Software. Die serviceorientierte Architektur (SOA) schaut erstmals in der
IT nicht von der IT-Seite auf die Geschäftsprozesse, sondern blickt in die umgekehrte Richtung. Sie
löst Software in funktionelle Services auf, in gekapselte Komponenten, die sich jedoch nicht an
technischen Aspekten, sondern an den Geschäftsprozessen orientieren. Solche Services lassen sich
flexibel in Prozesse einbinden, und sie sind auf Grund durchgängiger Standardisierung weder an
räumliche noch an Unternehmensgrenzen gebunden.
Unternehmen können schnell auf neue Anforderungen reagieren, indem sie derartige Services neu
organisieren, sie eventuell ergänzen, im Wesentlichen aber bestehende Funktionen wieder verwenden.
Wobei anders als bei frühren Ansätzen bei der Wiederverwendbarkeit nicht der Kostenaspekt im
Vordergrund steht (stehen sollte), sondern die damit erreichbare Agilität. Da Services nach außen
nur über definierte Schnittstellen kommunizieren, wirken sich Änderungen der Software nur in einem
geschützten Bereich aus. Schlimmstenfalls steht der Service nicht mehr zur Verfügung, andere
Service laufen weiter. In einem monolithischen System kann die geringste Änderung zu unabsehbaren
Folgen führen.
Die SOA bringt in dieses Grundkonzept einige spezifische Leistungen ein:
Sie basiert auf den Standards der Webtechnik, auf WSDL, UDDI und SOAP. Damit
bietet die SOA weltweite Interoperabilität – zwei Unternehmen können auf dieser Basis ihre
Anwendungssysteme mit erheblich weniger Aufwand verlinken, etwa im Rahmen einer
unternehmensübergreifenden Supply-Chain.
Die Services sind nur lose über ihre Schnittstellen gekoppelt, sie lassen sich
also bei Bedarf in neuen Kontext neu arrangieren; damit erreicht man ein ganz neues Niveau an
Flexibilität.
Die Services können auch von Dritten, zum Beispiel von Geschäftspartnern,
genutzt werden, sodass sie als Hebel der Integration wirken.
Im Rahmen der SOA lassen sich auch vorhandene Systeme einbinden, sodass
bestehende Algorithmen, etwa aus Legacy-Systemen, weiter arbeiten können. Damit kann die
Investition in die monolithische Welt zumindest teilweise erhalten bleiben.
Aus dem grundlegenden Business-Aspekt der SOA lässt sich für die Granularität, also wie grob-
oder feinkörnig Services zu definieren sind, zumindest Anhaltspunkte ableiten. Services sollten
mehr sein als rein technische Komponenten, wie sie etwa im Corba-Umfeld (Common Object Request
Broker Architecture) üblich waren. Sie enthalten also nicht nur einen Druckeraufruf und eine
Datenbankanfrage, sondern können bei Bedarf einen kompletten Geschäftsprozess umfassen, zum
Beispiel eine Schufa-Abfrage. Dabei ist es eine ziemlich akademische Frage, ob so eine
Schufa-Abfrage ihrerseits überhaupt ein Geschäftsprozess ist oder nur Teil eines Prozesses namens
Kreditgewährung. Services können eben Prozesse und/oder Subprozesse umfassen – wichtiger ist, dass
eine derartige Abfrage auch in einem anderen Kontext gestellt werden kann oder aber dass ihre
Algorithmen innerhalb der bestehenden Prozesse neu definiert werden, ohne dass die gesamte
Prozesskette zu behandeln ist. Die Änderung des Services endet hier genau an seiner
Schnittstelle.
Keine SOA ohne ESB
Dennoch, auch wenn einzelne Geschäftsprozesse als Services dargestellt werden, wird ein
Unternehmen, das seine Software auf Basis der SOA organisiert, schnell ein paar tausend Services
ansammeln. Soll die bessere Ausrichtung auf wirtschaftliche Anforderungen nicht erneut in einer
ausufernden Komplexität untergehen, benötigen die Services eine Infrastruktur, die ihre
Kommunikation regelt und überwacht. Diese Infrastruktur stellt der Enterprise Service Bus (ESB) zur
Verfügung. Er bietet ein Medium, einen dynamisch konfigurierten Nervenstrang, über das die Services
jene inhaltliche und statusbezogene Informationen austauschen, die sie überhaupt erst befähigen,
ihre jeweiligen Funktionen auszuüben. ESB stellt den Service an den richtigen Platz, "passt auf",
dass er dort bleibt und was er macht. Dabei erstreckt sich der ESB über Cluster und
Sicherheitsinfrastrukturen hinweg und bildet eine verteilte Umgebung, die an jedem Punkt verwaltet
werden kann. Anders ausgedrückt: ESB macht SOA transparent.
Leistungen der Infrastruktur
Die Services werden über den ESB flexibel und dynamisch verbunden, es müssen keine Verbindungen
programmiert werden; diese Verbindungen erfolgen im Wesentlichen asynchron auf Basis des
Messaging-Konzepts. Der ESB besteht seinerseits aus verschiedenen Komponenten. Sie sorgen zum einen
für die Verbindung zwischen Infrastruktur und Services. Zum anderes verfügt der ESB über eigene
Services, die das Management der Infrastruktur übernehmen und die Kommunikation der Services
steuern und kontrollieren. Dazu gehören:
Servicekommunikation: Über eine robuste und skalierbare Datenübertragung sind
Services unterschiedlicher Herkunft und Technik, also beispielsweise ERP-Systeme, Webservices,
J2EE-; Dotnet- oder Legacy-Applikationen im gesamten Unternehmen verbunden.
Servicevermittlung: Der Abgleich zwischen nicht kompatiblen Protokollen,
Datenformaten und Interaktionsmustern erleichtert eine flexible Kombination verbundener Services.
Das konfigurationsgesteuerte Design beseitigt unflexible, hart kodierte Serviceabhängigkeiten,
sodass sich Änderungen ohne Unterbrechung des Betriebs dynamisch vornehmen lassen.
Serviceorchestrierung: Die Modellierung von Prozessen und die Automatisierung
von langfristigen, zustandsabhängigen Transaktionen sowie komplexen Datenflüssen ermöglicht ein
umfassende Management von Geschäftsprozessen. Menschliche Arbeitsprozesse (human interaction) sowie
alle mit dem ESB verbundenen IT-Ressourcen sind zu einem koordinierten und geregelten
Geschäftsprozess zusammengefasst.
Serviceinstallation und -administration: Die verteilte Infrastruktur macht
einen zentralen Hub überflüssig, dennoch erfolgen Installation, Administration und Überwachung
zentral. Die Services können unabhängig voneinander skaliert, konfiguriert und installiert
sein.
Operative Datenservices: Die Benutzer können alle aktuellen Betriebsdaten
kontrollieren, auswerten und in Formaten wie XML weiterverarbeiten. Damit sind auch die
Dokumentation und ein lückenloses Auditing sichergestellt.
Lesen Sie mehr zum Thema
