Aspekte des Entwurfs und der Implementierung service-orientierter Architekturen am Beispiel von Portal-Systemen


Diplomarbeit, 2006

117 Seiten, Note: 1.3


Leseprobe


Page 12


Einleitung

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

Page 14


Service-orientierte Architekturen

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].

Page 15


Service-orientierte Architekturen

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

Page 16


Service-orientierte Architekturen

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]): x eine effiziente Grundlage für das Entwicklungsprojekt bieten x den aus den Anforderungen ermittelten Workflow spezifizieren x flexibel auf fachliche und technische Änderungen reagieren können x die Software muss leicht erweiterbar und einzelne Komponenten austauschbar sein x 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.

Page 17


Service-orientierte Architekturen

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.

Page 20


Service-orientierte Architekturen

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.

image 7fc5afc5218f37e66d346f8d29c3c965

Abbildung 2: Schematische Darstellung des EAI-Konzepts [Kaib 2002]

Page 23


Service-orientierte Architekturen

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.

Page 24


Service-orientierte Architekturen

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

Page 26


Service-orientierte Architekturen

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:

Page 27


Service-orientierte Architekturen

image 0926ecff69681be747742baab17d76bf

Abbildung 3: Aufbau einer SOAP-Nachricht [Dostal u.a. 2005]

Diese SOAP-Nachricht kann dann mit Hilfe eines Übertragungsprotokolls zwischen Service-Anbieter und Service-Nutzer ausgetauscht werden. In der Praxis hat sich dabei HTTP als Standardweg für die Übertragung von SOAP-Nachrichten durchgesetzt [Knuth 2003]. Diese Kombination erklärt die verbreitete Formel SOAP = XML over HTTP, die in der Literatur häufig zu finden ist.

Für detailliertere Informationen zum Aufbau von SOAP-Nachrichten und dem Ablauf der Kommunikation befindet sich im Anhang ein ausführliches Beispiel. Dabei wird ein Web Service vorausgesetzt, der die Gültigkeit einer Kreditkarte anhand der Kartennummer und dem Gültigkeitsdatum prüfen kann. Das Beispiel zeigt sowohl den Aufbau der SOAP-Nachricht die ein Client sendet, um eine bestimmte Kreditkarte zu prüfen, als auch die SOAP-Nachricht, die der Service als Antwort zurückliefert.

2.5.2 Web Service Description Language (WSDL)

Der zweite wesentliche Baustein von Web Services ist die exakte Beschreibung des angebotenen Services. Für die reine Kommunikation zwischen Service-Nutzer und Service-Anbieter ist ein Protokoll wie SOAP und die Übertragung über http ausreichend. Diese beiden Standards realisieren die eigentliche Kommunikation zwischen Anbieter und Nutzer. Voraussetzung dafür ist allerdings, dass der Service-Nutzer die exakten Methoden(namen) des gewünschten Services kennt, damit diese Aufrufe in der SOAP-Nachricht korrekt verwendet werden können. Wenn man ein Software Projekt auf Basis von Web Services realisiert, kann man jedoch nicht davon ausgehen, dass jeder Service-

Page 29


Service-orientierte Architekturen

Methoden, die der Web Service zur Verfügung stellt [Dostal u.a. 2005]. Dadurch ist dieser das zentrale Element einer WSDL-Beschreibungsdatei und kann mit den Bibliotheken einer traditionellen Programmiersprache verglichen werden. Das „binding“-Tag gibt an, mit welchem Protokoll und in welchem Format die in einem portType definierten Methoden abgearbeitet werden. An dieser Stelle wird im Dokument die Beschreibungssprache WSDL mit dem Protokoll SOAP verbunden, daher der Name „binding“ (engl. verbinden). Der letzte elementare Tag ist der „service“-Tag. In diesem wird der konkrete Endpunkt des Dienstes beschrieben. Für die Angabe des Endpunktes wird in einem untergeordneten Port-Element ein direkter URI (Unified Ressource Identifier) vergeben. Darüber hinaus gibt es noch optionale Elemente wie documentation und import, die aber hier nicht weiter betrachtet werden sollen.

Diese sechs kurz vorgestellten XML-Tags werden in einem WSDL-Dokument benötigt, um einen Web Service einheitlich zu beschreiben (vgl. [Dostal u.a. 2005]). Jedem Service-Nutzer, der in der Lage ist, diese Datei zu lesen, ist es somit möglich, den angebotenen Web Service (automatisch) zu nutzen. Für die Erstellung einer solchen Beschreibungsdatei gibt es bereits eine Vielzahl an WSDL-Generatoren, die aufbauend auf einem Web Service und den benötigten Meta-Daten eine WSDL-Datei nach dem aktuellen WSDL-Standard generieren können (aktuell ist die WSDL-Version 2.0, siehe [W3C 2006_c]). Für detailliertere Informationen zu dem Aufbau einer WSDL-Beschreibungsdatei mit den in diesem Kapitel vorgestellten Tags, befindet sich im Anhang dieser Diplomarbeit ein konkretes Beispiel.

2.5.3 Universal Description, Discovery and Integration (UDDI)

Der dritte und letzte Baustein im Bereich von Web Services ist der Verzeichnisdienst. Ein Verzeichnisdienst unterstützt den Service-Nutzer bei der Suche nach einem geeigneten Service (s. Abbildung 1). Dabei gibt es in service-orientierten Architekturen einen zentralen Verzeichnisdienst, in dem alle zur Verfügung stehenden Web Services gelistet sind. Der Verzeichnisdienst kann mit den gelben Seiten im alltäglichen Leben verglichen werden. Benötigt ein Nutzer einen bestimmten Dienst, stellt er eine Anfrage an den Verzeichnisdienst. Dieser liefert ihm entsprechend seiner Suchanfrage den passenden Service. Wird die Anwendung um einen weiteren Service ergänzt, wird dieser Service dem Verzeichnisdienst hinzugefügt. Dadurch kann jeder Service-Nutzer dieser Architektur den neu hinzugekommenen Service direkt verwenden.

Durchgesetzt im Bereich der Verzeichnisdienste hat sich UDDI [Hauser, Löwer 2004]. Diese Abkürzung steht für Universal Description, Discovery and Integration. Entstanden

Page 31


Service-orientierte Architekturen

Unternehmen sich immer noch in einem sehr frühen Anfangsstadium befindet. Viele Unternehmen haben sich mit diesem Thema noch gar nicht beschäftigt. Diejenigen Firmen, die schon an einer service-orientierten Architektur arbeiten, beginnen damit, ihre bestehenden Anwendungen in Services umzubauen. Diese Services können zu Beginn der Einführung SOA immer noch manuell aufgerufen werden. Die Stärke eines Verzeichnisdienstes kommt allerdings erst bei der automatischen Kommunikation zwischen Maschinen zur Geltung.

Daher wird UDDI in Zukunft an Bedeutung gewinnen, zunehmend mit dem Prinzip der Semantic Web Services. Diese haben das Ziel, dass Maschinen nicht nur Daten untereinander austauschen können, sondern zudem noch in der Lage sind, diese Daten automatisch auswerten zu können [Hauser, Löwer 2004]. Einen etwas ausführlicheren Einblick in dieses Thema wird im Kapitel 5 „Fazit und Ausblick“ gegeben.

2.6 Weiterführende Aspekte service-orientierter Architekturen

Nach den Grundlagenbetrachtungen service-orientierter Architekturen und der Darstellung einer konkreten Implementierung am Beispiel von Web Services, geht dieses Kapitel auf die Einführung SOA in einem Unternehmen ein. Die ersten beiden Unterkapitel analysieren zwei zentrale Probleme bei der Einführung service-orientierter Architekturen: Die Vorgehensweise bei der Einführung (Kapitel 2.6.1) und die fachliche Aufteilung der einzelnen Services (Kapitel 2.6.2). Das abschließende Unterkapitel 2.6.3 zeigt dann konkret, wie man mit Hilfe einer Prozessbeschreibungssprache Geschäftsprozesse in service-orientierten Architekturen umsetzen kann.

2.6.1 Top-Down Ansatz

Die Einführung service-orientierter Architekturen ist immer eine strategische Entscheidung (vgl. [Richter u.a. 2005]). Wie bereits in den vorangegangen Kapiteln verdeutlicht, handelt es sich bei service-orientierten Architekturen nicht um ein technisches, sondern um ein fachliches Konzept. Der entscheidende Vorteil SOA liegt in der Umsetzung der Geschäftsprozesse als Services. Diese Services sind in der Architektur lose gekoppelt (vgl. Kapitel 2.4.1). Wenn dieses Prinzip konsequent umgesetzt worden ist, kann ein Unternehmen durch die Flexibilität der lose gekoppelten Services sehr schnell seine Geschäftsprozesse anpassen, um so auf Änderungen im Markt zu reagieren [Richter u.a. 2005]. In diesem Prinzip liegt die entscheidende Stärke service-orientierter Architekturen. Unternehmen, die eine service-orientierte Architektur einführen, wollen diese Flexibilität nutzen, um so einen Wettbewerbsvorteil zu erlangen. Das hat zur Folge, dass service-

Page 32


Service-orientierte Architekturen

orientierte Architekturen, um sie effizient in einem Unternehmen einführen zu können, mit einem Top-Down Ansatz eingeführt werden müssen. Dies bedeutet, dass hierfür zunächst auf fachlicher Ebene alle relevanten Geschäftsprozesse im Unternehmen definiert werden müssen. In einem zweiten Schritt werden diese Geschäftsprozesse in Services umgewandelt. Es muss gewährleistet sein, dass ein Geschäftsprozess durch eine Verbindung (Komposition) von fachlichen Services durchgehend abgebildet werden kann. Erst nach dieser ausführlichen fachlichen Analyse- und Designphase wird die technische Realisierung im Rahmen einer SOA-Umsetzung vorgenommen.

Ende der Leseprobe aus 117 Seiten

Details

Titel
Aspekte des Entwurfs und der Implementierung service-orientierter Architekturen am Beispiel von Portal-Systemen
Hochschule
Universität Siegen
Note
1.3
Autor
Jahr
2006
Seiten
117
Katalognummer
V186252
ISBN (eBook)
9783869438207
ISBN (Buch)
9783869430843
Dateigröße
3113 KB
Sprache
Deutsch
Schlagworte
aspekte, entwurfs, implementierung, architekturen, beispiel, portal-systemen
Arbeit zitieren
Jens Kohne (Autor:in), 2006, Aspekte des Entwurfs und der Implementierung service-orientierter Architekturen am Beispiel von Portal-Systemen, München, GRIN Verlag, https://www.grin.com/document/186252

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Aspekte des Entwurfs und der Implementierung service-orientierter Architekturen am Beispiel von Portal-Systemen



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden