Ein Paradigma in der IT (Teil 1)
von Christoph Jeggle, PMP, CDIA+, E-Mail: Christoph.Jeggle@PROJECT-CONSULT.com. Christoph Jeggle ist Seniorberater bei PROJECT CONSULT. SOA, die Service Oriented Architecture, ist in der IT-Welt in aller Munde. Häufig wird sie nur als neue Technik betrachtet und nicht als das, was sie tatsächlich ist, ein Denkmuster, ein Paradigma. Jeder, der sich mit SOA beschäftigt, sollte sich dessen bewusst sein, um die Möglichkeiten von SOA zu entdecken. Dieser Artikel versucht als Beginn einer kleinen Reihe von Artikeln zum Thema SOA ein grundlegendes Verständnis für dieses Thema zu vermitteln.
SOA kann man nicht kaufen. Nun mag mancher einwenden, dass SOA doch im Markt angeboten wird, sogar jeder Softwareanbieter, der etwas auf sich und sein Produkt hält, für dieses mit SOA wirbt. Viele Produkte und auch Dienstleistungen schmücken sich mit der Bezeichnung SOA als Garant für Modernität und Zukunftssicherheit. Gibt es SOA also doch zu kaufen?
SOA kann man nicht kaufen, weil SOA keine fertige Lösung, keine technische Schnittstelle, sondern ein Paradigma, ein Denkmuster ist. Und Denkmuster kann man nicht kaufen, sondern nur anwenden.
Dieses Paradigma geht vom Begriff des Service, des Dienstes aus. Da möglicherweise viele, die diesen Artikel lesen, einen technischen Hintergrund haben, sei an dieser Stelle darauf hingewiesen, dass Service nicht sofort eine bestimmte technische Implementierung wie zum Beispiel Web Service meint. Wesentlich ist, dass ein solcher Dienst eine genau abgegrenzte, nicht zu komplexe Aufgabe umfasst, die genau definiert und beschrieben werden kann.
Geschäftsprozesse und Dienste
Dieses Verständnis des Service wird nun verbunden mit einem erweiterten Verständnis von Geschäftsprozessen. Während eine klassische Beschreibung eines Geschäftsprozesses von dem Bild der Wertschöpfungskette ausgeht, in dem einem wie immer gearteten Produkt durch aufeinander folgende Verarbeitungsschritte Wert hinzugefügt wird, wird immer mehr deutlich, dass dieses einfache Modell in vielen Fällen nicht mehr der Komplexität heutiger Wirtschaft entspricht. Erweiterte Modelle gehen von einem Netzwerk von Beziehungen zu Kunden und Lieferanten aus, die untereinander Dienste anbieten oder anfordern. Dieses Netzwerk von Beziehungen bildet den Geschäftsprozess.
Dieses Verständnis von Geschäftsprozess als Netzwerk von angebotenen und in Anspruch genommenen Diensten gilt nicht nur für Geschäftsprozesse außerhalb des Unternehmens. Es kann auch auf die Prozesse innerhalb eines Unternehmens übertragen werden. Die einzelnen Abteilungen und Gruppen innerhalb des Unternehmens agieren dabei als Kunden für bzw. Lieferanten von Leistungen.
Genau hiermit sind die beiden wesentlichen Bestandteile von SOA beschrieben: der Prozess und der Dienst. Beide bilden den theoretischen Unterbau einer Service Oriented Architecture.
So geht es bei SOA in erster Linie also nicht um einen neuen technischen Standard oder eine neue Schnittstellentechnik. Bei SOA geht es um Geschäftsprozesse und die Dienste, die diesen Prozess abbilden.
Geschäftsprozesse in modernen Unternehmen sind heute nicht mehr denkbar ohne Informationstechnologie. SOA schlägt die Brücke vom Prozess zur IT. Die Service Oriented Architecture geht der Fragestellung nach, wie Geschäftsprozesse in der IT abgebildet werden können.
Diese Abbildung erfolgt dadurch, dass die Dienste, die für einen Geschäftsprozess erforderlich sind, von der IT bereitgestellt werden. Unter Diensten werden dabei Komponenten verstanden, die untereinander lose verbunden sind. Lose verbunden heißt dabei, dass die Komponenten nicht unlösbar voneinander abhängig sind, sondern durch andere Komponenten ersetzt werden können, die den gleichen Dienst anbieten. Die Steuerung des Geschäftsprozesses selbst erfolgt nicht durch die Komponenten oder anders gesagt Services/Dienste, sondern diese stellen nur die definierte Funktionalität zur Verfügung und sind nur für ihre eigenen Daten verantwortlich. Die nur lockere Verbindung der Dienste und die Kapselung der Daten, die für einen Dienst benötigt werden, stellen weitere wesentliche Merkmale von SOA dar. Die Dienste sind nur soweit miteinander verbunden, wie es notwendig ist für die Inanspruchnahme eines Dienstes durch einen anderen. Keiner der Dienste besitzt eine feste Verbindung zu einem anderen Dienst. SOA ist damit nicht vergleichbar mit Softwareanwendungen, die aus mehreren Komponenten bestehen und durch fest kodierte gegenseitige Aufrufe miteinander verbunden sind.
Anbieter und Konsument
Aus der Sicht des Geschäftsprozesses stellt der Dienst ein Angebot dar, das möglicherweise konkurrierend zu anderen Diensten am "Markt" vorhanden ist und verwendet werden kann. Aus Sicht des Dienstes stellt der Geschäftsprozess den Konsumenten dar, der einen Dienst benötigt und den auswählt, der verfügbar ist und den Anforderungen entspricht.
Dieses Verhältnis von Anbieter (service provider) und Konsument (service consumer) ist auch eines der grundlegenden Elemente des OASIS Reference Models for Service Oriented Architecture 1.0 [1], mit dem ein Framework für SOA außerhalb jeder technischen Implementierung definiert wird. Dieses Framework fügt dem Modell des service providers und consumers noch die Begriffe policy und contract hinzu. Damit wird unterstrichen, dass das Verhältnis zwischen consumer und provider von einer genauen Spezifikation des Services einschließlich der allgemeinen Bedingungen und Einschränkungen, die für ihren Einsatz gelten, (policy) und der gegenseitigen Vereinbarung, unter welchen Bedingungen der Service genutzt werden kann (contract), abhängt.
Wie werden nun die Dienste, die, wie wir gesehen haben, nur locker miteinander verbunden sind, zu einem Gesamtsystem integriert? Der einfachste Weg besteht darin, dass die Anwendungen, die den Geschäftsprozess in der IT darstellen, die Dienste dann aufrufen, wenn sie benötigt werden. Für überschaubare Systeme mit einer geringen Zahl von Anwendungen ist das sicherlich möglich und bietet auch den Vorteil, dass die Dienste ausgetauscht werden können, ohne dass die Anwendung selbst davon berührt wird, sofern der neue Dienst sich genau an die Anforderungen hält, die an den Dienst gestellt werden.
Damit ist aber höchstens eine Teilmenge der Möglichkeiten einer SOA ausgenutzt worden. Da SOA ein Paradigma ist, das sich am Geschäftsprozess orientiert, ist es nur zu sinnvoll, dass dieser Geschäftsprozess selbst Bestandteil der SOA ist.
Damit kommen wir zu den Begriffen der Orchestrierung und Choreografie. Zu einer vollständigen SOA gehören Komponenten, die definieren, für welche Aufgabe welcher Dienst verwendet wird, und die Prozesssteuerung übernehmen, damit die Dienste in der richtigen Abfolge und unter den richtigen Bedingungen aufgerufen werden. (CJ)
Anm.d.Red.: Der zweite Teils des Artikels erscheint in den nächsten Newsletterausgabe.
Metadata