Analyse von Web Service-Spezifikationen zur Unterstützung von Transaktionen in Geschäftsprozessen


Masterarbeit, 2006

128 Seiten, Note: 1,3


Leseprobe


Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Listings

Abkurzungsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Ziele
1.3 Aufbau der Arbeit

2 Service-orientierte Architektur
2.1 Merkmale einer service-orientierten Architektur
2.1.1 Lose Kopplung
2.1.2 Verzeichnisdienst und dynamische Bindung
2.1.3 Offene Standards
2.1.4 Einfachheit
2.2 Definition einer service-orientierten Architektur
2.3 Struktur und Rollen in einer service-orientierten Architektur
2.4 Dienste

3 Web Services
3.1 Charakteristische Merkmale der Web-Service-Plattform
3.1.1 Web Service-Protokoll-Stack
3.1.2 Web Service Description Language
3.1.3 SOAP
3.1.4 Verzeichnisdienste von Web Services
3.1.5 Web Services Orchestration
3.2 Einordnung und Abgrenzung von Web Services

4 Grundlagen transaktionssicherer Verarbeitung
4.1 ACID-Transaktionen
4.1.1 Serialisierbarkeit von Ausfuhrungsplanen
4.1.2 Techniken zur Synchronisation
4.1.2.1 Preventive Synchronisationsverfahren
4.1.2.2 Verifizierende Synchronisationsverfahren
4.1.3 Einfache Transaktionen
4.1.4 Verteilte Transaktionen
4.2 Business-Transaktionen
4.2.1 Zusatzliche Anforderungen an das Koordinationsmodell
4.2.2 Losungsansatze
4.2.3 Zusammenfassung

5 Transaktionsmodelle fur Web Services
5.1 Business Transaction Protocol
5.1.1 Konzept
5.1.1.1 Unterstutzte Transaktionsarten
5.1.1.2 Struktur des Business Transaction Protocols
5.1.1.3 Lebenszyklus einer einfachen BTP-Transaktion
5.1.1.4 Transaktionsstrukturierung
5.1.2 Optimierungen
5.2 WS-Coordination und WS-Transactions
5.2.1 Konzept
5.2.1.1 WS-Coordination
5.2.1.2 WS-Atomic Transaction
5.2.1.3 WS-Business Activity
5.2.2 Optimierungen
5.3 WS-Composite Application Framework
5.3.1 Konzept
5.3.1.1 Web Services Context
5.3.1.2 Web Services Coordination Framework
5.3.1.3 Web Services Transaction Management
5.3.2 Optimierungen
5.4 Vergleich und Abgrenzung der Transaktionsmodelle
5.4.1 Modellarchitektur
5.4.2 Transaktionssteuerung
5.4.3 Trennung von Koordination und Geschaftslogik
5.4.4 Koordinationsstrukturierung
5.4.5 Anwendungsbereich
5.4.6 Erweiterbarkeit und Kompatibilitat

6 Zusammenfassung und Ausblick

Literaturverzeichnis

Anhang

Abbildungsverzeichnis

Abb. 1: Registratur und dynamische Bindung uber einen Verzeichnisdienst

Abb. 2: Zusammenspiel der Rollen einer SOA (Vgl. [Dus+03])

Abb. 3: Rollen einer SOA im Kontext von Web Services

Abb. 4: Pendants IDL und WSDL

Abb. 5: Struktur einer WSDL-Datei

Abb. 6: Struktur einer SOAP-Nachricht

Abb. 7: Zweiphasige Transaktion

Abb. 8: Zweiphasige Transaktion mit Preclaiming

Abb. 9: Strikt zweiphasige Transaktion

Abb. 10: Strikt zweiphasige Transaktion mit Preclaiming

Abb. 11: Verifizierende Synchronisation mit lokalen Puffern

Abb. 12: X/Open DTP Referenzmodell

Abb. 13: Das 2-Phasen-Commit-Protokoll

Abb. 14: Zerlegung einer Geschaftstransaktion anhand der SOM-Methodik [vgl. FeSi01]

Abb. 15: Koordinator-Teilnehmer-Transaktionsmodell (vgl. [LiFr03])

Abb. 16: BTP-Basisarchitektur [Fur+04]

Abb. 17: Inferior-Typ-Hierarchie [Fur+04]

Abb. 18: Superior-Typ-Hierarchie [Fur+04]

Abb. 19: BTP Superior-Inferior-Relation [Fur+04]

Abb. 20: BTP-Interposition [Fur+04]

Abb. 21: Struktur des WS-Coordination Service (vgl. [Cab+05a])

Abb. 22: Registrierungsprozess bei WS-Coordination [Cab+05a]

Abb. 23: WS-Coordination-Interposition [Cab+05a]

Abb. 24: Completion Protocol [Cab+05b]

Abb. 25: Two-Phase Commit Protocol [Cab+05b]

Abb. 26: Business-Agreement-With-Participant-Completion-Protokoll [Cab+05c]

Abb. 27: Business-Agreement-With-Coordinator-Completion-Protokoll [Cab+05c]

Abb. 28: Domanen der WS-CAF [Bun+03a]

Abb. 29: Beziehungen der WS-CTX-Komponenten [Bun+03b]

Abb. 30: Strukturierung durch untergeordnete Koordinatoren bei WS-CF [Bun+03c]

Abb. 31: Beziehung zwischen WS-CF und WS-TXM [Bun+03d]

Abb. 32: 2PC des WS-TXM bei ACID-Transactions [Bun+03d]

Abb. 33: Zustandsubergange des Koordinators bei WS-TXM (AT) [Bun+03d]

Abb. 34: WS-TXM-Sync-Protokoll [Bun+03d]

Abb. 35: Nested Scopes beim LRA-Modell [Bun+03d]

Abb. 36: Interaktion beim LRA-Modell [Bun+03d]

Abb. 37: Domanenstruktur der WS-TXM Business Process-Transaktion [Bun+03d]

Abb. 38: WS-CAF-Bestandteile im Web Service-Stack [Bun+03b]

Tabellenverzeichnis

Tab. 1: Gegenuberstellung gelaufiger Verteilungsplattformen

Tab. 2: Verklemmung von zwei Transaktionen

Tab. 3: Kompatibilitatsmatrix des RX-Sperrverfahrens

Tab. 4: Implementierungsalternativen des 2PO

Tab. 5: An Kontrollbeziehungen beteiligte BTP-Rollen

Tab. 6: An Ergebnisbeziehungen beteiligte BTP-Rollen

Tab. 7: Standard-Qualifiers des Business Transaction Protocols

Tab. 8: Gegenuberstellung der vorgestellten Transaktionsmodelle

Listings

Listing 1: Beispiel einer CreateCoordinationContext-Nachricht [Cab+05a]

Listing 2: Beispiel einer CreateCoordinationContextResponse-Nachricht [Cab+05a]

Listing 3: Beispiel einer Register-Nachricht [Cab+05a]

Listing 4: Beispiel einer RegisterResponse-Nachricht [Cab+05a]

Abkurzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Die letzten Jahrzehnte der Software- und Systementwicklung waren von zunehmender Verteilung von Softwaresystemen gepragt. Aus monolithischen, zentralisierten und iso- lierten Systemen werden 2-tier- und Multi-Tier-Systeme, die feingranularer strukturiert und miteinander integriert sind [GrTh00, S. 5-13].

Objekt- und komponentenorientierte Architekturen losen monolithisch entworfene Sys- teme ab, bzw. versuchen diese mithilfe von Kopplungsarchitekturen und Integrations- konzepten in die wachsenden heterogenen Systemlandschaften einzubinden. Man spricht in diesem Zusammenhang von der Transformation und/oder Integration von Alt- systemen (vgl. dazu [Ulri02]). Damit Systeme, ihre Plattformen und Architekturen ver- schiedener Hersteller miteinander interoperieren konnen, begleitet diese Entwicklungen ein Prozess der Evaluation und Standardisierung.

1.1 Motivation

Seit Jahren streben Softwarearchitekten und fordern Anwender nach Systemen, die durch relativ einfache Komposition von autonomen Black-Box-Komponenten flexibel gestaltbar und umsetzbar waren. Im Rahmen der Softwareentwicklung etablierte sich in diesem Zusammenhang ein Entwicklungsparadigma namens komponentenbasierte An- wendungsentwicklung (Component Based Development, CBD) und es wurden zahlrei- che Komponentenmodelle entwickelt, wie z.B. COM, DCOM, JavaBeans, EJB und CORBA [GrTh00, S. 3f.]. Ahnliches wunschen sich Unternehmen fur die Verwaltung von Geschaftsprozessen. Vorhandene Aktivitatsbausteine der betrieblichen Informati- onssysteme (IS) sollen bedarfsgerecht und moglichst effizient (kostengunstig und schnell) zu nahtlosen Prozessketten und Workflows verbunden werden konnen und ide- aler Weise ohne Medienbruche, sowie - wenn moglich - vollautomatisiert inner- und zwischenbetriebliche Aufgaben unterstutzen [HaLo04, 162f.].

Nach einer Vielzahl entstandener Kopplungsarchitekturen und Technologien zum elekt- ronischen Nachrichten- und Datenaustausch, wie z.B. Component Object Model (COM), Distributed Component Object Model (DCOM), Common Object Request Bro­ker Architecture (CORBA) oder Electronic Data Interchange (EDI) for Administration, Commerce and Transport (EDIFACT) (vgl. [FeSi01, S. 84f.] und [Newc02, S. 32-39]),

ist seit weinigen Jahren ein zunehmender Hype festzustellen, der serviceorientierte Ar- chitektur (SOA) und insbesondere Web Services als eine konkrete Losung adressiert.

Web Services konnen Unterstutzung in vielerlei Hinsicht leisten. Auf der einen Seite konnen sie lokale Konsumentenapplikationen mit im Internet verfugbaren Anwendun- gen verbinden, wie z.B. Reservierungssysteme, Online-Shops, usw. Anderseits sind sie in der Lage, Business-to-Business-Integration (B2B-Integration) zu unterstutzen, wenn sie entlang der Wertschopfungsketten heterogene Anwendungssysteme miteinander koppeln und Kommunikationsmoglichkeiten schaffen. Durch ihre beworbene Einfach- heit und Flexibilitat konnen sie zur Vernetzung von Systemen innerhalb und auBerhalb von Unternehmensgrenzen beitragen (vgl. Enterprise Application Integration, EAI) [Newc02, S.2f.].

Bei der Umsetzung eines solchen Vorhabens sind neben dem Sachziel, das in der Imp- lementierung der Geschaftslogik (Business Logic) liegt, zahlreiche Formalziele mit zu erfullen. Eines von ihnen ist die Forderung nach einer bestimmten Softwarequalitat[1]. Nach dem FURPS-Modell [2] zahlt zu den bestimmenden Faktoren in diesem Zusammen- hang auch die Verlasslichkeit und Robustheit eines Anwendungssystems [GrCa87, S. 159ff.]. Diese Eigenschaft ist im Feld der verteilten, lose gekoppelten Systeme beson- ders wichtig, weil Kommunikationsfehler auftreten und einzelne, autonome Teile des Gesamtsystems unerwartet reagieren oder gar ausfallen konnen.

1.2 Ziele

Im Rahmen der Entwicklung komplexer und unternehmenskritischer Systeme haben sich zwei wichtige Aspekte als entscheidend herausgestellt: die Sicherstellung konsi- stenter Transaktionen innerhalb verteilter Anwendungssysteme und die Kombination mehrerer verteilter Anwendungen zu umfangreichen Prozessen [HaLo04, S. 163]. Mit Letzterem beschaftigen sich so genannte Prozessspezifikationen, die gerade im Umfeld von Web Services zahlreich erschienen sind - sowohl als Standards verabschiedet, oder als proprietare Losungen einzelner Hersteller. Ohne den Anspruch auf Vollstandigkeit sind in diesem Zusammenhang Business Process Specification Schema (BPSS) bei

ebXML3 , Web Services Conversation Language (WSCL) bei HP, Web Services Flow Language (WSFL) bei IBM, Business Process Markup Language (BPML) bei Intalio, XLANG und BizTalk bei Microsoft, Web Services Composite Application Framework (WS-CAF) mit den Bestandteilen Web Services Coordination Framework (WS-CF), Web Services Context (WS-CTX) und Web Services Transaction Management (WS- TXM) von Oracle und Sun, Partner Interface Processes (PIP) bei RosettaNet und Web Services Choreography Interface (WSCI) bei SAP und Sun zu nennen.

Diese Arbeit beschaftigt sich mit dem erst erwahnten Teil - der Sicherstellung konsi- stenter Transaktionen. Ziel ist es, die aktuell etablierten Transaktionsstandards im Be- reich der Web Services zu untersuchen und gegeneinander abzugrenzen. Es werden das Business Transaction Protocol (BTP) von OASIS, das Web Services Composite Application Framework und die Web Service Coordination Specification (WS- Coordination) mit den beiden Spezifikationen Web Services Atomic Transaction (WS- Atomic Transaction) und Web Services Business Activity Framework (WS-Business Activity) betrachtet. Die resultierende Gegenuberstellung kann als eine Entscheidungs- hilfe bei kunftigen Realisierungen transaktionssicherer Web Service-Applikationen die- nen.

1.3 Aufbau der Arbeit

Die nachfolgenden beiden Kapitel 2 und 3 stellen das technologische Umfeld dieser Arbeit vor, und geben eine Einfuhrung in das Konzept der service-orientierten Architek- tur und die Plattform Web Services, als einen konkreten Vertreter derselben. Obwohl in der einschlagigen Literatur nur selten zwischen den beiden Begriffen konsequent diffe- renziert wird, werden sie im Rahmen dieser Arbeit strikt getrennt behandelt, um dem Unterschied zwischen Konzept und Realisierung Rechnung zu tragen. Wahrend sich das Kapitel zwei auf grundlegende, charakteristische Merkmale von SOA konzentriert, und ihre Struktur und den Dienstbegriff in einer allgemeinen Definition zusammenfasst, liefert dazu Kapitel drei konkrete Losungsverfahren und Standards. Den Abschluss die- ser Einfuhrung in die betrachtete Technologie bildet eine Abgrenzung der Web Services von benachbarten Standards.[3]

Das vierte Kapitel beschaftigt sich mit der transaktionssicheren Datenverarbeitung und fasst hierzu die Grundlagen dieses Gebiets - insbesondere vor dem Hintergrund der Nutzung in verteilten Systemen - zusammen. Neben den Bedingungen, die es fur einen transaktionssicheren Betrieb zu erfullen gilt, werden auch entsprechende Losungsver- fahren vorgestellt. Dabei wird der Begriff der Transaktion weiter differenziert und die erlauterten Verfahren kritisch betrachtet.

Im Kapitel funf wird auf Basis der Grundlagen zu Web Service-Technologien, wie auch den methodischen Grundlagen zur Transaktionskoordination aufgebaut, und die derzeit verfugbaren, standardisierten Transaktionsmodelle fur Web Services vorgestellt. Ein- fuhrend wird das abstrakte Konzept des Koordinator-Teilnehmer-Transaktionsmodells erlautert, das allen Modellen gemein ist. Nachfolgend werden drei Transaktionsmodelle vorgestellt, ihr Funktionsumfang beschrieben, sowie ihre jeweiligen Besonderheiten herausgearbeitet. Das Kapitel schlieBt eine verdichtete Gegenuberstellung und Abgren- zung der behandelten Transaktionsmodelle ab, welche gleichzeitig als Entscheidungs- hilfe fur die Auswahl bei kunftiger Entwicklung Web Service-basierter, transaktionssi- cherer Anwendungssysteme dienen kann.

Das sechste Kapitel beendet die Arbeit mit einer abschlieBenden Zusammenfassung und einem Ausblick in die Zukunft.

2 Service-orientierte Architektur

Die service-orientierte Architektur ist ein Architekturkonzept einer Software- Architektur, in dessen Zentrum das Anbieten, Suchen und Nutzen von sog. Diensten (Services) uber ein Netzwerk steht. Als bevorzugter Kommunikationsmechanismus werden derzeit Web Services beworben. Bevor jedoch auf diese konkrete Auspragung naher eingegangen wird, bietet es sich an, das Architekturkonzept an sich vorzustellen.

Im folgenden Kapitel wird das abstrakte und zugleich generische Konzept einer SOA behandelt. Dieses Konzept ist deshalb abstrakt, weil es von konkreten Implementie- rungsdetails zunachst ganzlich unabhangig ist. Der generische Aspekt ist in der Anpass- barkeit an jeweilige Hardware- und Software-Plattformen begrundet.

Nach einem Uberblick der Merkmale einer service-orientierten Architektur, wird diese fur die folgenden Betrachtungen definiert und vereinbart. AnschlieBend wird auf die innere, konzeptuelle Struktur dieser Basisarchitektur mit ihren Rollen eingegangen, ge- folgt von der Begrundung des Dienst-Begriffs.

2.1 Merkmale einer service-orientierten Architektur

Wie bereits einfuhrend erwahnt, handelt es sich bei der SOA nicht um eine konkrete Technik oder Technologie, sondern um ein abstraktes und generisches Architekturkon­zept. Dieses beschreibt und hebt wichtige Aspekte hervor, ohne auf konkrete Realisie- rungsvorschlage Bezug zu nehmen [Dos+05, S. 8]. Weiterhin lasst sich die SOA auf einen bestimmten Kontext so abstimmen und adaptieren, dass die Architektur den An- forderungen der jeweiligen Entwicklungsaufgabe oder technologischen Rahmenbedin- gungen Rechnung tragt. Diese Eigenschaft macht die SOA generisch.

Die wesentlichen Merkmale einer service-orientierten Architektur sind die lose Kopp- lung (Loose Coupling) der Dienste, ihr dynamisches und spates Binden (Dynamic and Late Binding) unter Zuhilfenahme eines Verzeichnisdienstes, die Verwendung von of- fenen Standards und ihre Einfachheit [Dos+05, S. 9ff.]. Die wichtigsten Merkmale sol- len im Folgenden einzeln erlautert werden.

2.1.1 Lose Kopplung

Der Begriff der losen Kopplung von Komponenten bzw. Bestandteilen eines Systems ist keine Erfindung, die im Rahmen von SOA entstanden ware. Sie kommt bereits in den zahlreichen allgemeinen Definitionen von verteilten Systemen vor.[4] Weil die lose Kopplung von Diensten jedoch als Bestandteil einer SOA explizit genannt wird [ChJe03, S. 2], soll an dieser Stelle naher auf sie eingegangen werden.

Die lose Kopplung von Diensten bedeutet, dass Dienste von Anwendungen oder ande- ren Diensten bei Bedarf dynamisch gesucht und angebunden werden [HaLo04, S. 162f.]. Zum Zeitpunkt der Ubersetzung und Bin dung des Programms durfen also die spater zu nutzenden Dienste undefiniert bleiben. Ein wichtiger Vorteil einer solchen losen Kopplung ist die Flexibilitat der Verteilung von Diensten und ihre Migration. Da keine Informationen uber Plattformen, Adressen, Aufrufstrukturen oder gar Implemen- tierung in das Partner-Objektprogramm[5] eingebunden werden, kann ein Umzug des Dienstes, oder sogar seine Reimplementierung fur die umgebenden Systeme transparent vorgenommen werden.

2.1.2 Verzeichnisdienst und dynamische Bindung

Damit ein Dienst von der nutzenden Komponente gerufen werden kann, muss dieser zunachst gefunden und beschrieben werden. Diese Aufgabe ist vergleichbar mit der Suche in den gelben Seiten. Innerhalb der SOA ubernimmt diese Aufgabe ein Verzeich­nisdienst bzw. das so genannte Repository [HaLo04, S. 18].

Zur erfolgreichen Suche eines Dienstes mussen folgende Bedingungen erfullt sein:

- Mindestens eine Instanz des besagten Verzeichnisdienstes muss zugreifbar sein.
- Der Suchende muss sich uber die Kategorisierung des gesuchten Dienstes im Klaren sein.
- Der gesuchte Dienst muss sich zuvor in dem Repository registriert haben.

Damit eine Unabhangigkeit der Bindung von der jeweiligen Programmiersprache oder gar der binaren Implementierung des Dienstes selbst erreicht werden kann, muss eine Entkopplung mittels einer Schnittstellendefinition (Interface Definition) stattfinden. Dies erfolgt mithilfe einer plattform- und programmiersprachenunabhangigen, maschi- nenlesbaren Beschreibung der Schnittstelle bzw. des Services.

Kommunikationspartner sind danach in der Lage, anhand dieser Beschreibung und ggf. dynamisch zur Laufzeit ein sog. Client-Stub6 zu erzeugen, das alle Anfragen entgegen- nimmt und an die Zielressource weiterleitet. Eine beispielhafte service-orientierte Infra- struktur wird in der Abb. 1 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: Registratur und dynamische Bindung über einen Verzeichnisdienst

2.1.3 Offene Standards

Wenn in der IT-Branche und insbesondere in Verbindung mit (Internet-) Technologien von Standards gesprochen wird, sind damit meist die Ergebnisse der Aktivitaten von Gremien gemeint. Oft werden diese Gremien auf Initiative von mehreren, groBen Un- ternehmen gegrundet und unterhalten. Im Unterschied zu Normen, die beispielsweise von der International Organization for Standardization (ISO) oder dem Deutschen Insti- tut fur Normung e. V. (DIN) ist ein Standard nicht bindend. World Wide Web Consorti­um (W3C) spricht von so genannten Empfehlungen (Recommendations) [Dos+05, S. 34f.]. SOA setzt in diesem Zusammenhang auf offene Standards. Das bedeutet, dass zugunsten von hoher Interoperabilitat kostenfreie und frei verfugbare Standards gefor- dert werden.

2.1.4 Einfachheit

Das letzte hier besonders hervorzuhebende Merkmal einer service-orientierten Architek­tur sei die Einfachheit. Obwohl es sich dabei um eine auBerst subjektive Metrik bzw. Beurteilung handelt, so sind sich nahezu alle Autoren der herangezogenen Literatur ei- nig, dass SOA im Vergleich zu den alternativen, konkreten Verteilungsarchitekturen, vergleichsweise einfach ist.7 Diese Einfachheit und darin enthaltene Offenheit bzw. Abstraktheit birgt jedoch auch Gefahren. Dies konnte einer der Grunde dafur gewesen sein, dass SOA bereits seit geraumer Zeit in aller Munde ist, aber ein einheitlicher Be- schreibungsrahmen bis heute fehlt.

2.2 Definition einer service-orientierten Architektur

Obwohl bis heute noch keine allgemeingultige Definition einer service-orientierten Ar- chitektur existiert, besteht unter Fachleuten weitgehend ein Konsens daruber, dass die Interoperabilitat, die lose Kopplung von Anwendungen/Diensten und die Methodik, wie diese gefunden werden, die zentralen Aspekte dieses Architekturentwurfs sind.

Evdemon sieht in SOA ein architekturbezogenes Konzept zum Erstellen von Systemen, die aus autonomen Diensten aufgebaut werden, die in verschiedenen Programmierspra- chen entwickelt und auf verschiedenen Plattformen mit unterschiedlichen Sicherheits- modellen und Geschaftsprozessen gespeichert werden [Evde05].[6]

Dostal, Jeckle, Melzer und Zengler definieren SOA als: „... eine Systemarchitektur, die vielfaltige, verschiedene und eventuell inkompatible Methoden oder Applikationen als wiederverwendbare und offen zugreifbare Dienste reprasentiert und dadurch eine platt- form- und sprachenunabhangige Nutzung und Wiederverwendung ermoglicht“ [Dos+05, S. 11].

Sahai und Graupner schlieBen sich in [SaGr05, S. 28f.] Burbeck [Burb00] an und definieren SOA als: “a specific type of distributed system in which the agents are services. A service is a software agent that performs some well-defined operation (i.e., provides a service) and can be invoked outside of the context of a larger application. That is, while a service might be implemented by exposing a feature of larger application . the users of that server need be concerned only with the interface description of the service. Services have network-addressable interface and communicate via standard protocols and data formats.”

Die Vielzahl der individuellen Definitionen von SOA mit all ihren Uberlappungen und Unterschieden und gleichzeitig ihre Popularitat und Etablissement in der heutigen IT- Welt fuhrten letztendlich im Februar letzten Jahres zur Grundung eines technischen Komitees bei OASIS8 zur Entwicklung eines Referenzmodells - des SOA-RM. Die Mitglieder sind sich einig, dass sich eine vollstandige und korrekte Definition erst aus einem konsolidierten Referenzmodell der service-orientierten Architektur ableiten lasst. Der von OASIS jungste verfugbare Entwurf einer Spezifikation des Referenzmodells fur SOA bezeichnet die service-orientierte Architektur grob als ein Paradigma zur Or­ganisation und Nutzung der Eigenschaften verteilter Systeme zur dezentralen Steuerung durch mehrere autonome Bereiche [Mac+06, S. 8].

2.3 Struktur und Rollen in einer service-orientierten Architektur

Die service-orientierte Architektur legt drei verschiedene Rollen fest [HaLo04, S. 15f.]: den Service Provider als Anbieter eines Services, den Service Requestor als Interessen- ten bzw. Nutzer eines solchen und den Service Broker - einen Verzeichnisdienst, der als Vermittler zwischen den beiden anderen agiert. Provider und Requestor sind somit nicht[7]

statisch miteinander verbunden, sondern werden mithilfe des Brokers dynamisch zu- sammengefuhrt.

Der Interaktionsprozess bei der Nutzung eines Services erfolgt in vier Phasen, wobei die drei Rollen dabei wie folgt zusammenspielen [GlaB03, S. 162f.]:

1. Service Provider, der einen Service anbietet, registriert diesen beim Service Broker (veroffentlichen, publish).
2. Ein Service Requestor sucht bei einem Verzeichnisdienst (Service Broker) nach einem Service mit den gewunschten Eigenschaften (auffinden, find).
3. Service Requestor fordert an und erhalt nach einer erfolgreichen Suche eine de- taillierte Beschreibung des Services, die eine vollstandige Spezifikation seiner Schnittstellen enthalt.
4. Uber ein lokales Interface - den sog. Client-Proxy bzw. Stub - wendet sich der Service Requestor an den Service Provider zur Nutzung des Services (binden, bind).

Das Zusammenwirken der eingefuhrten Rollen wird in der Abb. 2 zur Veranschauli- chung nochmals graphisch dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Zusammenspiel der Rollen einer SOA (Vgl. [Dus+03])

2.4 Dienste

Dienste bzw. Services sind in diesem Kontext allgemein gesprochen Funktionen von Anwendungssystemen, die uber Schnittstellen der AuBenwelt verfugbar gemacht wer­den. GemaB diesen Schnittstellen kann auf die Systeme lokal oder uber das Netzwerk von anderen Knoten zugegriffen werden. Damit dieser Zugriff automatisiert erfolgen kann, muss die Beschreibung der Dienste in maschinenlesbarer Form vorliegen. Durch diese Kapselung wird das Geheimnisprinzip[9] (Information Hiding) umgesetzt.

Ob sich also hinter einem Service eine Klasse oder Methode im Sinne der Objektorien- tierung (OO), eine Komponente oder gar ein ganzes (Teil-) Anwendungssystem ver- birgt, ist nach auBen nicht sichtbar und die Kenntnis daruber fur die Nutzung des Diens- tes auch nicht erforderlich. Gleiches gilt fur die Implementierungsdetails, wie Angaben zur Plattform oder Programmiersprache.

Die maschinenlesbare Dienstbeschreibung (Service Description) sollte selbst von einer spezifischen Programmiersprache oder Plattform unabhangig sein. Die meisten der vor- liegenden Implementierungen der Schnittstellenbeschreibungssprachen (sog. Interface Definition Language, IDL) schaffen es, die funktionalen Eigenschaften eines Dienstes hinreichend zu beschreiben.

Neben ihnen gibt es jedoch auch nicht nichtfunktionale Anforderungen, die den Dienst- nutzer oft interessieren. Dazu gehoren zum Beispiel Angaben uber Antwortzeiten, Ver- fugbarkeit und Kosten der Nutzung. Diese Klasse von Beschreibungen lasst sich unter dem Begriff Quality of Service (QoS) zusammenfassen. Die ersten Umsetzungen zur Beschreibung von nichtfunktionalen Anforderungen befinden sich derzeit noch in Ent- wicklung [Dos+05, S. 13].

Nachdem in diesem Kapitel die service-orientierte Architektur als ein abstraktes und zugleich generisches Architekturkonzept eingefuhrt und vorgestellt wurde, widmet sich das nachfolgende Kapitel einer konkreten Implementierung desselben - den Web Servi­ces.

3 Web Services

Wie bereits einfuhrend erwahnt, handelt es sich bei Web Services um eine konkrete Implement! erung einer service-orientierten Architektur. In der Literatur [HaLo04, S. 15f.] wird haufig der Ursprung - respektive die Idee - von Web Services in der von Hewlett-Packard (HP) im Jahre 1999 vorgestellten Web-Plattform namens e-Speak ge- funden. E-Speak folgte bereits zum damaligen Zeitpunkt dem service-orientierten An- satz, konnte sich jedoch am Markt nicht etablieren. Das Scheitern dieser Technologie wird dem unzureichenden Marketing von HP zugeschrieben (vgl. [HaLo04, S. 15]).

Das vorliegende Kapitel stellt die Architektur von Web Services vor und beschreibt die wesentlichen Techniken und Standards in diesem Zusammenhang. Den Abschluss bil- det eine uberblickartige Abgrenzung der Web Services von anderen bekannten, verteil- ten Software-Architekturen.

3.1 Charakteristische Merkmale der Web-Service-Plattform

In der Struktur von Web Services konnen die bereits aus dem SOA Ansatz bekannten Rollen mit ihren Funktionen wieder gefunden werden. Im Gegensatz zum abstrakten und generischen SOA-Konzept konnen jedoch an dieser Stelle konkrete Losungsverfah- ren und Technologien benannt werden, wie dies in der Abb. 3 grob dargestellt wird. In den folgenden Unterkapiteln werden nun die, im Bereich von Web Services herrschen- den Standards vorgestellt und damit die charakteristischen Merkmale von Web Services beschrieben.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3: Rollen einer SOA im Kontext von Web Services

3.1.1 Web Service-Protokoll-Stack

Ob sich eine Technologie und/oder ihre Architektur in der Praxis bewahrt und etabliert hangt nicht nur von ihrer Machtigkeit und ihrem Funktionsumfang, sondern auch zum GroBteil davon ab, ob sich ein oder mehrere groBe Softwarehersteller entschlieBen, die- se aktiv und in einem angemessenen Rahmen zu vermarkten und einzusetzen. Findet sich eine entsprechende Anhangerschaft und bewahrt sich die Technologie auch prak- tisch am Markt, ohne kurz danach verdrangt zu werden, kann bei einer gegebenen For- malisierung von einem so genannten Standard gesprochen werden [Wiki06b].

Auch Web Services, die mittlerweile vom W3C koordiniert werden, basieren auf eini- gen Standards, die sich in einer Protokollhierarchie formieren - dem so genannten Web Service-Protokoll-Stack [Newc02, S. 22-41].

Den einzelnen Schichten dieses Protokoll-Stacks fallen dabei folgende Aufgaben zu:[10]

- Hypertext Transfer Protocol (HTTP) basierend auf TCP/IP stellt die Kommuni- kationsinfrastruktur dar[11].
- SOAP (mittlerweile ein eigener Name; ehemals die Kurzform fur Simple Object Access Protocol) ermoglicht das Versenden von Funktions- bzw. Methodenauf- rufen und Nachrichten im XML-Format.
- Web Service Description Language (WSDL) dient zur funktionalen Spezifikati- on der Schnittstellen eines Web Services.
- Universal Description, Discovery & Integration (UDDI) ist ein Verzeichnispro- tokoll zur Verwaltung von Web Services, um ihre Publikation und Suche zu er- moglichen.
- Business Process Execution Language (BPEL) ist eine Technologie, die eine Modellierung von Geschaftsprozessen mittels lose gekoppelter Web Services ermoglicht - die so genannte Web Service Orchestration.

Einige typische Technologien sollen im Folgenden uber ihre ubersichtartige Vorstellung hinaus genauer betrachtet werden.

3.1.2 Web Service Description Language

Web Service Description Language stellt eine Basistechnologie zur Entwicklung von Web Services dar. Sie spezifiziert einen Rahmen fur die Beschreibung von Web Servi­ces mittels einer XML-Grammatik (vgl. [NuMi02]). WSDL entstand auf Initiative der Firmen IBM, Microsoft und Ariba und wurde von W3C standardisiert [Lang03, S. 168f.]12. Als Basis dienten die beiden Meta-Beschreibungssprachen Network Accessible Service Specification Language (NASSL) von IBM und SOAP Contract Language (SCL) von Microsoft [HeZe03, S. 164f.].

Diese programmiersprachenunabhangige und zugleich standardisierte Beschreibungs- sprache schafft eine Entkopplung von konkreten Basismaschinen[13], wie Programmier- sprachen und Protokollen. Durch ihre Maschinenlesbarkeit dient sie zur Automatisie- rung der Kommunikation zwischen Anwendungen. Das Pendant zu WSDL ist auf der Seite der CORBA-Technologie die CORBA-IDL[14]. Beide dienen sie dazu, Schnittstel- len und Datentypen fur ein diskretes Stuck Programmierlogik zu definieren (vgl. dazu Abb. 4).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 4: Pendants IDL und WSDL

Abbildung in dieser Leseprobe nicht enthalten

Abb. 5: Struktur einer WSDL-Datei

Wie in der obigen Abbildung Abb. 5 dargestellt, wird ein WSDL-Dokument in folgende Bereiche strukturiert [Chr+01]:

- Das Element <definitions> in einer WSDL-Datei dient als Container fur eine Dienstbeschreibung.
- Das <types>-Element dient als Container zur Definition von Datentypen, die in <message>-Elementen verwendet werden.
- Das <message>-Element definiert das Format der Nachrichten, die zwischen Web Service-Requestor und Web Service Provider bei der Nutzung des Web Service ausgetauscht werden.
- Das Element <portType> beschreibt eine Teilmenge von Operationen, die von einem Endpunkt eines Web Services unterstutzt werden. Das Element <operati­on> stellt eine solche Operation dar.
- Ein <binding>-Element ist ein konkretes Protokoll- und eine Datenformatsspezi- fikation fur ein <portType>-Element. Es konnen sowohl standardisierte Bin- dungserweiterungen HTTP, SOAP oder MIME, wie auch eigene Erweiterungen genutzt werden.
- Das Element <service> identifiziert einen Web Service. Ein Web Service ist ei- ne Sammlung eines oder mehrerer <port>-Elemente. Ein <port>-Element stellt einen einzelnen Endpunkt des Web Service dar.

Ein beispielhaftes WSDL-Dokument ist im Anhang (A2) zu finden.

3.1.3 SOAP

Das Kommunikationsprotokoll von Web Services heiBt SOAP [Gud+03]. Es spezifiziert das Nachrichtenformat, in dem, zwischen mittels Web Service Technologie verbunde- nen Systemen, Informationen ausgetauscht werden. Ursprunglich stand SOAP fur eine Abkurzung des auf XML basierenden Simple Object Access Protocol, das von der Fir- ma Microsoft fur entfernte Prozeduraufrufe (Remote Procedure Call, RPC) entwickelt wurde. Zur Version SOAP 1.1 schlossen sich Ariba, IBM und Microsoft zu seiner Wei- terentwicklung zusammen, woraufhin das Protokoll schnell an Unterstutzung wichtiger Anbieter im Bereich von Web Services gewann. SOAP 1.2 wurde schlieBlich im Juni 2003 vom W3C als „Recommendation“ verabschiedet.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 6: Struktur einer SOAP-Nachricht

Um ein allgemeines und flexibles Protokoll fur einen XML basierten Nachrichtenaus- tausch zu schaffen, reguliert die SOAP Spezifikation[15]:

- Den sog. SOAP Envelope (zu deutsch Umschlag), welches das gesamte zur U- bertragung bestimmte XML-Dokument einschlieBt (vgl. Abb. 6),
- Die Form, wie optionale Header zur Ubertragung von fur den Transport relevan- ten Zusatzinformationen, wie z.B. Angaben zur Rechteverwaltung oder Koordi- nation von Transaktionen,
- Die Art und Weise, wie Daten und zugehorige Datentypen serialisiert werden und
- Die Bindung, um den ordnungsgemaBen Informationsaustausch sicherzustellen.

SOAP ist ein Kommunikationsprotokoll. Seine Spezifikation umfasst den Nachrichten- transport nicht, sondern beinhaltet lediglich die so genannte Bindung (Binding). Eine Bindung legt fest, wie SOAP-Nachrichten mithilfe eines entsprechenden Transportpro- tokolls ubertragen werden sollen. Aufgrund dieser Trennung kann fur den Nachrichten- transport ein geeignetes Protokoll separat ausgewahlt werden, oder gar mehrere Trans- portprotokolle parallel angeboten werden. Dabei sind sowohl synchrone, wie auch a- synchrone Protokolle denkbar.[16] Meistens kommt dabei HTTP(S/R) zum Einsatz, je nach Anwendung ist aber beispielsweise auch das Simple Mail Transfer Protocol (SMTP) oder das File Transfer Protocol (FTP) moglich. Nach seiner Standardisierung existieren mehrere Implementierungen von SOAP fur alle gangigen Plattformen und Programmiersprachen [Engl02, S. 6f.]. Knuth spricht in [Knut02, S. 71] von einer nahe- zu hundertprozentigen Abdeckung.

3.1.4 Verzeichnisdienste von Web Services

Als ein wesentlicher Bestandteil der service-orientierten Architektur wurde bereits der Verzeichnisdienst eingefuhrt, der eine dynamische Bindung ermoglichen soll. Im Fol- genden sollen drei Moglichkeiten vorgestellt werden, wie im Kontext von Web Services und mit Hilfe welcher Technologien diese Laufzeitbindung erfolgen kann.

Web Service Inspection Language

Ist dem Web Service Requestor die Adresse des Web Service Providers bekannt, kann er sich direkt an diesen wenden und mittels Web Service Inspection Language (WSIL) die Beschreibung aller von ihm angebotenen Web Services beziehen [Newc02, S. 240f.]. Hierzu muss am Server eine Datei namens inspection.wsil zur Verfugung gestellt werden, die eine adaquate Beschreibung der angebotenen Web Services beinhaltet

[SaGr05, S. 22f.]. Es handelt sich dabei um ein XML-Dokument, dessen Struktur durch die WSIL vereinbart wird.

DISCO

Die im Jahre 1999 von Microsoft publizierte Spezifikation DISCO stellt eine proprietare Variante eines Verzeichnisdienstes fur Web Services, deren Relevanz immer weiter abnimmt. Im Mittelpunkt des Konzepts von DISCO stehen zwei einander erganzende XML-Dokumente. Wahrend das WSDL-Dokument die verfugbaren Methoden und Nachrichtenformate eines Web Services beschreibt, konnen im korrespondierenden DISCO-Dokument Informationen hinterlegt werden, die uber die Funktionalitat Auf- schluss geben, die sich hinter einem bestimmten Methodennamen verbirgt [HaLo04, S.94-98].

Universal Description, Discovery & Integration

Wie bereits festgestellt, findet man in der SOA neben dem Anbieter und Nutzer eines Service noch die Rolle des Service Brokers. Im Kontext von Web Services wird dieser haufig auch als UDDI-Registry bezeichnet, benannt nach der gleichnamigen Spezifika­tion UDDI, die fur Universal Description, Discovery and Integration steht. Die UDDI besteht aus vier Hauptspezifikationen [Lang03, S.352-358]17:

- Die Datenstruktur (vgl. dazu [Rieg02])
- Die API-Spezifikationen (vgl. dazu [Bell02])
- Die Replikationsspezifikation (vgl. dazu [Clem02a])
- Die Spezifikation fur Registry-Anbieter (vgl. dazu [Clem02b])

In einer UDDI-Registry konnen drei verschiedene Informationstypen abgelegt, respek- tive veroffentlicht werden [Newc02, S. 157f.]:

- White Pages - Informationen uber Unternehmen und Kontaktpersonen
- Yellow Pages - Beschreibungen von Taxonomien der angebotenen Web Servi­ces
- Green Pages - technische Informationen der Web Services[16]

Eine offentliche UDDI-Registry wird im Internet von den groBen Initiatoren IBM, Microsoft, Hewlett Packard und SAP betrieben. Analog dem Domain Name Service (DNS) konnen jedoch weitere UDDI-Knoten an diesem Netzwerk teilnehmen (vgl. [Bad+03, S. 60-64]).

Die Inhalte werden zwischen den einzelnen Knoten repliziert. Dadurch kann ein Web Service auch dann gefunden werden, wenn einer oder mehrere Broker-Knoten ausfallen. Neben der offentlichen Nutzung ist ebenfalls ein lokaler, oft auch als privat bezeichne- ter Betrieb einer UDDI-Registry denkbar. Dies ist insbesondere dann sinnvoll, wenn die so veroffentlichten Web Services auch (ggf. spater) einem breiteren Interessentenkreis angeboten werden sollen, wie z.B. Lieferanten, Kunden oder Geschaftspartnern [Newc02, S. 183f.].

3.1.5 Web Services Orchestration

Geschaftsprozesse lassen sich nur selten in Form einer einzigen Aktivitat darstellen und realisieren. Oft ist es vielmehr sinnvoll, Einzelvorfalle granular zu betrachten, damit das Zusammenspiel der Aktivitaten insgesamt flexibler gestaltet werden kann und im Rah- men von Wiederverwendung Synergieeffekte erzielt werden konnen [Newc02, S.230].

Im Kontext von Web Services spricht man bei der Verknupfung von modularen WS- Aktivitaten von der Web Services Choreographie oder Orchestration. Auch an dieser Stelle lasst sich eine Standardisierung feststellen. Durch Konsolidierung der individuel- len Technologien und Implementierungen, wie z.B. Web Services Flow Language (WSFL) von IBM oder XLANG von Microsoft, entstand die Business Process Executi­on Language (BPEL oder auch BPEL4WS) [And+03], mit deren Hilfe auch komplexe

und langlaufige Geschaftsprozesse abgebildet werden konnen [SaGr05, S. 23f.]18.

3.2 Einordnung und Abgrenzung von Web Services

Die Web Service-Architektur ist nicht die erste Umsetzung einer service-orientierten Architektur. Bereits vor dem Aufkommen von Web Services existierten Konzepte, die ahnliche Probleme adressierten und zumindest in der Theorie auch erfolgreich gelost[17] haben. Ohne Anspruch auf eine vollstandige Aufzahlung sind als bekannteste Konzepte zu nennen:

- COM/DCOM von Microsoft (vgl. dazu [Ewal01] und [HoKi97])
- RMI von Sun Microsystems
- Jini von Sun Microsystems (vgl. dazu [BaHu00] und [Sun04])
- CORBA von der Object Management Group (OMG) (vgl. dazu [Sieg96])

Nicht alle der genannten Konzepte bzw. Technologien folgen den Ideen und erfullen alle Eigenschaften einer service-orientierten Architektur. Aufgrund der Absenz einer eindeutigen und klaren Definition der service-orientierten Architektur ist es ohnehin noch problematisch, uber Zugehorigkeit zu dieser Klasse zu bestimmen. Ihnen gemein ist jedoch, der Klasse der Middleware anzugehoren.

In der nachfolgenden Tabelle (Tab. 1) werden die gelaufigen Verteilungsplattformen und ihre Technologien grob gegenuber gestellt. Neben einem Uberblick soll damit eine klare Einordnung der Web Services in die Klasse der Middleware Architekturen ermog- licht und eine technologische Abgrenzung zu alternativen Technologien vereinfacht werden. Obwohl lediglich CORBA[19] als vergleichbar plattformunabhangig gilt, sollen einige der genannten Architekturen nebeneinander betrachtet werden. Sie versuchen vergleichbare Aufgabenstellungen zu losen, sodass mit ihnen interessante Parallelen aufgezeigt und die wesentlichen Unterschiede veranschaulicht werden konnen.

Abbildung in dieser Leseprobe nicht enthalten[20][21]

Tab. 1: Gegenuberstellung gelaufiger Verteilungsplattformen

4 Grundlagen transaktionssicherer Verarbeitung

Ein Anwendungssystem wird als transaktionssicher oder transaktionsorientiert bezeich- net, wenn die durch jenes System durchgefuhrte Verarbeitung stets im Rahmen von so genannten Transaktionen erfolgt [KeEi04, S. 265f.]. Eine Transaktion ist im Allgemei- nen als eine atomare und isolierte Folge von Operationen definiert, die einen konsisten- ten Zustand einer persistenten Datenbasis in einen wiederum konsistenten Zustand uber- fuhrt [VoHo90, S. 3]. Sie tragt somit das Pradikat konsistenzerhaltend. Der Begriff der Konsistenz wird in der herangezogenen Literatur nicht einheitlich definiert. Jedoch dru- cken alle Definitionen sinngemaB aus, dass es sich bei einem konsistenten Zustand um eine wohldefinierte, vollstandige und korrekte Abbildung des betrachteten Ausschnitts eines Referenzsystems handelt [VoHo90, S. 2f.]. Auf ein betriebliches Anwendungssys­tem bezogen, ist dies also ein Zustand, der ein Stuck des betrachteten, betrieblichen In- formationssystems22 wahrheitsgemaB abbildet.

Die folgenden Abschnitte erklaren die wichtigsten Begriffe und Konzepte im Zusam- menhang mit Transaktionen. Je nach Betrachtungsweise und Anwendungsbereich lasst sich der Begriff einer Transaktion, seine Eigenschaften und die damit verbundenen An- forderungen unterschiedlich auslegen, oder es konnen vielmehr verschiedene Arten von Transaktionen identifiziert werden. Die Klassifikation und die Betrachtung der Transak- tionsklassen konnen je nach Fokus variieren. Als haufigste Klassifikationen konnen in der Literatur gefunden werden:

- Einfache Transaktionen vs. zusammengesetzte/komplexe Transaktionen
- Softwaretechnische Transaktionen vs. betriebliche Transaktionen [FeSi04, S. 5,6]
- Lokale/zentralisierte Transaktionen vs. verteilte Transaktionen
- Flache/atomare Transaktionen vs. mehrschichtige/hierarchische/geschachtelte Transaktionen
- ACID-Transaktionen vs. Business-Transaktionen

Im Folgenden sollen die beiden Arten ACID-Transaktionen und Business- Transaktionen naher erlautert und gegeneinander abgegrenzt werden. Die Klasse der ACID-Transaktionen kann als die Teilmenge softwaretechnischer Transaktionen ver- standen werden, welche die nachfolgend erlauterten ACID-Eigenschaften erfullen. Fur die Durchfuhrung von Business-Transaktionen muss das ACID-Prinzip jedoch aus Praktikabilitatsgrunden meistens eingeschrankt werden [ScRe96, S. 336ff.], obwohl die Anforderungen an ein konsistentes Transaktionsergebnis (Outcome) ebenso gefordert sind.

Gleichzeitig wird auf die zu dieser Abgrenzung orthogonale Klassifikation von Transak­tionen in lokale/zentralisierte Transaktionen und verteilte Transaktionen eingegangen. Die Berucksichtigung dieser weiteren Unterscheidung ist notwendig. Wahrend ACID- Transaktionen in beiden letztgenannten Arten nicht nur sichergestellt werden konnen, sondern aufgrund zunehmender Systemverteilung bereits erfolgreich praktiziert werden, geht man im Rahmen von Business-Transaktionen immer von einem verteilten Szenario aus. Dies ist insbesondere bei der transaktionssicheren Systemkopplung via Web Servi­ces immer der Fall.

4.1 ACID-Transaktionen

Zu der Klasse von ACID-Transaktionen gehoren diejenigen Transaktionen, welche die Eigenschaften Atomizitat, Konsistenz, Isolation und Dauerhaftigkeit (Persistenz) besit- zen [KuHs96, S. 3]. Der Begriff ACID zur Charakterisierung von Transaktionen geht auf Harder und Reuter zuruck, deren formale Betrachtung auch fur die Transaktions- Recovery wegweisend war [HaRe83]. Diese essentiellen Eigenschaften der Transakti- onsverarbeitung werden nachfolgend im Detail betrachtet. Im Anschluss darauf wird auf die methodischen Grundlagen der Serialisierbarkeit von Ausfuhrungsplanen eingegan­gen und Mechanismen zu ihrer Erzeugung vorgestellt. Aufgrund der Themenstellung der zugrunde liegenden Arbeit werden abschlieBend einfache und verteilte Transaktio­nen differenziert.

Atomizitat (Atomicity)

Eine Transaktion ist nicht unterbrechbar bzw. teilbar und wird demzufolge atomar aus- gefuhrt. Dies bedeutet, dass eine ACID-Transaktion nach dem Alles-oder-nichts-Prinzip durchgefuhrt wird [HaRe83, S. 289]. Wenn nicht alle Operationen der Transaktion er- folgreich ausgefuhrt werden konnen, werden sie allesamt zuruckgenommen und damit die gesamte Transaktion zuruckgerollt. Der Zustand des Systems nach einer zuruckge- rollten Transaktion ist jener, als hatte keinerlei Aktion stattgefunden. Dies ist die we- sentliche Voraussetzung dafur, dass konsistente Zustandsubergange erreicht werden.

Konsistenz (Consistency)

Diese Eigenschaft besagt, dass eine Transaktion die vorhandenen Konsistenzregeln ein- zuhalten hat und somit den konsistenten Zustand eines Anwendungssystems wahrt [HaRe83, S. 289f.]. Zwischenzustande, die wahrend der Transaktionsverarbeitung ent- stehen, durfen zwar inkonsistent sein, der resultierende Endzustand muss jedoch die vereinbarten Konsistenzbedingungen (wie z.B. referentielle Integritat bei Datenbanken) erfullen.

Isolation (Isolation)

Unabhangig davon, ob eine Datenbasis zentral oder verteilt ist, kann im Allgemeinen davon ausgegangen werden, dass ihre Instanzen mehrere Benutzer bedienen mussen. Gleichzeitig kann ein Client im Rahmen einer Client/Server-Architektur auch mehrere Transaktionen zur gleichen Zeit ausfuhren. Somit wurde eine serielle Ausfuhrung von Transaktionen auf der Serverseite die Leistungsfahigkeit eines Anwendungssystems stark beeintrachtigen. Schlechte Verfugbarkeit des Systems mit unverhaltnismaBig lan- gen Wartezeiten, sowie in der Konsequenz ein niedriger Durchsatz waren die Folgen [KeEi04, S. 295]. Der erforderliche Mehrbenutzerbetrieb auf der Seite des betrieblichen Backendsystems, der zu einer besseren Auslastung des Systems fuhrt, muss jedoch ko- ordiniert werden, damit sich die zeitlich uberlappenden, parallelen Transaktionen nicht storend beeinflussen [HaRe83, S. 290]. Zu bekannten Anomalien im unkoordinierten Mehrbenutzerbetrieb zahlen verloren gegangene Anderungen (Lost Updates) [Chry96,

S. 9f], der Zugriff auf inkonsistente Daten (Dirty Read / Dirty Write, bzw. Inconsistent Retrieval) [Chry96, 10f.], nicht reproduzierbares Lesen (Non-repeatable Read) und schlieBlich das Phantomproblem [Ber+87, 64-66]. Die Eigenschaft der Isolation stellt sicher, dass alle Transaktionen in Form eines logischen Einbenutzerbetriebs ohne ge- genseitige Beeinflussung ablaufen konnen.

Dauerhaftigkeit (Durability)

Nach dem erfolgreichen Ende einer Transaktion sind die resultierenden Zustandsande- rungen dauerhaft gespeichert und gehen durch mogliche nachfolgende Fehler nicht ver- loren [HaRe83, S. 290]. Ebenso lassen sich Operationen einer abgeschlossenen Trans­aktion von keinem Teilnehmer zurucksetzen. Trotz einer so genannten Kompensations- operation, die zum Ziel hat, den semantischen Zustand vor einer Transaktion wieder herzustellen, ist der resultierende Zustand ein anderer. Dieses Verhalten lasst sich in gewisser Weise mit dem in der Buchfuhrung vergleichen. Obwohl eine Stornobuchung zur Aufgabe hat, die Urbuchung fachlich zu neutralisieren, bleiben beide Buchungen in den Buchern verzeichnet. Der Zustand des (Buchungs-) Systems ist damit ein anderer, als vor ihrer Ausfuhrung.

4.1.1 Serialisierbarkeit von Ausfuhrungsplanen

Wie Transaktionen nebenlaufig und ohne gegenseitige, storende Beeinflussung von ei­ner Instanz durchfuhrt werden konnen, wird im Konzept der Serialisierbarkeit von Aus­fuhrungsplanen (in der Literatur auch als Ablaufplane oder Historien bezeichnet [KeEi04, S.304]) methodisch behandelt. Als Ausfuhrungsplan (Schedule) fur eine Men- ge von Transaktionen wird die zeitliche Reihenfolge der Abarbeitung ihrer einzelnen Operationen bezeichnet. Sei eine Menge von Transaktionen {Ti, ..., Tn} mit Operatio­nen {O(Ti)i, ..., O(Ti)m}, so entsteht der Ausfuhrungsplan S mit {O1, ... Oz} durch das Mischen der Operationen O(Ti)j, wobei die Reihenfolge der Operationen innerhalb der jeweiligen Transaktion beibehalten wird. Es konnen folgende Klassen von Ausfuh­rungsplanen unterschieden werden [KeEi04, S. 301-305]:

Serieller Ausfuhrungsplan

Ein serieller Ausfuhrungsplan ist ein Schedule Sseriell von {T1, ., Tn}, in dem die Akti- onen der einzelnen Transaktionen nicht untereinander vermischt, sondern in Blocken hintereinander ausgefuhrt werden. Die Transaktionen werden demnach ohne zeitliche Uberlappung mit anderen Transaktionen nacheinander ausgefuhrt. Dieser Ansatz garan- tiert die Wahrung der Isolation, indem er die Nebenlaufigkeit verhindert. Wie bereits erwahnt ist jedoch diese Strategie aufgrund von Performanzgesichtspunkten in der Pra­xis allgemein kaum anwendbar.

Serialisierbarer Ausfuhrungsplan

Ein Ausfuhrungsplan Sserialisierbar der Transaktionen {Ti, ..., Tn} heiBt serialisierbar, wenn mindestens ein serieller Ausfuhrungsplan Sseriell existiert, der dasselbe globale Transaktionsergebnis in Form eines Systemzustands und dieselbe externe Wirkung er- zeugt. Liegt ein serialisierbarer Ausfuhrungsplan von Transaktionen vor, erfolgen die Operationen der nebenlaufigen Transaktionen ohne storende Beeinflussung. Diese Ko- ordination ist fur den Benutzer transparent und erscheint nach auBen hin, als ob die ein- zelnen Transaktionen in einer beliebigen Reihenfolge, jedoch nacheinander ausgefuhrt worden waren.

Mit Hilfe von Abhangigkeitsgraphen (in der Literatur oft auch als Serialisie- rungsgraphen bezeichnet) kann die Serialisierbarkeit eines beliebigen Ausfuhrungsplans nachgewiesen werden. Die beteiligten Transaktionen T1, ..., Tn bilden die Knoten des Graphen. Als Kanten werden die Abhangigkeiten zwischen ihnen dargestellt (Schreib- Lese-Abhangigkeiten, Lese-Schreib-Abhangigkeiten und Schreib-Schreib- Abhangigkeiten). Ein Ausfuhrungsplan ist serialisierbar, wenn der korrespondierende Abhangigkeitsgraph zyklenfrei ist. Einen zugehorigen seriellen Ausfuhrungsplan erhalt man schlieBlich durch topologisches Sortieren des Graphen.

4.1.2 Techniken zur Synchronisation

Der Aufwand fur die Verwaltung von im letzten Abschnitt erwahnten Abhangigkeits­graphen ist in der Praxis oft zu hoch. Es wurden deshalb alternative Verfahren entwi- ckelt, um die Serialisierbarkeit von Ausfuhrungsplanen zu gewahrleisten. Sie konnen anhand ihrer Strategie grob in zwei Klassen eingeteilt werden. Man unterscheidet pra- ventive Verfahren (auch pessimistisch genannt) und verifizierende Verfahren (auch op- timistisch genannt) [Agr+96, S. 61]. Beide Typen von Synchronisationsverfahren sollen im Folgenden kurz vorgestellt werden23.

4.1.2.1 Preventive Synchronisationsverfahren

Die Strategie der praventiven Synchronisationsverfahren folgt der Idee des Vorbeugens von Konsistenzverletzungen. Sie werden auch als pessimistische Verfahren bezeichnet. Ein Strom von Aktionsaufforderungen wird vom Koordinator (Scheduler) beobachtet,

23 Neben dieser groben Kategorisierung wird in der Fachliteratur noch feiner anhand bestimmten Verhal- tens unterschieden und z.B. das Immediate-Restart-Verfahren als eine Erweiterung von Sperrverfahren identifiziert (vgl. dazu [Agr+96, S. 61]).

der dann eingreift, sobald aus Sicht des Synchronisationsverfahrens zu einem spateren Zeitpunkt eine Konsistenzverletzung moglich werden konnte. Zu diesem Bereich zahlen insbesondere die im Datenbankumfeld etablierten Sperrverfahren [Ber+87, S. 49] und Zeitstempelverfahren [PeBr87, S. 22], die speziell im Bereich von verteilten Datenban- ken untersucht werden.

Das zentrale Element von Sperrverfahren ist die Sperre (Lock). Eine Sperre ist ein Zugriffsrecht R, welches eine Transaktion T bezuglich eines Datenobjekts O besitzt. Eine Transaktion fordert beim Sperrverwalter (Lock-Manager) mit der Operation lock(O) eine Sperre an, fuhrt die Operationen durch und gibt mit unlock(O) diese Sperre wieder frei. Der Sperrverwalter fuhrt eine Sperrtabelle mit den aktuell vergebenen Sper- ren. Eine neue Sperre wird nur dann gewahrt, wenn die Vergabe mit den bereits existie- renden Sperren vertraglich ist [Ber+87, S. 49]. Eine Transaktion kann auf einem Daten- objekt nur dann eine Operation durchfuhren, wenn vorher eine entsprechende Sperre gewahrt worden ist. Nach dem letzten Zugriff auf das Datenobjekt, spatestens bei Tran- saktionsende, wird die Sperre freigegeben. Wird die Sperre auf eine benotigte Ressour- ce vom Sperrverwalter nicht gewahrt, muss die Transaktion warten. Dieses blockierende Verhalten fuhrt dazu, dass so genannte Verklemmungen (Dead Locks) entstehen konnen [Ber+87, S. 56ff.].

Die nachfolgende Tabelle (Tab. 2) veranschaulicht, wie zwei nebenlaufige Transaktio- nen Ti und T2, die jeweils Sperren auf die Ressourcen a und b anfordern in einer Ver- klemmung resultieren. Bei diesem Beispiel wird von einem Sperrtyp ausgegangen der die Zustande NL = nicht gesperrt (Not Locked) und L = gesperrt (Locked) annehmen kann. Die Sperre darf dabei exklusiv nur einer Transaktion gewahrt werden.

Abbildung in dieser Leseprobe nicht enthalten

Tab. 2: Verklemmung von zwei Transaktionen

[...]


[1] Die Softwarequalitat wird nach DIN ISO 9126: 1991 wie folgt definiert: „Die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordenisse zu erfullen“

[2] FURPS ist ein Akronym fur Functionality, Usability, Reliability, Performance und Supportability.

[3] ebXML ist eine 1999 gestartete, gemeinsame Initiative von UN/CEFACT und OASIS.

[4] Ferstl und Sinz schlieBen sich in [FeSi01, S. 202] Enslow an und spezifizieren ein verteiltes System als ein integriertes System, dessen Komponenten miteinander lose gekoppelt sind und uber den Austausch von Nachrichten bei Verfolgung gemeinsamer Ziele kooperieren.

[5] Als Objekt-Programm (Object Program) wird dasjenige Programm bezeichnet, das durch ein Uberset- zungsprogramm (Compiler) aus dem Quellprogramm (Source Program) als Ergebnis der Ubersetzung erzeugt wird [StHa05, S. 83]. Unabhangig davon, ob das Programm im sog. Byte-Code vorliegt oder im Maschinen-Code, ist eine Anderung in dieser Form nicht ohne weiteres moglich.

6 Ein Stub (aus dem Englischen stub für „Stubben“, „Stummel“, „Stumpf“) bezeichnet in der Softwareentwicklung einen Programmcode, der entsprechend dem Entwurfsmuster „Stellvertreter“ (proxy) anstelle eines anderen Programmcodes steht. Insbesondere im Umfeld von verteilten Systemen kommen Stubs häufig zur Anwendung. Funktionalität eines entfernten, über ein Netzwerk erreichbaren, Softwaresystems wird auf einem anderen System in Form eines Stubs zur Verfügung gestellt (vgl. [Ewal01, S. 26f.] und [GrTh00, S. 63]). Dieses Client-Stub kann von der Software so angesprochen werden, so als wäre die Funktionalität des entfernten Systems lokal vorhanden. Statt die Funktionen tatsächlich zu implementieren, übersetzt das Client-Stub die Anfragen in Netzwerkaufrufe, kommuniziert mit dem entfernten System und delegiert die Aktionen an dieses. Für das nutzende System bleibt dieser Kommunikationsvorgang verborgen (vgl. Ortstransparenz [GrTh00, S. 10f.]).

[7] Gerne wird beispielsweise SOA und CORBA gegenubergestellt und dabei auf die Komplexitat von CORBA hingedeutet [Dos+05, S. 9f.].

[8] OASIS - Organization for the Advancement of Structured Information Standards - sieht sich als interna­tional non-profit Konsortium fur die Entwicklung, Vereinheitlichung und Anpassung von Standards im e-Business. Seit der Grundung im Jahre 1993 zahlt es heute uber 5000 Mitglieder aus uber 600 Unter- nehmen und 100 Landern.

[9] Eine einheitliche Definition fur den Begriff information Hiding “ kann nicht gefunden werden. Die Begriffe Kapselung, Geheimsprinzip und Abstraktion sind miteinander eng verwandt, obwohl sie ver- schiedene Aspekte adressieren. Aufgrund ihrer engen Beziehung werden sie in der Literatur haufig ver- wechselt oder zumindest verschieden verwendet. Berard bemuht sich in [Bera93] um eine Abgrenzung der Begriffe.

[10] Bei dieser Darstellung handelt es sich um eine weitlaufig verwendete. Fur die einzelnen Schichten existieren auch Alternativen, wie z.B. anstatt von HTTP auch andere Protokolle verwendet werden kon- nen, oder anstatt von BPEL auch WSFL oder XLANG denkbar sind.

[11] Das HTTP-Protokoll ist ein standardisiertes Kommunikationsprotokoll, das innerhalb des siebenschich- tigen OSI-Basisreferenzmodells auf der Anwendungsschicht (Schicht 7, Application Layer) angesiedelt ist [Fie+99].

[12] Die WSDL-Schema-Definition ist unter http://schemas.xmlsoap.org/wsdl/ und die WSDL- Spezifikation unter http://www.w3.org/TR/wsdl zu finden.

[13] Das Strukturmodell Nutzer- und Basismaschine von Ferstl und Sinz bezeichnet eine programmgesteu- erte Maschine aus AuBensicht als Nutzermaschine. Die Innensicht besteht hingegen aus einer oder mehre- ren Basismaschinen und den zugehorigen Programmen. Ein Programm realisiert demnach eine Nutzerma­schine unter Verwendung einer bestimmten Basismaschine [FeSi01, S. 286-289].

[14] Ein Beispiel einer CORBA-IDL-Datei ist im Anhang (A1) zu finden.

[15] In dieser Arbeit wurde die zum gegenwartigen Zeitpunkt aktuelle SOAP Version 1.2 betrachtet.

[16] Die asynchrone Kommunikation erscheint insbesondere in Verbindung mit Systemen sinnvoll, die nicht permanent verfugbar sind.

[17] Die Ausfuhrungen beziehen sich auf die UDDI Version 2, weil die Version 3 bis zum gegenwartigen Zeitpunkt lediglich in Form eines Committee Draft vorliegt.

[18] Weil eine detaillierte Betrachtung dieses Bereichs fur die Losung der behandelten Aufgabenstellung nicht von Bedeutung ist, wird von weiteren Ausfuhrungen abgesehen. Fur weiterfuhrende Informationen siehe [And+03], [Newc02, S.230-250] und [SaGr05, 23-26].

[19] Im Anhang (A3) ist eine Darstellung der Struktur der Object Management Architecture (OMA) zu finden.

[20] In dieser Arbeit werden URL (Uniform Resource Locator) und URI (Uniform Resource Locator) syn­onym betrachtet, obwohl URI als Identifikator einer abstrakten oder physischen Ressource (vgl. dazu [Ber+98]) als Oberbegriff uber URL und URN (Uniform Resource Name) vom W3C festgelegt wird (vgl. dazu [Mea+02]).

[21] Eine vollstandige Spezifikation von MIDL ist in [Micr98] zu finden.

22 Der Begriff Informationssystem (IS) wird in der Literatur zur Wirtschaftsinformatik je nach Sichtweise und Kontext verschieden interpretiert. In dieser Arbeit wird unter dem Begriff ein System verstanden, das die Objektart Information verarbeitet - also erfasst, ubertragt, transformiert, speichert und bereitstellt. Betriebliche Informationssysteme dienen der Lenkung von Geschaftsprozessen in Form von Informatio- nen [FeSi01, S. 1-9].

23 Neben dieser groben Kategorisierung wird in der Fachliteratur noch feiner anhand bestimmten Verhaltens unterschieden und z.B. das Immediate-Restart-Verfahren als eine Erweiterung von Sperrverfahren identifiziert (vgl. dazu [Agr+96, S. 61]).

Ende der Leseprobe aus 128 Seiten

Details

Titel
Analyse von Web Service-Spezifikationen zur Unterstützung von Transaktionen in Geschäftsprozessen
Hochschule
Universität Duisburg-Essen  (Lehrstuhl für Wirtschaftsinformatik und Softwaretechnik)
Veranstaltung
Verteilte Systeme
Note
1,3
Autor
Jahr
2006
Seiten
128
Katalognummer
V149644
ISBN (eBook)
9783640606245
ISBN (Buch)
9783640605941
Dateigröße
2551 KB
Sprache
Deutsch
Schlagworte
Analyse, Service-Spezifikationen, Unterstützung, Transaktionen, Geschäftsprozessen
Arbeit zitieren
Filip Karst (Autor:in), 2006, Analyse von Web Service-Spezifikationen zur Unterstützung von Transaktionen in Geschäftsprozessen, München, GRIN Verlag, https://www.grin.com/document/149644

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Analyse von Web Service-Spezifikationen zur Unterstützung von Transaktionen in Geschäftsprozessen



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