Enterprise Application Integration

Teilleistung

Offene Standards als Basis einer SOA

Kai Wirth Wintersemester 2010

Inhaltsverzeichnis

Inhaltsverzeichnis
Abbildungsverzeichnis .......................................................................................... II Abkrzungsverzeichnis ........................................................................................ III 1 Einfhrung und Motivation ............................................................................... 4 2 Die Serviceorientierte Architektur ................................................................... 5 2.1 Begriffsbestimmung .................................................................................... 5 2.2 Web-Services als Technologie-Plattform einer SOA ................................... 5 3 Offene Standards als Basis der SOA ............................................................... 7 3.1 Begriffsbestimmung .................................................................................... 7 3.2 Der Web Services Technologiestack .......................................................... 7 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 Die Extensible Markup Language (XML) ......................................... 8 Das SOAP-Protokoll........................................................................ 9 Die Web Service Description Language (WSDL) .......................... 10 Universal Description, Discovery, and Integration (UDDI) ............. 11 Interdependenzen zwischen den Standards .................................. 13

3.3 Web-Services der zweiten Generation (WS-* -Extensions) ....................... 13 4 Zusammenfassung und Ausblick .................................................................. 14 Literaturverzeichnis ............................................................................................. 15

Abbildungsverzeichnis

II

Abbildungsverzeichnis
Abbildung 1: Das Web-Services Dreieck incl. offener Standards .............................. 6 Abbildung 2: Der Web-Services Technologie Stack .................................................. 8 Abbildung 3: Austausch einer SOAP-Nachricht ....................................................... 9 Abbildung 4: Elemente der WSDL .......................................................................... 11 Abbildung 5: Zusammenhang offene Standards ..................................................... 13

Abkrzungsverzeichnis

III

Abkrzungsverzeichnis
API AwS SOA Application programming interface Anwendungssystem serviceorientierte Architektur

DEM Document Exchange Model JMS Java Message Service

SOAP kein Akronym, ursprnglich Simple Object Access Protocol XML Extensible markup language

WSDL Web Services Description Language SMTP Simple Mail Transfer Protocol HTTP Hypertext Transfer Protocol TCP/IP Transmission Control Protocol / Internet Protocol Familie UDDI Universal Description, Discovery and Integration

Einfhrung und Motivation

Einfhrung und Motivation

Zentrales Merkmal einer SOA ist die Verwendung von Services zur Realisation von Geschftsprozessen oder Workflows innerhalb einer verteilten, heterogenen Systemlandschaft. Im Mittelpunkt steht dabei das Zusammenspiel dieser Services in ihren Rollen als Dienstsucher und Dienstanbieter unter Zuhilfenahme eines Dienstverzeichnisses - , um die unterschiedlichen Anwendungssysteme (AwS), Workflows oder Prozesse einer heterogenen Systemlandschaft miteinander zu koppeln. Kommunikation, Nachrichtenbermittlung zwischen den AwS erfolgt dabei auf Basis von offenen Standards. Sie stellen damit ein grundlegendes Merkmal einer serviceorientierten Architektur (SOA) dar. Die Rollen, die die einzelnen Standards innerhalb der SOA spielen sowie die Standards selbst, sollen in dieser Arbeit thematisiert und nher betrachtet werden. In dieser Arbeit soll die Funktionsweise einer SOA auf Basis von Web-Services erlutert werden, im Anschluss daran werden die einzelnen zugrundliegenden offenen Standards vorgestellt und Abhngigkeiten zwischen ihnen herausgearbeitet. Abschlieend erfolgt ein Ausblick, in dem mgliche Weiterentwicklungen des SOAParadigmas auf Basis zuknftiger Standards aufgezeigt werden sollen.

Die serviceorientierte Architektur

2
2.1

Die Serviceorientierte Architektur

Begriffsbestimmung

Der Begriff Service-orientierte Architektur beschreibt ein abstraktes SoftwareArchitekturkonzept, das Services1 (Dienstleistungen) in den Mittelpunkt stellt (vgl. [Erl2008, S. 53], auch [TiSt2007, S. 12]). Er beschreibt eine Systemarchitektur, die heterogene und verteilte Software- bzw. Anwendungssysteme (AwS) mit Hilfe dieser Services miteinander verbindet (vgl. [Heutschi2007, S. 22-23]), wobei Servicekompositionen entstehen, die eine gewnschte Funktionalitt reprsentieren (vgl. [Erl2008, S. 53]). Zentrales Merkmal ist dabei das Anbieten, Suchen und Nutzen von Services ber ein Netzwerk (vgl. [Melzer2010, S. 7]). Eine SOA-Definition soll allerdings hier nicht hergeleitet werden, da bereits eine Vielzahl von unterschiedlichen SOA-Definitionen existieren (vgl. [Literaturangaben sammeln]), die das Problem darber hinaus aus verschiedenen, d.h. technischen, betriebswirtschaftlichen oder organisatorischen, Blickwinkeln heraus betrachten (vgl. [TiSt2007, S. 12-16]), insofern gibt es nicht die allgemeingltige-, sondern je nach Perspektive unterschiedliche Definitionen mit anderen Schwerpunkten.

2.2

Web-Services als Technologie-Plattform einer SOA

Die am hufigsten verwendete Technologie-Plattform zur Realisierung einer serviceorientierten Architektur sind Web-Services (vgl. [Erl2008, S. 62]). Web-Services stellen eine Kombination von bereits etablierten Technologien dar, die eine Realisierung von verteilten Anwendungen ermglichen und mit Hilfe von offenen Standards realisiert werden (vgl. [BuHa2003, S. 2-5]). In einer SOA stehen, wie bereits oben angefhrt, der Service oder Dienst sowie dessen Komposition im Mittelpunkt. Notwendige Basis ist also zunchst die Beschreibung eines Dienstes (Service Description) fr potentielle Nutzer, aus der die vollstndige Beschreibung der ffentlichen Schnittstelle eines Dienstes hervorgeht, was blicherweise mit Hilfe der Web Service Description Language (WSDL) erfolgt. Akteure innerhalb der SOA knnen hierbei drei unterschiedliche Rollen einnehmen, d.h. die Rolle des Dienstanbieters, der seine Dienste verffentlicht und diese bei

Unter einem Service werden im Folgenden Programme oder Softwarekomponenten verstanden, die ber ein Netzwerk von anderen Programmen/Komponenten genutzt werden knnen.

Die serviceorientierte Architektur

einem Verzeichnisdienst registriert, die des Dienstnutzers, der bentigte Dienste sucht, und die Rolle des Vermittlers (Dienstverzeichnis), das dem Finden von bentigten Diensten durch potentielle Nutzer dient. Die Interaktion zwischen diesen drei Polen gestaltet sich konkret wie folgt: Die eingangs erwhnte Dienstbeschreibung wird vom Dienstanbieter beim Dienstverzeichnis oder makler angemeldet bzw. verffentlicht (1. Verffentlichen). Der potentielle Nutzer des Services sucht beim Dienstverzeichnis nach geeigneten Services (2. Suchen), die die gewnschte Funktionalitt bereitstellen. Wurde ein entsprechender Dienst gefunden, so bezieht der Nutzer vom Dienstverzeichnis den Verweis auf die Dienstbeschreibung (3. Verweis auf Dienst), welche alle notwendigen technischen Informationen bereitstellt. Es kommt nun zur Interaktion zwischen Nutzer und Anbieter (4 Abfrage der Beschreibung) und schlielich, bei erfolgreicher Einigung, zur Bindung (5. Nutzung) der Dienste (vgl. [BuHa2003, S. 6-8] und [Melzer2010, S. 1419]). Abbildung 1 mag diesen Zusammenhang illustrieren, wobei gleichzeitig die bei der Interkation zugrundliegenden Standards mit angegeben sind. Die einzelnen Standards werden im Folgenden Kapitel genauer erlutert.

Abbildung 1: Das Web-Services Dreieck incl. offener Standards (vgl. [Melzer2010, S. 64])

Offene Standards als Basis der SOA

3
3.1

Offene Standards als Basis der SOA

Begriffsbestimmung

Von der British Standards Institution wird ein Standard als ein ffentlich zugngliches technisches Dokument, das unter Beteiligung aller interessierter Parteien entwickelt wird und deren Zustimmung findet beschrieben. Weiter heit es Der Standard beruht auf Ergebnissen aus Wissenschaft und Technik und zielt darauf ab, das Gemeinwohl zu frdern (Wiki2010_1). Standards sind offen wenn sie fr alle Marktteilnehmer besonders leicht zugnglich, weiter entwickelbar und einsetzbar sind (vgl. Wiki2010_2). Insbesondere erleichtern Standards Entwicklern und Architekten die Arbeit, indem sie Entscheidungen abnehmen und somit Konsistenz und Kompatibilitt von Lsungen erhhen (vgl. [Erl2008, S. 101]). Mittlerweile existieren im Zusammenhang mit der SOA diverse verschiedene Standards, die z.T. konkurrieren und widersprchlich sind (vgl. Masak2007, S. 235-236). In dieser Arbeit soll lediglich auf den Web-Service Technologiestack eingegangen werden, der allgemein anerkannt und weit verbreitet ist (vgl. [Frotscher2007, S. 489]), und fr das Realisieren einer SOA auf Basis von Web-Services erforderlich ist.

3.2

Der Web Services Technologiestack

Der Web-Service Technologiestack stellt eine Familie aufeinander aufbauender Standards dar, wobei eine Schicht jeweils die Voraussetzungen fr die darber liegende Schicht darstellt. Basis ist eine Transportschicht, die blicherweise, wenn die Kommunikation ber das Internet erfolgt - wie z.B. bei B2B-Anwendungen entlang der Supply Chain - mit dem HTTP-Protokoll realisiert wird, aber auch andere Protokolle, wie JMS, SMTP die etwa unternehmensintern Verwendung finden - sind mglich (vgl. (vgl. [Frotscher2007, S. 493]). Darauf aufbauend erfolgt die Inhaltsbeschreibung der Nachricht durch XML. Mit Hilfe der SOAP-Spezifikation erfolgt die Vereinbarung der Kommunikation zwischen den Diensten. Die Beschreibung des Dienstes wird von der Web Service Description Language in Form einer technischen und einer funktionalen Beschreibung vorgenommen. Auf der oberen Ebene erfolgt die Realisation des Verzeichnisdienstes mit Hilfe der UDDI-Spezifikation. Auf die genannten Protokolle und Spezifikationen wird im Folgenden einzeln eingegangen, die Protokolle der

Offene Standards als Basis der SOA

Transportschicht, z.B. HTTP und die darunter liegende TCP/IP-Schicht stellen Basisstrukturen bereit und sollen daher keine weitere Beachtung finden.

Abbildung 2: Der Web-Services Technologie Stack (vgl. BuHa2003, S. 26])

3.2.1

Die Extensible Markup Language (XML)

XML stellt heutzutage den De-facto Standard fr Datenreprsentation bzw. Datenaustausch dar (vgl. [MDPS2007, S. 9]). Sie ist eine textbasierte Metasprache und erlaubt die Beschreibung, Austausch, Darstellung und Manipulation von strukturierten Daten (vgl. [BuHa2003, S. 26]). Mithilfe von XML-Schema knnen konkrete XML-Sprachen spezifiziert werden, z.B. WSDL, mit XML selbst knnen Daten in Elementen oder als Attribut beschrieben werden (vgl. [TiSt2007, S. 32]). XML-Elemente werden analog HTML mit Start- und End-Tags sowie durch den Inhalt des Tags charakterisiert. Dieser Inhalt kann dabei entweder Daten oder wiederum aus anderen Elementen bestehen, so das sich einen Baumstruktur ergibt. Ein einfaches XML-Dokument hat den folgenden Aufbau:

XML spielt innerhalb des Web Services Technologiestack eine entscheidende Rolle, alle bergeordneten Standards, wie SOAP, WSDL und UDDI stellen selbst XML Schema-Spezifikationen dar (vgl. [Heutschi2007, S. 52]). Darber hinaus erfolgt die Beschreibung der Web Services selbst in XML, damit werden den Web Services Eigenschaften wie Plattform- und Programmiersprachenunabhngigkeit bertragen, wodurch diese einen hohen Grad an Interoperabilitt erreichen, die plattformber-

Offene Standards als Basis der SOA

greifende Integration innerhalb der SOA wird somit problemlos ermglicht (vgl. [BuHa2003, S. 4]).
3.2.2 Das SOAP-Protokoll

Die SOAP-Spezifikation ist XML-basiert und daher ein einfaches, sprach-und plattformunabhngiges Kommunikationsprotokoll zum Austausch strukturierter Informationen, und hat sich damit im Zusammenhang mit Web Services als Standard fr die Nachrichtenkapselung etabliert (vgl. [BuHa2003, S. 34]). Eine SOAP-Nachricht definiert die Grobstruktur sowie die Verarbeitungsvorschriften von Nachrichten, legt also lediglich fest, wie eine Nachricht aufgebaut sein muss. Der Ablauf einer SOAP-Kommunikation kann wie folgt beschrieben werden: Zunchst wird durch den Sender ein Kommunikationskanal ausgewhlt, den auch der Empfnger nutzt. Die Nachricht wird dann in einem Format erstellt, die der Empfnger versteht. Vor Senden der Nachricht, muss sie so verpackt (serialisiert) werden, dass sie ber den gewhlten Kommunikationskanal gesendet werden kann. Auf der Empfngerseite luft der Prozess spiegelverkehrt ab. Er entpackt (deserialsiert) und liest die Nachricht, da er sich vorab mit dem Sender ber das Format geeinigt hat (vgl. [Melzer2010, S. 85-86]).

Abbildung 3: Austausch einer SOAP-Nachricht (vgl. Melzer2010, S. 86])

Der SOAP-Envelope kapselt den eigentlichen Inhalt der Nachricht, den SOAPHeader und -Body. Der Header enthlt i.d.R. Informationen zum Absender sowie

Offene Standards als Basis der SOA

10

sicherheitsrelevante Informationen. Der Body enthlt die zu bertragende Information bzw. die eigentliche Nutzlast (payload), der Nachricht. Dieser Inhalt muss den in XML spezifizierten Anforderungen der Wohlgeformtheit2 entsprechen. ber das SOAP Protokoll lassen sich alle Informationen versenden, die sich als XMLDokument darstellen lassen, also z.B. PDF-Dokumente, HTML-Seiten, Bestellformulare usw.; binre Daten knnen mit Hilfe von zustzlichen Spezifikationen so angepasst werden, das auch solche Dateien mit XML dargestellt und per SOAP versendet werden knnen (vgl. Melzer2010, S. 88-90]). Das SOAP Protokoll wurde von Beginn an erweiterbar angelegt, so dass bei Bedarf anspruchsvollere Konzepte, wie Verschlsselungs-, Authentifizierungsmechanismen oder digitale Signaturen, in Form zustzlicher Spezifikationen an SOAP angedockt werden knnen (vgl. Frotscher2007, S. 489-490]).
3.2.3 Die Web Service Description Language (WSDL)

Auch WSDL basiert auf XML und ist selbst eine XML-Sprache bzw. Spezifikation fr netzwerkbasierte XML-Services (vgl. Masak2007, S. 241]). Sie dient der Beschreibung von Web Services bzw. Schnittstellen und unterscheidet dabei eine abstrakte und eine konkrete Perspektive aus der heraus die Services beschrieben werden (vgl. Melzer2010, S. 116]). Die abstrakte Schnittstelle beschreibt auf der Schema-Ebene Operationen, Nachrichten und Datentypen und damit, welche Nachrichten ausgetauscht werden. Ein portType besteht aus einer oder mehreren operation-Elementen, die jeweils einen Nachrichtenaustausch reprsentieren. Nachrichten werden ber message-Elemente beschrieben, die ein oder mehrere parts, z.B. bergabeparameter enthalten. Um einen Service aufrufen zu knnen, muss die Adresse des Services bekannt gemacht werden. Dies erfolgt durch das service-Element, welches ein oder mehrere port-Elemente enthlt. Ports beschreiben die Adresse eines Services, z.B. in Form einer URL oder eines logischen Server-ports. Die Elemente der abstrakten Schnittstellenbeschreibung werden mittels des binding-Elements auf die konkrete Ebene abgebildet (vgl. [MDPS2007, S. 11-12]), es definiert das konkrete Messageformat sowie die Protokolldetails. Da beliebig viele binding-Elemente fr ein bestimmtes

Wohlgeformtheit bedeutet in diesem Zusammenhang, dass alle in XML spezifizierten Regeln eingehalten werden mssen, ansonsten verliert ein XML-Dokument seine Gltigkeit.

Offene Standards als Basis der SOA

11

portType-Element existieren knnen, ist es mglich dieselbe Service-Operation ber verschiedene Protokolle anzubieten (vgl. Masak2007, S. 242]).

Abbildung 4: Elemente der WSDL (vgl. [MDPS2007, S. 11])

WSDL teilt die Elemente in zwei Klassen - Serviceinterfaces und ServiceImplementations ein, damit die WSDL-Dokumente innerhalb der UDDI-Registry einfacher zu finden sind (vgl. ebenda). Die WSDL-Spezifikation ist grundlegend fr eine Realisierung eines verteilten, offenen und flexiblen Systems. Durch die vollstndige und neutrale Beschreibung der Schnittstellen knnen voneinander unabhngige Parteien miteinander kommunizieren. Die mit WSDL beschriebenen Services knnen auf unterschiedlichen Systemen unterschiedlich implementiert sein, lediglich die Schnittstelle muss untersttzt werden. Dies ermglicht dann Systeme oder Prozesse aus unterschiedlich implementierten Komponenten flexibel zu kombinieren (vgl. [Melzer2010, S.138-139]).
3.2.4 Universal Description, Discovery, and Integration (UDDI)

UDDI stellt eine Spezifikation eines Verzeichnisdienstes dar und bietet eine durchsuchbare bersicht ber alle in einem bestimmten Netzwerk verfgbaren Web-Services. UDDI baut - wie aus Abbildung 2 ersichtlich - auf einer Netzwerktransportschicht und einer SOAP-basierten XML-Messageschicht auf, durch Nutzung von WSDL als Schnittstellen-Beschreibungssprache wird darber hinaus ein hoher Grad an Austauschbarkeit erreicht (vgl. [Masak2007, S. 243]). ber UDDI knnen Web-Services von Anbietern verffentlicht und von Nachfragern gesucht werden, wobei auch nach Suchkategorien oder kriterien gesucht werden kann, ebenso wird die Vergleichbarkeit z.B. nach Preis oder Leistung ermglicht (vgl. Melzer2010, S. 148]).

Offene Standards als Basis der SOA

12

UDDI besteht aus zwei Komponenten. Das UDDI-XML-Schema reprsentiert das Datenmodell, welches die kategorisierte Suche, Katalogisierung, Verwaltung etc. untersttzt. Die UDDI-API ermglicht die Interaktion zwischen UDDI-Client und Server. Die API basiert auf dem Document Exchange Model (DEM), d.h. die ClientServer Interaktion erfolgt durch den Austausch von XML-Dokumenten. Die Nutzung von XML ermglicht wiederum verschiedenen IT-Systemen unterschiedlicher Plattformen die Kommunikation mit dem UDDI Verzeichnis (vgl. Melzer2010, S. 157]). Wesentliche UDDI Server-APIs sind die UDDI Inquiry API, die die Suche innerhalb von Verzeichnissen ermglicht und die UDDI Publication API, welche sich um die Verffentlichung und Aktualisierung von Informationen in einem UDDI Verzeichnis kmmert (vgl. ebenda, S. 158-160]). Vor Fllen der Registry mit Inhalten mssen diese mit sog. tModels bestckt werden. Diese enthalten branchenspezifische Semantik der Datenelemente und bilden entsprechende Taxonomien ab (vgl. [Masak2007, S. 244]). Verzeichnisdienste wie UDDI konnten sich bisher noch nicht richtig durchsetzen. Zum einem spielen sicherlich Konkurrenzngste eine Rolle, wenn die eigenen Services verffentlicht werden, zum anderen verzichten Unternehmen noch oft auf die lose Kopplung von Services, da Performance-Einbuen im Netzwerk befrchtet werden, und insgesamt eher auf die Risiken als auf die Chancen fokussiert wird. Ebenso spielen ungeregelte Fragen der Abrechnung von erbrachter Leistung eine Rolle. (vgl. [Melzer2010, S. 166-167]).

Offene Standards als Basis der SOA

13

3.2.5

Interdependenzen zwischen den Standards

Die Zusammenhnge zwischen den beschriebenen offenen Standards und WebServices sollen abschlieend noch einmal zusammenfassend dargestellt werden.

XMLDokument
enthlt beschreibt

SOAPNachricht

XMLSchema

Tauscht aus

enthlt/referenziert

Web-Service
beschreibt

WSDL

Abbildung 5: Zusammenhang offene Standards (vgl. [TiSt2007, S. 33])

3.3

Web-Services der zweiten Generation (WS-* -Extensions)

Web-Services der zweiten Generation bauen auf dem Grundgerst der ersten Generation auf und reichern die grundlegenden Standards mit ntzlichen Zusatzfunktionalitten an (vgl. [Erl2008, S. 62-63]). Dies ist notwendig geworden, da WebServices zunehmend in unternehmenskritischen Bereichen eingesetzt werden und nun adquate Antworten auf bisher schlecht- oder ungelste Probleme gefunden werden mussten. Es handelt sich dabei hauptschlich um nichtfunktionale Anforderungen, wie z.B. Erhhung der Nachrichtensicherheit, servicebergreifende Transaktionen, Verschlsselung. Derartige nichtfunktionale Anforderungen knnen aber nicht mit WSDL beschrieben werden. Diese Aufgabe soll nun vom sog. WS-Policy Framework gelst werden (vgl. [Frotscher2007, S. 490-491]). Die WS-Policy Spezifikation definiert, wie nichtfunktionale Anforderungen in XML beschrieben werden knnen. Derartige Policies knnen dann an ein WSDL-Dokument angehngt oder in externe Dateien ausgelagert werden. (vgl. [ebenda, S. 491]).

Zusammenfassung und Ausblick

14

Zusammenfassung und Ausblick

Offene Standards sind grundlegende Basis, um eine SOA basierend auf WebServices realisieren zu knnen. Sie erhhen die Interoperabilitt und Skalierbarkeit sowie die plattformbergreifende Integration und frdern die lose Kopplung zwischen den Services. Weiterentwicklungen, wie die WS-Policy ermglichen darber hinaus, dass eine SOA auch in unternehmenskritischen Bereichen sicher und mit zufriedenstellender Dienstqualitt operieren kann. Denkbar wird damit eine unternehmensweite oder bergreifende Anwendungslandschaft, die mit einem flexiblen Werkzeugkasten an Geschftsprozessen angemessen und schnell auf zuknftige Herausforderungen im Wettbewerbsumfeld reagieren kann.

Literaturverzeichnis

15

Literaturverzeichnis
BuHa2003 Burghardt, M., Hagenhoff, S.: Web Services Grundlagen und Kerntechnologien. In: Arbeitsbericht Nr. 22/2003 Matthias Schumann (Hrsg.); Institut fr Wirtschaftsinformatik, Georg-AugustUniversitt Gttingen. Erl, Thomas: SOA Entwurfsprinzipien fr serviceorientierte Architekturen, Addison-Wesley Mnchen, 2008 Frotscher, Thilo: Der Webservices-Technologiestack; in: Tilkov, Stefan; Starke Gernot (Hrsg.): SOA-Expertenwissen, dpunkt.verlag, Heidelberg, 2007 Heutschi, Roger: Serviceorientierte Architektur, Springer Berlin Heidelberg 2007 Masak, Dieter: SOA?, Springer, Berlin Heidelberg, 2007 Melzer, Ingo: Service-orientierte Architekturen mit Web-Services, Spektrum Akademischer Verlag, Heidelberg, 4. Auflage 2010 Kloppmann, Matthias; Knig, Dieter; Pfau, Gerhard; Scheible, Michael: Von singulren Web Services zu integrierten SOAPlattformen: Die Evolution serviceorientierter Architekturen und Anwendungen, in: Kircher, Herbert (Hrsg.): IT Technologien, Lsungen, Innovationen, Springer Berlin Heidelberg, 2007 Tilkov, Stefan; Starke Gernot: Einmaleins der serviceorientierten Architekturen, in: Tilkov, Stefan; Starke Gernot (Hrsg.): SOAExpertenwissen, dpunkt.verlag, Heidelberg, 2007 http://de.wikipedia.org/wiki/Standard; Abruf am 04.01.2011 http://de.wikipedia.org/wiki/Offener_Standard; Abruf am 04.01.2011

Erl2008 Frotscher2007

Heutschi2007 Masak2007 Melzer2010

MDPS2007

TiSt2007

Wiki2010_1 Wiki2010_2

Eidesstattliche Erklrung

16

Ich versichere an Eides statt durch meine Unterschrift, dass ich die vorstehende Arbeit selbstndig und ohne fremde Hilfe angefertigt und alle Stellen, die ich wrtlich oder annhernd wrtlich aus Verffentlichungen entnommen habe, als solche kenntlich gemacht habe, mich auch keiner anderen als der angegebenen Literatur oder sonstiger Hilfsmittel bedient habe. Die Arbeit hat in dieser oder hnlicher Form noch keiner anderen Prfungsbehrde vorgelegen.

_________________________________________________ Ort, Datum, Unterschrift