 |
Archivierte alte Webseite - Datenschutzerklärung, Adressen und Links zu externen Seiten sind vielfach ungültig - Bitte besuchen Sie www.PROJECT-CONSULT.com
Archived old Web Site - Privacy declaration, addresses and links to external web sites may be invalid - Please visit www.PROJECT-CONSULT.com |
|
| Service Oriented Architecture |
 |
| Abstract |
| Service Oriented Architecture |
| Geschäftsprozesse und Dienste |
| Anbieter und Konsument |
| Begriffe im SOA Umfeld |
| Zusammenfassung |
|
 |
|
| Abstract |
| | | | 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.
| | |
|
|
|
| Service Oriented Architecture |
| | | | 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.
| | |
|
|
|
| Begriffe im SOA Umfeld |
| | | | Vor diesem Hintergrund sollen nun einige Begriffe erläutert werden, die im Umfeld von SOA immer wieder genannt werden und häufig eher zur Verwirrung als zur Klärung beitragen.
| | |
|
| | | | Begriffe wie Enterprise Service Bus (ESB), Enterprise Application Integration (EAI) beschreiben, wie der Aufruf von Services durchgeführt werden kann. Dabei ist EAI mehr technisch ausgerichtet auf die Lösung der Fragestellung, wie Anwendungen bzw. Dienste mit unterschiedlichen Schnittstellen aufgerufen werden können. ESB ist dagegen stärker auf die Abbildung von Prozessen durch Dienste ausgerichtet.
| | |
|
| | | | Web Services und die damit zusammenhängenden Begriffe SOAP, Universal Description, Discovery and Integration (UDDI), Web Services Description Language (WSDL) sind dagegen eine spezifische Implementation, die für SOA verwendet werden kann. Diese Begriffe sind keinesfalls gleichbedeutend mit SOA, und Systeme, die Web Services verwenden, sind auch nicht unbedingt eine Implementierung einer Service Oriented Architecture.
| | |
|
| | | | Dennoch zeigt die Implementierung von SOA durch die Web Services, welche Elemente wichtig sind. SOAP ist die auf XML beruhende Schnittstelle zu den Diensten. Dabei wird per XML sowohl der Funktionsaufruf als auch die dazu gehörenden Daten übergeben und die Antwort des Dienstes zurückgegeben. UDDI und WSDL sind die Implementierung der Registrierung von Diensten im Sinne einer Bekanntmachung des Angebotes, um beim Bild des Anbieters und des Konsumenten zu bleiben. Dabei wird zu einen die Plattform geschaffen, in der solche Angebote abgegeben werden können, zum anderen aber auch festgelegt, wie das Angebot beschrieben werden soll.
| | |
|
| | | | Es fehlt aber noch die Komponente der Prozesssteuerung. In diesen Bereich gehören Begriffe wie Business Process Management (BPM), Business Process Execution Language (BPEL), Business Process Modeling Notation (BPMN). Während BPM ein allgemeiner Oberbegriff ist, stellen die beiden anderen Begriffe konkrete Möglichkeiten der grafischen (BPMN) bzw. XML-basierenden (BPEL) Darstellung von Prozessen dar.
| | |
|
|
|
| Zusammenfassung |
| | | | SOA kann man nicht kaufen. SOA muss angewendet werden. Das ist zugleich die Stärke und das Risiko von SOA. Es ist kein technischer Standard, der in dem Moment der Standardisierung bereits technisch überholt ist, und damit keine kurzlebige Modeerscheinung. Vielleicht wird der Begriff der Service Oriented Architecture nach einiger Zeit nicht mehr modern sein und durch einen anderen ersetzt werden. Aber das Paradigma der SOA selbst, Geschäftsprozesse eng mit der Informationstechnologie zu verknüpfen und diese als notwendiges und wichtiges Mittel zur Ausführung der Prozesse zu sehen und nicht als Selbstzweck, wird für die Informationstechnologie, die den Kinderschuhen der alleinigen Technikorientierung entwächst, bleiben. Vielleicht ändert sich das Etikett, aber das Paradigma entwickelt sich weiter.
| | |
|
| | | | Zugleich ist die Tatsache, das SOA nicht einfach zu kaufen ist, auch die Schwäche in vielen SOA Projekten, in denen SOA-fähige Produkte eingekauft werden, in der Hoffnung so eine Service Oriented Architecture implementieren zu können, ohne dass die Geschäftsprozesse sorgfältig definiert und mit den vorhandenen oder neuen Anwendungen implementiert werden. SOA ist zunächst keine Frage der Technik und keine Aufgabe für IT-Spezialisten, sondern zu aller erst eine Aufgabe der Fachabteilungen.
| | |
|
|
| Link |
| | | | [1] OASIS Reference Models for Service Oriented Architecture 1.0 vom
2. August 2006
| | www.oasis-open.org
| |
|
|
| Rechtshinweis |
| | | | © CopyRight PROJECT CONSULT 2007
Autorenrechte Christoph Jeggle
| | Rechtshinweis
Autorenrechte
| | | Zum Download sind ausschließlich die Beiträge in der Rubrik Download vorgesehen. Als PDF bereitgestellte Beiträge enthalten auch die zugehörigen Grafiken.
| | Download
| |
|
|
|
