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

Größe: px
Ab Seite anzeigen:

Download "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 https://... 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: "http://tempuri.org/calc" <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:body> <Calc xmlns="http://tempuri.org/"> <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="http://www.w3.org/2001/xmlschema-instance" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:body> <CalcResponse xmlns="http://tempuri.org/"> <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="http://www.vangock.de/webstart/" href="programm.jnlp"> <information> <title>programm Version 0.0 </title> <vendor>gockel </vendor> <homepage href="http://www.vangock.de"/> <description>programm </description> <description kind="short">tolles Programm in Webstart </description> <icon href="http://www.vangock.de/webstart/logo.gif"/> <offline-allowed/> </information> <security> <all-permissions /> </security> <resources> <j2se version="1.4+"/> <jar href="http://www.vangock.de/webstart/programm.jar" 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

Web 2.0 Software-Architekturen

Web 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,

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Hauptseminar 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 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

Mehr

Datenbank-basierte Webserver

Datenbank-basierte Webserver Datenbank-basierte Webserver Datenbank-Funktion steht im Vordergrund Web-Schnittstelle für Eingabe, Wartung oder Ausgabe von Daten Datenbank läuft im Hintergrund und liefert Daten für bestimmte Seiten

Mehr

Proseminar: Website-Management-Systeme

Proseminar: Website-Management-Systeme Proseminar: Website-Management-Systeme Thema: Web: Apache/Roxen von Oliver Roeschke email: o_roesch@informatik.uni-kl.de Gliederung: 1.) kurze Einleitung 2.) Begriffsklärung 3.) Was ist ein Web? 4.) das

Mehr

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen...

Dataport IT Bildungs- und Beratungszentrum. HTML- Grundlagen und CSS... 2. XML Programmierung - Grundlagen... 3. PHP Programmierung - Grundlagen... Inhalt HTML- Grundlagen und CSS... 2 XML Programmierung - Grundlagen... 3 PHP Programmierung - Grundlagen... 4 Java - Grundlagen... 5 Java Aufbau... 6 ASP.NET Programmierung - Grundlagen... 7 1 HTML- Grundlagen

Mehr

Ausarbeitung zum Vortrag Java Web Start von Adrian Fülöp Fach: Komponentenbasierte Softwareentwicklung WS 06/07 Fachhochschule Osnabrück

Ausarbeitung zum Vortrag Java Web Start von Adrian Fülöp Fach: Komponentenbasierte Softwareentwicklung WS 06/07 Fachhochschule Osnabrück Ausarbeitung zum Vortrag Java Web Start von Adrian Fülöp Fach: Komponentenbasierte Softwareentwicklung WS 06/07 Fachhochschule Osnabrück Adrian Fülöp (297545) - 1 - Inhaltsverzeichnis: 1. Einführung 2.

Mehr

Sicherheit in Rich Internet Applications

Sicherheit in Rich Internet Applications Sicherheit in Rich Internet Applications Florian Kelbert 14.02.2008 Seite 2 Sicherheit in Rich Internet Applications Florian Kelbert 14.02.2008 Inhaltsverzeichnis Grundlagen Ajax und Mashups Adobe Flash-Player

Mehr

Client/Server-Programmierung

Client/Server-Programmierung lient/server-programmierung WS 2014/2015 etriebssysteme / verteilte Systeme rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, üro: H- 8404 Stand: 15. Oktober 2015 etriebssysteme / verteilte Systeme

Mehr

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web 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.

Mehr

Web Services: Inhalt

Web 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

Mehr

FuE-Bereich IuK-Systeme im Gesundheitswesen

FuE-Bereich IuK-Systeme im Gesundheitswesen FuE-Bereich IuK-Systeme im Gesundheitswesen IG XML und Web Services Dipl.-Inform. Axel Schwolow IG Kommunikation im Web Entwicklung früher ausschließlich Kommunikation über Browser heute zunehmend direkt

Mehr

Anwendungsprotokolle: HTTP, POP, SMTP

Anwendungsprotokolle: HTTP, POP, SMTP Anwendungsprotokolle: HTTP, POP, SMTP TCP? UDP? Socket? eingesetzt, um Webseiten zu übertragen Zustandslos Nutzt TCP Client schickt Anfrage ( HTTP-Request ) an Server, Server schickt daraufhin Antwort

Mehr

XML-RPC, SOAP und Web Services. Jörn Clausen joern@techfak.uni-bielefeld.de

XML-RPC, SOAP und Web Services. Jörn Clausen joern@techfak.uni-bielefeld.de XML-RPC, SOAP und Web Services Jörn Clausen joern@techfak.uni-bielefeld.de Übersicht Was ist RPC? Was hat XML mit RPC zu tun? Was sind XML-RPC und SOAP? Was sind Web Services? Wird das die Welt retten?

Mehr

Praktikum aus Softwareentwicklung 2. Web Services. Java Praktikum SS 2010 Gerald.Ehmayer@borland.com

Praktikum 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

Mehr

ISA Server 2004 HTTP Filter - Von Marc Grote

ISA Server 2004 HTTP Filter - Von Marc Grote Seite 1 von 11 ISA Server 2004 HTTP Filter - Von Marc Grote Die Informationen in diesem Artikel beziehen sich auf: Microsoft ISA Server 2004 Einleitung In diesem Artikel erläutere ich die Konfiguration

Mehr

VS11 Slide 1. Verteilte Systeme. Vorlesung 11 Sebastian Iwanowski FH Wedel

VS11 Slide 1. Verteilte Systeme. Vorlesung 11 Sebastian Iwanowski FH Wedel VS11 Slide 1 Verteilte Systeme Vorlesung 11 Sebastian Iwanowski FH Wedel VS11 Slide 2 Verteilte Systeme 1. Innovative Beispiele aus der Praxis 2. Allgemeine Anforderungen und Techniken verteilter Systeme

Mehr

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13

NEWpixi* API und die Umstellung auf REST. Freitag, 3. Mai 13 NEWpixi* API und die Umstellung auf REST Fakten NEWpixi* API Technik REST-basierend.NET Webservice IIS Webserver Release 31. August 2013, zusammen mit dem NEWpixi* ELI Release Legacy API und erste NEWpixi*

Mehr

Apache Tomcat. Inhalt. Rechner und Netzarchitektur SS 2003. Einleitung. Architektur

Apache Tomcat. Inhalt. Rechner und Netzarchitektur SS 2003. Einleitung. Architektur Apache Tomcat Rechner und Netzarchitektur SS 2003 Johannes Jabornig Daniel Peintner Inhalt Einleitung Was sind Servlets und JSP Vorteile Architektur Catalina Jasper Konnektoren Installation / Konfiguration

Mehr

Basistechnologien: Web-Services

Basistechnologien: Web-Services Alexander Rudolf Cloud-Computing Seminar Hochschule Mannheim WS0910 1/29 Basistechnologien: Web-Services Alexander Rudolf Hochschule Mannheim Fakultät für Informatik alexander.rudolf@stud.hs-mannheim.de

Mehr

Web Service Security

Web Service Security Hochschule für Angewandte Wissenschaften Hamburg Fachbereich Elektrotechnik und Informatik SS 2005 Masterstudiengang Anwendungen I Kai von Luck Web Service Security Thies Rubarth rubart_t@informatik.haw-hamburg.de

Mehr

!"# $ % Internet Protokolle: HTTP 1/38

!# $ % Internet Protokolle: HTTP 1/38 !"# $ % Internet Protokolle: HTTP 1/38 1 Themenübersicht Schichtenmodell Gopher /FTP Statistik URL Einleitung Anwendungsablauf Beispiel mit Telnet Request, Response Anfragemethoden header Negotiation Proxyserver

Mehr

PKI (public key infrastructure)

PKI (public key infrastructure) PKI (public key infrastructure) am Fritz-Haber-Institut 11. Mai 2015, Bilder: Mehr Sicherheit durch PKI-Technologie, Network Training and Consulting Verschlüsselung allgemein Bei einer Übertragung von

Mehr

ESB. Open Source ESB: Mule Flightreservation. Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus]

ESB. Open Source ESB: Mule Flightreservation. Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus] ESB Open Source ESB: Mule Flightreservation Res Gilgen Hochschule Luzern [Wählen Sie das Datum aus] Inhalt 1. Open Source ESB: Mule... 2 1.1. Überblick... 2 1.1.1. Das Beispiel Zeigt:... 2 1.2. Installationsanleitung...

Mehr

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java

Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Erstellung eines Frameworks für Shop Systeme im Internet auf Basis von Java Präsentation zur Diplomarbeit von Übersicht Java 2 Enterprise Edition Java Servlets JavaServer Pages Enterprise JavaBeans Framework

Mehr

Peter Sobe Internettechnologien. HTTP Protokoll (1) Hypertext Transport Protocol, größtenteils zum Austausch von Hypertext (HTML, xhtml) benutzt

Peter Sobe Internettechnologien. HTTP Protokoll (1) Hypertext Transport Protocol, größtenteils zum Austausch von Hypertext (HTML, xhtml) benutzt WWW Web basierend auf dem Internet Das Internet war bereits eher als das Web vorhanden, mit verteilten Anwendungen, Dateitransfer, Netzwerk- Dateisystemen (NFS) Web: entstanden durch Vorhandensein des

Mehr

Herzlich Willkommen! eine praxisnahe Übersicht. Mit Java ins Web - mb@bebox.franken.de. 26.11.2000 (c) Michael Behrendt -

Herzlich Willkommen! eine praxisnahe Übersicht. Mit Java ins Web - mb@bebox.franken.de. 26.11.2000 (c) Michael Behrendt - Herzlich Willkommen! Mit Java ins Web - eine praxisnahe Übersicht 1 Wer bin ich? Michael Behrendt, 21, Nürnberg kurzer Lebenslauf: 1991 Erster Rechner: Commodore C128 1995 Ausbildung zum Datenverarbeitungskaufmann

Mehr

4. Verwendete Methoden und Werkzeuge

4. Verwendete Methoden und Werkzeuge 4. Verwendete Methoden und Werkzeuge In diesem Kapitel werden die verschiedenen Methoden und Werkzeuge vorgestellt, die bei der Realisierung der Mediathek eingesetzt wurden. Zuerst werden die Grundlagen

Mehr

Termin 4: Web Services Computing

Termin 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

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Web Services mit Java

Web 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

Mehr

Dynamische Webanwendungen

Dynamische Webanwendungen Dynamische Webanwendungen Mohamed Said Seminar Moderne Informatik Universität Dortmund SS 2003 Mohamed Said / 2003-05-30 1 Überblick Einleitung (Konzept) Client-seitiges Skripting mit JavaScript CGI Server-seitiges

Mehr

JSP und Servlet Programmierung

JSP und Servlet Programmierung Seminarunterlage Version: 5.02 Copyright Version 5.02 vom 1. März 2013 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

Dynamische Webseiten

Dynamische Webseiten Dynamische Webseiten Seminar Medientechnik 30.06.2003 Dynamische Webseiten 1 Inhalt Allgemeine Funktionsweise eines Webservers Grundgedanke von dynamischen Webseiten Einschub: Dynamische Seitenerzeugung

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

Web- Applikationen. in Java-Web

Web- Applikationen. in Java-Web Einführung in Java-Web Web- Applikationen Frank Huber Humboldt-Universität zu Berlin Allgemeines Java: Programmierung ist Programmierung nach Konvention Insbesondere bei Web-Applikationen wurde eine API

Mehr

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen.

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. 181 In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. Wir beginnen mit dem Startup-Unternehmen Seals GmbH aus Frankfurt,

Mehr

Application Server und Continuous Integration

Application Server und Continuous Integration Application Server und Continuous Integration Outline 2 Einleitung Application Server Java EE Enterprise Applikationen vs. Web Applikationen Web Application Life Cycle Servlets JavaServer Pages verschiedene

Mehr

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System

Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Konzepte zur Datenhaltung für Webseiten in einem Web-Content- Management-System Web-Content-Management-Systeme () dienen dazu, komplexe Websites zu verwalten und den Autoren einzelner Webseiten möglichst

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung 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

Mehr

Web Service Entwicklung mit Java. Sven Lindow

Web 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

Mehr

Managed VPSv3 Was ist neu?

Managed 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

Mehr

Workflow, Business Process Management, 4.Teil

Workflow, 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

Mehr

Rechnernetze Übung 12

Rechnernetze Übung 12 Rechnernetze Übung 12 Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juli 2011 Sie kennen sicherlich sogenannte Web-Mailer, also WWW-Oberflächen über die Sie Emails lesen und vielleicht

Mehr

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition

Inhaltsverzeichnis. Enterprise Java im Überblick. Technologien der Java2 Enterprise Edition Inhaltsverzeichnis Vorwort 13 I Enterprise Java im Überblick 1 Bedeutung von Enterprise Java und IBM WebSphere 21 1.1 Enterprise Java 23 1.1.1 Anforderungen 23 1.1.2 E-Business 30 1.1.3 Java 36 1.2 IBM

Mehr

Installation Anleitung für JTheseus und MS SQL Server 2000

Installation Anleitung für JTheseus und MS SQL Server 2000 Installation Anleitung für JTheseus und MS SQL Server 2000 Inhaltsverzeichnis 1 Installation der Datenbank 3 1.1 Erstellen der Datenbank 3 1.2 Tabellen und Minimal Daten einlesen 4 1.3 Benutzer JTheseus

Mehr

Themen. Anwendungsschicht DNS HTTP. Stefan Szalowski Rechnernetze Anwendungsschicht

Themen. Anwendungsschicht DNS HTTP. Stefan Szalowski Rechnernetze Anwendungsschicht Themen Anwendungsschicht DNS HTTP Anwendungsschicht OSI-Schicht 7, TCP/IP-Schicht 4 Dienste für den Nutzer/Anwender Unabhängig von den niederen Schichten Verschiedene Dienste bzw. Services DNS HTTP FTP,

Mehr

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com Merkblatt: HSM Version 1.01 Systemvoraussetzungen, Setup und Trouble Shooting Kontakt: pdfsupport@pdf-tools.com Besitzer: PDF Tools AG Kasernenstrasse 1 8184 Bachenbülach Schweiz www.pdf-tools.com Copyright

Mehr

Leitfaden zur Installation von BitByters.Backup

Leitfaden zur Installation von BitByters.Backup Leitfaden zur Installation von BitByters.Backup Der BitByters.Backup - DASIService ist ein Tool mit dem Sie Ihre Datensicherung organisieren können. Es ist nicht nur ein reines Online- Sicherungstool,

Mehr

JAXR Java API for XML Registries. Jasmin Hatteh

JAXR Java API for XML Registries. Jasmin Hatteh JAXR Java API for XML Registries Jasmin Hatteh Übersicht Web Service Architektur Rollenverteilung Interaktionen Business-Registry UDDI ebxml JAXR Architektur Interaktionen Pakete Was sind Web Services?

Mehr

Daten-Kommunikation mit crossinx

Daten-Kommunikation mit crossinx Daten-Kommunikation mit Datenübertragung.doc Seite 1 von 8 Inhaltsverzeichnis 1 Einführung... 3 1.1 Datenübertragung an... 3 1.2 Datenversand durch... 3 2 X.400... 4 3 AS2... 4 4 SFTP (mit fester Sender

Mehr

Version 4.4. security.manager. Systemvoraussetzungen

Version 4.4. security.manager. Systemvoraussetzungen Version 4.4 security.manager Systemvoraussetzungen Version 4.4 Urheberschutz Der rechtmäßige Erwerb der con terra Softwareprodukte und der zugehörigen Dokumente berechtigt den Lizenznehmer zur Nutzung

Mehr

:HE'DWHQEDQN$QELQGXQJ PLW-DYD6HUYOHWVEDVLHUHQG DXI$SDFKH-6HUY2UDFOHL

:HE'DWHQEDQN$QELQGXQJ PLW-DYD6HUYOHWVEDVLHUHQG DXI$SDFKH-6HUY2UDFOHL DNDGLD,QIRUPDWLRQ 7HFKQRORJ\ :HE'DWHQEDQN$QELQGXQJ PLW-DYD6HUYOHWVEDVLHUHQG DXI$SDFKH-6HUY2UDFOHL Authoren: Christoph Gächter / Martin Zahn Copyright 1999 Akadia AG All rights reserved $NDGLD$* Information

Mehr

Zustandsgebundene Webservices

Zustandsgebundene 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

Mehr

Userhandbuch. Version B-1-0-2 M

Userhandbuch. Version B-1-0-2 M Userhandbuch Version B-1-0-2 M Inhaltsverzeichnis 1.0 Was bietet mir SERVRACK?... 3 1.1 Anmeldung... 3 1.2 Passwort vergessen?... 3 1.3 Einstellungen werden in Realtime übernommen... 4 2.0 Die SERVRACK

Mehr

SOAP Simple Object Access Protocol

SOAP Simple Object Access Protocol Informatikseminar Tobias Briel Überblick 1. Einführung - was ist? 2. Middlewaretechnologie 3. Aufbau von Nachrichten 4. Vergleiche 5. Beispielanwendung 6. Zusammenfassung 1 Einführung was ist Soap? neue

Mehr

Howto. Konfiguration eines Adobe Document Services

Howto. Konfiguration eines Adobe Document Services Howto Konfiguration eines Adobe Document Services (ADS) Inhaltsverzeichnis: 1 SYSTEMUMGEBUNG... 3 2 TECHNISCHE VERBINDUNGEN ZWISCHEN DEN SYSTEMEN... 3 2.1 PDF BASIERENDE FORMULARE IN DER ABAP UMGEBUNG...

Mehr

.NET-Networking 2 Windows Communication Foundation

.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

Mehr

Datenbanksysteme SS 2007

Datenbanksysteme SS 2007 Datenbanksysteme SS 2007 Frank Köster (Oliver Vornberger) Institut für Informatik Universität Osnabrück Kapitel 9c: Datenbankapplikationen Architektur einer Web-Applikation mit Servlets, JSPs und JavaBeans

Mehr

Remote- und Server-Programmierung. Dr. Wolfgang Süß Thorsten Schlachter

Remote- und Server-Programmierung. Dr. Wolfgang Süß Thorsten Schlachter Remote- und Server-Programmierung Dr. Wolfgang Süß Thorsten Schlachter Remote Method Invocation (RMI) Servlets WebServices 2 Remote Method Invocation (RMI) Das Remote Method Invocation (RMI)-Framework

Mehr

Hochschule Darmstadt Fachbereich Informatik

Hochschule Darmstadt Fachbereich Informatik Hochschule Darmstadt Fachbereich Informatik 6.3 Systemarchitektur 430 6.3 Systemarchitektur Drei Schichten Architektur Die "Standardtechniken" des Software-Engineering sind auch auf die Architektur einer

Mehr

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL 1 TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL Kleine Auswahl bekannter Sicherheitsprotokolle X.509 Zertifikate / PKIX Standardisierte, häufig verwendete Datenstruktur zur Bindung von kryptographischen

Mehr

Benutzerdokumentation Web-Portal

Benutzerdokumentation Web-Portal GRUPP: SWT0822 Benutzerdokumentation Web-Portal Yet Another Reversi Game Martin Gielow, Stephan Mennicke, Daniel Moos, Christine Schröder, Christine Stüve, Christian Sura 05. Mai 2009 Inhalt 1. Einleitung...3

Mehr

Installation und Benutzung AD.NAV.ZipTools

Installation und Benutzung AD.NAV.ZipTools Installation und Benutzung AD.NAV.ZipTools Version 1.0.0.0 ALTENBRAND Datentechnik GmbH Am Gelicht 5 35279 Neustadt (Hessen) Tel: 06692/202 290 Fax: 06692/204 741 email: support@altenbrand.de Die Komponente

Mehr

Android Kurs Online Kurs Entwicklung auf Android-Handys

Android Kurs Online Kurs Entwicklung auf Android-Handys Android Kurs Online Kurs Entwicklung auf Android-Handys Akademie Domani info@akademiedomani.de Allgemeines Programm des Kurses Modul Eins - Programmierung J2ee 1) Grundlegende Java - Programmierung : Grundlegende

Mehr

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION

COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION COI-BUSINESSFLOW SOAP-SERVER MODUL INFORMATION Präambel Die COI GmbH entwickelt seit 1988 moderne, prozessorientierte Lösungen rund um die Themen Archivierung, Dokumentenmanagement und Workflow. Als kompetenter

Mehr

Sicherheit von Webapplikationen Sichere Web-Anwendungen

Sicherheit von Webapplikationen Sichere Web-Anwendungen Sicherheit von Webapplikationen Sichere Web-Anwendungen Daniel Szameitat Agenda 2 Web Technologien l HTTP(Hypertext Transfer Protocol): zustandsloses Protokoll über TCP auf Port 80 HTTPS Verschlüsselt

Mehr

Datenempfang von crossinx

Datenempfang von crossinx Datenempfang von crossinx Datenempfang.doc Seite 1 von 6 Inhaltsverzeichnis 1 Einführung... 3 2 AS2... 3 3 SFTP... 3 4 FTP (via VPN)... 4 5 FTPS... 4 6 Email (ggf. verschlüsselt)... 5 7 Portalzugang über

Mehr

Enterprise Java Beans Einführung

Enterprise Java Beans Einführung Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse

Mehr

1. Java Grundbegriffe

1. Java Grundbegriffe 1. Java Grundbegriffe Geschichte von Java Programmieren mit Java Interpretieren vs. Kompilieren Java Byte-Code Jave Virtual Machine Arbeitsmaterialien Allgemeine Informatik 2 SS09 Folie 1.1 Java, eine

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

E-Mails versenden aber sicher! Secure E-Mail

E-Mails versenden aber sicher! Secure E-Mail E-Mails versenden aber sicher! Secure E-Mail Leitfaden S Kreisparkasse Verden 1 Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische

Mehr

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik Programmieren I Die Programmiersprache Java KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Eigenschaften von Java Java ist eine

Mehr

Webserver allgemein Voraussetzung für die Integration von Plone NginX Apache 2 Demonstration Zusammenfassung

Webserver allgemein Voraussetzung für die Integration von Plone NginX Apache 2 Demonstration Zusammenfassung Webserver allgemein Voraussetzung für die Integration von Plone NginX Apache 2 Demonstration Zusammenfassung Software zur Annahme und Verarbeitung von HTTP/HTTPs- Requests (Port 80/443) benutzerdefinierte

Mehr

HOB WebSecureProxy Universal Client

HOB WebSecureProxy Universal Client HOB GmbH & Co. KG Schwadermühlstr. 3 90556 Cadolzburg Tel: 09103 / 715-0 Fax: 09103 / 715-271 E-Mail: support@hob.de Internet: www.hob.de HOB WebSecureProxy Universal Client Juli 2011 HOB WebSecureProxy

Mehr

HOB Remote Desktop VPN

HOB Remote Desktop VPN HOB GmbH & Co. KG Schwadermühlstr. 3 90556 Cadolzburg Tel: 09103 / 715-0 Fax: 09103 / 715-271 E-Mail: support@hob.de Internet: www.hob.de HOB Remote Desktop VPN Sicherer Zugang mobiler Anwender und Geschäftspartner

Mehr

Secure Socket Layer v. 3.0

Secure Socket Layer v. 3.0 Konzepte von Betriebssystem-Komponenten Schwerpunkt Internetsicherheit Secure Socket Layer v. 3.0 (SSLv3) Zheng Yao 05.07.2004-1 - 1. Was ist SSL? SSL steht für Secure Socket Layer, ein Protokoll zur Übertragung

Mehr

Ajax & GWT. Kurs: User Interfaces und ihre Evaluierung Dozent: Manfred Thaller WS 2012/2013 Referent: Rafael Kalina

Ajax & GWT. Kurs: User Interfaces und ihre Evaluierung Dozent: Manfred Thaller WS 2012/2013 Referent: Rafael Kalina Ajax & GWT Kurs: User Interfaces und ihre Evaluierung Dozent: Manfred Thaller WS 2012/2013 Referent: Rafael Kalina Ajax Technisches Verfahren, bei dem Browser aktualisierte Inhalte nicht mehr synchron

Mehr

Web Services and Semantic Web - Introduction to Web Services. von Andreas Weiler

Web Services and Semantic Web - Introduction to Web Services. von Andreas Weiler Web Services and Semantic Web - Introduction to Web Services von Andreas Weiler Definitionen Beispiele Technologien Vorteile Kritik Abschlussbeurteilung Fragen? Definition von IBM: Web services are a new

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de Fortgeschrittene Servlet- Techniken Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Servlet Initialisierung Attribute und Gültigkeitsbereiche Sessions

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr

Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware

Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware Das E-Mail-Programm Outlook 98 von Microsoft bietet Ihnen durch die Standard- Integration des E-Mail-Protokolls S/MIME (Secure/MIME) die Möglichkeit,

Mehr

Forefront Threat Management Gateway (TMG) und Forefront Unified Access Gateway (UAG) Die perfekte Lösung

Forefront Threat Management Gateway (TMG) und Forefront Unified Access Gateway (UAG) Die perfekte Lösung Forefront Threat Management Gateway (TMG) und Forefront Unified Access Gateway (UAG) Die perfekte Lösung Das Problem Die Abkündigungen seitens Microsoft von Forefront Threat Management Gateway (TMG) und

Mehr

Erstellung eines SharkNet Installers für Windows mit Inno Setup Compiler 5.4.2

Erstellung eines SharkNet Installers für Windows mit Inno Setup Compiler 5.4.2 Erstellung eines SharkNet Installers für Windows mit Inno Setup Compiler 5.4.2 1. Benötigte Software Zur Erstellung des Installers wird folgende Software benötigt. Es wird sich in dieser Dokumentation

Mehr

Verschlüsselung der Kommunikation zwischen Rechnern

Verschlüsselung der Kommunikation zwischen Rechnern Verschlüsselung der Kommunikation zwischen Rechnern Stand: 11. Mai 2007 Rechenzentrum Hochschule Harz Sandra Thielert Hochschule Harz Friedrichstr. 57 59 38855 Wernigerode 03943 / 659 0 Inhalt 1 Einleitung

Mehr

Kundenleitfaden Secure E-Mail

Kundenleitfaden Secure E-Mail Vorwort Wir leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie das Versenden von E-Mails. Neben den großen Vorteilen, die uns elektronische

Mehr

Web Visu Tutorial. Hipecs Web Visu. Übersicht

Web Visu Tutorial. Hipecs Web Visu. Übersicht Revision Date V100 10082011 Hipecs Web Visu Die hipecs (high performance controller system) bietet die Möglichkeit einer sog Web-Visualisierung über den integrierten Webserver Hierfür wird im Standard

Mehr

Web 2.0 Architekturen und Frameworks

Web 2.0 Architekturen und Frameworks Web 2.0 Architekturen und Frameworks codecentric GmbH Mirko Novakovic codecentric GmbH Quality Technische Qualitätssicherung in Software-Projekten mit Fokus auf Performance, Verfügbarkeit und Wartbarkeit

Mehr

email, Applikationen, Services Alexander Prosser

email, Applikationen, Services Alexander Prosser email, Applikationen, Services Alexander Prosser WWW für Menschen und Maschinen SEITE 2 (C) ALEXANDER PROSSER WWW für Menschen (1) Mensch gibt Adresse ein, z.b. evoting.at oder klickt Link an (2) Server

Mehr

ESB - Elektronischer Service Bericht

ESB - Elektronischer Service Bericht Desk Software & Consulting GmbH ESB - Elektronischer Service Bericht Dokumentation des elektronischen Serviceberichts Matthias Hoffmann 25.04.2012 DESK Software und Consulting GmbH Im Heerfeld 2-4 35713

Mehr

Seminararbeit Ruby Uno Kartenspiel

Seminararbeit Ruby Uno Kartenspiel Seminararbeit Ruby Uno Kartenspiel Autor: Fabian Merki Fabian Merki 05.11.2006 1 von 10 Inhaltsverzeichnis Einleitung... 3 Die Idee... 4 Design und Implementierung in Ruby... 5 Testing... 7 Startbefehle...

Mehr

Technische Beschreibung: EPOD Server

Technische 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

Mehr

Active Server Pages. Internetanbindung von Datenbanken. Gliederung. Einführung in ASP. Sessions mit ASP. Datenbankanbindung mit ASP ASP-1

Active Server Pages. Internetanbindung von Datenbanken. Gliederung. Einführung in ASP. Sessions mit ASP. Datenbankanbindung mit ASP ASP-1 Internetanbindung von Datenbanken Active Server Pages ASP-1 Gliederung Einführung in ASP Sessions mit ASP Datenbankanbindung mit ASP Brunner, Fromm, Huppert ASP-2 Einführung in ASP ASP-3 Entwicklung des

Mehr

REST Grundlagen. Seminar Aktuelle Software-Engineering-Praktiken für das World Wide Web. Olga Liskin

REST Grundlagen. Seminar Aktuelle Software-Engineering-Praktiken für das World Wide Web. Olga Liskin <olga.liskin@gmail.com> REST Grundlagen Seminar Aktuelle Software-Engineering-Praktiken für das World Wide Web Olga Liskin Übersicht Motivation, Einführung Architekturstil REST RESTful Webservices Patterns,

Mehr

Signieren und Verschlüsseln mit Outlook 2013

Signieren und Verschlüsseln mit Outlook 2013 Anleitung: Von Tobias Neumayer (support@thi.de) MAIL-VERSCHLÜSSELUNG / SIGNIERUNG Einführung Die meisten Mailprogramme unterstützen den Umgang mit S/MIME-Zertifikaten zur Verschlüsselung bzw. Signierung

Mehr

Benutzerzertifikate für Java Webstart

Benutzerzertifikate für Java Webstart Benutzerzertifikate für Java Webstart Benutzerdokumentation Wien 5. Dezember 2011 Florian Bruckner, Florian Heinisch 3kraft IT GmbH & Co KG Wasagasse 26/2 1090 Wien Österreich Tel: +43 1 920 45 49 Fax

Mehr

eytron VMS Webanwendung Fehlersuche und -Behebung

eytron VMS Webanwendung Fehlersuche und -Behebung eytron VMS Webanwendung Fehlersuche und -Behebung 2009 ABUS Security-Center GmbH & Co. KG, Alle Rechte vorbehalten Diese Anleitung soll Ihnen Unterstützung für den Fall geben, dass die Webanwendung nach

Mehr

Web Services. Dr. Wolfgang Süß

Web Services. Dr. Wolfgang Süß Service-orientierte Architektur (SOA) Architekturkonzept, da sich aus Diensten zusammensetzt. 3 Komponenten: Konnektoren: register Registrierung eines Dienstes bei einer Registry find Suchanfrage eines

Mehr