D i p l o m a r b e i t

Transkript

1 Evaluierung unterschiedlicher SOA-Produktsuiten und Realisierung eines SOA-Prototypen zur Automatisierung eines Geschäftsprozesses aus der Finanzwirtschaft Jan Tammen Konstanz, D i p l o m a r b e i t

2

3 Diplomarbeit zur Erlangung des akademischen Grades Diplom-Informatiker (FH) an der Hochschule Konstanz Technik, Wirtschaft und Gestaltung Fakultät Informatik Studiengang Software-Engineering Thema: Diplomand: Firma: Evaluierung unterschiedlicher SOA-Produktsuiten und Realisierung eines SOA-Prototypen zur Automatisierung eines Geschäftsprozesses aus der Finanzwirtschaft Jan Tammen Mundsburger Damm 33a Hamburg evodion Information Technologies GmbH Högerdamm Hamburg 1. Prüfer: Prof. Dr.-Ing. Jürgen Wäsch Fakultät Informatik, HTWG Konstanz 2. Prüfer: Dr. Michael Bark evodion Information Technologies GmbH Abgabedatum: 15. Januar 2008

4

5 Zusammenfassung (Abstract) Thema: Diplomand: Firma: Betreuer: Evaluierung unterschiedlicher SOA-Produktsuiten und Realisierung eines SOA-Prototypen zur Automatisierung eines Geschäftsprozesses aus der Finanzwirtschaft Jan Tammen Mundsburger Damm 33a Hamburg evodion Information Technologies GmbH Högerdamm Hamburg Prof. Dr.-Ing. Jürgen Wäsch Fakultät Informatik, HTWG Konstanz Abgabedatum: 15. Januar 2008 Dr. Michael Bark evodion Information Technologies GmbH Schlagworte: SOA, Serviceorientierte Architektur, Web-Services, Evaluierung, WS-BPEL, Orchestrierung, Prototyp, ESB, Workflow Die vorliegende Diplomarbeit befasst sich mit der Evaluierung von SOA-Produktsuiten. Dazu wird zunächst ein Kriterienkatalog erarbeitet, welcher sowohl allgemeine als auch einsatzspezifische Kriterien berücksichtigt. Die anschließende Evaluierung fünf verschiedener Produkte entlang des Kriterienkatalogs erfolgt hauptsächlich anhand der von den Herstellern der Produkte gemachten Angaben und Dokumentationen. Die abschließende Auswertung der Evaluierung erfolgt nicht auf der Basis einer Punkte- oder Notenvergabe, sondern es wird eine grobe Rangfolge der evaluierten Produkte aufgestellt. Schließlich wird mithilfe der Oracle SOA Suite eine prototypische Anwendung erstellt, die einen beispielhaften Geschäftsvorfall implementiert und das Zusammenspiel der verschiedenen Komponenten der Suite erprobt.

6

7 Ehrenwörtliche Erklärung Hiermit erkläre ich, Jan Tammen, geboren am in Oldenburg, 1. dass ich meine Diplomarbeit mit dem Titel: Evaluierung unterschiedlicher SOA-Produktsuiten und Realisierung eines SOA-Prototypen zur Automatisierung eines Geschäftsprozesses aus der Finanzwirtschaft bei der evodion Information Technologies GmbH in Hamburg unter Anleitung von Dr. Michael Bark und der Betreuung durch Prof. Dr.-Ing. Jürgen Wäsch selbständig und ohne fremde Hilfe angefertigt habe und keine anderen als die angeführten Hilfen benutzt habe; 2. dass ich die Übernahme wörtlicher Zitate, von Tabellen, Zeichnungen, Bildern und Programmen aus der Literatur oder anderen Quellen (Internet) sowie die Verwendung der Gedanken anderer Autoren an den entsprechenden Stellen innerhalb der Arbeit gekennzeichnet habe. Ich bin mir bewusst, dass eine falsche Erklärung rechtliche Folgen haben wird. Hamburg, Jan Tammen

8

9 Inhaltsverzeichnis Zusammenfassung (Abstract) v Ehrenwörtliche Erklärung vii 1. Einleitung Problemstellung und Zielsetzung Aufbau der Arbeit Serviceorientierte Architektur Herleitung, Definition und Abgrenzung Was ist eine serviceorientierte Architektur? Abgrenzung zu verwandten Themen Das SOA-Konzept Merkmale einer SOA Der Service (Dienst) als Grundelement Weitere Elemente einer SOA Rollen und Aktionen Die organisatorische Ebene Motivation und Zielsetzung Technische Umsetzung und Standards Web-Services Geschäftsprozessmodellierung und Orchestrierung Kritische Betrachtung von SOA Kriterien zur Evaluierung von SOA-Produktsuiten Bestehende Methoden zur Evaluierung Vorbetrachtungen zur Evaluierung Vorgehensweise bei der Evaluierung Entwicklung der Evaluierungskriterien Modellunabhängige Kriterien Modellabhängige Kriterien Zusammenfassung Evaluierung ausgewählter SOA-Produktsuiten Marktübersicht SOA-Produkte Auswahl und Beschreibung der Evaluanden Evaluierung der Produkte ix

10 Inhaltsverzeichnis Modellunabhängige Kriterien Modellabhängige Kriterien Zusammenfassung und Fazit Entwicklung eines SOA-Prototypen Beschreibung des Geschäftsvorfalls Installation und Konfiguration der Oracle SOA Suite Modellierung in BPMN Implementierung und Orchestrierung der Services WS-BPEL-Prozess»Kreditvergabe« WS-BPEL-Prozess»AddressCheck« WS-BPEL-Prozess»CreditRating« Einbindung von Geschäftsregeln mit dem»decisionservice« Einbindung menschlicher Aktivitäten mit dem»taskservice« WS-BPEL-Prozess»CRM« Sicherung des Web-Services»ERP« Deployment der BPEL-Prozesse Test und Betrieb Test des»addresscheck«-prozesses Stresstest des»creditrating«-prozesses Test des Gesamtprozesses»Kreditvergabe« Überwachung und Logging Fazit Zusammenfassung Probleme und offene Fragen Weiterführende Arbeiten Glossar und Abkürzungsverzeichnis 89 Abbildungsverzeichnis 93 Tabellenverzeichnis 94 Listings 95 Quellenverzeichnis 96 A. Quellcode WS-BPEL-Prozess»Kreditvergabe«100 x

11 1. Einleitung Seit einiger Zeit bereits ist die IT-Welt um eines der gern genutzten Schlagworte reicher: SOA (Serviceorientierte Architektur) ist ein derzeit vieldiskutiertes Thema in IT- und Management-Kreisen. Von vielen wird es dabei lediglich als Hype und alter Wein in neuen Schläuchen bezeichnet, von anderen wiederum als Evolution und das zukunftsträchtigste Enterprise-Software-Architekturmodell angesehen. Fakt ist, dass das Thema inzwischen über den Status des reinen Hypes hinausgewachsen ist und auch seitens der Wirtschaft steigendes Interesse an SOA besteht. Das Marktforschungs- und Analystenunternehmen Gartner veröffentlicht regelmäßig den sog. Hype-cycle, welcher die Entwicklung neuer Technologien visualisiert. In der aktuellen Version für das Jahr 2007 sieht Gartner das Thema SOA bereits über den Gipfel der Hype-Kurve hinaus, wie Abbildung 1.1 zeigt. Abbildung 1.1.: Hype-cycle für 2007: SOA ist über das Hype-Extremum hinaus. Quelle: Gartner. 1

12 1. Einleitung 1.1. Problemstellung und Zielsetzung Ungeachtet aller Kritik an der SOA-Idee und teilweise bereits eingetretener Ernüchterung, gibt es offenkundig Bedarf und Interesse an diesem Thema. Komplexer werdende Software-Systeme erfordern bessere Strukturierung und flexiblere Architekturen, um dieser Komplexität Herr zu werden und den ebenfalls steigenden Marktanforderungen gerecht zu werden. Für ein Unternehmen, das sich entschlossen hat, eine Softwarearchitektur nach dem SOA-Konzept einzuführen, stellt sich die Frage, wie konkret diese Architektur realisiert werden kann. Da hierzu neben organisatorischen Maßnahmen auch technische Hilfsmittel bzw. Software vonnöten sind, haben diverse Hersteller Produkte zu SOA-Suiten gebündelt, mit deren Hilfe diese Anforderungen umsetzbar sein sollen. In dieser Arbeit soll daher untersucht werden, inwieweit die am Markt verfügbaren SOA-Produktsuiten in der Lage sind, die Konzepte einer serviceorientierten Architektur zu unterstützen und wie sich z. B. bereits bestehende Systeme in die neue Architektur integrieren lassen. Neben der rein theoretisch durchgeführten Evaluierung wird auf Basis einer der Evaluierungskandidaten ein Prototyp geschaffen werden, an dem beispielhaft wichtige Aspekte in einer SOA durchgespielt und das Zusammenspiel der Komponenten erprobt werden soll Aufbau der Arbeit Die vorliegende Arbeit besteht neben obligatorischer Einleitung und dem zusammenfassenden Schlussteil aus den folgenden vier Abschnitten. In Kapitel 2 werden zunächst die benötigten theoretischen Grundlagen zum Thema SOA eingeführt. Außerdem wird auf konkrete technische Umsetzungsmöglichkeiten wie Web-Services eingegangen. Kapitel 3 beschäftigt sich anschließend mit der Erarbeitung des Kriterienkatalogs zur Evaluierung der Produkte. Es werden dabei auf der einen Seite sehr allgemein gehaltene, andererseits eher produktspezifische Kriterien aufgestellt. In Kapitel 4 wird dann auf Basis des erstellten Kriterienkatalogs die Evaluierung fünf verschiedener Produktsuiten durchgeführt. Dabei wird hauptsächlich auf die von den Herstellern der Produkte zur Verfügung gestellten Informationen zurückgegriffen. Am Ende entsteht eine grobe Wertung und Beurteilung der evaluierten Produkte. Schließlich wird in Kapitel 5 auf Basis der Oracle SOA Suite ein SOA-Prototyp umgesetzt, der beispielhaft den Geschäftsvorfall einer automatischen Kreditvergabe implementiert. 2

13 2. Serviceorientierte Architektur In den nachfolgenden Abschnitten werden zunächst einige grundlegende Begriffe erläutert, um anschließend eine Definition für SOA zu formulieren. Weiterhin wird eine Abgrenzung zu anderen verwandten Begriffen hergestellt. Sodann werden die wichtigsten Aspekte des SOA-Konzepts sowie die Zielsetzungen und Motivationen eingeführt. Obwohl es sich bei SOA zunächst lediglich um ein abstraktes Konzept handelt, bedarf es zu einer Umsetzung auch konkreter Technologien und Werkzeuge. Zum jetzigen Zeitpunkt sind Web-Services aufgrund ihrer Verbreitung und fortgeschrittenen Standardisierung eine naheliegende Möglichkeit, eine SOA zu realisieren. Daher wird in diesem Kapitel eine Einführung in diese Technologie gegeben. Da es im Zusammenhang mit SOA nicht an kritischen Stimmen mangelt, wird am Ende dieses ersten Teils auf die von den Kritikern angebrachten Argumente und möglichen Hürden bei der Einführung einer SOA eingegangen Herleitung, Definition und Abgrenzung SOA ist kein Produkt, keine Middleware und ist auch nicht abhängig von einer speziellen Technologie. Vielmehr handelt es sich um einen Architekturstil. Das Akronym SOA setzt sich zusammen aus den Bestandteilen serviceorientiert und Architektur. Bevor auf den Begriff der Serviceorientierung eingegangen wird, sei hier knapp aufgeführt, was unter einer Architektur bzw. Softwarearchitektur zu verstehen ist. Hasselbring liefert in [Has06], basierend auf der Terminologie eines Standards der IEEE (Institute of Electrical and Electronics Engineers), die nachstehende Definition: Definition (Softwarearchitektur) Die grundlegende Organisation eines Systems, dargestellt durch dessen Komponenten, deren Beziehungen zueinander und zur Umgebung sowie den Prinzipien, die den Entwurf und die Evolution des Systems bestimmen. Eine Softwarearchitektur beschreibt demnach die Komponenten des Systems sowie deren Verbindungen untereinander, ohne auf konkrete Entwurfsdetails einzugehen und Einschränkungen bzgl. der verwendeten Technologie zu machen. 1 1 In [KBS07, Kap. 4] sind weitere, leicht unterschiedliche Definitionen verschiedener Autoren zusammengefasst. 3

14 2. Serviceorientierte Architektur Der andere Bestandteil des SOA-Begriffs weist darauf hin, dass sich die Architektur an der Verwendung von Services (Diensten) orientiert. Ein Service lässt sich allgemein und abstrakt beschreiben als sinnvolle, abgeschlossene Dienstleistung, die z. B. ein Computerprogramm für ein anderes erbringt. Was genau unter einem Service im Zusammenhang mit SOA zu verstehen ist, wird in Abschnitt detailliert beschrieben. Festhalten lässt sich jedoch, dass der Service-Begriff keine Innovation darstellt und schon seit geraumer Zeit im IT-Umfeld verwendet wird oft mit unterschiedlichen Bedeutungen. Nach [Erl07, Kap. 4] ergibt sich die folgende Definition: Definition (Serviceorientierung) Designparadigma für verteilte Anwendungen, das Services als Grundbausteine verwendet. Verschiedene Designprinzipien charakterisieren dieses Paradigma, dazu zählen u. a. die Verwendung standardisierter Schnittstellen, die lose Kopplung sowie Wiederverwendung. Bei der klassischen Erstellung von Geschäftsanwendungen wird häufig nach dem Prinzip vorgegangen, zunächst den zu automatisierenden Geschäftsprozess zu identifizieren, um diesen anschließend in einer spezifischen Lösung abzubilden. Dieses Vorgehen ist für eine einzelne, statische Anwendung effizient und taktisch sinnvoll. Ändern sich jedoch die Anforderungen oder muss gar ein neuer Geschäftsvorfall implementiert werden, so muss im schlimmsten Fall eine komplette Neuentwicklung betrieben werden. Auf diese Weise werden Teile der Geschäftslogik an mehreren Stellen dupliziert, was zu einer erhöhten Komplexität und sinkender Wartbarkeit führt. Das Paradigma der Serviceorientierung verspricht hier Abhilfe zu schaffen. Durch die Einhaltung der oben angesprochenen Designprinzipien sollen u. a. die folgenden positiven Charakteristiken erreicht werden (nach [Erl07]): Funktionalität und Daten sind konsistenter dargestellt, die Abhängigkeiten zwischen den einzelnen Lösungsbausteinen (den Services) sind geringer, Zuverlässigkeit, Skalierbarkeit und nicht zuletzt Wiederverwendbarkeit werden erhöht. Dagegen stehen potentielle Nachteile, die eine konsequente Serviceorientierung mit sich bringen kann. Durch das erhöhte Abstraktionsniveau wird auch die Komplexität der Architektur größer; werden die Services im Hinblick auf eine spätere Wiederverwendung konzipiert, so haben sie zwangsläufig eine abstraktere Schnittstelle. In der Folge kann dies auch zu weniger performanten Lösungen führen, wenn viele dieser unabhängigen Dienste zu einem Gesamtprozess kombiniert werden müssen. Weiterhin müssen einheitliche Standards zunächst definiert und anschließend deren Einhaltung überwacht werden. All dies stellt einen zusätzlichen Aufwand für das Unternehmen dar. 4

15 2.1. Herleitung, Definition und Abgrenzung Was ist eine serviceorientierte Architektur? Wie bereits erkennbar ist, sind die auftauchenden Begrifflichkeiten teilweise subjektiv und wenig spezifisch. Eine einheitliche Definition des Begriffs SOA gibt es folglich derzeit nicht und wird es aufgrund der inhaltlichen Breite des Themas vermutlich auch nicht geben. Je nach Blickwinkel des Betrachters (oder Verkaufsstrategie eines Software- Herstellers) gibt es vielfältige Definitionen, die das Hauptaugenmerk jeweils auf verschiedene Aspekte legen. Es lässt sich jedoch aus den vorhandenen Definitionen eine gemeinsame Schnittmenge bilden. Damit ergibt sich nach [MW07; KBS07; Erl07] diese Definition: Definition (SOA) Softwarearchitektur, bei der die wertschöpfenden Geschäftsprozesse eines Unternehmens im Vordergrund stehen. Diese Prozesse werden dabei aus standardisierten, lose gekoppelten, wiederverwendbaren Services (Diensten) komponiert. Diese Sichtweise soll im Kontext dieser Arbeit fortan als Definition für eine SOA dienen. Selbstverständlich ist diese Definition nicht allumfassend und lässt u. U. einige Gesichtspunkte unberücksichtigt. Es stellt sich die Frage, was neu am SOA-Konzept ist und welche Unterschiede sich zur herkömmlichen Implementierung von Geschäftsprozessen ergeben. Wie bereits angesprochen, wurden in der Vergangenheit (bzw. werden noch heute) im Unternehmensumfeld zumeist eigenständige, in sich geschlossene Anwendungen eingesetzt (oft als Silos oder Säulen bezeichnet). Die Geschäftsprozesse eines Unternehmens laufen jedoch oft quer über diese Säulen hinweg, d. h. an den Schnittstellen zwischen diesen Systemen kann es zu Problemen kommen, die sowohl technischer als auch organisatorischer Natur sein können. So muss z. B. eine spezielle Middleware eingesetzt werden, um die unterschiedlichen Systeme überhaupt miteinander verbinden zu können. Treten Änderungen am Geschäftsprozess auf, erfordern diese oftmals komplizierte und redundanzfördernde Maßnahmen an unterschiedlichen Stellen. Mithilfe einer an die SOA-Idee angelehnten Architektur sollen diese Probleme nun in den Griff bekommen werden. Anhand eines typischen Beispiels soll dies nochmals verdeutlicht werden. Ein bestehender Geschäftsprozess Kreditvergabe ist mittels verschiedener Applikationen automatisiert. Beteiligt sind ein Kreditverwaltungssystem, ein Kundenverwaltungssystem sowie zwei externe Systeme zur Adress- und Bonitätsüberprüfung. Die einzelnen Komponenten sind dabei über ein Kommunikationssystem (Middleware) miteinander verbunden, wie Abbildung 2.1 zeigt. Treten in dieser Konstellation Änderungsanforderungen auf, so müssen unter Umständen die Schnittstellen zwischen den einzelnen Komponenten angepasst werden. Dazu bedarf es technischer Unterstützung durch die IT es besteht hier also eine starke Abhängigkeit der Geschäftsebene von der Technik. 5

16 2. Serviceorientierte Architektur Abbildung 2.1.: Geschäftsprozess Kreditvergabe ohne SOA In einer SOA hingegen wird der Geschäftsprozess aus einzelnen, voneinander unabhängigen Services zusammengestellt. In unserem Beispiel wären dies Services wie Berechne Bonität, Aktualisiere Kunde oder Benachrichtige Kunde, wie in Abbildung 2.2 dargestellt. Wie man sieht, gibt es in dieser Variante eigentlich keine Verbindungen zwischen den einzelnen Services diese entstehen erst durch deren explizite Verknüpfung, wodurch sich auch der Ablauf des Gesamtgeschäftsprozesses ergibt. Abbildung 2.2.: Geschäftsprozess Kreditvergabe in einer SOA Notwendige Änderungen am Geschäftsprozess können in dieser aus Services komponierten Variante im Idealfall direkt durch ein Mitglied der Fachabteilung unter Verwen- 6

17 2.1. Herleitung, Definition und Abgrenzung dung eines graphischen Modellierungstools durchgeführt werden. Somit kann schneller auf Änderungen reagiert werden, ohne sofort auf technische Unterstützung angewiesen zu sein. Beispielsweise könnte die Abfolge der Teilprozesse geändert werden oder ein weiterer externer Service wie die Abfrage einer Kredithistorie eingebunden werden. Das eigentlich Neue an der SOA-Idee ist also, dass die fachliche Ebene gegenüber der IT in den Vordergrund gerückt ist und davon im Sinne einer Annäherung beider Disziplinen profitieren soll. Zusammenfassend muss festgehalten werden, dass die SOA-Idee kein neues oder revolutionäres Konzept darstellt. Die Ideen der Serviceorientierung und Wiederverwendung finden ihren Ursprung im Prinzip schon in den Anfängen der prozeduralen Programmierung. Auch hier wurde bereits versucht, einzelne Funktionen (oder eben Dienste) durch Auslagerung wiederverwendbar zu machen. Weitere Entwicklungen wie die objektorientierte Programmierung, die RPC-Programmierung oder CORBA (Common Object Request Broker Architecture) haben die SOA-Idee beeinflusst. SOA lässt sich folglich eher als Evolution und die logisch nächste Abstraktionsstufe denn als Revolution bezeichnen (vgl. [MW07, Kap. 2.6] und [Erl07, Kap. 4.4]) Abgrenzung zu verwandten Themen Im Zusammenhang mit SOA werden oftmals die Begriffe ESB (Enterprise Service Bus) sowie EAI (Enterprise Application Integration) genannt. Bei der EAI handelt es sich um das Vorhaben, die in einem Unternehmen vorhandenen Geschäftsanwendungen miteinander zu verbinden. Ziel ist dabei, die oftmals an verschiedenen Stellen gespeicherten Daten zusammenzuführen, um ein effizienteres Arbeiten zu ermöglichen. Erreicht wird dies auf der technischen Ebene durch die Verwendung spezieller Adapter, welche die verschiedenen Anwendungen über eine gemeinsame Kommunikationsinfrastruktur (z. B. CORBA ORB (Object Request Broker)) verbinden [CHKT06]. Im Gegensatz zur SOA wird also nicht auf den Servicegedanken und die Standardisierung gesetzt, sondern lediglich eine Integration der bestehenden Systeme ohne deren Änderung betrieben. Unter einem ESB versteht man im Allgemeinen ein Konzept bzw. Softwaresystem zur Integration von Unternehmensanwendungen, auch wenn hier wie so oft keine einheitliche Definition vorliegt. Der Grundgedanke der EAI wird aufgegriffen als Kommunikationsbasis werden nun allerdings bevorzugt Web-Services eingesetzt. Sinnvollerweise lässt sich ein ESB als technologische Basis für eine SOA einsetzen, indem er eine zentrale Kommunikationsplattform zur Verfügung stellt [MW07]. Zusammenfassend lässt sich sagen, dass die SOA-Idee eine Weiterentwicklung der EAI ist bzw. ebenfalls eine Anwendungsintegration ermöglicht und dass in ihr ein ESB als Infrastrukturkomponente eingesetzt werden kann. 7

18 2. Serviceorientierte Architektur 2.2. Das SOA-Konzept Nach der Definition und Einführung der Grundbegriffe soll in den nächsten Abschnitten detaillierter auf die hinter SOA stehenden Konzepte und Ideen eingegangen werden Merkmale einer SOA Ein Grundkonzept einer SOA liefert der sog. SOA-Tempel (s. Abbildung 2.3) nach [MW07]. Er identifiziert die wichtigsten Grundlagen und Merkmale einer SOA. Die Basisvoraussetzungen bilden demnach zunächst Standards, Sicherheit und Einfachheit. Die Verwendung offener Standards (z. B. für die Schnittstellenbeschreibung) ist nötig, damit Dienste von externen Nutzern richtig verstanden und genutzt werden können. Gleichzeitig erhöht die Verwendung von Standards i. A. die Akzeptanz einer Technologie. Gerade für Geschäftsanwendungen ist die Sicherheit ein wichtiges Thema und muss bereits zu Beginn der Planungen berücksichtigt werden. Die Einfachheit einer Architektur ist nicht zuletzt mitentscheidend für ihren Erfolg. Abbildung 2.3.: Der SOA-Tempel. Quelle: [MW07] Als weitere Eigenschaften (die Säulen) einer SOA lassen sich lose Kopplung, Verteiltheit, das Vorhandensein eines Verzeichnisdienstes sowie Prozessorientierung ausmachen. Ziel der losen Kopplung ist es, die einzelnen Dienste möglichst unabhängig voneinander zu machen. Damit kann u. a. eine dynamische Bindung zur Laufzeit erfolgen; d. h. es 8

19 2.2. Das SOA-Konzept wird erst zur Laufzeit bestimmt, welche konkrete Service-Instanz verwendet wird. Damit dies möglich ist, muss natürlich zusätzlich eine zentrale Verzeichnisinstanz vorhanden sein, in der Dienste registriert und aufgefunden werden können (s. auch Abschnitt 2.2.3). Dass es sich bei SOA um eine verteilte Architektur handelt, wurde bereits erwähnt die Services müssen sich weder auf dem selben Hostsystem wie die Clientanwendung noch im selben (Unternehmens-)Netz befinden. Eines der wichtigsten Merkmale und Unterschiede zu bisherigen Ansätzen ist die Prozessorientierung. Bei einer SOA stehen die fachlichen Aspekte, die wertschöpfenden Geschäftsprozesse eines Unternehmens, im Vordergrund Der Service (Dienst) als Grundelement In den vorangegangenen Abschnitten wurde der Begriff des Dienstes schon mehrfach erwähnt und abstrakt umschrieben. Hier soll nun eine formale und detaillierte Definition erfolgen. Ein Service ist eine Softwarekomponente, die eine wohldefinierte, geschäftliche Funktion kapselt und diese über eine oder mehrere Schnittstellen anderen Teilnehmern einer SOA zur Verfügung stellt [KBS07]. Über die Schnittstelle kommuniziert ein Nutzer physisch mit dem Service. Im Sinne des Prinzips der Kapselung und der losen Kopplung sind Schnittstelle und eigentliche Implementierung strikt voneinander getrennt. Die Implementierung trennt sich dabei auf in Geschäftslogik und dazugehörige Daten. Weiterhin enthält ein Service zusätzlich einen sog. Vertrag, in dem die Funktionalität (Sicherheit, Transaktionen), die Nutzung (z. B. in Form eines SLA (Service Level Agreement)) oder Einschränkungen des Services (QoS) informell spezifiziert sind. Zusätzlich kann der Vertrag eine formelle Schnittstellendefinition (z. B. auf Basis von WSDL (Web Services Description Language) oder IDL (Interface Description Language)) enthalten. Abbildung 2.4 stellt die Bestandteile eines Services nochmals graphisch dar. Wie bereits angesprochen, stehen in einer SOA diejenigen Funktionen im Vordergrund, die das Unternehmen in dessen Wertschöpfung unterstützen. Diese Wertschöpfung erfolgt z. B. bei Erbringung von Dienstleistungen oder der Fertigung von Produkten; entsprechende Services sind Kundenverwaltung, Bestellabwicklung oder Produktionsplanung. Andererseits gibt es auch eine Reihe sinnvoller technischer Dienste, wie beispielsweise Dienste zur Transformation von Daten oder zur Aufzeichnung von Protokolldaten. Erl schlägt in [Erl07] daher die folgende Kategorisierung für Servicetypen vor und identifiziert noch einen zusätzlichen Typ, den Task Service : Entity Service (Entitätendienst): Kapselt den Zugriff auf Geschäftsentitäten, wie beispielsweise eine Rechnung oder einen Kunden. Diese Art von Dienst ist typischerweise gut wiederverwendbar. Task Service (Prozessdienst): Kapselt einen übergeordneten (Teil-)Geschäftsprozess, der sich im Gegensatz zum Entitätendienst über mehrere Domänen erstrecken 9

20 2. Serviceorientierte Architektur Abbildung 2.4.: Bestandteile eines Services. Vgl. [Jas07] kann. Als Beispiel lässt sich eine automatisierte Rechnungserstellung nennen, die zunächst auf die Domäne der Rechnung und anschließend auf die der Kunden zugreift. Utility Service (Hilfsdienst, technischer Dienst): Im Gegensatz zu den oben genannten Diensten hat dieser Typ primär keinen Bezug zu den eigentlichen Geschäftsprozessen. Ähnlich wie Klassenbibliotheken bietet ein solcher Dienst z. B. Transformationen verschiedener Datenformate, Logging, Single-Sign-On, Identitätsfeststellung oder dergleichen an. Eine SOA, in der es hauptsächlich technische Services gibt, ist im Prinzip nicht als SOA zu bezeichnen, da die Kernidee die Ausrichtung auf die Geschäftsprozesse nicht umgesetzt ist [ST07] Weitere Elemente einer SOA Neben dem nun beschriebenen Hauptelement, dem Service, gibt es in einer SOA eine Reihe weiterer Elemente, auf die im Folgenden eingegangen wird. Frontends (Anwendungen) sind diejenigen Teile einer SOA, welche hauptsächlich die Geschäftsprozesse initiieren und deren Ergebnisse verarbeiten, z. B. mittels einer GUI (Portal, Web-Applikation, Rich-Client etc.) oder eines Batch-Prozesses. Dabei greifen sie über deren Schnittstelle auf die Services zu. Verzeichnisse dienen dazu, Informationen über Dienste zu speichern und abrufbar zu machen. Dabei gibt es grundsätzlich zwei verschiedene Arten von Informationen. In einer Registry wird hinterlegt, unter welcher physikalischen Adresse der Dienst erreichbar 10

21 2.2. Das SOA-Konzept ist und wie dessen Schnittstelle aussieht. Optionale Metadaten wie z. B. Qualitätsmerkmale oder Sicherheitsinformationen werden in einem separaten Repository abgelegt. Da sich zur Zeit noch kein Standard für Verzeichnisdienste herauskristallisiert hat, bieten viele Hersteller inzwischen eine proprietäre Kombination aus beiden Verzeichnisarten an man spricht dann nur noch von einer Registry [ST07]. Verwendung finden die Verzeichnisse im kompletten Lebenszyklus eines Services: zur Zeit der Entwicklung wird in ihnen nach bereits verfügbaren und wiederverwendbaren Diensten gesucht. Während des Betriebs wird die Service-Landschaft im Rahmen der SOA-Governance über die Verzeichnisse überwacht. Zur Laufzeit schließlich wird bei dynamischer Bindung ein passender Dienst über das Verzeichnis gesucht. Ein Service Bus dient als Infrastrukturelement in einer SOA. Über ihn werden die Beteiligten (Services und Frontends) vernetzt und können ohne Details der Kommunikation kennen zu müssen untereinander Daten austauschen. Weiterhin bietet der Service Bus (oder ESB, siehe Abschnitt 2.1.2) eine Kapselung heterogener Technologien sowie synchroner und asynchroner Kommunikation. Außerdem können zusätzliche technische Dienste, wie z. B. Logging oder Transaktionen durch den Service Bus bereitgestellt werden. Dabei muss die Funktionalität eines Service Buses nicht zwangsläufig durch die Verwendung eines speziellen ESB-Produktes erfolgen, sondern kann durchaus durch Kombinieren verschiedener Einzelkomponenten virtualisiert werden [KBS07; ST07] Rollen und Aktionen In einem abstrakten Grundmodell existieren in einer SOA drei Rollen sowie verschiedene Aktionen. Abbildung 2.5 zeigt diese Rollen und ihre Beziehungen untereinander. Der Anbieter stellt einen oder mehrere Dienste bereit, auf die über ein Netzwerk zugegriffen werden kann. Dazu wird zunächst eine Beschreibung der Dienste erstellt, anschließend werden die Dienste in einem Verzeichnis (Registry/Repository) registriert. Nun kann der Nutzer in dem Verzeichnis nach einem Dienst suchen und bei Bedarf vom Anbieter nähere Informationen in Form der Dienst-Beschreibung anfordern. Schließlich verbindet sich der Nutzer mit dem Anbieter und kann den Dienst nutzen. Alternativ zur Suche in einem Verzeichnis lassen sich die zu verwendenden Services natürlich bereits zur Entwicklungszeit festlegen. Es obliegt dem Dienst-Anbieter, die notwendigen Ressourcen zur Nutzung des Dienstes zur Verfügung zu stellen, sowie dessen Verfügbarkeit und Sicherheit sicherzustellen Die organisatorische Ebene Soll eine SOA erfolgreich unternehmensweit etabliert werden, sind auf organisatorischer Ebene einige Anstrengungen zu unternehmen. Es ist unbedingt erforderlich, dass Geschäftsbereich (die Fachabteilungen) und IT kooperieren, und dabei gleichzeitig Unterstützung durch die Geschäftsleitung erfahren. Auf dieser eher politischen Ebene gibt 11

22 2. Serviceorientierte Architektur Abbildung 2.5.: Rollen und Aktionen in einer SOA es nach [MW07] oftmals Konfliktpotential, da die Einführung einer SOA für viele Parteien eine große Umstellung und mitunter einen Machtverlust darstellt. Es müssen Maßnahmen ergriffen werden, um die Verwendung und Bereitstellung von Services attraktiv zu machen bzw. zu forcieren. Dazu gehören u. a. eine Festlegung gewisser Standards (z. B. für die Granularität von Services), eine geeignete Katalogisierung der Dienste und eine Überwachung zur Laufzeit. Weiterhin muss ggf. ein Abrechnungsmodell für Service-Aufrufe angeboten werden. Dieser komplexe Prozess wird üblicherweise unter dem Begriff Governance (Steuerung, Führung) zusammengefasst. Dazu kommen weitere, auch nicht-technische Anforderungen, wie z. B. betriebswirtschaftliche oder juristische Vorgaben, die in einem Unternehmen eingehalten und überwacht werden müssen. Es herrscht größtenteils Einigkeit darüber, dass die Einführung einer SOA, die auf vielen Ebenen eine Umstellung für das Unternehmen bedeutet, nicht in einem einzigen großen Schritt ( Big Bang ) durchführbar ist. Vielmehr scheint eine schrittweise Herangehensweise, bei der z. B. zunächst einige kleinere Projekte umgesetzt werden, sinnvoller. In diesem Abschnitt wurde lediglich ein kurzer Überblick über die organisatorischen Aspekte einer SOA gegeben umfangreichere Ausführungen finden sich in [Erl07] sowie [KBS07] Motivation und Zielsetzung Mit der Einführung einer SOA sind typischerweise eine ganze Reihe von Erwartungen verknüpft. Unternehmen sind heutzutage mehr und mehr abhängig von einer funktionierenden IT-Infrastruktur, die die Geschäftsprozesse optimal unterstützt. Die Anforderungen an die Unternehmen sind durch erhöhte Konkurrenz durch globales Agieren, 12

23 2.3. Technische Umsetzung und Standards sich stetig wandelnde Kundenanforderungen und ähnliche Aspekte immer weiter gestiegen. Es hat sich gezeigt, dass die IT eines Unternehmens diesen Anforderungen oftmals nicht gerecht werden kann sie ist einfach zu starr und unflexibel [KBS07; ST07]. An diesem Punkt setzt die Idee einer SOA an: eines der Hauptziele ist eine stärkere Annäherung der IT an die geschäftlichen Prozesse. Dieses Vorhaben ist auch bekannt unter dem Schlagwort IT-Business-Alignment und soll dazu dienen, das Unternehmen agiler und flexibler zu machen. Dadurch, dass die einzelnen Bestandteile der Geschäftsvorfälle in lose gekoppelte, standardisierte Services (Dienste) aufgeteilt werden, ergeben sich noch weitere mögliche Vorteile [KBS07, Kap. 11]: Wiederverwendung Seit jeher wird in der Informatik nach Wiederverwendung von bereits Vorhandenem gestrebt. Die Granularität ist dabei im Laufe der Zeit stets gröber geworden angefangen bei Subroutinen über Objekte bis hin zu Komponenten. In einer SOA lassen sich nun idealerweise komplette Geschäftsprozesse wiederverwenden, und das nicht nur in einem einzigen Projekt, sondern im gesamten Unternehmen oder sogar über die Unternehmensgrenzen hinaus. Technologieunabhängigkeit Eine SOA fördert die Unabhängigkeit von bestimmten Technologien vor allem durch die Verwendung der abstrakten Service-Verträge. Kosteneinsparungen Bei Aufkommen der SOA-Idee wurden nicht zuletzt finanzielle Einsparungsmöglichkeiten auf verschiedenen Ebenen vermutet dieser Aspekt hat sich jedoch inzwischen stark relativiert. So zeigt sich, dass bei der Einführung einer neuen Architektur zwangsläufig Kosten entstehen. Dabei handelt es sich zum einen um Kosten für IT-Infrastrukur, zum anderen um organisatorische Kosten wie z. B. für Schulungen oder Beratung. Ob sich diese Mehrkosten durch spätere Einsparungen wieder ausgleichen lassen, ist zumindest fraglich. Fest steht jedoch, dass durch erhöhte Agilität auf lange Sicht gesehen ein Wettbewerbsvorteil für das Unternehmen entsteht, der sich letztlich auch finanziell bemerkbar machen kann [MW07, Kap. 3] Technische Umsetzung und Standards Als Architekturstil ist SOA laut Definition erst einmal technologieunabhängig. Von vielen wird SOA jedoch oft automatisch mit Web-Services in Verbindung gebracht und von einigen sogar gleichgesetzt. Es gab allerdings bereits lange vor den Web-Services verschiedene Konzepte, mit denen eine serviceorientierte Architektur realisiert werden kann. Dazu zählen z. B. Java RMI (Remote Method Invocation), CORBA von der OMG (Object Management Group), Microsoft DCOM (Distributed Component Object Model) oder nachrichtenorientierte Middleware. Diese wiesen jedoch mindestens jeweils einen gravierenden Nachteil auf, der eine schlussendliche Etablierung verhinderte. Bei 13

24 2. Serviceorientierte Architektur RMI und DCOM war dies die Plattform- bzw. Programmiersprachenabhängigkeit und bei CORBA die am Ende zu hohe Komplexität und die mangelnde Interoperabilität der Produkte verschiedener Hersteller [MW07]. Web-Services sind eine Weiterentwicklung dieser Konzepte und vereinen deren jeweilige Stärken. Nicht zuletzt durch den fortwährenden Erfolg des Internets (und speziell des World Wide Webs) und die Verwendung von etablierten Standards haben Web- Services es bis dato zu einer großen Akzeptanz gebracht. Heutzutage ist es selbst auf vielen mobilen Endgeräten möglich, diese Technologie einzusetzen. Somit sind Web- Services derzeit als naheliegende Möglichkeit zu sehen, eine SOA aufzubauen. In den nachfolgenden Abschnitten wird eine kurze Einführung in die Grundkonzepte der Web- Services gegeben Web-Services Die Grundidee von Web-Services ist es, verschiedene Anwendungen lose über das Internet zu koppeln. Ähnlich zu der Situation um SOA auch, gibt es für Web-Services eine Vielzahl verschiedener Definitionen [MW07]. Im Rahmen dieser Arbeit soll die folgende Definition des W3C (World Wide Web Consortium) von 2003 verwendet werden [HB04]: Definition (Web-Service) A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards. Vorteile von Web-Services sind u. a. die Technologie- und Plattformunabhängigkeit. Mit der XML (Extensible Markup Language) als Basissprache wird ein inzwischen breit akzeptierter Standard verwendet und für nahezu alle aktuellen Entwicklungsplattformen existieren Implementierungen der Web-Service-Protokolle. Zu den Basisprotokollen gehören das SOAP (Simple Object Access Protocol) als Kommunikationsprotokoll, WSDL als Beschreibungssprache sowie UDDI (Universal Description, Discovery and Integration) als Verzeichnisdienst. Die nachfolgenden Abschnitte geben eine knappe Übersicht über diese drei Basiskomponenten von Web-Services SOAP SOAP stellt die Kommunikationskomponente von Web-Services dar und definiert ein Nachrichtenformat, mit dem Web-Service-Anwendungen untereinander kommunizieren. Es werden keinerlei Annahmen über Plattform oder zu verwendendes Transport- 14

25 2.3. Technische Umsetzung und Standards protokoll gemacht. Die SOAP-Spezifikation 2 ist aufgrund ihres Umfangs unterteilt in mehrere Dokumente. Auf die Details soll hier nicht eingegangen werden, sondern lediglich der grundsätzliche Aufbau einer SOAP-Nachricht dargestellt werden. Eine solche Nachricht besteht aus drei Bestandteilen: dem Envelope (Umschlag), in dem der Header (Kopf) sowie der Body (Körper/Rumpf) verpackt sind. Abbildung 2.6 stellt diese Struktur dar. Abbildung 2.6.: Aufbau einer SOAP-Nachricht. Vgl. [ML07] Der Header ist optional und kann z. B. durch den Empfänger oder Zwischenstationen, über welche die Nachricht transportiert wird, ausgewertet oder erweitert werden. Welche Informationen im Header verpackt sind, wird in der Spezifikation nicht festgelegt. Es können hier beispielsweise Sicherheitsinformationen übertragen werden, wie in [RSR06] dargestellt wird. Im Body der Nachricht werden schließlich die eigentlichen Nutzdaten übertragen, welche durch ein beliebiges wohlgeformtes XML-Dokument repräsentiert werden. In Listing 2.1 ist eine beispielhafte SOAP-Nachricht als komplettes XML-Dokument aufgeführt. <?xml version= 1.0?> <env:envelope xmlns:env=" <env:header> <! Zusätzliche Informationen, z.b. bzgl. Sicherheit > </env:header> 2 Aktuell Version 1.2, s. [ML07] als Einstieg. 15

26 2. Serviceorientierte Architektur <env:body> <m:nutzlast xmlns:m=" <m:message>zu transportierende Nutzlast</m:Message> </m:nutzlast> </env:body> </env:envelope> Listing 2.1: Beispiel für eine SOAP-Nachricht WSDL Zur Beschreibung von Web-Services dient die ebenfalls XML-basierte Sprache WSDL. Mit ihrer Hilfe wird eine Schnittstelle zwischen dem Dienst und dem aufrufenden Client definiert. Kennt ein Client die WSDL-Beschreibung eines Dienstes, so kann er dessen öffentlich zugängliche Funktionen aufrufen. Die durch das W3C verwaltete WSDL-Spezifikation sieht vor, einen Web-Service aus einer abstrakten sowie einer konkreten Sicht zu beschreiben. Auf diese Weise wird die Beschreibung der Funktionalität (abstrakte Sicht) getrennt von den technischen Details wie z. B. dem Ort, an welchem der Dienst angeboten wird (konkrete Sicht). Der abstrakte Teil der Beschreibung besteht aus den folgenden Bestandteilen: Beschreibung der verwendeten Ein- und Ausgabe-Datentypen, Beschreibung der Schnittstellen des Web-Services, inkl. der Operationen, Einund Ausgabeparameter sowie Fehlertypen. Im konkreten Teil werden die folgenden Informationen abgelegt: Festlegung des zu verwendenden Protokolls (z. B. SOAP) für den Nachrichtenaustausch, optional Festlegung für Transport und Kodierung pro Operation, physikalische Adresse des Services. Für weitergehende Darstellungen sei auf die aktuelle WSDL-Spezifikation in [BL07] bzw. [MW07, Kap. 6] verwiesen UDDI Gibt es in einer SOA mehr als nur eine Handvoll von Diensten, so sollte ein zentrales Verzeichnis für die Suche und Verwaltung der Dienste eingesetzt werden. Im Umfeld der Web-Services gibt es derzeit zwei unterschiedliche Ansätze, mit denen sich Verzeichnisse realisieren lassen: WS-Inspection sowie UDDI. Dabei ist UDDI dessen Spezifikation von der OASIS (Organization for the Advancement of Structured Information 16

27 2.3. Technische Umsetzung und Standards Standards) verwaltet wird der potentiell zukunftsträchtigere und soll daher hier kurz vorgestellt werden. Man muss allerdings festhalten, dass UDDI bisher kein allgemein akzeptierter Standard ist und es daher von vielen Herstellern eigene Lösungen gibt. Ganz allgemein dient UDDI dazu, Informationen über Web-Services zu veröffentlichen und auffindbar zu machen. Es können dabei verschiedene Arten von Informationen bereitgestellt werden. In den sog. White Pages werden Informationen über den Anbieter des Services abgelegt. Die Yellow Pages gruppieren die Anbieter nach Branchen. Die Beschreibungen für die eigentlichen Services werden abgelegt in den Green Pages sowie der Service Type Registration. Die UDDI-Spezifikation beschreibt neben verschiedenen Datenstrukturen (in Form eines XML-Schemas) für die o. g. Datenquellen ein API (Application Programming Interface) zur Veröffentlichung, Modifikation und Suche von Datensätzen Web-Services und SOA Web-Services bieten mit den drei vorgestellten Protokollen SOAP, WSDL und UDDI die benötigten Grundkomponenten für den Aufbau einer SOA: Kommunikation, Dienstbeschreibung sowie Verzeichnisdienst. Die bereits in Abschnitt vorgestellten Rollen und Aktionen lassen sich nun mit diesen Komponenten konkretisieren. Abbildung 2.7 zeigt, an welchen Stellen sich SOAP, WSDL und UDDI in das Rollen-Aktionen-Dreieck einordnen. Abbildung 2.7.: SOA mit Web-Services Der Service wird mithilfe eines WSDL-Dokuments beschrieben und über die von dem UDDI-basierten Verzeichnisdienst angebotene SOAP-Schnittstelle veröffentlicht. Der Dienst-Nutzer sucht ebenfalls über die SOAP-Schnittstelle in dem Verzeichnis. Er 17

28 2. Serviceorientierte Architektur fordert vom Anbieter die WSDL-Beschreibung an und kann anschließend über SOAP mit dem Service kommunizieren. In einer SOA existieren allerdings noch weitere Anforderungen, die beispielsweise die Sicherheit oder Transaktionen betreffen. Erfüllt werden können diese Anforderungen durch die Erweiterung mittels verschiedener Spezifikationen und Standards, die im sog. Web-Service-Stack abgebildet werden. Auf diese Erweiterungen soll hier jedoch nicht eingegangen werden; eine ausführliche Darstellung findet sich z. B. in [MW07, Kap. 4]. Es soll hier abschließend nicht unerwähnt bleiben, dass es auch verschiedene Kritikpunkte an Web-Services gibt. Im Wesentlichen betrifft die Kritik die Themen Standardisierung sowie Performance. Im Umfeld von Web-Services haben sich inzwischen mehr als 100 Spezifikationen angesammelt, welche mitunter nur bedingt ausgereift sind oder sich gar gegenseitig widersprechen. Auf der anderen Seite seien wichtige Dinge bislang nur unzureichend oder gar nicht spezifiziert. Hier den Überblick zu bewahren stellt eine gewisse Herausforderung dar. Die Kritik im Hinblick auf die Leistungsfähigkeit von Web-Services bezieht sich auf den nicht unerheblichen Kommunikationsoverhead, den die Verwendung von XML als Basis mit sich bringt. Auch wenn dieser sicherlich nicht zu leugnen ist und einige Untersuchungen dies bestätigen wollen (z. B. [EPL02]), so kommen andere zu dem Schluss, dass der Overhead bei der Wahl geeigneter Transportprotokolle und den heutigen Übertragungsbandbreiten kaum noch eine Rolle spielt [MW07, Kap. 8] Geschäftsprozessmodellierung und Orchestrierung Nachdem nun grob aufgezeigt wurde, wie sich Services konkret umsetzen lassen, soll hier auf einen weiteren wichtigen Aspekt von SOA eingegangen werden: die Prozessorientierung. Wie bereits ausgeführt, liegt der Fokus bei einer SOA eindeutig auf den Geschäftsprozessen eines Unternehmens. Diese müssen u. U. aus mehreren feingranularen Services zu einem kompletten Prozess zusammengesetzt werden. Ein solcher zusammengesetzter Prozess hat gegenüber einem hartcodierten Prozess den Vorteil, dass er gegenüber Änderungen flexibler ist. Vorausgesetzt, die Services weisen die richtige Granularität auf, lässt sich ein solcher Prozess relativ problemlos neu arrangieren, indem z. B. einfach zwei Web-Service-Aufrufe in ihrer Aufrufreihenfolge vertauscht werden. Diesen Vorgang nennt man auch Orchestrierung und ist in vielerlei Hinsicht vergleichbar mit dem klassischen Workflow-Management. Es wird dabei genau festgelegt, in welcher Reihenfolge welche Operation mit welchen Parametern aufgerufen wird. Im Gegensatz dazu gibt es in einer Choreographie keine zentrale Steuerungsinstanz, sondern das Zusammenwirken der einzelnen Services ergibt sich aus der Struktur der ausgetauschten Nachrichten. Zur Modellierung und Orchestrierung von Geschäftsprozessen existieren zahlreiche Ansätze, darunter BPML (Business Process Modelling Language) und WS-BPEL (Web Services Business Process Execution Language). Im Folgenden soll jedoch lediglich auf 18

29 2.3. Technische Umsetzung und Standards WS-BPEL näher eingegangen werden, da es sich derzeit durchzusetzen scheint [KBS07, Kap. 7] WS-BPEL Vormals unter dem Namen BPEL4WS (Business Process Execution Language for Web Services) bekannt, ist WS-BPEL seit April 2007 in der Version 2 von der OASIS standardisiert. Es handelt sich dabei dem Namen nach um eine Art Programmiersprache, mit der XML-basiert Geschäftsprozesse modelliert werden können, indem einzelne Web- Services zu einem gesamten Workflow kombiniert werden. Die Grundstruktur eines mit WS-BPEL beschriebenen Prozesses ist in Listing 2.2 gezeigt. <! Prozess > <process name="helloworld" targetnamespace=" xmlns=" <! Dienste, die an dem Prozess b e t e i l i g t sind > <partnerlinks>...</partnerlinks> <! Daten > <variables>...</variables> <! Ablaufsequenz > <sequence name="main"> <! Aktivitäten > <invoke... /> <receive... /> <reply... /> </sequence> </process> Listing 2.2: Beispiel für ein WS-BPEL-Dokument Das Wurzelelement process beschreibt einen Geschäftsprozess. Innerhalb des Elements partnerlinks werden alles Services angegeben, die an dem Prozess beteiligt sind. Weiterhin können strukturierte Aktivitäten, z. B. ein sequentieller Ablauf mit dem sequence-element programmiert werden. Unterhalb dieses Elements wiederum finden sich in diesem Beispiel Basisaktivitäten, wie z. B. das Aufrufen eines Web-Services (invoke), das Warten auf einen Rückgabewert (receive) sowie die Rückgabe eines Wertes an einen Aufrufer (reply). Für detaillierte Beschreibungen der einzelnen Elemente sei auf [MW07, Kap. 10] bzw. [AAA + 07] verwiesen. Ein solches WS-BPEL-Dokument oder -Programm wird an eine sog. Prozess-Engine übergeben, die die darin enthaltenen Anweisungen ausführt [AAA + 07]. Da die Modellierung der Geschäftsprozesse idealerweise von Mitgliedern der Geschäftsführung bzw. Fachabteilungen und nicht von Technikern durchgeführt werden 19

30 2. Serviceorientierte Architektur sollte, ist ein solcher programmiersprachenähnlicher Ansatz jedoch wenig hilfreich. Eine Möglichkeit zur graphischen Modellierung bzw. Darstellung von Geschäftsprozessdiagrammen ist die BPMN (Business Process Modelling Notation), die vergleichbar ist mit der UML (Unified Modelling Language). Mit entsprechenden Werkzeugen lassen sich die Geschäftsprozesse dann über eine graphische Benutzeroberfläche modellieren; anschließend kann das Modell z. B. nach WS-BPEL transformiert und dann technisch konkret umgesetzt werden BPEL4People und WS-HumanTask Was die WS-BPEL-Spezifikation nicht berücksichtigt, ist die menschliche Interaktion in einem Workflow. Da dies offensichtlich einen erheblichen Mangel darstellt, haben sich die Hersteller von BPEL-Produkten dieses Themas angenommen und teilweise eigene, proprietäre Erweiterungen erschaffen. Auf der anderen Seite existiert eine Initiative von IBM, SAP und anderen Software-Herstellern, die unter dem Titel BPEL4People (Business Process Execution Language for People) eine auf WS-BPEL basierende Erweiterung für die Behandlung menschlicher Interaktion vorschlägt. Dabei wird mit der people activity ein neuer Typ von Basisaktivität eingeführt [KKL + 05]. Zusätzlich wird unter dem Namen WS-HumanTask eine Spezifikation für die Definition von menschlichen Aufgaben entwickelt. Ob diese Vorschläge jedoch Einzug in die OASIS-Standards und die Produkte der Hersteller erhalten werden, bleibt abzuwarten Kritische Betrachtung von SOA Abschließend soll in diesem Abschnitt auf die häufigsten Schwierigkeiten bei der Einführung bzw. Umsetzung einer SOA sowie einige wichtige Kritikpunkte an der SOA-Idee eingegangen werden. Herrmann identifiziert in [Her07] hauptsächlich organisatorische Aspekte als mögliche Hürden bei der SOA-Einführung. So sei es besonders wichtig, dass die Geschäftsund IT-Ebene eng zusammenarbeiten und eine gemeinsame Sprache sprechen. Wie bereits dargelegt, erfordert eine SOA-Initiative außerdem Unterstützung aus der obersten Geschäftsebene. Bliebe diese aus, würden SOA-Projekte nur von den IT-Abteilungen vorangetrieben, was letztlich die Erfolgschancen vermindere. Um diese Unterstützung zu bekommen, ist die überzeugende Darlegung der potentiellen Vorteile gegenüber der Geschäftsleitung besonders wichtig. Gerade die geschäftlichen Vorteile einer SOA sind jedoch nur schwer messbar und damit ebenso schwer vermittelbar. Abseits aller möglichen Einstiegshürden sieht manch einer die potentiellen Vorteile einer SOA sehr kritisch bzw. stellt diese sogar komplett infrage. So liefert [KM07] u. a. Kritik zu den Themen Agilität, Wiederverwendung und Kosteneinsparungen. So führen die Autoren beispielsweise an, dass in einer SOA Wiederverwendung nicht besser oder 20

31 2.4. Kritische Betrachtung von SOA schlechter funktioniere als bei anderen Ansätzen wie CORBA zuvor auch. Unbestreitbar ist, dass Wiederverwendung nur bei entsprechender Qualität der Services, einer ausreichenden Beschreibung und Dokumentation sowie nicht zuletzt der Bereitschaft der Entwickler, bereits vorhandenes auch wiederzuverwenden, stattfinden kann. Weiterhin gibt es potentielle Probleme bzgl. der Performance, die durch das erhöhte Abstraktionsniveau deutlich leiden könne, wie die Autoren in [RFY + 07] mithilfe eines Prototypen zeigen. In [Mas05] legt der Autor anschaulich dar, dass in einer serviceorientierten Architektur die Entropie 3 des Systems um einiges höher ist als in einer herkömmlichen, monolithischen Anwendung. In diesem Zusammenhang warnt er außerdem vor dem als Servicitis bezeichneten Antipattern. Der Begriff beschreibt die Versuchung, jede noch so kleine Funktion als Service zu implementieren. Ein solches stark fragmentiertes System sei aufgrund der hohen Komplexität nicht mehr wartbar. Es bleibt abzuwarten, ob sich das SOA-Konzept auf lange Sicht durchsetzen kann oder ob sich die propagierten Vorteile als unerfüllbar erweisen. Jedoch zeigen zahlreiche bereits realisierte Projekte, dass durchaus positive Ergebnisse zu erzielen sind [KBS07]. 3 Unter der Entropie eines Systems versteht man dessen Unordnung. 21

32 3. Kriterien zur Evaluierung von SOA-Produktsuiten Unter der Evaluierung von Software versteht man die strukturierte Analyse und Bewertung bestehender Softwaresysteme. Im Allgemeinen ist der Anlass bzw. Zweck einer solchen Evaluierung die Unterstützung bei der Auswahl einer Software für einen bestimmten Anwendungsbereich. Dazu werden die Evaluanden unter verschiedenen Gesichtspunkten betrachtet, darunter u. a. das Leistungsspektrum aber auch allgemeine Rahmenbedingungen [DMEW94]. Im Rahmen dieser Diplomarbeit soll eine Untersuchung von SOA-Suiten durchgeführt werden. Die Zielsetzung der Evaluierung ist dabei nicht, eine ideale Suite für ein bestimmtes Projekt oder Kunden zu finden oder ein bestes Produkt zu ermitteln. Es soll vielmehr eine Übersicht über die am Markt befindlichen Produkte geschaffen werden, auf deren Basis sich einschätzen lässt, welche der Produkte zur Umsetzung einer SOA geeignet erscheinen. Anschließend soll mit einer der Suiten eine prototypische Anwendung entwickelt werden, um das Zusammenspiel der einzelnen Komponenten zu beleuchten. Dies setzt demnach auch die Verfügbarkeit einer Evaluationsversion des betreffenden Systems voraus. Für die Durchführung der Evaluierung wird zunächst eine systematische Vorgehensweise benötigt, welche in den nachfolgenden Abschnitten erarbeitet wird, bevor im Anschluss mit der Evaluierung fortgefahren werden kann Bestehende Methoden zur Evaluierung Überall dort, wo nicht-eigenerstellte Software eingesetzt werden soll, besteht die Notwendigkeit, sich einen Überblick über die am Markt vorhandenen Produkte zu verschaffen, diese zu analysieren und nach individuellen Kriterien die beste Alternative zu ermitteln. Daher gibt es in der Literatur eine ganze Reihe von Vorgehensmodellen für die Evaluierung von Software bzw. Evaluierung im Allgemeinen. Einige dieser Methoden sollen nachfolgend vorgestellt und auf ihre Einsatzmöglichkeit in dieser Arbeit hin untersucht werden. In [DMEW94] schlagen die Autoren vor, eine Evaluierung von Software grundsätzlich in zwei Bestandteile zu unterteilen: in der modellabhängigen Sicht wird die Funktionalität der Software berücksichtigt, während bei der modellunabhängigen Evaluierung allgemeine Aspekte, die nicht direkt auf die Software bezogen sind, untersucht werden. Bei der modellabhängigen Evaluierung kann weiter unterschieden werden zwischen quantitativen und qualitativen Kriterien. Zu ersteren zählt beispielsweise das Vorhandensein der benötigten Funktionen; bei den qualitativen wird die Güte der gebotenen Funktionalität betrachtet. Die quantitativen Faktoren lassen sich dabei recht objektiv 22

33 3.1. Bestehende Methoden zur Evaluierung messen, während die qualitativen naturgemäß eher subjektiv bewertet werden müssen. In [FW95] werden diese Ideen aufgegriffen und zusätzlich ein Verfahren beschrieben, mit dessen Hilfe man zu den benötigten Evaluierungskriterien gelangt. Dabei wird zunächst ein Modell benötigt, das als unabhängiger Maßstab für die Evaluierung benutzt werden kann. Die Autoren schlagen dazu in ihrer Arbeit vor, das geplante Anwendungsumfeld aus verschiedenen Perspektiven zu betrachten, um anschließend daraus die Kriterien ableiten zu können. Ein abstraktes Rahmenwerk zur Evaluierung von Technologien wird in [BW96] vorgestellt. Die Grundidee ist dabei, das sog. feature delta der zu untersuchenden Objekte zu bestimmen. Die Autoren bezeichnen damit die Menge an Merkmalen, in denen sich zwei Technologien voneinander unterscheiden und wie sich diese Unterschiede auf das Unternehmen auswirken. Der Evaluierungsvorgang wird in mehrere Phasen unterteilt: zunächst werden die Evaluanden bezüglich ihrer Abstammung und verschiedener Relationen zueinander dargestellt. Anschließend werden sie mithilfe diverser Experimente untersucht und verglichen, um schließlich die Auswertung der Evaluierung vorzunehmen. Dieses Verfahren zielt insgesamt eher auf den Vergleich unterschiedlicher Technologien, nicht konkreter Produkte. Einen weiteren interessanten Ansatz stellt ein mit Multiple Criteria Decision Aid (MC- DA) bezeichnetes Verfahren dar, welches in [SRK + 00] auf die Domäne der Bildungssoftware angewandt wird. Analog zu den bereits genannten Veröffentlichungen wird hier unterschieden zwischen der technischen und domänenspezifischen Betrachtung des Evaluierungsproblems. Zur allgemeinen Entscheidungshilfe gibt es eine Reihe weiterer Methoden, die mehr oder minder etabliert sind. Bei der Nutzwertanalyse handelt es sich um eine beliebte Methode, mit welcher mehrere Entscheidungsalternativen gegenübergestellt werden können. Dabei eignet sich dieses Verfahren z. B. auch für die Entscheidung zwischen mehreren möglichen Produktalternativen, bei der auch subjektive, nicht-monetäre Faktoren berücksichtigt werden müssen [Sch03]. Ähnlich zur Nutzwertanalyse, jedoch deutlich simpler, ist die Verwendung einer Entscheidungsmatrix. Eine mathematisch abstraktere und präzisere Variante der Nutzwertanalyse stellt der Analytic Hierarchy Process (AHP) dar; Details zu dieser Methode finden sich z. B. in [SP97]. Trotz dieser bereits vorhandenen Ansätze ist die Evaluierung von Software immer ein schwieriges Unterfangen. Das liegt daran, dass mitunter eine Vielzahl von Attributen betrachtet werden muss, die sich teilweise überschneiden oder gar widersprechen können. Je komplexer die zu untersuchenden Systeme sind, desto umfangreicher wird dementsprechend die Evaluierung. Neben den oben aufgeführten Vorschlägen sind Modelle für die Definition von Softwarequalität von der ISO/IEC entwickelt worden [ISO01]. Auf diesen aufbauend ist mit der Normenreihe bis auch ein Vorgehen zur Evaluierung von Softwareprodukten vorgeschlagen worden [ISO99]. 23

34 3. Kriterien zur Evaluierung von SOA-Produktsuiten 3.2. Vorbetrachtungen zur Evaluierung Es muss festgehalten werden, dass SOA kein Produkt ist, welches man von einem Hersteller gebrauchsfertig erwerben kann. Entsprechende Tools und Suiten können allenfalls Unterstützung bei der Umsetzung der technischen und organisatorischen Anforderungen bieten. Letztlich muss auch das abstrakte Konzept der SOA in konkrete technische Implementierungen umgesetzt werden, sei es in der Form von Integration von Legacy-Anwendung oder der Erstellung komplett neuer Services. Diese Anforderungen versuchen diverse Hersteller mit der Zusammenstellung unterschiedlicher Produkte zu kompletten SOA-Suiten zu erfüllen. Die Verwendung einer vollständigen Produktpalette eines einzelnen Herstellers kann allerdings durchaus nachteilig sein. So macht man sich u. U. auf längere Zeit von diesem Unternehmen abhängig und ist z. B. auf speziellen Support angewiesen. Auch ist eine den Anforderungen genügende Produktlebensdauer nicht immer gewährleistet. Andererseits ist der Einsatz einer wohl zusammengestellten Suite sehr verlockend, da eine unkomplizierte Installation und eine gute Integration aller Komponenten anzunehmen ist. Für ein Unternehmen hat die Verwendung einer kompletten SOA-Suite also potentielle Vorteile gegenüber der eigenständigen Zusammenstellung aus den Komponenten von verschiedenen Herstellern. Dies ist der Grund, weshalb in der vorliegenden Arbeit die Angebote an kompletten SOA-Suiten untersucht werden sollen. Es soll hier nochmals betont werden, dass SOA keineswegs ein allgemeingültig definierter Begriff ist. Daher ist es verständlich, dass jeder Hersteller seine eigenen Vorstellungen von der SOA-Idee hat und bei der Zusammenstellung seiner Produkte möglicherweise andere Schwerpunkte setzt, als ein anderer Hersteller dies tut. Die einzelnen Produkte können daher u. U. nicht immer im direkten Vergleich gesehen werden Vorgehensweise bei der Evaluierung Betrachtet man die Zielvorgaben dieser Diplomarbeit, so wird deutlich, dass keines der vorgestellten Evaluierungsverfahren direkt anwendbar ist, jedoch Teilaspekte wieder aufgegriffen werden können. Da kein Sieger ermittelt und keine strikte Rangfolge unter den Evaluanden bestimmt werden soll, ist klar, dass in der Evaluierung keine Gewichtungen oder konkrete kardinale Bewertungspunkte vergeben werden. Stattdessen sollen die einzelnen Kriterien, bei denen dies quantitativ möglich ist, mit den Attributen»vorhanden«,»nicht vorhanden«,»nicht dokumentiert«bewertet werden. Qualitative Bewertungen werden in den drei Abstufungen»positiv«,»negativ«und»neutral«ausgedrückt. Die geplante Vorgehensweise lässt sich zusammengefasst in die folgenden vier Schritte aufteilen: 1. Vorauswahl der Menge der Evaluierungskandidaten aus den derzeit am Markt verfügbaren Produkten. 24

35 3.4. Entwicklung der Evaluierungskriterien 2. Erstellung eines Modells des Realitätsausschnitts, in welchem die SOA-Suiten eingesetzt werden sollen. Anschließend Ableitung der Evaluierungskriterien aus diesem Modell sowie Aufstellen modellunabhängiger Kriterien. 3. Ermittlung der Produkteigenschaften orientiert an dem Kriterienkatalog. 4. Auswertung der ermittelten Ergebnisse, Bewertung anhand der aufgestellten Kriterien und Aufstellung einer groben Rangfolge der Produkte. Eine Vorauswahl muss getroffen werden, da im Rahmen dieser Arbeit nicht alle auf dem Markt verfügbaren Produkte analysiert werden können. Zudem lassen sich einige bereits zu Beginn aufgrund objektiver oder subjektiver Kriterien von der Kandidatenliste streichen. Die Liste der ursprünglich in Erwägung gezogenen Produkte findet sich in Kapitel 4, zusammen mit den letztlich ausgewählten Kandidaten sowie einer Begründung für deren Auswahl Entwicklung der Evaluierungskriterien Bei der Evaluierung sollen sowohl modellunabhängige als auch -abhängige Aspekte betrachtet werden. Erstere ergeben sich z. B. aus allgemeinen Bewertungsschemen für Softwareprodukte. Unter die möglichen Kriterien fallen Punkte wie Interoperabilität, das Vorhandensein von Dokumentation oder auch allgemeine Aspekte den Anbieter des Systems betreffend [FW95]. Letztere hingegen können abgeleitet werden aus einem Modell, welches das Anwendungsfeld des zu evaluierenden Systems repräsentiert. In den nachfolgenden Abschnitten werden die Kriterien beider Kategorien aufgeführt und beschrieben. Es ist zu beachten, dass die Zuordnung der einzelnen Kriterien zu den beiden Kategorien mitunter nicht immer objektiv und eindeutig vorgenommen werden kann Modellunabhängige Kriterien Zu den modellunabhängigen Kriterien zählen all jene Aspekte, die in keinem direkten Bezug zu dem Einsatzbereich des Softwaresystems stehen. Dabei sind unter anderem den Anbieter des Produkts betreffende Gesichtspunkte von Interesse. Insgesamt ergeben sich die nachfolgend aufgeführten Kriterien und Fragen. Anbieter: Den Anbieter der Suite betreffend sind die folgenden Aspekte zu betrachten: Größe und Geschichte, Stabilität, Reichweite und Marktpräsenz, Mitgliedschaften in Standardisierungsgremien wie z. B. W3C oder OASIS, 25

36 3. Kriterien zur Evaluierung von SOA-Produktsuiten Bisheriges Engagement im SOA-Bereich, Referenzkunden, Produktpflege und Strategie, Support. Verfügbarkeit: Ist das Produkt bereits verfügbar und auf welche Weise kann es bezogen werden? (z. B. über Internet-Download) Kosten: Welche Kosten fallen bei Einsatz der Suite an? Dazu können u. a. Lizenz- und Wartungskosten gezählt werden. Ebenfalls von Interesse ist, unter welchem bzw. welchen Lizenzmodell(en) die Produkte angeboten werden. Dokumentation, Handbücher, Community: Gibt es eine ausreichende Menge an Dokumentationen (Installation, Beispiele, Tutorials) und Handbüchern? Sind sie qualitativ hochwertig? Existiert eine Entwickler- und Benutzergemeinde, über die zusätzliche Informationen und Hilfestellungen erhalten werden kann? (z. B. Foren, User-Groups, Weblogs) Integrationsfähigkeit, Offenheit: Inwieweit lassen sich die Komponenten der Suite mit Produkten anderer Hersteller kombinieren? Hardware-, Softwareanforderungen: Welche Anforderungen werden an die Hardund Software (z. B. Betriebssystem) für die Verwendung der SOA-Suite gestellt? Modellabhängige Kriterien Eine SOA-Suite soll ihren Nutzer (nicht zwangsläufig verkörpert durch eine einzelne natürliche Person) darin unterstützen, eine unternehmensweite SOA einzuführen und zu verwalten. Das Modell, aus welchem die modellabhängigen Kriterien abgeleitet werden, ergibt sich aus dem Anwendungsfeld des Softwaresystems. Für eine SOA-Suite kann das Konzept des Lifecycle (Lebenszyklus) als entsprechendes Modell gewählt werden. Unter dem Lebenszyklus versteht man im Zusammenhang mit Softwareentwicklung die einzelnen Phasen, die ein Produkt durchläuft, angefangen von der Planung bis hin zur Einstellung. In einer SOA lassen sich für einen Service bzw. eine servicebasierte Anwendung (Composite-Anwendung) die folgenden sechs Phasen identifizieren, deren Abfolge in Abbildung 3.1 nochmals graphisch dargestellt ist: Analyse, Modellierung, Design, 26

37 3.4. Entwicklung der Evaluierungskriterien Realisierung, Betrieb (d. h. Erstellung von Composite-Anwendungen) und Überwachung zur Laufzeit, Abkündigung und Einstellung. Abbildung 3.1.: Lifecycle in einer SOA Neben dem Modell des Lebenszyklus lassen sich Bewertungskriterien zusätzlich ableiten aus einem Schichtenmodell, welches die funktionalen und nicht-funktionalen Anforderungen an eine SOA widerspiegelt. In diesem sog. SOA-Stack sind die einzelnen Schichten einer serviceorientierten Architektur aufgeführt. Je nach Umfang kann eine SOA-Suite alle sieben Schichten mehr oder minder vollständig abdecken. Ein solches Grundmodell eines SOA-Stacks ist in Abbildung 3.2 aufgeführt. Das Modell gliedert sich in vier funktionale sowie drei nicht-funktionale Schichten. In Schicht 1 befinden sich Altsysteme oder Applikationen wie z. B. J2EE-,.NET-Anwendungen oder Datenbanken. Schicht 2 beinhaltet die Grundbausteine einer SOA, die Services, welche u. U. auf Systeme aus der darunterliegenden Schicht zugreifen oder diese kapseln. Dabei kann es sich sowohl um zusammengesetzte als auch atomare Dienste handeln. Aus diesen Services wiederum werden in Schicht 3 die Geschäftsprozesse zusammengestellt. Auf diese Prozesse wird schließlich aus der Schicht 4 von den Clients aus zugegriffen. Die nicht-funktionalen Schichten sind in der Abbildung vertikal dargestellt, da sie sich auf alle anderen Schichten auswirken. Schicht 5 ist essentiell und zuständig für die Kommunikation zwischen Service-Nutzern und -Anbietern. Dabei können 27

38 3. Kriterien zur Evaluierung von SOA-Produktsuiten Abbildung 3.2.: Modell eines SOA-Stacks ggf. eine Reihe weiterer Dienste wie Datentransformationen oder Sicherheitsmechanismen in dieser Schicht realisiert werden. Die Quality of Service -Schicht dient dazu, die nicht-funktionalen Anforderungen (Verfügbarkeit, Skalierbarkeit usw.) in einer SOA zu erfüllen und Verstöße gegen diese zu protokollieren. In der letzten Schicht werden all jene Aspekte behandelt, die sich mit dem Thema Governance befassen, darunter z. B. Sicherheit, Leistung oder Monitoring. Aus den Phasen des Lebenszyklus sowie dem SOA-Stack-Modell lassen sich nun die Anforderungen an eine SOA-Suite herleiten. Wie bereits aus Kapitel 2 hervorgegangen ist, gibt es in einer SOA sowohl eine technische als auch eine geschäftsbezogene Sicht. Daher bietet es sich an, die Anforderungen und somit auch die Kriterien zunächst in diese zwei Klassen aufzuteilen. Aus IT-Sicht lassen sich die folgenden Aspekte und damit zusammenhängende Fragen ausmachen: Infrastruktur: Stellt die Suite Komponenten zur Verfügung, mit denen sich Geschäftsanwendungen betreiben lassen, d. h. Laufzeitumgebungen für z. B. J2EE-,.NET- Anwendungen oder Web-Services? Sollen neue Services in der SOA implementiert werden, so wird dies zumeist unter der Verwendung von Web-Services getan. Für die Implementierung der Dienste muss eine Laufzeitumgebung existieren, in welcher diese ablaufen. 28

39 3.4. Entwicklung der Evaluierungskriterien Performance und Verfügbarkeit: Lassen sich die Leistung sowie die Verfügbarkeit der Services auf technischer Ebene überwachen und so mögliche Flaschenhälse aufspüren? Je nach Art des Unternehmens bzw. der eingesetzten Anwendungen kann das Thema Performance ein wichtiger Faktor sein. Wie bereits in Abschnitt 2.4 angesprochen, stellt die Leistungsfähigkeit in einer SOA bisweilen durchaus ein Problem dar. Mögliche Schwachstellen sind in diesem Zusammenhang die Transformation von Daten und eine zu feingranulare Service-Landschaft [Erl07]. Die Verfügbarkeit einzelner Services ist gerade im Hinblick auf die mögliche Wiederverwendung in mehreren Anwendungen wichtig fällt ein Service aus, so sind die abhängigen Anwendungen u. U. nicht mehr lauffähig, sofern es keinen gleichwertigen Ersatzservice gibt, der alternativ verwendet werden kann. Integration und Mediation: Gibt es Unterstützung für die Integration von Altsystemen sowie Kommunikationskomponenten wie z. B. einen ESB? In den meisten (größeren) Unternehmen gibt es eine Vielzahl heterogener Anwendungssysteme, welche bei Einführung einer SOA nicht einfach entfernt werden können [KBS07]. Bei entsprechender Umsetzung der SOA lassen sich solche Altsysteme jedoch in die neue Architektur integrieren dazu sind allerdings entsprechende Kommunikationskomponenten wie z. B. ein ESB vonnöten. Fehlerbehandlung: Wie wird auf Fehler und Ausnahmen reagiert; können diese zentral protokolliert und eingesehen werden? Gerade bei geschäftskritischen Anwendungen ist es unerlässlich, dass die Integrität der einzelnen Prozesse sichergestellt wird. Dies ist besonders schwierig, wenn die einzelnen Schritte des Prozesses aus mehreren Services zusammengestellt sind, wie es in einer SOA der Fall ist. Es sollten Mechanismen vorhanden sein, mit denen sich z. B. technische Ausfälle von Services protokollieren und zurückverfolgen lassen. Sicherheit: Welche Maßnahmen zur technischen Sicherung von Services unterstützt die Suite? Wie in Kapitel 2 dargelegt, stellt die Sicherheit einen sehr wichtigen Aspekt in einer SOA dar. Nach [KBS07] ist das Thema Sicherheit unter den drei Aspekten Authentifizierung, Autorisierung und Vertraulichkeit zu betrachten. Bei der Authentifizierung weist der Service-Nutzer gegenüber einer Instanz (z. B. dem Service selbst) seine Identität nach. Bei der Autorisierung wird dem Aufrufer Zugriff auf bestimmte Ressourcen erlaubt bzw. untersagt. Dies könnten beispielsweise die Nutzung eines bestimmten Services oder die zu diesem Nutzer gehörigen Datensätze einer Datenbank sein. Beim Einsatz von Web-Services mit SOAP könnten hier z. B. WS-Security oder SAML (Security Assertion Markup Language) verwendet werden, welche sowohl Authentifizierung als auch Autorisierung unterstützen [KK07]. Unter Vertraulichkeit versteht man i. A. die Nichtzugänglichkeit vertraulicher Daten für Unbefugte. Erreicht wird dies durch die Verwendung von Verschlüsselungsverfahren, wobei grundsätzlich unterschieden werden 29

40 3. Kriterien zur Evaluierung von SOA-Produktsuiten kann zwischen einer Verschlüsselung auf Transport- und auf Nachrichtenebene [MW07]. Weiterhin kann zusätzlich zur Vertraulichkeit die Nachrichtenintegrität von Interesse sein, welche zumeist über die Verwendung digitaler Signaturen umgesetzt wird. Entwicklung und Deployment: Sind Werkzeuge für die Entwicklung und Hilfestellungen für das Deployment von Services bzw. Composite-Anwendungen vorhanden? Die Entwickler von Services sollten bei ihrer Arbeit idealerweise durch entsprechende Tools unterstützt werden, z. B. über die Integration in Entwicklungsumgebungen. Unterstützung von Standards: Bauen die Komponenten der Suite auf verbreiteten Standards (z. B. SOAP, UDDI, WS-Security, usw.) auf oder werden stattdessen proprietäre Techniken verwendet? Einer der Hauptgedanken des SOA-Konzepts ist die Verwendung offener und verbreiteter Standards. Dadurch steigt die Flexibilität und die Unabhängigkeit von einem einzelnen Softwarehersteller. Verschiedene Hersteller versuchen jedoch häufig durch die Verwendung von proprietären Protokollen oder Formaten eine künstliche Abhängigkeit zu erzeugen. Es ist daher darauf zu achten, dass entsprechende Standards unterstützt werden. Administration: Inwieweit wird dem Entwickler bzw. technischem Administrator Unterstützung bei der Administration der verschiedenen Komponenten geboten, beispielsweise durch graphische Benutzeroberflächen? Bei der Verwaltung komplexer Softwaresysteme ist es u. U. hilfreich, wenn durch geeignete Hilfsmittel eine Gesamtsicht auf das Zusammenspiel der einzelnen Komponenten geboten wird. Dies könnte z. B. eine Art Netzwerkdiagramm sein, in welchem die im Unternehmen vorhandenen Services sowie die Abbildungen auf physikalische Ressourcen dargestellt sind. Bei Einnahme der Geschäftssicht ergeben sich die nachstehenden Faktoren und Fragestellungen: Service-Management und Governance: Wie können Daten zur Laufzeit überwacht werden (Monitoring), z. B. die Einhaltung von SLAs? Gibt es Hilfsmittel für die Versionierung von Services? Sobald eine SOA eine gewisse Größe und Komplexität erreicht hat, müssen auch entsprechende Verwaltungsmaßnahmen durchgeführt werden. Beispielsweise müssen vorhandene Services katalogisiert (z. B. mittels einer Registry) und versioniert werden. Zudem müssen oftmals gewisse Qualitätskriterien definiert, eingehalten und überwacht werden. Eine vollständige SOA-Suite sollte diese Aspekte adressieren und ggf. auch entsprechende graphische Benutzerschnittstellen zur Verfügung stellen. 30

41 3.4. Entwicklung der Evaluierungskriterien Geschäftsprozess-Management und Orchestrierung: Welche Mittel sind vorhanden, um Geschäftsprozesse modellieren, erstellen, verwalten, simulieren und überwachen zu können? Die geschäftlichen Ziele eines Unternehmens sind ein zentraler Aspekt der SOA-Idee. Im Idealfall bietet die Suite also die Möglichkeit, die Geschäftsprozesse des Unternehmens über entsprechende Tools zu modellieren und aus Service-Bausteinen zusammenzusetzen. Insbesondere sollten hier Werkzeuge angeboten werden, die auch durch nicht-techniker nämlich vor allem durch die Entscheidungsträger der Fachabteilungen bedienbar sind. Accounting: Gibt es Unterstützung für Abrechnungsmodelle von Leistungen, also z. B. dem Aufruf von Services? Im Normalfall werden in einer SOA Services lediglich in den Grenzen einen bestimmten Unternehmens genutzt. Bietet ein Unternehmen jedoch nach außen verfügbare, kostenpflichtige Services (wie z. B. eine Adressüberprüfung oder einen SMS-Versand) an, so muss es entsprechende zuverlässige Methoden für die Rechnungsstellung/Abrechnung geben. In größeren Unternehmen ist ebenfalls eine Rechnungsstellung zwischen verschiedenen Abteilungen denkbar. Logging: Können Ereignisse auf Geschäftsprozessebene protokolliert werden und sind die Protokolldaten zugänglich und aufbereitet? Bei Auftreten von Ausfällen müssen u. U. verschiedene Aktivitäten ausgeführt werden, wie z. B. das Senden einer Meldung an einen Benutzer oder die Protokollierung dieses Ausfalls. Dieser Aspekt ist nicht speziell auf SOA beschränkt, sondern trifft auf alle verteilten Architekturen zu. Sicherheit, Auditing: Werden die Themen Nachvollziehbarkeit, Nichtabstreitbarkeit und Revisionssicherheit adressiert? Zusätzlich zu den bereits genannten technischen Sicherheitsanforderungen werden unter gewissen Umständen zusätzliche Sicherheitsaspekte bzw. juristische Anforderungen relevant. Diese Aspekte werden zumeist unter dem Begriff Auditing zusammengefasst. Als Unteraspekt des Logging dient das Auditing dazu, bestimmte rechtliche Anforderungen zu erfüllen. Als Beispiel kann hier das Festhalten einer Transaktion, z. B. der Kauf eines Flugtickets, genannt werden. Im Gegensatz zum Logging ist das Auditing als systemkritische Komponente zu betrachten, bei dessen Ausfall das System als nicht mehr funktionsfähig angesehen werden muss, denn durch das Ausbleiben des Audits könnten rechtliche Bestimmungen verletzt werden. Eine SOA-Suite, die für diese Art von Anwendungen eingesetzt werden soll, könnte also robuste Auditing- Mechanismen beinhalten. Registry/Repository: Ist ein Verzeichnisdienst Bestandteil der Suite bzw. lassen sich externe Verzeichnisse integrieren? Die Bedeutung eines Verzeichnisdienstes wurde bereits in Abschnitt angesprochen. Dieser Aspekt spielt zwar auch in der 31

42 3. Kriterien zur Evaluierung von SOA-Produktsuiten IT-Sicht beispielsweise bei der Entwicklung neuer Dienste eine Rolle, wurde jedoch nur an dieser Stelle aufgenommen Zusammenfassung Der in diesem Kapitel erarbeitete Kriterienkatalog wird nun als Basis für die systematische Betrachtung der einzelnen SOA-Produkte dienen. Die Kriterien ergaben sich zum einen aus allgemeinen, anwendungsunabhängigen Aspekten, zum anderen aus den funktionalen Anforderungen an das zu evaluierende System. Abschließend zeigt Abbildung 3.3 nochmals die vollständige Struktur des Kriterienbaums. 32

43 3.5. Zusammenfassung Abbildung 3.3.: Vollständiger Kriterienkatalog 33

44 4. Evaluierung ausgewählter SOA-Produktsuiten Nachdem im vorangegangenen Kapitel der Kriterienkatalog erarbeitet wurde, soll in den folgenden Abschnitten nun die Evaluierung der SOA-Produkte durchgeführt werden. Dazu werden zunächst die in der initialen Recherche ermittelten Anbieter potentieller Kandidaten aufgeführt, bevor dann die Auswahl und Begründung der tatsächlichen Kandidaten vorgenommen wird. Anschließend werden, entlang des Kriterienkatalogs, die einzelnen Evaluanden untersucht. Die dazu verwendeten Quellen beschränken sich hauptsächlich auf die von den Herstellern zur Verfügung gestellten Produktbeschreibungen und -dokumentationen. Dort fehlende Informationen wurden durch entsprechende Nachfragen bei den Anbietern eingeholt Marktübersicht SOA-Produkte In einer initialen Recherche wurde versucht, eine Marktübersicht über aktuelle SOA- Anbieter und deren Produkte zu erstellen. Es wird darauf hingewiesen, dass diese Zusammenstellung keinerlei Anspruch auf Vollständigkeit erhebt und aufgrund der branchenüblichen Dynamik nur einen Auszug aus dem aktuellen Marktangebot darstellen kann, der lediglich eine zeitlich begrenzte Gültigkeit aufweist. In Tabelle 4.1 sind die ermittelten Produkte sowie deren Hersteller und ggf. Anmerkungen aufgeführt. Es wird deutlich, dass viele Hersteller Produkte im SOA-Umfeld anbieten, es sich dabei jedoch oft nicht um vollständige Abdeckungen der SOA-Anforderungen im Sinne dieser Arbeit handelt. In der Tabelle sind diese Fälle gekennzeichnet mit keine dedizierte SOA-Suite. Trotzdem sind diese Produkte hier aufgeführt und berücksichtigt, um einen gewissen Marktüberblick zu vermitteln Auswahl und Beschreibung der Evaluanden Die Liste der ermittelten Produkte wurde in einem nächsten Schritt mit Blick auf verschiedene Aspekte reduziert auf die Auswahl der endgültigen Kandidaten. Bei deren Auswahl kamen verschiedene Faktoren zum Tragen. Zunächst einmal soll das angebotene Produkt eine möglichst vollständige SOA-Suite sein. Diese Vollständigkeit wurde zunächst ohne Berücksichtigung der Evaluierungskriterien rein intuitiv bewertet. Weiterhin spielte das subjektive Empfinden der Relevanz des Herstellers eine entscheidende Rolle. Eine Ausnahme bildet die Firma Microsoft, die trotz der Tatsache, dass keine spezielle SOA-Suite angeboten wird, in die Evaluierung einbezogen wird. Aufgrund ihrer 34

45 4.2. Auswahl und Beschreibung der Evaluanden Tabelle 4.1.: Auswahl der am Markt verfügbaren SOA-Produkte (September 2007) Hersteller Produkt Anmerkungen AmberPoint SOA Management System Starker Fokus auf Governance, keine dedizierte SOA-Suite BEA WebLogic Platform, AquaLogic IBM IBM SOA Foundation Keine dedizierte SOA-Suite IONA FUSE Basierend auf diversen Open-Source- Produkten JBoss/Red Hat JBoss Enterprise Middleware Suite (JEMS) Microsoft.NET u. BizTalk Keine dedizierte SOA-Suite Oracle Oracle SOA Suite Progress Software Actional und Sonic Keine dedizierte SOA-Suite SOA Software Infrastructure Suite Software AG Crossvision Eventuell Zusammenlegung mit den Produkten der übernommenen Firma webmethods Sun Microsystems Java CAPS TIBCO ActiveMatrix, BusinessWorks Keine dedizierte SOA-Suite webmethods webmethods Anfang 2007 übernommen durch die Software AG, daher ungewisse Produktzukunft speziellen Marktstellung und des hohen Verbreitungsgrades wurde versucht, die von Microsoft angebotenen Produkte dahingehend zu untersuchen, inwieweit sich mit ihnen eine SOA realisieren lässt. Im Folgenden werden die ausgewählten Produkte sowie die Begründung für ihre Auswahl aufgeführt. BEA WebLogic Platform/AquaLogic: Die Firma BEA deckt mit ihren Produkten ein großes Spektrum der SOA-Anforderungen ab und wird daher in die Reihe der Evaluanden aufgenommen. Folgende Komponenten sind laut Produktbeschreibung Bestandteil der aktuellen Version 9.2 der WebLogic Platform: WebLogic Server, Workshop for WebLogic Platform, WebLogic Integration und WebLogic Portal. 35

46 4. Evaluierung ausgewählter SOA-Produktsuiten Zusätzlich werden in der AquaLogic-Familie eine ganze Reihe weiterer SOA-Produkte angeboten, welche jedoch nicht Bestandteil der Basissuite WebLogic Platform sind. Oracle SOA Suite: Oracle ist zum einen als Softwarehersteller (insbesondere Datenbankmanagementsysteme) sehr relevant, zum anderen scheint das angebotene Produkt auf den ersten Blick einen großen Funktionsumfang zu besitzen. Die aktuelle Version 10g der Oracle SOA Suite besteht laut Datenblatt aus den folgenden Komponenten: Oracle BPEL Process Manager, Oracle Business Activity Monitoring, Oracle Business Rules, Oracle Enterprise Service Bus, Oracle Web Services Manager, Oracle JDeveloper 10g sowie Oracle Web Services Registry. 1 Progress Actional/Sonic: Mit den Actional- und Sonic-Produktreihen bietet die Firma Progress einen großen Funktionsumfang, auch wenn es sich nicht um eine ausgewiesene SOA-Suite handelt. In der Actional-Reihe sind mit den Produkten Actional for SOA Operations, Actional for Continuous Service Optimization, Actional for Active Policy Enforcement und Actional for Sonic ESB Management hauptsächlich Komponenten für die Governance einer SOA enthalten. Zusätzlich werden mit der Sonic-Produktfamilie die Bedürfnisse nach einer geeigneten SOA- Infrastruktur angesprochen. Im Rahmen der Evaluierung sollen beide Produktreihen gemeinsam betrachtet werden. Red Hat JBoss Enterprise Middleware Suite (JEMS): Die Firma Red Hat, die den Middlewareanbieter JBoss übernommen hat, ist einer der wichtigsten Vertreter der Open-Source-Branche. Die angebotene Suite ist besonders in Hinblick auf die ausbleibenden Lizenzkosten für kleinere Unternehmen interessant. Red Hat bzw. JBoss stellen in der JEMS aktuell die folgenden Komponenten zur Verfügung: 1 Der Hersteller macht bzgl. des Enthaltenseins der Services Registry an verschiedenen Stellen widersprüchliche Angaben. Nach der Installation der Suite stellte sich heraus, dass diese separat bezogen werden muss. 36

47 4.2. Auswahl und Beschreibung der Evaluanden JBoss Enterprise Application Platform (enthält u. a. JBoss Application Server, Hibernate und Seam), JBoss Enterprise Portal Platform, JBoss jbpm, JBoss Rules sowie JBoss Transactions. Leider muss hier festgehalten werden, dass die Produktdarstellung zum aktuellen Zeitpunkt als nicht sonderlich übersichtlich zu bezeichnen ist. Fest steht, dass JEMS nicht als Komplettprodukt angeboten wird, sondern Red Hat damit die Gesamtheit der JBoss-Middleware-Produkte bezeichnet. Obgleich bewirbt der Hersteller die JEMS als Basis-Suite für eine SOA und daher findet diese Eingang in die Evaluierung. Software AG Crossvision: Neben der Relevanz des Anbieters (besonders im deutschsprachigen Raum) spricht der augenscheinlich große Funktionsumfang für eine Auswahl dieses Produkts. Bei Durchführung der Initialrecherche bestand die angebotene Suite aus sechs verschiedenen Komponenten, die den kompletten Lebenszyklus in einer SOA abdecken sollten. Im Laufe der Evaluierung stellte sich jedoch heraus, dass die Software AG ihr Produkt eingestellt hat und anscheinend mit den webmethods-produkten vereinen möchte. Eine weitergehende Evaluierung der Crossvision-Suite findet folglich nicht statt. Microsoft: Obwohl keine speziellen SOA-Produkte durch Microsoft angeboten werden, spricht die große Marktrelevanz dafür, sich näher mit diesem Anbieter zu beschäftigen. Eine Reihe von Fallstudien zeigt, dass sich mit einer Kombination aus Microsoft-Produkten durchaus eine SOA umsetzen lässt. Demzufolge lassen sich die folgenden Produkte zum Aufbau einer serviceorientierten Architektur verwenden: Windows Server 2003,.NET Framework 3.0 und BizTalk Server Microsoft bezeichnet den BizTalk Server selbst als BPM (Business Process Management)-Server mit erweiterten ESB- und SOA-Funktionen. Als Entwicklungsumgebung wird zusätzlich Microsoft Visual Studio mitbetrachtet. Weitere: Das Produkt der Firma AmberPoint ist sehr stark begrenzt auf den Bereich Governance und erfüllt daher nicht die Minimalanforderungen dieser Evaluierung. IBM bietet zwar eine große Fülle von Produkten im SOA-Umfeld an, jedoch stellt sich das Angebot zum aktuellen Zeitpunkt eher als unübersichtlich, wenig 37

48 4. Evaluierung ausgewählter SOA-Produktsuiten strukturiert und stark fluktuierend dar; die Produkte scheinen sich zudem in ihrer Funktionalität teilweise zu überschneiden. Das auf Open-Source-Produkten basierende IONA FUSE erscheint in der aktuellen Version zu wenig ausgereift und funktionsreich. Ebenso ist das Produkt der Firma SOA Software zu speziell und lässt viele Aspekte unberücksichtigt. Das von Sun beworbene CAPS fokussiert sich stark auf die Integration von Altsystemen und vermittelt derzeit einen eher verwaisten Eindruck, da seitens des Herstellers nur wenige Informationen zu erhalten sind. Die Produkte der Firma TIBCO schließlich erscheinen subjektiv als zu ungeordnet Evaluierung der Produkte Wie bereits eingangs erwähnt, erfolgt die Untersuchung der Evaluanden auf Basis der von den Herstellern zur Verfügung gestellten Produktbeschreibungen sowie -dokumentationen, da eine Untersuchung in einem realen Einsatzumfeld den Rahmen dieser Arbeit sprengen würde. Es ist zu beachten, dass daher das Vorhandensein bestimmter Funktionalitäten auch nur dann erkannt werden kann, wenn diese vom Anbieter entsprechend dokumentiert wurden. Überdies kann die Betrachtung der verschiedenen Produkte je nach Umfang der zur Verfügung stehenden Quellen unterschiedlich umfangreich und detailliert erfolgen Modellunabhängige Kriterien Anbieter In diesem Abschnitt wird auf die den Anbieter der Evaluanden bezogenen Kriterien eingegangen. Die Erhebung der Daten wird auf Basis der von den Herstellern oder Dritten gemachten Angaben (z. B. Hersteller-Websites) sowie subjektiven Einschätzungen durchgeführt. Bezüglich der Einschätzung der (finanziellen) Stabilität der Unternehmen ist anzumerken, dass im Rahmen dieser Diplomarbeit lediglich eine oberflächliche Betrachtung der wirtschaftlichen Aspekte betrieben werden kann. Die Auswertung der einzelnen Kriterien erfolgt in diesem Abschnitt gruppiert nach den Anbietern. BEA Systems Gegründet im Jahre 1995, hat die Firma ihren Hauptsitz in Kalifornien, USA. An insgesamt 91 Standorten verfügt das Unternehmen derzeit über ca Mitarbeiter und zählt damit zu den größeren Softwareherstellern. 2 Der Hauptfokus des Unternehmens liegt dabei auf der Entwicklung von Geschäftsinfrastruktur-Software. Im Geschäftsjahr 2007 wurde ein Umsatz von knapp 1,4 Mrd. US-$ erwirtschaftet, was im 2 Quelle: corporate/ 38

49 4.3. Evaluierung der Produkte Gegensatz zum Vorjahr einen Anstieg von 17% bedeutet. Der Gewinn konnte in den letzten Jahren ebenfalls gesteigert werden. Durch eine Reihe von Übernahmen hat sich außerdem die Anzahl der Mitarbeiter stark erhöht. Der Zustand des Unternehmens ist aufgrund dieser Tatsachen als stabil zu bezeichnen. In der Vergangenheit kursierten allerdings immer wieder Übernahmegerüchte im Internet, als potentielle Käufer werden z. B. Oracle oder Microsoft genannt [Dig07]. Aktuell erhöht einer der Hauptinvestoren des börsennotierten Unternehmens seine Anteile; möglicherweise um das Unternehmen anschließend zu einem Verkauf zu zwingen [Reu07]. Aus dieser Sicht ist die zu erwartende Produktlebensdauer bei einer möglichen Übernahme schlecht abzuschätzen. Die Marktpräsenz des Unternehmens ist relativ schwer einzuschätzen. Ausgehend von den Erlösen durch Softwarelizenzverkäufe bestätigt der Marktforschungsdienstleister Gartner dem Unternehmen einen 10%igen Marktanteil im Bereich Portale und Middleware, noch vor Oracle mit 8% [Pet07]. Als Referenzkunden im Bereich SOA gibt der Hersteller eine ganze Reihe von Unternehmen aus den Branchen Finanzdienstleistungen, Versicherungen und Telekommunikation an; dabei werden teilweise detaillierte Fallstudien mit Beschreibung der Herausforderungen, den Lösungen sowie Resultaten angeboten. Das Engagement BEAs im SOA-Bereich ist als recht groß zu bezeichnen. Neben der WebLogic Platform bietet BEA mit der AquaLogic-Reihe ein Vielzahl weiterer Produkte im SOA-Umfeld an. Viele dieser Produkte wurden durch die Übernahmen anderer Firmen erworben, was eindeutig für das Interesse an einem Ausbau der SOA-Strategie spricht. Die Website des Unternehmens stellt umfangreiche Produktinformationen sowie allgemeine Beschreibungen von SOA-spezifischen Themen zur Verfügung. Eine Anfrage bezüglich der Produktpreisgestaltung wurde innerhalb kürzester Zeit unter Angabe konkreter Daten beantwortet. BEA ist in zahlreichen Standardisierungsgremien vertreten, darunter: OASIS (Gründungsmitglied), OMG, OSOA (Open SOA), The Open Group 3, W3C und WS-I (Web Services Interoperability Organization). Zudem arbeitet BEA augenscheinlich aktiv an der Weiterentwicklung von z. B. Web-Service-Standards (z. B. WS-Transaction oder BPEL4People) mit. Oracle Corporation Hierzulande ist Oracle hauptsächlich bekannt für das gleichnamige Datenbankmanagementsystem Oracle. Das 1977 gegründete Unternehmen, das seinen Sitz ebenfalls in Kalifornien hat, beschäftigt derzeit weltweit rund Mitarbeiter an 145 Standorten. 4 Neben den sehr erfolgreichen Datenbank-Produkten bietet Oracle Software im Bereich Middleware sowie CRM- und ERP-Systeme an. Oracles 3 Gremium für die Verbreitung hersteller- und technologieneutraler Standards, Website: opengroup.org 4 Quellen: [Ora07a] und / free-co-factsheet.xhtml 39

50 4. Evaluierung ausgewählter SOA-Produktsuiten Umsatz lag im Geschäftsjahr 2007 bei ca. 18 Mrd. US-$. Neben dem Umsatz ist auch der Gewinn des Unternehmens in den letzten vier Jahren stetig gewachsen. Durch Übernahmen (z. B. Siebel und PeopleSoft) ist die Anzahl der Mitarbeiter ebenso stark angestiegen. Derzeit versucht Oracle seine Expansionsstrategie durch die Übernahme der BEA Systems fortzuführen zum aktuellen Zeitpunkt wurde ein erstes Übernahmeangebot jedoch abgelehnt. Aus dieser Sicht ist das Unternehmen als finanziell stabil und wachstumswillig zu betrachten. Im Bereich der Datenbanken ist Oracle als weltweiter Marktführer zu bezeichnen. Im Bereich von Anwendersoftware liegt Oracle jedoch derzeit noch hinter dem größten Konkurrenten in diesem Bereich, dem Walldorfer Softwarehersteller SAP AG [man07]. Referenzkunden für SOA präsentiert Oracle auf der Unternehmens-Website aus den verschiedensten Branchen. Allerdings sind die meisten der aufgeführten Beispiele bereits älteren Datums und berichten oftmals lediglich von der Einführung eines speziellen Oracle-Produkts wie einer Datenbank oder Teile aus der Fusion-Produktpalette. Hier liegt die Vermutung nahe, dass die Referenzliste aus marketingstrategischen Gründen etwas angereichert wurde. Der Bereich SOA ist für Oracle sicherlich bisher nur als Nebenschauplatz zu betrachten. Die Website des Unternehmens bietet jedoch bereits eine ganze Reihe von SOAspezifischen Informationen und Dokumentationen. Mit dem jüngsten Übernahmeangebot an BEA zeigt sich außerdem, dass Oracle offensichtlich Interesse daran hat, das Produktportfolio im Bereich Middleware und SOA zu erweitern bzw. zu verbessern. Wie BEA auch, engagiert sich Oracle in zahlreichen Standardisierungsgremien, u. a.: ACORD (Association for Cooperative Operations Research and Development), OASIS (Sponsor), OMG, OSOA, The Open Group, W3C und WS-I. Auch Oracle trägt zu der Weiter- und Neuentwicklung diverser Standards und Spezifikationen (z. B. UDDI v3 oder BPEL4People) bei. Progress Software 1981 wurde das Unternehmen ursprünglich unter dem Namen Data Language Corporation gegründet und beschäftigt heute rund 1600 Mitarbeiter in 90 Ländern der Welt. 5 Der Hauptsitz des Unternehmens befindet sich im US-amerikanischen Massachusetts. Progress bietet hauptsächlich Software für den Unternehmenseinsatz an. Der Umsatz des Unternehmens im Geschäftsjahr 2006 betrug etwa 450 Mio. US-$. Gegenüber den Vorjahren bedeutet dies zwar einen Anstieg, jedoch sank gleichzeitig der Gewinn. Ebenso ist ein leichter Rückgang der Mitarbeiterzahlen festzustellen. Durch eine Reihe von Übernahmen in den letzten Jahren (z. B. Actional und Pantero) verstärkt das Unternehmen jedoch sein Engagement im SOA-Bereich. Im ESB-Markt scheint Progress eine starke Position zu besetzen zumindest ernennt der Marktforscher Gartner den Progress Sonic ESB im Jahr 2006 zum Marktführer. 5 Quellen: und com/progress-software/--id /free-co-factsheet.xhtml 40

51 4.3. Evaluierung der Produkte Als Referenzkunden nennt Progress zahlreiche Beispiele aus den Bereichen Finanzen, Telekommunikation, Einzelhandel und öffentliche Verwaltung. Auch wenn jeweils Fallstudien zu den einzelnen Kunden vorhanden sind, so werden aus dem Bereich SOA keine speziellen Beispiele genannt. Durch die Übernahme der u. a. auf SOA spezialisierten Firma Actional im Jahr 2006 wurde das Produktportfolio des Unternehmens deutlich in Richtung SOA ausgebaut. Die Websites der verschiedenen Produktreihen, die leider etwas unübersichtlich verteilt sind, bieten hauptsächlich Informationen zu den Produkten sowie einige allgemeine SOA-Artikel. Progress konnte leider keine Antwort auf eine Anfrage bzgl. der Preisgestaltung ihrer Produkte liefern. Als etwas kleinerer Softwarehersteller ist das Unternehmen in nicht ganz so vielen Gremien vertreten, darunter: OASIS (Sponsor), OSOA, W3C und WS-I. Aktiv an der (Weiter-)Entwicklung von Web-Service-Standards scheint Progress nicht beteiligt zu sein, sondern gehört eher zu denjenigen, die die Standards in ihren Produkten verwenden. Red Hat Die Firma Red Hat wurde 1993 im US-Bundesstaat North Carolina gegründet und beschäftigt weltweit ca Mitarbeiter. 6 Durch die Übernahme des 1991 gegründeten Anbieters von Middleware-Produkten JBoss baute das auf Linux spezialisierte Unternehmen seine Position im Open-Source-Bereich aus. Red Hat bietet hauptsächlich Software-Abonnements sowie -Support im Bereich Linux und Open-Source an. Im Geschäftsjahr 2007 wurde ein Umsatz von ca. 400 Mio. US-$ erwirtschaftet. Damit konnte dieser im Vergleich zu den Vorjahren, ebenso wie der Gewinn, gesteigert werden. Die Anzahl der Mitarbeiter ist innerhalb eines Jahres um knapp 700 angestiegen. Red Hat sieht sich selbst mit den Produkten Red Hat Enterprise Linux und der JBoss Enterprise Middleware als Marktführer im Bereich Enterprise-Linux bzw. Open-Source- Middleware. Auf ihrer Website veröffentlicht die Firma Referenzkunden u. a. aus den Branchen Finanzdienstleistung, Gesundheitswesen, Bildung und Telekommunikation. Das Engagement der Firma Red Hat im Bereich SOA lässt sich als eher zurückhaltend bezeichnen. Ursprünglich lediglich im Gebiet Enterprise-Linux tätig, kam erst mit der Übernahme von JBoss der Aspekt Middleware und SOA hinzu. So sind auch die Informationen auf der Website Red Hats zum Thema SOA eher dürftig; auch auf den Seiten von JBoss wird die JEMS nur sehr knapp beworben und beschrieben. Red Hat bzw. JBoss sind vertreten in den folgenden Gremien: OASIS (Sponsor), OMG, OSOA, The Open Group, W3C und WS-I. JBoss trägt zudem eigenen Angaben zufolge durch die Mitarbeit in den Gremien aktiv zu der Weiterentwicklung diverser Standards (z. B. Java-Spezifikationen, WS-Transaction und auch WS-BPEL) bei. 6 Quellen: und hoovers.com/red-hat/--id /free-co-factsheet.xhtml 41

52 4. Evaluierung ausgewählter SOA-Produktsuiten Microsoft Corporation Der weltweit größte und sicherlich auch bekannteste Softwarehersteller wurde im Jahre 1975 gegründet und hat seinen Hauptsitz im US-Bundesstaat Washington. 7 Derzeit arbeiten an 102 Standorten knapp Mitarbeiter für die Firma. Neben den bekannten Windows-Betriebssystemen bietet Microsoft eine Vielzahl weiterer Software-Produkte wie z. B. Bürosoftware oder Entwicklungswerkzeuge an. Daneben wird auch Computer-Hardware entwickelt. Der Umsatz Microsofts belief sich im Geschäftsjahr 2007 auf ca. 51,2 Mrd. US-$. Im Laufe der letzten vier Jahre sind sowohl Umsatz als auch Gewinn beständig gestiegen, ebenso die Anzahl der Mitarbeiter. Das Unternehmen Microsoft genießt mit seiner nahezu monopolartigen Marktstellung gewiss eine Sonderstellung unter den Softwareherstellern. Im Bereich der Betriebssysteme ist diese Marktpräsenz besonders ausgeprägt und allseits bekannt. Dabei werden auch in vielen Unternehmen Microsoft-Produkte eingesetzt. Gerade für diese Firmen ist es u. U. interessant, eine SOA-Lösung auf Basis der bereits vorhandenen Microsoft-Produkte zu realisieren. Das Engagement Microsofts im Bereich SOA wurde von vielen Seiten lange als nicht vorhanden bezeichnet. Erst in der jüngeren Vergangenheit scheint es seitens des Herstellers in diesem Bereich verstärkte Aktivitäten zu geben. Die im Internet zur Verfügung gestellten Informationen zum Thema SOA sind dabei jedoch noch eher knapp und wenig zugänglich. Dabei scheint dieses bisher zurückhaltende Verhalten sehr verwunderlich, gehört Microsoft doch zu einem der aktivsten Treiber der Web-Service- und auch XML-Spezifikationen. Microsoft wird oftmals die Behinderung oder Ignoranz gegenüber offener Standards vorgeworfen. Jedoch gerade im Bereich der Web-Services ist das Unternehmen als Mitglied diverser Gremien (darunter u. a. ACORD, OASIS (Sponsor), OSOA, W3C und WS-I) sehr aktiv. Eine Mitarbeit bzw. Entwicklung ist z. B. bei den folgenden Standards und Spezifikationen dokumentiert: SOAP, WSDL, WS-Addressing, WS-Eventing oder auch WS-Transaction Verfügbarkeit und Support Die BEA WebLogic Platform ist aktuell verfügbar und kann über einen Internet-Download bezogen werden, in dem die komplette Suite enthalten ist. Dazu wird zunächst eine einfache Registrierung auf der Website verlangt. Für Evaluierungs-Zwecke erlaubt BEA eine zeitlich uneingeschränkte, kostenfreie Nutzung der Software, für den Entwicklungsund Produktiveinsatz werden dann Lizenzgebühren fällig. Support bietet BEA lediglich für den kommerziellen Einsatz der Produkte an; bei Erwerb dieser muss gleichzeitig ein entsprechender Support-Vertrag abgeschlossen werden. Die Oracle SOA Suite kann gleichfalls über einen einzigen Internet-Download bezogen werden. Eine Registrierung ist in diesem Falle nicht vonnöten. Ähnlich wie BEA bietet Oracle an, die Suite zeitlich unbeschränkt für die Erstellung eines einzigen Pro- 7 Quelle: 42

53 4.3. Evaluierung der Produkte totypen zu verwenden. Oracle bietet für die Evaluierungs-Version ebenfalls keinen offiziellen Support an. Für reguläre Kunden hat Oracle diverse Support-Varianten im Angebot, die sich dabei nach den jeweiligen Kundenanforderungen richten. Die Produkte der Actional-Reihe sind nur auf Anfrage zu beziehen. Ausnahme bildet Actional for SOA Operations, welches nach einer Registrierung über die Website des Herstellers in einer 30 Tage gültigen Testversion bezogen werden kann. Support bietet der Hersteller seinen Kunden in drei verschiedenen Qualitäts- und Preisstufen an. Die Verfügbarkeit des Produkts JEMS ließ sich aus den Angaben des Herstellers Red Hat nicht ableiten. Einzelne zu der Suite gehörende Komponenten lassen sich jedoch auf der Website des Herstellers nach Ausfüllen eines Registrierungsformulars herunterladen. Das Geschäftsmodell des Unternehmens sieht es vor, u. a. optionale Support- Veträge für die vertriebenen Open-Source-Produkte anzubieten. Dabei wird grundsätzlich unterschieden zwischen zwei Qualitäts- bzw. Preisstufen (Standard und Premium). Microsoft Windows Server, BizTalk Server, das.net-framework sowie Visual Studio sind derzeit alle verfügbar und können von dem Hersteller teils in verschiedenen Editionen erworben werden. Zusätzlich sind alle Produkte auch in zeitlich begrenzten Test-Versionen über das Internet erhältlich, für deren Bezug eine Registrierung nötig ist: Das Windows Server-Betriebssystem lässt sich in der Version 2003 für 180 Tage testen, BizTalk Server 2006 für 120 Tage und Visual Studio für 90 bzw. 180 Tage. Außerdem gibt es eine für nicht-kommerzielle Zwecke kostenfreie, zeitlich unbeschränkte, aber im Funktionsumfang reduzierte Version des Visual Studios. Das.NET-Framework in der Version 3.0 ist ebenfalls kostenfrei erhältlich. Microsoft bietet eine Fülle verschiedener Support-Modelle an, deren komplette Auflistung hier nicht erfolgen soll. 8 Für den Essential Support, welcher eine 24x7-Unterstützung beinhaltet, werden in der Basisvariante beispielsweise derzeit 8800 e pro Jahr zzgl. MwSt berechnet Sonstige Kriterien Kosten Auf Anfrage (Stand: Mitte Oktober 2007) teilte BEA mit, dass sich die Preise für die Lizenzen nach der Anzahl der CPUs berechnet, auf denen die Software ausgeführt wird. Der Preis für die WebLogic Platform beträgt demnach ca e (ca US-$) pro CPU. Bei Einsatz unter Linux auf einer S/390 oder z/series-plattform beträgt der Preis etwa das zweifache. Zusätzlich muss zwingend ein Vertrag über eine von zwei möglichen Support-Varianten abgeschlossen werden, für den zusätzliche Kosten in Höhe von 18 bzw. 21% des jeweiligen Nettolizenzpreises fällig werden. Bestandteil der Support-Leistungen sind Produkt-Updates sowie technische Unterstützung per E- Mail, Telefon und Internet je nach Variante mit unterschiedlicher Verfügbarkeit. Oracle veröffentlicht in [Ora07b] u. a. die Preise für die SOA Suite. Die Lizenzkosten pro CPU betragen derzeit US-Dollar. Zusätzlich wird ein optionales Support- 8 Eine Übersicht findet sich unter der Adresse 43

54 4. Evaluierung ausgewählter SOA-Produktsuiten Paket für US-Dollar angeboten, in dem sowohl Produkt-Updates als auch technischer Support per Internet oder Telefon enthalten sind. Die Firma Progress macht auch auf Nachfrage leider keine Angaben zu den Preisen ihrer Produkte oder der Support-Dienstleistungen. Da es sich bei den Produkten von RedHat/JBoss um Open-Source-Software handelt, werden hier keinerlei Lizenzkosten für die eigentliche Software fällig. Stattdessen erhält der Kunde neben der Software in einem obligatorischen Abonnement Support- Dienstleistungen. Diese beinhalten neben Produkt-Updates auch technischen Support mit unterschiedlichen Verfügbarkeitszeiten. Leider konnten von dem Unternehmen keine konkreten Angaben zu den Preisen für die JEMS eingeholt werden. Summiert man jedoch die angegebenen Einzelpreise der Abonnements (jeweils für bis zu 4 CPUs) für die Produkte Enterprise Application Platform, Enterprise Portal Platform, Hibernate, Rules sowie jbpm, so erhält man für die Standard-Variante einen Gesamtpreis von bzw US-Dollar für die Premium-Variante. Microsoft bietet durch verschiedene Produktvarianten eine sehr differenzierte Preisgestaltung. Je nach Anforderungen des Unternehmens können so unterschiedliche Funktionsumfänge erworben werden. Hier sollen aus Übersichtsgründen lediglich die Preise der bestausgestattetsten Varianten aufgeführt werden. Für den Windows Server 2003 in der Enterprise Edition werden derzeit rund 4000 US-Dollar fällig. Der BizTalk Server 2006 kostet, bei einer Lizensierung pro CPU, knapp US-Dollar. Für Visual Studio werden in der Professional Edition derzeit ca. 800 US-Dollar fällig. Interessant ist die Möglichkeit, Lizenzen für Microsoft-Produkte auch auf Raten zu kaufen oder zu mieten. Zusätzlich gibt es für Unternehmen die Möglichkeit, durch den Erwerb von Volumenlizenzen Kosten zu sparen. Dokumentation, Handbücher, Community BEA bietet unter der Internet-Adresse ein umfangreiches Portal mit Produktdokumentationen, aus welchen alle technischen Angaben in den nachfolgenden Kapiteln entnommen wurden. Zusätzlich lässt sich die Dokumentation der jeweiligen Produkte in einzelnen PDF- Dokumenten herunterladen. Der Umfang und die Qualität der Dokumentationen lässt sich durchweg als positiv bezeichnen, auch wenn es teilweise etwas umständlich war, zu der jeweils richtigen Version der Dokumentation zu navigieren. Neben Installationsanleitungen sind auch eine Vielzahl von Fallbeispielen und Tutorials dokumentiert. Daneben gibt es eine umfangreiche und sehr aktive Community 9, in welcher diverse Foren zu allen Produkten, Artikel und Blogs vereint sind. Oracle bietet Dokumentationen seiner Produkte unter der Adresse oracle.com/technology/documentation ebenfalls über das Internet an. Dabei gibt es hier keine spezielle Dokumentation für die SOA Suite, sondern nur für die einzelnen Komponenten. In dem herunterladbaren Paket befinden sich dann allerdings Di- 9 s. 44

55 4.3. Evaluierung der Produkte rektlinks zu diversen Dokumentationen, die auch die SOA Suite als solche thematisieren. Zusätzlich gibt es eine optional beziehbare Demo-Anwendung samt Dokumentation, anhand derer die Funktionalitäten der SOA Suite präsentiert werden sollen. Für die Verwendung dieser Beispiel-Anwendung benötigt man jedoch noch eine Oracle- Datenbank, die sich allerdings kostenfrei herunterladen lässt. Neben einer offiziell von Oracle betriebenen Community 10 mit sehr aktiven Foren zu zahlreichen produkt- und technologiespezifischen Themen gibt es im Internet außerdem diverse von Privatpersonen oder anderen Firmen betriebene Foren. Überdies stellt Oracle eine Auflistung 11 von Weblogs von Angestellten und anderen Personen zur Verfügung, die sich mit vielen Aspekten der Oracle-Produkte beschäftigen. Die Firma Progress bietet für ihre Actional-Produkte außer knapper Produktdatenblätter keine frei zugänglichen Dokumentationen im Internet an, ebensowenig gibt es ein offizielles Forum. Im Folgenden werden alle technischen Informationen den jeweiligen Produktdatenblättern entnommen. Das Unternehmen betreibt ein Weblog, welches u. a. diverse Themen im SOA-Umfeld behandelt. Red Hat bzw. JBoss bietet im Internet unter der Adresse index zu allen Produkten umfangreiche Dokumentationen. Diese sind dabei jedoch ähnlich wie bei Oracle aufgeteilt auf die einzelnen Komponenten der JEMS und müssen separat bezogen werden. Rund um die JBoss Open-Source-Produkte existiert eine recht große Entwicklergemeinde, die aktiv an der Weiterentwicklung und Verbesserung der Produkte mitarbeitet. Ebenso gibt es neben einer offziellen Community 12 im Internet diverse weitere Foren und Weblogs, die sich mit den JBoss-Produkten beschäftigen. Microsoft stellt im Internet umfangreiche Dokumentationen und Hilfen zu seinen Produkten bereit. Mit dem Microsoft Developer Network (MSDN) gibt es außerdem eine große Community für Anwender der Microsoft-Entwicklungsprodukte. Aufgrund der großen Verbreitung der Microsoft-Produkte gibt es zudem unzählige Foren, User- Groups und Weblogs, die sich mit diesen Produkten beschäftigen. Microsoft stellt ähnlich wie Oracle auch ein Verzeichnis dieser Communities bereit. 13 Integrationsfähigkeit BEA betont in der Produktbeschreibung der WebLogic Platform die Verwendung offener Standards, die dazu führen würde, dass sowohl andere Produkte aus dem eigenen Hause als auch von Fremdherstellern mit der Suite kombiniert werden könnten. Weiterhin ließen sich dadurch bestehende Systeme einfach anbinden und Eigenentwicklungen integrieren. Die Produkte der Firmen Oracle und Progress sind nach Angaben der Hersteller 10 s s s z. B. für Deutschland: 45

56 4. Evaluierung ausgewählter SOA-Produktsuiten ebenfalls kombinierbar mit einer Vielzahl von Produkten anderer Anbieter. Red Hat hat sich gleichermaßen die Verwendung offener Standards und der Interoperabilität auf die Fahnen geschrieben. Auch Microsoft verspricht durch die konsequente Verwendung offener Standards eine hohe Interoperabilität. Außerdem sollen sowohl proprietäre als auch standardbasierte Systeme integriert werden können. Hardware- und Softwareanforderungen BEA gibt für die WebLogic Platform die folgenden minimalen Hardwareanforderungen an: Prozessor: 1 GHz CPU empfohlen Speicher (RAM): minimum 1 GB, empfohlen 2 GB Festplattenspeicher: ca. 1,8 GB Sonstiges: 8-Bit Farbtiefe für graphische Installationsoberfläche Oracle gibt keine speziellen Angaben für die Anforderungen der SOA Suite heraus, jedoch wird empfohlen, sich an den Angaben für den Oracle Application Server sowie ESB Server zu orientieren: Prozessor: mind. 1 GHz CPU Speicher (RAM): minimum 1,5 GB Speicher (virtuell): minimum 1535 MB Festplattenspeicher: ca. 2 GB Sonstiges: 8-Bit Farbtiefe für graphische Installationsoberfläche Die Firma Progress gibt in den öffentlich zugänglichen Datenblättern keinerlei Hardwareanforderungen an. Red Hat macht ebenfalls keine Anforderungsangaben für die komplette JEMS. Für die Enterprise Application Platform werden jedoch folgende Anforderungen gestellt: Prozessor: mind. 400 MHz CPU Speicher (RAM): minimum 512 MB Festplattenspeicher: ca. 100 MB Je nach gewählter Variante und Kobination der einzelnen Produkte ergeben sich für die Microsoft-Produkte verschiedene Hardwarenforderungen. Beispielhaft seien hier die Angaben für den BizTalk Server 2006 aufgeführt: 46

57 4.3. Evaluierung der Produkte Prozessor: mind. 1 GHz CPU Speicher (RAM): minimum 1 GB Festplattenspeicher: ca. 15 GB Sonstiges: Display mit SVGA-Auflösung Bei den Angaben der Hardwareanforderungen ist zu beachten, dass diese sich teilweise nur auf eine einzelne Komponente beziehen bei Verwendung eines Gesamtpakets erhöhen sich die Anforderungen also möglicherweise. Zusätzlich ist von Interesse, auf welchen Plattformen (Hardwarearchitektur und Betriebssystem) die jeweiligen Produkte lauffähig sind soweit von den Herstellern publiziert, sind diese Angaben in Tabelle 4.2 aufgeführt. Tabelle 4.2.: Unterstützte Plattformen (Hardware und Betriebssystem) Hersteller und Produkt Unterstützung CPUs Betriebssysteme BEA, WebLogic Platform x86, EM64T/AMD64, Itanium, SPARC, PA-RISC, POWER Oracle, SOA Suite x86, Itanium, SPARC, PA-RISC, POWER, IBM zseries Progress, Actional u. Sonic keine Angaben Windows, Linux, Unix (Sun Solaris, HP UX, IBM AIX) Windows, Linux, Unix (Sun Solaris, HP UX, IBM AIX) Windows, Red Hat (Enterprise) Linux, Red Hat pseries, Unix (Sun Solaris, HP UX, IBM AIX) Red Hat, JEMS keine Angaben Windows, Red Hat Enterprise Linux, Novell SUSE Linux, Unix (Sun Solaris, HP UX, IBM AIX) Microsoft,.NET u. BizTalk x86, x64, Itanium Windows Zusammenfassung Tabelle 4.3 fasst die wichtigsten Ergebnisse dieses Abschnitts nochmals zusammen. Die aufgeführten Bewertungen sind dabei hauptsächlich auf subjektiven Empfindungen basiert und enthalten keinerlei konkrete Bewertungspunkte oder -noten Modellabhängige Kriterien Nachfolgend werden die Evaluanden mit Blick auf die erarbeiteten modellabhängigen Kriterien aus IT- und Geschäftssicht untersucht. Dabei werden die Evaluanden grup- 47

58 4. Evaluierung ausgewählter SOA-Produktsuiten Tabelle 4.3.: Zusammenfassung der Bewertung modellunabhängiger Kriterien Hersteller und Produkt Kriterien Anbieter Sonstige Größe (Mitarbeiter) Stabilität Marktpräsenz Referenzen SOA-Engagement Produktpflege Support Verfügbarkeit Kosten Doku, Community Standardisierungsgremien Integrationsfähigkeit BEA, WebLogic Platform 4200 A D D D D D D D C D A Oracle, SOA Suite D D A A D D D D A D A Progress, Actional u. Sonic 1600 D A A D A A A A C A Red, Hat JEMS 2000 D A C A A D D A D D A Microsoft,.NET u. BizTalk D D A A D D D D A D A Legende: nicht bekannt, C»negativ«, A»neutral«, D»positiv«piert nach den einzelnen Kriterien betrachtet, um für den Leser eine gute Vergleichsmöglichkeit zu erreichen IT-Sicht Infrastruktur Als infrastrukturbildende Komponente beinhaltet die BEA WebLogic Platform den WebLogic Server. Dabei handelt es sich um einen Java-basierten Applikationsserver, welcher neben einer Laufzeitumgebung für Java-Enterprise-Anwendungen auch native Unterstützung für Web-Services bietet. Die Oracle SOA Suite enthält als Basiskomponente den Oracle Application Server, welcher ebenso wie der BEA WebLogic Server Unterstützung für Webapplikationen, J2EE- Anwendungen und Web-Services bietet. Progress bietet in ihrer Produktpalette keine Infrastrukturkomponenten wie Applikationsserver o. ä. an. In der JBoss Enterprise Middleware Suite ist mit dem JBoss Application Server ein Java- Applikationsserver enthalten, der sowohl J2EE-Anwendungen als auch Web-Services unterstützt. Microsofts Windows Server 2003 beinhaltet neben den Funktionen eines Server-Betriebssystems auch das.net-framework, mit dem sich Geschäftsanwendungen entwickeln und betreiben lassen. Teil dieses Entwicklungsframeworks ist außerdem mit der WCF (Windows Communication Foundation) eine Komponente, die u. a. die Entwicklung von Web-Services ermöglicht. Weiterhin bietet der Microsoft Windows Server die 48

59 4.3. Evaluierung der Produkte Möglichkeit, Web-Applikationen zu betreiben. Performance und Verfügbarkeit BEA bietet im Internet umfangreiche Dokumentationen zum Thema Performance-Verbesserung und Aufspüren von Flaschenhälsen bei Verwendung des WebLogic Servers. Dabei werden hautpsächlich manuelle Methoden beschrieben. Die Überwachung der Leistung ist außerdem mittels der Administration Console sowie über externe Schnittstellen auch mit Anwendungen von Drittanbietern möglich. Das in der Suite enthaltene WegLogic Integration verfügt über eine graphische Oberfläche, mithilfe welcher sich Leistungs- und Verfügbarkeitsaspekte überwachen lassen. Oracle stellt ebenfalls Dokumentationen zum Thema Performance zur Verfügung. Über die webbasierte Application Server Control-Schnittstelle können zudem Angaben zur Verfügbarkeit und Belastung des Applikationsservers eingesehen werden. Der in der Suite enthaltene Web Services Manager ermöglicht es, u. a. Leistungsaspekte der erstellten Web-Services zu überwachen. Mit Actional for SOA Operations bietet Progress ein Produkt, welches speziell für die Überwachung von Leistung und Verfügbarkeit von Services in einer SOA konzipiert wurde. Dabei sollen vorhandene Services durch die Software automatisch erkannt, über eine graphische Oberfläche visualisiert und anschließend überwacht werden. Auf diese Weise sollen Leistungs- und Verfügbarkeitsprobleme möglichst früh aufgedeckt und diese durch entsprechende Warnungen kommuniziert werden. In der JEMS von Red Hat sind keine Werkzeuge und Oberflächen zur Überwachung der Infrastruktur vorhanden. In der Dokumentation des Application Servers wird lediglich eine Schnittstelle beschrieben, über die sich Laufzeitinformationen der Server- Instanz abfragen lassen. Zur Überwachung der Leistungsfähigkeit und Verfügbarkeit der Web-Services bietet Microsofts WCF die Möglichkeit, diverse Indikatoren über verschiedene graphische Schnittstellen zu visualisieren. Der BizTalk Server stellt mit dem Performance Monitor eine Oberfläche zur Überwachung diverser Leistungsaspekte zur Verfügung. Zudem stellt Microsoft im Internet diverse Dokumentationen bereit, die sich mit den Themen Performanceüberwachung und Verfügbarkeit beschäftigen. Integration und Mediation Mit WebLogic Integration bietet BEA in der Suite ein Produkt, mit dem sich bestehende Anwendungen mit einer Service-Schnittstelle versehen sowie Altsysteme in die SOA einbinden lassen. Dazu werden u. a. Funktionen zur Datentransformation bereitgestellt. Einen kompletten ESB bietet BEA lediglich in der AquaLogic-Produktfamilie, welche nicht Bestandteil der Web-Logic Platform ist. Web- Logic Integration kann dabei zusammen mit dem AquaLogic Service Bus verwendet werden und sowohl als Service-Anbieter als auch -Nutzer auftreten. In Oracles SOA Suite ist der Oracle Enterprise Service Bus enthalten, der Kommuni- 49

60 4. Evaluierung ausgewählter SOA-Produktsuiten kations- und Routingdienste zur Verfügung stellt, mit denen Services und bestehende Anwendungen integriert werden können. Zudem werden eine Reihe von Datentransformationen, inhaltsbasiertes Routing und Filtering sowie eine Anzahl von Adaptern bereitgestellt, mit denen sich bestehende Systeme anbinden lassen. Der Oracle ESB verfügt über eine graphische Benutzeroberfläche, über die sich Einstellungen vornehmen lassen und die angeschlossenen Systeme visualisiert werden. In der Actional-Suite sind keine Integrations-Komponenten enthalten. Mit dem Sonic ESB bietet Progress einen funktionsreichen Service Bus an. Für die Zusammenarbeit mit dem Sonic ESB beinhaltet die Actional-Reihe das Produkt Actional for Sonic ESB Management. Damit ist es möglich, die an den ESB angeschlossenen Services und auch IT-Systeme (wie J2EE-Anwendungen oder Datenbanken) zu visualisieren und verschiedene Laufzeitinformationen anzuzeigen und abzufragen. Red Hats JEMS enthält keine Integrations- und Mediations-Komponenten. Microsofts BizTalk Server beinhaltet neben den BPM-Funktionalitäten eine Reihe von Adaptern, mit denen sich auch proprietäre Systeme unterschiedlicher Hersteller in eine SOA integrieren lassen. Weiterhin bietet BizTalk Funktionen eines ESB wie Routing und Datentransformationen. Fehlerbehandlung Fehlerausgaben werden in der BEA WebLogic Platform jeweils durch die Produkte WebLogic Server und WebLogic Integration protokolliert und sind über die Management-Konsolen einsehbar. Oracles BPEL Process Manager unterstützt die WS-BPEL 1.1 Spezifikation, in der auch Maßnahmen für die Behandlung von Ausnahmen sowie Zurücknahme von Aktionen (im Zusammenhang mit Transaktionen) vorgesehen sind. Der Oracle Enterprise Service Bus bietet ebenfalls die Möglichkeit, auf Fehler durch verschiedene Maßnahmen zu reagieren auftretende Fehler werden dabei außerdem über die graphische Oberfläche visualisiert. Auftretende Fehler wie z. B. Systemausfälle oder Verletzungen von SLAs werden von Progress Actional for SOA Operations festgehalten und auf anschauliche Weise visualisiert. Dabei wird der komplette Pfad vom fehlerauslösenden Aufruf bis hin zur Wurzel des Fehlers ermittelt und in einer baumartigen Darstellung angezeigt. Mit dem Sonic BPEL Server stellt Progress außerdem einen WS-BPEL 2.0-Server zur Verfügung, welcher u. a. die Standard-Funktionen zur Behandlung von Ausnahmen beinhaltet. Red Hat macht keine konkreten Angaben zur Behandlung von Fehlern in ihren Produkten. Für die Behandlung fehlerhafter Orchestrierungsnachrichten bietet der BizTalk Server von Microsoft die Möglichkeit, solche Nachrichten gesondert zu behandeln, also beispielsweise per zu versenden. Weitere Details bzgl. der Behandlung von Fehlern konnten leider nicht ermittelt werden. 50

61 4.3. Evaluierung der Produkte Sicherheit Auf technischer Ebene bietet der BEA WebLogic Server mit dem Security Framework eine umfangreiche Unterstützung für sicherheitsrelevante Themen. Im Hinblick auf Web-Services werden sowohl die Sicherung auf Nachrichten- als auch auf Transportebene unterstützt. Zusätzlich können Zugriffsrechte verwendet werden, mit denen eine rollenbasierte Rechtevergabe für den Zugriff auf einzelne Services ermöglicht wird. Technisch realisiert werden die Sicherheitsfunktionen durch die Unterstützung des OASIS-Standards WS-Security sowie der Standards WS-Trust, WS-SecureConversation, WS-SecurityPolicy und der SAML. Mit dem Web Services Manager enthält Oracles SOA Suite ein Produkt, mit dem sich u. a. (Sicherheits-)Policies für Web-Services definieren und verwalten lassen. Auch hier wird eine graphische Schnittstelle geboten, über die die entsprechenden Einstellungen vorgenommen werden können. Es werden dabei alle relevanten Sicherheitsmechanismen wie Nachrichtenverschlüsselung und -signierung unterstützt. Oracle stellt zudem ausführliche Anleitungen zur Sicherung von Web-Services bereit. Progress offeriert mit Actional for Active Policy Enforcement ein Produkt, mit dem sich Sicherheits-Policies zentral erstellen und verwalten lassen. Der Hauptgedanke dabei ist, die Entwicklung von Services unabhängig von den Policies zu halten, um so eine konsistente Anwendung der Richtlinien über die gesamte SOA zu ermöglichen. Durch die Unterstützung des Standards WS-Security werden u. a. die Verschlüsselung und Signierung von Nachrichten ermöglicht. Die Web-Service-Implementierung in Red Hats JEMS unterstützt die Sicherung von Web-Services mit dem bekannten Standard WS-Security. Microsoft bietet mit ihren Produkten ebenfalls die Möglichkeit, die Services mit den bekannten Standards zu sichern. Entwicklung und Deployment BEA bietet mit dem Produkt Workshop for WebLogic eine auf dem Eclipse-IDE-Framework basierende Entwicklungsumgebung. Mit dieser lassen sich u. a. Java-Webanwendungen, Enterprise Java Beans und Web-Services erstellen, testen und in die entsprechende Laufzeitumgebung installieren. Weiterhin ist mit dem Produkt WebLogic Portal in der Suite ein Produkt enthalten, mit welchem sich Portale erstellen lassen, über die menschliche Interaktionen in die SOA-Anwendungen eingebunden werden können. Ähnlich wie BEA integriert Oracle mit JDeveloper eine Entwicklungsumgebung in die Suite, mit der Java-Anwendungen und auch Web-Services erstellt werden können. Laut Oracle soll das Werkzeug dabei den kompletten Lebenszyklus der Entwicklung unterstützen, angefangen von der Modellierung bis hin zu Tests, Profiling und Deployment. In der Sonic-Reihe bietet Progress mit dem Sonic Workbench eine Entwicklungsumgebung, die genau wie BEAs Workshop for WebLogic auf dem Eclipse-Framework basiert. Das Tool bietet u. a. Unterstützung für die Erstellung von Web-Services. Dabei sollen nach Herstellerangaben die Phasen und Aufgaben Modellierung, Konfiguration, 51

62 4. Evaluierung ausgewählter SOA-Produktsuiten Test/Debugging sowie Deployment unterstützt werden. JBoss bietet optional diverse Plugins für die Eclipse-IDE an, mit denen sich z. B. der Application Server steuern oder Web-Applikationen und Web-Services erstellen lassen. Ebenso wie BEA beinhaltet die JEMS mit JBoss Portal ein Produkt zur Erstellung von Benutzer-Portalen. Microsofts Visual Studio kann u. a. für die Erstellung von Web-Services genutzt werden. Ebenso können Geschäftsprozesse modelliert werden, die über den BizTalk Server orchestriert werden. Neben dieser eher an IT-Fachleute gerichteten Modellierungsvariante gibt es zusätzlich eine auf dem Modellierungstool Visio basierende Oberfläche, die für Geschäftsnutzer geeignet sein soll. Standard-Unterstützung Bei der Frage nach den von den SOA-Suiten unterstützten Standards muss zunächst festgehalten werden, dass es im Rahmen dieser Arbeit nicht möglich ist, tatsächlich alle unterstützten Standards aufzuführen; eine Erwähnung von Netzwerkprotokollen oder einfachen Basisprotokollen wie HTTP oder auch XML ist hier sicherlich nicht sinnvoll. Es wurde versucht, eine Auswahl derjenigen Standards zu treffen, die bei der Realisierung einer SOA auf Basis von Web-Services relevant erscheinen. Weiterhin ist anzumerken, dass die meisten Standards und Spezifikationen zumeist einen gewissen Interpretationsspielraum bieten, sodass die Implementierungen zweier Hersteller u. U. nicht die exakt selbe Funktionalität zur Verfügung stellen. Tabelle 4.4 zeigt auf, welche Produkte in der zum Betrachtungszeitpunkt aktuellen Version welche der Standards unterstützen. Administration Wie bereits beschrieben, verfügen die BEA-Produkte WebLogic Server und Integration über graphische Administrationsoberflächen, über welche sich alle Einstellungen vornehmen lassen. Für die technische Administration bieten in der Oracle SOA Suite der Application Server und der Enterprise Service Bus graphische Oberflächen, über die sich die Anwendungen konfigurieren und überwachen lassen. Für die Verwaltung von Web-Services bietet der Oracle Web Services Manager ebenfalls eine solche GUI. Mit den Produkten Actional for SOA Operations und Actional for Sonic ESB bietet Progress diverse Administrationswerkzeuge, die für die technische Verwaltung der SOA-Komponenten eingesetzt werden können. Der JBoss Application Server verfügt über eine graphische Konfigurationsoberfläche, ansonsten sind in der JEMS von Red Hat keine Werkzeuge für die Administration enthalten. Für die Verwaltung von Web-Services beinhaltet Microsofts WCF eine Reihe von Tools, mit denen u. a. Konfigurationseinstellungen vorgenommen werden können. Der BizTalk Server enthält mit der BizTalk Server Administration Console ebenfalls eine graphische Oberfläche, mit der sich die Anwendung verwalten und konfigurieren lässt. 52

63 4.3. Evaluierung der Produkte Tabelle 4.4.: Unterstützte Standards und Spezifikationen Standard Bedeutung Hersteller und Produkt BEA, WebLogic Platform Oracle, SOA Suite Progress, Actional u. Sonic Red Hat, JEMS Microsoft,.NET u. BizTalk UDDI 2/3 s. Abschnitt B B E B B JAXR 1.0 Java-API zur Kommunikation mit Verzeichnisdiensten B B A B A WS-Security 1.0 Rahmenwerk zur Verschlüsselung und Signierung B B B B B von SOAP-Nachrichten WS-Policy Beschreiben von Sicherheitsanforderungen und Policies B B B B B WS-SecurityPolicy Policies für die Absicherung von Web-Services A A B A B WS-Trust 1.0 Erweiterung von WS-Security u. a. für den Austausch B A A A B von Sicherheitstokens WS-SecureConversation Definition eines Sicherheitskontextes für den Aus- B A A A B 1.0 tausch gesicherter Nachrichten WSTF Spezifikationsfamilie für (verteilte) Transaktionen über Web-Services A A A B E SOAP 1.x s. Abschnitt B B B B B WSDL 1.1 s. Abschnitt B B B B B WS-Addressing 1.0 Austausch von Adressierungsinformationen unabhängig B B B B B vom Transportprotokoll WS-ReliableMessaging 1.x Protokoll für die verlässliche Zustellung von SOAP- Nachrichten B B B A B WS-BPEL 1.1, 2.0 s. Abschnitt E B B A E BPMN s. Abschnitt A A A A A WS-Eventing Kommunizieren von Events über Web-Services A A A B A SNMP 3 Zentrale Überwachung und Verwaltung von Netzwerkkomponenten B B A B B WS-Management Auf SOAP basierendes Protokoll zur Verwaltung A A A A A von Netzwerkkomponenten WSDM 1.x Verwalten und Überwachen des Zustands von Web- Services A A A A A Legende: A»nicht unterstützt«bzw. nicht dokumentiert, E»teilweise unterstützt«, B»vollständig unterstützt«53

64 4. Evaluierung ausgewählter SOA-Produktsuiten Geschäfts-Sicht Service-Management, -Governance und Registry/Repository BEA bietet in der WebLogic Platform keine speziellen Tools für die SOA-Governance, eine Registry bzw. Repository ist ebenfalls nicht Bestandteil. Ein entsprechendes Produkt ist lediglich in der AquaLogic-Familie unter dem Titel Registry Repository verfügbar, welches umfangreiche Governance-Funktionen bereitstellt. WebLogic Integration bietet die Möglichkeit, SLAs für Prozesse zu definieren und deren Einhaltung über die Administrationskonsole zu überwachen. Ebenso wird eine Versionierung von Prozessen und Services unterstützt. Mit dem Web Services Manager der SOA Suite bietet Oracle umfangreiche Möglichkeiten zur Verwaltung von Services dabei können sowohl WS-BPEL- als auch über den Oracle ESB erstellte Prozesse verwaltet werden. Es können mittels einer GUI Policies definiert werden, deren Einhaltung anschließend graphisch ausgewertet werden kann. Mit der Oracle Service Registry stellt der Anbieter außerdem einen UDDI-konformen Verzeichnisdienst bereit, der allerdings nicht Bestandteil der SOA Suite ist. Dieser stellt neben den üblichen Verzeichnisfunktionen u. a. Funktionen für die Versionierung von Services zur Verfügung. Mit dem Produkt Actional for Continuous Service Optimization stellt Progress ein Werkzeug zur Verfügung, mit dem sich die Prozesse aus Geschäftssicht nach verschiedenen Kriterien überwachen lassen. Mithilfe des Produkts Actional for Active Policy Enforcement können neben den bereits erwähnten Sicherheits-Policies auch andere Richtlinien wie z. B. SLAs definiert und überwacht werden. Einen Verzeichnisdienst bietet Progress nicht an, jedoch können UDDI-konforme Verzeichnisse eingebunden werden. In Red Hats JEMS sind keinerlei Werkzeuge für die Verwaltung von Services gegeben, jedoch enthält der JBoss Application Server mit der Apache juddi Registry einen UDDIkonformen Verzeichnisdienst. Microsofts WCF bietet, wie schon erwähnt, verschiedene Möglichkeiten zur graphischen Überwachung von Web-Services. Augenscheinlich bietet Microsoft derzeit keine vorgefertigten Möglichkeit zur Definition und Überwachung von SLAs. Bestandteil des Microsoft Windows Servers ist ein UDDI-konformer Verzeichnisdienst, welcher u. a. die Katalogisierung und Kategorisierung von Services unterstützt. Geschäftsprozess-Management und Orchestrierung Geschäftsprozesse können mit BEAs WebLogic Integration und Workshop for WebLogic über einen graphischen Editor zusammengestellt werden. Die im Einsatz befindlichen Prozesse können dann über die Oberfläche detailliert überwacht werden. WebLogic Integration bietet außerdem die Möglichkeit, WS-BPEL-Dokumente (in der Version 1.1) zu im- und exportieren. Native Verarbeitung von WS-BPEL-Prozessen hingegen bietet lediglich das Produkt AquaLogic BPM. Eine Überwachung der Geschäftsprozesse anhand konfigurierbarer Kennzahlen (Key 54

65 4.3. Evaluierung der Produkte Performance Indicator, KPI) bietet das in der Oracle SOA Suite enthaltene Business Activity Monitoring. Über eine graphische Schnittstelle können Daten in Echtzeit überwacht und Benachrichtigungen eingerichtet werden, die den Anwender bei Eintreten bestimmter Ereignisse informieren. Als Bestandteil des BPEL Process Managers bietet Oracle mit dem Process Designer eine graphische Anwendung zur Erstellung von WS-BPEL- Prozessen. Der BPEL Process Manager unterstützt dabei nativ WS-BPEL in Version 1.1 sowie eine proprietäre Erweiterung für die Integration menschlicher Interaktion. Weiterhin enthält die Suite das Produkt Business Rules, mit dessen Hilfe sich Geschäftsregeln deklarativ festhalten lassen. Dies ist insbesondere dann von Vorteil, wenn sich die Geschäftsregeln häufig ändern: sind diese unabhängig von der Implementierung des Geschäftsprozesses gehalten, so können Regeländerungen ohne Einfluss auf den eigentlichen Prozess durchgeführt werden. Geschäftsprozesse lassen sich über Progress Sonic Workbench graphisch modellieren, über WS-BPEL orchestrieren und anschließend in den Sonic BPEL Server installieren. Dieser bietet zusätzlich eine graphische Benutzerschnittstelle, über welche die Ausführung von Prozessen verfolgt werden kann. Mit JBoss jpbm enthält Red Hats JEMS eine Workflow- und BPM-Engine, mit der sich u. a. Geschäftsprozesse orchestrieren lassen. Derzeit bietet JBoss jpbm keine Unterstützung für WS-BPEL, sondern lediglich die JBoss-eigene Prozessdefinitionssprache jpdl. Die Prozesse lassen sich über ein entsprechendes Eclipse-Plugin graphisch modellieren und anschließend in den Server installieren. Ähnlich wie Oracles Business Rules ist in der JEMS mit JBoss Rules ein Produkt zur Beschreibung von Geschäftsregeln enthalten. Es ist eine graphische Oberfläche zur Modellierung der Regeln verfügbar. Microsoft bietet mit dem BizTalk Server einen funktionsreichen BPM-Server. Zur Automatisierung und Orchestrierung von Geschäftsprozessen bietet der Server die Möglichkeit, sowohl Web-Services als auch über Adapter angeschlossene Proprietärsysteme zu verarbeiten. Auch werden über den Human Workflow menschliche Interaktionen unterstützt. Graphisch modelliert werden die Prozesse über die Visual Studio Entwicklungsumgebung. Die Unterstützung für WS-BPEL 1.1 beschränkt sich derzeit auf eine Import- und Exportfunktion. Über die Business Rules Engine können wie bei Oracle und JBoss Geschäftsregeln definiert und flexibel verwaltet werden. Für die Überwachung der Geschäftsprozesse bietet der BizTalk Server umfangreiche BAM (Business Activity Monitoring)-Funktionalitäten. Dabei können die Daten über verschiedene Schnittstellen, wie z. B. Microsoft Excel oder ein BAM-Portal, abgerufen werden. Ebenso können automatische Benachrichtigungen bei Eintreten bestimmter Ereignisse erzeugt werden. Accounting, Logging Funktionen für das Accounting also die Abrechnung von Leistungen bietet augenscheinlich keine der evaluierten Produktsuiten. Sowohl auf technischer als auch auf Geschäftsprozessebene bieten die Komponenten der BEA WebLogic Platform umfangreiche Logging-Möglichkeiten; die Protokolldaten können dabei über die graphische Oberfläche angezeigt und ausgewertet werden. 55

66 4. Evaluierung ausgewählter SOA-Produktsuiten Der Oracle Web Services Manager bietet umfangreiche Möglichkeiten für die Protokollierung von Zugriffen auf Web-Services in unterschiedlichen Detailstufen. Ebenso kann die Einhaltung von SLAs protokolliert werden. Über die Oberfläche des BPEL Process Managers lassen sich die Instanzen der WS-BPEL-Prozesse detailliert betrachten und alle relevanten Informationen protokollieren. Der Progess Sonic ESB stellt verschiedene Protokollierungsmechanismen zur Verfügung, mit denen sich z. B. Fehler und Orchestrierungsdaten festhalten lassen. Der JBoss Application Server sowie JBoss jpbm enthalten Funktionen zur Protokollierung von Nutzungsdaten. Microsofts Produkte bieten ebenfalls die Möglichkeit, Nutzungs- und Leistungsdaten zu protokollieren. Auditing und Sicherheit Der BEA WebLogic Server stellt in dem bereits erwähnten Security Framework diverse Funktionen für das Auditing zur Verfügung. Oracles Web Services Manager bietet Funktionen für das Auditing auf Basis kompletter Web- Services, einzelner Operationen und pro Client. Der Progress Sonic BPEL Server bietet Unterstützung für das Auditing von WS-BPEL-Prozessen. Weiterhin lässt sich mit Actional for Active Policy Enforcement die Einhaltung von z. B. rechtlichen Vorgaben überwachen und protokollieren. In der Red Hat JEMS sind offenbar derzeit keine expliziten Möglichkeiten für das Auditing gegeben. Microsoft sieht offenbar ebenfalls keine vorgefertigten Lösungen für das Auditing vor Zusammenfassung und Fazit In den vorangegangenen Abschnitten wurden die zur Evaluierung ausgewählten Produkte anhand des erarbeiteten Kriterienkatalogs untersucht. Abschließend soll nun versucht werden, eine grobe Zusammenfassung der Produkte aufzustellen. Es fällt auf, dass sich die Qualität und der Umfang der Produktbeschreibungen der verschiedenen Hersteller deutlich unterscheiden, was eine einheitliche Bewertung der Produkte erschwert. Positiv aufgefallen sind hier die Hersteller BEA, Oracle und Microsoft, die sehr umfangreiche und detaillierte Dokumentationen bereitstellen, auch wenn aufgrund der Informationsfülle zeitweilen Probleme beim Auffinden der benötigten Daten auftreten können. Teilweise konnten Informationen auch durch längere Recherche nicht ermittelt werden, hier müsste man ggf. durch eine detaillierte Evaluierung anhand eines kompletten Installationsszenarios weitere Erkenntnisse gewinnen. Im Bereich der modellunabhängigen Kriterien schneiden die großen Hersteller BEA, Oracle und Microsoft am besten ab; sie bieten größtenteils gute und umfangreiche Dokumentationen und professionellen Support. Größe und Stabilität können bei einer Kaufentscheidung ebenfalls eine Rolle spielen. Bei Anbietern wie Oracle oder Microsoft muss man sich um eine plötzlich eingestellte Produktlinie oder entfallenden Support weniger sorgen als bei den kleineren Anbietern. Auf modellabhängiger Ebene gibt es bei allen 56

67 4.4. Zusammenfassung und Fazit Anbietern Stärken und Schwächen. Im Bereich der Infrastruktur und bei Performance- Aspekten treten sicherlich BEA und Oracle besonders positiv hervor. Alle Anbieter unterstützen im Großen und Ganzen offene Standards, in diesem Bereich gibt es nur Detailunterschiede. Geschäftsspezifische Aspekte werden besonders in Oracles SOA Suite betont. Aber auch Microsoft bietet hier augenscheinlich viel Funktionalität mit dem BizTalk Server. Progress bietet als einziger Kandidat sehr spezifische SOA-Produkte für Governance und Verwaltung, die in diesem Bereich als sehr positiv hervorzuheben sind. Gerade bei den großen Herstellern BEA und Oracle fällt auf, dass das Produktportfolio durch Zukäufe externer Produkte bereichert wurde und die Suites somit u. U. aus Komponenten verschiedener Hersteller zusammengestellt sind. Es ist zu erwarten, dass hier evtl. kleinere Unebenheiten in der Integration der einzelnen Komponenten auftreten. Augenscheinlich stellen sich diese jedoch trotzdem als sehr homogen dar und versprechen eine nahtlose Integration. Red Hats JEMS erscheint durch die bare Kombination diverser Produkte auf den ersten Blick wenig homogen. Im Gegensatz dazu scheinen die Produkte der Firma Progress sehr gut aufeinander abgestimmt und kombinierbar. Die Produkte der Firma Microsoft sind üblicherweise gut miteinander kombinierbar, weswegen hier eine recht problemlose Zusammenarbeit zu erwarten ist. Betrachtet man diese Ergebnisse, so stellt sich die Oracle SOA Suite als die kompletteste Suite dar, mit der nahezu alle Aspekte einer SOA abzudecken sind. Es ist allerdings fraglich, ob eine SOA-Initiative direkt einen derartigen Funktionsumfang benötigt i. A. herrscht Einigkeit darüber, dass eine SOA nicht schlagartig durch den Kauf eines Produktes oder einer Produktsuite entsteht, sondern es sich dabei um einen längeren, iterativen Prozess handelt, der auch organisatorische Aspekte beinhaltet. Für eine schrittweise Einführung lassen sich demnach auch die Produkte von BEA, Progress und JBoss nutzen und ggf. später durch weitere Tools ergänzen. Sind in einem Unternehmen bereits hauptsächlich Microsoft-Produkte im Einsatz und entsprechende technische Qualifikationen und Kenntnisse vorhanden, so scheint ein Aufbau der SOA mit den angesprochenen Microsoft-Produkten als sinnvoll. Zusammenfassend lassen sich die Ergebnisse wie folgt festhalten: BEA: solide Basiskomponenten, viele Erweiterungsmöglichkeiten von dem selben Hersteller, hohe Lizenzkosten. Oracle: sehr umfangreiche Suite, ausgeprägte Funktionen im Bereich Geschäftsprozesse, teilweise unklare Produktzusammenstellung. Progress: gute Funktionalitäten im Bereich Governance und Management, wenig verfügbare Dokumentation, keine Preisinformationen. Red Hat/JBoss: preisgünstige Open-Source-Variante, unklare Produktbündelung. Microsoft: beschränkt auf Windows-Plattform, starke Geschäftsprozessfokussierung, Integration mit vielen anderen Produkten des Herstellers. 57

68 5. Entwicklung eines SOA-Prototypen Wie im vorangegangenen Kapitel dargelegt, stellt sich Oracles SOA Suite nach der Evaluierung augenscheinlich als ein interessantes und funktionsreiches Produkt dar. Zudem wird eine kostenfreie Evaluationsversion angeboten. Aus diesen Gründen erfolgt die Entwicklung des Prototypen auf Basis der Oracle SOA Suite in der zur Erstellung dieser Arbeit aktuellen Version Der Prototoyp soll sich dabei an einem simplifizierten Geschäftsvorfall orientieren, welcher möglichst viele Aspekte und Phasen des SOA-Lifecycles einbeziehen soll. Es kommt hierbei ausdrücklich nicht auf die sinnvolle Implentierung von Services an, sondern auf das Zusammenspiel der Komponenten der Suite sowie die Erstellung des Gesamtgeschäftsprozesses. In den nachfolgenden Abschnitten wird dazu zunächst dieser Geschäftsvorfall beschrieben und modelliert. Weiterhin erfolgt eine Darstellung des Installationsvorgangs und der Konfiguration der Oracle SOA Suite. Abschließend wird auf die Implementierung des Prototypen sowie dessen Test und Betrieb eingegangen und eventuell auftretende Probleme aufgezeigt Beschreibung des Geschäftsvorfalls In diversen Quellen (z. B. [AAA + 07, Kap. 13]) wird als Beispiel eines Geschäftsvorfalls die automatische Bearbeitung eines Kreditantrages aufgeführt. Im Rahmen dieser Arbeit soll an diese Idee angeknüpft und das Szenario um einige Details erweitert werden. Bei der Umsetzung des Geschäftsprozesses sollen die folgenden Aspekte behandelt werden: Aufruf interner und externer Services, Aufruf synchroner und asynchroner Services, Fehler- und Ausnahmebehandlung, Integration menschlicher Aktionen (Human Workflow), Parallelität, Kompensation im Fehlerfall, Einbindung von Geschäftsregeln, Sicherung eines Web-Services (Authentifizierung). 58

69 5.1. Beschreibung des Geschäftsvorfalls Der zu modellierende und umzusetzende Geschäftsprozess läuft folgendermaßen ab: Zunächst sendet ein Kunde eine Kreditanfrage inklusive seiner persönlichen Daten an das System. Daraufhin wird eine Adressprüfung vorgenommen dazu wird ein externer Web-Service synchron aufgerufen. Wurde die Adresse als ungültig eingestuft, so bricht der Prozess ab und der Kunde erhält eine entsprechende Benachrichtigung. Andernfalls wird im nächsten Schritt eine Anfrage an einen externen Bonitätsprüfservice gesendet, um die Kreditwürdigkeit des Kunden zu überprüfen. Da diese Überprüfung u. U. längere Zeit in Anspruch nehmen kann, wird dieser Web-Service asynchron aufgerufen. Das bedeutet, dass der Prozess solange angehalten wird, bis die Antwort des Web-Services eintrifft. Im folgenden Schritt soll die Einbindung eines Geschäftsregel-Systems vorgenommen werden. Im Beispiel soll dazu über Geschäftsregeln entschieden werden, ob der vom Bonitätsprüfsystem zurückgelieferte Wert eine positive bzw. negative Bewertung darstellt, da dies ja durchaus eine subjektive Klassifizierung darstellt, die von verschiedenen Faktoren wie z. B. dem Alter oder dem Beruf des Antragstellers abhängen kann. Wurde die Bonität als»schlecht«eingestuft, so wird der Prozess beendet und der Kunde erhält eine entsprechende Benachrichtigung per . Im anderen Fall kommt eine weitere Fallunterscheidung zum Tragen, welche dieses Mal allerdings fest im Prozess verankert und nicht über ein externes System beeinflusst wird: Beträgt die Höhe des beantragten Kredits weniger als 5000 e, so wird der Antrag automatisch genehmigt, der Kunde erhält eine Benachrichtigung und der Prozess endet erfolgreich. Ist dies nicht der Fall, so muss der Antrag manuell durch einen Sachbearbeiter überprüft werden. In diesem Zusammenhang soll die Einbindung menschlicher Interaktion in den Geschäftsprozess vorgenommen werden ein Mitglied der Benutzergruppe Sachbearbeiter soll den Antrag manuell bewilligen bzw. ablehnen, der Kunde erhält dann eine entsprechende Benachrichtigung. In den letztgenannten Fällen werden jeweils zwei weitere Services eingebunden: Wurde der Kreditantrag mangels Kreditwürdigkeit abgelehnt bzw. genehmigt, so werden die im Unternehmen vorhandenen CRM (Customer Relationship Management)- und ERP (Enterprise Resource Planning)-Systeme angesprochen, um die Kundendaten entsprechend zu aktualisieren. Diese Dienste werden über den ESB servicefähig gemacht und können dann von dem Kreditvergabe-Prozess angesprochen werden. In diesem Zusammenhang soll auch die Situation simuliert werden, in der ein Serviceaufruf auf fachlicher Ebene scheitert und daraufhin andere bereits durchgeführte Aktionen zurückgenommen werden müssen, vergleichbar mit dem Rollback von Transaktionen in einem DBMS. Außerdem soll der Aufruf des»erp«-services nur nach einer Authentifizierung möglich sein. 59

70 5. Entwicklung eines SOA-Prototypen 5.2. Installation und Konfiguration der Oracle SOA Suite Im folgenden Abschnitt soll kurz auf die Installation sowie Konfiguration der Oracle SOA Suite eingegangen werden. Die SOA Suite stellt einen graphischen Installationsassistenten zur Verfügung, welcher zwei verschiedene Installationsvarianten anbietet: In der Basisinstallation werden automatisch alle Komponenten der Suite installiert, die erweiterte Installation bietet die Möglichkeit, differenzierte Einstellungen bzgl. des Installationsumfangs sowie weiterer technischer Details vorzunehmen. Im Rahmen dieser Arbeit wird die Basisinstallation gewählt und es werden alle Standardeinstellungen übernommen. Die Installation lässt sich ohne Probleme durchführen. Ein Fehler tritt in der verwendeten Version jedoch auf, wenn die Setupdateien in einem Verzeichnis liegen, dessen Pfad ein Leerzeichen enthält; in diesem Falle bricht die Installation mit einem Fehler ab. Nach der Installation der SOA Suite Version wird noch das von Oracle bereitgestellte Patchset installiert, welches diverse Fehler beseitigt und die Suite auf Version bringt. Der Oracle JDeveloper benötigt keine spezielle Installation, es muss lediglich die komprimierte Archivdatei entpackt werden. Nach der Installation der Suite stellt sich heraus, dass weder die Oracle Service Registry noch das Produkt Business Activity Monitoring direkt in der SOA Suite enthalten sind, wie dies dem Produktdatenblatt bzw. der Herstellerinternetseite zu entnehmen ist. Allerdings besteht die Möglichkeit, diese beiden Komponenten ebenfalls in kostenlosen Evaluationsversionen von Oracle zu beziehen. Positiv hervorzuheben ist, dass für die Verwendung der Suite kein initialer Konfigurationsaufwand vonnöten ist die Komponenten lassen sich problemlos in der ausgelieferten Konfiguration starten. Alle für den Prototyp verwendeten Einstellungen lassen sich zudem über die verschiedenen graphischen Benutzeroberflächen vornehmen. Ausnahme bildet hier die Konfiguration des Benachrichtigungsdienstes des BPEL-Servers, welche in der Datei <ORACLE_HOME>/bpel/system/services/config/ns_ . cfg vorgenommen werden muss Modellierung in BPMN Wie in Kapitel angesprochen, bietet sich zur abstrakten Modellierung von Geschäftsprozessen die BPMN an. Auf dieser Modellierungsebene werden technische Details, wie z. B. Angaben zu den zu verwendenden (Web-)Services, vorerst ignoriert. Anschließend kann der modellierte Prozess in WS-BPEL transformiert und von einer BPEL- Engine ausgeführt werden. Für die Modellierung von BPMN-Prozessen gibt es eine Reihe frei verfügbarer Tools (z. B. ebpmn von Soyatec oder BPMN Designer von Intalio). Außerdem bietet Oracle in der Business Process Analysis (BPA) Suite mit dem Business Process Architect ein auf der ARIS Design Platform basierendes graphisches Modellierungstool für BPMN an. Die BPA Suite ist zwar nicht Bestandteil der für die Erstellung 60

71 5.4. Implementierung und Orchestrierung der Services des Prototypen verwendeten SOA Suite, obgleich soll im Folgenden der Business Process Architect für die Modellierung verwendet werden, um das Zusammenspiel mit den Komponenten der SOA Suite zu erproben. Die Software kann von Oracle über das Internet in einer 90 Tage gültigen Testversion bezogen werden. Zusätzlich wird eine Oracle- Datenbank benötigt, es kann auf die kostenfrei verfügbare Oracle Express Edition in der Version 10g zurückgegriffen werden. Die BPMN stellt einen Business process diagram Modelltyp zur Verfügung, mit dem Geschäftsprozesse beschrieben werden können. Oracles Business Architect unterstützt dieses Modell sowie einige zusätzliche Erweiterungen. Es soll hier nicht näher auf die Details der BPMN eingegangen werden, sondern lediglich die im modellierten Beispiel verwendeten Elemente vorgestellt werden. Abbildung 5.1 zeigt den modellierten Prozess. Ein Diagramm nach der BPMN wird üblicherweise durch die Verwendung von Swimlanes (Verantwortlichkeitsbereich), ähnlich wie in UML-Aktivitätsdiagrammen unterteilt. Im hier modellierten einfachen Beispiel wurde jedoch auf eine solche Unterteilung verzichtet, stattdessen läuft der ganze Prozess in einer einzigen Swimlane, die dann laut Spezifikation nicht explizit dargestellt werden muss. Die Start- und Endsymbole sind ebenfalls ähnlich zu Elementen der UML das hier gewählte Startsymbol deutet an, dass der Prozess mit Erhalt einer Nachricht (hier einem Kreditantrag) beginnt. Die abgerundeten Rechtecke stellen Funktionen bzw. Aktivitäten dar. Abweichend von der Spezifikation wird hier durch ein Symbol gekennzeichnet, ob es sich um einen automatisierten Prozess, das Senden einer Nachricht oder eine menschliche Interaktion handelt. Der Fortgang des Ablaufs wird durch die durchgezogenen Pfeile markiert. Die Rauten sind sog. Gateways (Entscheidungspunkte), an denen der Kontrollfluss getrennt bzw. zusammengeführt werden kann. Bei einem Entscheidungspunkt wird der Defaultzweig mit einem Schrägstrich markiert. Für weitere Details zu BPMN sei auf die von der OMG herausgegebene Spezifikation [OMG06] verwiesen Implementierung und Orchestrierung der Services Mittels des Business Architects lässt sich das in BPMN erstellte Modell nach Fertigstellung auf dem BPA Server speichern und somit für den Entwickler freigeben. Über den Oracle JDeveloper wird das Modell anschließend heruntergeladen, daraufhin wird automatisch ein Grundgerüst (von Oracle als Blue Print bezeichnet) für den WS-BPEL- Prozess erstellt. Dieses Grundgerüst gilt es schließlich mit den entsprechenden Details zu füllen WS-BPEL-Prozess»Kreditvergabe«Es wird dabei so vorgegangen, dass zunächst alle Services erstellt werden, die an dem Prozess beteiligt sind und durch den Hauptprozess aufgerufen werden. In der WS-BPEL- Terminologie werden diese als Partner-Links bezeichnet. Anschließend werden Daten- 61

72 5. Entwicklung eines SOA-Prototypen Abbildung 5.1.: Kreditvergabeprozess in BPMN 62

73 5.4. Implementierung und Orchestrierung der Services typen und Variablen definiert. Letztlich wird der Gesamtprozess orchestriert, indem die Aufrufe der einzelnen Services modelliert werden. In Abbildung 5.2 ist der Gesamtprozess»Kreditvergabe«ohne Details dargestellt (d. h. alle Elemente, die weitere Unterelemente enthalten, sind eingeklappt) im Folgenden werden die einzelnen Sektionen ausschnittsweise dargestellt und näher beschrieben. Abbildung 5.2.: Übersicht Kreditvergabeprozess in WS-BPEL (Oracle JDeveloper BPEL Designer) Die rechte und linke Spalte der Designansicht beinhalten die Partner-Links, wobei die Positionierung der Elemente keine semantische Bedeutung hat. Im Beispiel sind die folgenden Services in den Geschäftsprozess involviert: AddressCheck: Eigenerstellter Service zur Adressüberprüfung 63

74 5. Entwicklung eines SOA-Prototypen NotificationService: Von Oracle bereitgestellter Service zur Versendung von Benachrichtigungen CRM: Eigenerstellter Service, der einen Adapter zu dem CRM-System darstellen soll Client: Service, über den der Kreditvergabeprozess angestoßen und das Ergebnis abgefragt werden kann DecisionService: Von Oracle bereitgestellter Service zur Einbindung von Business Rules (Geschäftsregeln) CreditRating: Eigenerstellter Service zur Bonitätsüberprüfung ERP: Eigenerstellter Service, der einen Adapter zu dem ERP-System darstellen soll TaskService: Von Oracle bereitgestellter Service zur Einbindung menschlicher Interaktionen (Workflows) Die graphische Darstellung des Prozesses zeigt außerdem in der Mitte den Prozessablauf, wie er einleitend bereits beschrieben und im BPMN-Diagramm modelliert wurde. Über die Schnittstelle des Partner-Links Client wird der Prozess angestoßen, dargestellt durch die mit AntragErhalten betitelte receive-aktivität. Es folgt der scope Adresspruefung in welchem der Adressprüfdienst aufgerufen wird, dessen Details in Abschnitt beschrieben sind. Anschließend folgt die Fallunterscheidung Adresse- Gueltig ist die Adresse ungültig, so wird eine Benachrichtigung versandt und der Prozess beendet, andernfalls wird mit der Bonitätsprüfung fortgefahren. In Abbildung 5.3 ist dieser Ausschnitt des Prozesses dargestellt. In dem Block Bonitaetspruefung wird der Service zur Bonitätsprüfung asynchron aufgerufen und das Ergebnis in einer globalen Variable abgelegt. Auftretende Ausnahmen werden in diesem Abschnitt durch einen catchall-block gefangen und daraufhin der nicht erhaltene Rückgabewert auf einen Standardwert gesetzt. Abbildung 5.4 zeigt dieses Detail. Eine Beschreibung des»creditrating«-services findet sich in Abschnitt Über die Aktion BonitaetBewerten (s. Abbildung 5.3) wird der von Oracle angebotene Service»DecisionService«aufgerufen, welcher in Abschnitt näher vorgestellt wird. Je nachdem, ob der vom Bonitätsservice gelieferte Wert als gute oder schlechte Bonität eingestuft wird, soll der Antrag abgelehnt bzw. weiterverarbeitet werden. Dazu dient die Fallunterscheidung BonitaetOk deren Inhalt in Abbildung 5.5 dargestellt ist. Wie man sieht, folgt direkt im positiven Zweig eine weitere Fallunterscheidung: Ist die beantragte Summe kleiner als ein bestimmter Betrag, so wird der Antrag automatisch bewilligt, andernfalls wird ein menschliches Eingreifen benötigt, welche mit der Oracle SOA Suite über den»taskservice«eingebunden werden können. Es werden hier zwei mögliche Resultate definiert: Wird der Antrag nicht bewilligt (Fall REJECT), so 64

75 5.4. Implementierung und Orchestrierung der Services Abbildung 5.3.: Detailansicht des switch-blocks AdresseGueltig wird eine Benachrichtigung gesendet, andernfalls (Fall APPROVE) wird der Rückgabewert entsprechend gesetzt und ebenfalls eine verschickt. In Abschnitt wird die Einbindung menschlicher Aktivitäten genauer beschrieben. Im letzten entscheidenden Abschnitt Datenaktualisierung werden schließlich die Services»CRM«und»ERP«aufgerufen und die sog. compensate-aktivität beispielhaft demonstriert. Schlägt das Aktualisieren des Kunden im CRM-System fehl (signalisiert durch das Auftreten des Fehlers crm:error), so wird die parallel durchgeführte Aktion im Block ERPAktualisieren durch entsprechende Maßnahmen rückgängig gemacht. Der Detailausschnitt ist in Abbildung 5.6 gezeigt. Der Service»CRM«wird in Abschnitt näher vorgestellt; die Sicherung des Dienstes»ERP«wird in Abschnitt beschrieben. Der kommentierte WS-BPEL-Quellcode des Prozesses findet sich auszugsweise im Anhang A dieser Arbeit. 65

76 5. Entwicklung eines SOA-Prototypen Abbildung 5.4.: Detailansicht Aufruf der Bonitätsprüfung Abbildung 5.5.: Detailansicht des switch-blocks BonitaetOk 66

77 5.4. Implementierung und Orchestrierung der Services Abbildung 5.6.: Detailansicht des flow-blocks Datenaktualisierung WS-BPEL-Prozess»AddressCheck«Anhand dieses Prozesses soll zum einen die Beschreibung von Ein- bzw. Ausgabeparametern, zum anderen die Einbettung von Java-Code in einen BPEL-Prozess demonstriert werden. Der synchron aufgerufene Web-Service»AddressCheck«erhält die zu überprüfende Adresse in einem Parameter (AddressCheckProcessRequest) und gibt das Ergebnis schließlich an den Aufrufer mittels eines Rückgabeparameters (AddressCheckProcessResponse) zurück. Die Datentypen für diese Parameter können beispielsweise in einem externen XML-Schema definiert werden, wie dies in Listing 5.1 dargestellt ist. <schema targetnamespace=" xmlns=" <element name="addresscheckprocessrequest"> <! Eingabeparameter > <complextype> <sequence> <element name="address"> <complextype> <sequence> <element name="street" type="string" />... </sequence> </complextype> </element> </sequence> </complextype> </element> <element name="addresscheckprocessresponse"> <! Rueckgabeparameter > 67

78 5. Entwicklung eines SOA-Prototypen <complextype> <sequence><element name="isvalidaddress" type="boolean" /></sequence> </complextype> </element> </schema> Listing 5.1: Definition von Ein- und Ausgabeparametern (Ausschnitt AddressCheck.xsd) In diesem vereinfachten Beispiel hängt das Ergebnis der Adressprüfung davon ab, ob das Feld Street eine Zeichenkette enthält, die länger als 5 Zeichen ist. Dazu wird von der Möglichkeit Gebrauch gemacht, Java-Code direkt innerhalb des BPEL-Prozesses ausführen zu lassen. Dies wird über die generelle Erweiterbarkeit von WS-BPEL als XML-Sprache realisiert. Oracle verwendet den Namensraum bpelx, um solche Erweiterungen zu markieren. Der entsprechende Ausschnitt aus dem Prozess ist dargestellt in Listing 5.2. <bpelx:exec import="oracle.xml.parser.v2.xmlelement"/> <bpelx:exec name="checkaddress" language="java" version="1.4"> <![CDATA[ Boolean result = new Boolean(false); XMLElement streetelement = (XMLElement)getVariableData("inputVariable", "payload", "/client:addresscheckprocessrequest/client:address/client:street"); if (streetelement.getfirstchild()!= null && streetelement.getfirstchild().getnodevalue().length() >= 5) { result = Boolean.TRUE; } setvariabledata("outputvariable", "payload", "/client:addresscheckprocessresponse/client:isvalidaddress", result); ]]> </bpelx:exec> Listing 5.2: Einbindung von Java-Code über die exec-aktivität (Ausschnitt AddressCheck.bpel) Über die vom Oracle BPEL Process Manager Server zur Verfügung gestellten Methoden getvariabledata() sowie setvariabledata() kann auf die Variablen des BPEL-Prozesses zugegriffen und deren Inhalt manipuliert werden. Alternativ zur direkten Einbettung von Java-Code, die sich nur für sehr kompakte Programmstücke eignet, kann bereits bestehender Java-Code über WSIF (Web Services Invocation Framework)- Bindings oder durch einen SOAP-Wrapper in einen BPEL-Prozess eingebunden werden WS-BPEL-Prozess»CreditRating«Dieser Prozess dient zur Demonstration der Einbindung asynchroner Web-Services. Damit der»creditrating«-prozess sein Ergebnis, welches zu einem nicht vorhersehbaren Zeitpunkt vorliegen kann, an den Aufrufer zurückgeben kann, muss dieser ei- 68

79 5.4. Implementierung und Orchestrierung der Services ne entsprechende Callback-Methode anbieten. Es werden dazu bei der Definition des»creditrating«-prozesses zwei sog. Roles definiert eine wird von dem Service selbst, die andere von dem Service-Aufrufer eingenommen. Der entsprechende Ausschnitt der dem Bonitätsprüfservice zugehörigen WSDL-Datei ist in Listing 5.3 abgedruckt. <porttype name="creditratingcallback"> <operation name="onresult"> <input message="client:creditratingresponsemessage"/> </operation> </porttype> <plnk:partnerlinktype name="creditrating"> <plnk:role name="creditratingprovider"> <plnk:porttype name="client:creditrating"/> </plnk:role> <plnk:role name="creditratingrequester"> <plnk:porttype name="client:creditratingcallback"/> </plnk:role> </plnk:partnerlinktype> Listing 5.3: Definition der Rollen im»creditrating«-service (Ausschnitt CreditRating.wsdl) Der Aufrufer (in diesem Falle der WS-BPEL-Prozess»Kreditvergabe«) verwendet dann für die Verbindung zu diesem Service die Rolle CreditRatingRequester (s. Listing A.1 im Anhang, Zeilen 25 f.) Einbindung von Geschäftsregeln mit dem»decisionservice«oracle stellt in der SOA Suite die Möglichkeit bereit, sog. Business Rules (Geschäftsregeln) in einen BPEL-Prozess einzubinden. Dazu kann im JDeveloper BPEL Designer eine Decide-Aktivität in den Prozess integriert werden, welche einen entsprechenden Web-Service aufruft. Für die Definition der Geschäftsregeln liefert Oracle außerdem eine webbasierte Oberfläche, über die zunächst ein sog. Repository angelegt wird, welches sich als Datei im Dateisystem oder auf einer zentralen WebDAV-Ressource ablegen lässt. Dieses Repository nimmt die Regeln auf und wird später von dem»decisionservice«verwendet. Damit in den Geschäftsregeln Daten aus dem BPEL-Prozess verwendet werden können, müssen diese in Form sog. XMLFacts importiert werden. Für den Prototypen werden anschließend zwei Regeln definiert: Die Regel BonitaetGut soll greifen, wenn das vom»creditrating«-prozess gelieferte Ergebnis als positiv zu werten ist, andernfalls trifft die Regel BonitaetSchlecht zu. Geschäftsregeln bestehen dabei jeweils aus einem Bedingungs- und einem Aktionsteil sind die Bedingungen erfüllt, wird die Aktionen (bzw. die Aktionen) ausgeführt. Abbildung 5.7 zeigt beispielhaft die Oberfläche des Regeldesigners anhand der Regel BonitaetGut. Im Bedingungsteil (If) ist hier gefordert, dass der übergebene Parameter score vom Typ CreditRatingType ist und einen Wert größer 5 besitzt. Der Aktionsteil (Then) 69

80 5. Entwicklung eines SOA-Prototypen Abbildung 5.7.: Oberfläche des Oracle Rule Authors weist dem Ausgabeparameter scoreokay den bool schen Wert true zu und gibt zudem eine Logmeldung aus. Die Regel BonitaetSchlecht ist analog definiert. Sind die Geschäftsregeln einmal definiert, können nun im laufenden Betrieb ohne Änderungen des Geschäftsprozesses Anpassungen vorgenommen werden. Im Beispiel ist der Schwellwert 5 variabel und könnte durch die Fachabteilung über die Oberfläche angepasst werden, wie Abbildung 5.8 beispielhaft zeigt. Auf den ersten Blick scheint die Business Rules Engine keinerlei Logging-Funktionalitäten anzubieten, mit deren Hilfe sich z. B. nachvollziehen ließe, wann welche Regel aufgrund welcher Eingabedaten Anwendung gefunden hat. Es lässt sich jedoch ein solches Logging durch manuelles Anpassen der Konfigurationsdatei des»decisionservice«im jeweiligen BPEL-Projekt aktivieren. Nach dem Aufruf des Services im Kreditvergabe- Prozess lassen sich der Logdatei die in Listing 5.4 gezeigten Informationen entnehmen. <OracleRuleSession::executeUnitOfWork> assert fact de.evodion.bpel. Kreditvergabe.CreditRating <OracleRuleSession::executeUnitOfWork> ==> f-1 de.evodion.bpel.kreditvergabe. CreditRatingImpl(creditRatingScore : 10, scoreokay : false, DOMNode : < CreditRating xmlns=" <OracleRuleSession::executeUnitOfWork> <CreditRatingScore>10</ CreditRatingScore> <OracleRuleSession::executeUnitOfWork> <ScoreOkay/> <OracleRuleSession::executeUnitOfWork> </CreditRating> 70

81 5.4. Implementierung und Orchestrierung der Services Abbildung 5.8.: Anpassung einer variablen Geschäftsregel mit dem Rule Author <OracleRuleSession::executeUnitOfWork> ) <OracleRuleSession::executeUnitOfWork> ==> Aktivierung: de.evodion.bpel. Kreditvergabe. xpath.retractdeadcreditrating : f-1, OracleRuleSession::executeUnitOfWork> ==> Aktivierung: de.evodion.bpel. Kreditvergabe. xpath.retractdeadcreditratingtype : f-1, <OracleRuleSession::executeUnitOfWork> ==> Aktivierung: BonitaetsPruefung. BonitaetGut : f-1 <OracleRuleSession::executeUnitOfWork> Execute rule set BonitaetsPruefung <OracleRuleSession::executeUnitOfWork> Auslösen 1 BonitaetsPruefung.BonitaetGut f-1 <OracleRuleSession::executeUnitOfWork> Score ist okay: 10 <OracleRuleSession::executeUnitOfWork> Ruleset BonitaetsPruefung executed, 1 rules fired. Listing 5.4: Ausschnitt Log-Datei des BPEL-Servers Wie man sieht, wird in diesem Beispiel ein CreditRatingScore von 10 übergeben, sodass am Ende die Regel BonitaetGut feuert und die entsprechenden Aktionen ausgeführt werden Einbindung menschlicher Aktivitäten mit dem»taskservice«wie bereits im einleitenden Kapitel dieser Arbeit erwähnt, bietet WS-BPEL eigentlich keine Unterstützung menschlicher Aktivitäten. Oracle stellt mit dem»taskservice«jedoch eine Erweiterung bereit, mit der solche Aufgaben in einen BPEL-Prozess eingebunden werden können. Es handelt sich dabei um eine proprietäre Erweiterung, die bisher noch nicht auf der erst kürzlich veröffentlichten finalen Spezifikation von BPEL4People (s. auch Abschnitt ) beruht. Im Prototypen soll eine menschliche Interaktion er- 71

82 5. Entwicklung eines SOA-Prototypen folgen, wenn die beantragte Kreditsumme einen bestimmten Betrag überschreitet. Über den JDeveloper kann dieser Task (Aufgabe) ebenfalls graphisch bearbeitet werden; Abbildung 5.9 zeigt die entsprechende Eingabemaske. Abbildung 5.9.: Definition einer menschlichen Aktivität Wie man sieht, werden als mögliche Ergebnisse (Outcomes) APPROVE und REJECT definiert und die Aufgabe einem einzelnen Bearbeiter der Gruppe Sachbearbeiter zugewiesen. Es werden hier zahlreiche weitere Möglichkeiten wie Verfallsdaten, Benachrichtigungen oder Eskalationspfade angeboten. Zusätzlich ist in der Suite eine einfache Portalanwendung enthalten, über welche die zugewiesenen Aufgaben angenommen und bearbeitet werden können. Abbildung 5.10 zeigt eine angenommene Aufgabe für einen Mitarbeiter der Gruppe Sachbearbeiter, der nun zwischen den definierten Optionen wählen und somit den Fortgang des Prozesses beeinflussen kann. Ebenfalls könnte der Mitarbeiter die angenommene Aufgabe wieder freigeben, an eine andere Person delegieren oder eskalieren. Zusätzlich kann der Angestellte über die Portalanwendung einfache Berichte (z. B. zur Task-Produktivität oder Task-Laufzeiten) 72

83 5.4. Implementierung und Orchestrierung der Services Abbildung 5.10.: Bearbeitung einer menschlichen Aufgabe über das Portal einsehen sowie im Falle seiner Abwesenheit Regeln definieren, wie mit Aufgaben zu verfahren ist, die diesem Mitarbeiter persönlich zugewiesen wurden. Abbildung 5.11 zeigt eine Beispiel-Regel, nach der alle Aufgaben, die vor einem bestimmten Datum auslaufen, an eine andere Person delegiert werden. Abgesehen von den einfachen Berichten, scheint die Workflow-Anwendung keine zentral zugängliche Logging-Möglichkeiten zu beinhalten, mit denen z. B. nachvollziehbar wäre, welcher Mitarbeiter wann welche Aufgabe bearbeitet hat WS-BPEL-Prozess»CRM«Zur Behandlung von Fehlern auf Anwendungsebene bietet WS-BPEL die Möglichkeit, benutzerdefinierte Fehler zu definieren. Diese Fehler können dabei beliebige Daten aufnehmen, z. B. eine Fehler-Nummer und -Beschreibung. Anhand des Services»CRM«73

84 5. Entwicklung eines SOA-Prototypen Abbildung 5.11.: Erstellen einer Abwesenheits-Regel soll dies demonstriert werden. Es wird dazu bei der Operation process neben Ein- und Ausgabeparameter zusätzlich ein Fehlerelement definiert, wie Listing 5.5 zeigt. <porttype name="crm"> <operation name="process"> <input message="client:crmrequestmessage"/> <output message="client:crmresponsemessage"/> <fault name="error" message="client:crmexceptionmessage"/> </operation> <message name="crmexceptionmessage"> <part name="payload" element="client:crmexception"/> </message> </porttype> <element name="crmexception"> <complextype> <sequence> <element name="code" type="integer"/> <element name="message" type="string"/> </sequence> </complextype> </element> Listing 5.5: Definition eines Fehlers 74

85 5.4. Implementierung und Orchestrierung der Services Beim Aufrufer kann nun über die catch-aktivität das Auftreten dieses Fehlers abgefangen und entsprechend reagiert werden. Im Beispiel wird innerhalb des catch-blocks die compensate-aktivität aufgerufen, wodurch der gewünschte compensationhandler aktiviert wird. Auf diese Weise lassen sich ähnlich wie bei Transaktionen in Datenbanksystemen bereits durchgeführte Aktionen rückgängig machen, indem entsprechende Kompensierungsmaßnahmen durchgeführt werden Sicherung des Web-Services»ERP«Abschließend soll beschrieben werden, wie sich ein Web-Service technisch absichern lässt. Vereinfachend wird lediglich eine Authentifizierung durch Angabe eines Benutzernamens und eines Passwortes erfolgen. Solche Sicherheitsanforderungen lassen sich mithilfe des in der Oracle SOA Suite enthaltenen Oracle Web Services Managers (OWSM) umsetzen. Web-Services lassen sich hier auf zwei Arten schützen: 1. Durch die Verwendung eines sog. Gateways, welches quasi als Proxy für den eigentlichen Web-Service dient und u. a. Funktionen für die Authentifizierung, Autorisierung oder Verschlüsselung bietet. 2. Durch die Verwendung sog. Agents, die auf Server- bzw. Client-Seite im jeweiligen Ausführungskontext laufen und Anfragen an den Web-Service abfangen und die gewünschten Aktionen ausführen. Für den Prototypen wird die einfachere Variante mit einem Gateway gewählt. Zu beachten ist hier, dass auf diese Weise lediglich eine verminderte Sicherheit gegeben ist, da der ursprüngliche Service weiterhin direkt aufgerufen und das Gateway umgangen werden kann. Bei Verwendung eines Gateways in einem realen Szenario müsste dies dann durch technische Maßnahmen verhindert werden. Abbildung 5.12 zeigt ausschnittsweise, wie eine solche Policy mit der Oberfläche des OWSM erstellt werden kann. Im Ausführungsschritt Request sieht man in der Abbildung die Aktionen Extract Credentials (das Extrahieren der Daten aus dem SOAP-Header) sowie File Authentication (Authentifizierung gegen Daten aus einer Datei). Die zur Verfügung stehenden Policy-Schritte können dabei mit diversen Einstellungsmöglichkeiten angepasst werden. So lassen sich die Authentifizierungsdaten beispielsweise aus dem HTTP- oder JMS- Header oder über einen beliebigen XPath-Ausdruck extrahieren. Neben der Authentifizierung gegen eine Datei kann dies alternativ bzw. auch zusätzlich über Active Directory, LDAP oder den Oracle Access Manager durchgeführt werden. Außerdem lassen sich Nachrichten mittels eines Gateways ver- und entschlüsseln sowie signieren. Um beim Aufruf des Web-Services»ERP«nun auch die korrekten Authentifizierungsdaten übergeben zu können, müssen für den entsprechenden Partner-Link zusätzliche Eigenschaften gesetzt werden, wie Listing 5.6 zeigt. 75

86 5. Entwicklung eines SOA-Prototypen Abbildung 5.12.: Erstellen einer Policy mit dem Oracle Web Services Manager <partnerlinkbinding name="erp"> <property name="wsdllocation"> ERPService?wsdl</property> <property name="wsseheaders">credentials</property> <property name="wsseusername">test</property> <property name="wssepassword">test</property> </partnerlinkbinding> Listing 5.6: Angabe der Authentifizierungsdaten für den Partner-Link ERP (Ausschnitt bpel.xml) 76

87 5.5. Deployment der BPEL-Prozesse Wie man sieht, wird der Service über das erstellte Gateway angesprochen und es werden die zusätzlichen Header-Einträge wsseheaders, wsseusername und wsse- Password verwendet Deployment der BPEL-Prozesse Für das Deployment der BPEL-Prozesse bietet der JDeveloper ein Ant-Skript, welches sich direkt über einen Menüpunkt starten lässt. Es lässt sich hier der Zielserver sowie die Versionsnummer des zu publizierenden Prozesses wählen. Mithilfe der Oracle BPEL-Console können die deployten Prozesse verwaltet, Test- Instanzen gestartet, Audit-Trails eingesehen sowie Test-Fälle aufgezeichnet werden. Abbildung 5.13 zeigt beispielhaft das Starten einer Instanz des»addresscheck«-prozesses, in Abbildung 5.14 ist der graphisch visualisierte Audit-Trail dargestellt. Abbildung 5.13.: Starten einer Prozess-Instanz über die BPEL-Console Weiterhin bietet die BPEL-Console die Möglichkeit, alle im System befindlichen Prozessinstanzen zu überwachen und anzuzeigen. Neben der graphischen Visualisierung 77

88 5. Entwicklung eines SOA-Prototypen Abbildung 5.14.: Graphisch visualisierter Audit-Trail in der BPEL-Console des Prozessverlaufs können alle während der Ausführung anfallenden Daten (Ein- und Ausgabeparameter, Fehler) angezeigt werden auf diese Weise lassen sich die BPEL- Prozesse relativ komfortabel überprüfen und debuggen Test und Betrieb In diesem Abschnitt wird beschrieben, wie sich WS-BPEL-Prozesse mithilfe der Oracle SOA Suite testen lassen. Weiterhin soll ein rudimentärer Lasttest durchgeführt und die beim Betrieb des Prototypen aufgetretenen Probleme aufgeführt werden. Im Rahmen dieser Arbeit sollen drei der erstellten Web-Services bzw. WS-BPEL-Prozesse mit beispielhaften Tests überprüft werden: Der»AddressCheck«-Service soll mit einer Test-Suite getestet werden, der»creditrating«-service wird einem einfachen Stresstest unterzogen und schließlich wird der gesamte»kreditvergabe«-prozess mit einem Composite-Test überprüft. Anzumerken ist, dass die Tests an dieser Stelle nicht dazu gedacht sind, eine vollständige Testabdeckung zu erreichen, sondern lediglich beispielhaft 78

89 5.6. Test und Betrieb die gegebenen Möglichkeiten aufgezeigt werden sollen. Oracles SOA Suite unterstützt Testfälle sowohl nach dem Unit-Test-Konzept als auch Composite-Tests: Bei einem Unit-Test werden die Interaktionen mit anderen Web-Services emuliert, in einem Composite-Test werden die Partner mit konkreten Testdaten aufgerufen. Dabei können mehrere Testfälle außerdem zu sog. Test-Suites zusammengefasst und gemeinsam ausgeführt werden. Ein Testfall kann dabei entweder manuell über den JDeveloper bzw. mithilfe der BPEL-Console erzeugt und anschließend in den JDeveloper importiert werden. Die Testfälle bzw. Test-Suiten werden daraufhin auf den BPEL-Server übertragen und können schließlich mittels der BPEL-Console instanziiert werden. Nach der Ausführung eines Tests kann ein Report sowie eine graphische Ausgabe der Testabdeckung angezeigt werden Test des»addresscheck«-prozesses Für den Test dieses Prozesses wird eine Test-Suite mit vier Testfällen erstellt: Jeweils zwei Fälle, die je eine gültige und ungültige Adresse enthalten. Zur Erzeugung der Testfälle werden über die BPEL-Console zunächst entsprechende Instanzen der Prozesse mit den gewünschten Testdaten erzeugt. Ein Beispiel für eine solche erzeugte Testnachricht ist in Listing 5.7 dargestellt. Anschließend kann aus den abgeschlossenen Instanzen jeweils eine Unit-Test-Datei erzeugt werden, welche die eingegebenen Eingangsdaten enthält. <?xml version="1.0" encoding="utf-8"?> <BPELTest processname="addresscheck" xmlns=" instancedriver" xmlns:client=" <initiate operation="process"> <inboundmessage> <part name="payload"> <content> <ns1:addresscheckprocessrequest xmlns:ns1=" <ns1:address> <ns1:street>mundsburger Damm 33a</ns1:Street>... </ns1:address> </ns1:addresscheckprocessrequest> </content> </part> </inboundmessage> </initiate> <activitydriver name="checkaddress"> <assertvalue variablename="outputvariable" partname="payload" comparisonmethod="string" fatal="true" patternmatch="false"> <message>result should be true</message> <actualpath> /client:addresscheckprocessresponse/client:isvalidaddress </actualpath> 79

90 5. Entwicklung eines SOA-Prototypen <expected>true</expected> </assertvalue> </activitydriver> </BPELTest> Listing 5.7: Mittels der BPEL-Console erzeugter und im JDeveloper vervollständigter Testfall Die Testfälle werden anschließend in die über den JDeveloper erstellte Test-Suite Tests importiert und es können manuell Assertions eingefügt werden, wie diese bei Unit-Tests üblich sind. Im oben gezeigten Beispiel wird gefordert, dass das Ergebnis des Prozesses (die Variable IsValidAddress) den Wert true besitzt. Nach Fertigstellung der Tests wird die Test-Suite auf den Server übertragen; Abbildung 5.15 zeigt den Dialog nach erfolgreichem Deployment der Test-Suite. Abbildung 5.15.: Deployment einer Test-Suite über den JDeveloper Anschließend wird die Test-Suite über die BPEL-Console gestartet und es wird ein Testbericht angezeigt, wie in Abbildung 5.16 dargestellt. Im Beispiel ist der Testfall InvalidStreet aufgrund einer nicht erfüllten Assertion fehlgeschlagen Stresstest des»creditrating«-prozesses Die Oracle BPEL-Console ermöglicht die Ausführung einfacher Stresstests für Prozesse, die eine relativ kurze Laufzeit haben. Dabei kann die Anzahl der Iterationen sowie der zu verwendenden Threads angegeben werden. In diesem Beispiel sollen 5 Threads jeweils 50 Instanzen des»creditrating«-prozesses ausführen. Nach Start des Stresstestes 80

91 5.6. Test und Betrieb Abbildung 5.16.: BPEL-Testbericht nach Ausführung einer Test-Suite wird eine Statistik angezeigt, welche die minimale, maximale und durchschnittliche Ausführungszeit des Prozesses aufführt, wie der Ausschnitt aus dem Bericht in Abbildung 5.17 zeigt. Der hier durchgeführte Test ist selbstverständlich nur bedingt aussagekräftig, da es sich um einen extrem einfachen Service handelt und die komplette Installation auf einem Desktop-Entwicklungsrechner vorgenommen wurde. Mit dem vorgestellten Hilfsmittel lassen sich jedoch auf einfache Weise schnell einfachere Lasttests durchführen, um beispielsweise eine grobe Ressourcenplanung durchzuführen Test des Gesamtprozesses»Kreditvergabe«Abschließend soll der gesamte Prozess einem Composite-Test unterzogen werden, um das Zusammenspiel der einzelnen Services zu überprüfen. Hierzu werden beispielhaft zwei Testfälle definiert: Im ersten wird lediglich eine Startnachricht vorgegeben, anschließend werden alle beteiligten Services tatsächlich aufgerufen. Im zweiten Fall wird die Kreditsumme in der Startnachricht größer als 5000 e betragen und daher würde der Workflow-Service aufgerufen werden. Da dies bei der Durchführung automatisierter Tests nicht praktikabel ist, wird die menschliche Interaktion emuliert, indem die einund ausgehenden Nachrichten bei der Definition des Testfalles vorbelegt werden. Diese Nachrichten müssen dabei entweder manuell verfasst oder über die BPEL-Console aufgezeichnet und anschließend gespeichert werden der Oracle JDeveloper bietet leider 81

92 5. Entwicklung eines SOA-Prototypen Abbildung 5.17.: BPEL-Testbericht nach Ausführung eines Stresstests derzeit keinerlei Unterstützung für die Generierung von Stub-Nachrichten. In diesem vereinfachten Beispiel wird davon ausgegangen, dass das Ergebnis des Prozesses im Voraus bekannt ist denn die Implementierung der einzelnen Services ist ja bekannt. In einem realen Umfeld mit echten Web-Services fallen solche Tests jedoch sicherlich weniger trivial aus Überwachung und Logging Neben der Definition von Policies lassen sich mit dem Oracle Web Services Manager (OWSM) auch Statistiken bezüglich der Einhaltung der Richtlinien anzeigen. Abbildung 5.18 zeigt eine Übersicht mit einer graphischen Darstellung der SLA-Daten. Die aufgeführten Sicherheits- und Servicestatistiken lassen sich dann im Detail betrachten. Außerdem können zu Debug- bzw. Audit-Zwecken über den OWSM alle Requestund Response-Nachrichten eingesehen werden. Diese Daten stehen aber auch zusätzlich in einer Logdatei zur Verfügung. Für die Überwachung der Web-Services zur Laufzeit gibt es weiterhin die Möglichkeit, verschiedene Alarmregeln zu definieren, mit denen sich beispielsweise eine Benachrichtigung versenden lässt, sobald die Latenz eines Web-Services über einem definier- 82

93 5.7. Fazit Abbildung 5.18.: OWSM: Übersicht über SLA-Statistiken baren Wert liegt oder ein Service nicht erreichbar ist Fazit In diesem Abschnitt sollen die Erfahrungen bei der Erstellung des Prototypen abschließend zusammengefasst werden. Positiv zu bewerten ist die Integration der verschiedenen Komponenten wie Applikations-, BPA- und BPEL-Server sowie Business Rules Engine in die Entwicklungsumgebung JDeveloper. Auch die graphische Bearbeitung und das Deployment der BPEL- Prozesse und Test-Suites sind gut gelungen. Hier wäre allerdings eine noch komfortablere Integration mit dem BPEL-Server wünschenswert, sodass sich die BPEL-Prozesse direkt im JDeveloper starten, testen und debuggen lassen derzeit muss hier stets der Umweg über die BPEL-Console gegangen werden. Die Konfiguration der restlichen Komponenten lässt sich größtenteils problemlos über webbasierte, lokalisierte Oberflächen durchführen und ist in den meisten Fällen auch leicht verständlich und mit ausreichender Dokumentation versehen. Allgemein bietet Oracle eine sehr gute und ausführliche Dokumentationsbasis. Dazu zählt neben den Handbüchern, Beispielanwendungen und Demo-Projekten auch die Online-Com- 83