SOA mit Oracle Fusion Middleware - Diplomarbeit
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Diplomarbeit
SOA mit Oracle Fusion Middleware
zur Erlangung des akademischen Grades
Diplom-Informatiker (FH)
vorgelegt dem
Fachbereich Mathematik, Naturwissenschaften und Informatik der
Fachhochschule Gießen-Friedberg
von
Joachim Ansorg
im August 2007
Referent: Prof. Dr. rer. nat. Michael Jäger
Korreferent: Prof. Dr. rer. nat. Bodo Igler
Eidesstattliche Erklärung Hiermit versichere ich, die vorliegende Arbeit selbstständig und unter ausschließlicher Verwen- dung der angegebenen Literatur und Hilfsmittel erstellt zu haben. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungsbehörde vorge- legt und auch nicht veröffentlicht. Ort und Datum Unterschrift (Joachim Ansorg)
Einleitende Hinweise Querverweise. Verweise auf andere Stellen im Dokument werden grafisch hervorgehoben: ►Kapitel 1. Dies wird bei Verweisen auf Textstellen, Fußnoten und Literaturangaben verwendet. Literaturangaben. Quellenangaben werden im Fließtext angegeben. Das Format bei einem Verfasser besteht aus dem Nachnamen und einem Minuszeichen: ►[nachname-1]. Bei mehreren Autoren wird nur der Nachname des Hauptverfassers zusammen mit einem Pluszeichen in die An- gabe aufgenommen: ►[nachname+1]. Das numerische Suffix dient jeweils der Unterscheidung von sonst gleichnamigen Einträgen. Bei Literaturangaben für Bücher werden jeweils die relevanten Seiten angegeben. Viele der Bü- cher wurden in ihrer Online-Fassung gelesen1. Bei einigen ist es nicht möglich, die Seitennummer zum gelesenen Text zu ermitteln. Daher enthalten Literaturangaben zu diesen Online-Fassungen den Namen des gelesenen Abschnitts. Die Angaben zu den verwendeten Internetseiten enthalten keine Angabe über die genaue Stelle. Wikipedia-Artikel wurden nicht zur Erarbeitung dieser Arbeit verwendet. Verweise auf diese Arti- kel wurden jedoch eingefügt, um dem Leser einen schnellen Überblick zu bestimmten Themenge- bieten zu ermöglichen. Internetseiten. Inhaltlich wichtige Internetseiten werden als normale Literaturangaben einge- bunden. Andere Verweise auf Internetseiten werden bis auf die Füllfarbe wie interne Verweise ge- kennzeichnet. Die URL steht jeweils in der Fußnote, der Hostname im Fließtext: ►www.fh-gies- sen.de►2. Fachbegriffe. Englische Fachbegriffe werden, soweit möglich und sinnvoll, in der deutsch Übersetzung verwendet. Beim ersten Auftreten eines bislang unerwähnten Begriffes wird auf das Glossar im Anhang verwiesen: Fachbegriff•. Manche Begriffe werden detailliert behandelt. Im Glossar ist dann ein Verweis auf den jeweiligen Abschnitt der Arbeit zu finden. Es ist sinnvoll, das Glossar (►Anhang A) vor dem restlichen Teil dieser Arbeit zu lesen. 1 ►safari.oreilly.com ist ein Onlineportal, auf dem die wichtigsten Verleger von IT-Literatur ihre Bücher ge- gen einen monatlichen Betrag zum Lesen anbieten. 2 http://www.fh-giessen.de/fachbereich/mni/
Zusammenfassung
Zur Zeit wird das Thema „serviceorientierte Architektur“ (SOA) in der Informatik intensiv disku-
tiert. Für die Sylphen GmbH & Co. KG, dem Auftraggeber dieser Arbeit, ist es wichtig, Erfah-
rungswissen in solch aktuellen Gebieten zu besitzen. Neben theoretischem Wissen geht es vor al-
lem um die Evaluierung der praktischen Tauglichkeit für das Unternehmen. Daher wurde be-
schlossen, diesem Thema im Rahmen einer Diplomarbeit auf den Grund zu gehen.
Da Sylphen ein Partner von Oracle ist, wurde als technische Plattform Oracle Fusion Middleware•
gewählt. Die Aufgabenstellung lässt sich durch drei konkrete Fragen zusammenfassen:
Wie ist SOA, insbesondere aus Entwicklersicht, zu beurteilen?
Wie gut kann mit Oracle Fusion Middleware eine serviceorientierte Architektur entwickelt
werden?
Wie ist SOA in Bezug auf einen möglichen Einsatz bei Sylphen zu beurteilen?
Die vorliegende Diplomarbeit möchte diese Fragen beantworten. Deshalb wird die Thematik der
serviceorientierten Architekturen aus drei unterschiedlichen Richtungen betrachtet.
Im ersten Teil (►Abschnitt 1, S. 1ff) werden die Grundlagen von SOA und Fusion Middleware er-
läutert. Hier werden die wichtigsten Begrifflichkeiten definiert und erläutert. Außerdem werden
einige verwandte Technologien erläutert, soweit sie im weiteren Verlauf der Arbeit angewandt
werden.
Der zweite Teil (►Abschnitt 2, S. 18ff) baut darauf auf. Hier werden die praktischen Seiten der
serviceorientierten Architekturen beleuchtet. Dies geschieht, indem die Entwicklung einer service-
orientierten Anwendung dokumentiert wird. Hauptanliegen ist, die gewonnene Erfahrung festzu-
halten.
Der dritte Teil dieser Arbeit (►Abschnitt 3, S. 45ff) diskutiert die Thematik der serviceorientierten
Architekturen auf einer abstrakten, theoretischen Ebene. Hier wird ein Ansatz geschaffen, um die
Usability von Fusion Middleware bewerten zu können. Weiterhin wird die Anwendbarkeit von
SOA in kleinen Unternehmen untersucht. Zuletzt werden einige gängige Behauptungen zu SOA
untersucht, um so ein realistisches Bild der Thematik zu erhalten.
Im Fazit (►Abschnitt 4, S. 67ff) dieser Arbeit werden die Ergebnisse dieser Teile herangezogen,
um SOA und Oracle Fusion Middleware in wenigen Sätzen zusammenfassend zu beurteilen.Danksagung
Rückblickend kann ich sagen, dass mir die Diplomarbeit großen Spaß gemacht hat. Viele Tore zu
neuen Sachgebieten haben sich geöffnet und viel Freiraum gegeben, die Arbeit zu gestalten.
Rückblickend gilt jedoch auch, dass die Erstellung, besonders gegen Ende, viel Stress bedeutet.
Ohne der fleißigen Mithilfe einiger Personen sähe das vorliegende Ergebnis ganz anders aus►3.
Carsten, mein technischer Ansprechpartner bei Sylphen, war immer geduldig, kompetent und vol-
ler guter Ideen. Ihm war die Zeit nie zu schade, um in den Diskussionen über SOA mit an den Kan-
ten dieser Arbeit zu feilen.
Christoph hat sich Zeit genommen, das Dokument ausführlich unter die Lupe zu nehmen. Die da-
bei entstandenen Vorschläge zur Verbesserung haben viel zur Qualität beigetragen.
Auch mein Bruder Matthias hat viel beigesteuert: etliche gute Ansatzpunkte in den anfänglichen
Diskussionen über die Ziele der Arbeit, die OpenOffice-Dokumentenvorlage und vor allem viel
Zeit für die Korrekturen der einzelnen Teile.
Michael hat viel Zeit investiert, die Arbeit auf Herz und Nieren zu prüfen. Seine zahlreichen, detail-
lierten Anmerkungen haben viel zur Qualität und zum besseren Verständnis beigetragen.
Ralph möchte ich, stellvertretend für Sylphen, für die gute Zusammenarbeit mit der Firma danken.
Der unkomplizierte Umgang in der Firma ist immer wieder ein Plus.
Besonders dankbar bin ich auch all denen, die in den stellenweise ziemlich sauren Apfel gebissen
haben, die Rechtschreibung zu korrigieren: Carsten, Daniel, Lars, Matthias, Michael und Ralph.
3
Die Aufzählung erfolgt alphabetisch, meine Dankbarkeit gilt allen gleich.Inhaltsverzeichnis
Inhaltsverzeichnis
► Zusammenfassung...........................................................................v
► Danksagung...................................................................................vii
► Inhaltsverzeichnis...........................................................................ix
►1 Grundlagen......................................................................................1
►1.1 Serviceorientierte Architekturen.........................................................1
►1.1.1 Vorgeschichte und Randbedingungen...................................................1
►1.1.2 Definition.........................................................................................2
►1.1.3 Dienste............................................................................................4
►1.1.4 Muster.............................................................................................9
►1.1.5 Praxisberichte...................................................................................9
►1.2 Oracle Fusion Middleware................................................................10
►1.2.1 Oracle SOA-Suite.............................................................................10
►1.2.2 Entwicklungsumgebung....................................................................12
►1.3 Verwandte Technologien.................................................................12
►1.3.1 EJB.................................................................................................13
►1.3.2 Business Process Execution Language.................................................13
►1.3.3 Webservice-Erweiterungen................................................................15
►2 Konzeption und Implementierung einer SOA-Anwendung..........18
►2.1 Aufgabenstellung............................................................................18
►2.2 Analyse...........................................................................................20
►2.2.1 Anwendungsfälle.............................................................................20
►2.2.2 Geschäftsprozesse...........................................................................26
►2.3 Entwurf............................................................................................27
►2.3.1 Datenbank......................................................................................28
►2.3.2 Dienste..........................................................................................28
►2.4 Implementierung.............................................................................32
►2.4.1 Allgemeines....................................................................................32
►2.4.2 Entwicklung eines Basisdienstes.........................................................32
►2.4.3 Entwicklung eines Dienstes der Prozessschicht.....................................34
►2.5 Verbesserungsmöglichkeiten...........................................................38
►2.6 Bewertung.......................................................................................42
►3 Anwendung und Beurteilung.........................................................45
►3.1 Usability..........................................................................................45
►3.1.1 Definition.......................................................................................45
►3.1.2 Überblick der Bewertungsverfahren....................................................46
►3.1.3 Bewertungsvorschlag........................................................................48
►3.2 SOA in kleinen Unternehmen...........................................................55
►3.2.1 Umstellung kleiner Unternehmen.......................................................55
ixInhaltsverzeichnis
►3.2.2 SOA im Kundenauftrag.....................................................................59
►3.3 Theorie und Praxis..........................................................................61
►3.3.1 Versprechen an den Geschäftsbereich.................................................62
►3.3.2 Versprechen an den IT-Bereich..........................................................64
►4 Fazit...............................................................................................67
►4.1 SOA.................................................................................................67
►4.2 Oracle Fusion Middleware................................................................68
►4.3 Ausblicke........................................................................................69
►A Glossar..............................................................................................I
►B Detaillierte Datenbankstruktur......................................................IX
► Glossarverzeichnis..........................................................................XI
► Tabellenverzeichnis......................................................................XIII
► Abbildungsverzeichnis.................................................................XIV
► Literaturverzeichnis.......................................................................XV
► Datenträger...................................................................................XIX
x1 Grundlagen
1 Grundlagen
Zusammenfassung. In diesem Teil der Arbeit werden die Grundlagen erläutert, die für das
weitere Verständnis zwingend notwendig sind. Themen wie XSL•, XML Schema•, WSDL• und
SOAP• werden daher als bekannt vorausgesetzt. Eine kurze Erläuterung dieser Begriffe mit zu-
sätzlichen Literaturverweisen ist im Glossar (►Abschnitt A, S. I) zu finden.
1.1 Serviceorientierte Architekturen
1.1.1 Vorgeschichte und Randbedingungen
Zusammenfassung. Softwarearchitekturen haben sich im Laufe der Zeit immer wieder ge-
wandelt. Die folgenden Abschnitte geben einen kurzen, gerafften Überblick über die Entwicklung
bis hin zur serviceorientierten Architektur. Dabei werden die Entwicklungsschritte, die für diese
Arbeit nicht relevant sind, bewusst ausgelassen.
Entwicklung der Softwarearchitektur. Zu Anfang wurde Software monolithisch program-
miert. Alles bestand aus einem großen Stück Quellcode. Die Probleme, die damit ebenfalls er-
schaffen wurden, versuchte man durch Modularisierung zu lösen.
Der Trend ging weiter zu Terminals, um so von mehreren Orten auf die Mainframe-Software zu-
greifen zu können ►[britton+1, Abschnitt 2.1]. Die nächsten Entwicklungsschritte führten zu netz-
werkfähiger Software, wie beispielsweise Datenbank-Anwendungen.
Durch die weitere Entwicklung wurden allgemeinere Modelle verteilter Systeme geschaffen, wie
etwa das Client-Server Modell. Programme sollen die Fähigkeiten einer Serversoftware verwen-
den können. Eine der dazu entwickelten Lösungen ist RPC, der Aufruf von entfernten Methoden.
Später wurde CORBA• definiert, eine Spezifikation objektorientierter Middleware. Sie soll die Er-
stellung verteilter Anwendungen vereinfachen.
Das Internet hat die Softwarewelt weiter verändert. Die Einsatzgebiete von Anwendungen wer-
den größer und die Anforderungen höher. XML-RPC wurde bespielsweise als pragmatischer An-
satz geschaffen, entfernte Methodenaufrufe mit Hilfe von XML und den bekannten Internetproto-
kollen zu ermöglichen. Die formalisierende Weiterentwicklung von XML-RPC führte zu SOAP.
SOAP spielt für Webservices eine große Rolle. Diese sind eine der technischen Möglichkeiten die
Dienste einer serviceorientierten Architektur zu erstellen.
Die Geschichte zeigt, dass in der Softwareentwicklung Fehler begangen wurden. Die erstellten
Anwendungen waren groß und unflexibel. Es war nicht oder nur mit sehr hohem Aufwand mög-
lich, Änderungen am System durchzuführen. Die immer neuen Entwicklungen möchten die Pro-
11 Grundlagen
bleme der Vergangenheit lösen und gleichzeitig innovativ sein. Allgemein gilt, dass die Erstellung
von Software immer mehr auf die Flexibilität des Gesamtsystems ausgerichtet ist.
Eine der zur Zeit diskutierten Innovationen der Softwarearchitektur ist SOA.
Geschäftliche Aspekte. Die Entwicklung der oben genannten Softwaresysteme wurde meis-
tens von kommerziellen Interessen getrieben.
Unternehmen müssen sich in einer immer mehr globalisierten Welt behaupten. Die an sie gestell-
ten Anforderungen können sich schnell ändern. Geschäftsprozesse ändern sich nicht mehr in jährli-
chen Abständen, sondern monatlich oder gar wöchentlich ►[carter-1, S. 8].
Die Flexibilität eines Unternehmens wird daher immer wichtiger. Nur so ist es möglich, sich dem
Markt und den neuen Geschäftschancen anzupassen. Um diese neue Flexibilität durchsetzen zu
können, wird Informationstechnik benötigt. Ohne der Hilfe der Informatik sind in der heutigen
Zeit Verbesserungen eines Unternehmens nur schwer möglich.
IT- und Geschäftsbereich sind notwendig, um ein Unternehmen . Daher ist es notwendig, diese
beiden Bereiche aufeinander abzustimmen. Bei den zu entwickelnden Softwaresystemen wird auf
hohe Flexibilität geachtet um ein Unternehmen für die neuen Herausforderungen bereit zu ma-
chen.
Das Konzept der serviceorientierten Architektur verspricht, Unternehmen zu einer höheren Flexi-
bilität zu verhelfen.
1.1.2 Definition
Zusammenfassung. Serviceorientierte Architekturen werden ganz unterschiedlich definiert.
Im folgenden Abschnitt werden zuerst die bestehenden Definitionen der Literatur zusammenge-
fasst und diskutiert. Anschließend wird der Versuch einer eigenen Definition unternommen.
1.1.2.1 Bestehende Definitionen
Die verfügbare Literatur enthält einige Definitionen von serviceorientierten Architekturen. Abhän-
gig von ihrer jeweiligen Perspektive unterscheiden sie sich in verschiedenen Punkten. Wie schon
Tilkov und Starke schreiben, gibt es keine einzelne, umfassende Definition des Begriffes
►[starke+1, S. 9]. Im Folgenden werden nun einige der Definitionen aufgeführt. So können die
verschiedenen Schattierungen des Begriffes erfasst werden.
„Service oriented architecture (SOA) is a business-driven IT architectural ap-
proach that supports integrating your business as linked, repeatable business
tasks or services. SOA helps today's businesses innovate by ensuring that IT
systems can adapt quickly, easily, and economically to support rapidly chang-
21 Grundlagen
ing business needs. It helps customers increase the flexibility of their business
processes, strengthen their underlying IT infrastructure, and reuse their exist-
ing IT investments by creating connections among disparate applications and
information sources.“ ►[carter-1, S. 44]
Bei dieser betriebswirtschaftlichen und organisationsorientierten Sicht werden einige Punkte be-
sonders betont. Hier wird vor allem die Ausrichtung der IT an den geschäftlichen Zielen des Un-
ternehmens deutlich. Die Motivation einer serviceorientierten Architektur ist zuallererst der wirt-
schaftliche Mehrwert, der so für ein Unternehmen entsteht. Das Ziel ist, die Flexibilität eines Un-
ternehmens mit einer geeigneten technischen Infrastruktur zu unterstützen.
„A service-oriented architecture is a style of design that guides all aspects of
creating and using business services throughout their lifecycle (from concep-
tion to retirement). An SOA is also a way to define and provision an IT infra-
structure to allow different applications to exchange data and participate in
business processes, regardless of the operating systems or programming lan-
guages underlying those applications.“ ►[newcomer+1, Abschnitt „Introduc-
tion to SOA with Web Services“]
Hier wird deutlich, dass eine serviceorientierte Architektur unabhängig von der Implementierungs-
technologie eingesetzt werden kann. SOA-Dienste werden hauptsächlich eingesetzt, um Daten
auszutauschen und um in die Geschäftsprozesse eines Unternehmens integriert zu werden.
„SOA is not a product. It isn't something that you build or buy. SOA is some-
thing you do. It's an approach taken when building software systems. SOA is
like health and fitness. There is no quick fix. You can't just buy a diet book and
join a health club and expect to get fit. You have to follow the diet and exer-
cise regularly. It requires a lifestyle change. The same is true of SOA.“
►[manes-1, S. 5]
Diese allgemeine Anmerkung betont, dass SOA nicht eine Ansammlung technischer Dienste ist. Es
handelt sich um ein unternehmensübergreifendes Konzept. SOA ist nicht bloß eine Softwarearchi-
tektur, sondern die Denkweise eines Unternehmens, ein Paradigma.
Die erfolgreiche Einführung dieses Ansatzes erfordert Zeit. Ebenfalls sehr wichtig ist die Unter-
stützung durch die Unternehmensführung, um wirklich diesen übergreifenden Ansatz durchsetzen
zu können.
1.1.2.2 Eigene Definition
Definition. Dieser Abschnittes schlägt eine eigene Definition vor. Neben dem persönlichen
Verständnis serviceorientierter Architekturen dienen die oben erfassten Definitionen als Grundla-
ge.
31 Grundlagen
„Eine serviceorientierte Architektur (SOA) bezeichnet ein IT-gestütztes, un-
ternehmensweites Paradigma zur Steigerung der geschäftlichen Agilität. Das
zentrale Strukturelement, der Dienst, hat eine geschäftliche Ausrichtung,
wird technisch realisiert, ist idealerweise im Unternehmen einzigartig und
wird – bevorzugt lose gekoppelt – in verschiedenen Geschäftsprozessen ver-
wendet.“
Erläuterung. SOA wird besonders als Denkweise eines Unternehmens betont. Diese betrifft
vor allem die geschäftliche Seite, braucht zur Realisierung jedoch die Unterstützung der techni-
schen Seite. Der Dienst ist Merkmal beider Seiten. Der Nutzen eines Dienstes entsteht erst durch
den Einsatz in den fachlichen geprägten Bereichen – den Geschäftsprozessen.
1.1.3 Dienste
Zusammenfassung. Ein Dienst (engl. service) ist das wesentliche Element der serviceorientier-
ten Architektur. In diesem Abschnitt werden die Grundlagen des Dienstbegriffes erläutert. Weiter-
hin wird ein Modell vorgestellt, wie die Dienste einer serviceorientierten Architektur strukturiert
werden können.
1.1.3.1 Ursprung
Der Begriff „Dienst“ stammt aus der Geschäftswelt und bezeichnet ganz allgemein eine Dienstleis-
tung. Diese benötigt einen Anbieter (engl. provider) und einen Konsumenten (engl. consumer). Bei-
spielsweise ist ein Patient der Konsument der Dienstleistung, die von einem Arzt angeboten wird.
Die Informatik bedient sich dieser Begriffe und überträgt sie auf technische Systeme. Dienste be-
zeichnen auch hier Dienstleistungen zum Erledigen bestimmter Aufgaben.
1.1.3.2 Definition
Da Dienste die wichtigsten Bausteine einer serviceorientierten Architektur sind, werden nun die
charakteristischen Eigenschaften beschrieben. Im Folgenden werden die Stellen des Systems, die
einen Dienst verwenden, als Dienstkonsumenten bezeichnet. Der Dienst selbst ist der Dienstanbie-
ter. Ein Anbieter kann auch als Konsument anderer Dienste agieren, um seine Dienstleistung zu er-
bringen.
Die folgenden Absätze behandeln die Eigenschaften, die einen Dienst charakterisieren.
Geschäftsfunktionalität. Ein Dienst wird vor allem durch den geschäftlichen Mehrwert
definiert. Er enthält eine definierte Menge von Funktionen, die für die Aufgaben eines Un-
ternehmens relevant sind.
Es gibt auch Dienste, die rein technische Aufgaben erfüllen. Diese sind sinnvoll, jedoch
nicht die Grundbausteine einer serviceorientierten Architektur. ►[starke+1, S. 19]
41 Grundlagen
Die Geschäftslogik wird durch die Schnittstelle verfügbar gemacht. Sie ist Teil der Imple-
mentierung ►[krafzig+1, S. 60].
Schnittstelle. Der Zugriff auf einen Dienst geschieht nur über eine Schnittstelle. Dies er-
möglicht die lose Kopplung von Diensten und die Möglichkeit, die Implementierung ohne
Einfluss auf die Konsumenten auszutauschen. ►[krafzig+1, S. 60], ►[starke+1, S. 19]
Daten. Zu einem Dienst können auch Daten gehören. Diese stammen aus externen
Quellen, werden aber vom Dienst verwaltet (siehe ►Basisdienste, S. 6). Die Dienstdaten
orientieren sich an der jeweiligen Geschäftsfunktionalität, die hier implementiert wird. Da-
bei gilt, dass nur diese Daten zum Dienst gehören. Daten anderer Bereiche werden von
anderen Diensten verwaltet. ►[krafzig+1, S. 60]
Implementierung. Jeder Dienst muss über eine Implementierung seiner Schnittstelle
verfügen. ►[krafzig+1, S. 60], ►[starke+1, S. 19]
Die Implementierung umfasst mindestens die Geschäftsfunktionalität des Dienstes. Wei-
terhin kann sich hier beispielsweise die Persistenzlogik zur Verwaltung der Dienstdaten
befinden.
Dienstvertrag. Zu jedem Dienst gehört eine Beschreibung. Diese enthält Informationen
über den Zweck, die Funktionalität, die Rahmenbedingungen und die Verwendung des
Dienstes. Eine formale Beschreibung, durch WSDL oder IDL•, ist nicht zwingend, erleich-
tert Werkzeugen und Entwicklern jedoch die Arbeit. ►[krafzig+1, S. 59f], ►[starke+1,
S. 21f]
Ein Dienst ist nicht an eine konkrete Implementierungstechnologie gebunden. Meist werden hier-
für jedoch Webservices verwendet. Diese basieren auf verschiedenen XML-Technologien. Dienst-
konsumenten verwenden SOAP um auf die angebotene Funktionalität zuzugreifen. Das Angebot
eines Webservices wird mit Hilfe von WSDL beschrieben.
1.1.3.3 Diensttypen
Zusammenfassung. Dienste unterscheiden sich in verschiedenen Punkten. Es gilt, ein System
zu finden, mit denen die unterschiedlichen Arten klassifiziert werden können. Die Literatur bietet
verschiedene Modelle an, mit denen die Struktur einer serviceorientierten Architektur erfasst
werden kann.
►[krafzig+1, S. 67-85] beschreibt ein Modell, das Dienste in vier Kategorien einteilt. ►[erl-1, S.
327-353] beschreibt eine alternative Möglichkeit, wie ein serviceorientiertes System strukturiert
werden kann. ►[carter-1, S. 65-69] beschreibt ein ESB•-zentrisches Modell, das in seiner Gesamt-
heit eher an der fachlichen Seite orientiert ist.
51 Grundlagen
Das hier vorgestellte Modell entspricht der Einteilung nach Krafzig et al. Es wird auch im weiteren
Verlauf dieser Arbeit verwendet.
Abbildung 1: Dienststruktur einer serviceorientierten Architektur, nach ►[krafzig+1]
Dienststruktur. Die technische Struktur einer serviceorientierten Architektur kann durch vier
Schichten dargestellt werden (siehe ►Abb. 1, S. 6). Zu beachten ist, dass der im Folgenden ver-
wendete Begriff „Schicht“ nicht dem gewöhnlichen Verständnis in der Softwaretechnik entspricht.
Beispielsweise dürfen auch Zugriffe über Schichten hinweg erfolgen. „Schicht“ ist hier vielmehr ein
Konzept, mit dem die Einteilung der Architektur beschrieben werden kann. Siehe dazu auch
►[krafzig+1, S. 82f].
►Abbildung 1 zeigt eine mögliche Konfiguration dafür, welche Dienste des Systems als Konsument
und welche als Dienstanbieter arbeiten.
Basisdienste►4. Die Dienste dieser Schicht sind die Grundbausteine des Systems. Die Wieder-
verwendbarkeit ist daher hoch. Die Implementierung hat eine geringe oder mittlere Komplexität.
Basisdienste sind zustandslos und können zwei verschiedene Ausprägungen haben:
4
Engl. Basic services
61 Grundlagen
Daten-zentrische Dienste. Ein solcher Dienst verwaltet persis-
tente Daten – nicht alle Daten des Systems, sondern nur die, die
zur Funktionalität des Dienstes gehören.
Er muss alle Daten, auf die er zugreift, alleine besitzen. Andere
Abbildung 2: Symbol
Dienste dürfen nicht auf diese Daten zugreifen. Auch sind für Basisdienst
einen Dienst Zugriffe auf die Daten anderer Dienste nicht erlaubt.
Logik-zentrische Dienste. Ein solcher Dienst kapselt einzelne Algorithmen oder Regeln
des Geschäftsbereiches. Die Logik orientiert sich an der Wiederverwendbarkeit, sie muss
also in anderen Diensten sinnvoll eingesetzt werden können. Durch die Abstraktion be-
stimmter Logikelemente an einer Stelle wird Redundanz vermieden und die Änderbarkeit
des Systems erhöht.
Bei Altanwendungen wird oft benötigte Logik in Bibliotheken ausgelagert, um sie an ver-
schiedenen Stellen verwenden zu können. Dies ist jedoch nicht redundanzfrei. Wenn ver-
schiedene Dienste gleiche Logik benötigen, soll diese durch Aufrufe anderer Dienste und
nicht durch das Einbinden von Bibliotheken eingebunden werden.
Eine serviceorientierte Anwendung benötigt mehrere Basisdienste, um den gesamten Fachbereich
abzudecken. Dienste in der Basisschicht können auch als Proxies zu öffentlichen Diensten Dritter
dienen. Zu beachten ist, das Basisdienste nur Dienstanbieter sind, sie agieren also nicht als Dienst-
konsumenten.
Vermittlerdienste►5. Die Schicht über der Basisschicht enthält Diens-
te, die der Vermittlung und Anpassung dienen. Diese sind zustandslos und
von mittlerer bis hoher Komplexität. Krafzig et al. teilt diese Dienste in
vier unterschiedliche Typen ein:
Abbildung 3: Symbol
Technologie-Gateway. Diese Dienste dienen dazu, die Kluft zwi- Vermittlerdienst
schen verschiedenen Technologien zu überbrücken. Sie können
gut zur Integration von Altanwendungen verwendet werden. Dazu bietet ein Gateway-
Dienst die Funktionalität des zu integrierenden Systems in Form einer Dienst-Schnittstelle
an. Der Gateway-Dienst ist eine Möglichkeit, das Altsystem unsichtbar in die SOA-Land-
schaft einzubinden.
Adapter. Allgemein ist „Adapter“ ein Strukturmuster von Gamma et al., das dazu dient,
eine Schnittstelle in anderer Form anzubieten ►[gamma+1, S. 151-163]. Ein Adap-
ter-Dienst wird dazu verwendet, die Schnittstelle eines anderen Dienstes anzupassen.
Beispielsweise können Adapter angewandt werden, wenn Unternehmen zusammenge-
schlossen werden. Die Dienste des einen werden durch Adapter angepasst. So können sie
5
Engl. intermediary services
71 Grundlagen
in der SOA-Landschaft des anderen Unternehmens in der dort gebräuchlichen Form ver-
wendet werden.
Fassade. Dieser Begriff bezeichnet ein GoF-Strukturmuster, bei dem eine einzelne
Schnittstelle den Zugriff auf verschiedene Schnittstellen eines Subsystems vereinfacht
►[gamma+1, S. 189-198]. Ganz ähnlich dient eine Fassade in einem SOA-System dazu,
die Funktionalität mehrerer Dienste vereinfacht durch einen einzelnen Dienstes anzubie-
ten.
Dienste mit funktionalem Mehrwert. Es kann nötig sein, dass die Funktionalität beste-
hender Dienste erweitert werden soll, ohne sie selbst zu ändern. Als Lösung kann ein neu-
er Dienst erstellt werden, der zusätzlich zur Schnittstelle des bisherigen Dienstes neue
Funktionalität integriert. Ein solcher Mehrwert-Dienst kann also als Proxy mit zusätzlicher
Funktionalität gesehen werden.
Prozessdienste►6. Die Geschäftsprozesse eines Unternehmens wer-
den durch Dienste dieser Kategorie umgesetzt. Diese sind zustandsbehaf-
tet und gleichzeitig Dienstanbieter und -konsument. Die einzelnen Aktio-
nen des Prozesses werden von Diensten darunterliegender Schichten be-
reitgestellt. Ein Prozessdienst ist somit für die Steuerung des Kontrollflus- Abbildung 4: Symbol
Prozessdienst
ses zuständig.
Die Trennung zwischen Prozess- und Kernlogik eines Unternehmens ist eine wichtige Vorausset-
zung für BPM•. Dies wird durch die Dienste der Prozessschicht erreicht; hier ist keine Kernlogik
mehr direkt implementiert.
Öffentliche Unternehmensdienste►7. Dienstleistungen eines Unternehmens können ande-
ren durch Dienste zugänglich gemacht werden. Beispielsweise bietet eBay verschiedene Dienste
an, mit denen Artikel verwaltet werden können ►ebay.com8. Die öffentlichen Unternehmens-
dienste müssen besondere Anforderungen erfüllen:
Entkopplung der Kommunikation. Die Dienstkonsumenten sind im Voraus nicht be-
kannt. Um diese nicht einzuschränken, muss auch eine entkoppelte, asynchrone Kommu-
nikation möglich sein.
Sicherheit. Die Sicherheit eines unternehmensintern eingesetzten Dienstes ist meist nicht
so kritisch wie die eines öffentlichen. Je nach Art der übertragenen Daten sind verschiede-
ne Sicherheitsmaßnahmen notwendig – beispielsweise Authentifizierung, Nachrichten-Si-
gnierung oder Verschlüsselung.
6
Engl. Process-centric services
7
Engl. Public Enterprise services
8
http://developer.ebay.com/products/overview/
81 Grundlagen
Abrechnung. Die Verwendung eines Dienstes ist für die Konsumenten gewöhnlich nicht
kostenlos. Für einen Dienstanbieter muss es möglich sein, die gelieferte Leistung in Rech-
nung zu stellen.
Unternehmens-Anwendungen. Dies sind keine Dienste, sondern die
Anwendungen, die diese verwenden. Sie starten Geschäftsprozesse, ver-
arbeiten deren Ergebnisse und ermöglichen Benutzern die Interaktion mit
den Diensten. Unternehmens-Anwendungen machen die serviceorientier-
te Architektur für Endbenutzer zugänglich. Abbildung 5: Symbol
Unternehmensanwen-
dung
1.1.4 Muster
Aktuell gibt es Bemühungen, Musterkataloge für SOA zu erstellen. Bislang sind diese Sammlungen
jedoch nur im Internet zu finden. Ganze Bücher zu diesem Thema gibt es noch nicht. Das einzige
auffindbare Werk zu SOA Mustern ist ►[rotem-1] und befindet sich noch in der Entstehung. Vor
Anfang 2008 ist nicht mit der Veröffentlichung zu rechnen.
Es gibt gute Muster zu verwandten Bereichen. So bieten beispielsweise ►[fowler-1] und insbeson-
dere ►[hohpe+1] Inspirationen für eine serviceorientierte Architektur. Die dort dokumentierten
Muster sind jedoch nur manchmal direkt auf serviceorientierte Architekturen zu übertragen. Das
Muster-Wissen in verwandten Bereiche kann jedoch für die zu entwickelnden Systeme nur eine
Hilfe sein.
Im Internet ist unter ►[jones-1] eine Sammlung von 13 Anti-Mustern►9 zu finden, die auf SOA zu-
geschnitten sind. Eine Sammlung von Mustern verschiedener Quellen ist in ►[soaprpc-1] verfüg-
bar – der Umfang lässt jedoch zu wünschen übrig. ►[bigatti-1] und ►[bigatti-2] definieren Muster
für die Entwicklung von Webservice•-Konsumenten.
Insgesamt sind die vorhandenen Ressourcen an SOA-Mustern sehr dürftig. Es ist jedoch zu erwar-
ten, dass durch die praktische Arbeit mit SOA-Systemen neue Erfahrungen gewonnen werden
können, die in Form von Mustern für alle publiziert werden.
1.1.5 Praxisberichte
In der Literatur sind einige Berichte über erfolgreiche SOA-Projekte zu finden. Hier sind die wich-
tigsten zusammen aufgeführt.
IBM ►[carter-1, S. 223-243]
People's Bank of China ►[carter-1, S. 275-277]
9
Ein Anti-Muster beschreibt das Gegenteil von Mustern, also Lösungen, die nicht angewandet werden soll-
ten.
91 Grundlagen
ING-DiBa ►[carter-1, S. 278-279]
Deutsche Post AG ►[krafzig+1, S. 311-324]
Credit Suisse ►[krafzig+1, S. 341-357]
Volks- und Raiffeisenbanken ►[starke+1, S. 681-694]
1.2 Oracle Fusion Middleware
Ganz allgemein ist Oracle Fusion Middleware eine Zusammenstellung von vielen Oracle-Produk-
ten, die zur Entwicklung von verteilten Anwendungen verwendet werden können. SOA ist einer
der Bereiche, die Oracle mit der Middleware abdecken möchte. Im Folgenden wird dieser Bereich
von Fusion Middleware genauer untersucht.
1.2.1 Oracle SOA-Suite
Der technische Rahmen dieser Arbeit ist durch Oracles SOA-Suite gegeben. Dies ist die Kompo-
nente von Fusion Middleware, die zur Entwicklung von SOA-Anwendungen verwendet wird. Die
SOA-Suite selbst enthält verschiedene Teile. Diese werden zur Realisierung der technischen Seite
einer serviceorientierten Architektur verwendet.
Die wichtigsten Komponenten werden im Folgenden beschrieben. Somit wird das Fundament für
das Verständnis der folgenden Teile dieser Arbeit gelegt, in denen Fusion Middleware eingesetzt
wird.
1.2.1.1 BPEL-Process Manager
Fusion Middleware unterstützt BPEL• 1.1. Das bedeutet, dass alle Bereiche von Entwicklung bis
hin zum Betrieb durch Werkzeuge und Programme abgedeckt werden. Die Komponente, die dies
unterstützt ist Oracle BPEL-Process Manager. Im Folgenden werden die einzelnen Teile des Pro-
dukts beschrieben:
BPEL Engine. Dies ist Oracles Laufzeitumgebung für BPEL-Prozesse. Die Funktionalität
deckt den gesamten Sprachumfang von BPEL ab und umfasst einige zusätzliche Erweite-
rungen. So werden beispielsweise Prozesse mit langer Laufzeit unterstützt, indem ihr Sta-
tus in einer Datenbank festgehalten wird. ►[oracle-10, S. 2]
BPEL Konsole. Dies ist eine Webanwendung mit der entwickelte Prozesse überwacht,
getestet, auf Fehler untersucht und verwaltet werden können.
Die Konsole zeigt alle verfügbaren BPEL-Prozesse in einer Übersicht an und erlaubt deren
Administration.
101 Grundlagen
Zur Fehlersuche kann der Kontrollfluss einzelner Instanzen genauer untersucht werden.
Dabei können zum Beispiel die übertragenen SOAP-Nachrichten nachvollzogen und über-
prüft werden.
Weiterhin bietet die Konsole auch die Möglichkeit, BPEL-Tests auszuführen, die vorher in
JDeveloper definiert wurden.
Integrationsdienste. Oracle liefert einige Dienste mit, die für die BPEL-Entwicklung zu-
sätzliche Funktionalität bieten. So werden Abläufe unterstützt, die in Geschäftsprozessen
oft eine Rolle spielen. Die Funktionalität verteilt sich auf die folgenden Bereiche:
Benachrichtigungen. Dieser Dienst bietet den Versand von Benachrichtigungen
an, um so verschiedenen Personen während der Prozessabarbeitung Informationen
zukommen zu lassen. Der Versand kann beispielsweise per E-Mail oder SMS erfol-
gen.
Workflow. In diesem Bereich decken verschiedene Dienste die Abfrage und Ver-
waltung von Aufgaben ab. So können beispielsweise Personen oder Gruppen Aufga-
ben zugewiesen werden, die im Rahmen des gerade abgearbeiteten Geschäftspro-
zesses zu erledigen sind. Ein anderer Dienst bietet Dienst-Konsumenten Zugriff auf
die registrierten Benutzer. Hiermit kann beispielsweise Authentifizierung in
BPEL-Prozessen integriert werden.
Detaillierte Informationen zu den mitgelieferten Diensten sind in [oracle-2, S. 203-372]
verfügbar.
BPEL Designer. Der Designer ist eine Erweiterung für JDeveloper oder Eclipse mit der
BPEL-Prozesse grafisch unterstützt entwickelt werden können. Dies ist das zentrale
Werkzeug für Entwickler zum Umgang mit dem BPEL-Process Manager; sie ermöglicht den
Zugriff auf alle anderen oben erwähnten Module des BPEL-Process Managers.
1.2.1.2 Oracle Webservice–Manager
Mit dieser Webanwendung von Oracle können Dienste verwaltet, abgesichert und überwacht
werden ►[oracle-11].
Für einen Benutzer der Anwendung sind Richtlinien (policies) die Hauptelemente dieses
Oracle Produktes. Mit ihnen können Diensteigenschaften wie Authentifizierung, Autorisie-
rung oder Verschlüsselung definiert werden. Verschiedene dieser Definitionen können un-
ter einem Namen zusammengefasst werden und anschließend ein oder mehreren Diens-
111 Grundlagen
ten zugewiesen werden. Die so konfigurierten Dienste verhalten sich dann den Richtlinien
entsprechend.
Dienste, die in Oracles Webservice-Manager eingebunden sind, können so leicht kontrol-
liert werden. Beispielsweise lassen sich Authentifizierungsversuche, Latenzzeiten oder
auch die übertragenen Daten leicht überwachen.
Im praktischen Teil dieser Arbeit wird die Verwendung von Oracles Webservice-Manager an ei-
nem Beispiel demonstriert (siehe ►Abschnitt 2.5.1.1, Seite 38).
1.2.2 Entwicklungsumgebung
Oracle stellt neben den beschriebenen SOA-Produkten auch die Werkzeuge zur Verfügung, um
die eigentliche Entwicklung durchzuführen. Die für Fusion Middleware unterstützten Umgebungen
sind JDeveloper und Eclipse. JDeveloper hat jedoch zur Zeit einen Vorsprung, da hier sehr viele
Produkte von Oracle gut integriert sind, was die Entwicklung von Oracle-basierten Systemen ver-
einfacht.
JDeveloper deckt viele Bereiche der SOA-Entwicklung ab:
Webservice-Entwicklung. Mit JDeveloper können SOAP- und REST•-Dienste entwickelt
werden. Zum Beispiel wird die Entwicklung von JAX-WS• und EJB3 Diensten unterstützt.
BPEL-Entwicklung. Die BPEL-Prozesse können in einer grafischen Umgebung entworfen
werden. Es werden alle Elemente der BPEL 1.1 Spezifikation unterstützt. Außerdem kön-
nen auch Oracles Erweiterungen, wie etwa die oben genannten Integrationsdienste, ver-
wendet werden.
Datenbankentwurf. Dies ist zwar nicht direkt für SOA relevant, für die Neuentwicklung
von Diensten ist jedoch auch die Entwicklung der Datenbankstruktur notwendig. Neben
der Entwicklung eines Schemas wird die Organisation in einem ERD, die Generierung von
SQL sowie das automatisierte Einspielen in die Datenbank unterstützt.
Außerdem unterstützt JDeveloper JPA und Oracle Toplink. Somit kann leicht auf die Daten
der Dienste zugegriffen werden.
1.3 Verwandte Technologien
Bei der Entwicklung einer serviceorientierten Architektur kommt ein Entwickler mit verschiede-
nen Bereichen in Berührung, die nicht direkt zu WSDL oder SOAP gehören. In den nächsten Ab-
schnitten werden alle Gebiete kurz erläutert, die für diese Arbeit relevant sind.
121 Grundlagen
1.3.1 EJB
EJB• ist eine in JSR-220 spezifizierte Architektur zur Entwicklung von Java-basierten Geschäftsan-
wendungen ►[jsr-220]. In dieser Spezifikation werden die Ziele der Enterprise JavaBeans Archi-
tektur aufgezählt:
EJB soll die Standard-Architektur zur Entwicklung von Java-basierten Geschäftsanwendun-
gen sein.
Es soll die Standard-Architektur zur Erstellung von komponentenbasierten, verteilten Java-
Anwendungen sein.
Die Unterstützung von Webservices soll von Beginn an integriert sein.
Die Abstraktion von Dingen wie Transaktionen, Connection-Pooling oder Multi-Threading
soll Programmierern eine einfache, von technischen Details unbeschwerte Entwicklung er-
möglichen.
„Write Once, Run Anywhere™“ soll den Einsatz auf verschiedenen Plattformen ermögli-
chen.
Die Kompatibilität mit anderen Lösungen und Standards spielt eine große Rolle. So werden in der
Spezifikation folgende Punkte genannt:
Die Anbieter-übergreifende Entwicklung und Verwendung von Komponenten wird durch
die Spezifikation unterstützt.
Unterstützung der Anbieter-übergreifenden Verwendung von EJB-Entwicklungswerkzeu-
gen wird geboten.
Kompatibilität mit dem CORBA-Protokoll.
1.3.2 Business Process Execution Language
1.3.2.1 Definition
„BPEL4WS defines a model and a grammar for describing the behavior of a
business process based on interactions between the process and its partners.
The interaction with each partner occurs through Web Service interfaces,
and the structure of the relationship at the interface level is encapsulated in
what we call a partner link.“ ►[ibm-2, S. 10]
Mit BPEL►10 kann das Verhalten von Geschäftsprozessen plattformübergreifend festgehalten wer-
den. Die Kommunikation mit externen Stellen erfolgt ausschließlich über Webservices►11. BPEL
10
Hier wird Version 1.1 statt der aktuellen Version 2.0 beschrieben, da Fusion Middleware die neue Version
noch nicht unterstützt.
131 Grundlagen
spielt dabei das zentrale Kontrollorgan und steuert so die Zusammenarbeit der beteiligten Diens-
te.
BPEL basiert hauptsächlich auf WSDL, XML Schema, XPath und WS-Addressing• ►[ibm-2, S. 11].
Ein BPEL-Prozess ist im Unterschied zu normalen Diensten zustandsbehaftet. Mit Hilfe der
Sprachmittel wird die Kommunikation zwischen verschiedenen Parteien gesteuert.
In Fusion Middleware wird BPEL dazu verwendet, Prozessdienste (siehe ►Abschnitt 1.1.3.3 S. 8)
zu implementieren. Oracle erweitert die Funktionalität im Vergleich mit der offiziellen Spezifikati-
on etwas. Diese Erweiterungen werden weiter unten beschrieben.
Prozessarten. BPEL unterstützt zwei Arten, Geschäftsprozesse zu definieren: ausführbar
oder abstrakt ►[ibm-2, S. 8-10]. Ein in BPEL definierter Geschäftsprozess wird als BPEL-Prozess
bezeichnet. Ein BPEL-Prozess ist zustandsbehaftet; die Instanzen können von langer Laufzeit sein.
Abstrakte Prozesse dienen der Beschreibung von Geschäftsprozessen. Dabei liegt der Schwer-
punkt auf den ausgetauschten Nachrichten. Ziel ist, eine öffentlich zugängliche, formale und ab-
strakte Beschreibung von Geschäftsprozessen anzubieten, ohne dabei unternehmensinterne Logik
offenzulegen.
Ausführbare Prozesse dagegen enthalten eine vollständige Definition des Geschäftsprozesses und
können daher in einer Laufzeitumgebung ausgeführt werden. Eine Instanz bezeichnet einen gerade
ausgeführten Prozess. Ein ausführbarer Prozess erscheint nach außen als normaler Dienst und
kann daher leicht in andere Prozesse integriert werden.
BPEL stellt für die Schnittmenge beider Prozessarten einheitliche Sprachmittel zur Verfügung
►[ibm-2, S. 13f]. Zusätzlich enthält BPEL spezifische Spracherweiterungen um die Anfor-
derungen beider Prozessarten zu unterstützen ►[ibm-2, S. 10].
Orchestrierung•. BPEL steuert, wie erwähnt, den Kontrollfluss und die Kommunikation der
beteiligten Dienste. Die zentrale Steuerung wird als Orchestrierung• bezeichnet. Choreographie•,
ein verwandtes Konzept, wird von BPEL nicht unterstützt. Hierfür wurde WS-CDL begonnen. Ein
Vergleich zwischen BPEL und WS-CDL• ist in ►[oracle-7, S. 17-18] zu finden.
1.3.2.2 Sprachelemente
BPEL verfügt über viele Elemente gewöhnlicher Programmiersprachen. Die folgenden Absätze ge-
ben einen Überblick über die wichtigsten Elemente von BPEL 1.1.
11
Es wird an der Erweiterung BPEL4People gearbeitet, die im Prozess die Interaktion mit Menschen ermög-
licht. ►http://www.ibm.com/developerworks/webservices/library/specification/ws-bpel4people/
141 Grundlagen
Grundelemente. Die wichtigsten Bausteine in BPEL sind Variablen, Zuweisungen sowie einfa-
che und strukturierte Aktivitäten.
Variablen halten den Status einer Prozess-Instanz. Sie liegen im globalen oder einem lokalen Gültig-
keitsbereich. Zuweisungen erlauben, die Werte von Variablen zu belegen.
Mit einfachen Aktivitäten können zum Beispiel Dienstoperationen aufgerufen werden. Das Warten
auf den Empfang von Konsumenten-Anfragen zählt auch zu den einfachen Aktivitäten. Zu den
strukturierten Aktivitäten gehören beispielsweise Bedingungen, Schleifen und die serielle und par-
allele Ablaufsteuerung von Aktivitäten.
Details zu den hier angesprochenen Elementen sind in ►[ibm-2, S. 38-84] zu finden.
Korrelation. BPEL-Prozesse sind zustandsbehaftet. Daher richtet sich der Aufruf einer Dienst-
operation an eine konkrete Instanz. Die Daten, die bestimmen, an welche Instanz eine Anfrage ge-
leitet werden soll, werden als Correlation Sets bezeichnet. Details sind in ►[ibm-2, S. 45-53] ver-
fügbar.
Fehlerbehandlung. In Diensten können Fehler auftreten, die an den Dienstkonsumenten wei-
tergeleitet werden. BPEL integriert Sprachelemente zur Fehlerbehandlung. Wenn ein Aufruf statt
dem erwarteten Ergebnis einen Fehler zurückgibt, kann der BPEL-Kontrollfluss automatisch zu
vorher festgelegten Aktionen der Fehlerbehandlung verzweigen.
Compensation. Der BPEL-Standard integriert eine Vorgehensweise namens compensation.
Wenn ein Schritt im BPEL-Prozess fehlschlägt, können hiermit ausgleichende Aktionen eingeleitet
werden. Dies heißt, dass entweder alternative Wege eingeschlagen oder alle Änderungen in vorhe-
rigen Schritten rückgängig gemacht werden. Im Gegensatz zu einer Transaktionen muss dies je-
doch explizit erfolgen. Dazu können pro Gültigkeitsbereich ausgleichende Aktionen definiert wer-
den, die den oben angesprochenen Ausgleich durchführen.
1.3.3 Webservice-Erweiterungen
Die Grundelemente bei der Entwicklung von Webservices sind SOAP und WSDL. Die hier gebote-
ne Funktionalität ist zwar vielfältig, für anspruchsvolle Anwendungen jedoch meist nicht ausrei-
chend. Beispielsweise wurden Sicherheitsmerkmale ganz außer Acht gelassen.
Als Abhilfe wurden verschiedene Erweiterungen geschaffen, die in ihrer Gesamtheit gewöhnlich als
WS-* bezeichnet werden. Eine einzelne Erweiterung hat das Prefix WS-, beispielsweise WS-Secu-
rity•. Alle Erweiterungen basieren auf SOAP. Sie klinken sich jeweils in den Kopf einer SOAP-Nach-
richt ein.
Die wichtigsten und für die vorliegende Arbeit relevanten Erweiterungen werden im Folgenden
erläutert.
151 Grundlagen
1.3.3.1 WS-Policy
WS-Policy ist ein von einem Konsortium erstellter Vorschlag, der beim W3C eingereicht wurde
►[w3c-9]. Es wird ein Modell definiert, um ein Regelwerk für SOAP-Dienste zu schaffen. Diese
Regeln sind Bedingungen, die in der Kommunikation zwischen Service-Nutzer und -Anbieter erfüllt
sein müssen.
Zum Beispiel kann festgelegt werden, dass eine bestimmte Verschlüsselung bei der Übertragung
verwendet werden muss. Die Spezifikation der Erweiterung enthält dazu ein einfaches Beispiel
►[w3c-9, Abschnitt 1.2]:
WS-Policy gibt nur die Syntax eines Regelwerkes vor. Die eigentlichen Regeln (hier beispielsweise
sp:Basic256Rsa15) stammen aus ergänzenden Spezifikationen.
1.3.3.3 WS-ReliableMessaging
Beim Nachrichtenaustausch mit einem Webservice können verschiedene Probleme auftreten.
Zum Beispiel können durch Fehler Nachrichten verloren, mehrfach zugestellt oder im Inhalt ver-
ändert werden. Eine zuverlässige Kommunikation ist jedoch für viele Unternehmensanwendungen
eine wichtige Voraussetzung.
Dies ist das Anwendungsfeld von WS-ReliableMessaging•. Diese Erweiterung wurde unter ande-
rem von IBM und Microsoft geschaffen und ist ein Protokoll, um die zuverlässige Kommunikation
zwischen Diensten sicherzustellen. Die Lösung ist unabhängig von Protokollen, es besteht jedoch
bereits eine Bindung an SOAP.
1.3.3.4 WS-Security
„This specification proposes a standard set of SOAP [...] extensions that can
be used when building secure Web services to implement message content
integrity and confidentiality.“ ►[oasis-3, S. 7]
WS-Security, auch WSS genannt, ist für die Sicherheit von SOAP-Nachrichten zuständig. Wichtige
Punkte sind hier die Integrität und Vertraulichkeit der übertragenen Daten. Die Spezifikation, mitt-
lerweile in Version 1.1 verfügbar, wird von OASIS• herausgegeben.
161 Grundlagen
Signaturen gewährleisten die Integrität der Nachrichten. Im Kopf der Nachricht werden die Signa-
turen festgehalten, mit denen einzelne Bereiche der Nachricht beim Empfänger auf Unversehrt-
heit geprüft werden können.
Durch Verschlüsselung wird die sichere Übertragung von vertraulichen Daten ermöglicht. WS-Se-
curity unterstützt die symmetrische Verschlüsselung von Elementen, die in Header oder Body der
SOAP-Nachricht liegen können. Dazu wird ein Schlüssel verwendet, der Sender und Empfänger
bekannt ist. Möglich ist jedoch auch, den Schlüssel der Nachricht in verschlüsselter Form mitzuge-
ben.
Signaturen und Verschlüsselung können parallel verwendet werden. Dabei können sich die Signa-
turen sowohl auf unverschlüsselte als auch verschlüsselte Daten beziehen.
1.3.3.5 WS-I
Die vielen Erweiterungen, die bisher entstanden sind, erschweren die einfache Kommunikation
zwischen verschiedenen Diensten. WS-I• ist eine Organisation mit dem Ziel, genau dieses Problem
zu lösen. Sie bemüht sich um die Kompatibilität von Diensten über die Grenzen von Plattformen,
Anwendungen und Programmiersprachen hinweg.
WS-I Basic Profile definiert verschiedene Regeln, die eingehalten werden müssen, damit eine An-
wendung als kompatibel eingestuft werden kann ►[wsi-1]. Enthalten sind neben genauen Vorga-
ben über die Syntax von SOAP auch Klarstellungen zu Passagen der verschiedenen Spezifikationen.
WS-I Basic Security Profile ist ein ähnliches Dokument für den Bereich Sicherheit ►[wsi-2]. Behan-
delt werden beispielsweise Protokolle, XML Verschlüsselung, XML Signaturen, Kerberos und An-
hänge.
172 Konzeption und Implementierung einer SOA-Anwendung
2 Konzeption und Implementierung einer SOA-
Anwendung
Um SOA und Oracle Fusion Middleware richtig beurteilen zu können, ist Praxiserfahrung notwen-
dig. Das bedeutet, dass ein Projekt realisiert werden muss, bei dem diese erworben werden kann.
In diesem Kapitel wird die Entwicklung einer solchen Anwendung beschrieben.
Ausgehend von der Aufgabenstellung werden Analyse, Entwurf und Implementierung des Systems
detailliert erläutert. Zum Schluss wird versucht, das Resultat der Bemühungen kritisch zu beurtei-
len.
2.1 Aufgabenstellung
Zusammenfassung. Anhand einer fiktiven Problemstellung soll eine SOA-Anwendung erstellt
werden. Dabei wird versucht, sich an einer praxisnahen Aufgabenstellung zu orientieren. Diese
Software soll später zu Demonstrationszwecken in einer virtuellen Maschine zur Verfügung ge-
stellt werden.
Ausgangssituation. Ein Unternehmer möchte in ganz Deutschland PC-Hardware verkaufen.
Dafür hat er fünf unabhängige lokale Geschäfte übernommen und fasst diese im neuen Unterneh-
men „MyPC GmbH“ zusammen.
Bundesweit existieren nun fünf Filialen seines Unternehmens, die ihre Ware direkt an Endkunden
verkaufen. Jede dieser Filialen verfügt über ein eigenes Warenlager. Ein zentrales Lager existiert je-
doch nicht. Die Standorte der Filialen sind:
Hamburg
Berlin
Köln
Kassel
Stuttgart
Somit ist in jeweils einer Himmelsrichtung eine Niederlassung, zentral liegt Kassel.
Nun hat die Geschäftsleitung entschieden, dass in Deutschland auch ein Onlineshop angeboten
werden soll. Kunden sollen zwischen Direktabholung in einer Filiale und Paketversand wählen kön-
nen.
Bestellt ein Kunde über den Onlineshop zum Paketversand, so soll die Filiale, die die meisten Teile
der Bestellung vorrätig hält, die Bestellung ausführen. Noch fehlende Teile sollen, falls möglich, aus
den Beständen anderer Filialen beschafft werden. Falls dies nicht möglich ist, soll bei verschiede-
nen Großhändlern jeweils ein Angebot eingeholt werden. Das preiswerteste soll automatisch be-
stellt werden.
182 Konzeption und Implementierung einer SOA-Anwendung
In keiner der Filialen existiert ein Softwaresystem, das nach dem Zusammenschluss weiter ver-
wendet werden könnte.
Aufgabenstellung. Es soll eine SOA-Anwendung erstellt werden. Diese soll die ehemals
selbstständigen Filialen integrieren und eine einfache Zusammenarbeit ermöglichen. Sowohl La-
den- als auch Onlinegeschäfte sollen mit diesem neuen System arbeiten. Besonders die folgenden
Bereiche sollen in einer ersten Version implementiert werden:
Kundenverwaltung. Die Software soll alle Onlineshop-Kunden verwalten. Diese werden
anhand einer eindeutigen Kundennummer identifiziert. Ladenkunden haben keine Kunden-
nummer.
Produktverwaltung. Die Angebotspalette, die im Onlineshop und in den Filialen angebo-
ten wird, soll zentral verwaltet werden. Dabei sollen die Produkte in hierarchische struk-
turierten Kategorien eingeordnet sein.
Lagerverwaltung. Im Rahmen der Umstrukturierung soll in das System eine zentrale La-
gerverwaltung integriert werden. Die Bestände alle Filialen sollen hier erfasst und verwal-
tet werden. Die einzelnen Filialen können auf eine Webanwendung zugreifen, mit der sie
ihre eigenen Lagerbestände verwalten können.
Bestellungsabwicklung. Des gesamte Internet-Bestellvorganges eines Kunden soll von
der Software abgewickelt werden. Dazu zählen:
Warenkorbverwaltung
Bezahlvorgang
Wahl der Versandart
Versand einer E-Mail-Bestätigung an den Kunden
Die Benachrichtigung der Filiale, die die meisten der bestellten Teile vorrätig hat,
über den neuen Auftrag.
Die automatische Bestellung bei einem Großhändler, falls Ware nicht im Lager vor-
handen ist.
Zudem soll es leicht sein, die Software an geänderte Geschäftsprozesse anzupassen. Wenn bei-
spielsweise eine sechste Filiale eröffnet wird, soll sie ohne Schwierigkeiten integriert werden kön-
nen. Auch Änderungen an Vorgängen wie der Bestellabwicklungen oder der Zahlungsabwicklung
sollen leicht möglich sein.
Das System soll durchgängig SOA-Prinzipien verwenden. Auch der Onlineshop soll auf Diensten
aufbauen. Ein Ziel ist, dass im ganzen Unternehmen nur ein Ort vorhanden ist, an der eine be-
19Sie können auch lesen
