Apache Axis Ausarbeitung im Rahmen des Seminars
Werbung
Westfälische Wilhelms-Universität Münster Apache Axis Ausarbeitung im Rahmen des Seminars: Service Computing und Service-Oriented Architectures AG Parallele und Verteilte Systeme am Institut für Informatik Themensteller: Betreuer: Prof. Dr. habil. Sergei Gorlatch Dipl.-Inf. Jens Müller vorgelegt von: Gunnar Thies Kanalstraße 30 48147 Münster Telefon: 0251 / 2109672 [email protected] Abgabetermin: 08.07.2005 – II – Inhaltsverzeichnis Inhaltsverzeichnis ............................................................................................................. II 1 Einleitung......................................................................................................................1 2 Architektur von Axis .....................................................................................................3 2.1 Architektur Einführung..........................................................................................3 2.2 Struktur der Axis-Engine........................................................................................3 2.3 Ablauf einer Web Service-Anfrage .......................................................................5 2.4 Handler und Chains ...............................................................................................6 2.5 Web Service Deployment Descriptor ....................................................................7 2.6 Web Service Description Language ......................................................................9 3 Web Service-Implementierung mit Java.....................................................................10 3.1 Implementierungsvorbereitung............................................................................10 3.2 Programmierbeispiel............................................................................................11 4 Web Service-Implementierung mit C++ ....................................................................13 4.1 Implementierungsvorbereitung............................................................................13 4.2 Programmierbeispiel............................................................................................13 5 Technologiebetrachtung..............................................................................................16 5.1 Sicherheit und Authentifizierung.........................................................................16 5.2 SOAP Attachments..............................................................................................17 5.3 Interoperabilität....................................................................................................17 6 Zusammenfassung und Ausblick ................................................................................18 Literaturverzeichnis .........................................................................................................19 Internet-Adressen.............................................................................................................19 Anhang ............................................................................................................................20 –1– 1 Einleitung Strategien und Konzepte für Web Services und Service-orientierte Architekturen sind in der Informationstechnologie mittlerweile sehr verbreitet. Das Anbieten solcher Dienste, die über ein Netzwerk – sei es das Inter- oder ein Intranet – (fast) überall aufrufbar sind, wird durch eine Web Service-Laufzeitumgebung, wie beispielsweise die Open SourceSoftware Apache Axis [1], ermöglicht. Deren Architektur wird im Folgenden näher betrachtet und es wird dabei besprochen, wie die Web Services innerhalb der Laufzeitumgebung verarbeitet und behandelt werden. Außerdem wird deren Konfiguration und Beschreibung mittels XML-basierter Dateien vorgestellt. Axis liegt in zwei Versionen vor: für C++ und Java. Somit ist es möglich, eine der beiden objektorientierten Programmiersprachen zur Implementierung von Web Services zu benutzen. Um die Architektur von Axis zu verstehen, wird die konkrete Implementierung eines Web Services mit Axis Java und zum Vergleich anschließend mit Axis C++ an einem kurzen Beispiel erläutert. Zusätzlich werden mögliche technische Erweiterungen von Web Services angesprochen, die mit Axis realisierbar sind. Zunächst wird der Begriff Web Service durch die eher nüchterne Definition des W3C erläutert: “Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks.“ [2] Ein Web Service ist also nach Meinung des W3C eine Komponente (Dienst), die die Zusammenarbeit (bzw. den Austausch von Informationen) verschiedener Programme auf unterschiedlichen Plattformen oder Frameworks ermöglicht. Kurz gesagt, kann mit Hilfe eines Web Services eine Nachricht zwischen zwei unterschiedlichen Programmen ausgetauscht werden. Axis steht für Apache extensible Interaction System und wird durch die Apache Software Foundation entwickelt, die ein Zusammenschluss vieler Software-Entwickler rund um den Globus ist. Diese Organisation entwickelt auch den weltweit eingesetzten Apache HTTP Webserver und weitere führende Open Source-Lösungen für den InternetBereich. Axis ist bereits die dritte Generation dieser Software, die ursprünglich als Apache SOAP startete. Sie erlaubt – vereinfacht gesagt – die Verarbeitung und Erstellung von (XML-) Nachrichten.1 1 AXIS wurde so konzipiert, dass nicht nur SOAP, sondern auch „Message“-Formate wie XML-RPC und weitere Formate, wie das der W3C XML Protokoll Work Group, verarbeitet werden können. –2– So lassen sich SOAP2-Nachrichten an Axis schicken, die dann im Axis-Framework an einen Web Service weitergereicht werden und ggf. eine Antwort für das aufrufende Programm generieren. Durch diese Verarbeitungsschritte ermöglicht Axis die Kommunikation von und mit Web Services über ein Netzwerk. Es gibt weitere entsprechende Applikationen verschiedener Softwarehersteller, beispielsweise den SUN Java System Applikation Server oder das Microsoft .NET-Framework, die ebenfalls das Erstellen bzw. Anbieten von Web Services ermöglichen. Die wichtigsten Elemente in der Architektur von Axis sind Handler: dies sind einzelne Verarbeitungsschritte innerhalb der Laufzeitumgebung, die eine Nachricht in irgendeiner Form verändern oder bearbeiten. Mit Hilfe einer Beschreibungsdatei (Web Service Deployment Descriptor, im Folgenden WSDD) können Handler beliebig zu einem konkreten Web Service zugeordnet werden. Was durch diese Zuordnung von Handler zu Web Services erreicht werden kann, wird in Kapitel 2.3 sowie 2.4 näher erläutert. In [3] nennen die Axis-Entwickler folgende Punkte als Hauptmerkmale des Produkts: • Hohe Geschwindigkeit durch Verwendung von SAX3 (statt DOM). • Hohe Flexibilität durch das Erweitern mit selbst programmierten Handler. • Stabilität des Programmkerns durch ein Grundgerüst an Interfaces, welches sich selten ändert. • Transportschicht, die vom benutzten Protokoll abstrahiert (SMTP, FTP, HTTP). • WSDL4-Support zur schnelleren Code-Erstellung bzw. Erstellung von WSDLDokumenten aus dem Quellcode eines Web Services. Der Aspekt der hohen Flexibilität wird durch die Vorstellung der Architektur von Axis in Kapitel 2 näher betrachtet. In Kapitel 3 wird dann auf die Implementierung von Web Services mit Axis Java eingegangen, woran das Kapitel 4 mit der Implementierung mit Axis C++ anknüpft – damit lässt sich die WSDL-Unterstützung für die schnellere CodeErstellung veranschaulichen. Das fünfte Kapitel gibt daraufhin einen kurzen Überblick über weitere technische Aspekte und Möglichkeiten des Axis-Frameworks. In Kapitel 6 wird dann schließlich das Thema in einer kurzen Zusammenfassung reflektiert. 2 Das Simple Object Access Protocol verschickt Daten (auf XML-Basis) zwischen Systemen und kann Remote Procedure Calls durchführen. Der Transport einer SOAP-Nachricht wird dabei meist über das im Internet übliche TCP/IP-Protokoll abgewickelt. 3 SAX und DOM sind zwei verschiedene Ansätze, um durch eine XML-Dateistruktur zu navigieren. 4 Ein Web Service Description Language-Dokument beschreibt auf XML-Basis u.a. die aufrufbaren Operationen eines Web Services. In Kapitel 2.6 wird darauf kurz eingegangen. –3– 2 Architektur von Axis 2.1 Architektur Einführung Axis ist in zwei Versionen verfügbar: für C++ und für Java. Dadurch werden zwei weit verbreitete objektorientierte Programmiersprachen für die Implementierung von Web Services verwendet. Axis Java existiert in der Version 1.2, Axis C++ bereits in der Version 1.5. Anders als die Versionsnummern glauben lassen, wurde zuerst die Java Version von Axis entwickelt und anschließend eine an die Architektur der Java Version angelehnte C++ Version implementiert. Die Struktur der beiden Versionen unterscheidet sich nicht, so dass die Architektur anhand der Java-Version erläutert wird. Nur in der Implementierung eines Web Services für Axis ergeben sich Unterschiede durch die verschiedenen Versionen. 2.2 Struktur der Axis-Engine Bei Axis dreht sich alles um die Verarbeitung von Nachrichten in aufeinander folgenden Schritten. Axis wurde dabei unter der Prämisse entwickelt, verschiedenste Nachrichten im XML-Format zu verstehen. Hier wird nur auf das aktuell gängigste Format zur Interaktion von Web Services, SOAP, eingegangen. Im Axis-Framework lassen sich zwei Akteure unterscheiden: die Serverseite – die den Web Service anbietet – und die Clientseite – mit der eine Applikation zur Abfrage eines Web Services realisiert werden kann. Es ergeben sich nur geringfügige Unterschiede in der Architektur bzw. den Ablauf der Verarbeitung einer Nachricht der beiden Akteure, daher wird hier die Struktur anhand der Serverseite erläutert. Die Implementierung einer Applikation mit Axis, die als Client einen Web Service aufruft, wird hier vernachlässigt und wir nehmen zur Vereinfachung an, dass ein Test-Client eine SOAP-Nachricht über einen Webbrowser (durch einen PHP-Client) an den Axis-Server sendet. Durch die Verwendung von PHP als Client – also ohne Axis-spezifischen Hintergrund – kann in Kapitel 5.3 (mit Einschränkungen) gezeigt werden, dass die mit Axis realisierten Web Services wirklich unabhängig von der Programmiersprache oder der Plattform benutzt werden können. Um die in Axis bereitgestellten Web Services im Inter- oder Intranet zur Verfügung zu stellen, muss die Axis-Engine – so wird der Serverteil des Frameworks bezeichnet – in einen geeigneten Server eingebettet werden. Eine Möglichkeit besteht hierbei in der Benutzung des mitgelieferten SimpleAxisServers. Dieser ist zwar recht rudimentär (lediglich ein Port zur Annahme von Anfragen ist zu definieren), aber läuft in beiden Versionen stabil. Eine weitere Möglichkeit besteht bei Axis C++ in der Einbettung in den –4– Apache HTTP Web Server – ein durch die Apache Group entwickelter Web Server – und bei Axis Java in den Jakarta Tomcat Server – ein Applikationsserver für Java. Die jeweilige Installation einer Axis-Version auf unterschiedlichen Betriebssystemen und in unterschiedlicher Konfiguration ist manchmal nicht ganz unproblematisch, wird aber durch die vielfältigen Dokumentationen5 des Axis-Entwickler-Teams erleichtert. Die Grundstruktur der Axis-Engine besteht aus drei unterscheidbaren Schichten: der Transport-Schicht, der globalen Schicht und der Service-Schicht (siehe Abb. 1). In jeder Schicht existieren Handler, die zur Bearbeitung einer Nachricht verwendet werden. Beispielsweise ein Handler in der Transport-Schicht, der alle Nachrichten, die per HTTP geschickt werden, annimmt und weiterverarbeitet, während für eingehende Nachrichten über SMTP ein anderer Handler zuständig ist. In der Konfigurationsdatei (WSDDDatei), die für jeden Web Service angelegt wird, kann für jede Schicht festgelegt werden, welche weiteren Handler auf eine Nachricht angewendet werden sollen. Es lassen sich auch Handler aneinanderreihen, und so zu einer Kette (Chain) zusammenfassen. Eine solche Chain kann damit beliebig viele Verarbeitungsschritte kapseln. Um eine Nachricht überhaupt bearbeiten zu können, muss diese in einer für die Handler verarbeitbaren Form vorliegen. Dazu wird die ankommende Nachricht bevor sie der AxisEngine übergeben wird von einem so genannten Transport Listener6 in ein MessageContext-Objekt (im Folgenden MC-Objekt) umgewandelt. Dieses MC-Objekt enthält alle in der Nachricht enthaltenen Informationen in einer XML-Formatierung, die AxisHandler verstehen können, und wird an die erste Schicht von Axis (die TransportSchicht) weitergegeben. Innerhalb der Axis-Engine muss man dann zwischen zwei unterschiedlichen Wegen unterscheiden: zunächst – bei ankommenden Nachrichten – den Request-Flow, der den Weg des MC-Objekts bis hin zum empfangenden Web Service beschreibt (oben in Abb. 1) und den Response-Flow, der den Rückweg des MC-Objekts (erweitert um evtl. Antwortnachrichten) zum Transport Listener beschreibt (unten in Abb.1). 5 6 Siehe: http://ws.apache.org/axis/ Ein „Transport Listener“ könnte hier beispielsweise ein HTTP-Servlet für Anfragen über einen Webbrowser sein. –5– Abbildung 1: Architektur der Axis-Engine Der Aufbau eines MC-Objekts ist in Abb. 2 dargestellt: Hierbei wird einem MC-Objekt eine eingehende Nachricht und/oder eine ausgehende Nachricht (Message) zugeordnet. Eine solche Nachricht enthält jeweils einen SOAPPart und ein Attachment, welche beide das Part-Interface implementieren. Der SOAPPart umfasst – wie der Name schon verrät – die SOAP-spezifischen Informationen der Nachricht. Der Attachement-Teil einer Nachricht enthält ggf. Informationen und (Binär-) Daten einer Datei, die mit dem Web Service übermittelt werden soll. Abbildung 2: MessageContext-Aufbau 2.3 Ablauf einer Web Service-Anfrage Ein MC-Objekt wird nach dem Empfang durch den Transport Listener zunächst an die transportspezifische Request-Kette (z.B. den HTTP-Handler) der Axis-Engine weitergeleitet. Hierin sind verschiedene Handler für unterschiedliche Protokolle vorgesehen. Die Information, welches Protokoll die eingehende Nachricht hatte, ist im MC-Objekt hinterlegt. Sind alle Handler (also die Kette) der Transport-Schicht auf das MC-Objekt angewendet worden, wird es an die globale Request-Kette weitergegeben. Hierin sind Handler positioniert, die auf jedes MC-Objekt ausgeführt werden, unabhängig davon über welches Protokoll sie die Axis-Engine erreichten oder welchen Web Service sie anvisieren. Ein möglicher Handler der globalen Schicht wäre z.B. ein Zähler, der jegliche Web Service-Aufrufe – egal an welchen Web Service sie gerichtet sind – zählt oder die Anfragen für spätere Analysen in einer Datenbank mitprotokolliert. –6– Im letzten Schritt des Request-Flows erreicht das MC-Objekt die servicespezifische Schicht: hierin werden jeweils nur die für einen spezifischen Web Service auszuführenden Handler auf das MC-Objekt angewendet. Ein spezieller Handler – der Provider – ruft dann letztendlich den endgültigen Web Service auf, an den die Nachricht gerichtet ist. Eine eventuelle Antwort des Web Services wandelt der Provider in den Antwortteil des MC-Objekts um und schickt die Nachricht auf den Rückweg – also den ResponseFlow. Dieser Weg verläuft umgekehrt zum Request-Flow durch die Schichten: nach der servicespezifischen Schicht folgt die globale Response-Kette und daraufhin die transportspezifische Response-Kette. Die Handler, die auf dem Response-Flow auf das MCObjekt angewendet werden, können sich von denen des Request-Flows unterscheiden. Ein Handler, der wie der Provider den Wendepunkt vom Request-Flow zum ResponseFlow repräsentiert, wird als Pivot-Handler bezeichnet. Der Transport Listener wandelt schließlich das MC-Objekt wieder in eine SOAP-Nachricht um und schickt sie zurück an den aufrufenden Client. Es ist es auch möglich, dass ein einfacher Web Service so konfiguriert wird, dass eine an ihn gerichtete Nachricht weder in der globalen noch in der servicespezifischen Schicht durch irgendeinen Handler verarbeitet wird und lediglich durch den ProviderHandler an den Web Service übergeben, und dessen Antwort an den Client zurückgeschickt wird. 2.4 Handler und Chains Durch Handler lassen sich zu den bereits existierenden Implementierungen der Axis Engine weitere nützliche Werkzeuge erstellen. Um einen einfachen Web Service (wie später den „exampleService“ Web Service) mit Axis zu realisieren, reichen die in Axis integrierten Handler und Chains jedoch aus. Will man aber weitere Funktionalitäten, beispielsweise für Verschlüsselung, Authentifizierung oder oben angeführte Protokollierungen einbinden, so kann man dafür selbst Handler schreiben und in die globale Request bzw. Response-Schicht einbinden. Um einen Handler zu implementieren, kann – in beiden Programmiersprachen – die BasicHandler-Klasse erweitert werden. Dabei muss zumindest die Methode invoke, die beim Aufruf ein MC-Objekt übergeben bekommt, überschrieben werden. In dieser Methode befindet sich dann die Logik, die eine Veränderung der Nachricht im AxisFramework vornimmt. Der Handler muss nur für die jeweilige Plattform kompiliert und in der WSDD-Datei für einen Web Service konfiguriert werden. –7– Auf die näheren Details einer Implementierung eigener Handler wird hier nicht weiter eingegangen, da hier nur ein einfacher Web Service als Beispiel erläutert wird, der keine weiteren als die vorhandenen Handler benötigt. Dokumentationen für die Implementierung von Handler in Axis C++ lassen sich aber unter [4] oder für Axis Java in [ER03] finden. 2.5 Web Service Deployment Descriptor Um einen Web Service in Axis benutzen zu können, muss eine Web Service Deployment Descriptor-Datei (WSDD) für den Web Service erstellt werden. Diese im XMLFormat strukturierte Datei ist für die Konfiguration des Web Services in Axis nötig. Sie legt für Axis verständlich fest, wie ein Web Service aufzurufen ist, welche zusätzlichen Handler auf eine an ihn gerichtete Nachricht anzuwenden sind und wo der konkrete Service zu finden ist. Man kann diese WSDD-Datei also als Konfigurationsdatei eines Web Services bezeichnen. Nachfolgend wird der „exampleService“ durch eine WSDDDatei konfiguriert: 1: 2: 3: 4: 5: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: <deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <!-- Definieren eines servicespezifischen Handlers --> <handler name="track" type="java:samples.userguide.example.LogHandler"> <parameter name="filename" value="MyService.log"/> </handler> <!-- Definieren des Web Services, unter Benutzung des Handlers--> <service name="exampleService" provider="java:RPC"> <requestFlow> <handler type="track"/> </requestFlow> <parameter name="className" value="samples.seminar.exampleService"/> <parameter name="allowedMethods" value="*"/> <parameter name="scope" value="application"/> </service> </deployment> In Zeile 11-18 wird zunächst innerhalb des <service>-Tags der Web Service selbst beschrieben. Es wird zum einen der Name und der Provider-Typ (hier als RemoteProcedureCall; java:RPC oder CPP:RPC) festgelegt – unter diesem Namen ist der Web Service später auch erreichbar. Zusätzlich dazu werden Parameter wie der Klassenname des konkreten Web Services und die aufrufbaren Methoden (allowedMethods) der Web Service-Implementierung konfiguriert. Der Wert „*“ bedeutet, dass alle Methoden der Web Service-Implementierung aufgerufen werden dürfen. In Zeile 12-14 wird zusätzlich angegeben, dass auf dem Weg zum Web Service (dem Request-Flow) ein Handler mit dem Namen „track“ ausgeführt werden soll; dies geschieht in der servicespezifischen Schicht. Um diesen Handler auch ausführen zu können, muss Axis mitgeteilt –8– werden, was dieser Handler tun soll. Dies wird in Zeile 4 bis 8 durch die <handler>Tags definiert. Der Handler erhält einen Namen und eine konkrete Klasse (C++ oder Java) zugewiesen, die die Logik des Handlers implementiert. Als zusätzlichen Parameter benötigt dieser Handler einen Dateinamen (in die die Log-Daten geschrieben werden). Dies ist ein einfacher Handler, der mitprotokollieren kann, wie oft ein Web Service aufgerufen wurde. Eine WSDD-Datei kann für umfangreichere Web Services sehr viel größer und komplexer werden, für das hier verwendete Beispiel genügt diese Datei jedoch. Weitere Informationen zur Konfiguration von Web Services mittels der WSDD-Datei sind in [DAP04] zu finden. Der Provider-Typ dieses Services ist in Zeile 11 als RPC-Typ angegeben. Damit wird der Stil definiert, wie der SOAPPart – also die Informationen – des MC-Objekts kodiert wird. Axis bietet hierfür vier verschiedene Stile an: • RPC-Service: Dieser (als Standard eingestellte) Stil hält sich an die SOAP RPC Convention (beschrieben in [5]), in der das SOAP „section 5“-encoding angewendet wird. • Document Service: Der Inhalt der Nachricht wird nicht nach dem SOAPStandard codiert, sondern nur in eine einfache XML-Struktur „gepackt“. Es gibt ein einziges Binding in dem SOAPBody, welches alle Daten enthält. So gesehen, wird praktisch nur ein Objekt – ähnlich einem Attachement – im SOAPBody spezifiziert und verschickt. Dies kann man sich als das Verschicken eines ganzen Objektes in einer objektorientierten Programmiersprache vorstellen. • Wrapped Service: Verhält sich wie der Document Service, wobei hier im SOAP-Body mehrere Parameter für den Inhalt verwendet werden. Der Inhalt eines Objektes wird also auf verschiedene Parameter (Tags) aufgeteilt. Hierbei – um bei der Analogie zu objektorientierter Programmierung zu bleiben – würden die Aufruf-Parameter eines Objektes und nicht das Objekt selbst verschickt werden. • Message Service: bei diesem Stil werden keine TypeMappings oder DataBindings in der Nachricht benutzt, die Nachricht wird als „arbitrary“ XML geschickt. So kann verhindert werden, dass aus den SOAP-Nachrichten Java (bzw. C++)-Objekte erstellt werden. Es ist also möglich, mit der „reinen“ SOAPNachricht auf XML-Basis zu arbeiten. Dies ist beispielsweise für die Interoperabilität zwischen Systemen nützlich. –9– Im Normalfall wird hier ein RPC-Service-Stil benutzt, damit die empfangenen Nachrichten von einem potentiellen (Axis-) Client direkt in Objekte der jeweiligen Programmiersprache umgewandelt werden können. Einen weiteren wichtigen Parameter enthält Zeile 17: Durch den Parameter Scope lässt sich das Objektverhalten des Web Services festlegen. Dafür stehen drei Arten zur Verfügung: durch application wird ein einziges Singleton-Objekt für alle Aufrufe dieses Services auf dem Server erstellt, durch request wird für jeden Aufruf ein eigenes Objekt erstellt und session generiert für jede Session eines Benutzers – also mehrere hintereinander ausgeführte, zusammengehörende Aufrufe – ein Objekt auf dem Server. 2.6 Web Service Description Language Neben der WSDD-Datei, die nur der Konfiguration des Web Services in Axis dient, sollten die Operationen des Web Services in einer WSDL-Datei (Version 1.1) beschrieben werden. Die Operationen und deren Parameter werden darin durch eine vom W3C definierte XML-Struktur beschrieben. Eine WSDL-Datei wird zumeist für die Implementierung von Client-Programmen benötigt, um die aufrufbaren Operationen und deren Parameter eines Web Services zu kennen. Im Folgenden wird eine kurze Übersicht über die möglichen Parameter einer WSDL-Datei zur Beschreibung eines Web Services gezeigt: WSDL-Tag <types> <message> <portType>7 <binding> <service> Bedeutung Hiermit lassen sich komplexe Typen oder Strukturen definieren. Hier werden Nachrichtenteile, die später im Web Service benutzt werden an Typen gebunden: z.B. <wsdl:part name=“test“ type=“xsd.string“> Ein portType ist eine Menge abstrakter Operationen. Es können pro Operation Ein-, Ausgabe und Fehlernachrichten (messages) festgelegt werden. Dies definiert für einen portType das Übertragungsprotokoll (z.B. SOAP) und die Übertragungsart (z.B. HTTP) Benennt den konkreten Web Service, welchem portType dieser zugeordnet ist und wo dieser aufzurufen ist (url). Hierin wird dann noch ein <port> definiert, der auf ein <binding> verweist. Eine konkrete Ausführung einer WSDL-Datei befindet sich im Anhang dieser Ausarbeitung als Beschreibung für den in Kapitel 3 und 4 implementierten Web Service. 7 Seit dem 11. Juni 2003 existiert die Spezifikation 1.2 von WSDL-Dokumenten: <portType> soll nun als <interface> und <port> als <endpoint> spezifiziert werden (u.a.). Die Implementierung von Axis hält sich jedoch noch an die WSDL 1.1 Spezifikation. – 10 – 3 Web Service-Implementierung mit Java 3.1 Implementierungsvorbereitung Es gibt für die Implementierung von Web Services mit Java zwei Ansätze: entweder werden zunächst alle für einen Java-Web Service benötigten Klassen selbst geschrieben und dafür anschließend automatisch die beschreibende WSDL-Datei erstellt, oder man definiert zuerst eine WSDL-Datei und lässt daraus automatisch die nötigen JavaObjektsignaturen (ohne Programmlogik) erstellen. Hier wird die zweite Methode vorgestellt, da sie weniger arbeitsintensiv ist und nur eine Datei – die WSDL-Datei – von Hand zu erstellen ist. Die automatisch generierten Java-Interfaces und Klassen müssen dann nur noch mit Implementierungsdetails gefüllt werden. Es gibt zusätzlich eine dritte Methode, um einen Web Service zu erstellen: dieser Ansatz nennt sich Instant Deployment (siehe auch [ER03]). Hierbei wird eine Java-Datei unkompiliert in das WEB-INFVerzeichnis des Tomcat-Servers kopiert und mit einer *.jws-Endung versehen. Bei einem Aufruf wird diese Datei zur Laufzeit kompiliert und als Web Service behandelt. Dieses Verfahren hat aber auch den Nachteil, dass weder Paketstrukturen benutzt, noch Fehler vor der Laufzeit bemerkt werden können: Daher wird diese Art des Veröffentlichens nicht weiter behandelt. Zunächst wird kurz erläutert, welche Dateien aus einer WSDL-Datei durch das in Axis enthaltene Tool WSDL2Java erstellt werden. Auch hierbei muss wiederum zwischen der Client- und der Serverseite unterschieden werden. Abbildung 3 zeigt eine schematische Übersicht über die automatisch erstellten Dateien für die Implementierung eines serverseitigen Web Services. Abbildung 3: WSDL2Java Generierung der Server-Klassen Durch den folgenden Befehl werden die benötigten Java-Klassen der Serverseite mit WSDL2Java erzeugt: – 11 – java –cp %AXISCLASSPATH% org.apache.axis.wsdl.WSDL2Java --server-side exampleService.wsdl Aus der WSDL-Datei exampleService.wsdl werden so entsprechend der folgenden Übersicht aus <binding> und <service>-Tags automatisch Java-Objektsignaturen erstellt: WSDL-Tag Binding: Service: Generierte Java-Dateien für die serverseitige Implementierung Implementierungsklasse (und evtl. Skeletonklasse8) Eine deploy.wsdd und eine undeploy.wsdd-Datei Als Ergebnis des obigen Befehls wird für jedes Binding der WSDL-Datei eine Implementierungsklasse erstellt, die die Methodenrümpfe – wie in Kapitel 3.2 dargestellt – für die Operationen des Web Services enthält. In einer solchen Implementierungsklasse muss nur noch die jeweilige Programmlogik in den Methodenrümpfen ausgefüllt werden. Es wird jedoch für einen Web Service immer nur eine deploy.wsdd und eine undeploy.wsdd Datei erstellt, da diese beiden Dateien die Konfiguration eines Web Services für Axis beschreiben, und somit alle Operationen des Web Services in einer Datei zusammenfassen. Die deploy.wsdd wird nach der Implementierung zum Veröffentlichen des Web Services (im Folgenden als Deployen bezeichnet) in Axis benutzt. Da in diesem Beispiel bewusst keine Skeletonklassen erstellt wurden, verweisen die Parameter der deploy.wsdd-Datei, die den Klassennamen (className) bestimmen, direkt auf die Implementierungsklassen des Web Services (wie auch in der WSDD-Datei des Kapitels 2.5 zu sehen ist). 3.2 Programmierbeispiel Als Programmierbeispiel dient hier ein Web Service, der zwei Parameter (einen Vorsowie einen Nachnamen) übergeben bekommt und als Antwort einen Parameter (eine Grußbotschaft, die den vollständigen Namen enthält) an den aufrufenden Client zurückschickt. Für die Implementierung bzw. automatische Generierung der Java-Klassen durch das Tool WSDL2Java wird die im Anhang beschriebene Datei exampleService.wsdl benutzt. Um die Implementierung des serverseitigen Web Services zu beginnen, werden zunächst die Klassen ohne Skeleton erstellt. Man erhält dabei folgende Dateien: • 8 ExampleService.java: Interface des Web Services, welches die Operationen des Web Services als abstrakte Methoden definiert. Skeletonklassen werden von Axis aufgerufen und leiten den Aufruf an die relevante Implementierung in der Implementierungsklasse weiter; sie agieren also als eine Art Brücke. – 12 – • ExampleServiceSoapBindingImpl.java: Diese Klasse repräsentiert die Implementierung des Web Services und muss nur noch mit Programmlogik erweitert werden. Sie implementiert das Interface des Web Services (ExampleService.java) und damit dessen abstrakte Methoden. • deploy.wsdd und undeploy.wsdd: die Konfigurationsdateien dieses Web Services, die zum Deployen benötigt werden. Die ExampleServiceSoapBindingImpl.java enthält folgenden generierten Rumpf: package axis.services.exampleService; public class ExampleServiceSoapBindingImpl implements axis.services.exampleService.ExampleService{ public java.lang.String sayHello(java.lang.String in0, java.lang.String in1) throws java.rmi.RemoteException { return null; } } Wie man sehen kann, ist die Funktion sayHello, die in der WSDL-Datei beschrieben ist, als Funktion generiert worden. Diese muss nur noch mit einer Funktionalität erweitert werden. Beispielsweise mit folgendem Code: public java.lang.String sayHello(java.lang.String in0, java.lang.String in1) throws java.rmi.RemoteException { String hello = “Hallo “ + in0 +” “ + in1; return hello; } Nun gibt diese Methode die als Parameter übergebenen Vor- und Nachnamen zurück an den aufrufenden Client. Um diesen einfachen Web Service auch aufrufen zu können, muss er noch in Axis deployed werden. Unter der Prämisse, dass Axis in einen lauffähiger Tomcat-Server eingebunden ist, können die Klassen kompiliert und in das WEBINF-Verzeichnis des Tomcat Servers kopiert werden. Anschließend muss Axis durch den AdminClient (ein Web Service zum Deployen von Web Services) informiert werden, dass ein neuer Web Service vorhanden ist. Durch den folgenden Befehl ist dies möglich: java –cp %AXISCLASSPATH% org.apache.axis.client.AdminClient -lhttp://localhost:8080/axis/services/AdminService deploy.wsdd Bei diesem Befehl muss die Datei deploy.wsdd des zu veröffentlichenden Web Services angegeben werden. Daraufhin wird der Tomcat-Server einmalig neu gestartet und der Web Service exampleService ist in Axis konfiguriert und kann benutzt werden. Um diesen Web Service zu testen, kann einfach ein Internetbrowser mit der URL – 13 – http://127.0.0.1:8080/axis/services/exampleService?method=sayHello&in0=Gunnar&in1=Thies aufgerufen werden. Als Ergebnis schickt Axis eine SOAP-Nachricht mit dem Parameterinhalt „Hallo Gunnar Thies“ zurück.9 4 Web Service-Implementierung mit C++ 4.1 Implementierungsvorbereitung Ebenso wie die Java Version bietet die C++-Version von Axis die Möglichkeit, aus einer WSDL-Datei die nötigen Klassen zur Implementierung eines Web Services automatisch erstellen zu lassen. Durch das Java-Tool WSDL2Ws können die server- und clientseitigen Dateien erstellt werden. Hier wird wiederum nur die Implementierung des serverseitigen Web Services vorgestellt. Leider ließen sich für das Tool WSDL2Ws keinerlei Information über den genauen internen Generierungsablauf der Web Service-Klassen (wie bei WSDL2Java) in Erfahrung bringen; daher kann später nur eine Liste mit den in diesem Fall generierten C++-Klassen erläutert werden. Folgender Befehl erstellt die Klassen: java –cp %AXISCPP_CLASSPATH% org.apache.axis.wsdl.wsdl2ws.WSDL2Ws exampleService.wsdl – lc++ sserver An dieser Stelle soll kurz die Plattformunabhängigkeit als kleiner Vorteil der JavaProgrammierung erwähnt werden. Ein in Java geschriebener Web Service funktioniert sowohl mit Axis unter Linux als auch mit Axis unter Windows ohne Änderungen. Dagegen sollte die Zielplattform auf der ein C++ Web Service zum Einsatz kommt, bereits vor der Kompilierung bekannt sein: Denn Axis C++ unter Linux benötigt den Web Service als *.so-Datei; unter Windows dagegen als *.dll-Datei.10 4.2 Programmierbeispiel Durch WSDL2Ws werden aus der bereits eingeführten exampleService.wsdl-Datei folgende C++-Klassen für die Implementierung eines Web Services mit Axis C++ erstellt: • 9 exampleService.h: Eine Interfaceklasse (Header) für den Web Service Alternativ wird zum Testen des Web Services das in Kap. 5.3 beschriebene PHP-Client-Skript benutzt. Natürlich ist der Source-Code einer Web Service-Implementierung mit C++ ohne Probleme auf jeder Plattform zu kompilieren und mit Axis C++ verwendbar. Aber die Vorteile der Java-Version, die dagegen komplett plattformunabhängig ist, bietet C++ nicht. 10 – 14 – • exampleService.cpp: Dies ist die Klasse für die Implementierung der Logik des Web Services; analog zur ExampleServiceSoapBindingImpl.java der JavaVersion (implementiert das Interface) • exampleServiceService.cpp: Hierin sind zwei Funktionen für die Erstellung der dynamischen Bibliothek definiert (*.dll bzw. *.so) • exampleServiceWrapper.cpp und exampleServiceWrapper.h: Interface und Implementierung eines Wrappers11 für den Web Service • deploy.wsdd, undeploy.wsdd: Dateien zum veröffentlichen des Web Service in Axis • make.am: Make-File zur Erstellung der C++-Bibliothek Analog zu der Java-Version von Axis muss nur noch das Gerüst in der exampleService.cpp-Klasse mit der Programmlogik gefüllt werden, um den Web Service fertig zu stellen. Die Ergänzung des Funktionsrumpfs mit einer Rückgabefunktion in der Methode sayHello wird nach dem Vorbild des oben besprochenen Java-Web Services vorgenommen: #include "exampleService.h" exampleService::exampleService() { } exampleService::~exampleService() { } xsd__string exampleService::sayHello(xsd__string Value0, xsd__string Value1) { //return null; return "Hallo " + Value0 + " " + Value1; } Hier wird also bei Aufruf der Methode sayHello (mit zwei Parametern) ein Rückgabewert mit der Grußformel zurückgegeben. Um den Web Service in Axis einbinden zu können, muss anschließend mit einem C++Kompiler eine Bibliotheksdatei (für Windows eine *.dll-Library oder für Linux eine *.so-Datei) erstellt werden. Diese fertige Bibliotheksdatei kopiert man in das Webservice-Verzeichnis des eingebetteten Axis im Apache Webserver. Der letzte Schritt besteht 11 Eine Wrapper-Klasse ist ein grundlegendes Entwurfsmuster bei der Softwareentwicklung. Sie schafft eine Hülle für eine andere Klasse, um deren Methoden zu erweitern oder zu vereinfachen (bzw. deren Aufruf zu vereinheitlichen). Ähnlich zu einer Skeletonklasse in Axis Java, leitet die Wrapper-Klasse hier die Methodenaufrufe an die umschlossene Klasse weiter. – 15 – nun wieder in der Anpassung der Konfigurationsdatei von Axis (server.wsdd), um diesen Web Service zu veröffentlichen. Dazu werden folgende Informationen eingetragen: 1: 2: 3: 4: 5: 6: <service name="exampleService" provider="CPP:RPC" description=”exampleService "> <parameter name="allowedMethods" value="sayHello"/> <parameter name="className" value="H:\Axis_C\Apache2\axis\webservices\exampleService.dll"/> </service> • Der Name des Web Services (Zeile 1). • Die Art des Aufrufs (der Provider): RPC – Remote Procedure Call (Zeile 1) • Die erlaubten aufrufbaren Methoden (Zeile 3): hier nur die sayHello-Methode • Der Pfad der Bibliotheksdatei (Zeile 4-5): hier eine Windows *.dll-Datei Nach einem anschließenden Neustart des Apache Webservers kann der Beispiel-Web Service aufgerufen werden. Um ihn zu testen, muss ein Axis C++-Client implementiert werden, der den Web Service aufruft. Mit anderen Arten des Aufrufs gibt es massive Probleme, die im Rahmen dieser Ausarbeitung nicht gelöst werden konnten. Das Aufrufen des C++-Web Services per Web Browser wie in der Axis Java Version ist nicht möglich, da für Axis C++ kein Servlet (Server Applet) vorhanden ist, das eine HTTPAnfrage an das Axis-Framework weitergeben könnte. Auch ist das Aufrufen des Web Services weder über einen Axis Java Client noch über das in Kapitel 5.3 gezeigte PHPSkript möglich, da ein Fehler in Axis C++ auftritt. Bei Aufrufen durch Java wie auch durch PHP gibt die von Axis C++ empfangene SOAP-Nachricht trotz korrekt konfigurierter WSDD-Datei folgende Fehlermeldung an: “AxisWsddException:Requested method is not allowed” . Dieses Problem ist den Entwicklern bekannt12 und wird hoffentlich in zukünftigen Versionen behoben werden. 12 Axis-C-User-Forum am 30.06.05: http://www.mail-archive.com/[email protected]/msg00137.html (Entgegen des Foren-Beitrags trat diese Fehlermeldung auch bei dem Service-Stil „RPC-Service“ und nicht nur bei „Document-Service“ auf.) – 16 – 5 Technologiebetrachtung 5.1 Sicherheit und Authentifizierung Die zunächst einfachste Möglichkeit, Web Services sicherer zu gestalten, ist die Benutzung des SecureSocketLayer-Verfahrens13: Damit wird die Kommunikation vom Client zum Server verschlüsselt, und keine Informationen werden im Klartext über das Internet verschickt. Ein Vorteil dabei ist, dass Axis dazu nicht konfiguriert werden muss, vielmehr muss der Web Server das SSL-Verfahren unterstützen, damit der Client eine SSLVerschlüsselung zum Server aufbauen kann. Ist dies gegeben, kann die Kommunikation zwischen Axis und einem Client komplett verschlüsselt ablaufen: Die Datenpakete werden vom Client verschlüsselt und vom Server, bevor sie an das Axis-Framework übergeben werden, wieder entschlüsselt. Weitergehende speziellere Verfahren sind z.B. XML-Signature14, bei dem eine Prüfsumme15 (ähnlich einem md5-Hash) der kompletten SOAP-Nachricht erstellt und mitgeschickt wird, um den Absender der Nachricht zu verifizieren (dafür wird das Public Key Verfahren angewendet; siehe [VA04]). Darüber hinaus existieren auch Verschlüsselungskonzepte, die wahlweise die Nachrichtenpakete komplett oder auch nur einzelnen Teile der SOAP-Nachricht verschlüsseln. Hier ist beispielsweise XML-Encryption16 zu nennen: Dieses Verfahren wurde im Jahre 2002 vom W3C als Empfehlung veröffentlicht. Damit können gesamte XML-Elemente inklusive deren Unterelemente oder wahlweise auch nur deren Inhalte verschlüsselt werden. Dafür wird in speziellen Tags angegeben, mit welchem Verfahren der jeweilige Inhalt verschlüsselt wurde. So könnten z.B. Kreditkarten-Informationen verschlüsselt geschickt werden. Der Schlüssel muss dann entweder dem Empfänger bekannt sein oder dieser muss in der XML-Nachricht mitgeschickt werden (in diesem Fall sollte er natürlich ebenfalls verschlüsselt werden, beispielsweise durch asymmetrische Verschlüsselungsverfahren; siehe [VA04]). Eine Initiative, die unter anderem von IBM, Microsoft und VeriSign gegründet wurde, bemüht sich auf der Grundlage von WS-Security (also XML-Signature und XMLEncryption) ein Framework zur Verbesserung der Sicherheit im Umgang mit Web Services zu konzeptionieren (siehe [9]). 13 Einstieg in SSL mit weiteren Links unter [6] Weiter Informationen über XML-Signature in [TH04 ],[DA04] oder unter [7] 15 Hierbei muss die XML-Datei durch einen XML-Parser kanonisch geordnet werden, da sonst eine Prüfsumme (durch die freie Formatierung von XML-Dokumenten) keinen Sinn machen würde. 16 Weitere Informationen über XML-Encryption in [TH04],[DA04] oder unter [8] 14 – 17 – Um XML-Signature oder XML-Encryption in Axis zu benutzen, können zusätzliche Handler in die globale Request- und Response-Kette eingebaut werden, die die erforderlichen Sicherheitsmaßnahmen (wie z.B. Verschlüsselung oder auch Authentifizierung) auf das MC-Objekt ausführen. 5.2 SOAP Attachments Ein Problem, das sich im Zusammenhang mit Web Services öfters ergibt, ist das Verschicken von größeren Datenmengen, wie beispielsweise Bildern oder anderen größeren Dateien (beispielsweise Zip- oder Tar-Archive). Daher gibt es die Möglichkeit von SOAP Attachments. Axis unterstützt das Verschicken von Dateien durch das DIME(Direct Internet Message Encapsulation) sowie das MIME- (Multipurpose Internet Mail Extension) Format. Im MC-Objekt kann die Art der Codierung festgelegt werden. Handler zur En- und Decodierung von binären Daten sind im Axis-Framework bereits enthalten und können so ohne großen Mehraufwand eingebunden werden. Durch das Verwenden des DIME- oder MIME-Formats lassen sich somit beliebige binäre Daten als Anhang mit einer SOAP-Nachricht mitschicken. Weitere Informationen sind unter [10] zu finden. 5.3 Interoperabilität Oft wird als großer Vorteil von Web Services die Interoperabilität zwischen Client und Server unabhängig von der jeweils gewählten Programmiersprache hervorgehoben. Somit kann der Web Service beispielsweise in C++ geschrieben sein und von einem JavaClient aufgerufen werden und umgekehrt. Leider gibt es diesbezüglich bei dem AxisFramework ein Problem: zwar ließ sich der exampleService als Java-Variante sowohl von einem C++-Client, einem Java-Client als auch von einem (Axis-unabhängigen) PHP-Client aufrufen; als C++-Variante ließ er sich aber nur durch einen C++-Client ansprechen. In Axis-Developer-Foren ist dieses Problem bekannt17, wurde bisher aber nicht behoben. Mit folgendem PHP-Code lassen sich Web Services aufrufen: <?php //Hier wird die verwendete NuSOAP Erweiterung eingebunden require_once('nusoap.php'); // Client-Instanz erstellen $client = new soapclient('http://127.0.0.1:8080/axis/services/exampleService'); //Java Variante // Hier wird die SOAP-Methode von unserem Beispiel-Service aufgerufen $result = $client->call('sayHello', array('in0' => 'Gunnar', 'in1' => 'Thies'), 'uri:helloworld', 'uri:helloworld/hello'); 17 s.o. Fußnote 12. – 18 – //Ausgabe des Rückgabewertes print_r($result);?> 6 Zusammenfassung und Ausblick Mit dem Axis-Framework können Web Services relativ leicht und schnell entwickelt und angeboten werden. Da Axis im Grunde nur eine Verarbeitungsschicht für (SOAP-) Nachrichten ist, muss es zusammen mit einem Webserver wie Apache HTTP oder dem Tomcat Server verwendet werden (bzw. dem SimpleAxisServer). Durch die Möglichkeit, Java oder C++ zur Implementierung der Web Services zu benutzen, können beispielsweise schon vorhandenen Codefragmente (gerade im Bereich C/C++) ebenfalls in Web Services benutzt werden. Die durch die Struktur von Axis gegebene Erweiterbarkeit – durch eigene Handler – erlaubt auch die Realisierung von Web Services mit Authentifizierungs- und Verschlüsselungsverfahren. Damit lassen sich auch sicherheitsrelevante Konzepte mit Web Services umsetzen. Ebenso können auch beliebige Anhänge im DIME oder MIME-Verfahren mit Axis geschickt und empfangen werden. Axis ist daher eine verbreitete und beliebte Laufzeitumgebung für Web Services. Die Java-Version ist bereits ziemlich ausgereift und funktioniert (jedenfalls bei dem hier getesteten Web Service) einwandfrei. Die C++-Version hat wohl noch einige Kinderkrankheiten, die mit zukünftigen Releases aber wohl behoben werden. Generell lassen sich aber mit Axis, vor allem auch durch die unterstützenden Tools wie WSDL2Java und WSDL2Ws, relativ schnell Ideen mit Web Services verwirklichen. – 19 – Literaturverzeichnis [TH04] Thomas, Erl: Service-Oriented Architecture, Prentice Hall, 2004. [DA04] Wang, Dapeng (Hrsg.); Bayer, Thomas; Frotscher, Thilo; Teufel, Marc: Java Web Services mit Apache AXIS, Software & Support, 2004. [ER03] Eickstädt, D.; Reuhl, T.: Java mit Open Source-Tools, Markt+Technik, 2003. [VA04] Vacca, J.R.: Public Key Infrastructure Building Trusted Application and Web Services, CRC Press LLC, 2004. Internet-Adressen (alle zuletzt abgerufen: 15.06.2005) [1] Apache Axis Projekt: http://ws.apache.org/axis/ [2] W3C – Web Service Activity: http://www.w3.org/2002/ws/Activity [3] Axis User’s Guide (Java): http://ws.apache.org/axis/java/user-guide.html [4] Axis Handler Tutorial C++ : http://ws.apache.org/axis/cpp/arch/handler.html [5] SOAP Version 1.2 vom W3C: http://www.w3.org/TR/2003/REC-soap12-part2-20030624/#soapforrpc [6] SSL in Wikipedia: http://de.wikipedia.org/wiki/Secure_Sockets_Layer [7] XML-Signature Syntax and Processing (W3C): http://www.w3.org/TR/xmldsig-core/ [8] XML Encryption Syntax and Processing (W3C): http://www.w3.org/TR/xmlenc-core/ [9] Web Services Security (IBM): http://www-106.ibm.com/developerworks/webservices/library/ws-secure/ [10] Grundlegendes zu DIME und WS-Attachments: http://www.microsoft.com/germany/msdn/library/xmlwebservices/Grundl egendesZuDIMEUndWSAttachments.mspx – 20 – Anhang Anhang A: WSDL-Datei exampleService.wsdl des Beispiel Web Services <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions targetNamespace="http://127.0.0.1:8080/axis/services/exampleService" xmlns:apachesoap="http://xml.apache.org/xml-soap" xmlns:impl="http://127.0.0.1:8080/axis/services/exampleService" xmlns:intf="http://127.0.0.1:8080/axis/services/exampleService" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <wsdl:message name="sayHelloResponse"> <wsdl:part name="sayHelloReturn" type="xsd:string"/> </wsdl:message> <wsdl:message name="sayHelloRequest"> <wsdl:part name="in0" type="xsd:string"/> <wsdl:part name="in1" type="xsd:string"/> </wsdl:message> <wsdl:portType name="exampleService"> <wsdl:operation name="sayHello" parameterOrder="in0 in1"> <wsdl:input message="impl:sayHelloRequest" name="sayHelloRequest"/> <wsdl:output message="impl:sayHelloResponse" name="sayHelloResponse"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="exampleServiceSoapBinding" type="impl:exampleService"> <wsdlsoap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="sayHello"> <wsdlsoap:operation soapAction=""/> <wsdl:input name="sayHelloRequest"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://seminar.samples" use="encoded"/> </wsdl:input> <wsdl:output name="sayHelloResponse"> <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="http://127.0.0.1:8080/axis/services/exampleService" use="encoded"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="exampleService"> <wsdl:port binding="impl:exampleServiceSoapBinding" name="exampleService"> <wsdlsoap:address location="http://127.0.0.1:8080/axis/services/exampleService"/> </wsdl:port> </wsdl:service> </wsdl:definitions> – 21 – Abschließende Erklärung Ich versichere hiermit, dass ich meine Ausarbeitung „Apache Axis“ selbstständig und ohne fremde Hilfe angefertigt habe, und dass ich alle von anderen Autoren wörtlich übernommenen Stellen wie auch die sich an die Gedankengänge anderer Autoren eng anlegenden Ausführungen meiner Arbeit besonders gekennzeichnet und die Quellen zitiert habe. Münster, den 08. Juli 2005 _____________________________ (Gunnar Thies)
