Aspekte des Entwurfs und der Implementierung service-orientierter Architekturen am Beispiel von Portal-Systemen
©2006
Diplomarbeit
118 Seiten
Zusammenfassung
Inhaltsangabe:Einleitung:
Ein zurzeit aktuelles Thema im Bereich der Informationstechnologie sind die so genannten service-orientierten Architekturen (SOA). Viele Firmen beschäftigen sich aktuell mit Serviceorientierung und prüfen, ob die Einführung einer solchen Architektur einen Mehrwert für das Unternehmen bringen kann.
Diese Arbeit analysiert das Konzept service-orientierter Architekturen. Der Schwerpunkt liegt dabei auf der Verbindung und den daraus resultierenden Vorteilen dieser Architektur im Zusammenhang mit Unternehmensportalen. Zusätzlich zu der Analyse von service-orientierten Architekturen und Unternehmensportalen wird im Anschluss an diese theoretischen Betrachtungen die Umsetzung eines Portal-Protypen in einem Unternehmen beschrieben. Damit ergeben sich für die Arbeit drei elementare Themenbereiche: service-orientierte Architekturen, Unternehmensportale und konkrete Realisierung eines Portal-Prototypen für die Collogia AG.
Das grundlegende Konzept service-orientierter Architekturen liegt darin, über einheitliche Schnittstellen ausgewählte Funktionen oder Daten bereitzustellen. Eine Komponente der Architektur, die dieses leisten kann, wird dabei als Service bezeichnet. Auf diese Weise können komplexe, zusammenhängende heterogene Anwendungen erstellt und verknüpft werden. Das verwendete Prinzip service-orientierter Architekturen ist dabei nicht neu.
Verteilte Anwendungen auf heterogener Basis können beispielsweise ebenfalls durch CORBA realisiert werden. Bei CORBA spricht man in diesem Zusammenhang von definierten Diensten und Protokollen. Daher ist lediglich der Begriff des Services relativ neu, die grundlegende (technische) Idee allerdings nicht. Somit können service-orientierte Architekturen durchaus als eine Weiterentwicklung des CORBA-Prinzips gesehen werden. Das erste Auftreten des Begriffes service-orientierter Strukturen ist dabei auf Hewlett-Packard zurückzuführen. HP wollte 1999 mit e-Speak eine Plattform für das Web schaffen, auf der Daten und Funktionalitäten als Service zur Verfügung gestellt werden können. Das Produkt fand allerdings keine Akzeptanz am Markt. Das e-Speak Projekt scheiterte, aber der Begriff service-orientierter Architekturen war damit geboren.
Heute werden service-orientierte Architekturen, kurz SOA genannt, von einigen Experten als Hype bezeichnet. Sie rechnen nicht damit, dass sich solche Architekturen durchsetzen werden und somit bald vom Softwaremarkt verschwinden. Entgegengesetzte Ansichten […]
Ein zurzeit aktuelles Thema im Bereich der Informationstechnologie sind die so genannten service-orientierten Architekturen (SOA). Viele Firmen beschäftigen sich aktuell mit Serviceorientierung und prüfen, ob die Einführung einer solchen Architektur einen Mehrwert für das Unternehmen bringen kann.
Diese Arbeit analysiert das Konzept service-orientierter Architekturen. Der Schwerpunkt liegt dabei auf der Verbindung und den daraus resultierenden Vorteilen dieser Architektur im Zusammenhang mit Unternehmensportalen. Zusätzlich zu der Analyse von service-orientierten Architekturen und Unternehmensportalen wird im Anschluss an diese theoretischen Betrachtungen die Umsetzung eines Portal-Protypen in einem Unternehmen beschrieben. Damit ergeben sich für die Arbeit drei elementare Themenbereiche: service-orientierte Architekturen, Unternehmensportale und konkrete Realisierung eines Portal-Prototypen für die Collogia AG.
Das grundlegende Konzept service-orientierter Architekturen liegt darin, über einheitliche Schnittstellen ausgewählte Funktionen oder Daten bereitzustellen. Eine Komponente der Architektur, die dieses leisten kann, wird dabei als Service bezeichnet. Auf diese Weise können komplexe, zusammenhängende heterogene Anwendungen erstellt und verknüpft werden. Das verwendete Prinzip service-orientierter Architekturen ist dabei nicht neu.
Verteilte Anwendungen auf heterogener Basis können beispielsweise ebenfalls durch CORBA realisiert werden. Bei CORBA spricht man in diesem Zusammenhang von definierten Diensten und Protokollen. Daher ist lediglich der Begriff des Services relativ neu, die grundlegende (technische) Idee allerdings nicht. Somit können service-orientierte Architekturen durchaus als eine Weiterentwicklung des CORBA-Prinzips gesehen werden. Das erste Auftreten des Begriffes service-orientierter Strukturen ist dabei auf Hewlett-Packard zurückzuführen. HP wollte 1999 mit e-Speak eine Plattform für das Web schaffen, auf der Daten und Funktionalitäten als Service zur Verfügung gestellt werden können. Das Produkt fand allerdings keine Akzeptanz am Markt. Das e-Speak Projekt scheiterte, aber der Begriff service-orientierter Architekturen war damit geboren.
Heute werden service-orientierte Architekturen, kurz SOA genannt, von einigen Experten als Hype bezeichnet. Sie rechnen nicht damit, dass sich solche Architekturen durchsetzen werden und somit bald vom Softwaremarkt verschwinden. Entgegengesetzte Ansichten […]
Leseprobe
Inhaltsverzeichnis
Jens Kohne
Aspekte des Entwurfs und der Implementierung service-orientierter Architekturen am
Beispiel von Portal-Systemen
ISBN: 978-3-8366-0078-1
Druck Diplomica® GmbH, Hamburg, 2007
Zugl. Universität Siegen, Siegen, Deutschland, Diplomarbeit, 2006
Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,
insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von
Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der
Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,
bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung
dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen
der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik
Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich
vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des
Urheberrechtes.
Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in
diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,
dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei
zu betrachten wären und daher von jedermann benutzt werden dürften.
Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können
Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die
Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine
Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.
© Diplomica GmbH
http://www.diplom.de, Hamburg 2007
Printed in Germany
Vorwort Seite
II
Vorwort
Für die Realisierung meiner Diplomarbeit habe ich mich relativ frühzeitig dazu entschieden,
diese Arbeit nicht ausschließlich auf rein theoretischer Basis zu schreiben. Ich wollte diese
Arbeit nutzen, um einen weiteren Schritt in die Praxis zu gehen. Daher habe ich nach einem
Unternehmen gesucht, dass mir die Möglichkeit bietet (nach einem einführenden Praktikum)
eine Diplomarbeit direkt im Unternehmen zu schreiben. Bei dieser Suche habe ich mich für
die Collogia Unternehmensberatung AG in Köln entschieden. Dort habe ich zunächst ein
dreimonatiges Praktikum im SAP Basis Bereich absolviert, um anschließend auch dort meine
Diplomarbeit schreiben zu können.
Mein zu bearbeitendes Diplomthema liegt im Bereich der service-orientierte Architekturen
(SOA). Der Schwerpunkt der Arbeit soll dabei in der Analyse der Kombination von service-
orientierten Architekturen und Unternehmensportalen liegen. Durch die Arbeit in der SAP
Basis Abteilung der Collogia AG standen mir neben den Ressourcen für den Aufbau einer
Systemlandschaft auch eine aktuelle Portalsoftware zur Verfügung (SAP Enterprise Portal
6.0). Diese Kombination bot für mich eine sehr gute Chance, weil ich so zum einen die
Möglichkeit hatte, mich auf wissenschaftlicher Basis intensiv mit service-orientierten
Architekturen zu beschäftigen, auf der anderen Seite sehr wertvolle praktische Erfahrungen
im SAP-Umfeld sammeln konnte. Zur Veranschaulichung der Bedeutung eines
Unternehmensportals im SOA-Umfeld habe ich für die Collogia AG einen Portal-Prototypen
auf Basis des SAP Enterprise Portals entwickelt.
Danksagung
Seite
III
Danksagung
An dieser Stelle möchte ich mich zunächst bei der Collogia AG bedanken, die mir die
benötigten Ressourcen für meine Diplomarbeit zur Verfügung gestellt hat. Neben der
eigentlichen Arbeit an meinem Diplomthema habe ich auch durch das Umfeld in der
Unternehmensberatung und einigen kleinen Projekten sehr viel dazulernen können. Ich habe
in dieser relativ kurzen Zeit wichtige Erfahrungen gemacht, die mir ohne den Schritt in die
Praxis vergönnt geblieben wären. Für diese Möglichkeit bin ich sehr dankbar. Besonderer
Dank gilt dabei meinen beiden Betreuern Bernd Stevens und Markus Stockhausen. Von
beiden Mitarbeitern der Collogia AG habe ich nicht nur fachliche Unterstützung beim Aufbau
des Unternehmensportals erhalten, sondern auch wertvolle Unterstützung und zahlreiche
Hinweise für die grundlegenden theoretischen Kapitel dieser Diplomarbeit bekommen.
Darüber hinaus möchte ich mich ebenfalls bei Herrn Juniorprofessor Dr. Thomas Barth für
die Betreuung dieser Diplomarbeit und die damit verbundene gute Zusammenarbeit
bedanken.
Inhaltsverzeichnis
Seite
IV
Inhaltsverzeichnis
1
Einleitung ... 1
2
Service-orientierte Architekturen ... 3
2.1
Einordnung des Architekturbegriffes ... 3
2.2
Definition einer Software-Architektur... 4
2.3
Ziele einer Software-Architektur... 5
2.4
Grundlagen service-orientierter Architekturen ... 6
2.4.1
Einführung ... 6
2.4.2
Begriffsabgrenzung ... 9
2.4.3
Der Anspruch an SOA Definition und Ziele ... 12
2.5
Die Implementierung service-orientierter Architekturen ... 13
2.5.1
SOAP... ...................................................................................... 15
2.5.2
Web Service Description Language (WSDL) ... 16
2.5.3
Universal Description, Discovery and Integration (UDDI)... 18
2.6
Weiterführende Aspekte service-orientierter Architekturen... 20
2.6.1
Top-Down Ansatz ... 20
2.6.2
Granularität... 21
2.6.3
Umsetzung von Geschäftsprozessen in SOA ... 23
2.6.3.1
Business Process Execution Language (BPEL)... 26
Inhaltsverzeichnis
Seite
V
3
Unternehmensportale ... 29
3.1
Historische Entwicklung und Begriffsabgrenzung ... 29
3.2
Klassifizierung von Portalen... 31
3.2.1
Offene und geschlossene Portale ... 31
3.2.2
Horizontale und Vertikale Portale ... 32
3.3
Analyse von Unternehmensportalen ... 35
3.3.1
Definition eines Unternehmensportals... 35
3.3.2
Motivation für die Einführung eines Unternehmensportals... 36
3.3.2.1
Kooperation ... 37
3.3.2.2
Unterstützung der Unternehmensstrategie... 39
3.3.2.3
Motivation der Mitarbeiter ... 41
3.3.3
Kernelemente eines Unternehmensportals ... 42
3.3.3.1
Personalisierung und Benutzerverwaltung ... 42
3.3.3.2
Single Sign On... 44
3.3.3.3
Kommunikation und Collaboration... 45
3.3.3.4
Workflow Management ... 46
3.3.3.5
Wissensmanagement ... 47
3.3.4
Integration... 48
3.3.4.1
Datenintegration ... 48
3.3.4.2
Systemintegration... 49
3.3.4.3
Prozessintegration ... 50
3.4
Die Bedeutung des Portals im Rahmen SOA ... 51
3.4.1
Standards für Portalimplementierungen ... 52
3.4.2
Portallösungen im SOA-Umfeld... 53
Inhaltsverzeichnis
Seite
VI
4
Entwurf und Implementierung eines Portal-Prototypen ... 54
4.1
Einführung und Überblick in die SOA-Strategie der SAP AG ... 54
4.1.1
SAP Architektur Überblick ... 55
4.1.2
Architektur des SAP Enterprise Portals... 57
4.2
Überblick über die Systemlandschaft... 61
4.2.1
Einführung ... 61
4.2.2
Betrachtung der einzelnen Komponenten ... 61
4.2.2.1
Infrastruktur der Systemlandschaft ... 62
4.2.2.2
Portal-Server... 63
4.2.2.3
Supplier Relationship Management System... 64
4.2.3
Fachliche Struktur des Unternehmensportals ... 64
4.3
Abgrenzung Produktivportal vs. Prototypenimplementierung ... 70
4.4
Vorteile für das Unternehmen durch die Portaleinführung ... 72
4.5
Anwendungsintegration im Unternehmensportal ... 76
4.5.1
Integration eines SAP Backend-Systems... 77
4.5.1.1
Aufgabenbeschreibung... 77
4.5.1.2
Vorgehensweise ... 78
4.5.1.3
Aktivierung von Single Sign On (SSO) ... 83
4.5.1.3.1
SAP Logon Tickets ... 84
4.5.2
Web Service Integration am Beispiel von google.de ... 86
5
Fazit und Ausblick... 89
6
Literaturverzeichnis ... 92
7
Anhang ... 100
A) SOAP und WSDL Beispiele... 100
B) Java Beispiele... 102
C) Screenshots aus dem Unternehmensportal der Collogia AG ... 105
Abbildungsverzeichnis
Seite
VII
Abbildungsverzeichnis
Abbildung 1: Funktionsweise service-orientierter Architekturen [Dostal u.a. 2005]... 7
Abbildung 2: Schematische Darstellung des EAI-Konzepts [Kaib 2002] ... 9
Abbildung 3: Aufbau einer SOAP-Nachricht [Dostal u.a. 2005]... 16
Abbildung 4: Dokumentenstruktur eines WSDL-Dokuments [Hauser, Löwer 2004]... 17
Abbildung 5: Entwicklung der Geschäftsprozessmodellierungssprachen
[Dostal u.a. 2005]... 25
Abbildung 6: Basisstruktur eines WSBPEL-Dokuments [Dostal u.a. 2005]... 27
Abbildung 7: Beispiel eines Portals ... 30
Abbildung 8: Kategorisierungsmatrix für Portale [Grossmann Koschek 2005] ... 33
Abbildung 9: Motive für die Einführung eines Unternehmensportals... 37
Abbildung 10: Prinzip des Single Sign On ... 44
Abbildung 11: EAI Prinzip zur Systemintegration [Grossmann Koschek 2005]... 50
Abbildung 12: SAP NetWeaver Komponentenübersicht [Goebel, Ritthaler 2004]... 55
Abbildung 13: Komponenten des SAP Enterprise Portals [Goebel, Ritthaler 2004]... 57
Abbildung 14: Überblick Unification Server [Goebel, Ritthaler 2004] ... 59
Abbildung 15: Systemlandschaft Collogia AG ... 62
Abbildung 16: Benutzer und Gruppen der Collogia AG ... 63
Abbildung 17: Rollenhierarchie im Portal der Collogia AG ... 65
Abbildung 18: Portal Content Directory der Collogia AG ... 66
Abbildung 19: Worksetansicht im Unternehmensportal der Collogia AG ... 67
Abbildung 20: Portal Content des GB SAP Beratung ... 68
Abbildung 21: Rollenzuordnung zur Gruppe "SAP Beratung" ... 69
Abbildung 22: Portalinhalt für einen Mitarbeiter des GB IT-Services... 70
Abbildung 23: Portalinhalt für ein Mitglied der Gruppe "Vorstand" ... 70
Abbildung 24: Portalbereich eines Mitarbeiters der Collogia AG... 74
Abbildungsverzeichnis
Seite
VIII
Abbildung 25: Integration des Mailservers im Unternehmensportal ... 76
Abbildung 26: Transaktion "db13" im SRM-System auf colvm11 ... 77
Abbildung 27: Konfiguration eines Backend-Systems im Portal... 79
Abbildung 28: Anlegen eines neuen iViews... 80
Abbildung 29: Workset GB SAP Beratung... 81
Abbildung 30: Portalausschnitt eines Mitarbeiters des GB SAP Beratung ... 82
Abbildung 31: Integration eines SAP-Systems im Unternehmensportal... 85
Abbildung 32: Eingabemaske für den Google Web Service... 87
Abbildung 33: Ergebnisanzeige des Google Web Services ... 88
Abkürzungsverzeichnis
Seite
IX
Abkürzungsverzeichnis
API
Application
Programming
Interface
B2B
Business to Business
B2C
Business to Customer
B2E
Business to Employee
BPEL
Business Process Execution Language
BPML
Business Process Modeling Language
CMS
Content Management System
CORBA
Common Object Request Broker Architecture
CRM
Customer Relationship Management
DCOM Distributed
Component
Object
Model
EAI
Enterprise
Application
Integration
ERP
Enterprise Resource Planning
ESA
Enterprise Service Architecture
HP
Hewlett-Packard
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
JSR
Java Specification Request
JSP
Java Server Page
LDAP
Lightweight Directory Access Protocol
MDA
Model Driven Architecture
MVC
Model View Controller
OASIS
Organization for the Advancement of Structured Information
Standards
REST Representational
State
Transfer
RMI
Remote Method Invocation
Abkürzungsverzeichnis
Seite
X
ROI
Return on Investment
SOA
Service-orientierte Architektur
SLA
Service Level Agreement
SRM
Supplier Relationship Management
SSO
Single Sign On
UDDI
Universal Description, Discovery and Integration
URI
Unified Ressource Identifier
W3C
World Wide Web Consortium
WAD
Web Application Designer
WS-BPEL
Web Service Business Process Execution Language
WSCDL
Web Services Choreography Description Language
WSCI
Web Service Choreography Interface
WSDL
Web Service Description Language
WSFL
Web Services Flow Language
XML
Extensible Markup Language
XPDL
XML Process Definition Language
Einleitung Seite
1
1 Einleitung
Ein zurzeit aktuelles Thema im Bereich der Informationstechnologie sind die so
genannten service-orientierten Architekturen (SOA). Viele Firmen beschäftigen sich
aktuell mit Service-orientierung und prüfen, ob die Einführung einer solchen Architektur
einen Mehrwert für das Unternehmen bringen kann. Diese Arbeit analysiert das Konzept
service-orientierter Architekturen. Der Schwerpunkt liegt dabei auf der Verbindung und
den daraus resultierenden Vorteilen dieser Architektur im Zusammenhang mit
Unternehmensportalen. Zusätzlich zu der Analyse von service-orientierten Architekturen
und Unternehmensportalen wird im Anschluss an diese theoretischen Betrachtungen die
Umsetzung eines Portal-Protypen in einem Unternehmen beschrieben. Damit ergeben
sich für die Arbeit drei elementare Themenbereiche:
1.) service-orientierte Architekturen
2.) Unternehmensportale
3.) konkrete Realisierung eines Portal-Prototypen für die Collogia AG
Das grundlegende Konzept service-orientierter Architekturen liegt darin, über einheitliche
Schnittstellen ausgewählte Funktionen oder Daten bereitzustellen. Eine Komponente der
Architektur, die dieses leisten kann, wird dabei als Service bezeichnet. Auf diese Weise
können komplexe, zusammenhängende heterogene Anwendungen erstellt und verknüpft
werden. Das verwendete Prinzip service-orientierter Architekturen ist dabei nicht neu.
Verteilte Anwendungen auf heterogener Basis können beispielsweise ebenfalls durch
CORBA realisiert werden (vgl. [Corba 2006]). Bei CORBA spricht man in diesem
Zusammenhang von definierten Diensten und Protokollen. Daher ist lediglich der Begriff
des Services relativ neu, die grundlegende (technische) Idee allerdings nicht. Somit
können service-orientierte Architekturen durchaus als eine Weiterentwicklung des
CORBA-Prinzips gesehen werden (vgl. [Dostal u.a. 2005]). Das erste Auftreten des
Begriffes service-orientierter Strukturen ist dabei auf Hewlett-Packard zurückzuführen
[Hauser und Löwer 2004]. HP wollte 1999 mit e-Speak eine Plattform für das Web
schaffen, auf der Daten und Funktionalitäten als Service zur Verfügung gestellt werden
können. Das Produkt fand allerdings keine Akzeptanz am Markt. Das e-Speak Projekt
scheiterte, aber der Begriff service-orientierter Architekturen war damit geboren [Hauser
und Löwer 2004]. Heute werden service-orientierte Architekturen, kurz SOA genannt, von
einigen Experten als ,,Hype" bezeichnet. Sie rechnen nicht damit, dass sich solche
Architekturen durchsetzen werden und somit bald vom Softwaremarkt verschwinden.
Entgegengesetzte Ansichten sehen in SOA eine Revolution, um IT-Architekturen neu und
Einleitung Seite
2
flexibel zu gestalten. Diese Diplomarbeit macht es sich zur Aufgabe, die Aspekte service-
orientierter Architekturen zu analysieren. Im Vordergrund stehen, nach einer generellen
Betrachtung service-orientierter Architekturen, die Verbindung und der daraus
resultierende Mehrwert dieser Architekturen mit prozessorientierten Unternehmens-
portalen. Kapitel 2 beinhaltet eine umfassende Analyse service-orientierter Architekturen.
Dabei wird der Begriff zunächst in den Kontext allgemeiner IT-Architekturen eingeordnet.
Danach werden service-orientierte Architekturen definiert und ihre wesentlichen Merkmale
und Ziele vorgestellt. Es wird aufgezeigt, dass die verwendeten Prinzipien nicht völlig neu
sind (vgl. vorangegangenes CORBA-Beispiel), allerdings einen entscheidenden Mehrwert
im Gegensatz zu bisherigen Architekturen leisten können. Nach der Analyse des
generellen Konzepts werden Möglichkeiten zur Implementierung serviceorientierter
Architekturen vorgestellt. Zum Abschluss dieses Kapitels werden weiterführende Aspekte
behandelt. Dazu zählen unter anderem die strategische Einführung service-orientierter
Architekturen und die Verbindung von service-orientierten Architekturen mit
Geschäftsprozessmodellierungssprachen. Kapitel 3 analysiert anschließend die Thematik
der Unternehmensportale. In diesem Kapitel wird ebenfalls zunächst der Portal-Begriff
eingeordnet, um anschließend aufzuzeigen, wie man Portale kategorisieren kann. Der
Fokus liegt dabei auf prozessorientierten Unternehmensportalen. Diese werden definiert,
anschließend werden die Vorteile und Kernelemente eines prozessorientierten
Unternehmensportals vorgestellt. Am Ende des dritten Kapitels werden dann beide
Themenkomplexe miteinander verknüpft. Diese Verknüpfung stellt den eigentlichen
Mehrwert der vorliegenden Diplomarbeit dar. Nach einer separaten Betrachtung beider
Themenkomplexe wird die Verbindung zwischen service-orientierten Architekturen und
prozessorientierten Unternehmensportalen aufgezeigt. Abschließend wird der Vorteil
analysiert, den Unternehmen aus einer solchen Verbindung für sich nutzen können. In
dem nachfolgenden Kapitel 4 werden dann, aufbauend auf dem vermittelten theoretischen
Wissen der Kapitel 2 und 3, ausgewählte Funktionen eines Unternehmensportals in Form
eines Portal-Prototypen für die Collogia AG realisiert. Dieses Kapitel beschreibt den
praktischen Teil der Diplomarbeit und dient zur Veranschaulichung der in Kapitel 3
beschriebenen Aspekte eines Unternehmensportals. Das abschließende Kapitel 5 fasst
die Arbeit aus den vorangegangenen Kapiteln noch einmal zusammen. Neben einem
Fazit der vorliegenden Arbeit wird ebenfalls ein Blick auf die Zukunft service-orientierter
Architekturen geworfen.
Service-orientierte Architekturen
Seite
3
2 Service-orientierte
Architekturen
2.1 Einordnung des Architekturbegriffes
Um das Konzept service-orientierter Architekturen zu verstehen, muss man sich mit den
sprachlichen Bausteinen beschäftigen: ,,Service-orientierung" und ,,Architektur". Um an
das Thema heranzuführen, wird in diesem Kapitel zunächst allgemein auf den Begriff der
Architekturen in IT-Projekten eingegangen. Danach wird der konkrete Ansatz der service-
orientierten Architekturen analysiert.
Der Architekturgedanke im Zusammenhang mit Software ist circa 30 Jahre alt ist [Shaw,
Garlan 1996]. Daher gibt es auch eine Vielzahl unterschiedlicher Definitionen zu diesem
Gebiet. Es existiert nicht die einheitliche Definition für Software-Architektur (vgl. [Software
Engineering Institute 2006]. Es geht vielmehr darum, die Vorteile einer Software-
Architektur zu erkennen. Diese können allerdings nicht allgemein vordefiniert werden,
sondern sind vom jeweiligen Softwareprojekt abhängig. Ein Beispiel zeigt der Vergleich
zwischen der Suchmaschine Google (www.google.de) und der Kommunikation zwischen
den Systemen einer Bank. Google muss in der Lage sein, viele Anfragen pro Sekunde
performant beantworten zu können. Dabei können die Daten unverschlüsselt übertragen
werden, da die Ergebnisse dieser öffentlichen Suchmaschine nicht vertraulich sind. Bei
einem Banksystem hingegen ist es sehr wichtig, dass die Daten vertraulich behandelt
werden und es keinem unbefugten Dritten gelingt, diese Übertragung abzuhören. Somit
werden in beiden Szenarien unterschiedliche Anforderungen an die jeweilige Software-
Architektur gestellt. Auf der einen Seite ist der Anspruch an Sicherheit bei der
Übertragung hoch, auf der anderen Seite ist die Performanz des Systems das
entscheidende Kriterium. Das Ziel dieses einleitenden Kapitels ist es daher nicht,
Software-Architektur eindeutig zu definieren und die möglichen Vorteile diverser
Architekturen zu beleuchten. Es dient lediglich dazu, ein Grundverständnis für
Architekturen und deren Nutzen zu legen. Die nachfolgende Betrachtung ist mit Hinblick
auf service-orientierte Architekturen zu sehen. Zunächst wird in diesem Rahmen eine
Definition gegeben, anschließend konkrete Vorteile genannt. Sind diese Grundlagen
definiert, werden die service-orientierten Architekturen im Kapitel 2.4 im Detail betrachtet.
Weiterführende Literatur zum allgemeinen Verständnis von Softwarearchitekturen findet
sich beispielsweise in [Posch u.a. 2004] oder [Vogel u.a. 2005].
Service-orientierte Architekturen
Seite
4
2.2 Definition einer Software-Architektur
Wie im vorangegangenen Kapitel erwähnt, gibt es für die Architektur einer Software keine
allgemeingültige Definition. Es existieren in der Literatur eine Vielzahl von parallelen
Definitionen. Zur Verdeutlichung werden im Folgenden drei ausgewählte Definitionen von
Software-Architektur vorgestellt:
,,Eine Software-Architektur ist eine strukturierte oder hierarchische Anordnung der
Systemkomponenten sowie Beschreibung ihrer Komponenten." [Balzert 2002]
,,Software-Architektur beschäftigt sich mit dem Design und der Implementierung von
Software auf höchster Strukturebene. Sie ist das Resultat des sorgfältig ausgewählten
Zusammenbaus einer bestimmten Anzahl an architektonischen Elementen, um sowohl
den Hauptfunktionalitäten, als auch den Performance Anforderungen wie Verteilbarkeit
und Verfügbarkeit gerecht zu werden. Software-Architektur beschäftigt sich mit
Abstraktion, mit Dekomposition und Komposition, mit Stilen und Ästhetik." (vgl. [Kruchten
1994])
Eine Software-Architektur besteht (a) aus einer Verteilungsstrategie und (b) einer
Koordinationsstrategie. Die Verteilungsstrategie hat die Aufgabe, dass gesamte System in
eigenständige, nicht-überschneidende Teile oder Komponenten aufzuteilen. Die
Koordinationsstrategie beschreibt die exakt definierten Schnittstellen zwischen diesen
Teilen. (vgl. [Crispen, Stuckey 94])
Diese ausgewählten Definitionen sollen exemplarisch verdeutlichen, dass es keine
allgemeingültige Definition zu diesem Thema gibt. Die Definition einer Software-
Architektur ist immer ausgehend von den verfolgten Zielen und Absichten der jeweiligen
Arbeit heraus zu sehen. Daher wird an dieser Stelle im Hinblick auf service-orientierte
Architekturen eine eigene Definition von Software-Architekturen gegeben:
Eine Software-Architektur ist eine abstrakte Sicht auf das Gesamtsystem. Sie abstrahiert
von Implementierungsdetails und beschreibt die Kommunikation der
Softwarekomponenten untereinander. Sie sorgt dafür, dass das System flexibel und leicht
erweiterbar ist. Außerdem soll durch die Architektur die Wiederverwendung von
Komponenten gefördert werden.
Eine Architektur legt ausgehend von den Anforderungen, aber unabhängig von dem
konkreten System, das Fundament eines Projekts fest. Sie bestimmt damit die tragenden
Säulen, jedoch nicht die Details für das zu entwickelnde System [Buschmann u.a. 1996].
Aufbauend auf der hier gegebenen Definition wird im nachfolgenden Kapitel die
allgemeine Motivation einer Software-Architektur beschrieben. Anschließend wird die
Service-orientierte Architekturen
Seite
5
service-orientierte Architektur als eine konkrete Ausprägung einer Software-Architektur
detailliert vorgestellt.
2.3 Ziele einer Software-Architektur
Genauso vielfältig wie die in der Literatur angegebenen Definitionen zum Begriff Software-
Architektur sind auch die beschriebenen Ziele, die diese bringen soll. Der Nutzen einer
Software-Architektur kann aus verschiedenen Blickwinkeln betrachtet werden. Diese sind
dabei aber immer abhängig von den jeweiligen Rahmenbedingungen eines Projekts. Mit
der Blickrichtung auf service-orientierte Architekturen werden an dieser Stelle folgende
Ziele definiert, die eine Software-Architektur (also auch SOA) leisten muss und die im
Folgenden erläutert werden (vgl. [Posch u.a. 2004]):
·
eine effiziente Grundlage für das Entwicklungsprojekt bieten
·
den aus den Anforderungen ermittelten Workflow spezifizieren
·
flexibel auf fachliche und technische Änderungen reagieren können
·
die Software muss leicht erweiterbar und einzelne Komponenten austauschbar sein
·
ein Verständnis bei allen Beteiligten für das System schaffen
Da eine Software-Architektur das technische Grundgerüst eines jeden
Entwicklungsprojekts ist, hängt der Erfolg des Projekts stark von der Qualität der
gewählten Software-Architektur ab. Software wird inkrementell entwickelt, man spricht
vom so genannten iterativ inkrementellen Entwicklungsprozess. Ohne diesen ist es nicht
möglich, Software wirtschaftlich zu entwickeln. Die Architektur stellt den notwendigen
Integrationsrahmen dar, in dem iterativ entwickelt werden kann (vgl. [Kruchten 2000]).
Gäbe es keine grundlegende Architektur in Software-Projekten, müsste bei jeder neuen
Änderung das Gesamtkonzept angepasst werden. Solche Änderungen sind nicht
wirtschaftlich und ab einer bestimmten Projektgröße auch nicht mehr möglich. Damit dient
die gewählte Software-Architektur als effiziente Grundlage für das Entwicklungsprojekt.
Ein weiterer Punkt, in dem eine gute Software-Architektur die Effizienz eines
Entwicklungsprojekts steigert, liegt in der Zusammenarbeit mit dem Projektmanagement.
Ein Teamleiter kann anhand der Architektur das System aufteilen, Meilensteine festlegen
und Arbeitspakete verteilen. In Zusammenarbeit mit dem Software-Architekten kann er
anhand der Architektur einen für ihn ausreichenden Blick über das Gesamtsystem
erhalten. So können Projektpläne aufgestellt und das Softwareprojekt gesteuert werden.
Ohne eine effiziente Software-Architektur wäre dies ebenfalls nicht möglich [Posch u.a.
Service-orientierte Architekturen
Seite
6
2004]. Das zweite definierte Ziel ist die geforderte Flexibilität auf fachliche und technische
Änderungen. Flexibilität ist auf fachlicher Basis noch wichtiger als auf der technischen
Seite. Oft stehen zu Beginn eines Software-Projekts noch nicht alle Anforderungen fest
oder der Kunde ändert seine Anforderungen im laufenden Projekt. Eine stabile Software-
Architektur dient dazu, auf diese Änderungswünsche flexibel zu reagieren, ohne jedes Mal
das Gesamtkonzept anpassen zu müssen. Ähnliches gilt für den dritten Punkt, die
Erweiterbarkeit von Software. Zum einen betrifft dies das Hinzufügen von neuen
Funktionalitäten, zum anderen muss man in der Lage sein, die Software auch auf
mehrere Rechner zu verteilen oder einzelne Komponenten auszutauschen, was durch die
Schaffung oder Nutzung von standardisierten Schnittstellen erreicht werden kann. Eine
Software-Architektur muss gewährleisten, dass bei Bedarf Komponenten der Software
beliebig verteilt werden können, ohne konzeptionelle Änderungen vorzunehmen. Der
letzte Punkt der hier aufgelisteten Ziele betrifft das Verständnis aller Beteiligten in einem
Software-Projekt. Eine Architektur, die dem gesamten Projekt zugrunde liegt, definiert
bestimmte Schnittstellen und sorgt für die Zuordnung fachspezifischer Termini. Dieses
Verständnis ist vor allem bei großen Projekten wichtig und dient den vielen verschiedenen
Projektbeteiligten als gemeinsame Kommunikationsbasis.
2.4 Grundlagen
service-orientierter
Architekturen
2.4.1 Einführung
Eingangs wurde bereits erwähnt, dass man sich mit den sprachlichen Bausteinen
,,Service-orientierung" und ,,Architektur" beschäftigen muss, um das Konzept SOA zu
verstehen (vgl. 2.1). Der Begriff der Architektur im Zusammenhang mit Software ist im
vorangegangenen Kapitel bereits definiert und erläutert worden.
Services sind in service-orientierten Architekturen die beschriebenen Komponenten, die
miteinander kommunizieren. Ein Service beschreibt eine wohl definierte, in sich
abgeschlossene fachliche Funktion. Er verfügt über eine klar definierte Schnittstelle.
Diese Schnittstelle legt fest, wie der Service aufgerufen werden kann, welche Parameter
zu übergeben sind und wie das Resultat aussieht [Richter u.a. 2005].
Der Aufruf eines Services ist standardisiert. Es wird exakt festgelegt wie und mit welchem
Parameter ein Service aufgerufen werden kann. Der Service wird von einem Anbieter
bereitgestellt und kann dann von einem Nutzer verwendet werden. Dabei muss weder der
Servicenutzer den Anbieter kennen, noch umgekehrt. Beide Parteien können völlig
unabhängig voneinander agieren. Durch die Definition ist jeder Service exakt spezifiziert.
Service-orientierte Architekturen
Seite
7
Ein Servicenutzer erkennt anhand der Servicedefinition, welche Parameter übergeben
werden müssen und welche Form das zurückgelieferte Ergebnis des Services hat. Somit
definiert sich die gesamte Architektur durch das Zusammenspiel dieser Services. Die
Betonung der Architektur liegt dabei auf einer losen Kopplung. Es ist möglich, die
Architektur um weitere Services zu ergänzen, oder einen existierenden Service
auszutauschen. Der Service selbst verbirgt seine eigenen Implementierungsdetails
gegenüber seiner Umgebung. Dadurch können Services, die eine identische Schnittstelle
bieten, ausgetauscht werden ohne dass der Nutzer diese Veränderung bemerkt. Dieses
Prinzip macht die Flexibilität und damit einen der wesentlichen Vorteile SOA aus (vgl.
Kapitel 2.3 Ziele einer Software-Architektur). Ein Nutzer ist nicht an einen bestimmten
Dienst gebunden, wenn er einen Service in Anspruch nehmen möchte. Er stellt eine
Anfrage über den benötigten Dienst. Das Ergebnis dieser Anfrage liefert einen
Dienstanbieter. Die Suche bezieht sich dabei auf den eigentlichen Service, nicht auf den
konkreten Anbieter, der diesen Dienst implementiert. Innerhalb service-orientierter
Architekturen gibt es ein zentrales Verzeichnis, welches die Kommunikation zwischen den
Services koordiniert. Sobald man die Architektur um einen Service erweitert, wird dieser in
dem zentralen Verzeichnis registriert. Bei dieser Registrierung wird neben den definierten
Schnittstellenbeschreibungen auch der Funktionsumfang des Services gespeichert. Wird
ein bestimmter Dienst benötigt, stellt der Benutzer eine Anfrage an den Verzeichnisdienst.
Abbildung 1 verdeutlicht dieses Prinzip:
Abbildung 1: Funktionsweise service-orientierter Architekturen [Dostal u.a. 2005]
Service-orientierte Architekturen
Seite
8
Der in dieser Abbildung gezeigte Service Contract ist ein Vertrag zwischen dem
Konsumenten und dem Anbieter des Services. Grundlage dieses Vertrages ist die
angegebene Schnittstellenbeschreibung des Dienstes [Dostal u.a. 2005]. Darüber hinaus
können auch funktionsunabhängige Eigenschaften wie beispielsweise Verfügbarkeit oder
maximale Antwortzeit geregelt werden. Dadurch ermöglicht es dieser Vertrag, Services
auch nach außen an externe Partner weiterzugeben. Diese können den angebotenen
Service dann auf Basis des zugrunde liegenden Vertrages in Anspruch nehmen. So kann
ein Unternehmen, das seine Prozesse auf SOA umstellt, sukzessive eine B2B
Anwendungslandschaft mit seinen Geschäftspartnern aufbauen. Vertragliche Grundlage
bietet der dabei geschlossene Service Contract der verwendeten Services (vgl. [Dostal
u.a. 2005]).
Durch diese Einführung in die grundlegenden Funktionsweisen service-orientierter
Architekturen soll vor allem eine Sache deutlich werden: Service-orientierte Architekturen
sind ein fachliches Konzept, indem ohne Bezug zu einer konkreten technischen
Realisierung Services definiert werden. SOA sind somit technologieunabhängig und
betrachten, beispielsweise in einem Unternehmen, die durchgehenden
Geschäftsprozesse auf einer höheren Ebene (vgl. [Richter u.a. 2005]). Dabei nutzen SOA
ebenfalls Aspekte anderer Architekturen, wie beispielsweise das Prinzip der losen
Kopplung, oder das Information-Hiding-Prinzip (vgl. [Dostal u.a. 2005]). Diese werden
allerdings nicht auf technischer, sondern auf fachlicher Ebene verwendet. Service-
orientierte Architekturen sind ein Konzept, dass von der konkreten Implementierung und
Anwendungslandschaft des Unternehmens abstrahiert, um die Geschäftsprozesse
ganzheitlich zu betrachten. Sobald diese Prozesse umfassend als Service definiert
worden sind, können service-orientierte Architekturen eingeführt werden. In diesem
Zusammenhang spielen Web Services und Enterprise Application Integration (EAI) eine
Rolle. Diese Begriffe werden im nachfolgenden Kapitel definiert und von SOA abgegrenzt.
Service-orientierte Architekturen
Seite
9
2.4.2 Begriffsabgrenzung
Enterprise Application Integration (EAI)
Geschäftsanwendungen und deren Abbildungen in IT-Systemen sind im Laufe der Zeit
immer komplexer geworden. In einem Unternehmen entstehen immer mehr Lösungen für
die Abwicklung von spezifischen Geschäftsprozessen. Dies hat eine Vielzahl von IT-
Systemen zur Folge. Die Problematik in den Unternehmen besteht darin, diese Vielzahl
von Systemen zu verbinden, um Daten und Prozesse integrieren zu können (vgl. [Kaib
2002]. EAI ist seit Beginn der 90er Jahre das gebräuchliche Konzept für Daten- und
Prozessintegration [Kaib 2002]. Dabei dient ein einheitlicher Business Bus als
Integrationsplattform. Das entscheidende Prinzip beim EAI-Ansatz ist die Tatsache, dass
die bestehenden Schnittstellen nicht verändert werden. Um diese dennoch integrieren zu
können, werden Adapter entwickelt, die das System mit dem Business Bus verbinden.
Abbildung 2 zeigt eine schematische Darstellung des Konzeptes.
Abbildung 2: Schematische Darstellung des EAI-Konzepts [Kaib 2002]
Service-orientierte Architekturen
Seite
10
Die meisten EAI-Produkte liefern bereits vorgefertigte Adapater für gängige
Standardsoftware an. Dadurch wird der Integrationsaufwand erheblich gesenkt
[Großmann, Koschek 2005]. Des Weiteren bieten solche Produkte einheitliche
Schnittstellen und eine integrierte Middleware an. Die Middleware ist in diesem
Zusammenhang für den Transport komplexer Daten zwischen den Anwendungen
zuständig. Zudem ermöglicht die Middleware entfernte Funktionsaufrufe zwischen den
Komponenten (sogenannte Remote Procedure Calls (RPCs) [Großmann, Koschek 2005]).
Das Konzept der EAI und die damit verbundenen Produkte der Hersteller unterstützen ein
Unternehmen, die vorhandenen Systeme auf einer gemeinsamen technischen Ebene zu
integrieren. Trotz des gemeinsamen Ziels der Integration, das sowohl der SOA- als auch
der EAI-Ansatz verfolgen, sind beide Konzepte voneinander abzugrenzen. Der
Unterschied liegt im Ansatz der Integration. Während das EAI-Konzept eine komplette
technische Betrachtung der Unternehmensintegration ist, betrachten SOA die Integration
auf Prozessebene. Dadurch wird die Thematik bei SOA auf einer höheren Ebene
betrachtet. EAI kann einer SOA als Integrationsgrundlage dienen (vgl. [Richter u.a.
2005]).
Web Services
Web Services werden oft fälschlicherweise mit SOA gleichgesetzt. Service-orientierte
Architekturen beschreiben ein technologieneutrales Konzept für Software-Architekturen
(vgl. Kapitel 2.4.1). Web Services beschreiben eine konkrete Implementierung, um
service-orientierte Architekturen umzusetzen. In der Praxis werden allerdings meistens
Web Services verwendet, um SOA zu implementieren [Hauser, Löwer 2004].
Web Services basieren auf Standards, die es ermöglichen, Services anzubieten und zu
nutzen. Der Unterschied zum klassischen Client/Server Prinzip liegt darin, dass nun keine
,,Mensch-zu-Maschine" Kommunikation mehr vorliegt. Bei der Implementierung von Web
Services und damit der Umsetzung SOA geht es um die reine ,,Maschine-zu-Maschine"
Kommunikation [Hauser, Löwer 2004]. Mit Maschine sind damit Anwendungen gemeint,
die Daten untereinander austauschen. Dieses Prinzip ist nicht neu, das Austauschen von
Daten zwischen Anwendungen kann auch ohne Web Services realisiert werden. Dafür
gibt es Middleware wie beispielsweise CORBA oder DCOM. Allerdings sind der Umgang
mit diesen Techniken und der Einsatz bei verteilten Systemen relativ komplex und
aufwändig [Heinzl und Mathes 2005]. Zudem ergeben sich aufgrund der
Sicherheitseinstellungen der einzelnen Systeme häufig Probleme bei der Kommunikation
zwischen den Anwendungen [Posch u.a. 2004]. Web Services bieten auf diesem Bereich
Service-orientierte Architekturen
Seite
11
einen entscheidenden Vorteil gegenüber der zuvor verwendeten Middleware, da sie auf
dem Hypertext Transfer Protocol (http) basieren [Hauser, Löwer 2004]. Die
Kommunikation ist somit für Intranet- und Extranet-Umgebungen geeignet, da Firewalls
kein Problem mehr bei der Unternehmenskommunikation darstellen. Es ist mit Web
Services möglich, umfangreiche B2B-Applikationen über Unternehmensgrenzen hinweg
zu realisieren. Web Services sind dabei keine einheitliche Technologie, sondern basieren
auf verschiedenen Standards und Definitionen. Diese Standards adressieren
verschiedene Bereiche, wie beispielsweise die Übermittlung, die Beschreibung von
Services, oder den Verzeichnisdienst (vgl. [WC3 2006_d]). Eine detailliertere Betrachtung
der einzelnen Komponenten von Web Services findet sich in Kapitel 2.5 ,,Die
Implementierung service-orientierter Architekturen". Dort wird exemplarisch gezeigt, wie
SOA auf Basis von Web Services implementiert werden können. Die einzelnen
Bestandteile eines Web Services werden vorgestellt und dem Prinzip service-orientierter
Architekturen zugeordnet.
Enterprise Service Architecture (ESA)
Im Zusammenhang mit service-orientierten Architekturen stößt man häufig auf den Begriff
der Enterprise Service Architecture, kurz ESA genannt. Bevor weitere Detailkonzepte
service-orientierter Architekturen erläutert werden, soll auch dieser Begriff zunächst von
SOA abgegrenzt werden.
ESA bezeichnet die Interpretation der SAP AG service-orientierter Architekturen. In dem
fachlichen Konzept gibt es dabei keinen Unterschied zwischen ESA und SOA [Richter u.a.
2005]. Mit dem Produkt Netweaver hat die SAP AG eine Integrationsplattform entwickelt,
die Unternehmen einsetzen können, um Ihre Daten und Prozesse zu integrieren. Diesen
Vorgang bezeichnet die SAP AG als Enterprise Service Architecture (vgl. [SAP 2006_a]).
Dabei wird eine eigene Strategie verfolgt, um Kunden an das Unternehmen zu binden. Als
Werkzeug gibt es neben der Integrationsplattform Netweaver den Composite Application
Framework. Mit diesem Framework können Kunden Anwendungen kombinieren und
Services im dem beschriebenen Sinne service-orientierter Architekturen bereitstellen
[Goebel, Ritthaler 2004]. Im nachfolgenden Kapitel werden aufbauend auf dem in Kapitel
2.4.1 vermittelten Grundverständnis und dieser Begriffsabgrenzung weiterführende
Konzepte SOA analysiert. Eine detailliertere Betrachtung der SAP Strategie zum Thema
service-orientierte Architekturen befindet sich im Kapitel 4.1 ,,Einführung und Überblick in
die SOA-Strategie der SAP AG".
Service-orientierte Architekturen
Seite
12
2.4.3 Der Anspruch an SOA Definition und Ziele
Nachdem die Grundprinzipien service-orientierter Architekturen analysiert wurden und
SOA von verwandten Themenkomplexen abgegrenzt worden sind, greift dieses Kapitel
noch einmal die allgemeine Definition von Architektur aus dem Kapitel 2.2 und die Ziele
einer Software-Architektur aus dem Kapitel 2.3 auf. Es soll gezeigt werden, dass service-
orientierte Architekturen der angegebenen Definition entsprechen und die allgemein
formulierten Ziele einer Software Architektur erfüllen können.
SOA bieten durch die gezeigten Services eine abstrakte Sicht auf das Gesamtsystem.
Wird eine service-orientierte Architektur skizziert, besteht diese aus den angebotenen
Services, dem Verzeichnisdienst und den Nutzern. Die Kommunikation wird durch die
Verbindung zwischen Servicenutzer und Anbieter verdeutlicht. Die technische Umsetzung
hängt dabei von der Art der Implementierung SOA ab. Ein Service selbst verbirgt dabei
seine Implementierungsdetails. Für einen Nutzer ist das Resultat einer Anfrage
entscheidend, nicht der Weg, wie der Service zu diesem Resultat kommt. Dadurch bietet
dieses System eine flexible Möglichkeit, B2B Applikationen aufzubauen. Viele
Unternehmen möchten ihre Geschäftsprozesse gegenüber Partnern und Lieferanten nicht
offen legen. In einer gemeinsamen Geschäftsanwendung, die auf einer service-
orientierten Architektur basiert, können sie die Funktionen als Service definieren. Dieser
kann dann durch wohldefinierte Schnittstellen von Partnern und Lieferanten genutzt
werden, ohne dass das Unternehmen seine Geschäftsprozesse offen legen muss. Dieses
Prinzip ist in der Informatik nicht neu und wird als ,,Information-Hiding-Prinzip" bezeichnet
(vgl. Kapitel 2.4.1). Weitere Aspekte der Definition beschreiben die leichte Erweiterbarkeit
und die Wiederverwendung von Software. Auch diese Anforderung wird durch den SOA-
Ansatz erfüllt. Eine Software kann leicht durch das Hinzufügen von Services erweitert
werden (vgl. [Dostal u.a. 2005]). Ein konkretes Beispiel ist die Erweiterung SOA um eine
Anwendung. Die Aufgabe besteht darin, die Funktionalität, die diese Anwendung bietet, in
einen Service umzuwandeln. (In diesem Vorgehen wird auch der unterschiedliche Ansatz
der Integration zwischen SOA und EAI deutlich, vgl. Kapitel 2.4.2 Begriffsabgrenzung
EAI). Ist die Anwendung als Service definiert worden, muss sie dem Verzeichnisdienst als
neuer Service bekannt gemacht werden. Auf diese Weise lassen sich SOA sukzessive um
ausgewählte Funktionalitäten erweitern. Die Wiederverwendung wird durch dieses Prinzip
ebenfalls gefördert, da ein vorhandener Service nicht neu entwickelt werden muss,
sondern dann von jedem Servicenutzer verwendet werden kann.
Service-orientierte Architekturen
Seite
13
Somit werden auch die in Kapitel 2.3 verfolgten Ziele einer Architektur erreicht. Das
System ist flexibel genug, um Services einfach ergänzen zu können, oder einzelne
Services auszutauschen. Ferner wird durch die Definition aller Dienste als Service und
einer exakten Beschreibung der angebotenen Dienste eine gemeinsame
Kommunikationsgrundlage für alle Beteiligten gelegt.
Das Grundverständnis service-orientierter Architekturen ist damit beschrieben. Einfache
Strukturen basieren exakt auf diesem Prinzip und können mit einem einheitlichen
Kommunikationsprotokoll, einer Beschreibung der Services und einem Verzeichnisdienst
auch genauso umgesetzt werden. Allerdings reichen diese einfachen Grundlagen für die
Praxis meinst nicht aus, da die Zusammenhänge zwischen den Systemen und Prozessen
sehr komplex sind. Zentrale Fragestellungen betreffen die Umsetzung von sicheren
Transaktionen innerhalb SOA und der Umsetzung von Geschäftsprozessen. Das nächste
Kapitel betrachtet aufbauend auf dem vermittelten Wissen die Implementierung service-
orientierter Architekturen.
2.5 Die Implementierung service-orientierter Architekturen
Nachdem die Komponenten, Vorteile und theoretischen Aspekte service-orientierter
Architekturen vorgestellt worden sind, widmet sich dieses Kapitel der Umsetzung. Es gibt
generell verschiedene Möglichkeiten diese zu realisieren. Vorweg sei aber bemerkt, dass
sich in der Praxis die Umsetzung service-orientierter Architekturen auf Basis von Web
Services durchgesetzt haben [Newcomer, Lomow 2004]. Technisch gesehen ist es
allerdings möglich, service-orientierte Architekturen auch anders umzusetzen,
beispielsweise auf Basis von CORBA. CORBA wird oftmals als erste Umsetzung service-
orientierter Architekturen beschrieben [Hauser und Löwer 2004]. Der Nachteil gegenüber
der Verwendung von Web Services liegt allerdings in dem Problem der Überwindung von
Unternehmensgrenzen (vgl. Kapitel 2.4.2, Definition von Web Services). Weitere
Möglichkeiten liegen in der Verwendung von REST oder der direkten Verwendung von
Remoting Objekten. REST steht für REpresentational State Transfer und beschreibt einen
Architekturstil, der die Realisierung service-orientierter Architekturen auf Basis von URIs
realisiert [Langham 2002]. REST wurde geprägt von Roy Fielding, der diese Idee in seiner
Dissertation im Jahre 2000 erstmals veröffentlicht hat. REST steht in Konkurrenz zu
SOAP, findet aber in der Praxis durch die weite Verbreitung von SOAP kaum
Berücksichtigung [Hauser, Löwer 2004]. Für detailliertere Informationen zu REST sei auf
[Fielding 2000] verwiesen. Mit der direkten Verwendung von Remoting Objekten ist der
Aufruf von entfernten Methoden eines Objektes gemeint, dass zu einer anderen
Service-orientierte Architekturen
Seite
14
Anwendung gehört. Remoting-Technologien in diesem Sinne sind beispielsweise .NET
Remoting von Microsoft (vgl. [Microsoft 2006]) oder Java RMI von Sun (vgl. [RMI 2006]).
Der Vorteil gegenüber Web Services liegt hier in der Geschwindigkeit, da direkt
Binärdaten übertragen werden können [Hauser, Löwer 2004]. Allerdings ist man dadurch
auch an eine spezifische Plattform gebunden. Eine Verbindung heterogener Plattformen
ist mit der direkten Verwendung von Remoting Objekten nicht möglich, weder mit .NET
Technologien, noch mit Java RMI. Um heterogene Plattformen zu verbinden bieten sich
Web Services an [Einhorn, Olbrich 2004]. Diese Möglichkeit ist ein wesentlicher Grund
dafür, dass sich Web Services zum Standard für die Umsetzung service-orientierter
Architekturen entwickelt haben [Newcomer, Lomow 2004]. Daher sind die anderen
Umsetzungsmöglichkeiten lediglich der Vollständigkeit halber erwähnt und sollen nicht
weiter vertieft werden.
Im nachfolgenden Kapitel werden die elementaren Bausteine von Web Services vor-
gestellt und gezeigt, welche Aufgaben sie bei der Umsetzung service-orientierter
Architekturen erfüllen. Web Services sind dabei nicht als eigenständige Technologie zu
sehen, sondern basieren auf Standards und Spezifikationen, die im Zusammenspiel
miteinander eine eigene Technologie bilden. Um SOA auf Basis von Web Services
umzusetzen, müssen drei wesentliche Elemente spezifiziert werden:
1. Die Übertragung
Zwischen dem Service-Nutzer, dem Service-Anbieter und dem Verzeichnisdienst einer
SOA (vgl. Abbildung 1) müssen Daten übertragen werden. Durch eine Spezifikation des
Web Services wird geregelt, wie diese Daten übertragen werden.
2. Die Beschreibung
Der angebotene Service und seine Methoden müssen exakt beschrieben werden, damit
der Service-Nutzer erkennt, was dieser Service ihm bieten kann und wie er zu verwenden
ist.
3. Der Verzeichnisdienst
Damit ein Service-Nutzer einen bestimmten Service finden kann, sind alle verfügbaren
Services in einem Verzeichnisdienst registriert.
Diese drei Spezifikationen bilden die Basis von Web Services und werden in den
folgenden Kapiteln detailliert beschrieben. Darüber hinaus gibt es noch weitere Standards
im Web Service Bereich für verschiedene Anwendungsbereiche wie beispielsweise
Sicherheit, Transaktions- oder Prozessmanagement (vgl. [Hauser, Löwer 2004]). Diese
Standards werden im Rahmen der Diplomarbeit allerdings nicht weiter erläutert.
Service-orientierte Architekturen
Seite
15
2.5.1 SOAP
SOAP ist ein Protokoll mit dessen Hilfe Daten zwischen Systemen ausgetauscht werden
können und adressiert den ersten Aufzählungspunkt in der vorangegangen Liste der
Standards von Web Services. SOAP hat sich gegenüber XML-RPC (XML Remote
Procedure Call) als Standardprotokoll für Web Services durchgesetzt. In vielen
Publikationen wird es oft schon als Synonym für Web Services verwendet [Hauser, Löwer
2004]. Dies ist zwar nicht korrekt, zeigt aber zugleich die Bedeutung, die SOAP
mittlerweile erlangt hat. SOAP stand früher für Simple Object Access Protocol, seit der
Version 1.2 ist dieser Name aber mittlerweile kein Akronym mehr, sondern steht für sich
[W3C 2006_a].
SOAP spezifiziert wie eine Nachricht für die Übertragung aufgebaut werden muss und
garantiert damit, dass die Gegenstelle diese Nachricht verstehen kann. Im Bereich der
Web Services wird SOAP verwendet, damit der Service-Anbieter den Service-Aufruf des
Nutzers verstehen und dessen übergebene Parameter eindeutig zuordnen kann.
Dasselbe Prinzip gilt für die Antwort des Service-Anbieters. Durch die Einhaltung der
SOAP-Spezifikation kann der Empfänger die Antwort korrekt auswerten. Dabei liefert das
Protokoll zwei wesentliche Dienste. Zum einen können in SOAP Remote Procedure Calls
(RPCs) eingebettet werden, die das Aufrufen einer entfernten Methode ermöglichen, zum
anderen kann SOAP für die Übermittlung von asynchronen Nachrichten verwendet
werden. Letzterer Punkt ist der entscheidende Vorteil von SOAP gegenüber XML-RPC,
mit dem lediglich entfernte Funktionsaufrufe realisiert werden können [Hauser, Löwer
2004].
Dabei baut SOAP genau wie XML-RPC auf XML auf. Die einzelnen SOAP-Anweisungen
werden in XML-Tags beschrieben und haben denselben hierarchischen Aufbau wie eine
normale XML-Datei. Eine SOAP-Nachricht besteht dabei aus drei Teilen: Dem SOAP-
Envelope, einem umfassenden Tag, das den SOAP-Header und den SOAP-Body
umschließt. Abbildung 3 verdeutlicht diesen Aufbau:
Details
- Seiten
- Erscheinungsform
- Originalausgabe
- Jahr
- 2006
- ISBN (eBook)
- 9783956361388
- ISBN (Paperback)
- 9783836600781
- Dateigröße
- 2.2 MB
- Sprache
- Deutsch
- Institution / Hochschule
- Universität Siegen – Wirtschaftswissenschaften, Wirtschaftsinformatik
- Erscheinungsdatum
- 2007 (Januar)
- Note
- 1,3
- Schlagworte
- wirtschaftsinformatik unternehmensportal service
