Apache Axis. Ausarbeitung im Rahmen des Seminars: Service Computing und Service-Oriented Architectures
|
|
- Stephanie Schuler
- vor 6 Jahren
- Abrufe
Transkript
1 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: vorgelegt von: Prof. Dr. habil. Sergei Gorlatch Dipl.-Inf. Jens Müller Gunnar Thies Kanalstraße Münster Telefon: 0251 / guth@wi.uni-muenster.de Abgabetermin:
2 II Inhaltsverzeichnis Inhaltsverzeichnis...II 1 Einleitung Architektur von Axis Architektur Einführung Struktur der Axis-Engine Ablauf einer Web Service-Anfrage Handler und Chains Web Service Deployment Descriptor Web Service Description Language Web Service-Implementierung mit Java Implementierungsvorbereitung Programmierbeispiel Web Service-Implementierung mit C Implementierungsvorbereitung Programmierbeispiel Technologiebetrachtung Sicherheit und Authentifizierung SOAP Attachments Interoperabilität Zusammenfassung und Ausblick...18 Literaturverzeichnis...19 Internet-Adressen...19 Anhang...20
3 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 Source- Software 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 Internet- Bereich. 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.
4 2 So lassen sich SOAP 2 -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 SAX 3 (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). WSDL 4 -Support zur schnelleren Code-Erstellung bzw. Erstellung von WSDL- Dokumenten 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 Code- Erstellung 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.
5 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
6 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 Dokumentationen 5 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 (WSDD- Datei), 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 Axis- Engine übergeben wird von einem so genannten Transport Listener 6 in ein Message- Context-Objekt (im Folgenden MC-Objekt) umgewandelt. Dieses MC-Objekt enthält alle in der Nachricht enthaltenen Informationen in einer XML-Formatierung, die Axis- Handler verstehen können, und wird an die erste Schicht von Axis (die Transport- Schicht) 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 Siehe: 6 Ein Transport Listener könnte hier beispielsweise ein HTTP-Servlet für Anfragen über einen Webbrowser sein.
7 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.
8 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 Response- Flow. 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 MC- Objekt angewendet werden, können sich von denen des Request-Flows unterscheiden. Ein Handler, der wie der Provider den Wendepunkt vom Request-Flow zum Response- Flow 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 Provider- Handler 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 Axis- Framework vornimmt. Der Handler muss nur für die jeweilige Plattform kompiliert und in der WSDD-Datei für einen Web Service konfiguriert werden.
9 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 XML- Format 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 WSDD- Datei konfiguriert: 1: <deployment xmlns=" 2: xmlns:java=" 3: 4: <!-- Definieren eines servicespezifischen Handlers --> 5: <handler name="track" type="java:samples.userguide.example.loghandler"> 7: <parameter name="filename" value="myservice.log"/> 8: </handler> 9: 10: <!-- Definieren des Web Services, unter Benutzung des Handlers--> 11: <service name="exampleservice" provider="java:rpc"> 12: <requestflow> 13: <handler type="track"/> 14: </requestflow> 15: <parameter name="classname" value="samples.seminar.exampleservice"/> 16: <parameter name="allowedmethods" value="*"/> 17: <parameter name="scope" value="application"/> 18: </service> 19: </deployment> In Zeile 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 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
10 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 SOAP- Standard 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 SOAP- Body 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 SOAP- Nachricht auf XML-Basis zu arbeiten. Dies ist beispielsweise für die Interoperabilität zwischen Systemen nützlich.
11 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.
12 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 Java- Objektsignaturen (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-INF- Verzeichnis 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:
13 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 Generierte Java-Dateien für die serverseitige Implementierung Binding: Implementierungsklasse (und evtl. Skeletonklasse 8 ) Service: 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: ExampleService.java: Interface des Web Services, welches die Operationen des Web Services als abstrakte Methoden definiert. 8 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.
14 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 WEB- INF-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
15 13 aufgerufen werden. Als Ergebnis schickt Axis eine SOAP-Nachricht mit dem Parameterinhalt Hallo Gunnar Thies zurück. 9 4 Web Service-Implementierung mit C 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 Java- Programmierung 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 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: exampleservice.h: Eine Interfaceklasse (Header) für den Web Service 9 Alternativ wird zum Testen des Web Services das in Kap. 5.3 beschriebene PHP-Client-Skript benutzt. 10 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.
16 14 exampleservice.cpp: Dies ist die Klasse für die Implementierung der Logik des Web Services; analog zur ExampleServiceSoapBindingImpl.java der Java- Version (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 Wrappers 11 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.
17 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: <service name="exampleservice" provider="cpp:rpc" 2: description= exampleservice "> 3: <parameter name="allowedmethods" value="sayhello"/> 4: <parameter name="classname" 5: value="h:\axis_c\apache2\axis\webservices\exampleservice.dll"/> 6: </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 HTTP- Anfrage 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 PHP- Skript 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 bekannt 12 und wird hoffentlich in zukünftigen Versionen behoben werden. 12 Axis-C-User-Forum am : (Entgegen des Foren-Beitrags trat diese Fehlermeldung auch bei dem Service-Stil RPC-Service und nicht nur bei Document-Service auf.)
18 16 5 Technologiebetrachtung 5.1 Sicherheit und Authentifizierung Die zunächst einfachste Möglichkeit, Web Services sicherer zu gestalten, ist die Benutzung des SecureSocketLayer-Verfahrens 13 : 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 SSL- Verschlü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-Signature 14, bei dem eine Prüfsumme 15 (ä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-Encryption 16 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 XML- Encryption) ein Framework zur Verbesserung der Sicherheit im Umgang mit Web Services zu konzeptionieren (siehe [9]). 13 Einstieg in SSL mit weiteren Links unter [6] 14 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]
19 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 Java- Client aufgerufen werden und umgekehrt. Leider gibt es diesbezüglich bei dem Axis- Framework 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 bekannt 17, 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(' //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.
20 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.
21 19 Literaturverzeichnis [TH04] Thomas, Erl: Service-Oriented Architecture, Prentice Hall, [DA04] [ER03] [VA04] Wang, Dapeng (Hrsg.); Bayer, Thomas; Frotscher, Thilo; Teufel, Marc: Java Web Services mit Apache AXIS, Software & Support, Eickstädt, D.; Reuhl, T.: Java mit Open Source-Tools, Markt+Technik, Vacca, J.R.: Public Key Infrastructure Building Trusted Application and Web Services, CRC Press LLC, Internet-Adressen (alle zuletzt abgerufen: ) [1] Apache Axis Projekt: [2] W3C Web Service Activity: [3] Axis User s Guide (Java): [4] Axis Handler Tutorial C++ : [5] SOAP Version 1.2 vom W3C: [6] SSL in Wikipedia: [7] XML-Signature Syntax and Processing (W3C): [8] XML Encryption Syntax and Processing (W3C): [9] Web Services Security (IBM): [10] Grundlegendes zu DIME und WS-Attachments: egendeszudimeundwsattachments.mspx
22 20 Anhang Anhang A: WSDL-Datei exampleservice.wsdl des Beispiel Web Services <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions targetnamespace=" xmlns:apachesoap=" xmlns:impl=" xmlns:intf=" xmlns:soapenc=" xmlns:wsdl=" xmlns:wsdlsoap=" xmlns:xsd=" <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=" <wsdl:operation name="sayhello"> <wsdlsoap:operation soapaction=""/> <wsdl:input name="sayhellorequest"> <wsdlsoap:body encodingstyle=" namespace=" use="encoded"/> </wsdl:input> <wsdl:output name="sayhelloresponse"> <wsdlsoap:body encodingstyle=" namespace=" use="encoded"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="exampleservice"> <wsdl:port binding="impl:exampleservicesoapbinding" name="exampleservice"> <wsdlsoap:address location=" </wsdl:port> </wsdl:service> </wsdl:definitions>
23 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)
Verteilte Systeme: Übung 4
Verteilte Systeme: Übung 4 WSDL und SOAP Oliver Kleine Institut für Telematik https://www.itm.uni-luebeck.de/people/kleine SOAP Nachrichten Serialisierung in XML Root-Element einer SOAP Nachricht ist
MehrVerteilte Systeme: Übung 4
Verteilte Systeme: Übung 4 WSDL und SOAP Oliver Kleine Institut für Telematik https://www.itm.uni-luebeck.de/people/kleine SOAP Nachrichten Serialisierung in XML Root-Element einer SOAP Nachricht ist
MehrWiederholung: Beginn
B) Webserivces W3C Web Services Architecture Group: "Ein Web Service ist eine durch einen URI eindeutige identifizierte Softwareanwendung, deren Schnittstellen als XML Artefakte definiert, beschrieben
MehrWebservices. 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung. Hauptseminar Internet Dienste
Hauptseminar Internet Dienste Sommersemester 2004 Boto Bako Webservices 1 Einführung 2 Verwendete Standards 3 Web Services mit Java 4 Zusammenfassung Was sind Web Services? Web Services sind angebotene
MehrWissenschaftliche Vertiefung Web Services. Esslingen, 22. Januar 2016 Simon Schneider
Wissenschaftliche Vertiefung Web Services Esslingen, 22. Januar 2016 Agenda 1. Einführung 2. Serviceorientierte Architektur 3. SOAP Web Service 4. Standards und Protokolle von SOAP Web Services 5. Bewertung
MehrGrundlagen der Web-Entwicklung INF3172
Grundlagen der Web-Entwicklung INF3172 Web-Services Thomas Walter 16.01.2014 Version 1.0 aktuelles 2 Webservice weitere grundlegende Architektur im Web: Webservice (Web-Dienst) Zusammenarbeit verschiedener
MehrSOA, Webservices und SOAP für Schnelleinsteiger
SOA, Webservices und SOAP für Schnelleinsteiger (C)opyright 2005 by Jochen Vajda Inhalt Einführung I. Was ist SOA? II. Webservices, SOAP und WSDL SOAP mit PHP5 I. Benötigte Komponenten II. Client ohne
MehrJava Web Services mit
Java Web Services mit Seminar Softwaretechnik WS 2004/05 Lehrstuhl für Praktische Informatik an der WWU Münster Jürgen de Braaf - 05.01.2005 Inhalt Definition und Eigenschaften von Web Services Einführendes
MehrThemen. Web Service - Clients. Kommunikation zw. Web Services
Themen Web Service - Clients Kommunikation zw. Web Services Bisher: Implementierung einer Java Anwendung und Bereitstellung durch Apache Axis unter Apache Tomcat Java2WSDL Erzeugen einer WSDL-Datei zur
MehrTermin 4: Web Services Computing
Arbeitsgruppe Übung Netzbasierte Informationssysteme Termin 4: Web Services Computing Prof. Dr. Adrian Paschke Arbeitsgruppe Corporate Semantic Web (AG-CSW) Institut für Informatik, Freie Universität Berlin
MehrÜbersicht. Angewandte Informatik 2 - Tutorium 6. Teile einer WSDL-Datei. Was ist WSDL. Besprechung: Übungsblatt 5
Übersicht Angewandte Informatik 2 - Tutorium 6 Besprechung: Übungsblatt 5 Götz Bürkle (goetz@buerkle.org) Übungsblatt 5: Aufgabe 4 - Webservices Institut für Angewandte Informatik und Formale Beschreibungsverfahren
MehrWeb Services. Standards und Realisierung in Java
Standards und Realisierung in Java http://werner.gaulke.net 4.6.2007 Idee Aufbau und Standards und Java Outline 1 Idee Idee hinter? 2 Aufbau und Standards Schichtenmodell WSDL Fazit WSDL SOAP Fazit SOAP
MehrErweitern Sie ihren Tomcat um das AXIS-Framework und machen Sie ihn damit bereit für den Einsatz von Web Services:
0BBA Karlsruhe, Vorlesung Programmieren, Web Services 1BAufgabe 1 Tomcat um das AXIS-Framework erweitern : Erweitern Sie ihren Tomcat um das AXIS-Framework und machen Sie ihn damit bereit für den Einsatz
MehrAsynchrone Webservices mit Axis 1.x in Java
Asynchrone Webservices mit Axis 1.x in Java 1. Übersicht Architektur Da Webservices nach relativ kurzen Timeouts Anfragen abgearbeitet haben müsse, sind komplexe Anfragen wie sie in der Bioinformatik üblich
MehrSeminar E-Services WS 02/03 WSDL. Web Services Description Language. Moritz Kleine SES 02 - WSDL
Seminar E-Services WS 02/03 WSDL Web Services Description Language SES 02 - WSDL Zum Ablauf Einleitung Webservices und WSDL Grundlagen (XML - Schema und Namespaces) WSDL Syntax Beispiel Zusammenfassung
MehrProjekt Entwicklung verteilter Softwaresysteme mit Web Services SoSe Java API for XML Web Service (JAX-WS) April 2008
Projekt Entwicklung verteilter Softwaresysteme mit Web Services SoSe2008 - Java API for XML Web Service (JAX-WS) - 07. April 2008 Verteilte Systeme und Informationssysteme (VSIS) Department Informatik
MehrApache AXIS Architektur
In diesem Kapitel Um was geht s? Axis Architektur Eine Übersicht Subsysteme Message Flow Handlers und Chains (Handler Ketten) Message Contexts Adminstratives Subsystem SOAP Message Modell Subsystem Message
MehrWebServices Zwischen Buzzword und Nutzen
WebServices Zwischen Buzzword und Nutzen Tobias Koenig Übersicht Webservices Allgemein WSDL Anwendungsbeispiele Programmierung Perl Python C++/KDE Zusammenfassung LUG Dresden 2005 p.1 Webservices Trennung
MehrNorm 410 Security Token Service
1 Norm 410 Security Token Service 2 3 Release und Version Release 1, Version 1.0, vom 19. Juni 2007 4 5 Status Offizielle Norm 6 7 Editor Dr. Thomas Kippenberg, NÜRNBERGER 8 9 10 11 12 13 14 Autoren Dr.
MehrEinführung Servlets. JEE Vorlesung Teil 2. Ralf Gitzel
Einführung Servlets JEE Vorlesung Teil 2 Ralf Gitzel ralf_gitzel@hotmail.de 1 Übersicht Wiederholung Hello World Blick in die Details Servlet Programmierung Potentielle Fehler Lernziele Gruppenübung 2
MehrPraktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com
Web Services Java Praktikum SS 2010 Gerald.Ehmayer@borland.com 1 Web Services Einführung Definition, Eigenschaften, Anwendungen... JAX-RPC Überblick, Architektur... JAX Übersicht, Architektur Java Praktikum
MehrAuszug aus JAX-WS Folien
Auszug aus JAXWS Folien Dieses Dokument ist ein Auszug aus unserem Skript zur Java Web Services Schulung. Es dient lediglich als Beispiel für unsere Kursunterlagen. Thomas Bayer Hauptstraße 33 75050 Gemmingen
MehrSeminarbericht Rechnernetze XML Web Services Schnittstelle zwischen den Welten.NET und Java
Seminarbericht Rechnernetze XML Web Services Schnittstelle zwischen den Welten.NET und Java von Christian Brand Kennnummer: 09376 November 2005 Abkürzungen Abkürzungen API - Application Programming Interface
MehrDie Technik hinter Web Services. Wie baut man einen Web Service? Was sind die technischen Details von WSDL, SOAP und UDDI?
Die Technik hinter Web Services Wie baut man einen Web Service? Was sind die technischen Details von WSDL, SOAP und UDDI? Folie 1 / 47 Themen Beschreibung des Beispiels Exkurs: XML Beschreibung eines Web
Mehr6 Zusammenschaltung von Web-Services
6 Zusammenschaltung von Web-Services Komposition von Web-Services zu neuen Web-Services abstrakte Beschreibung der internen Struktur Workflow-Konzept abstrakte Beschreibung der Zusammenhänge und Interaktionen
MehrWebservices. Grundlagen, Beispiel, Tomcat, Apache Axis
Webservices Grundlagen, Beispiel, Tomcat, Apache Axis Pratikum SWE 2 M. Löberbauer, T. Kotzmann, H. Prähofer 1 Was ist ein WebService Eine oder mehrere Methoden die über das Netzwerk aufgerufen werden
MehrSOA. Prof. Dr. Eduard Heindl Hochschule Furtwangen Wirtschaftsinformatik
SOA Prof. Dr. Eduard Heindl Hochschule Furtwangen Wirtschaftsinformatik Laderampen müssen passen Modularisieren Softwarearchitektur Modul A Modul B Modul C Modul D Große Anwendung im Unternehmen Modul
MehrWSDL. Web Services Description Language. André Vorbach. André Vorbach
André Vorbach WSDL Web Services Description Language André Vorbach Übersicht Was ist WSDL? Dokumentenstruktur Elemente Definitions Types Messages porttype Binding Service SOAP-Bindings Beispiel Was ist
MehrJava und XML 2. Java und XML
Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003
MehrWeb Services: Inhalt
Web Services Fachseminar Verteilte Systeme 8. April 2002 - Marco Steiner Assistent: Thomas Schoch Professor: Dr. F. Mattern Web Services: Inhalt Bedeutung Gegenwart Architektur SOAP WSDL UDDI Vergleich
MehrEtablierung serviceorientierter Architekturen mit Web Services
Etablierung serviceorientierter Architekturen mit Web Services Vorlesung im (Entwicklung von Serviceangeboten) 1 Agenda Einsatzbereiche von Web Service basierten Angeboten Übersicht zur Java-System Application
MehrEnterprise Applikation Integration und Service-orientierte Architekturen. 09 Simple Object Access Protocol (SOAP)
Enterprise Applikation Integration und Service-orientierte Architekturen 09 Simple Object Access Protocol (SOAP) Anwendungsintegration ein Beispiel Messages Warenwirtschaftssystem Auktionssystem thats
MehrSystemprogrammierung. Projekt: Java RMI. Wintersemester 2006 / 2007
Systemprogrammierung Projekt: Java RMI Wintersemester 2006 / 2007 Systemprogrammierung 1. Einleitung 2. Einführung in RPC 3. RMI 4. Code Beispiele 5. Live Vorstellung 6. Ausblick 7. Fazit 2 1. Einleitung
MehrGrundlagen des Grid Computing
Grundlagen des Grid Computing Webservices und Grid Computing Globus Toolkit 4 - Grundlagen ICA Joh.. Kepler Universität t Linz Eine Typische Grid-Applikation (Beispiel) VO Management Service Resource Discovery
MehrZustandsgebundene Webservices
Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite
MehrKompendium der Web-Programmierung
. Thomas Walter Kompendium der Web-Programmierung Dynamische Web-Sites Mit 510 Abbildungen und 22 Tabellen 4ü Springer OOM- Hinweise zum Gebrauch des Buches XIII Teil I Grundlagen der Web-Programmierung
MehrWeb Services. Web Services in the News. Vision: Web of Services. Learning for Results. DECUS Symposium 2002, Vortrag 1K07,
Web Services Vision: Web of Services Applikationen und Services Ralf Günther Compaq Computer GmbH, Köln Ralf.Guenther@compaq.com DECUS Symposium 2002, Vortrag 1K07, 16.04.2002 Web Services in the News
MehrEine Untersuchung der Funktionen des Apache Wicket Webframeworks
Eine Untersuchung der Funktionen des Apache Wicket Webframeworks Seminararbeit von Olaf Matticzk 1 15.01.2016 (c) by synaix 2016 synaix...your business as a service. Agenda 1. Einleitung 2. Webanwendungen
MehrGliederung Einleitung Die Interprozess Kommunikation Zusammenfassung Fragen. .NET Remoting. André Frimberger
.NET Remoting André Frimberger 30.11.2004 André Frimberger.NET Remoting 1 Gliederung 1 Einleitung Was ist.net Remoting? 2 Die Interprozess Kommunikation Grundkonzept der Datenkanal Parameterübergabe Instanziierung
MehrIUG DRESDEN ERSTELLUNG VON ROBUSTEN NATURAL SERVICES Software AG. All rights reserved. For internal use only
IUG DRESDEN ERSTELLUNG VON ROBUSTEN NATURAL SERVICES 2016 Software AG. All rights reserved. For internal use only DIGITAL BUSINESS APPLICATIONS DRIVE THE DIGITAL BUSINESS Partner Lieferanten Kunden SaaS
MehrDie Nutzung von Webservices in der Oracle Datenbank. 11 März 2010
Die Nutzung von Webservices in der Oracle Datenbank 11 März 2010 Agenda Vorstellung Apps Associates Einstieg und Definition Webservice Definition Application Server / Oracle Application Server Oracle Webservices
MehrServlet-zentrierte Architektur von Web-Anwendungen mit Java Servlets, Java Server Pages (JSPs) und Java Beans
Projekt Entwicklung verteilter Softwaresysteme mit Web Services SoSe 2008 - Java Server Pages und Servlets - 7. April 2008 Verteilte Systeme und Informationssysteme (VSIS) Department Informatik Universität
MehrAuszug aus Axis2 Schulung
Auszug aus Axis2 Schulung Dieses Dokument ist ein Auszug aus unserem Skript zur Axis2- Schulung. Es dient lediglich als Beispiel für unsere Kursunterlagen. Thomas Bayer Hauptstraße 33 75050 Gemmingen Mehr
MehrMicrosoft.NET Framework & Component Object Model. ein Vortrag von Florian Steuber
Microsoft.NET Framework & Component Object Model ein Vortrag von Florian Steuber Übersicht I..NET Framework 1. Was ist das.net Framework? 2. Das.NET Execution Model 3. Sprachunabhängigkeit, CTS und CLS
MehrAxis2, CXF und JAX-WS RI im Vergleich
Axis2, CXF und JAX-WS RI im Vergleich Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim www.oio.de info@oio.de Gliederung Die Standards: JWS, JAXB und JAX-WS Axis2 Apache CXF JAX-WS RI und
MehrDokumente mit WWW-Verweisen auf Dokumente der Digital Document Library (DDL) in Bern
Dokumente mit WWW-Verweisen auf Dokumente der Digital Document Library (DDL) in Bern Gerd Graßhoff Bern Inhaltsverzeichnis 1 Ziel 1 2 Technische Realisierung 4 3 Digital Document Library for the History
MehrAutor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer
Autor: Peter Seemann Seminar: Softwarearchitekturen Betreuer: Benedikt Meurer *Was sind Web Services? *Beispiele für Web Services *Web Service Architektur *Web Services Technologien *Fazit 2 *Übertragungsstandard
MehrWeb Services mit Java
Web Services mit Java Neuentwicklung und Refactoring in der Praxis Torsten Langner new technology Markt+Technik Verlag Inhaltsverzeichnis Vorwort 13 Warum ausgerechnet dieses Buch? 13 An wen richtet sich
MehrNetzprogrammierung Web-Dienste
Netzprogrammierung Web-Dienste Robert Tolksdorf und Mitarbeiter und Peter Löhr Überblick 1. Was sind Web-Dienste? 3 2. WSDL 13 3. Axis 20 4. SOAP 23 5. SOAP und HTTP 30 6. Zusammenfassung 36 Robert Tolksdorf
MehrHauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm. Web Services. Boto Bako
Hauptseminar Internetdienste Prof. F. Schweiggert Sommersemester 2004 Universität Ulm Web Services Boto Bako Inhaltsverzeichnis 1.Einführung und Motivation...3 2.Verwendete Standards...4 2.1.SOAP...5 2.2.WSDL...6
MehrWorkflow, Business Process Management, 4.Teil
Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung
MehrDokumentation. Elektronische Rechnungsübertragung mit der First Businesspost mittels. Business Connector 4.6
Dokumentation Elektronische Rechnungsübertragung mit der First Businesspost mittels Business Connector 4.6 Customizing des SAP BC für die Übertragung der INVOICE nach 1stbp Nachdem die erste Rechnung an
MehrStand der Entwicklung von Shibboleth 2
Stand der Entwicklung von Shibboleth 2 5. Shibboleth-Workshop Berlin, 17. Oktober 2007 Bernd Oberknapp Universitätsbibliothek Freiburg E-Mail: bo@ub.uni-freiburg.de Übersicht Offizieller Status Kommunikation
MehrEnterprise JavaBeans Überblick
Enterprise JavaBeans Überblick 1. Überblick Java EE 5 und Komponententechnologien 3. Enterprise JavaBeans Architektur 4. Ressourcen Management und Primäre Services 5. Java Persistence: Entity Manager 6.
MehrErstellen von Web-Seiten HTML und mehr...
Erstellen von Web-Seiten HTML und mehr... SS 2002 Duffner: Interaktive Web-Seiten 1 Themen! Was ist das WWW?! Client-Server-Konzept! URL! Protokolle und Dienste! HTML! HTML-Editoren! Ergänzungen und Alternativen
MehrService-Oriented Architecture (SOA) [1]
Verteilte Systeme SoSe 2007 Service-Oriented Architecture und Web Services Service-Oriented Architecture (SOA) [1] Ziel: Entwicklung einer robusten Architektur zur einfachen, schnellen und sicheren Integration
MehrWeb Service Entwicklung mit Java. Sven Lindow
Web Service Entwicklung mit Java Sven Lindow 22.11.2006 Agenda Einleitung SOAP, REST, WSDL, UDDI Web Services mit Java JWSDP JAX-RPC, JAX-WS 2.0 AXIS, AXIS2 Web Services nutzen Google, Ebay Web Services
MehrRemote Method Invocation
Remote Method Invocation spezielle Technik aus dem Java-Umfeld Ausführung der Methoden auf einem entfernten Rechner Analogon zum RPC (Remote Procedure Call) Zweck: Objekte in verschiedenen Java-VM s Aufruf
Mehr.NET-Networking 2 Windows Communication Foundation
.NET-Networking 2 Windows Communication Foundation Proseminar Objektorientiertes Programmieren mit.net und C# Fabian Raab Institut für Informatik Software & Systems Engineering Agenda Grundproblem Bestandteile
MehrDefinition Web Service
Gliederung Einführung Definition Web Service Drei Schhichtenmodell Architectural Model System Model Web Service Standards SOAP WSDL UDDI Types of Web Services Programmatic Web Services Interactive Web
MehrWeb Services Grundlagen und praktisches Beispiel
Web Services Grundlagen und praktisches Beispiel Ho Ngoc Duc http://come.to/duc duc@ifis.uni-luebeck.de Gliederung Einführung Was sind Web Services? Warum Web Services? Spezifikationen und Standards Beschreiben:
MehrDomino und PHP EC 2013 Track 2 Session 7
Domino und PHP EC 2013 Track 2 Session 7 1 Domino und PHP Worum es heute geht Überblick über die verschiedenen Methoden Installation Allerlei Beispiele und Ideen Worum es nicht geht LotusScript, PHP (Sie
MehrServiceorientierte Architektur (SOA), service oriented architecture, dienstorientierte Architektur.
Lothar Stein(Lothar.Stein@brunata-huerth.de) huerth.de) Heinz Peter Maassen(hp.maassen@lattwein.de) BRUNATA Hürth LattweinGmbH SOA SOAP WebServices Was ist SOA? Serviceorientierte Architektur (SOA), service
MehrAnleitung zur Integration der /data.mill API in SAP Java Applikationen
Anleitung zur Integration der /data.mill API in SAP Java Applikationen Inhalt 1. Anlage einer HTTP Destination 1 1.1. Anmelden an SAP Cloud Platform 1 1.2. Destination Konfiguration 3 1.3. Eintragen der
MehrRemote Method Invocation
Remote Method Invocation Spezielle Technik aus dem Java-Umfeld Ausführung von Methoden auf einem entfernten Rechner Analogon zum RPC (Remote Procedure Call) Zweck: Objekte in verschiedenen Java-VMs Aufruf
MehrSoftwareentwicklung in verteilten Umgebungen Middleware Case Studies (Coulouris et al., Kapitel 5 und 19) Dieter Schmalstieg Jens Grubert
Softwareentwicklung in verteilten Umgebungen Middleware Case Studies (Coulouris et al., Kapitel 5 und 19) Dieter Schmalstieg Jens Grubert Partly based on material by Victor García Barrios and Paul Krzyzanowski
MehrSoftwareentwicklung mit Enterprise JAVA Beans
Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung
MehrGRUDIS RB3 (Schnittstelle MapViewer)
GRUDIS RB3 (Schnittstelle MapViewer) Datum: 7.09.2005 Version: 1.0 Status: Genehmigt Bearbeiter: Markus Lauber Verteiler: Entwickler Fremd-GIS-System Inhaltsverzeichnis 1 Einleitung... 3 1.1 MapViewer...3
MehrGliederung. 1. Einleitung (1) 1. Einleitung (3) 1. Einleitung (2)
Referat im Rahmen des Proseminars Internettechnologie WS 2007/2008 Thema: Web Services und serviceorientierte Architekturen (SOA) vorgelegt von: Intelligente Web Services sind für das Informationszeitalter,
MehrWeb-Sevices : WSDL Entwicklung von Web-Anwendungen
Web-Sevices : WSDL Entwicklung von Web-Anwendungen Axel Reusch : ar047 MIB page 1 : 50 Agenda! Allgemeines! Prinzip! Anwendung! Details! WSDL und SOAP! Beispiel mit Java! Erweiterungen! Vorteile! Nachteile!
MehrBrowser mit SSL und Java, welcher auf praktisch jedem Rechner ebenso wie auf vielen mobilen Geräten bereits vorhanden ist
Collax SSL-VPN Howto Dieses Howto beschreibt wie ein Collax Server innerhalb weniger Schritte als SSL-VPN Gateway eingerichtet werden kann, um Zugriff auf ausgewählte Anwendungen im Unternehmensnetzwerk
MehrVertiefte Grundlagen Graphentheorie
Bauinformatik Vertiefte Grundlagen Graphentheorie 6. Semester 8. Übung Webservices Technische Umsetzung am Beispiel Flächenträgheitsmoment äg e e und Biegemoment e Benutzte Software ECLIPSE: Programmierumgebung
MehrJava: Kapitel 1. Überblick. Programmentwicklung WS 2008/2009. Holger Röder Holger Röder
Java: Kapitel 1 Überblick Programmentwicklung WS 2008/2009 Holger Röder holger.roeder@informatik.uni-stuttgart.de Was ist Java? Die Java-Technologie umfasst die Programmiersprache Java sowie die Java-Plattform
MehrNode.js der Alleskönner. Kai Donato MT AG Ratingen
Node.js der Alleskönner Kai Donato MT AG Ratingen Schlüsselworte JavaScript, Node.js, NPM, Express, Webserver, oracledb Einleitung Node.js ist nach seiner Veröffentlichung im Jahre 2009 in aller Munde
MehrJava Web Services mit Apache Axis2 Entwickler
Thilo Frotscher, Dapeng Wang, Marc Teufel Java Web Services mit Apache Axis2 Entwickler Vorwort 15 1 Einleitung 25 1.1 Entstehung 26 1.2 Unterstützte Standards 28 1.3 Was beinhaltet Axis2? 29 1.4 Warum
MehrJava Web Services Metadata JSR-181
Java Web Services Metadata JSR-181 Dieses Dokument ist ein Auszug aus unserem Skript zur Java Web Services Schulung. Es dient lediglich als Beispiel für unsere Kursunterlagen. Thomas Bayer Albertus-Magnus-Str.
MehrWeb Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen
9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.
MehrJava - Webapplikationen
Java - Webapplikationen Bestandteile (HTTP,, JSP) Aufbau (Model View Controller) Datenverwaltung (Java Beans, Sessions) Entwicklung (Projektstruktur, Sysdeoplugin für Eclipse) 17. Januar 2006 Jan Hatje
MehrSOAP Integrationstechnologie für verteilte Middlewarearchitekturen?
SOAP Integrationstechnologie für verteilte Middlewarearchitekturen? Großer Beleg Christian Wurbs Zwischenbericht http://www.inf.tu-dresden.de/~cw6 cw6@inf.tu-dresden.de Überblick 2 Aufgabenstellung CORBA
MehrPHP eine Einführung. Dipl.-Inf. Frank Hofmann. 18. November Potsdam
PHP eine Einführung Dipl.-Inf. Frank Hofmann Potsdam 18. November 2007 Dipl.-Inf. Frank Hofmann (Potsdam) PHP eine Einführung 18. November 2007 1 / 14 Allgemeines zum Kurs Zielsetzung des Kurses Erlernen
Mehr3-schichtige Informationssystem-Architektur
3-schichtige Informationssystem-Architektur plattformunabhängig beliebige Endgeräte Client als Applikation & Applet XML über SOAP Standard plattformunabhängig objektorientierte Architektur multiuserfähig
MehrWeb-Services Implementierung mit Java
Web-Services Implementierung mit Java J. Heinzelreiter WS 2004/05 Java-APIs für Web-Services (1) Anwendungs-Code JAXR JAXM JAX-RPC SAAJ SOAP/SwA JWSDL WSDL XML/XML-Schema Web-Services/Java - 2 Java-APIs
MehrWeb Services Security
Web Services Security Dokumentation zu den Beispielen Vortrag vom 11.12.02 Svetoslav Draganov Einrichtung der Entwicklungsumgebung unter Windows NT/2000/XP 1. Herunterladen aller Packages - VeriSign Trust
MehrOWASP Stammtisch München Sep 2014 XSS und andere Sicherheitslücken aus der Perspektive des Programmcodes
OWASP Stammtisch München Sep 2014 XSS und andere Sicherheitslücken aus der Perspektive des Programmcodes 1 XSS: Cross-Site Scripting 1.) Es gelangen Daten in den Web-Browser, die Steuerungsinformationen
MehrWebServices -reloaded-
WebServices -reloaded- Jan Krüger Bielefeld Bioinformatics Service Institute of Bioinformatics CeBiTec Bielefeld University jkrueger@techfak.uni-bielefeld.de 3 Juli 2007 Übersicht Motivation Was sind WebServices?
MehrSpezifikation DPD und primetime WebService Routenberechnung Gültig für Paketversender in Österreich. Version 3.3.0
Spezifikation DPD und primetime WebService Routenberechnung Gültig für Paketversender in Österreich Version 3.3.0 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis... 2 2 Versionshistorie... 2 3 Allgemein... 3
MehrCORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten
CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard
MehrManaged VPSv3 Was ist neu?
Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme
MehrMicrosoft.NET und SunONE
Microsoft.NET und SunONE, Plattformen und Application Service Providing Agenda Einordnung.NET und SunONE Kurzvorstellung Gegenüberstellung Zusammenfassung ASP (Application( Service Providing) ) und Ausblick
MehrObjectBridge Java Edition
ObjectBridge Java Edition Als Bestandteil von SCORE Integration Suite stellt ObjectBridge Java Edition eine Verbindung von einem objektorientierten Java-Client zu einer fast beliebigen Server-Komponente
MehrDOKUMENTATION. CaptchaAd mit Java. Entpacken und Hochladen. Die Schritte zur Integration des CaptchaAd-Modul im Einzelnen. Informationen von CaptchaAd
CaptchaAd mit Java Stand: 24. September 2012 Damit die Integration von CaptchaAd Ihnen noch leichter fällt, haben wir die notwendigen Schritte in diesem Leitfaden zusammen gefasst. Mit etwas Programmierkenntnissen
MehrWeb 2.0 Software-Architekturen
Web 2.0 Software-Architekturen Servlets als Controller einer MVC Web Architektur Prof. Dr. Nikolaus Wulff HTTP und HTML Das HyperText TransferProtokoll (HTTP) beschreibt eine einfache verbindungslose Kommunikation,
MehrWebservices Ein Vortrag von:
Webservices Ein Vortrag von: Andreas Münstermann Michael Reiher Markus Buschky Gliederung Einführung in Webservices Technische Grundlagen SOAP UDDI WSDL Sicherheitskonzepte Blick in die Zukunft Einführung
MehrPraktikum Datenbanken und verteilte Systeme SS Java Server Pages und Servlets -
Praktikum Datenbanken und verteilte Systeme SS 2008 - Java Server Pages und Servlets - Verteilte Systeme und Informationssysteme (VSIS) Department Informatik Universität Hamburg Infrastruktur vsispoolx
MehrTechnische Beschreibung: EPOD Server
EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für
MehrXML und SOAP Einführung und Grundlagen
XML und SOAP Einführung und Grundlagen Matthias Böhmer 16.12.2005 Agenda 1. XML 2. SOAP 3. Seife im Buchladen?! E-Commerce :: XML und SOAP Matthias Böhmer 16.12.2005 2 XML :: Einführung (1) extensible
Mehr<Insert Picture Here> Einführung in SOA
Einführung in SOA Markus Lohn Senior Principal Consultant SOA? - Ideen Selling Oracle To All SAP On ABAP Increasing Sales Of Applications 3 Agenda Motivation SOA-Definition SOA-Konzepte
MehrOnlineumfragen WebServices (OWS)
Onlineumfragen WebServices (OWS) Grundsätzlich steht Ihnen für den Zugriff auf Ihre Umfragen und sämtliche Einstellungen Ihr persönlicher Administrator-Bereich auf unserer WebSite zur Verfügung. Für bestimmte
Mehr