Verteilung, Kommunikation und Web. Ausarbeitung zum Referat Software Engineering Projekt WS2003/2004

Transkript

1 Verteilung, Kommunikation und Web Ausarbeitung zum Referat Software Engineering Projekt WS2003/2004 Autor: Ralf Anklam Matrikelnummer: Datum:

2 Inhaltsverzeichnis Vorwort Grundlagen http - Hypertext Transfer Protocol http und Sicherheit shttp -Secure Hypertext Transfer Protocol https Techniken für die Erstellung von Webapplikationen CGI - Common Gateway Interface ISAPI - Internet Server Application Programming Interface ASP Active Server Pages Servlet/JSP ASP.NET Webservices SOAP UDDI WSDL Zusammenspiel Applet/WebStart Applet Webstart JNLP Zusammenfassung...21 Literaturverzeichnis

3 Vorwort Heutzutage ist es selbstverständlich über das Internet Flüge zu buchen, Überweisungen auszuführen oder Produkte zu kaufen. All dies führt man mit einem Browser durch, so dass oft der Eindruck entsteht, der Browser sei die fürs Internet entscheidende Applikation. Dass dieser häufig lediglich zum Anzeigen von Web-Seiten und der Verwendung von Formularen in diesen dient, ja dass die gesamte Applikationslogik bei den oben beschriebenen Vorgängen meist gar nicht im Browser, sondern auf Web-Servern oder tief in den Unternehmen verwendeten Application-Servern hinterlegt ist, bemerkt man hierbei nicht. Um diese Komplexität einerseits zu verbergen, sie andererseits aber in einer leicht verständlichen und homogenen Umgebung zur Verfügung zu stellen, ist mit dem Internet eine neue Applikationsart entstanden: die Web-Applikation. Zur Entwicklung dieser Web-Applikationen sind in den letzten Jahren zahlreiche Techniken entstanden. Einige von ihnen können innerhalb des Browsers verwendet werden, andere werden innerhalb der Web-Server eingesetzt. In dieser Ausarbeitung möchte ich einen Überblick über die Techniken schaffen, die heute größtenteils für die Erstellung von Webapplikationen verwendet werden. Auf Frameworks wie Struts, Cocoon oder Java Turbine wurde nicht eingegangen, da das den Rahmen dieser Ausarbeitung überschreiten würde. 3

4 1. Grundlagen In diesem Abschnitt soll Grundlagenwissen vermittelt werden, welches für die Entwicklung von Webapplikationen unabdingbar ist. Eingegangen wird auf das http-protokoll und auf dessen Sicherheitsmechanismen. 1.1 http - Hypertext Transfer Protocol Das http-protokoll ist das Protokoll des Internets. Es basiert auf einem einfachen Request-Response-Prinzip, ist textbasiert und zustandslos. Bereits 1991 wurde die Version 0.9 eingeführt. Damals war das Protokoll als einfaches Datenaustauschprotokoll angedacht. Es unterstützte nur eine Methode- GET. Diese Methode war dazu gedacht eine Datei vom Server zu holen. Diese frühere Version des http-protokolls bot weder MIME-Unterstützung noch einen Authentifizierungsmechanismus kam dann die http-version 1.0. Bei dieser Version wurde das Request-Response-Prinzip verfeinert. Außerdem bot es eine weitere Methode an, die POST-Methode. Diese Methode erlaubt es Daten an den Webserver zu schicken. Ebenso wurden nun mehr Headerinformationen, also im Kopfteil der Protokollnachrichten übertragen. Eine komplette Beschreibung dieser Version ist in der RFC1945 zu finden wurde dann die jetzt immer noch aktuelle Version 1.1 des http-protokolls eingeführt. Diese Version besitzt bis zu 46, meist optionale Headerinformationen und fünf neue Methoden (TRACE, PUT, DELETE, CONNECT, OPTIONS). Außerdem besitzt sie eine neue Funktion, die das Offenhalten von Verbindungen ermöglicht, obwohl das Protokoll verbindungslos ist. Diese Funktion wird keep-alive genannt. Ebenso soll bei dieser Version die Effizienz erhöht und die Antwortzeiten verkürzt werden. Ein verringerter Ressourcenverbrauch ist ein weiters Merkmal der http-version 1.1. Wie oben erwähnt, basiert das http-protokoll auf einem einfachen Request-Response-Prinzip. Ein Request wird von einem Client an den Server geschickt, wobei dieser mit einem http-response antwortet. Abb.1 zeigt mögliche Requestmethoden des Client. Abb.1 Request HTTP version Beschreibung GET HTTP/0.9 Dokument vom Server erhalten HEAD HTTP/1.0 Headerinformationen einer Response erhalten POST HTTP/1.0 Daten an den Server senden PUT HTTP/1.1 den Server fragen, ob die gesendete Datei auf den Server gespeichert werden kann DELETE HTTP/1.1 eine Datei vom Server löschen TRACE HTTP/1.1 Überprüfung, welches Request an den Server geschickt wurde CONNECT HTTP/1.1 OPTIONS HTTP/1.1 Optionsliste, die für einen gegebene Ressource vorhanden sind Der Server sendet darauf eine Antwort an den Client, die einen bestimmten Response-, bzw. Statuscode enthält. Also einen Code, der beschreibt, wie der Server auf die Anfrage reagiert. In Abb2. sind alle Statuscodes aufgelistet, die ein Server an den Client versenden kann. Dabei sind Statuscode 200 und 404 die häufigsten, die wohl im täglichen Leben vorkommen. Zum Beispiel sagt Statuscode 200, dass die Anfrage korrekt bearbeitet werden konnte, d.h. das ein mit der GET-Methode angefordertes Dokument gefunden wurde und erfolgreich an den Client gesendet wird. Abb.2 Informational 1xx 100 Continue 101 Switching Protocols Success 2xx 200 OK 201 Created 202 Accepted 204 No Content Redirection 3xx 300 Multiple Choices 301 Moved Permanently 302 Moved Temporarily 304 Not Modified Client Error 4xx 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found Server Error 5xx 500 Internal Server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable 4

5 Der Ablauf des http-protokolls wird am folgenden Beispiel verdeutlicht. Beispiel: Benutzer gibt URL ein: Browser sendet an den Server den Request: GET /newsletter/ HTTP/1.0 <CRLF> Header-Zeilen <CRLF> <CRLF> Server antwortet mit: HTTP/ OK Date: Mon, 06 May :50:24 GMT Server: Apache/ Transfer-Encoding: chunked Content-Type: text/html... <html> <head> <title>heise online-newsletter - Informationen per </title> http und Sicherheit Das http-protokoll ist wie erwähnt textbasiert. Das bedeutet, dass alles was damit übertragen wird, menschenlesbar ist. Alle Werte werden als Text übertragen. Sogar in HTML-Formular eingegebene Passwörter. Da es ein Leichtes ist, den Netzverkehr abzuhorchen (sniffen), könnten somit ziemlich schnell geheime Informationen in die falschen Hände geraten. Es müssen also Mechanismen geschaffen werden, die den Verkehr verschlüsseln shttp -Secure Hypertext Transfer Protocol shttp ist ein Mechanismus, der den Netzverkehr verschlüsseln kann. shttp ist eine Erweiterung des http-protokolls um diverse Schutzmechanismen. Geheimhaltung wird durch Verschlüsselung erreicht. Kommunikationsnachweis wird durch digitale Unterschriften realisiert, Authentifizierung durch digitale Zerfitikate und Integrität durch Message Authentification Codes. Abb.3 Mit diesem Mechanismus werden keine weiteren Protokolle unterstützt, wie man in Abb.3 sehen kann. shttp ist also ein eigenständiges Protokoll, was parallel zu http existiert, aber kaum in Gebrauch ist, bzw. verwendet wird 5

6 1.2.2 https https steht dafür, dass das http-protokoll mit SSL verschlüsselt wird. SSL steht für Secure Socket Layer und wurde von Netscape vorgeschlagen. SSL ist ein Sicherheitsprotokoll für mehrere Protokolle, wo Daten unterverschlüsselt übertragen werden, wie z.b. (http, ftp, telnet, ). Dabei bietet SSL Authentisierung für Client und Server, Vertraulichkeit und Integrität der Daten. https steht also für http + ssl. Abb.4 Wie hier in Abb4. zusehen ist, ist SSL keine höheres Protokoll wie http oder ftp, sondern ergänzt die Transportschicht. Es sorgt also dafür, dass höhere textbasierte Protokolle Daten sicher (verschlüsselt) übertragen können. Wenn Daten mit SSL-Verschlüsselung via http übertragen werden sollen, dann muss im Browser eingetragen werden. SSL benutzt asymmetrische Verschlüsselung, um Schlüssel für symmetrische Datenverschlüsselung zu etablieren. Dabei werden mehrere Verschlüsselungsalgorithmen unterstützt, die bei der Verhandlung zwischen Client und Server ausgewählt werden können. Damit sich Server und notfalls auch Client authentifizieren können werden Zertifikate nach X.509 genutzt. Das SSL-Protokoll findet in zwei Phasen statt. In der ersten Phase findet die gegenseitige Authentisierung und Schlüsselaustausch statt. In der zweiten Phase sind die Schlüssel ausgetauscht und die gesicherte Datenkommunikation kann beginnen. Da der Schlüsselaustausch, -generierung Zeit in Anspruch nimmt, können Schlüssel gecached werden, um eine optionale Wiederverwendung über mehrere Kontakte hinweg zu gewährleisten. Kompression kann ebenso vereinbart werden. Wie die Phasen im Einzelnen funktionieren beschreibt Abb.5. Abb.5 1. Client stellt eine Anfrage an einen Server, der SSL unterstützt. Der Client möchte in diesem Beispiel die Seite secret.html mit https vom Server holen. 2. Der Server antwortet: "Ich bin da" und fordert den Client auf die Algorithmen, die der Client unterstützt an den Server zusenden. 3. Der Client sendet nun eine clientseitig generierte Zufallszahl und seine Möglichkeiten an kryptografischen Algorithmen mit. Optional noch eine SessionID, um zu überprüfen ob schon mal eine Verbindung mit dem Server bestand (Caching). 4. Der Server sendet eine serverseitig generierte Zufallszahl, die Algorithmen, die verwendet werden sollen und optional eine SessionID, für diese Session. Beim ersten Algorithmus handelt es sich um einen asymmetrischen Algorithmus um Informationen für den späteren symmetrischen Schlüssel verschlüsselt übertragen zu können. 5. Ebenfalls sendet der Server ein X.509 Zertifikat, was den öffentlichen Schlüssel des Servers enthält. Das Zertifikat dient zur Authentisierung des Servers. 6

7 6. Nun generiert der Client das "Pre-Master-Secret" als 48bit Zahl. Daraus wird dann beim Client und Server das Master-Secret abgeleitet, was für die symmetrische Verschlüsselung genutzt wird. Der Client verschlüsselt den "Pre-Master" mit dem öffentlichen Schlüssel des Servers. Der Client generiert nun den Session-Key für die symmetrische Datenverschlüsselung. 7. Der Server empfängt das "Pre-Master-Secret", entschlüsselt ihn mit seinem privaten Schlüssel und generiert ebenfalls den Session-Key für die symmetrische Verschlüsslung. 8. Der gleiche Schlüssel existiert nun auf beiden Seiten, ohne jemals übertragen worden zu sein und der eigentliche Datenaustausch kann beginnen. Das SSL-Protokoll ist also nun in Phase zwei. Dies ist eine sehr elegante und fast sichere Lösung um Daten verschlüsselt von A nach B zu bekommen, da Vorteile der asymmetrischen (RSA) und symmetrischen Verschlüsselung (RC2/RC4) genutzt werden. 7

8 2. Techniken für die Erstellung von Webapplikationen Nun wurden die Grundlagen für die Erstellung von Webapplikationen gelegt. Im folgenden Abschnitt werden einige Techniken vorgestellt, mit denen man Webapplikationen entwickeln kann. 2.1 CGI - Common Gateway Interface Das Common Gateway Interface ist eine Schnittstelle des Webservers zum Ausführen beliebiger Programme. Dabei können alle Programmiersprachen verwendet werden, die Umgebungsvariablen lesen können (env variablen). Außerdem muss die Programmiersprache die Standard-Eingabe (stdin) lesen und auf die Standard-Ausgabe schreiben können. Ein Client kann auf zwei Weisen Parameter an ein CGI-Skript weiterleiten. Zum einen kann er dies mit der POST-Methode tun. Dabei werden die Parameter als Standardeingabe an das CGI-Programm übergeben. Das Programm kann die übertragenden Parameter dann beliebig weiterverarbeiten. Die zweite Variante, mit der ein Client (z.b. Browser) Parameter an ein CGI-Programm senden kann, ist die GET-Methode. Wenn Daten mit GET beim Webserver ankommen, schreibt der Webserver die Parameter in die Systemumgebungsvariable Query_String. Das CGI-Programm kann diese Variable dann auslesen und weiterverarbeiten. Da es bei manchen Betriebssystemen Beschränkungen in der zulässigen Länge von Umgebungsvariablen gibt, existiert die Möglichkeit die Parameter umzulenken. Dabei wird die sonst in QUERY_STRING stehende Zeichenkette per Pipe gesendet und kann vom CGI-Programm direkt von Stdin gelesen werden. Die Information ist wie im QUERY_STRING im normalen URL Kodierungsschema verschlüsselt, d.h. sie muss zur Benutzung erst dekodiert werden. In Abb.6 wird der Ablauf dargestellt, wie eine Anfrage, die von einem Client an einen Webserver mit CGI-Schnittstelle, bearbeitet wird. Dabei sendet der Client Daten über das http-protokoll Daten, die er vorher in ein HTML-Formular eingegeben hat. Verlauf mit GET: Wenn die Daten am Webserver ankommen, schreibt der Webserver die Parameter in die Umgebungsvariable QUERY_STRING und startet darauf das CGI-Programm. Dieses Programm liest darauf die Umgebungsvariable aus und sendet seinen Output über Standardout an den Webserver. Der Webserver sendet dann via http den Output des Programms an den Client (Browser) zurück. Verlauf mit POST: Im Gegensatz zu GET muss das CGI-Programm bei POST die Parameter aus der Standardeingabe auslesen, um an die Parameter zu gelangen. Dabei ist zu beachten, dass die Umgebungsvariable CONTENT_LENGTH auszulesen ist, da der übergebene Datenstrom kein Datenendzeichen enthält. Das Programm kann also durch den Wert von CONTENT_LENGTH ermitteln, wann es den Datenstrom abbrechen muss, also alle Daten des Clients erhalten hat. Nun kann das Programm die Daten verarbeiten und sendet seinen Output über Standardout an den Webserver. Der Webserver sendet dies dann via http an den Client (Browser) zurück. Abb.6 8

9 Die Technik CGI hat, wie alle noch später vorgestellten Techniken Vor- und Nachteile. Was für diese Technik spricht ist eine einfache Implementierung mit beliebigen Sprachen. Bevorzugt sind hier die Sprachen perl und tcl, die zu den Skriptsprachen gehören. Da es sich bei CGI- Programmen um Standalone-Applikationen handelt, also um Applikationen, die in eigenem Prozess laufen, liegt keine zu enge Bindung zum Webserver vor. Wenn also ein CGI-Programm abstürzt, besteht eine geringe Gefahr, dass davon der Webserver betroffen ist und ebenfalls abstürzt. Ebenso ist mit CGI eine schnelle Prototypenentwicklung möglich, dank der unterstützen Programmiersprachen und der einfachen Einbindungsmöglichkeiten der Programme. Der größte Teil heutiger Webapplikationen sind mit der CGI-Technologie realisiert. Man kann also sagen, dass sich CGI bewährt hat. Die Nachteile dieser Technologie sollte man aber nicht verschweigen. Es herrscht dadurch, dass es sich bei CGI-Programmen um Standalone-Applikationen handelt, keine klare Trennung zwischen Design und Funktionalität. Dies kann besonders bei großen Projekten hinderlich sein. Es wird ziemlich schnell sehr aufwendig den Überblick über viele Skripte zu behalten. Der größte Nachteil ist aber wohl die langsame Geschwindigkeit. Bei jedem Aufruf einen CGI- Programms startet der Webserver eine Instanz des Programms in einem eigenen Prozess. Wird ein Skript/Programm gleichzeitig sehr oft aufgerufen, laufen viele Prozesse auf dem Webserver. Da Prozesswechsel Systemressourcen und Zeit kosten, können viele Anfragen den Webserver schnell sehr langsam machen. Um diesen Performanznachteil auszugleichen, wurde mit FastCGI eine Erweiterung entwickelt. FastCGI steigert die Performanz von CGI, indem ausgeführte Prozesse nicht beendet werden, sondern vielmehr auf die nächste Anfrage warten. Somit entfällt bei einer erneuten Anfrage das zeitintensive Erstellen eines Prozesses, was die Performanz deutlich steigert. Jedoch kommt es wieder zu Einbrüchen, wenn ein Prozess mehrfach zeitgleich angefragt wird, weil dann wieder mehrere Prozesse erzeugt werden müssen. Kurz soll noch WINCGI erwähnt werden. WINCGI basiert auf dem gleichen Prinzip wie CGI. Der Unterschied ist u.a., dass WINCGI nur von Webserver unterstützt werden, die unter Windows laufen. Unterstützt wird wie bei CGI jede Programmiersprache, die parameterfähig ist und Datei Handling beherrscht. Der Webserver benutzt zum Start des CGI-Programmes spezielle Windowsmethoden wie WinExec( ) und CreateProcess( ). Der Name der auszuführenden Datei muss nicht unbedingt *.exe sein. Es kann auch ein Dokument sein, das mit einer Anwendung verknüpft ist. 2.2 ISAPI - Internet Server Application Programming Interface Anders als bei CGI, wird bei ISAPI nicht bei jedem Aufruf ein Prozess gestartet. ISAPI ist eine weitere Technik um Webapplikationen zu entwickeln, die die Nachteile anderer Techniken (besonders CGI) ausmerzen sollte. Konkret handelt es sich um DLLs, die der Webserver zusätzlich lädt und damit in seiner Funktionalität wächst. Das hier beschriebene ISAPI-Konzept wird nur auf HTTP-Servern unterstützt, die unter MS- Windows laufen. Deren Zahl und Marktanteil wächst gegenwärtig beständig. Außer dem Microsoft- Internet-Informations-Service (IIS) und dem Microsoft-Personal-Webserver (PWS) unterstützen auch eine Reihe weiterer kommerzieller Server (z.b. O'Reillys-Webserver) und Freeware-Server (z.b. Sambar-Server) ISAPI-DLLs. Nach der Funktion werden zwei Arten von ISAPI-DLLs unterschieden: ISAPI-Filter und ISAPI- Erweiterungen (ISAPI-Extensions). ISAPI-Filter erledigen Aufgaben wie Zugriffskontrolle, Verschlüsselung oder Transferkontrolle. Sie liefern seltener direkt sichtbare Inhalte an den Client zurück. ISAPI-Erweiterungen hingegen produzieren Ausgabedaten, die unmittelbar zur Anzeige auf dem Browser des Client bestimmt sind. Die nachfolgenden Ausführungen beziehen sich ausschließlich auf die Extensions. Beim Laden der DLL ruft der HTTP-Server einmalig eine Prozedur namens GetExtensionVersion auf. Diese stellt man als Programmierer in der DLL bereit. GetExtensionVersion liefert an den Server zwei Kurzinformationen über Versionsnummer und Namen Ihrer DLL zurück. Das Anfordern von Ausgabeaktionen erfolgt, wenn der Server die zweite Export-Prozedur der DLL namens HttpExtensionProc aufruft. Diese ist quasi das Hauptprogramm der ISAPI-Extension. Zugleich legt der Server die Eingabedaten der Client-Anforderung in einem Datenblock namens ECB (Extension-Control-Bloc) ab und übergibt den Zeiger darauf als Parameter an HttpExtensionProc. 9

10 Jetzt hat die selbst verfasste Prozedur die Aufgabe, die dynamische Antwort zu generieren und über den Server an den Client-Browser zurück zuschicken. Treffen zwei oder mehr Anfragen gleichzeitig ein, läuft HttpExtensionProc in mehreren Threads parallel ab. Jeder Thread hat dabei seinen eigenen Datenblock ECB. Somit erhält jeder Client auch die von ihm geforderte Antwort. Wie alle Techniken birgt auch ISAPI Vor- und Nachteile. Der größte Vorteil wurde schon am Anfang erwähnt. Einmal geladen, verbleibt die DLL im Speicherraum des Servers. Damit entsteht bei wiederholten Aufrufen ein Geschwindigkeitsvorteil gegenüber Varianten mit erneutem Laden. Als DLL wird das Programm auch nur einmal geladen, selbst wenn mehrere Clientanforderungen zeitgleich zu beantworten sind. Damit wird bei ISAPI wertvoller Arbeitsspeicher auf der Servermaschine eingespart. Gegenüber den in der UNIX-Welt weit verbreiteten CGI-Scripts entstehen Vorteile dadurch, dass die DLLs echten Programmcode darstellen, der unmittelbar ablauffähig ist. Scripts hingegen müssen interpretiert werden. All das führt in der Praxis dazu, dass ISAPI-Lösungen ein überdurchschnittlich gutes Zeit- und Ressourcenverhalten zeigen. Ein ISAPI-Entwickler muss sich aber sehr gut mit der Architektur der Windows-DLLs auskennen und außerdem bereit sein, sich mit HTTP-Nachrichten auf einer sehr maschinennahen Ebene zu befassen. ISAPI-Programme sind also eher schwierig zu schreiben. Ebenso sind die ISAPI-DLLs sehr eng an den Webserver gebunden, da sie ja im gleichen Prozess wie der Webserver laufen. Fehlerhafte ISAPI s könnten den Webserverprozess zum Absturz bringen. 2.3 ASP Active Server Pages ASP wurde in der zweiten Hälfte der 90ziger Jahre von Microsoft eingeführt. Und ging erstmals einen anderen Weg der Webprogrammierung. Bei ASP können HTML-Code und serverseitige Skripte problemlos miteinander vermischt werden. ASP-Seiten sind also HTML-Seiten mit integriertem Source Code. Der Source-Code wird normalerweise in Jscript (der Microsoft-Version von JavaScript), VBScript oder Perl geschrieben. Wenn eine Active Server Page angefordert wird, verarbeitet ASP die Seite und führt alle Skripts aus, die darin enthalten sind. Skripts greifen mit Hilfe des ASP-Objekts Request auf die mit der Anforderung gesendeten Eingaben zu. Dann schreiben sie unter Verwendung des ASP-Objekts Response HTML-Code in die HTTP-Antwort. Vorteil dieser Technik ist, dass Webanwendungen nun einfacher als beispielsweise mit ISAPI zu erstellen sind. ASP bietet auch ein höheres Abstraktionslevel als CGI/ISAPI, was zum Beispiel daran zu sehen ist, dass http-response/-request als Objekte gesehen werden. Nachteile diese Technik sind das ASP-Anwendungen ebenfalls langsam laufen, da sie interpretiert und nicht kompiliert werden, was bei jedem Zugriff auf der Seite geschieht. Außerdem ist es zum Beispiel nicht möglich, wiederverwendbare ASP-Steuerelemente zum Kapseln einer komplexen Darstellungs- und Verhaltenslogik zu erstellen, ohne auf COM zurückzugreifen. Die größte Schwäche aber ist die Beschränkung auf den IIS von Microsoft, als einzigen Server der ASP unterstützt. Zudem sind die verwendeten Skriptsprachen sehr im Umfang beschränkt, so dass komplexere Anwendungen nur über Komponenten erstellt werden können. 2.4 Servlet/JSP Java Servlets wurden 1997 eingeführt und stellen den Ansatz von Sun dar, Java als Ersatz für CGI- Skripte zu etablieren. Sun selbst definiert das so: "A servlet can almost be thought of as an applet that runs on the server side -- without a face." Es handelt sich also um eine Technologie, mit der in Java geschriebene Programme Anfragen von Clients über HTTP empfangen, verarbeiten und beantworten können. Die Ausführung der Java-Programme und die Bereitstellung der Verbindung zum Client etc. erfolgt dabei durch einen sogenannten Servlet-Container und ist weitgehend transparent für den Programmierer. Vorraussetzung ist dabei, dass selbst programmierte Servlets immer Unterklasse einer der von Sun bereitgestellten Servletklassen sein müssen, meist HttpServlet. 10

11 Die weitere Entwicklung der JAVA-Servlet-API und der JSP s wurde von SUN an die Apache Software Foundation abgegeben. Dort ist sie nun als Tomcat-Projekt bekannt. Wie eine Anfrage eines Clients genau aussieht, ist in Abbildung 7 kurz illustriert. Abb.7 Selbst bei mehreren Anfragen an ein Servlet muss nur eine Servlet-Instanz erzeugt und initialisiert werden. Dabei spielt es keine Rolle, ob das Servlet in demselben oder einem anderen Prozess als der Server läuft. Ein Servlet erbt von GenericServlet und muss damit die Methoden init() und service() überschreiben. Das Servlet kann aber auch direkt von HTTPServlet erben, welches sich stark an http anlehnt und dem Programmierer unter anderem dopost() und doget() zur Verfügung stellt. Es ist nun davon abhängig, ob die Parameter, die der Client an den Web Server schickt mit Post oder Get ankommen. Kommen sie mit Post an, ruf der Web, bzw. Applikation Server die dopost() des entsprechenden Servlets auf. Bei Get, die doget()-methode. Servlets sind also ebenso eine Technik um dynamisch Webseiten zu erzeugen. Die Vorteile gegenüber anderen Ansätzen sind dabei klar: Zugriff auf das komplette Java API und viele Java-Bibliotheken von Drittherstellern, die weitgehende Plattformunabhängigkeit und die Existenz von ausgereiften Entwicklungsumgebungen. Es existieren aber auch einige Nachteile. Servlets-Code ist sehr unübersichtlich. Im Unterschied zu CGI können von einem Servlet-Prozess auch mehrere Anfragen parallel bearbeitet werden. Nachteil bei der Verwendung von Servlets liegt in der Tatsache, dass die Ausgaben innerhalb des Servlets generiert werden müssen, was schon bei HTML-Seiten geringeren Umfangs zu umständlichen und schwer wartbaren Code führt. Es können also keine HTML Design Tools direkt verwendet werden. Weitaus tragischer ist, dass keine parallele Entwicklung von Code und Grafikdesign möglich ist. Die Wartung von Servlet-Seiten erfordert Java-Programmierer und keine HTML-Designer. Wonach es also verlangte, war eine Trennung von Layout und Funktion, also eine Trennung der Benutzerschnittstelle(HTML) und Anwendungslogik. Um dieses Problem zu lösen führte Sun die JSP s ein. JSP steht für Java Server Pages. JSP S sind die Antwort von Sun auf Microsofts ASP, also Einbettung von Java-Code in HTML. Dabei bestehen die JSP s aus der Kombination der Skript- und Servletidee. Wie das genau funktioniert wird noch in Abbildung 8 genau beschrieben. Der Aufruf eigener und externer Javaklassen, so genannter Beans ist ein markantes Merkmal der JSP s. Das dient dazu eine Trennung von Darstellung und Logik vollziehen zu können. Die Programmierung und das HTML-Design(Layout) können, wenn man JSP s als Technik für die Entwicklung seiner Webanwendung nutzt, in separaten Schritten, bzw. von verschieden Leuten realisiert werden. Ein besonderes Merkmal von JSP gegenüber anderen Skriptsprachen ist die Möglichkeit, eigene Tags zu erstellen und in Tag-Bibliotheken verwalten zu können. Hierdurch können komplexe Funktionalitäten gesondert programmiert und über leicht zu verwendende Tags in die Skriptseiten eingebunden werden. 11

12 Abb.8 Was ist nun das besondere an JSP? Anhand eines Aufrufs einer jsp-seite soll dies verdeutlicht werden. Ein Client stellt also eine Anfrage an eine *.jsp- Seite. Die Verarbeitung einer JSP-Seite wird durch einen JSP fähigen Webserver durch eine JSP-Engine übernommen. Eine JSP-Engine ist meist als Servlet implementiert. Mit Hilfe eines Aliases innerhalb des Webservers, wird jede Client-Anfrage die sich auf eine JSP-Seite bezieht, auf die JSP-Engine umgeleitet. Die als Servlet implementierte JSP- Engine öffnet die angeforderte Java Server Page und überprüft deren Syntax. Ist alles in Ordnung, erfolgt die Generierung einer ".java"-quelldatei, die dann mit Hilfe eines vorab konfigurierten Compilers in eine ".class"-datei übersetzt wird. Das so entstandene Servlet wird dann von der Servlet Engine geladen, um die ursprüngliche Client-Anfrage zu bearbeiten. Der Request wird also dann an das Servlet weitergeben. Das Ergebnis ist somit ein aus der JSP Seite zur Laufzeit erzeugtes Servlet, das dynamisch von der Servlet Engine geladen wird. Die Erstellung des Servlet erfolgt nur beim ersten Aufruf der JSP-Seite. Es tritt daher eine Verzögerung bei der ersten Bearbeitung einer Anfrage aufgrund des zur Erzeugung des Servlets benötigten Aufwands ein. Jeder weitere Aufruf wendet sich dann über die JSP-Engine auf das bereits geladene Servlet. Die Vorteile in Bezug auf schon vorgestellte Techniken liegen auf der Hand. Die Trennung von Logik, Information und Darstellung kann konsequent angewandt werden. JSP s können also als Model-View- Controller-Architektur im Web angesehen werden (siehe Ausflug MVC). Positiv ist die Geschwindigkeit zur Laufzeit, die Nutzung von den reichhaltigen, wohl dokumentierten Java-Bibliotheken, die Nutzung einer einheitlichen Programmiersprache, gute Entwicklungsumgebungen und gute Möglichkeiten zur Fehlerbehandlung. Jede Technik hat auch ihre Nachteile. Bei JSP s wie allgemein bei Java ist es ein hoher Ressourcenverbrauch, da Javaanwendungen viel Speicher benötigen. Da wie beschrieben beim ersten Aufruf der jsp-seite das Servlet erst erstellt wird, ist ein langsamer Start auch ein negativer Punkt, der Erwähnung finden sollte. Ausflug MVC (Model View Controller): Entstanden ist diese Architektur im Bereich der GUI-Frameworks (Goldberg 1989). Sinn bei MVC ist es, Anwendungsobjekte in drei Rollen aufzuteilen. Die erste Rolle ist das Model. Sie kapselt die Daten und Operationen einer Anwendung und ist unabhängig von View und Controller. Die zweite Rolle ist die View-Komponente und ist für die Darstellung des Models verantwortlich. Die View-Komponente arbeitet unabhängig vom Controller. Der Controller ist die dritte Komponente und reagiert auf Benutzereingaben. Er verwaltet View und Model. Durch Einsatz dieser Technik wird sich bessere Wartbarkeit und Wiederverwendbarkeit versprochen. Durch Kombinierbarkeit der Komponenten erhöht sich außerdem die Flexibilität. 12

13 2.5 ASP.NET Ein neues Konzept stellte Microsoft mit ASP.NET vor. ASP.NET, die Fortführung der weiter oben beschriebenen ASP, steht für die Erstellung der Präsentationsschicht zur Verfügung. Hierunter liegt die Schicht der Geschäftslogik, die durch.netoder COM+-Komponenten gebildet wird. Die Einführung von wiederverwendbaren Serversteuerelementen, die HTML für Browserclients rendern und Ereignisse auslösen, die von serverseitigen Skripts verarbeitet werden können, ist das, was Microsoft als neu und innovativ präsentiert. Zentraler Bestandteil bei ASP.NET sind Web Forms. Web Forms umschreiben die Entwicklung von Webseiten mit Hilfe von Steuerelementen und Ereignishändlern. ASP.NET integriert sich voll in das.net-framework wie es in Abbildung 9 zu sehen ist. Abb.9 Das bedeutet, das sich ASP.Net- Anwendungen fast genauso wie normale Windowsapplikationen programmieren lassen. Da ASP.NET fester Bestandteil des.net- Frameworksist, kann für die Entwicklung auf jede von.net unterstützte Sprache zurückgegriffen werden. Wie in Abbildung 9 zu sehen ist, nutzt auch ASP.NET die Common Language Runtime. Das heißt, ASP.NET-Applikationen werden kompiliert und nicht wie bei ASP interpretiert. Auch alle anderen Features wie frühzeitiges Binden (early Binding), Just-In-Time Kompilierung und Caching werden von ASP.NET genutzt. ASP.NET hat sich auf die Fahnen geschrieben, dass automatisch geprüft wird, mit welchem Browsertyp der Benutzer auf die Webapplikation zugreift und generiert zur Laufzeit den passenden HTML-Code. Dank der Einbindung von ASP.NET ins Framework kann mittels ADO.NET mit einfachen Mitteln eine Datenbankverbindung zustande kommen. Web Forms sind wie schon erklärt der zentrale Bestandteil von ASP.NET Dabei liegt das Formular an sich und alle enthaltenen Elemente (Controls) als Objekt bei Server vor. Das Webformprogrammiermodell ist also vollkommen objektorientiert. Der Programmcode bei ASP.NET besteht im Prinzip aus serverseitigen Ereignisbehandlungsroutinen. Webcontrols (Websteuerelemente) lösen Ereignisse beim Server aus. Dabei wird zwischen zwei Arten von Ereignissen unterschieden. Zum einen werden Ereignisse spezifiziert, die ausgelöst werden, wenn verschiedene Verarbeitungsschritte an einer *.aspx-datei vorgenommen werden. (z.b. Page_Load()). Damit sind Ereignisse gemeint, die sich auf die komplette Seite beziehen. Zum anderen existieren Pseudoereignisse. Das sind Aktionen, also Zustandsänderungen beim Client(z.B. Button_Click). Diese Ereignisse werden zeitverzögert ausgelöst, da der Browser nicht jede Änderung an den Server überträgt. Datenübertragung findet im Rahmen eines erneuten HTTP-Request (Roundtrip) statt. Roundtrips basieren auf HTTP-POST und können automatisch beim Klick auf den Submitbutton oder einen Link ausgelöst werden. ASP.NET überbrückt im Prinzip die Kluft zwischen Client und Server, indem es so tut, als würden Ereignisse auf demselben Rechner ausgelöst und behandelt. In Wirklichkeit werden Ereignisse auf dem Server ausgelöst, wenn das Formular als Reaktion auf einen externen Stimulus (zum Beispiel einen Klick auf eine Schaltfläche) ein Postback zurück an den Server sendet. Außerdem unterstützt ASP.NET die Trennung von Code und Design. Hier wird es Code- Behind-Technik genannt und ist dafür gedacht, dass eine getrennte Bearbeitung der Seite von Webdesigner und Webentwickler möglich ist. Der Webentwickler kann eigene Tags definieren und damit dem Webdesigner mehr Spielraum geben. Web Forms speichern selbsttätig den so genannten View State. Dieser beinhaltet Informationen über die im Formular enthaltenen Controls, ihre Werte, ihre Eigenschaften, usw. Dadurch hat man, auch wenn das Formular mehrfach gepostet wird, immer die Einstellungen der Controls konsistent zur Verfügung. Die Benutzerschnittstelle eines Webformulars wird mit Hilfe einer Kombination aus HTML-Code und Serversteuerelementen»deklariert«. Steuerelemente können individuell angepasst werden. Dazu werden Eigenschaften, die als Attribute fungieren, in die Tags gesetzt, die die Steuerelemente deklarieren. Steuerelemente sind außerdem echte Objekte. Sie können als Instanzen definiert und 13

14 jedes Mal ausgeführt werden, wenn die Seite, auf der sie enthalten sind, angefordert wird. Dabei werden aber zwei Arten von Steuerelementen (Controls) unterschieden. HTML-Controls sind die serverseitigen Repräsentationen von HTML Formularelementen, wie wir sie bereits kennen. Die Funktionalität ist sehr stark an die tatsächliche HTML Funktionalität angelehnt, was dazu führt, dass die Programmierung der einzelnen Elemente nicht vollständig konsistent ist. Mit diesem Modell kann man existierende Formulare 1:1 übernehmen. HTML-Controls werden deklariert, indem das Attribut RunAt="server" in normale HTML-Seiten eingefügt. Zur Laufzeit erkennt ASP.NET das Attribut runat="server" und erstellt ein Objekt vom HTML-Control Typ, zum Beispiel HtmlInputText. Dieses Objekt gibt daraufhin beim das Tag <input type="text"> aus, das schließlich an den Browser zurückgegeben wird. Web-Controls haben mehr Features als HTML Controls, und lehnen sich nicht so stark daran an, wie sie am Client gerendert werden. Diese Controls umfassen nicht nur Formularelemente, sondern auch Spezialcontrols wie zum Beispiel einen Kalender. Dies ist der Weg, den man gehen sollte, wenn man ASP.NET Seiten von Grund auf neu programmiert. Bespiel für HTML-Controls Tag Entsprechendes HTML-Steuerelement <a runat="server"> HtmlAnchor <button runat="server"> HtmlButton <input type="text" runat="server"> HtmlInputText Beispiel für Web-Controls Klassenname Beschreibung Button Erzeugt Submit-Schaltflächen. Calendar Zeigt Kalender an, aus denen Daten ausgewählt werden können. CheckBox Zeigt ein Kontrollkästchen in einem Webformular an. 2.6 Webservices Webservices gehören nicht wirklich zu den Techniken für Webapplikationsentwicklung. Ein Webservice ist zwar über Port 80 ansprechbar, gehört aber mehr zum Kontext einer verteilten Anwendung als zu einer Webapplikation. Webservices sind ein auf W3C-Standards basierten Modell und unterstützen viele Techniken. Das Austauschprotokoll, womit sich alle Komponenten des Webservice-Frameworks unterhalten ist SOAP SOAP: SOAP steht für Simple Object Access Protocol und ist ein einfaches, leichtes Protokoll für den Austausch von strukturierten Informationen über das Web. SOAP ist ein höheres Protokoll und nutzt Protokolle wie http, smtp oder ftp. Es setzt also auf Protokollen auf, die für das Übertragen von Text- Daten genutzt werden. SOAP-Nachrichten liegen im XML-Format vor. Das Entwurfsziel von SOAP war das KISS-Prinzip (Keep It Simple and Stupid). Es sollte einfach zu implementieren sein und basiert auf schon bestehende Standards HTTP/XML). Warum sich für http als Hauptübertragungsprotokoll für SOAP-Nachrichten entschieden wurde, liegt auf der Hand und kann in Abschnitt 1.1. und Abschnitt 1.2. nachgelesen werden. Der größte Vorteil bzw. Nachteil (das liegt im Auge des Betrachters) ist, das http durch jede Firewall kommt und damit nicht geblockt werden kann. Warum sich für XML entschieden wurde sollte ebenso klar sein. XML ist eine textbasierte, selbst beschreibende Datenpräsentation. Es ist einfach damit umzugehen, da XML lesbar und strukturiert Informationen darstellt. Außerdem ist XML plattformunabhängig und wird von fast allen großen IT- Playern unterstützt. Es existieren ein Menge Tools (z.b. XMLSPY von Altona ) und API s für XML. XML ist sehr anpassungsfähig, da die Daten, die eine XML-Datei beinhaltet leicht mit Hilfe von XSL transformiert und damit in anderer Form präsentiert werden können. Außerdem kann man auf viele 14

15 weit verbreitete XML-Parser zurückgreifen, um die wichtigen Daten schnell aus der SOAP-Nachricht extrahieren zu können. Des Weiteren lässt sich SOAP beliebig mit anderen Internetstandards kombinieren. Um Daten verschlüsselt zu übertragen, kann man z.b. auf SSL zurückgreifen. Um das Datenaufkommen niedriger zu halten kann eine Nachricht vor dem Versenden mit GZip gepackt werden und dann vom SOAP Server vor der Verarbeitung wieder entpackt werden. Eine SOAP-Nachricht besteht aus einem Header, der von dem gewählten Protokoll für die Übertragung abhängt und dem so genannten SOAP Envelope. Der SOAP Envelope besteht wiederum aus einem optionalen SOAP Header und dem SOAP Body, der nicht optional ist. Der SOAP Envelope unterliegt noch weiteren Regeln. Er muss den SOAP Envelope Namespace und den SOAP Encoding Namespace verwenden. Außerdem darf der Envelope keine DTD Referenz und keine XML Processing Instructions enthalten. SOAP nutzt für die Repräsentation der Datentypen XML Schema. Dazu gehören z.b. Integer, Float, Boolean, String, Enumerations und Array of Bytes. XML Schema wird durch SOAP noch um Structs und Arrays erweitert. Auf Basis dieser Datentypen kann man weitere beliebig komplexe Datentypen aufbauen. Spezielle Datentypen von Programmiersprachen können so in SOAP Datentypen abgebildet werden. Ein Beispiel für eine Request SOAP-Nachricht: POST /Calc_WebService/Service1.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: " <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap=" <soap:body> <Calc xmlns=" <a>int</a> <b>int</b> </Calc> </soap:body> </soap:envelope> Beispiel für Response SOAP Nachricht: HTTP/ OK Content-Type: text/xml; charset=utf-8 Content-Length: length <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi=" xmlns:xsd=" xmlns:soap=" <soap:body> <CalcResponse xmlns=" <CalcResult>int</CalcResult> </CalcResponse> </soap:body> </soap:envelope> UDDI: Wie findet man nun einen Webservice? Wenn man nicht genau weiß wo sich ein Webservice befindet, kann man sich an einen Verzeichnisdienst wenden. UDDI ist die Spezifikation eines Verzeichnisdienstes für Web Services. Firmen, die eigene Web Services für andere zur Verfügung stellen wollen, stellen entsprechende Informationen darüber in einem UDDI-Verzeichnis bereit. Die Details werden, eingeteilt nach White, Yellow und Green Pages, in einer Datenbank abgelegt. Andere Firmen, die einen für sich passenden Web Service im UDDI-Verzeichnis suchen und finden dort Informationen u.a. beschriebene Schnittstelle, wie sie den gesuchten Webservice in ihre eigenen Applikationen einbinden können. UDDI ist die Abkürzung für Universal Description, Discovery and 15

16 Integration. Ins Deutsche übersetzt: Universelle Beschreibung, Auffindbarkeit und Einbindung. UDDI ist also ein Repository für Geschäftsdaten für das Web, wobei die Einträge in XML Schemas definiert sind. Es herrscht eine Ordnung der Informationen im Repository vor. Dabei existieren drei Gruppen: White Pages, Yellow Pages und Green Pages. In den White Pages werden allgemeine Informationen abgelegt, wie der Firmenname und textuelle Beschreibung der angebotenen Services, die möglichst auch in mehreren Sprachen vorhanden sein sollten. Außerdem werden Informationen zu Kontaktmöglichkeiten hinterlegt. Dazu gehören zum Beispiel der Name einer Kontaktperson, Telefonnummern, -adressen, Fax, eine WebSite-URL etc. Weiterhin könnte auch noch die Handelsregisternummer vermerkt sein. Ingesamt also Informationen über Unternehmen und die von ihnen angebotenen Dienste. Die Yellow Pages erlauben eine Kategorisierung der Services. Es wird beschrieben, um welches Produkt, welche Dienstleistung es sich handelt. Sinnvoll ist die Angabe einer Branche oder ähnliches. Es besteht auch die Möglichkeit eine geographische Referenz mit einzubinden. In den Green Pages sind die Informationen zum Anbinden eines Services zu finden. Dazu gehören weitere Informationen zum Service und eine Referenz auf die Schnittstellenbeschreibung. Das ist normalerweise eine URL, die auf ein WSDL-Dokument zeigt, in dem alle Einzelheiten der Schnittstelle enthalten sind. Green Pages enthalten technische Informationen über Nachrichtenformate, Protokolle und Kommunikationsendpunkte. Wenn man nun ein solches Verzeichnis ansieht, kristallisieren sich zwei Rollen heraus. Zum einen der, der den Dienst veröffentlicht. Also jemand, der seinen Web Services mit allgemeinen Informationen und Schnittstellenbeschreibung bekanntmachen möchte. Und zum anderen jemand, der einen bestimmten Webservice sucht und nutzen möchte. Dementsprechend existieren auch zwei SOAP-Api s eine für das Registrieren und die andere für das Suchen. Die Veröffentlicher-API (Publisher-API) wird für das Bereitstellen eines Web Service benutzt und definiert Funktionalitäten wie Erzeugen, Ansehen und Löschen der Registrierungen. Die Such-API (Inquiry-API) definiert Methoden zum Finden von Web Services und zum Details anzeigen, wenn schon ein Webservice gefunden wurde. Wenn man einen Web Service sucht steckt meistens die Absicht dahinter, den gefunden Web Service auch nutzen zu wollen. Deshalb endet fast jede Anfrage mit der Rückgabe von Zeigern (URL s) zu WSDLs und anderen Webservicebeschreibungen, um den Dienst dann auch wirklich nutzen zu können. Wie sieht nun aber so eine Webdienstbeschreibung, also dein WSDL-Dokument aus? WSDL: WSDL steht für Web Services Description Language, und ist, ins Deutsche übersetzt, eine Beschreibungssprache für Web Services im XML Format. Mit den Informationen, die ein Client(Service Requester) aus einem WSDL Dokument gewinnt, ist er in der Lage sich mit dem Server (Service Provider) zu verbinden und den angebotenen Service zu benutzen. Ein WSDL-Dokument beschreibt wie die Nachrichten, die ausgetauscht werden sollen, aufgebaut sind, mit welchem Protokoll die Nachrichten übertragen werden sollen und unter welcher URI der Web Service zu erreichen ist. WSDL-Dokumente sind die Dokumente, die auf eine UDDI-Registry publiziert werden können. Es gibt zwei Herangehensweisen, wie ein WSDL-Dokument erstellt werden kann. Zum einen kann es erst manuell erstellt werden, wobei dann später die Implementierung gegen die Beschreibung erfolgt. Diese manuelle Erstellung ist komplizierter und dauert dementsprechend länger. Der andere Weg ist, den Web Service zuerst zu implementieren und dann durch zu Hilfenahme von entsprechenden Tools die Beschreibung, also das WDSL-Dokument automatisch generieren zu lassen. Diese Methode ist verbreiteter, da die Entwicklungsumgebung meistens selbst dafür sorgt und die WSDL-Beschreibung automatisch erzeugt wird. Eine WSDL-Beschreibung liegt wie beschrieben in XML-Formatierung vor und hat eine bestimmte Struktur, wie in Abbildung 10 illustriert. Abb.10 <definitions name="nmtoken"? targetnamespace="uri"?> <import... /> * <!--Dient zur Modularisierung--> <types... />? <!--Datentyp Definitionen--> <message... /> * <!--Abstrakte Definition der Daten--> <porttype... > * <!--Abstrakte Menge von Aktionen--> <operation... > * <!--Abstrakte Beschreibung einer Aktion--> </porttype> <binding... /> * <!--Konkretes Protokoll und Daten Formate--> <service... > * <!--Menge von verwandten Endpunkten--> <port... /> * <!--Netzwerk Adresse eines einzelnen Endpunkts--> </service> </definitions> 16

17 Eine Beschreibung eines Dienstes in der WSDL zu spezifizieren hat viele Vorteile. Zum einem die Modularität des WSDL-Dokuments, das die Wartbarkeit erhöht. Außerdem die Selbstbeschreibungsfähigkeit. Da WSDL ja ein XML Format ist, ist es zugleich menschenlesbar. Somit trägt es auch etwas bei der Dokumentation von verteilten Systemen bei. Es gibt zahlreiche SOAPbzw. Web Services Toolkits und fast jedes enthält auch einen WSDL-Compiler. Und es herrscht große Akzeptanz und Unterstützung gegenüber WSDL, auch von der Open Community. WSDL hat aber auch gewisse Nachteile, die nicht ungenannt bleiben sollten. WSDL fehlt es an Semantik der auszutauschenden Nachrichten. So ist der Weg zum Traum Services in der Laufzeit zu suchen und binden noch sehr lang. WSDL ist, wenn man sich näher damit beschäftigt, an manchen Stellen zu komplex Zusammenspiel: Abb.11 Nun wurden die Komponenten SOAP, UDDI und WSDL vorgestellt. Anhand einer Abbildung 11 soll nun das Zusammenspiel beziehungsweise die Verwendung der einzelnen Komponenten erläutern werden. Soap-Server 1und Soap-Server 2 seien zwei Server auf denen jeweils ein Web Service läuft. Ebenfalls befindet sich auf dem Server die Beschreibung des Dienstes, also ein WSDL-Dokument. Bei Punkt eins registrieren sich Soap-Server 1 und Soap-Server 2 via Publisher-API bei einem Server, wo ein UDDI-Dienst läuft, um ihren Web Service anzumelden und für andere zugänglich zu machen. Soap-Client sucht via Inquiry-API, nach einem bestimmten Dienst. Der Soap-Client wendet sich also an den UDDI-Server mit einer Suchanfrage und bekommt eine WSDL-Beschreibung oder in unserem Beispiel die Adresse des Dienstes/der WSDL-Beschreibung. Nun kennt der Soap-Client die Adresse von Soap-Server 2 und kann sich die WSDL-Breschreibung holen. Der Client fordert nun eine Dienstbeschreibung vom Soap-Server 1 an. Wenn der Soap-Client das WSDL-Dokument bekommt, wird eine Webserviceproxyklasse angelegt. Der Client instanziiert die Webserviceproxyklasse und ruft die Methode auf, die der Web Service anbietet. Clientseitig existiert also ein Interface des eigentlichen Webservices. Nun werden durch den Aufruf die Argumente des Aufrufs von Systemkomponenten zu einer SOAP-Nachricht serialisiert und an den SOAP-/Webserver übertragen. Am Soap-Server wird die SOAP-Nachricht deserialisiert (XML-Mapping) und eine Instanz der Webserviceklasse erstellt und die Methode aufgerufen. Die Antwort der Applikation wird nun auf der Serverseite serialisiert und die SOAP-Nachricht wird an den Client zurück gesendet. Beim geschieht nun das Deserialisieren der SOAP-Nachricht und Übergabe der Antwort an den Webproxy. Nun wird das Ergebnis an die Clientapplikation weitergeleitet und der Aufruf ist zu Ende. Web Services sind mehr als normale Webapplikationen. Sie beherbergen eine Menge von guten, innovativen Ideen, die leider noch nicht den Weg zum Mainstream geschafft haben. Es wird wohl noch eine Weile dauern, bis eine erste wirklich sinnvolle Applikation mit Web Services realisiert wird. 17

18 2.7 Applet/WebStart Die Themen die bisher behandelt wurden, handelten über Techniken für Webapplikationen, die hauptsächlich serverseitig liefen. Nun sollen Techniken vorgestellt werden, die auch innerhalb eines Browsers funktionieren, hauptsächlich aber clientseitig ausgeführt werden Applet Ein Applet ist ein kleines Java-Programm, was hauptsächlich grafikorientiert arbeitet und in einem Container läuft. Eine Container kann eine Browserinstanz oder in einem Appletviewer sein. Applets laufen innerhalb von HTML-Seiten; sie können also über das WWW jedem Interessierten bereitgestellt werden. Um ein Applet clientseitig auszuführen, muss der Client eine bestimmte html-seite aufrufen, in der ein Applet referenziert ist. Der html-code beinhaltet das <applet>-tag, was ein solches Applet referenzieren könnte. Beispiel: <applet code="[classelement].class" width="[wert]" heigth="[wert]" codebase="../"> </applet> Das Attribut code steht für den Namen der Startklasse des Applets, also die kompilierte Datei, die den Quellcode des Applets enthält. width und heigth stehen für die Maße, wie das Applet im Browser dargestellt werden soll. Im Attribut codebase ist die URL verzeichnet, wo die benötigten Ressourcen für das Applet zu finden sind. Abb.12 Wenn ein Client eine html-seite aufruft, in der ein Appletaufruf beherbergt wird, geschieht das, was in Abbildung 12 veranschaulicht ist. Ein Client ruft also eine Seite auf, die ein Applet lädt. Durch den Applet-Tag-Eintrag im HTML-Code wird die Java- Klasse (*.class) oder das Java-Archiv (*.jar) in den Cache des Clients geladen und ausgeführt. Die Java Virtual Machine (jvm) wird gestartet und das Applet läuft nun in der Browserinstanz. Man sagt auch, dass das Applet in einer Sandbox läuft, da das Applet den Sicherheitsbestimmungen der jvm unterliegt. Diese sind so eingestellt, dass das Applet keine Berechtigungen für Lese-, bzw. Schreiboperationen bezüglich des lokalen Systems besitzt. Es darf nur mit dem Server von dem es geladen wurde kommunizieren, es darf keine Programme auf dem Client ausführen und hat nur beschränkten Zugriff auf die Java-Klassen-Bibliotheken. Um das Applet mit Parametern aufzurufen, können in der HTML-Seite diese Parameter spezifiziert werden. Um ein Applet zu schreiben zu können, müssen 4 Methoden überschreiben werden, die hier nicht näher erklärt werden sollen. Applets wurden aber auf Grund von Performanceproblemen und des Aufkommens von einfachen Scriptsprachen selten im großen Stil eingesetzt Webstart Webstart fällt wie Web Services etwas aus dem Kontext der typischen Umgebungen für die Erstellung von Webapplikationen. Es wird aber trotz vorgestellt, da eine Webstartanwendung vom Browser aus gestartet werden kann und als Fortsetzung der Applet-Idee verstanden werden kann. Es definiert sich 18

19 dadurch, dass es für Anwendungen keine Installationsphase gibt. Anwendungen können herunter geladen und gecacht werden und unterstützt wird ein transparentes (Versionscheck) und inkrementeller (nur Änderungen) Update. Webstart ist eine Technologie, die das Verteilen von Java-Applikationen sehr stark vereinfacht. Es ermöglicht, per einfachen Klick im Browser eine Anwendung zu starten. Dabei werden die in der Java2-Plattform enthaltenen Sicherheitsmerkmale unterstützt. Und das sogar browser- und betriebssystemunabhängig. Java Webstart vereinfacht dabei die Installation neuer Software im Gegensatz zu herkömmlicher Distribution beispielsweise per Datenträgeraustausch extrem. Der simple Klick im Browser genügt, die Software mit allen benötigten Dateien auf den heimischen Rechner zu laden und zu installieren. Webstart generiert dabei automatisch alle gewünschten Verknüpfungen, sei es auf dem Desktop oder im Startmenü (Windows). Das Webstartpaket ist seit der Version 1.4 fester Bestandteil des JDK. Um zu zeigen wie Webstart funktioniert, wird in der Abbildung 13 gezeigt. Dort ist illustriert, wie ein Client eine Webstartanwendung starten kann. Zuerst wird eine HTTP-Anfrage nach einer jnlp-datei gestellt. Was diese Datei genau beinhaltet wird in einem späteren Abschnitt behandelt. Nach dem Download der Datei startet Webstart, da es auf die Dateiendung *.jnlp reagiert. In der jnlp-datei ist die Anwendung spezifiziert, die gestartet werden soll. Webstart prüft nun, ob die in der jnlp-datei spezifizierte Anwendung schon mal auf dem Client ausgeführte wurde. Findet Webstart die Anwendung im Cache des Clients und ist es die Version, die den jnlp-einstellungen entspricht, zum Beispiel immer die neuste Anwendung auf dem Client ausführen, wird die Anwendung gestartet. Falls die Anwendung nicht im Cache existiert oder es sich um eine andere Version handelt, stellt der Client(Webstart) eine Anfrage an den Server, der in der jnlp-datei eingetragen ist, um die Anwendung in den Cache des Clients zu laden. Befindet sich die Anwendung dann im Cache wird sie gestartet. Auch eine Webstartanwendung unterscheidet sich, wie ein Applet von einer üblichen Javaapplikation durch spezielle Sicherheitsbestimmungen. Eine Webstartanwendung beinhaltet ein bestimmtes Zertifikat, welches die Rechte der Anwendung spezifiziert. Je nach dem ob die Anwendung Lese- oder Schreibzugriffe anfordert, wird das für lokale Dateisystemzugriffe erforderliche Zertifikat aus der Anwendung extrahiert. Dieses muss vom Nutzer bestätigt werden, denn schließlich darf eine Anwendung nur auf die lokalen Datenträger schreiben, wenn der Nutzer dies explizit bestätigt hat. Eine Anwendung, die nicht auf Datenträgerzugriffe angewiesen ist, braucht auch kein Zertifikat. Will man eine Webstartanwendung entwickeln, sind auch einige Punkte zu beachten. Zuerst muss die Software entwickelt werden und sie als JAR-Archiv packen. Die weiters Vorgehensweise hängt nun von der Anwendung an sich ab. Wenn die Anwendung keinen lokalen Zugriff braucht, muss eine jnlp-datei erstellt werden, die die Anwendung beschreibt. Soll das Programm aber auf dem Zielsystem auch auf die Festplatte zugreifen können, so ist das JAR- Archiv zu signieren. Signieren bedeutet, dass das Archiv zum einen durch die Signatur dem Herausgeber zugeordnet werden kann. Wenn man den Herausgeber des Programms kennt, und diesem vertraut, so kann man auch dem von ihm erstellten Programm vertrauen. Zum anderen stellt die Signatur sicher, dass das Archiv nach seiner Erstellung nicht mehr verändert wurde. Somit ist sichergestellt, dass keine dritte Person das Programm "böswillig" verändert hat. Eine Grundvoraussetzung ist wieder ein JAR- Archiv mit Manifest. Nun muss die Anwendung noch auf einem Webserver verfügbar gemacht und ein Link zu der jnlp-datei auf einer html-seite untergebracht werden. Abb.13 19

20 JNLP - Java Network Launching Protocol JNLP definiert ein plattformunabhängiges Protokoll für die Verteilung, Installation, Starten und Updaten von Javaprogrammen über das Netzwerk. Es beschreibt, wie eine Applikation für JNLP Clients auf einem Web Server hinterlegt werden muss. Diese Beschreibung liegt im XML-Format vor und besitzt vordefinierte Tags. Beispiel: <?xml version="1.0" encoding="utf-8"?> <jnlp spec=" " codebase=" href="programm.jnlp"> <information> <title>programm Version 0.0 </title> <vendor>gockel </vendor> <homepage href=" <description>programm </description> <description kind="short">tolles Programm in Webstart </description> <icon href=" <offline-allowed/> </information> <security> <all-permissions /> </security> <resources> <j2se version="1.4+"/> <jar href=" download="eager"/> </resources> <application-desc main-class="die.applikation"/> </jnlp> Der <information>-block enthält einige Metainformationen über die Anwendung. <security> und <resource> beschreiben, welche Rechte die Anwendung besitzt und wo (auf welchen Server) sie zu finden ist. Im <title> Tag steht der Name der Applikation. Der <vendor> Tag spezifiziert den Anbieter oder Hersteller der Anwendung. <Homepage> enthält eine URL zur Homepage der Anwendung. Diese wird vom Applikation-Manager genutzt, um auf eine Seite zu verweisen, wo der Anwender mehr Informationen über die Applikation erhalten kann. <Description> ist eine kurze Beschreibung zur Applikation. Das dazugehörige kind Attribut legt fest, wie die Beschreibung genutzt werden kann: Wenn die Anwendung den gleichen Zugriff haben soll, wie eine regulär gestartete Anwendung, so ist das <all-permissions/> Tag einzusetzen. Der Anwendung wird somit der volle Systemzugriff gegeben. Die Grundvoraussetzung hierfür ist allerdings, dass die Anwendung vorher entsprechend signiert wurde. Sollte die Anwendung aus mehreren JAR-Archiven bestehen, so sind diese alle zu signieren. Im Ressourcen-Block werden alle benötigten Elemente der Anwendung aufgelistet. In unserem Fall sind es nur zwei Elemente: Zum einen das Element jar. In diesem Tag wird ein URI zum Archiv beschrieben. Selbstverständlich können an dieser Stelle mehrere Archive angegeben werden. Des Weiteren kann man die Version einer bestimmten virtuellen Maschine voraussetzen. Für diese Einschränkung dient das Tag j2se. Es ist ebenfalls möglich, verschiedene Ressourcen wie Betriebssystem (os), eine bestimmte Plattform (arch), native Komponenten (nativelib) oder bestimmte Packages (package) im Ressourcen-Block anzugeben. Diese wurden im Beispiel aber nicht verwendet. Das application-element definiert den Start der eigentlichen Anwendung. Es besitzt ein optionales Attribut main-class. Dieses enthält den Klassennamen der Klasse, die die main-methode enthält. Das Attribut kann bei einer entsprechenden Manifest-Datei in der JAR-Datei natürlich auch weggelassen werden. In application können bei bedarf auch Übergabe- bzw. Startparameter an die main- Methode übergeben werden. Dabei kann man das argument-element nutzen. 20