Praktikum Middleware

Praktikum Middleware Institut für verteilte Systeme Thema: Web Service Migration Betreuer : Holger Schmidt Von : Lionel Montheu WS 2006/2007

Inhaltsverzeichnis 1 Aufgabenbeschreibung... 4 2 Grundlegende Technologien... 4 2.1 CORBA... 4 2.2 Web Services... 4 2.3 Apache Axis... 4 2.3.1 Axis Handler... 4 2.4 JXTA... 5 3 Design der kontextsensitiven Migration... 5 4 Kontextsensitive Web Service Migration... 5 4.1 AOMObjectImpl... 6 4.1.1 AOMObject... 7 4.1.2 BuiltInStatefulObject... 7 4.1.3 AOMObjectImpl... 7 4.2 AOM Manager... 7 4.3 Der AOM Store Service... 7 4.4 Der Generic Factory Service... 8 4.5 AOM Factory... 8 4.5.1 Installation eines Web Services... 8 4.6 Der Factory Finder Service... 8 5 Dienstkonsistenz... 8 6 Erreichbarkeit eines migrierenden Dienstes... 9 6.1 Service ID... 9 6.2 LocationServer... 9 6.3 LocationClient... 10 6.4 HTTPRedirector... 11 7 Codeladedienst... 11 7.1 Code Server... 12 7.2 Code Client... 12 8 Systemkonfiguration... 13 9 Schlusswort... 13 10 Literatur... 13

Abbildungsverzeichnis Abbildung 1 Design der kontextsensitiven Migration... 5 Abbildung 2 Detaillierter Ablauf der kontextsensitiven Migration... 6 Abbildung 3 UML Klassendiagramm für die kontextsensitive Migration... 7 Abbildung 4 Beispiel eines generierten Deployment Descriptors... 8 Abbildung 5 Aktivierung des SOAPInterceptor in AXIS... 9 Abbildung 6 UML Sequenzdiagramm der Verzögerung von Aufrufen... 10 Abbildung 7 Ein erweiterter WSDL Dokument mit Service ID und Zustandsinformationen. 10 Abbildung 8 UML Sequenzdiagramm der kontextfreien Verschiebung mit Location Service11 Abbildung 9 UML Sequenzdiagramm der Weiterleitung von Methodenaufrufen... 11 Abbildung 10 UML Sequenzdiagramm der vereinfachten Migration mit Code Download... 12

1 Aufgabenbeschreibung Das Ziel dieses Praktikums besteht darin, das bestehende Konzept des Life Cycle Service, das bereits für CORBA Objekte realisiert ([1], [2]) wurde, auf Web Services umzusetzen. Durch dieses Konzept kann ein Objekt von einem Ort zu einem anderen Ort wandeln. Für Web Services bedeutet dies, dass ein existierender Web Service deinstalliert und an einem anderen Ort installiert wird. Die Migration erfolgt dabei mit Berücksichtigung des Dienstzustands. Das bedeutet, dass der Wert der Variablen vor der Migration gespeichert und nach der Migration im neuen Dienst wiederhergestellt wird. Damit der Zugriff auf einen migrierenden Dienst konsistent bleibt, soll der Zugriff auf diesen Dienst blockiert werden, solange dieser sich in einer Life Cycle Methode befindet. Weiterhin wird der Code, der einen bestimmten Web Service implementiert, am Zielort gebraucht, um den Service dort zu installieren. Wenn dieser Code nicht vorhanden sein sollte, besteht die Möglichkeit ihn mittels eines auf JXTA basierten Ladediensts herunter zu laden. Schließlich sollen Klienten, die auf einen Web Service zugreifen, (der eventuell migriert) nichts von der Migration merken und den gleichen Web Service unter seiner ursprünglichen Adresse erreichen können. Zu diesem Zweck wurde ein Weiterleitungsdienst implementiert. Bei der Implementierung der Migration wurden ausschließlich Web Services der Plattform Apache Axis (2.3) berücksichtigt. 2 Grundlegende Technologien 2.1 CORBA Die Common Object Request Broker Architecture (kurz CORBA) ist eine objektorientierte Middleware, die plattformübergreifende Protokolle und Dienste definiert und von der Object Management Group (OMG) entwickelt wird. CORBA vereinfacht das Erstellen verteilter Anwendungen in heterogenen Umgebungen [10]. 2.2 Web Services Ein Web Service bzw. Webdienst ist eine Software-Anwendung, die mit einem Uniform Resource Identifier (URI) eindeutig identifizierbar ist und deren Schnittstellen mit XML definiert, beschrieben und gefunden werden können. Ein Web Service unterstützt die direkte Interaktion mit anderen Software-Agenten unter Verwendung XML-basierter Nachrichten durch den Austausch über internetbasierte Protokolle [11]. Ein Web Service bietet also Methoden an, die von entfernten Klienten aufgerufen werden können. Dafür werden die angebotenen Methoden in der Web Service Description Language (WSDL) beschrieben und den Klienten zugänglich gemacht. Ferner werden die Methodenanrufe in Nachrichten verpackt und den Empfänger geschickt. Das Format dieser Nachrichten (Anfrage und Antwort) wird durch das Simple Object Access Protocol beschrieben. 2.3 Apache Axis Apache Axis (Apache extensible Interaction System) ist eine SOAP Engine zur Konstruktion von Web Services und Client-Anwendungen [12]. Axis wird in einem Servlet Container (zum Beispiel Tomcat) installiert und ermöglich unter anderen Web Services zu de- und installieren, sowie WSDL Dokumenten bzw. Stub Code automatisch zu generieren. Für weitere Informationen über Apache Axis siehe [9]. 2.3.1 Axis Handler Apache Axis unterstützt das Konzept von so genannten Handler bzw. Handlerketten. Je nachdem ob die Handler auf Client Seite oder auf Server Seite agieren, unterscheidet man zwi-

schen clientseitigen und serverseitigen Handlern. Ein solcher Handler ist so konfiguriert, dass er SOAP Nachrichten zu einem bestimmten Zeitpunkt abfängt, eine Aufgabe durchführt, und die Nachricht anschließend weiterleitet. Mehr zu diesem Thema kann man unter [14] erfahren. 2.4 JXTA JXTA ist ein Projekt zur Standardisierung von Peer-to-Peer Anwendungen durch frei zugängliche Protokolle. Es werden unter einer Open-Source-Lizenz veröffentlichte Libraries (Referenzbibliotheken) für die Programmiersprachen Java, C und weitere Sprachen bereitgestellt [13]. Für weitere Information über Peer-to-Peer Systeme siehe [4]. Die Verwendung dieser Referenzbibliotheken ist unter anderen in [6] und [7] dokumentiert. 3 Design der kontextsensitiven Migration Ziel der Arbeit ist die Realisierung der kontextsensitiven Dienstmigration. Das hierfür entwickelte Konzept wird im folgenden Abschnitt vorgestellt. Abbildung 1 zeigt die verschiedenen Akteure, die bei der Migration eines Web Services eine Rolle spielen. Um den Prozess zu starten, ruft ein Klient eine entfernte Methode (copy oder move), die die Migration des aufgerufenen Web Services (ServiceX) auslöst. Nach dem Methodenaufruf (auf Klient Seite) wird (soweit konfiguriert) gegebenenfalls der Methodenauruf weitergeleitet. Wenn die Methode (auf Service Seite) aufgerufen wird, wird der aktuelle Dienstzustand im AOMStore gespeichert. Anschließend wird der implementierende Code publiziert (soweit vorhanden) und danach wird die entsprechende Klassenfabrik, die mittels des FactoryFinder gefunden wurde, veranlasst, den neuen Web Service zu installieren. Bei der Erzeugung des neuen Web Services wird der Code (falls nicht lokal vorhanden) herunter geladen. Schließlich wird falls erforderlich der aktuelle Ort des migrierten Web Services registriert. Abbildung 1 Design der kontextsensitiven Migration 4 Kontextsensitive Web Service Migration Unter der Migration eines Web Services versteht man, dass dieser Service von seinem aktuellen Ort (also von dem Servlet Container, wo dieser Service installiert ist) auf einen anderen Ort kopiert oder verschoben wird. Ein solcher Web Service bietet spezielle generische Methoden, copy und move, die beim Aufruf die Kopie bzw. die Verschiebung des Dienstes veranlassen. Bei dieser Operation wird der aktuelle Zustand von diesem Web Service (also der Wert von implementierungsunabhängigen Variablen) nach der Migration wiederhergestellt wird. Es ist auch möglich, dass eine andere Implementierung für den zu kopierenden Web Service, verwendet wird. Das ist die kontextsensitive Dienstmigration. Ein Web Service, der die Migration unterstützen soll, muss bestimmte Anforderungen (siehe 4.1) erfüllen, damit die Migration möglich ist.

Wie oben erwähnt ist es möglich, dass der migrierende Web Service am neuen Ort durch eine andere Implementierungsklasse (verschieden von der ursprünglichen Klasse) ersetzt bzw. adaptiert werden kann. Abbildung 2 zeigt ein möglicher Ablauf der kontextsensitiven Dienstmigration. Für diese Operation kommen verschiedene Akteure zum Einsatz. Diese werden in den folgenden Abschnitten erklärt. Abbildung 2 Detaillierter Ablauf der kontextsensitiven Migration 4.1 AOMObjectImpl Damit ein Web Service die kontextsensitive Migration unterstützt, kann er einfach die Klasse AOMObjectImpl erweitern. Diese Klasse implementiert die Migration auf generische Weise. Das untere Klassendiagramm (siehe Abbildung 3) zeigt beteiligte Klassen, die die benötigten Funktionalitäten für die Realisierung der Migration zur Verfügung stellen.

Abbildung 3 UML Klassendiagramm für die kontextsensitive Migration 4.1.1 AOMObject AOMObject ist die Schnittstelle, die die Methoden zum Kopieren und zum Verschieben eines Dienstes anbietet. 4.1.2 BuiltInStatefulObject Ermöglicht, aus einer Java Instanz den Namen, bzw. den Wert einer Variable abzufragen bzw. den Wert aller Variablen als XML Text darzustellen und berücksichtigt dabei nur die Java Datentypen, die sich Standardmäßig ([8], [15]) auf XML Datentypen abbilden lassen (mit Ausnahme von ValueTypes). 4.1.3 AOMObjectImpl Das AOMObjectImpl ist ein Subtyp von BuiltInStatefulObject (4.1.2), der zusätzlich die AOMObject- Schnittstelle (4.1.1) implementiert. Er stellt zusätzlich Methoden für die kontextfreie Dienstmigration zur Verfügung. 4.2 AOM Manager Wenn eine kontextsensitive Operation bei einem Web Service aufgerufen wird, wird sie an den AOM Manager delegiert. Der AOM Manager ist dann für den weiteren Ablauf der Migration verantwortlich. Er kontaktiert den Factory Finder Service und sucht nach einem Generic Factory Service, der den gewünschten Web Service installieren kann. Nachdem ein solcher Generic Factory Service gefunden wurde, wird der aktuelle Zustand (des Web Services) an den AOM Store Service geschickt, um dort gespeichert zu werden. Dieser Zustand wird einer eindeutigen Service ID (6.1) zugeordnet. Schließlich wird der Generic Factory Service veranlasst, den neuen Web Service zu installieren und anschließend den Dienstzustand wiederherzustellen. 4.3 Der AOM Store Service Damit der aktuelle Zustand eines Web Service nach der Migration wiederhergestellt werden kann, wird dieser Zustand zu Beginn der Migration zwischengespeichert. Für die Speicherung des Zustands ist der AOM Store Service zuständig. Er bietet also die Möglichkeit, den gespeicherten Zustand eines Web Services (anhand der Service ID) zu laden.

4.4 Der Generic Factory Service Dieser spezieller Web Service ist dafür zuständig, andere Web Services zu generieren bzw. zu installieren. Dafür bietet er eine entsprechende Prozedur adapt, die von entfernten Clients aufgerufen werden kann. Bei Aufruf vom von adapt wird wie Aufgabe an die AOMFactory delegiert. Damit es bekannt ist, welche Web Services ein Generic Factory Service in der Lage ist zu generieren, ist es erforderlich, dass dieser Generic Factory Service sie alle registriert. Für das Hinzufügen und das Entfernen von Registrierungen ist der Factory Finder Service zuständig. 4.5 AOM Factory Der AOM Factory ist für den weiteren Ablauf der kontextsensitiven Migration (im Zielort) verantwortlich. Er lädt zuerst den (beim AOM Store gespeicherten) Dienstzustand. Anschließend, wird geprüft, ob der Code, der den neuen Web Service implementiert, lokal vorhanden ist. Fall es nicht der Falls ist, versucht die AOMFactory diesen Code herunter zu laden(siehe 7.2). Anschließend wird der neue Web Service installiert 4.5.1 Installation eines Web Services Um einen Java-basierten Web Service mit AXIS zu installieren muss man angeben welche Java-Klasse diesen Web Service implementiert, sowie ein WSDL Dokument. Dieses Dokument wird mittels AXIS automatisch generiert (im Verzeichnis $Axispath/Web- Inf/migration/wsdl) und anschließend um eine Service ID sowie um Informationen über implementierungsunabhängigen Variablen erweitert (Abbildung 7). Die Variablenname können durch einen Aufruf von getstatenames (Abbildung 3, BuiltInStatefulObject) ermittelt werden. Danach wird das WSDL Dokument im Deployment Descriptor referenziert und anschließend wird der Deployment Descriptor an AXIS abgeschickt. <deployment> <service name="aomautomat" provider="java:rpc"> <parameter name="allowedmethods" value="*" /> <parameter name="classname" value="test.services.aomautomat" /> <parameter name="scope" value="application" /> <wsdlfile>..migration\wsdl\aomautomat.wsdl</wsdlfile> </service> </deployment> Abbildung 4 Beispiel eines generierten Deployment Descriptors Folglich wird der geladene Zustand im neuen Webdienst geschrieben. Schließlich wird die Post-Migration Methode im neuen Web Service aufgerufen. Diese Methode kann überschrieben werden, um Operation festzulegen (bzw. Aktualisierung, ), die unmittelbar nach einer Migration stattfinden sollen. 4.6 Der Factory Finder Service Der Factory Finder Service pflegt eine Registrierungsdatei (im XML Format), die die Information enthält, welcher Generic Factory Service welchen Web Service generieren kann. Er bietet Funktionen an, die die Registrierung (register) Generic Factory Services, die Suche (findfactories) nach Generic Factory Services (die einen bestimmten Webdienst installieren können) sowie das Entfernen (unregister) von Registrierungen ermöglichen. 5 Dienstkonsistenz Damit der Zustand eines Web Services, der dabei ist, zu migrieren, konsistent bleibt, werden alle weiteren Aufrufe auf diesen Web Service solange verzögert, bis die Migration abgeschlossen ist. Die Einheit die diese Verzögerung realisiert ist der SOAPInterceptor

(Abbildung 6). Der SOAPInterceptor ist ein Handler, der in der Axis Engine so eingestellt ist, dass er alle ankommenden SOAP Nachrichten abfängt. Er überprüft, ob es sich bei einer SO- AP Nachricht um eine life cycle Prozedur handelt. In diesem Fall wird der Web Service, für den diese Nachricht ist, markiert und die Nachricht wird an diesen Web Service normal weitergeleitet. Alle weiteren SOAP Nachrichten für diesen Web Service werden so lange verzögert, bis die Migration beendet ist. In diesem Fall wird die SOAP Antwort, die das Ende der Migration signalisiert, auch abgefangen und die Markierung des entsprechenden Web Service wird aufgehoben. Erst dann werden die verzögerten SOAP Nachrichten freigegeben. Der SOAPInterceptor Handler ist ein serverseitiger Handler auf Transport Ebene[14], der in der AXIS Konfigurationsdatei (serverconfig.wsdd) aktiviert werden kann (siehe Abbildung 5). <transport name="http"> <requestflow> <handler type="urlmapper"/> <handler type="java:org.apache.axis.handlers.http.httpauthhandler"/> <handler type="java:lcs.services.handler.soapinterceptor"/> </requestflow> <responseflow> <handler type="java:lcs.services.handler.soapinterceptor"/> </responseflow>... </transport> Abbildung 5 Aktivierung des SOAPInterceptor in AXIS 6 Erreichbarkeit eines migrierenden Dienstes Wenn ein Web Service auf einem anderen Ort verschoben wird (er wird also von seinem aktuellen Ort deinstalliert), ist er von Clients nicht mehr zu erreichen. Da diese von der Migration nicht Bescheid wissen und nur die ursprüngliche Adresse des Web Service besitzen. Damit der Web Service trotz der Migration unter der ursprünglichen Adresse erreichbar bleibt, wurde eine auf JXTA basierte Location Service Funktionalität implementiert. Das grundlegende Element dieses Dienstes ist die Service ID (siehe Abbildung 7). 6.1 Service ID Jeder Web Service, der fähig ist, zu migrieren, besitzt eine eindeutige ID, die sich (anfangs) aus der Adresse dieses Services berechnen lässt: zum Beispiel aus der Addresse http://localhost:8080/axis/service/myservice?wsdl wird der Hashcode berechnet. Dieser Wert ist dann die Service ID und wird im zugehörigen WSDL Dokument integriert wird. Bei move übernimmt der neue Web Service die ursprüngliche ID. Für die Registrierung der ID kommen der Location Client und der Location Server zum Einsatz. Diese Funktionalität wird durch den HTTPRedirector verwendet. 6.2 LocationServer Der Location Server ist ein zentraler JXTA Peer, der den Location Service Dienst zur Verfügung stellt. Er wartet auf Verbindungen von Clients über eine bestimmte (von den Clients bekannten) JXTA Pipe. Er kann eine neue Location registrieren, eine bestehende Location aktualisieren und eine bestimmte Location ermitteln. Bei der neuen Registrierung wird zu einer festen Service ID die entsprechende WSDL Adresse zugeordnet und in einer XML Datei gespeichert. Bei der Aktualisierung wird zu einem Service ID die neue WSDL Adresse gespeichert. Dies impliziert, dass ein Web Service bei der Verschiebung auf einen neuen Ort die gleiche Service ID behält. Diese ID lässt sich aus der WSDL Adresse berechnen, so dass ein Client anhand dieser ID die entsprechende Adresse (soweit registriert) anfordern kann.

Abbildung 6 UML Sequenzdiagramm der Verzögerung von Aufrufen <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/> <wsdl:types> </wsdl:types> <wsdl:porttype name="aomautomat"> <wsdl:operation name="getkontostand"> </wsdl:operation> <wsdl:service name="aomautomatservice"> <wsdl:port> </wsdl:port> <ns:serviceid value="1329345329" /> <ns:states xmlns:ns="www.web-service.de/migration"> <state>konto</state> </ns:states> </wsdl:service> </wsdl:definitions> Abbildung 7 Ein erweiterter WSDL Dokument mit Service ID und Zustandsinformationen 6.3 LocationClient Der Location Client ist ein JXTA Peer, der die Dienste des Location Servers in Anspruch nimmt. Bei einer erfolgreichen Verschiebung eines Web Service wird zuerst die neue Adresse des Web Service beim Location Server aktualisiert, bevor der ursprüngliche Web Service deinstalliert wird.

Abbildung 8 UML Sequenzdiagramm der kontextfreien Verschiebung mit Location Service 6.4 HTTPRedirector Es kann vorkommen, dass ein Client einen entfernten Methodenaufruf bei einem Web Service ausführt, der inzwischen migriert ist und unter seiner ursprünglichen Adresse nicht mehr erreichbar ist. Im Normalfall würde ein solcher Aufruf fehlschlagen. Es besteht aber die Möglichen, bei jedem entfernten Methodenaufruf die aktuelle Adresse des zugehörigen Web Service zu ermitteln und den Methodenaufruf an dieser Adresse weiter zu leiten. Damit dies möglich ist, muss der Client so konfiguriert sein, dass alle Anfragen über den HTTPRedirector vorbeigehen bevor sie ihr Ziel erreichen. Der HTTPRedirector ist als Handler (auf Client Seite) realisiert, und kann somit die SOAP Nachrichten bei Bedarf umlenken. Abbildung 9 UML Sequenzdiagramm der Weiterleitung von Methodenaufrufen 7 Codeladedienst Damit die Generic Factory einen Web Service im eigenen Servlet Container installieren kann, wird der Code (z.b. die.jar Datei), der diesen Web Service implementiert benötigt. Es kann

vorkommen, dass dieser Code nicht lokal vorhanden ist. In diesem Fall wird versucht, diesen Code zu laden und die entsprechende Klasse in der JVM zu laden. Für den Download ist der Code Client zuständig. Der migrierende Web Service kann diesen Code zu Beginn der Migration freigeben, so dass die zuständige Factory diesen bei Bedarf herunterladen und schließlich den neuen Web Service erzeugen kann. Der Codeladedienst wurde aus einer existierenden Bibliothek im System integriert. Für genauere Informationen darüber, wie der vorhandene Codeladedienst über JXTA realisiert wurde, siehe [3] und [5]. 7.1 Code Server Der Code Server ist als JXTA Peer realisiert. Er gibt bestimmte Dateien zum Download frei und publiziert diese Dateien entsprechend, so dass ein potentieller Client herausfinden kann, ob eine bestimmte Datei momentan durch den Code Server freigegeben ist. Während der Migration einer bestimmten Klasse (X), wird der Code Server gestartet und veranlasst, den Code der die Klasse X implementiert, zu publizieren. Dafür wird im CodeDownload Verzeichnis nach einer Datei X.jar gesucht. Falls sie gefunden wird, wird sie bis zum Ende der Migration publiziert und steht zum Download zur Verfügung. 7.2 Code Client Der Code Client ist ein weiterer JXTA Peer, der die Dienste des Code Servers in Anspruch nimmt, um nach dem Code zu suchen, der eine bestimmte Klasse implementiert. Dafür tritt er im Peer Group des Code Servers bei, dann sucht er in den publizierten Dateien. Im Erfolgsfall wird die entsprechende Datei herunter geladen und die implementierte Klasse in der JVM geladen. Abbildung 10 UML Sequenzdiagramm der vereinfachten Migration mit Code Download

8 Systemkonfiguration Es gibt eine Reihe von Konfigurationsdateien, mit denen Systemklassen konfiguriert werden: Location Server Der Location Server speichert die aktuellen Registrierungen von Adressen in der Datei "$WorkingDir/redirections.xml". Factory Finder Service Der Factory Finder Service speichert die Registrierungen von Generic Factory Services in der Datei "$WorkingDir/registrations.xml" Config.properties Diese Datei enthält bestimmte Default-Systemeintellungen: 1. axis.tomcathome Das Home-Verzeichnis von Tomcat 2. axis.adminserviceurl Die Adresse des AdminService von Axis, der benötigt wird zum (De-)Installieren von Web Services. 3. axis.servicespath Der relative Pfad, wohin neue Web Services installiert werden 4. lifecycle.factoryfinderwsdl Die WSDL Adresse des Default- Factory Finder Service 5. lifecycle.statestorewsdl Die WSDL Adresse des Default- AOM Store Service 6. lifecycle.updatelocationonmove legt fest, ob nach dem Verschieben eines Services die neue Adresse registriert werden soll. 7. lifecycle.enablelocationrequest Bestimmt, ob während eine Life Cycle Opration (copy, move) jede WSDL Adresse beim Location Server zu verifizieren ist 8. lifecycle.autopublishsourcefile Bestimmt, ob der emigrierende Dienst vor der Migration sein Code publizieren soll. 9 Schlusswort Der durchschnittliche Dauer der kontextsensitiven Verschiebung (move) eines Web Service ohne Codeladedienst und Location Service beträgt 14656 ms. Diese große Zeit liegt hauptsächlich daran, dass AXIS für das Deployment eines Web Services im Schnitt 6249 ms braucht. Die Migration selbst dauert also (nach Berechnung) 2158 ms. Falls der Codeladedienst oder der Location Service aktiviert wird, wird die Gesamtdauer (wegen JXTA) erheblich größer. 10 Literatur 1. Rüdiger Kapitza, Holger Schmidt, Franz J. Hauck. Platform-Independent Object Migration in CORBA. 2005 2. Rüdiger Kapitza, Holger Schmidt, Guido Söldner, Franz J. Hauck. A Framework for Adaptive Mobile Objects in Heterogeneous Environments 3. Dynamic Integration of Peer-to-Peer Services into a CORBA compliant Middleware. 2006 4. Franz J. Hauck, Holger Schmidt. Architektur für verteilte Internetdienste. Unterlagen zur Vorlesung im SS 2006, Uni. Ulm 5. Udo Bartlang: Integration der Peer-to-Peer Plattform JXTA in die CORBAkonforme middleware AspectIX auf Basis des fragmentierten Objektmodells. 2005 6. Brendon J. Wilson. JXTA, News Riders Publishing. 2002 7. Sun Microsystems. JXTA Java Programmer Guide v2. 2003

8. Roberto Chinnici. Java API for XML Based RPC JAXRPC 1.1. Sun Microsystems. 2003 9. The Apache Software Foundation. Web Services Axis. http://ws.apache.org/axis/ 2005. 10. Wikipedia, Die freie Enzyklopädie. Common Object Request Broker Architecture (CORBA). http://de.wikipedia.org/wiki/corba 2006 11. Wikipedia, Die freie Enzyklopädie. Web Services. http://de.wikipedia.org/wiki/web_services 2007 12. Wikipedia, Die freie Enzyklopädie. Apache Axis. http://de.wikipedia.org/wiki/apache_axis. 2006 13. Wikipedia, Die freie Enzyklopädie. JXTA. http://de.wikipedia.org/wiki/jxta. 2006 14. The Apache Software Foundation. Apache Axis. http://ws.apache.org/axis/java/architectureguide.html#handlersandthemessagepathinaxis. 2005 15. Sun Microsystems. Types supported by JAXRPC. http://java.sun.com/j2ee/1.4/docs/tutorial/doc/jaxrpc4.html