KTSI Web Based Instrument Remote Control (KWIRC)

Größe: px
Ab Seite anzeigen:

Download "KTSI Web Based Instrument Remote Control (KWIRC)"

Transkript

1 KTSI Web Based Instrument Remote Control (KWIRC) Web-basierte Konfiguration und Steuerung astronomischer Instrumente Dokumentation Version 1.00 Auftraggeber: Wildi, Markus Zimmermann, Lukas Betreuender Dozent: Tanner, Ronald Auftragnehmer: Reimann, Christoph Sütterlin, Patrik Müller, Andres Erstellt am

2 Inhaltsverzeichnis 1. Einleitung Zweck des Dokuments Geltungsbereich Übersicht Zweck des INDI-Web-Clients Was im Projekt INDI-Web-Client behandelt wird Nutzen / Zielpublikum Projektbeschreibung Konzept Use Case Diagramm des Interfaces Topologie Versuchsaufbau Benutzercharakteristiken Abhängigkeiten Eingesetzte Technologien und Applikationen Funktionsschema Übersicht MVC Konzept mit Spring Einführung in die MVC-Technologie Begriffserklärung Erklärung der Technologie Vor- und Nachteile Das Spring Web im Detail Funktionsweise Das Dispatcher Servlet Controller-Komponenten Model-Komponenten View-Komponenten Ein Tutorial zur Problemstellung im Projekt INDI-Web-Client Problemstellung Lösungsansatz Beispiel

3 Inhaltsverzeichnis 4. Ajax Einführung in Ajax Definition Vergleich mit üblichen Web-Technologien Aktualisierung durch Polling Vor- und Nachteile von Ajax Browser-Kompatibilität Ajax in unserem Projekt - Client-Seite Die Ajax-Kommunikationszentrale Der Requestgenerator für das Polling Die weitere Verarbeitung der erworbenen Daten Events bei Link- / Buttonklicks Ajax in unserem Projekt - Server-Seite Der Ajax-Manager XML Templates Der Versionsmanager XML-Anweisungen für den INDI-Server (Send Event) Acegi Security Sicherheitskonzept INDI-WebClient Acegi Security Grundlagen Konfiguration INDI-WebClient Acegi Security Integration in JSP Admin-Bereich DIMM-Schnittstelle Zweck der Schnittstelle BLOB-Übertragungsmechanismus Flexible Image Transport System Implementation für die Verarbeitung von FITS-Daten Ziele Anpassung der BLOB-Visualisierung Implementation XML-Abstraktion und XML-Verarbeitung Das INDI-XML-Protokoll INDI Properties Attribute der Properties und Elemente Spezielle Attribute Definitionen der Properties (Server to Client) Update der Properties (Server to Client) Update der Properties (Client to Server) Spezielle Befehle Abstraktionsprinzip

4 Inhaltsverzeichnis 7.3. Strukturierung der XML-Abstraktion Der XML Parser Schnittstellen für MVC Services Das Web Interface - Design, Aufbau und Bedienung Design Benutzerbedienbarkeit Aufbau der Webseite Elemente der Webseite Sichere Verbindung mit SSL Einleitung SSL-Verschlüsselungübersicht Zertifikate OPEN SSL X SSL CA-Zertifikate SSL Server Zertifikate SSL Client Zertifikate Vorbereitung Installation unter Kubuntu Dapper für Apache und Tomcat Sources List des Paketmanagers APT anpassen Installation und Konfiguration von Apache Vorausssetzungen für Tomcat-Installation Installation Tomcat Konfiguration Apache Tomcat Verbund SSL mit Tomcat SSL mit Apache SSL mit Apache mit Client-Zertifikat Apache Tomcat Verbund mit mod_jk Connector Schlussbemerkung Clustering Loadbalancing Einleitung Loadbalancing Loadbalancing mit Tomcat Konfiguration Loadbalancing mit Tomcat Schlussbemerkung A. Definition und Begriffe 112 B. Literaturverzeichnis 114 C. Eidesstattliche Erklärung 119 4

5 Kapitel 1. Einleitung 1.1. Zweck des Dokuments Dieses Dokument erläutert den Aufbau und die Funktionen der Applikation «INDI- Web-Client». Dabei werden die bei der Entwicklung verwendeten Technologien vorgestellt und es wird gezeigt, wie diese in der Applikation Verwendung finden. Ausserdem wird beschrieben, wie sich das Web-Interface bedienen lässt und wie die Web-Applikation mit dem entfernten INDI-Server kommuniziert. Das Dokument ist Bestandteil der Diplomarbeit von Patrik Sütterlin und Christoph Reimann an der Kantonalen Technikerinnen- und Techniker-Schule Muttenz (KTSI) Geltungsbereich Übersicht Zur Fernsteuerung des Observatoriums in Vermes wird über einen INDI Server auf die verschiedenen astronomischen Gerätschaften zugegriffen. Die Aufgabe beinhaltet das Erstellen eines plattformunabhängigen INDI-Web-Clients, der ausschliesslich mit Open-Source Web-Technologien implementiert werden soll. Der Web-Client kann eine Verbindung zu einem lokalen oder dezentralen INDI-Server aufbauen. Der Benutzer kann den Verbindungsvorgang vom Web-Client aus konfigurieren und steuern. Der Web-Client soll vom «Look and Feel»-Aspekt her wie eine gewöhnliche Desktop- Applikation auf einem grafischen Betriebssystem wirken. 5

6 Kapitel 1. Einleitung Zweck des INDI-Web-Clients Die Programme «KStars» und «Cartes du Ciel» können mit Hilfe der INDI-Hardware- Schnittstelle astronomische Geräte fernsteuren. Die mit INDI-Treibern angebundenen Geräte lassen sich direkt von diesen Programmen aus bedienen. Die Eigenschaften der einzelnen Geräte werden dabei grafisch in einem speziellen GUI dargestellt. Man ist jedoch immer an das Vorhandensein einer solchen INDI-kompatiblen Software auf dem jeweiligen Computer angewiesen. Für Windows und Apple Computer gibt es keine solch umfassenden Applikationen. Mit einem Web-Client möchten wir nun dieses Problem aus der Welt schaffen. Die grafische «KStars»-Oberfläche soll in einem Browser, möglichst mit gleicher Funktionalität, abgebildet werden. Mit dem INDI-Web-Client wird auch eine Bündelung der Client-Zugriffe erreicht. Dies reduziert den Netzwerkverkehr auf dem INDI Server-Host Was im Projekt INDI-Web-Client behandelt wird Es werden folgende Punkte umgesetzt: Mehreren Benutzern wird ermöglicht, weltweit INDI-Geräte über einen Web Browser zu überwachen und zu steuern. Der Zugriff auf den INDI-Web-Client wird mit einem Zugriffspasswort geschützt. Es wird angestrebt, eine möglichst «KStars»-ähnliche GUI-Struktur zu erstellen. Dabei muss nicht strikt das Design übernommen werden. Wichtiger ist eher, dass sämtliche Funktionen der INDI-Library abgebildet werden können. Werte in Textfeldern und grafische Anzeigen müssen dynamisch zur Laufzeit auf dem Web-Client aktualisiert werden, ohne dass der Browser ein «Refresh» durchführen muss. Fehlerhafte Eingaben bei den numerischen Eingabefeldern werden erkannt und gemeldet. Web-Design und Web-Logik sollen voneinander getrennt werden. Dies wird mit einem MVC-Konzept realisiert. Es soll eine Dokumentation zur Arbeit verfasst werden. Weiterverarbeitung von komplexen, übermittelten binären Datensätzen, den so genannten «BLOB» (Binary Large OBjects). z.bsp. Webcam Bilder. 6

7 Kapitel 1. Einleitung Nutzen / Zielpublikum Mit dem INDI-Web-Client kann man, unabhängig von spezieller Software und dem Betriebssystem, auf ein einfaches Web Interface zugreifen. Auf der Clientseite kann so der Zugangskomfort um einiges verbessert werden. Jeder internetfähige PC mit Javascriptfähigem Browser kann für den Zugriff auf die Umgebung benutzt werden. Zudem ist es möglich, den Standort für den Webserver frei zu wählen, er muss sich also nicht zwingend im gleichen Netzwerk wie der INDI Server befinden. Das hat den Vorteil, dass bei einem dezentralen Webserver nicht noch zusätzlicher Traffic (HTTP- Requests und Responses) das Netz im Observatorium belastet. Der Webserver bündelt dabei mehrere Web-Benutzer zu einem einzigen INDI-Benutzer. Die Software ist für sämtliche Benutzer des INDI-Protokolls, sowie auch für Aussenstehende (Beobachter) interessant. 7

8 Kapitel 2. Projektbeschreibung 2.1. Konzept Die INDI-Web-Client Umgebung besteht aus folgenden Teilkomponenten: Web-Interface (Web Browser, HTML, JSP, Javascript) Request Verarbeitungsschicht (Spring MVC und Ajax) XML-Abstraktion der INDI-Server Daten (XML Java-Klassen) Socket Connection zum INDI-Server (Java-Applikation) INDI-Server / INDI-Drivers Ajax - Engine Displays Updates / Events View Ajax Manager Controller Model (Daten-Puffer) Webbrowser INDI - Server Out In Devices Socket Connection Socket Connection INDI Server / Drivers INDI WebClient Abbildung 2.1.: Grundkonzept des INDI-Web-Clients Die Grafik zeigt die groben Zusammenhänge zwischen den einzelnen Teilkomponenten. Jede Komponente erledigt bestimmte Teilaufgaben. Die Grafik wird hier nun erläutert: 8

9 Kapitel 2. Projektbeschreibung Ein Benutzer bedient die INDI-Umgebung an seinem Browser über ein Web Interface. Das Interface zeigt periodisch alle Veränderungen, die vom INDI-Server gemeldet werden, an. Die Web-Interface-Komponenten werden mit Hilfe von Java Server Pages erzeugt. Die Anbindung zu den aktuellen Daten in der XML-Abstraktion wird mit Spring MVC und Java Server Beans realisiert. Nach dem Zusammenfügen der Daten mit der JSP-Vorlage werden die fertigen HTML-Teile an den Browser übermittelt. Da HTTP ein zustandsloses Protokoll ist, wird eine HTML Page nach dem Laden, nicht mehr automatisch aktualisiert. Die Seite bleibt somit solange unverändert, bis sie erneut angefordert wird (Refresh). Bei einem Refresh werden sämtliche Inhalte einer Seite ersetzt. Werte in Eingabefeldern werden dabei ohne spezielle Gegenmassnahmen gelöscht. Es kann auch vorkommen, dass Bereiche, die nachgeladen werden, jeweils kurz aufflackern. Um ein GUI «Look and Feel» erzeugen zu können, muss pro Sekunde mindestens ein Refresh durchgeführt werden. Die obigen Effekte sind daher unerwünscht. Um das Problem lösen zu können, wird mit Ajax (Asynchronous Javascript and XML) gezielt Content auf einer geladenen Seite ausgetauscht. Es können komplette HTML- Bereiche, Bilder oder Texte ausgetauscht oder verändert werden. Obige Effekte treten dabei nicht auf, da das Nachladen mit Javascript im Hintergrund erledigt wird. Klickt der Benutzer auf seinem Interface einen Button an, so wird ein Event ausgelöst. Dieser Event stösst einen Request an, der entweder Inhalte auf dem Interface verändert, oder eine Wertänderung an den INDI-Server zurück übermittelt. Die Werte und Eigenschaften sowie die Struktur des GUIs werden in einer XML-artigen Kommunikationsform zwischen einem INDI-Server und seinen INDI-Clients ausgetauscht. Der INDI-Web-Client muss diese Informationen ständig in einer XML-Abstraktion aktualisieren, damit eine reibungslose Darstellung gelingen kann. Die XML-Abstraktion wird beim ersten Verbindungsaufbau «aufgebaut» und spiegelt in erster Linie die komplette GUI-Struktur in Klassen wieder. In mehreren Objekten werden die aktuellen Eigenschaftsdaten wie Texte oder numerische Werte hinterlegt. Wenn der INDI-Server ein Update der Daten verlangt, so werden diese in der XML-Abstraktion sofort nachgeführt. Benutzer-Events werden nicht direkt in die XML-Abstraktionsdaten überführt, sondern es wird gewartet bis der INDI-Server die Anfrage bestätigt und somit die aktuellen Daten zurückmeldet. Die Socket Connection, stellt eine auf TCP/IP basierende Verbindung zum INDI-Server her. Die Verbindung kann problemlos über das Internet oder durch einen verschlüsselten Tunnel geführt werden. 9

10 >? -, + " Kapitel 2. Projektbeschreibung Auch die Verbindung zwischen dem Browser des Benutzers und dem Web-Client (Tomcat Server) kann mit SSL verschlüsselt werden. Da die Verbindung auf dem HTTP- Protokoll beruht, ist sie natürlich auch Internet-tauglich Use Case Diagramm des A BC!= D EF G< # G.'17/ /$ &'($# 6 0.' 8 H : # ;$ &('$ # ) < =.0/ 1%2 435$ #%$ &'($ ## ) *.I/ 42 J3 : K/ H=9! ' #A7 Ë EML 2.' <' A7 Ë E; ( 6? Abbildung 2.2.: Use Case Diagramm des INDI-Web-Clients 1 Der Zugang zum INDI-Web-Client ist passwortgeschützt. Der Passwortschutz soll nur berechtigten Benutzern Zugang zum System gewähren. Der Passwortschutz basiert auf Acegi Security Technologie. 2 Über ein Formular kann man zum INDI-Server eine Verbindung herstellen. Das Formular benötigt zwei Parameter. Computer (IP oder URL) und Port müssen eingetragen werden. Drückt man nun «connect» wird die Verbindung zum INDI- Server aufgebaut und die Gerätenavigation geladen. 3 Dem Benutzer wird ermöglicht die Echtzeitwerte eines INDI-Gerätes abzulesen. Der INDI-Server liefert permanent Werte, welche auf der Webseite ständig aktualisiert dargestellt werden. Beim Anfordern eines Bildes wird dieses auf dem Tomcat Webserver aufbereitet und hinterlegt. Danach kann es bei Bedarf im Browser angezeigt werden. 4 Dem Benutzer wird ermöglicht Werte eines INDI-Gerätes zu setzen. Das setzen erfolgt über Textfelder wo der Benutzer seine Werte eintragen und abspeichern kann. 10

11 Kapitel 2. Projektbeschreibung 5 Der Benutzer kann zwischen verschiedenen Geräten hin und her schalten. Einmal verbunden können mehrere Geräte angesteuert werden. 6 Die Eigenschaften sind in Gruppen geordnet. Diese Gruppenzugehörigkeiten verhelfen zu mehr Übersicht und erleichtern das Navigieren. Gruppen werden standardmässig vom INDI-Framework unterstützt Topologie Die topologische Ansicht aus der Benutzerperspektive: Webclient Serververbund Hardware Firefox / IE / Safari Apache Tomcat Server INDI-Server (1..n) INDI- Treiber INDI- Treiber Gerät 1 Gerät (2..n) Abbildung 2.3.: Diagramm mögliche Topologie des INDI-Web-Client Zwischen der Hardware und dem Web-Client steht ein Server-Verbund. Dieser realisiert den Austausch der Informationen, die an die Hardware gesendet werden und die der Benutzer auf dem Web-GUI sieht. Der Server-Verbund kann aus einem oder mehreren unabhängigen Systemen bestehen. Er kann bei Bedarf so konzipiert werden, dass er für einen externen Benutzer transparent ist oder auch nicht. Die einzelnen Systeme können über das Internet per TCP/IP-Protokoll kommunizieren. Die Kanäle können dabei auch verschlüsselt werden. Die Hardware wird mit sogenannten INDI-Treibern in die INDI Server-Umgebung eingebunden. Die Verbindung ist dabei nicht netzwerkbasierend, sondern findet direkt über einen I/O-Kanal auf demselben System statt. Somit ist ein Gerät immer auf das Vorhandensein eines INDI-Servers angewiesen. INDI-Server sind in der Lage mit weiteren INDI-Servern zu kommunizieren und so die Kommunikation zu bündeln. 11

12 Kapitel 2. Projektbeschreibung 2.4. Versuchsaufbau Damit im späteren Einsatz der Web-Client auf verschiedenen Zielsystemen laufen kann, werden die Möglichkeiten untersucht, wie die unabhängigen Server miteinander über die verschiedenen Medien kommunizieren können. Der Versuchsaufbau für ein mögliches System könnte dann wie folgt aussehen: Server PC Tomcat Web- Server WWW User PC Browser (1..n) Server PC SSH Tunnel INDI Server Deamon Devices (1..n) Abbildung 2.4.: INDI-Server, Web Container Tomcat und Client auf separaten Rechnern Dabei sind etliche Variationen denkbar. So könnte man für den INDI Server und den Web-Container Tomcat einen einzigen Server betreiben. Oder falls diese doch unabhängig betrieben werden, könnte der Datenverkehr im SSH-Tunnel auch über das Internet geführt werden. Die HTTP-Kommunikation zwischen den Browsern und dem Web-Container Tomcat könnte bei Bedarf mit SSL verschlüsselt werden. Zum Entwickeln und Testen des INDI-Web-Client muss auf dem Computer des Programmierers eine spezielle Umgebung geschaffen werden, die ein komfortables und effizientes Entwickeln ermöglicht. Hier ein Beispiel für eine Windows-Umgebung: 12

13 Kapitel 2. Projektbeschreibung Developer PC Tomcat Web- Server Eclipse IDE Browser (1..n) Virtueller Server PC SSH Tunnel INDI Server Deamon Devices (1..n) Abbildung 2.5.: Developer-Umgebung mit INDI-Server auf einem virtuellen PC Wenn vollständig unter Linux entwickelt wird, können auch alle Komponenten auf einem einzigen System lokal betrieben werden. Um mit einem INDI-Server kommunizieren zu können, muss dieser über eine Socket- Verbindung angesprochen werden können. Im obigen Diagramm wird der INDI-Server auf einem virtuellen Computer betrieben. Der Tomcat Web Container befindet sich lokal auf dem selben System, wie die Entwicklungsumgebung Eclipse. Die Verbindung zwischen dem INDI-Server und Tomcat wird über einen SSH-Tunnel realisiert. Die jeweiligen verschiedenen Anordnungen, haben Auswirkungen auf die Adressierung der Dienste, sowie auf die Antwortzeit und Übermittlungsgeschwindigkeit Benutzercharakteristiken Beim INDI-Web-Client werden 3 Benutzergruppen unterschieden: Administratoren der Serverumgebung. Benutzer mit Erlaubnis zur Interaktion. Benutzer mit Zuschauer Status. 13

14 Kapitel 2. Projektbeschreibung Administratoren müssen über Kenntnisse verfügen, um Webservices auf einem Apache Tomcat Webserver konfigurieren zu können. Benutzer brauchen keine speziellen Kenntnisse von serverbezogenen Internettechnologien. Sie kennen eher die Gerätschaften, die über den INDI-Client ferngesteuert werden können. Grundsätzlich ist also völlig offen, was für ein genaues Profil ein Endbenutzer demnach haben wird Abhängigkeiten 1. Für den Betrieb des INDI-Web-Clients muss serverseitig ein Apache Tomcat Server zur Verfügung stehen. 2. Der verwendete Browser muss Javascript unterstützen und die Funktion muss aktiviert sein. Eine Kompatibilitätsliste befindet sich im Abschnitt Der INDI-Server ist bis anhin nur auf Linux-Systemen lauffähig. 4. Die Zugriffs- und Abhörsicherheit der Kommunikation zwischen den Diensten hängt von den getroffenen Massnahmen des Systemadministrators ab. Dabei wären folgende Mechanismen zu nennen: SSL, SSH und das User-/Zugriffsmanagement des Web Containers Tomcat. Der Web-Client hat bis anhin keine Benutzerverwaltung implementiert Eingesetzte Technologien und Applikationen Folgende Technologien und Applikationen werden im Projekt eingesetzt: Ajax (Asynchronous Javascript and XML) Apache Tomcat Server (WebContainer) Eclipse IDE (Entwicklungsumgebung) / Tomcat Plugin INDI (Instrument Neutral Distributed Interface) HTTP / HTML / CSS Java / Java Server Pages / Java Beans / Javascript JDOM (XML Framework) Spring (MVC) / Acegi Security Socket Connections / TCP/IP / SSH Unit Test / Log4J (Logging Tool) 14

15 Kapitel 2. Projektbeschreibung 2.8. Funktionsschema Webbrowser Client Layer User Interface INDIAjaxReplacePicture.js (Replace Picture) INDIAjaxSetLamp.js (Replace Lamp) INDIAjaxMessageBox.js (Add MessageLine) Navigation INDIAjaxReplaceText.js (Replace Text) Connect control Devicelist Update Objects INDIAjaxSetButtonState.js (Enable / Disable Buttons) INDIExecuteFuntionCall.js (Execute js Funtion) Tabbar / Tabarea ReplaceHTML Content INDIAjaxHTMLManager.js (ReplaceHTML / Initiate HTML Requests) INDIAjaxRefresh.js (Refresh Timer) GetAreaVersions/Category GenerateUpdate Request onclickevent INDIAjaxGeneralRequest.js (Ajax Request Manager) Requests and Responses (HTML) Response (XML) Assign HTML Request Call Methods INDIAjaxAllocator.js (Prescreening - Forwarding) Internet / Local Area Network / SSL / SSH HTTP Requests (GET) HTTP Responses (HTML) HTTP Requests (POST) / HTTP Responses (XML) 1. lookup Handler Mapping Controller Dispatcher Servlet (Spring) 2. handle Request 6. Resolve View View Resolver View (jsp) 7. Send View to Client ClientMainServlet (Ajax) XMLWriter Forward Request Version Manager AjaxManager / PageElement Manager XMLTemplates 4. Create Model and View Object Model and View 5. Send back to Dispatcher Spring MVC / Acegi Security Services Object (String / List) Require current datarecord Send String or ArrayList Object Web Layer 3. Contact Service - get Datas Service Layer Ajax Layer Bean Factory / Spring dispatcher-servlet.xml applicationcontext.xml INDI Server Device 1 Driver 1 Device 2 Driver 2 Device 3 Driver 3 Device 4 Driver 4 Socket Connection TCP/IP (XML) Update Version Connect / Disconnect SendEvent Send XML Socket Connection Parse XML Abstraction (Buffer) Construct / Update XMLParser Application Layer web.xml Apache Tomcat Abbildung 2.6.: Das Funktionsschema des INDI-Web-Clients 15

16 Kapitel 2. Projektbeschreibung 2.9. Übersicht In den nächsten Kapiteln wollen wir die diversen Aspekte dieser Arbeit im Detail beleuchten. Der erste Teil beschäftigt sich vor allem mit den technologischen Aspekten: MVC-Konzept mit Spring. Ajax (Asynchronous Javascript and XML). XML-Abstraktion und XML-Verarbeitung. Benutzerauthentifikation mit Acegi Security. Der zweite Teil beschäftigt sich mit der Benutzung der fertigen Applikation: User Interface Design und Bedienungsanleitung. Der dritte Teil beschäftigt sich mit dem Aufbau einer sicheren SSL Verbindung und der Serverumgebung: Erstellen einer SSL verschlüsselte Verbindung. Benutzerauthentifikation mit SSL Zertifikaten. Koppeln von Apache und Tomcat mit dem Modul mod_jk. 16

17 Kapitel 3. MVC Konzept mit Spring 3.1. Einführung in die MVC-Technologie Begriffserklärung BEGRIFF Model View Controller ERKLÄRUNG Speichert die Daten Stellt die Daten dar Verwaltet und steuert die Schichten Tabelle 3.1.: MVC Begriffe in der Übersicht Erklärung der Technologie MVC wurde 1978 von Professor Trygve Reenskaug vom Xerox PARC entwickelt. Das ModelViewControlling-Konzept trennt die Anwendungskomponenten in drei selbstständig aufgeteilte Schichten, man spricht auch von einer Multitier-Umgebung. Die Model-Schicht wird für die interne Datenspeicherung verwendet. Es enthält die Daten, die durch die View-Schicht dargestellt werden sollen. Das Model bietet Methoden an, um die Daten von aussen abzufragen. Typische Datenspeicher sind Datenbanken oder XML-Dateien. Die View-Schicht stellt eine oder mehrere Aspekte des Models dar. Das View verwendet die Methoden des Models um die Daten anzuzeigen. Views sind meistens GUI- Elemente oder Web-Oberflächen mit denen der Benutzer agieren kann. Der Controller kann die Schichten verwalten, er nimmt Aktionen vom Benutzer entgegen und wertet sie aus. Der Controller hat einen schreibenden Zugriff auf das Model. 17

18 Kapitel 3. MVC Konzept mit Spring Vor- und Nachteile Warum man das MVC-Konzept einsetzen sollte: Wartbarkeit wird erhöht. Grosse Übersicht. Austauschbarkeit der Komponenten. Projekt wird strukturierter und flexibler. Änderungen werden vereinfacht, da sie gemappt werden. Was spricht dagegen: Lohnt sich nur für grosse Projekte (Einrichtung eines MVC-Frameworks bedeutet grossen Aufwand und Know-How). Es widerspricht dem Prinzip «From The Many To The Few»: Eine View muss Attribute oder gar Datenfelder von Model-Objekten anfordern, um sie in die Widgets stecken zu können. Desshalb muss die View wissen, aus welchen Daten sich ein Model zusammensetzt. 18

19 Kapitel 3. MVC Konzept mit Spring 3.2. Das Spring Web im Detail Funktionsweise Das im vorhergehenden Kapitel vorgestellte MVC-Konzept wurde im INDI-Web-Client mit Hilfe des Spring Frameworks umgesetzt. Das Spring Framework wurde von Rod Johnson ins Leben gerufen und erfreut sich heutzutage grosser Beliebtheit. Spring ist ein mehrschichtiges J2EE-Applicationframework. Das Ziel der Spring-Entwicklung ist hauptsächlich J2EE-Applikationen einfacher zu machen. Aufgelistet einige Merkmale: Leichtgewichtiger Container zur Verwaltung von POJO-basierten Anwendungskomponenten. Einfaches MVC Framework. Integration von Persistenzmechanismen, z.b. Hibernate, JDO. Realisation des IoC (Inversion of Control)-Prinzips. In den nächsten Abschnitten werden nun die einzelnen Komponenten vorgestellt Das Dispatcher Servlet Im «dispatcher-servlet.xml» werden Requests entgegengenommen. Da das «dispatcherservlet.xml» ein Servlet ist, muss es auch im web.xml registriert und deklariert werden. Im untenstehenden Codefragment sehen wir, dass es beim Start der Applikation geladen wird. 1 <servlet> Listing 3.1: «web.xml» im Verzeichnis «WEB-INF/» 2 <servlet-name>dispatcher</servlet-name> 3 <servlet-class >org.springframework.web.servlet.dispatcherservlet</servlet -class > 4 <load-on-startup>1</load-on-startup> 5 </servlet> Ein Dispatcher Servlet enthält Beans. Diese haben Eigenschaften wie Controller, URL Mappings und View Resolver. Schauen wir uns dieses Servlet anhand eines Beispiels genauer an. Im untenstehenden Beispiel wird zuerst ein Bean deklariert. Das Bean hat den Namen MainController und hinter diesem Bean steht die Klasse «ch.ktsi.indiclient.controller.maincontroller». In Zeile 4-10 sehen wir die Deklaration eines Controllers, die besagt, dass wenn die 19

20 Kapitel 3. MVC Konzept mit Spring Seite «index.html» aufgerufen wird, eine Weiterleitung an den Controller MainController erfolgt. In der Zeile wird noch ein View Resolver deklariert. In unserem Fall ruft der Resolver bei einem «index.html»-aufruf das Servlet «index.jsp» auf. 1 Listing 3.2: «dispatcher-servlet.xml» im Verzeichnis «WEB-INF/» 2 <bean id="maincontroller" class="ch.ktsi.indiclient.controller. MainController"/> 3 4 <bean id="urlmappingindex" class="org.springframework.web.servlet.handler.simpleurlhandlermapping"> 5 <property name="mappings"> 6 <props> 7 <prop key="/index.html">maincontroller</prop> 8 </props> 9 </property> 10 </bean> <bean id="viewindexresolver" class="org.springframework.web.servlet.view. InternalResourceViewResolver"> 13 <property name="viewclass"><value>org.springframework.web.servlet. view.jstlview</value></property> 14 <property name="prefix"><value>/</value></property> 15 <property name="suffix"><value>.jsp</value></property> 16 </bean> Controller-Komponenten Ein Controller implementiert das Interface «org.springframework.web.servlet.mvc.controller». Die Methode «handlerequest()» muss zwingend implementiert werden. Die handlerequest()-methode hat als Rückgabewert ein «ModelAndView» Objekt. Schauen wir uns mal die wichtigsten Konstruktoren an: KONSTRUKTOREN DER KLASSE MODELANDVIEW ModelAndView() ModelAndView(String viewname) ModelAndView(String viewname, String modelname, Object modelobject) Da der Controller die Anfrage nur an den richtigen View weiterleiten soll, nehmen wir also den Konstruktor mit einem Parameter und geben den View an. Beachten Sie 20

21 Kapitel 3. MVC Konzept mit Spring 2 die Zeile 16 im untenstehenden Quelltext. Nachdem der Controller den Request also entgegengenommen hat, wird er auf die Seite «start.jsp» weitergeleitet. 3 import java.io.ioexception; 4 Listing 3.3: «MainController.java» ist der Controller 5 import javax.servlet.servletexception; 6 import javax.servlet.http.httpservletrequest; 7 import javax.servlet.http.httpservletresponse; 8 9 import org.springframework.web.servlet.modelandview; 10 import org.springframework.web.servlet.mvc.controller; public class MainController implements Controller { 13 public ModelAndView handlerequest(httpservletrequest request, HttpServletResponse response) 14 throws ServletException, IOException { return new ModelAndView("start"); 17 } } Model-Komponenten Das Model speichert die Daten und bietet Methoden an, um die Daten von aussen abzufragen. Schauen wir uns an, wie das in diesem Projekt realisiert wurde: Die INDI- Web-Client-Daten werden von einem Server im XML-Format übermittelt. Dieses XML haben wir in Java-Klassen mit Getter- und Setter-Methoden abgebildet. Diese Klassen wurden wiederum gekapselt und in Collections abgelegt. Die Klasse, die diese Collections verwaltet, heisst «ch.ktsi.indiclient.xmlabstraction.xmlabstraction.java». Listing 3.4: Die Daten werden im Model gekapselt 7 package ch.ktsi.indiclient.xmlabstraction; 8 9 import java.util.arraylist; 10 import java.util.collections; 11 import java.util.iterator; 12 import java.util.list; import ch.ktsi.indiclient.components.property; public class XMLAbstraction { private List aproperties = Collections.synchronizedList(new ArrayList()); 19 private List amessages = Collections.synchronizedList(new ArrayList()); // Privater Konstruktor 22 private XMLAbstraction() { ; } 21

22 Kapitel 3. MVC Konzept mit Spring // einzige Instanz dieser Klasse 25 private s t a t i c XMLAbstraction uniqueinstance = null ; // Zugriffsmethode 28 public s t a t i c XMLAbstraction getuniqueinstance() { 29 i f (uniqueinstance == null){ 30 uniqueinstance = new XMLAbstraction() ; 31 } 32 return uniqueinstance ; 33 } Schauen wir uns mal die speziellen Eigenschaften dieser Klasse an: Zeile 25 Die Abstraktion ist in einer Singelton-Klasse gekapselt. Eine Singelton-Klasse ist eine Klasse von der nur eine Instanz existiert. Die private Member-Variable der Instanz wird üniqueinstance» genannt. Zeile 28 Eine andere Klasse will auf die Daten der Klasse zugreifen. Dazu muss sie erst die Methode «getuniqueinstance()» aufrufen. Beim aller ersten Aufruf wird die Instanz automatisch in dieser Methode angelegt. Listing 3.5: «XMLAbstraction.java» enthält die Liste mit den Daten 153 // Erstellt eine Liste aller Properties einer Geraetegruppe. 154 public synchronized List getpropertylist(string devicename, String groupname){ List devices = new ArrayList(); 157 Iterator i = this.aproperties.iterator(); // Alle Properties durchgehen. 160 while (i.hasnext()){ Property p = (Property)i.next(); // Pruefen auf den Geraetenamen und Gruppe 165 i f (p.getpdevice().equals(devicename) && p.getpgroup().equals(groupname )){ devices.add(p); 168 } 169 } return devices; 172 } Um nun auf die Daten zuzugreifen, stellt uns das Model Methoden zur Verfügung. Schauen wir uns das an einem Beispiel an: Zeile 154 «getpropertylist(string devicename, String groupname)» liefert uns eine Liste aller Properties einer Gerätegruppe. 22

23 Kapitel 3. MVC Konzept mit Spring View-Komponenten Der View stellt die Daten zur Schau, er ist für die Darstellung auf der Webseite oder auf einer GUI-Oberfläche zuständig. In unserem Projekt müssen die Daten auf einer Webseite dargestellt werden. Es existieren verschiedene Techniken, für komplexe Elemente könnten wir z.b. JSF einsetzen. JSF ist aber eher auf statische Elemente ausgerichtet und wir haben uns also für JSTL Java Server Pages Standard Tag Library entschieden. Während die Ausdrucksmöglichkeiten für Präsentationslogik bei den Java Server Pages in Reinform im Wesentlichen auf in die Seiten eingebauten Java Code basieren, führt die Java Server Pages Standard Tag Library eine Vielzahl ausdrucksstarker Tag Typen ein, die in den Java Server Pages verwendet werden können. [3] JSTL stellt uns also Tags zur Verfügung, damit wir die Daten sauber ausgeben können ohne in den JSP-Seiten Java Code zu verwenden. c:out (Ausgabe) c:foreach (Schleife) Als erstes müssen wir aber die JSTL-Bibliotheken in unser Projekt einbinden. Das geschieht mit folgenden Zeilen: Listing 3.6: «indinumber.jsp» JSTL Deklarationen 2 taglib prefix="c" uri="http://java.sun.com/jstl/core" %> 3 taglib prefix="fmt" uri="http://java.sun.com/jstl/fmt" %> Schauen wir uns nun eine typische Ausgabe an: Auf Zeile 23 sehen wir folgendes Codefragment c:out value={elements.property.pname}. Dank Spring, das die Klassen in Beans verwaltet, können wir auf die Klassen und Methoden zugreiffen. <c:out value={elements.property.pname}/> 22 <input Listing 3.7: «indinumber.jsp» Daten werden ausgegeben 23 id="number_<c:out value="${elements.property.pname}"/>_<c:out value="${ number.ename}"/>" 24 type="text" 25 class="readonly" 26 value="<c:out value="${number.nvalue}"/>" 27 title="minimum: <c:out value="${number.nmin}"/> / Maximum: <c:out value=" ${number.nmax}"/>" 28 readonly 29 /> 23

24 Kapitel 3. MVC Konzept mit Spring 3.3. Ein Tutorial zur Problemstellung im Projekt INDI-Web-Client Problemstellung Der INDI-Server sendet dauernd Daten über eine Socket-Verbindung an unsere Applikation. Die Daten werden in einer Abstraktionsklasse dynamisch abgebildet. Das Problem war nun, mit Beans auf diese Daten zugreifen zu können. Beans werden üblicherweise vom Container verwaltet oder in diesem Fall vom Spring Framework. Damit jeder Benutzer die gleichen Daten zu sehen bekommt, muss eine Verbindung zwischen den beiden Komponenten geschaffen werden Lösungsansatz Damit jeder Benutzer auf die gleichen Daten zugreift ist die Abstraktionsklasse als Singleton implementiert worden. Mit Service Beans kann auf dieses Singleton-Objekt von überall aus zugegriffen werden. Die Daten, die vom INDI-Server kommen werden ebenfalls dort eingefüllt. Ein Controller kann nun einen solchen Service nutzen, um z.b. eine Liste mit String-Objekten aus der Abstraktion zu holen. Die Daten werden dann von dem Controller in einem ModelAndView-Objekt an das Dispatcher Servlet übergeben Beispiel Schauen wir mal anhand dieses Beispiels, wie das Ganze abläuft. Step by Step sehen wir uns die Schritte an, von der Abstraktionsklasse bis zur View, wo die Daten angezeigt werden (hello.jsp). Zur Übersicht vorweg noch ein UML-Klassendiagramm: Abbildung 3.1.: UML-Diagramm des Tutorials 24

25 Kapitel 3. MVC Konzept mit Spring Die Abstraktionsklasse wurde als Singleton (Einzelstück) implementiert. Die Singleton- Klasse findet Verwendung, wenn nur ein Objekt zu einer Klasse existieren darf und ein einfacher Zugriff auf dieses Objekt benötigt wird. wenn das einzige Objekt durch Unterklassenbildung spezialisiert werden soll. Anwendungsbeispiele sind: Ein zentrales Protokoll-Objekt, das Ausgaben in eine Datei schreibt. 1 package ch.ktsi.inditutorial; 2 Listing 3.8: Die Singleton-Klasse 3 import java.util.arraylist; 4 /** 5 * 6 creimann 7 * 8 * Diese Klasse simuliert die XML Abstractionsklasse des INDIClients. 9 * Die Klasse liefert eine Liste mit Strings an den Service zurueck. 10 * 11 */ 12 public class TutorialAbstraction { // Array List mit Stirngs die spaeter auf der Webseite 15 // angezeigt werden sollen. 16 private ArrayList<String> li = null; // Einzige Instanz der Klasse 19 private s t a t i c TutorialAbstraction uniqueinstance = null; // Konstruktor 22 private TutorialAbstraction() { li = new ArrayList<String>(); 25 fillthelist(); 26 } // Einzige Instanz erstellen oder einfach holen 29 public s t a t i c TutorialAbstraction getuniqueinstance() { i f (uniqueinstance == null) { 32 uniqueinstance = new TutorialAbstraction(); } 35 return uniqueinstance; 36 } // Liste ausliefern 39 public ArrayList gettutoriallist() { 40 25

26 Kapitel 3. MVC Konzept mit Spring 41 return li; 42 } // Testwerte (erscheinen auf der Webpage) 45 public void fillthelist() { li.add(new String("Java")); 48 li.add(new String("C++")); 49 li.add(new String("PHP")); 50 } 51 } Zeile 16 Simuliert einen Datensatz (ArrayList), der in der GUI-Abstraktion bereit liegt und bei Bedarf vom Services über eine Methode abgefragt wird. Zeile 22 Der Konstruktor ist private, diese Klasse kann somit nicht von ausserhalb instanziert werden. Zeile 29 «getuniqueinstance()» erstellt und liefert die einzige Instanz der Klasse, sie muss static sein. Schauen wir uns nun die Service-Klassen an. Die Funktion der Service-Klassen beschränken sich einzig darauf, die Daten, in unserem Fall eine Liste, zu liefern. Die Implementation des Interfaces «TutorialService» besitzt eine Instanz der Klasse «TutorialList» welche auf die Tutorial Abstraktions-Klasse zugreift. Service-Klassen sollten sich wenn immer möglich auf eine einzige bestimmte Aufgabe beschränken. So erhält ein Service-Benutzer keine für ihn unnötigen Daten. 1 package ch.ktsi.inditutorial; 2 3 import java.util.list; 4 Listing 3.9: Das Klasse «TutorialServiceImpl.java» 5 /** 6 * 7 creimann 8 * 9 * Implementation des Interfaces Tutorial Service 10 * Besitzt eine Instanz der Klasse TutorialList welche auf 11 * die Tutorial Abstraktions-Klasse zugreifft. 12 * 13 */ public class TutorialServiceImpl implements TutorialService { private TutorialList tl; TutorialServiceImpl() { 20 this.tl = new TutorialList(); 21 } 22 26

27 Kapitel 3. MVC Konzept mit Spring 23 public List getlist() { 24 return this.tl.getlist(); 25 } 26 } Die «TutorialList»-Klasse holt Daten aus der Tutorial Abstraktions-Klasse. Zeile 17, die Methode «getlist()», liefert die Liste. 1 package ch.ktsi.inditutorial; 2 import java.util.list; 3 Listing 3.10: Die Klasse «TutorialList.java» 4 /** 5 * 6 creimann 7 * 8 * Die TutorialList Klasse holt Daten aus der Tutorial 9 * Abstraktions Klasse 10 * 11 */ 12 public class TutorialList { // Hier wird die Liste aus der TutorialAbstraktion geholt. 15 public List getlist(){ List li = TutorialAbstraction.getUniqueInstance().getTutorialList(); return li; 20 } } Schauen wir uns das Herzstück des INDI-Tutorials an. Die ganzen Verbindungen und Konfigurationen werden in XML-Files verwaltet. Beim Start eines Tomcat-Projektes wird die Datei «web.xml» geladen.die Datei «web.xml» im Verzeichnis «/WEB-INF» enthält die Konfigurationselemente (Deployment Description) des Projektes. Listing 3.11: «/WEB-INF/web.xml» 1 <?xml version="1.0" encoding="utf-8"?> 2 <!DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN > 3 4 <web-app> 5 6 <listener> 7 <listener-class> 8 org.springframework.web.context.contextloaderlistener 9 </listener-class> 10 </listener> <servlet> 13 <servlet-name>springapp</servlet-name> 27

28 Kapitel 3. MVC Konzept mit Spring 14 <servlet-class>org.springframework.web.servlet.dispatcherservlet</servlet -class> 15 <load-on-startup>1</load-on-startup> 16 </servlet> <servlet-mapping> 19 <servlet-name>springapp</servlet-name> 20 <url-pattern>*.htm</url-pattern> 21 </servlet-mapping> </web-app> Zeile 8 Die Komponenten einer lokalen Middle Tier in einer Webapplikation werden in einem oder mehreren XML-Bean-Definitions-Files konfiguriert und mittels Springs ContextLoaderListener (oder ContextLoaderServlet) geladen. Wenn kein spezieller Parameter angegeben ist, wird das File «/WEB-INF/applicationContext.xml» geladen. [4] Zeile 14 An dieser Stelle wird das Dispatcher Servlet geladen. In diesem Tutorial heisst es «springapp-servlet.xml». Zeile 20 URL Pattern, unter dem die Applikation aufrufbar sein soll. Das zweite Konfigurationsfile ist das application-context.xml. Wir definieren ein Bean «tutorialservice», das auf die Klasse «ch.ktsi.inditutorial.tutorialserviceimpl» zeigt. Spring verwaltet diese Klasse nun in der BeanFactory. Spring kennt «TutorialServiceImpl» nun und seine Service-Eigenschaften können im ganzen Spring-Projekt in Anspruch genommen werden werden. Dazu muss es bloss in ein Controller Bean eingebunden (referenziert) werden. Listing 3.12: «/WEB-INF/application-context.xml» 1 <?xml version="1.0" encoding="utf-8"?> 2 <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework. org/dtd/spring-beans.dtd"> 3 4 <beans> 5 6 <!--********************* TutorialService ************************--> 7 <bean id="tutorialservice" class="ch.ktsi.inditutorial.tutorialserviceimpl" /> 8 9 </beans> Zeile 7 Deklaration des Beans «tutorialservice». Das Dispatcher Servlet wird im Kapitel Spring Web im Detail ausführlich beschrieben. Daher schauen wir nur die für dieses Tutorial relevanten Stellen an. 28

29 Kapitel 3. MVC Konzept mit Spring Listing 3.13: «/WEB-INF/springapp-servlet.xml» 1 <?xml version="1.0" encoding="utf-8"?> 2 <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework. org/dtd/spring-beans.dtd"> 3 <beans> 4 <bean id="springappcontroller" class="ch.ktsi.inditutorial. SpringappController"> 5 <property name="tutorialservicemethod"> <!-- Setter Methode in der Klasse SpringappController --> 6 <ref bean="tutorialservice" /> <!-- Bean deklariert applicationcontext.xml --> 7 </property> 8 </bean> 9 10 <bean id="urlmapping" class="org.springframework.web.servlet.handler. SimpleUrlHandlerMapping"> 11 <property name="mappings"> 12 <props> 13 <prop key="/hello.htm">springappcontroller</prop> 14 </props> 15 </property> 16 </bean> <bean id="viewresolver" class="org.springframework.web.servlet.view. InternalResourceViewResolver"> 19 <property name="viewclass"><value>org.springframework.web.servlet. view.jstlview</value></property> 20 <property name="prefix"><value>/</value></property> 21 <property name="suffix"><value>.jsp</value></property> 22 </bean> 23 </beans> Zeile 4 Das «springappcontroller» Bean wird hier deklariert. Das Bean ist eine Instanz der Klasse «ch.ktsi.inditutorial.springappcontroller». Zeile 5-7 Hier wird dem «springappcontroller» ein fremdes Bean bekannt gemacht. Spring legt dazu eine Instanz des fremden Beans an und übergibt die Referenz dem «springappcontroller» Bean zur Verwaltung. Das «springappcontroller» Bean besitzt zu diesem Zweck eine Setter-Methode mit dem Namen «settutorialservicemethod()». Der Name der Methode muss mit dem Attribut «name» im Tag <property> bekannt gemacht werden, jedoch wird dabei, wie bei Beans üblich, der Präfix «set» weggelassen. Im Beispiel wird das Bean «tutorialservice» welches im application-context.xml definiert ist, auf diese Art beim «springappcontroller» Bean angemeldet. Zeile Hier wird ein «urlmapping» definiert. Mit der Deklaration auf Zeile 13 sagen wir, dass wenn jemand die Seite «/hello.htm» anfordert, die Anfrage an den Controller weitergeleitet werden soll, der dann die fortlaufenden Schritte unternimmt. 29

30 Kapitel 3. MVC Konzept mit Spring Zeile Der «ViewResolver» definiert das Verhalten, mit welcher Technik die View realisiert werden kann. In unserem Fall JSTL (auf Zeile 19 einsehbar). Kommen wir nun zum Controller, der den Request bearbeiten muss und die entsprechenden Daten weiterleitet. (Siehe Abschnitt 3.2.3) Zeile Dem Controller wird beim Abarbeiten des «springapp-servlet.xml»-files, wie vorher beschrieben, eine Referenz auf das Bean «tutorialservice» zugewiesen. Diese wird in der Methode «settutorialservicemethod()» entgegengenommen und in der privaten Variable «tutservice» dauerhaft gespeichert. Listing 3.14: «ch.ktsi.inditutorial.springappcontroller» 26 public class SpringappController implements Controller { private TutorialService tutservice; public void settutorialservicemethod(tutorialservice t) { 31 this.tutservice = t; 32 } public ModelAndView handlerequest(httpservletrequest request, 35 HttpServletResponse response) throws ServletException, IOException { Map model = new HashMap(); List tutoriallist = tutservice.getlist(); model.put("daten", tutoriallist); return new ModelAndView("hello", "model", model); 44 } } Zeile 39 Der Service wird nun beim Aufrufen des Controllers aufgefordert, die Liste zu liefern. Das Resultat wird in der Variable «tutoriallist» gespeichert. Zeile 41 Die Liste wird in eine HashMap mit dem Namen «model» verpackt. Sie kann mit dem String «daten» in der Map wieder gefunden werden. Zeile 43 Am Ende wird für das Dispatcher-Servlet eine ModelAndView-Klasse erstellt. Hier wird der Name der View (Parameter 1) dem ModelAndView Objekt bekannt gemacht. Das Dispatcher Servlet sorgt anschliessend dafür, dass die Daten (Parameter 3) innerhalb des Views als Bean ansprechbar sind (Parameter 2). Der gesamte Ablauf und die ModelAndView-Parameter werden in der folgenden Illustration dargestellt: 30

31 Kapitel 3. MVC Konzept mit Spring Service Daten Objekt Bezeichner HashMap Daten daten Evt. weitere Records hello.jsp ModelAndView hello model HashMap Dispatcher Servlet Parameter 1 View (.jsp) Parameter 2 Beanname Parameter 3 Hash Map Abbildung 3.2.: Diagramm der Vorgänge in der Controller-Klasse 1 page session="false"%> 2 Listing 3.15: «/hello.jsp» 3 taglib prefix="c" uri="http://java.sun.com/jstl/core" %> 4 taglib prefix="fmt" uri="http://java.sun.com/jstl/fmt" %> 5 6 <html> 7 <head><title>indimvctutorial</title> 8 <link rel="stylesheet" type="text/css" href="css/tut.css"/> 9 </head> 10 <body> 11 <center> 12 <br><br><br><br> 13 <h1>indimvctutorial</h1> 14 <br><br> 15 <b>dynamische Ausgabe der Liste aus der Klasse 16 ch.ktsi.inditutorial.tutorialmodell<b><p> <c:foreach items="${model.daten}" var="daten"> 19 <table> 20 <tr> 21 <td width="190" align="center"> 22 <c:out value="${daten}"/> <br><br> 23 </td> 24 </tr> 25 </table> 26 </c:foreach> 27 </center> 28 </body> 29 </html> Im «hello.jsp»-file kann man nun folgende Vorgänge erkennen: 31

32 Kapitel 3. MVC Konzept mit Spring Zeile Beim Verarbeiten des «hello.jsp»-files kann nun auf das Bean «model» zugegriffen werden. Da das Objekt eine Liste mit Strings ist, kann man mit einer «c:foreach»-schleife durch die Elemente iterieren. Damit die einzelnen Elemente innerhalb des for-statements ansprechbar sind, brauchen sie einen Namen. Dieser Name wird mit dem Attribut «var» im «c:foreach»-tag festgelegt. Auf Zeile 22 kann man erkennen, wie jeder einzelne String unter Verwendung dieses Namens mit einem «c:out»-tag auf die Seite ausgegeben wird. Und so sieht das Ganze dann im Browserfenster aus: Abbildung 3.3.: Browseransicht des Tutorials 32

33 Kapitel 4. Ajax 4.1. Einführung in Ajax Definition Ajax ist ein Akronym für die Wortfolge «Asynchronous Javascript and XML». Es bezeichnet ein Konzept der asynchronen Datenübertragung zwischen einem Server und dem Browser, welches es ermöglicht, dass die HTML-Seite nicht mit jeder HTTP-Anfrage komplett neu geladen werden muss. Das eigentliche Novum besteht in der Tatsache, dass nur gewisse Teile einer HTML-Seite oder auch reine Nutzdaten sukzessiv bei Bedarf nachgeladen werden. Bei Ajax werden verschiedene bekannte Technologien eingesetzt, um interaktive, desktopähnliche Webanwendungen zu realisieren. Diese vermitteln so den Eindruck, als ob das Problem der zustandslosen Webanwendung behoben wurde. [1] Eine Ajax-Anwendung basiert auf folgenden Web-Technologien: HTML. Document Object Model zur Repräsentation der Daten bzw. Inhalte. Javascript zur Manipulation des Document Object Models und zur dynamischen Darstellung der Inhalte. Javascript dient gleichzeitig als Schnittstelle zwischen einzelnen Komponenten. Das XMLHttpRequest-Objekt, Bestandteil vieler Browser, um Daten auf asynchroner Basis mit dem Webserver austauschen zu können. Der Begriff wurde in einer Arbeit von Jesse James Garrett erstmals erwähnt. Das Dokument hatte den Titel: «Ajax: A New Approach to Web Applications». Abrufbar unter: Grundsätzlich waren die technologischen Grundlagen und die Vorgehensweise aber bereits vorher bekannt und wurden generell mit dem Begriff XMLHttpRequest beschrieben. 33

34 Kapitel 4. Ajax Neueste Standardisierungsunterfangen des XMLHTTPRequest-Objekts seitens des W3C und die Gründung der Open-Ajax-Initiative lassen erkennen, dass die Industrie zukünftig die Ajax-Technologie in ihre Produkte integrieren und somit auf breiter Basis unterstützen wird. [1] Vergleich mit üblichen Web-Technologien Abbildung 4.1.: Vergleich Web-Anwendung mit und ohne Ajax 34

35 Kapitel 4. Ajax Traditionell übermitteln Webanwendungen Formulare, die zuvor vom Benutzer ausgefüllt wurden, an einen Webserver. Der Webserver antwortet, indem er dem Browser des Nutzers eine, entsprechend der zuvor übermittelten Formulardaten neu generierte, Webseite schickt. Aufgrund der Tatsache, dass der Webserver bei jeder Anfrage seitens des Nutzers eine neue Webseite erzeugen und übermitteln muss, erscheint die Anwendung dem Benutzer insgesamt als träge und wenig intuitiv, vergleicht man diese mit einer gewöhnlichen Desktop-Anwendung. Ajax-Anwendungen hingegen sind in der Lage, Anfragen an den Server zu schicken, bei denen nur die Daten angefordert werden, die tatsächlich benötigt werden. Für gewöhnlich geschieht dies über den Aufruf eines SOAP-Web-Services oder eines vergleichbaren XML-basierten Web-Service-Dialekts. Der Client, also der Web Browser, verarbeitet die Antwort des Servers nicht direkt, sondern schleust diese durch den Javascript-Prozess der Ajax-Engine. Im Ergebnis erhält man so eine Benutzeroberfläche, die sehr viel zügiger auf Benutzereingaben reagiert. Ein Grund für dieses veränderte Verhalten ist die Tatsache, dass wesentlich weniger Daten zwischen Web Browser und Webserver ausgetauscht werden müssen. Zudem wird die Webserverlast reduziert, da schon viele Verarbeitungsschritte clientseitig getätigt werden können. [1] Der Prozessfluss einer gewöhnlichen Web-Anwendung baut auf das zustandslose Request-Response-Verfahren auf. Dies hat mit dem Aufbau des zugrundeliegenden HTTP- Protokolls zu tun, das eigentlich nur zur einfachen Übertragung von Daten über ein Netzwerk ausgelegt worden ist. Nach dem Response vergisst der Server den anfragenden Client dann auch gleich wieder. Bei einem Übertragungsfehler muss der Client das Dokument nochmal anfordern. Um eine Wiedererkennung möglich zu machen, werden serverseitig oft Session-Objekte erzeugt, um einen Client immer wieder erkennen zu können. Dieser muss dann einfach bei jedem Request seine Session-ID-Kennung übermitteln. Die Auswertung der Parameter erfolgt üblicherweise über eine CGI-Schnittstelle des Web Servers oder Web Containers. Die Parameter werden bei einer GET Request direkt an die URL «angehängt». Damit die CGI-Schnittstelle die Parameter vom URL-String trennen kann, wird ein «?» als Trennzeichen eingesetzt. Mehrere Parameter werden mit dem Trennzeichen «&» voneinander getrennt. Hier ein Beispiel für einen URL-String beim GET-Request: Bei einem POST Request werden die Parameter im Rumpf der POST-Mitteilung als Zeichenkette mitgeschickt. Dies muss aber nicht mehr unbedingt in der oben gezeigten Notation erfolgen. Es wäre denkbar, auch XML als strukturierten Träger für die Daten einzusetzen. Ajax ist grundsätzlich auch an das HTTP-Protokoll gebunden, und funktioniert deshalb auch nach dem Request-Response-Prinzip. Jedoch wird dazu das XMLHttpRequest- Objekt mit Javascript angesteuert, welches dann die Ausführung des Requests steuert und die Antwortdaten als String in die Javascript-Umgebung zurück liefert. Der Benutzer bekommt von diesem Vorgang nichts mit, solange kein Fehler auftritt. 35

36 Kapitel 4. Ajax Aktualisierung durch Polling Die obige Erläuterung macht klar, dass Ajax nicht automatisch das Problem vom verbindungslosen Datenaustausch zwischen Server und Browser lösen kann. Da es nicht möglich ist, einem Web Server beizubringen, sich bei Bedarf direkt an einen seiner Clients zu wenden, muss das Problem anders angegangen werden. Das bedeutet, dass der Browser sich darum kümmern muss, seine Daten auf der aktuellen Seite, immer «Up to Date» zu halten. Er muss also periodisch beim Web Server nachfragen. Das regelmässige Abfragen eines Dienstes wird in der Informatik Polling genannt. Das Polling wird mit einem Javascript Timer gesteuert. Polling erzeugt eine völlig andere Auslastung auf einem Webserver, verglichen mit der Last, die von herkömmlichen Anwendungen erzeugt wird Vor- und Nachteile von Ajax + Dynamische Webseiten erlauben Destop-Applikationsflair. + Auch für komplexe Anwendungen geeignet. + Leicht erweiterbare Struktur (XML). Grosse Freiheiten bei der Ausgestaltung. + Der Server kann im Browser Javascript Funktionen aufrufen oder Variabeln manipulieren. + Es wird nur die nötigste Information übertragen. + HTTP-Protokoll ermöglicht flexiblen Einsatz. - Die Kommunikation kann immer nur vom Browser initiiert werden. - Durch das Polling wird der Web Server verstärkt mit Request-Anfragen belastet. - Noch nicht völlig standardisierte Technologie. - Viel Javascript Anteil im Browser. - Es gibt immer zwei Codeteile, die bei Änderungen gepflegt werden müssen, nämlich Server und Clientteil. 36

37 Kapitel 4. Ajax Browser-Kompatibilität Folgende Web Browser unterstützen zur Zeit die beschriebene Ajax-Technologie. Ein solcher Web Browser ist auch Voraussetzung für den Betrieb des INDI-Web-Client: Name Erste Version mit Ajax- Unterstützung Native Unterstützung Unterstützung durch ein AddOn Kommentar Microsoft Internet Explorer (ab 7.0) ja (ActiveX- Komponente) Die Version 4.0 unterstützte erstmals XML, jedoch nicht die für Ajax notwendige XMLHttpRequest-API. Diese API wurde später als ActiveX-Komponente realisiert und ist seit Version 7.0 nativer Bestandteil des IE. Browser, die auf der IE-Technologie aufbauen, sind ebenfalls Ajax-kompatibel. Mozilla Firefox 1.0 ja - d. h. die Gecko-basierte Familie der Mozilla- Browser Opera 8.0 ja - - Apple Safari 1.2 ja - - Netscape 7.1 ja - - Konqueror? ja - Das HTML-Rendering etc. wird durch die KHTML realisiert. Diese ist auch Bestandteil des Safari Browsers. icab 3.0 Beta ja - Ältere Version wie beispielsweise die Version für m68k-basierte Computer unterstützen kein Ajax. Abbildung 4.2.: Ajax Web Browser Kompatibilitätsliste [1] Bei manchen Browsern muss beachtet werden, dass die Verarbeitung von Javascript deaktiviert werden kann. Dies kann vor allem dann mühsam werden, wenn der Zu- 37

38 Kapitel 4. Ajax griff auf die Konfiguration des Browsers gesperrt worden ist. Dies könnte z.b. in einem Internet-Café der Fall sein Ajax in unserem Projekt - Client-Seite Die Ajax-Kommunikationszentrale INDIAjaxGeneralRequest.js Webbrowser (Ajax Request Manager) Internet / Local Area Network / SSL / SSH HTTP Requests (GET) HTTP Responses (HTML) HTTP Requests (POST) / HTTP Responses (XML) Dispatcher Servlet (Spring) View (jsp) MainServlet (Ajax) XMLWriter Ajax Manager / PageElement Manager Abbildung 4.3.: Kommunikationspartner der Ajax-Komponente. Ausschnitt Abb. 2.6 Der Ajax-Datenaustausch zwischen dem Server und dem Browser findet auf jeder Seite über bestimmte Schnittstellen statt. Der Browser sendet dabei immer ein HTTP-Request aus, der Server nimmt diese entgegen, verarbeitet die Anfrage und sendet ein HTTP- Response an den Browser zurück. Auf der Seite des Apache Tomcat Servers nehmen zwei Servlets die Requests entgegen: «MainServlet» - Ist die Schnittstelle für alle Anfragen, die an den Ajax-Manager weitergeleitet werden müssen. «Dispatcher Servlet» - Ist ein Servlet des Spring Frameworks, das mittels MVC Konzept einzelne HTML-Teile der Seite generiert und an den Aufrufer zurückschickt. Beim ersten Seitenaufruf wird direkt das Dispatcher Servlet angesprochen (Aufruf der Startseite per URL). Das automatische Aktualisieren der Anzeige und das Übermitteln von Benutzer-Events werden mit Hilfe des XMLHttpRequest-Objekt des Browsers erledigt. Hier ist eigentlich Ajax effektiv versteckt. 38

39 Kapitel 4. Ajax Der XMLHttpRequest-Vorgang wird mit Hilfe von Javascript Code gesteuert. Die Logik dazu findet sich im File INDIAjaxGeneralRequest.js in der Methode makehttprequest(..). Die makehttprequest() ist damit das Herzstück der Ajax-Engine auf dem Web Browser des Benutzers. Die Methode zeichnet sich dadurch aus, das sie universell für XMLsowie für HTML-Anfragen genutzt werden kann. Somit ist es möglich, automatisch HTML-Teile auf der Seite auf Anweisung des Servers hin auszutauschen. In vielen Tutorials wird folgender Aufbau für eine Request-Anfrage mit XMLHttpRequest vorgeschlagen: Zuerst wird global ein neues XMLHttpRequest()-Objekt angelegt. Für Mozilla, Firefox, Safari, and Netscape: 1 var xmlhttp=new XMLHttpRequest() Listing 4.1: Variable XMLHttpRequest erzeugen Für Internet Explorer (ActiveX Objekt): Listing 4.2: Variable XMLHttpRequest erzeugen für Microsoft IE 1 var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP") Nun folgt der eigentliche Code, der die Abfrage ausführt: Listing 4.3: Komplette Routine für einen XMLHttpRequest 1 <script type="text/javascript"> 2 3 function makehttprequest(url) { 4 5 xmlhttp.onreadystatechange=xmlhttpchange 6 xmlhttp.open("get",url, true) 7 xmlhttp.send() 8 } 9 10 function xmlhttpchange() { // Wenn alles komplett uebermittelt worden ist i f (xmlhttp.readystate==4) { // Und Status "OK" gemeldet wird i f (xmlhttp.status==200) { //...xmlhttp.responsexml //...xmlhttp.responsetext //...xmlhttp.statustext // Weiterleiten oder direkt verarbeiten 22 } 23 else { 24 alert("problem retrieving data") 39

40 Kapitel 4. Ajax 25 } 26 } 27 } 28 </script> Code-Beschreibung und Parameter In Zeile 7 wird dem XMLHttpRequest()-Objekt der Name der Callback-Methode bekannt gemacht. Der Event Handler wird jedesmal aufgerufen, wenn sich der Verbindungsstatus (readystate) ändert. Auf Zeile 8 wird die open(..)-methode aufgerufen, welche eine Verbindung zum Server öffnet: Syntax: open(method, URL[, asyncflag[, username[, password]]]) Parameter: method: GET POST PUT HEAD POST sollte verwendet werden, wenn die gesendeten Daten grösser als 500 bytes sind. Ansonsten kann auch GET verwendet werden. HEAD wird verwendet, wenn nur Response Header und keine Daten angefordert werden. Es kann z.b. verwendet werden, wenn für eine Datei auf dem Server das Datum der letzten Änderung (last-modified) abgefragt werden soll. URL: Pfad (relative oder absolut) + ggf. Querystring. asyncflag: true false asynchrone (true) oder synchrone (false) Datenübertragung. username: Benutzername... password:... und Passwort für eine Ressource auf dem Server. Danach werden mit send(«content») die Daten an den Server übermittelt. Content ist leer bei GET und ein Parameter-String bei POST. Mit setrequestheader(«label», «value») können noch zusätzlich Header Parameter gesetzt werden. Nun wird die Callback Routine aufgerufen und mit readystate() ausgewertet wie der Verbindungsstatus des Requests ist: 0 = Verbindung noch nicht geöffnet ( open() noch nicht aufgerufen) 1 = Noch keine Anfrage gesendet ( send() noch nicht aufgerufen) 40

41 Kapitel 4. Ajax 2 = Anfrage gesendet, Antwort-Header und Antwort-Status kann abgefragt werden. 3 = Daten vom Server kommen nach und nach an. responsetext enthält die bislang vom Server gesendeten Daten. 4 = Kommunikation mit dem Server ist abgeschlossen. Alle Daten sind angekommen (status = 200), wenn kein Fehler aufgetreten ist. status - Enthält den HTTP-Status der Verbindung als Zahl (z.b. 200 für Erfolg oder 404, wenn die angeforderte Ressource nicht existiert) statustext - Enthält den HTTP-Status als Text-Meldung (z.b. «Not found») responsexml - Enthält die vom Server gesendeten Daten als XML-Daten. Wenn die Daten als Plaintext gesendet worden sind, enthält responsexml null. responsetext - Enthält die vom Server gesendeten Daten als Text. Verbesserungen am Code für den Einsatz im INDI-Web-Client 1 /* INDI AJAX SCRIPTS */ 2 /* 08_03_2006 by P.Suetterlin */ 3 4 /* IE konformer Request erzeugen 5 */ 6 function getrequest(){ 7 Listing 4.4: Das File «INDIAjaxGeneralRequest.js» 8 i f (window.xmlhttprequest) { 9 req = new XMLHttpRequest(); 10 } else i f (window.activexobject) { 11 isie = true; 12 req = new ActiveXObject("Microsoft.XMLHTTP"); 13 i f (req == null){ 14 req = new ActiveXObject("Msxml2.XMLHTTP"); 15 } 16 } i f (req == null){ 19 alert( Unfortunatelly your browser doesn\ t support Ajax feature. ); 20 } return req; 23 } /* ############## Universelle Ajax Request Funktion ############## 26 * url = Pfad fuer den Request 27 * parameters = Uebergabeparameter 28 * callback_function = Die Methode die nach der Funktionsausf?hrung 29 * automatisch aufgerufen wird. 41

42 Kapitel 4. Ajax 30 * return_xml = Bei true wird XML zurueckgeliefert, ansonsten Text. 31 * targetid = ZielID auf der aktuellen Page dynamischen HTML. 32 */ 33 function makehttprequest(url, parameters, callback_function, return_xml, targetid) 34 { 35 var time = new Date().getTime(); 36 setlamppicture("pollstatus", getlamppath("busy"), "Busy"); 37 inserthtml("pollrate", m_refreshrate + " ms"); 38 var http_request = getrequest(); i f (!http_request) { 41 alert( Unfortunatelly your browser doesn\ t support Ajax feature. ); 42 return false; 43 } 44 http_request.onreadystatechange = function() { 45 i f (http_request.readystate == 4) { i f (http_request.status == 200) { 48 inserthtml("polllatency", new Date().getTime() - time + " ms") ; 49 setlamppicture("pollstatus", getlamppath("ok"), "Ok"); 50 i f (return_xml) { eval(callback_function + (http_request.responsexml) ); 53 } else { i f (targetid!= null){ 56 eval(callback_function + (\" + targetid + \", http_request.responsetext) ); 57 } else { 58 eval(callback_function + (http_request.responsetext) ); 59 } 60 } 61 } else { 62 setlamppicture("pollstatus", getlamppath("alert"), "Alert"); 63 inserthtml("polllatency", "no answer"); 64 } 65 } 66 } http_request.open( POST, url, true); 69 http_request.setrequestheader("content-type", "application/x-www-formurlencoded"); 70 http_request.setrequestheader("content-length", parameters.length); 71 http_request.setrequestheader("connection", "close"); 72 http_request.send(parameters); 73 } Der Name «General Request» deutet schon darauf hin, dass diese Request-Methode für verschiedene Aufgaben eingesetzt werden kann. Die erste vorgestellte Methode hat diesbezüglich einen grossen Nachteil. Das XML- 42

43 Kapitel 4. Ajax HttpRequest() wird nämlich global instanziert. Dies ist nötig, da die Verarbeitung auf zwei getrennte Routinen aufgeteilt ist. Zum einen die Hauptroutine, zum anderen die Callback Routine. Beide brauchen Zugriff auf das XMLHttpRequest-Objekt. Das ganze erzeugt dann ein Problem, wenn mehrere Requests in schneller Folge hintereinander oder annähernd parallel durchgeführt werden müssen. Denn das XMLHttpRequest() beansprucht eine gewisse Verarbeitungszeit, da das Objekt jedesmal Daten über das Netzwerk hin- und her übertragen muss (HTTP Request - Response). Falls nun unmittelbar während dieser Verarbeitungszeit eine weitere Request gestartet wird, so geht das aktuelle Request-Objekt verloren, weil es von einem neuen überschrieben wird. Die Folge davon ist entweder eine lückenhafte Übertragung oder ein völliges Abwürgen des Datenverkehrs. Ein Auszug aus einem MSDN-Artikel verdeutlicht das Problem: Auf Grund seiner Asynchronität erlaubt AJAX das parallele Verschicken von HTTP Requests. Nach dem Absenden läuft die Javascript-basierte Oberfläche weiter, und erst bei Eintreffen der HTTP-Antwort, wird die Methode am jeweiligen Objekt aufgerufen (Event Handling). Um mehrere Requests parallel abzusetzen, ist es notwendig, für jeden Request eine eigene Callback-Methode zu definieren und dem jeweiligen Objekt zuzuweisen. Die so initialisierten Objekte können zu einem beliebigen Zeitpunkt eine Verbindung öffnen und einen Request absenden. [2] Man müsste also für jeden Request eine eigene Callback-Methode definieren. Ein zentrales Abwickeln über eine einzelne universelle Methode wäre also unmöglich ohne ein dynamisches Erstellen mehrerer Callback-Methoden. Unsere eingesetzte Technik löst dieses Problem nun auf eine elegante, wenn aber auch nicht ganz einfache Weise. Die beiden Methoden für den Aufruf und das Callback werden nun einfach verschachtelt. Mit dem Aufruf von «function()» kann in der Hauptfunktion nun eine zweite namenlose Callback-Funktion deklariert werden. 1 function makehttprequest(url) { 2 Listing 4.5: Verschachtelte Methoden 3 // Erste Methode mit XMLHttpRequest() Objekt 4 var http_request = new XMLHttpRequest(); 5 6 http_request.onreadystatechange = function() { 7 8 // Zweite verschachtelte Methode 9 // Hier kann auch auf das XMLHttpRequest() Objekt 10 // zugegriffen werden. 11 } 12 } Für jeden Methodenaufruf in Javascript wird ein separater Prozess mit eigenem Namensraum erzeugt. Variablen, welche in den Methoden erzeugt werden, sind nur innerhalb des Methodenaufrufs gültig. So können nun mehrere XMLHttpRequest()-Objekte 43

44 Kapitel 4. Ajax in den verschiedenen Aufrufen scheinbar parallel abgearbeitet werden. Es findet keine gegenseitige Beeinflussung mehr statt. Multifunktionalität dank Callback-Funktionen Da das Problem mit den XMLHttpRequest()-Objekten nun gelöst ist, kann die Methode für verschiedenste Aufgaben fit gemacht werden. Dazu benötigt die Methode einige Parameter: Listing 4.6: Parameter der Methode makehttprequest() 1 function makehttprequest(url, parameters, callback_function, 2 return_xml, targetid) url (String) - Die URL des Zieldienstes. Die Request wird dorthin gesandt. parameters (String) - Übergabeparameter für den Zieldienst. Diese Parameter werden mit POST an den Server geschickt. Dort werden sie von den Servlets oder dem Ajax-Manager ausgewertet. callback_function (String) - Der Name einer Javascript-Funktion, die im Browser zu Beginn bereits geladen worden ist. Nach Erhalt des angeforderten Datensatzes wird diese Funktion aufgerufen. return_xml (boolean) - true false. Es wird XML an die Callback-Funktion zurückgegeben (true) oder Text/HTML (false). targetid (String) - Gibt die ID eines <div> Tags an, in welchen bei return_xml=false die HTML-Inhalte eingetragen werden sollen. Interessant ist vor allem die Angabe der Callback-Funktion. So kann beim Aufrufen des Requests bereits bestimmt werden, in welcher Methode später die Daten weiterverarbeitet werden sollen. Praktisch ist auch der Parameter «targetid». Mit einem einfachen Aufruf können einzelne HTML-Bereiche auf der bereits geladenen Seite so ausgetauscht werden Der Requestgenerator für das Polling Wie anfangs erwähnt, muss die Oberfläche andauernd mit Polling-Anfragen auf dem neusten Stand gehalten werden. Dazu muss ein Script geschrieben werden, welches regelmässig Requests mit der Methode makehttprequest() ausführt: 44

45 Kapitel 4. Ajax Listing 4.7: Das File «INDIAjaxRefresh.js» 17 /* - ############## Refresh Einsprungspunkt ############## 18 */ 19 function Refresh(){ // Device Namen holen 22 var device = window.document.getelementbyid("active-device"); 23 i f (device!= null){ 24 var devicename = device.title 25 } // Group Namen holen 28 var group = window.document.getelementbyid("active-group"); 29 i f (group!= null){ 30 var groupname = group.title 31 } // Version der aktuellen Anzeigegruppe holen 34 var version = window.document.getelementbyid("active-version"); 35 i f (version!= null){ 36 var versionnum = version.title 37 } // Refresh Request an INDIAjaxController senden 40 // Callback Routine ist processreqchange() 41 makehttprequest( "INDIAjaxController", 42 "action=refresh" + 43 "&deviceversion=" + escape(m_deviceversion) + 44 "&connectversion=" + escape(m_connectversion) + 45 "&messageversion=" + escape(m_updatemessageversion) + 46 "&device=" + escape(devicename) + 47 "&group=" + escape(groupname) + 48 "&displayversion=" + escape(versionnum), 49 "processreqchange", 50 true); // Versionenanzeige updaten 53 inserthtml("connection", m_connectversion); 54 inserthtml("device", m_deviceversion); 55 inserthtml("message", m_updatemessageversion); 56 inserthtml("group", versionnum); // Prozess nach Timeout neu starten 59 settimeout("refresh()", m_refreshrate); 60 } Im Code findet sich die Methode makehttprequest() wieder. Aufgerufen wird das Servlet mit dem URL-Namen «INDIAjaxController». Die Callback-Methode ist «processreqchange» und mit «true» wird festgelegt, dass der Response XML-Daten liefern wird. Die Parameter an zweiter Stelle sind Informationen für den Ajax-Manager (IN- DIAjaxController). Wie man bei genauerer Betrachtung der Zeile 46 sehen kann, ruft sich die Methode 45

46 Kapitel 4. Ajax nach einem Timeout wieder selbst auf. Die Geschwindigkeit der Aufrufe wird mit der Variable m_refreshrate gesteuert. Der Wert wird in Millisekunden beim Initialisieren im Browser festgelegt. Dazu gibt es eine separate Methode im gleichen.js File: 12 function setrefresh(rate){ m_refreshrate = rate; 15 } Listing 4.8: Die Refresh Rate wird hier eingestellt Hier noch das Einbinden des Skripts und die Initialisierungsanweisung im File «start.jsp». Ebenfalls kann man erkennen, wie bei der Anweisung «onload» der Refresh() Prozess angestossen wird: Listing 4.9: Starten und Einstellen des Refresh Prozesses (start.jsp) 1 <!-- INDIAjax Skripts --> < s c r i p t type="text/javascript" language="javascript" src="js/indiajaxrefresh.js"></ s c r i p t > <!-- INDIAjax Refresh Settings --> 8 < s c r i p t type="text/javascript"> 9 setrefresh(2000); 10 </ s c r i p t > <body onload="javascript:refresh();cleararea( messagebox );" > Am oberen Ende des Files INDIAjaxRefresh.js finden sich noch drei interessante Variabelndeklarationen. Das sind die Versionsvariabeln, in denen die aktuelle Anzeigeversion eines dynamischen HTML-Bereiches hinterlegt sind. Alle Versionsnummern werden bei jedem Request an den Ajax-Manager gesendet. So kann dieser erkennen, ob allenfalls in einem Bereich eine Änderung vollzogen werden muss. Wenn der Inhalt dann geändert worden ist, setzt der Server die Versionsnummer auf den aktuellen Wert. Wir werden die Zähler auch noch im Ajax-Manager genauer betrachten. Listing 4.10: Die Versions-Variabeln (INDIAjaxRefresh.js) 6 var m_deviceversion = -1; // Update Version 7 var m_connectversion = -1; // Update Version 8 var m_updatemessageversion = 0; // Update Version 46

47 Kapitel 4. Ajax Die weitere Verarbeitung der erworbenen Daten INDIAjaxReplacePicture.js (Replace Picture) INDIAjaxSetLamp.js (Replace Lamp) Navigation User Interface INDIAjaxMessageBox.js (Add MessageLine) INDIAjaxReplaceText.js (Replace Text) Connect control Devicelist Update Objects INDIAjaxSetButtonState.js (Enable / Disable Buttons) INDIExecuteFuntionCall.js (Execute js Funtion) Tabbar / Tabarea ReplaceHTML Content INDIAjaxHTMLManager.js (ReplaceHTML / Initiate HTML Requests) Requests and Responses (HTML) Assign HTML Request Call Methods INDIAjaxGeneralRequest.js (Ajax Request Manager) Response (XML) INDIAjaxAllocator.js (Prescreening - Forwarding) Abbildung 4.4.: Response Datenverarbeitung. Ausschnitt Abb. 2.6 HTML- und XML-Daten Je nachdem welches Servlet beim Request angesprochen worden ist, liefert die makehttprequest() Methode XML oder HTML an die gewünschte Callback-Methode zurück. HTML-Daten werden direkt auf das Web Interface überführt. XML-Daten hingegen werden erst einmal mit Javascript ausgewertet und weiteren spezialisierten Routinen übergeben. Im XML stehen nämlich Anweisungen für verschiedenste Prozesse, die dann bei Bedarf nacheinander aufgerufen werden. HTML-Datenverarbeitung Listing 4.11: Der HTML Manager im File INDIAjaxHTMLManager.js 1 /* INDI AJAX SCRIPTS */ 2 /* 08_03_2006 by P.Sütterlin */ 3 4 /* - ############## HTML Verarbeitung und Anforderungen ############## 5 */ 6 function replacehtmlcontent(action) { 7 8 var response = action.getelementsbytagname("object-id")[0]; 47

48 Kapitel 4. Ajax 9 var object = TrimString(response.firstChild.nodeValue); 10 var response = action.getelementsbytagname("url")[0]; 11 var url = TrimString(response.firstChild.nodeValue); makehttprequest(url, "", "inserthtml", false, object); 14 } function inserthtml(object, htmlcontent){ var outputarea = window.document.getelementbyid(object); 19 if (outputarea!= null){ 20 outputarea.innerhtml = htmlcontent; 21 } 22 } Mit der Funktion «replacehtmlcontent(action)» kann ein neuer HTML Request ausgelöst werden. Der Parameter «action» ist ein XML-Datensatz der eine URL und eine ID für das Ziel enthält. Nach der Auswertung wird makehttprequest() aufgerufen und der HTML Response wird an die Callback-Methode inserthtml() übergeben. Mit der Funktion «inserthtml(object, htmlcontent)» wird HTML auf der Webpage an einer bestimmten Stelle eingefügt. Die benötigten Parameter sind: object - enthält die ID eines <div> Tags, welcher in der geladenen HTML-Seite des Browsers bereits existieren muss. htmlcontent - enthält den HTML Code, der eingesetzt werden soll. Hier zum Beispiel das <div> Tag für den Einfügepunkt, in dem später der HTML Code der Links mit allen INDI-Geräten platziert wird: Listing 4.12: Einfügepunkt für HTML Code der Device Liste (navigation.jsp) 1 <div id="devicelist"> 2 <!--Einfgepunkt der Device List--> 3 </div> Mit «var outputarea = window.document.getelementbyid(object)» wird das <div> Objekt mit dem «id» String auf der Seite lokalisiert. Danach kann mit «outputarea.innerhtml = htmlcontent» der HTML Code zwischen dem Start und Endtag eingefügt werden. Der bestehende Inhalt wird dabei überschrieben. XML-Datenverarbeitung Der empfangene XML-Datensatz wird in einem ersten Schritt von der Funktion «processreqchange(req)» im File «INDIAjaxAllocator.js» entgegengenommen. Ausgewertet werden hier folgende Informationen: 48

49 Kapitel 4. Ajax Das <update-device-version> Tag - Enthält die neuste Version für den Device List HTML-Bereich. Das <update-connect-version> Tag - Enthält die neuste Version für den Connection- Anzeige-Bereich. Mehrere <action> Tags - Enthalten Informationen für weitere Aktionen. process- ReqChange() leitet diese an die zuständigen Funktionen weiter. Listing 4.13: Schleife durch alle <actions> im XML-Datenrecord (INDIAjaxAllocator.js) 1 // Alle Actions im XML abarbeiten 2 f o r (var i = 0; i < action.length; i++){ 3 4 var actiontype = action[i].getattribute("actiontype"); 5 6 // actiontype = Lampen ersetzen. 7 i f (actiontype == "replace-lamp"){ 8 replacelamp(action[i]); 9 } // actiontype = Texte ersetzen. 12 i f (actiontype == "replace-textfieldcontent"){ 13 replacetextfieldcontent(action[i]); 14 } // actiontype = Device HTML Bereich ersetzen. 17 i f (actiontype == "replace-htmlcontent"){ replacehtmlcontent(action[i]); 20 } // actiontype = Javascript Funktion ausführen. 23 i f (actiontype == "execute-function"){ executefunction(action[i]); 26 } // actiontype = Javascript Button State ausführen. 29 i f (actiontype == "change-buttonstate"){ setbuttonstate(action[i]); 32 } 33 } Hier noch eine Übersicht über die aufrufbaren Funktionen: 49

50 Kapitel 4. Ajax Funktionsname File replacelamp() INDIAjaxSetLamp.js replacetextfieldcontent() INDIAjaxReplaceText.js replacehtmlcontent() INDIAjaxHTMLManager.js executefunction() INDIAjaxExecuteFunction.js setbuttonstate() INDIAjaxSetButtonState.js XML Elemente <object-id> <state> <object-id> <text> <object-id> <url> <call> <object-id> <disabled> Beschrieb Ersetzt Statuslampen in der Verbindungsanzeige und Property- Anzeigen. Ersetzt Texte in Textfields. Ladet einen HTML Bereich in eine <div> nach. Führt einen Javascript-Anweisung zur Laufzeit aus. Setzt das Aussehen eines Buttons auf enabled/disabled. Tabelle 4.1.: Actions, die vom «AjaxAllocator» aufgerufen werden können Events bei Link- / Buttonklicks Damit der Benutzer interaktiv mit dem System arbeiten kann, benötigt er Steuerflächen und Eingabefelder. Das Übermitteln einer Eingabe oder das Treffen einer Auswahl wird mit einem einfachen Link oder einem Button ausgelöst. Der Aufruf geschieht mit dem «onclick()» Event Handler des jeweiligen Buttons oder des Links. Dieser stösst dann die makehttprequest()-methode an. Damit später der Ajax-Manager weiss, von wo der Event ausgelöst wurde und was dieser bezwecken soll, müssen jeweils einige Parameter übermittelt werden: Listing 4.14: Der eingetragene Text wird an den Ajax-Manager (INDIAjaxController) übermittelt (inditext.jsp) 1 {Inditext} onclick=" 2 var text = escape(gettext( field_<c:out value="${elements.property.pname} "/>_<c:out value="${text.ename}"/> )); 3 makehttprequest( INDIAjaxController, 4 action=send + 5 &type=textvector + 6 &device= + escape( <c:out value="${elements.property.pdevice}"/> ) + 7 &pname= + escape( <c:out value="${elements.property.pname}"/> ) + 8 &ename= + escape( <c:out value="${text.ename}"/> ) + 9 &text= + text, 10, 11 true ); 12 " 50

51 Kapitel 4. Ajax Es können auch direkt HTML-Bereiche auf der Seite ersetzt werden. Dazu müssen einfach die Parameter des makehttprequest() so gesetzt werden, dass HTML vom Dispatcher-Servlet zurückgegeben wird. Als Callback wird die Funktion «inserthtml» verwendet und beim letzten Parameter die <div> ID angegeben: 1 onclick=" Listing 4.15: Direktes Anfordern von HTML-Bereichen (devices.jsp) 2 var device = escape( <c:out value="${dev}"/> ); 3 makehttprequest( tabarea.html, device= + device, inserthtml, false, tabarea ); 4 " Hier wird z.b beim Anwählen eines Device Links die Seite «tabarea.html» aufgerufen und der Parameter «device» übergeben. Die inserthtml() wird als Callback aufgerufen und der HTML Code in das <div> mit der ID «tabarea» eingefügt Ajax in unserem Projekt - Server-Seite Der Ajax-Manager HTTP Requests (POST) / HTTP Responses (XML) MainServlet (Ajax) XMLWriter Forward Request Version Manager Ajax Manager / PageElement Manager Update Version Connect / Disconnect SendEvent Send XML Socket Connection Parse XMLTemplate Library XML Abstraction (synchronized) Construct / Update XML Parser Abbildung 4.5.: Die Ajax-Verarbeitungsschicht. Ausschnitt Abb. 2.6 Im Ajax-Manager werden sämtliche Requests für die Aktualisierung des User Interfaces, sowie Events der Benutzer ausgewertet. Vor dem Ajax-Manager steht jedoch noch ein Servlet, welches über den URL-Pattern «INDIAjaxController» angesprochen wird. Dieses Servlet leitet das Request- und Response- Objekt an den Manager weiter. 51

52 Kapitel 4. Ajax Der Ajax-Manager steht in engem Kontakt mit der Applikationsschicht, die mit dem INDI-Server kommuniziert. Er startet die Verbindung zum INDI-Server oder beendet diese wieder. Bei Fehlern sorgt der Ajax Manager dafür, dass der Web-Benutzer angemessen benachrichtigt wird. Ausserdem verwaltet er die Versionen der einzelnen Anzeigebereiche auf dem User Interface. Bei einem Request wird immer erst ermittelt, welche Aktion der Client vom Ajax- Manager ausgeführt haben möchte: action Benötigte Parameter für den Aufruf connect disconnect refresh send host port deviceversion connectversion messageversion device group type device pname ename {text / number} Beschrieb Öffnet eine Socket Connection zum INDI Server an der Socket-Adresse host:port Schliesst eine geöffnete Socket-Verbindung wieder. Sorgt dafür, dass beim nächsten Polling bei allen Clients die Anzeigebereiche aufgeräumt werden. Prüft für jeden Anzeigebereich ob Updates nötig sind. Setzt alle aktuellen Werte der INDI Properties, falls der Client einen Device und Group-Parameterwert übermittelt. Prüft für jeden Anzeigebereich, ob Updates nötig sind. Setzt alle aktuellen Werte der INDI Properties, falls der Client einen Device und Group-Parameterwert übermittelt. Tabelle 4.2.: Actions, die vom Ajax-Manager verarbeitet werden Welche Aktion ausgeführt werden soll, steht im «action» Parameter des Request Objekts: Mit getparameter() wird der Parameter aus dem Request-Objekt herausgeholt und in den String «action» abgelegt. Listing 4.16: Holen des «action» Parameters aus der Request (AjaxManager.java) 1 // Lookup for action parameter 2 String action = request.getparameter("action"); Für das Verarbeiten der Anfragen stehen weitere Hilfsklassen zur Verfügung: PageElementManager - Holt die Werte für die Properties der aktuellen Anzeige des jeweiligen Clients aus der Abstraktion und stellt die Update-Informationen für das Response XML zusammen. 52

53 Kapitel 4. Ajax SendEvent - Wertet die Event Requests der Clients aus und erstellt ein strukturiertes XML, welches an den Server übermittelt wird. Ausserdem werden numerische Werte auf Einhaltung des minimal oder maximal zulässigen Wertebereichs geprüft und falls nötig bei einer Überschreitung eine Mitteilung an den Client geschickt. XMLWriter - Erstellt aus den zusammengestellten XML-Daten ein formgültiges XML-Dokument und sendet dieses an den anfragenden Client zurück. Jeder Client erhält am Ende jedes Requests eine Sammlung vieler verschiedener Anweisungen (actions) welche in einem XML-Element-Objekt mit dem Namen «data» untergebracht werden. Für jede Request-Anfrage wird ein solches JDOM-Objekt angelegt, die nötigen Anweisungen (actions) darin untergebracht und anschliessend mit der XMLWriter-Klasse als Response an den anfragenden Client zurückgeschickt. Hier ein Beispiel für eine XML-Response die bei dem Vorgang generiert wird: Listing 4.17: Generiertes XML wird an die Ajax Engine im Browser zurückgeschickt 1 <data> 2 <action actiontype="replace-htmlcontent"> 3 <object-id>devicelist</object-id> 4 <url>devices.html</url> 5 </action> 6 <update-device-version>32687</update-device-version> 7 <action actiontype="replace-lamp"> 8 <object-id>statusbild</object-id> 9 <state>busy</state> 10 </action> 11 <action actiontype="replace-textfieldcontent"> 12 <object-id>status</object-id> 13 <text>parsing...</text> 14 </action> 15 <update-connect-version>32604</update-connect-version> 16 </data> XML Templates XML Templates sind statische Objekte mit einer Methode. Das Template erhält als Parameter immer ein bestehendes JDOM-Element vom Aufrufer und weitere für die XML-Information benötigte Daten. Anschliessend wird mit den Daten ein neues JDOM-Element erzeugt. Dies nach einem bestimmten Muster (Template): Listing 4.18: Ein XML Template für eine change-buttonstate Anweisung 1 <action actiontype= change-buttonstate > 2 <object-id> 3 id 53

54 Kapitel 4. Ajax 4 </object-id> 5 <disabled> 6 state 7 </disabled> 8 </action> actiontype Attribut = Erkennungsmerkmal für den AjaxAllocator der Ajax-Engine object-id Element = Beschreibt mit einem Namen, welches Element auf der Seite des Clients verändert werden soll. disabled Element = Beschreibt, ob der Button im «disabled» Style (1) oder «enabled» (0) dargestellt werden soll. Am Schluss wird das neue <action>-element dem übergebenen <data>-element hinzugefügt: Listing 4.19: Das XML Template File «ChangeButtonState.java» 1 public s t a t i c void changebuttonstate(element data, String id, String state) { 2 3 // Action Element anlegen und Attribut für Action Type setzen 4 Element action = new Element("action"); 5 action.setattribute("actiontype", "change-buttonstate"); 6 data.addcontent(action); 7 8 // Object-id Element anlegen und Wert setzen 9 Element object_id = new Element("object-id"); 10 object_id.addcontent(new Text(id)); 11 action.addcontent(object_id); // State Element anlegen und Wert setzen 14 Element url_elem = new Element("disabled"); 15 url_elem.addcontent(new Text(state)); 16 action.addcontent(url_elem); 17 } Für jede in der Tabelle 4.1 aufgeführte Ajax-Funktion gibt es ein solches Template. Das Hinzufügen einer Action zum Response XML ist nun wirklich sehr einfach und praktisch geworden. Listing 4.20: Beispiel für die Benutzung der Templates 1 // Error occured, send message with javascript call to browser 2 String command = "alert(\"hallo\");"; 3 ExecuteFunctionCall.executeFunctionCall(data, command); Hier wird z.b. eine ExecuteFunctionCall Action dem Element data hinzugefügt. Darin wird der Befehl im String command eingefügt und anschliessend im Browser zur Ausführung gebracht. Beim Client würde dann eine Alert Box mit der Mitteilung «hallo» erscheinen. 54

55 Kapitel 4. Ajax Es können mehrere Actions nacheinander so aneinander gefügt werden, im Browser werden dann die Action-Anweisungen nacheinander abgearbeitet Der Versionsmanager Der Versionsmanager ist ein Tool, das mehrere Versionszähler für den Ajax-Manager verwalten kann. Ausserdem haben die Klassen «SocketConnection.java» und «XML- Parser.java» Zugriff auf die Zähler. Diese erhöhen jeweils die Werte eines Zählers, wenn eine für die Anzeige relevante Änderung eingetreten ist. Der Ajax-Manager kann anhand der Information im Request des Clients (Versionsnummern) feststellen, ob ein Anzeigebereich nachgeladen werden muss. Zähler werden im Versionsmanager in einer HashMap mit einem Namen verwaltet. Der Aufbau eines Zählers ist ganz einfach gestaltet: Listing 4.21: Ein Zähler im Versions-Manager (VersionCounter.java) 1 public class VersionCounter { 2 3 p r i v a t e short updateversion = Short.MAX_VALUE; 4 5 // Decrements version counter 6 public void informationupdate() { 7 8 i f (updateversion > 0) { 9 updateversion--; 10 } else { 11 updateversion = Short.MAX_VALUE; 12 } 13 } Der Zähler besitzt eine private Short Variable, die beim Aufruf von informationupdate() um einen Zähler dekrementiert wird. Die Variable wird zu Beginn mit dem Maximalwert MAX_VALUE initialisiert. Sobald die Zahl 0 erreicht hat, wird sie wieder auf den Maximalwert gesetzt. Bei dem Erstaufruf der Seite wird der Zähler im Browser erst auf -1 gesetzt (siehe 4.2.2). Da die Zählerzahl im Manager nie niedriger als 0 sein kann, findet nach dem Laden der Seite auf jeden Fall ein erster Update der Anzeigebereiche statt. So ist es möglich zu sehen, ob bereits ein anderer Benutzer eine Verbindung hergestellt hat. Die einzelnen Versionszähler werden beim Manager wie folgt angesprochen: Listing 4.22: Auslesen des Zählers mit dem Namen «ServerConnection» 1 versionmanager.getversion("serverconnection").getinformationupdatestate() Listing 4.23: Update des Zählers mit dem Namen «ServerConnection» 1 versionmanager.getversion("serverconnection").informationupdate(); 55

56 Kapitel 4. Ajax XML-Anweisungen für den INDI-Server (Send Event) In der Klasse «SendEvent.java» wird die «send»-request eines Clients verarbeitet. Dabei wird die Eingabe einer Prüfung unterzogen und anschliessend ein XML in der Notation für den INDI-Server erstellt: Listing 4.24: NewSwitchVector-Anweisung an den INDI-Server 1 <newswitchvector device="simple Device" name="connection"> 2 <oneswitch name="connect">on</oneswitch> 3 </newswitchvector> Im obigen Beispiel wird dem Server mitgeteilt, dass im Switch Property mit dem Namen: «CONNECTION» des Devices: «Simple Device» das Switch-Element mit dem Namen «CONNECT» auf «On» geschaltet werden soll. Wenn alle Daten korrekt übermittelt worden sind, erfolgt eine Bestätigung des INDI- Servers an all seine Clients. Bei den numerischen Properties gibt es zwei spezielle Punkte, die beachtet werden müssen. Zum einen kennt INDI ein spezielles Format für die Ausrichtung von astronomischen Geräten. Dieses Format wird «sexagesimales» Format genannt. Die Notation für das Format wird im White Paper des INDI Frameworks vorgestellt. Ein Wert hat zum Bsp. folgende Formatierung: «hh:mm:ss.ss» Bruchzahl = hh + mm 60 + ss.ss 3600 (4.1) Astronomen benutzten in ihren Sternenkarten und -tabellen die Schreibweise des berühmten griechischen Astronomen Ptolemäus, die auf sexagesimalen Brüchen basierte. Man kann erkennen, dass es dabei um ein Zahlensystem mit Basis 60 handelt. Wenn man dies auf die Uhrzeit überträgt, sind «hh» Stunden, «mm» sind Minuten und «ss» Sekunden. Es gibt noch weitere Abwandlungen und Abkürzungen, die verwendet werden können, z.b. «hh:mm.m». Zwischen dem INDI-Server und seinen Clients wird der Wert als Bruch übermittelt. Somit muss eine Umwandlung stattfinden, wenn man möchte, dass der Benutzer das sexagesimale System nutzen kann. Diese Aufgabe erledigt die Klasse «PrintSexagesimal.java». Sie ist in der Lage, die Werte in beide Richtungen zu konvertieren. 56

57 Kapitel 4. Ajax Der zweite Punkt sind die Limiten, die vom INDI-Server vorgegeben werden. Diese müssen vom Client geprüft werden. Es gibt einen maximalen und minimalen Wert. Zusätzlich muss geprüft werden ob der Wert in einem bestimmten Step-Intervall liegt. Bei einem sexagesimalen Wert sind die Limiten als Bruch angegeben. Bei Switches müssen die Property Rules eingehalten werden. In den Rules ist das Verhalten der Button-Gruppe in einer Property geregelt. Nach Abschluss aller Prüfungen und Konvertierungen liegt ein generiertes XML vor, das über das Socket-Connection-Objekt an den INDI-Server überstellt wird. Damit ist auch der Kreis des Nachrichtenflusses zwischen INDI-Server und den einzelnen Web Clients geschlossen. 57

58 Kapitel 5. Acegi Security 5.1. Sicherheitskonzept INDI-WebClient Die Webapplikation INDI-WebClient soll weltweit erreichbar sein, jedoch sollen nur authentifizierte Benutzer darauf zugreifen können. Nicht authentifizierte Benutzer werden vom Sicherheitssystem abgewiesen. Kann sich ein User authentifizieren, wird durch eine Rollenvergabe bestimmt, was er machen kann und was nicht. Es existieren folgende Rollen: Admin-Rolle (ROLE_ADMIN) Ein Benutzer mit Admin-Status kann vom INDI-Hauptfenster in den Admin- Bereich wechseln und dort neue User erstellen und wieder löschen. Um einen Admin-Status erlangen zu können, muss der Benutzer vorgängig den Status erlangt haben. User-Rolle (ROLE_USER) Ein gewöhnlicher Benutzer mit User-Status kann vollumfänglich mit dem System interagieren. Er kann den INDI-WebClient mit dem INDI-Server verbinden und Werte von Geräten verändern. Passivrolle (ROLE_PASSIV) Ein Benutzer mit Passiv-Status befindet sich in einem Read-Only-Modus. Er kann also keine Änderungen an Geräten vornehmen, sämtliche Buttons sind für ihn deaktiviert. Acegi Security eignet sich hervorragend für das INDI-WebClient-Projekt, da es sich nahtlos in das Springframework integrieren lässt. Im nächsten Abschnitt wird Acegi Security näher vorgestellt. 58

59 Kapitel 5. Acegi Security 5.2. Acegi Security Grundlagen Acegi Security ist ein Sicherheitssystem, das auf dem Springframework aufbaut. Selbstverständlich kann es auch ohne Spring eingesetzt werden. Es gibt die Möglichkeit, Acegi Security auch per Servlet Filter und AspectJ einzusetzen. So kann es für (fast) jede Web und Client/Server Java-Anwendung benutzt werden. Acegi Security implementiert eine einfache, aber sehr mächtige Umsetzung von Sicherheitsaspekten auf allen Schichten einer Anwendung. Dabei beschäftigt sich das Framework vor allem mit Authentifizierungs-, Autorisierungsund verschiedene Security-Funktionen Konfiguration INDI-WebClient Acegi Security Soll eine Webapplikation mit Acegi Security geschützt werden, muss man ihr das mitteilen. Das erste File, das der Tomcat beim Start parst, ist das «web.xml». In diesem File weisen wir den Tomcat-Server an, dass Acegi Security geladen werden soll. 1 <!-- Acegi Filters --> 2 3 <filter> Listing 5.1: «web.xml» 4 <filter-name>acegi Filter Chain Proxy</filter-name> 5 <filter-class > 6 org.acegisecurity.util.filtertobeanproxy 7 </filter-class > 8 <init-param> 9 <param-name>targetbean</param-name> 10 <param-value>filterchainproxy</param-value> 11 </init-param> 12 </filter> <filter-mapping> 15 <filter-name>acegi Filter Chain Proxy</filter-name> 16 <url-pattern>/*</url-pattern> 17 </filter-mapping> <!-- End Acegi Filters --> Auf Zeile 4 steht die wichtigste Definition. Der Filter Chain Proxy startet drei Filter, die im «applicationcontext.xml» konfiguriert werden. Zwischen Zeile 14 und 17 sagen wir, dass jeder Request auf den INDI-WebClient durch das Acegi-Security-Sicherheitssystem geschlauft wird. Die untenstehende Grafik gibt Aufschluss zur Funktionsweise des Filter Chain Proxys: 1 Weitere Informationen unter: Acegisecurity Home Page 59

60 Kapitel 5. Acegi Security Abbildung 5.1.: Funktionsweise des Filter Chain Proxys [6] 1 Im «applicationcontext.xml» finden wir nun die Konfigurationen der einzelnen Filter: Listing 5.2: «applicationcontext.xml» 2 <bean id="filterchainproxy" 3 class="org.acegisecurity.util.filterchainproxy"> 4 <property name="filterinvocationdefinitionsource"> 5 <value> 6 CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON 7 PATTERN_TYPE_APACHE_ANT 8 /**=httpsessioncontextintegrationfilter, formauthenticationprocessingfilter, exceptiontranslationfilter,filtersecurityinterceptor 9 </value> 10 </property> 11 </bean> Das Bean FilterChainProxy hat folgende Aufgaben: 1. PATTERN_TYPE_APACHE_ANT: Sicherheits-URL-Muster können vereinfacht angegeben werden. 2. CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON: Das Acegi Framework soll alle Grossbuchstaben in einer URL in Kleinbuchstaben umwandeln, so kann der Security-Mechanismus nicht übergangen werden. 3. /**=https.. /** definiert das URL-Pattern (/** alle Files auf dieser Ebene, plus alle Unterverzeichnisse sind betroffen). Wird dieses URL-Pattern vom Browser aufgerufen, werden folgende Filter geladen: httpsessioncontextintegrationfilter, formauthenticationprocessingfilter, exceptiontranslationfilter, filtersecurityinterceptor 60

61 Kapitel 5. Acegi Security Listing 5.3: «applicationcontext.xml» 13 <!-- Start Security filter config --> 14 <bean id="exceptiontranslationfilter" 15 class="org.acegisecurity.ui.exceptiontranslationfilter"> 16 <property name="authenticationentrypoint"> 17 <ref bean="formloginauthenticationentrypoint" /> 18 </property> 19 </bean> Der ExceptionTranslationFilter kann jeden beliebigen Authentifikations- oder Autorisierungs- Error abfangen und folgende Aktionen auslösen: Wurde die Exception durch ein fehlendes Authentifikations-Objekt ausgelöst (der Benutzer ist noch nicht eingeloggt), wird der Benutzer auf die Login-Seite weitergeleitet.die Login-Seite wird im referenzierten formloginauthenticationentry- Point festgelegt. Wird die Exception im FilterSecurityInterceptor durch eine Authorisation Exception ausgelöst, sendet der ExceptionTranslationFilter eine SC_FORBIDDEN (HTTP 403) Error Page an den Browser. Listing 5.4: «applicationcontext.xml» 20 <!-- Define filter to handle BASIC authentication --> 21 <bean id="basicprocessingfilter" 22 class="org.acegisecurity.ui.basicauth.basicprocessingfilter"> 23 <property name="authenticationmanager"> 24 <ref bean="authenticationmanager" /> 25 </property> 26 <property name="authenticationentrypoint"> 27 <ref bean="authenticationentrypoint" /> 28 </property> 29 </bean> 31 Der BasicProcessingFilter verarbeitet die HTTP-Requests. Innerhalb des Beans wird eine Referenz auf den authenticationmanager angelegt. Listing 5.5: «applicationcontext.xml» 32 <!-- Define realm f o r BASIC login--> 33 <bean id="authenticationentrypoint" 34 class="org.acegisecurity.ui.basicauth.basicprocessingfilterentrypoint "> 35 <property name="realmname"> 36 <value>spring Web Realm</value> 37 </property> 38 </bean> <!-- Define filter to handle FORM authentication --> 41 <bean id="formauthenticationprocessingfilter" 42 class="org.acegisecurity.ui.webapp.authenticationprocessingfilter"> 43 <property name="filterprocessesurl"> 61

62 Kapitel 5. Acegi Security 44 <value>/j_acegi_security_check</value> 45 </property> 46 <property name="authenticationfailureurl"> 47 <value>/loginfailed.htm</value> 48 </property> 49 <property name="defaulttargeturl"> 50 <value>/</value> 51 </property> 52 <property name="authenticationmanager"> 53 <ref bean="authenticationmanager" /> 54 </property> </bean> Das formauthenticationprocessingfilter Bean definiert wie das Login-Formular verarbeitet werden soll. Zusätzlich kann man eine Fehlerseite definieren, die aufgerufen wird, wenn der Login-Prozess fehlgeschlagen ist. Mit dem authenticationmanager, der auf Zeile 70 definiert ist, wird ein Authentication Object erstellt, das die Authentifizierung durchführt. Abbildung 5.2.: Die Fehlerseite loginfailed.htm 57 Listing 5.6: «applicationcontext.xml» 58 <!-- Define realm f o r FORM login--> 59 <bean id="formloginauthenticationentrypoint" 60 class="org.acegisecurity.ui.webapp. AuthenticationProcessingFilterEntryPoint"> 61 <property name="loginformurl"> 62 <value>/login.jsp</value> 63 </property> 64 <property name="forcehttps"> 65 <value>false </value> 62

63 Kapitel 5. Acegi Security 66 </property> 67 </bean> Die im formloginauthenticationentrypoint Bean definierte loginformurl referenziert auf das Login-Formular. Ein Default-Standardformular sieht wie folgt aus: Listing 5.7: «applicationcontext.xml» 69 <form method="post" action="j_acegi_security_check"> 70 Username:<input 71 type="text" class="inputfield" name="j_username"><br><br> Password: 72 <input type="password" class="inputfield" name="j_password"><br> 73 <br><input type="submit" class="sendebutton" value="log in >>"> 74 </form> Das Login Form besteht nur aus den j_username und j_password Input Feldern. Der Actiontag ruft nach dem Absenden j_acegi_security_check auf. j_acegi_security_check wird im Bean formauthenticationprocessingfilter definiert und wird vom filterprocessesurl Filter verwendet. Das Login-Formular sieht folgendermassen aus: Abbildung 5.3.: Login-Formular 76 Listing 5.8: «applicationcontext.xml» 77 <bean id="httpsessioncontextintegrationfilter" 78 class="org.acegisecurity.context.httpsessioncontextintegrationfilter" > 63

64 Kapitel 5. Acegi Security 79 </bean> 80 <!-- End Security filter config --> Der HttpSessionContextIntegrationFilter ist verantwortlich das die 83 Kommunikation mit der User Session funktioniert und das die User 84 Authentication im ContextHolder gespeichert wird <!-- Start Security interceptor config --> 88 <!-- Define authentication manager, decision manager and secure URL patterns --> 89 <bean id="filtersecurityinterceptor" 90 class="org.acegisecurity.intercept.web.filtersecurityinterceptor"> 91 <property name="authenticationmanager"> 92 <ref bean="authenticationmanager" /> 93 </property> 94 <property name="accessdecisionmanager"> 95 <ref bean="accessdecisionmanager" /> 96 </property> 97 <property name="objectdefinitionsource"> 98 <value> 99 CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON 100 PATTERN_TYPE_APACHE_ANT 101 /app/**=role_user 102 /admin/**=role_admin 103 </value> 104 </property> 105 </bean> 106 <!-- End Security interceptor config --> Das filtersecurityinterceptor Bean hat folgende Aufgaben: Wir initialisieren einen AuthenticationManager. Ein AuthenticationManager verarbeitet die Authentifikationsprozesse. Es wird ein AccessDecisionManager initialisiert. Die objectdefinitionsource legt ein URL-Pattern fest, indem ein Bereich der Webseite nur bestimmten Usern zugänglich gemacht werden kann. Listing 5.9: «applicationcontext.xml» 107 <!-- Start authentication config --> 108 <bean id="authenticationmanager" 109 class="org.acegisecurity.providers.providermanager"> 110 <property name="providers"> 111 <list> 112 <ref bean="daoauthenticationprovider" /> 113 </list> 114 </property> 115 </bean> <bean id="daoauthenticationprovider" 118 class="org.acegisecurity.providers.dao.daoauthenticationprovider"> 64

65 Kapitel 5. Acegi Security 119 <property name="userdetailsservice"> 120 <ref bean="userdetailsservice" /> 121 </property> 122 </bean> <!-- Authentication using JDBC Dao --> 125 <bean id="userdetailsservice" 126 class="org.acegisecurity.userdetails.jdbc.jdbcdaoimpl"> 127 <property name="datasource"> 128 <ref bean="datasource"/> 129 </property> 130 </bean> <bean id="datasource" 133 class="org.springframework.jdbc.datasource.drivermanagerdatasource"> 134 <property name="driverclassname"> 135 <value>com.mysql.jdbc.driver</value> 136 </property> 137 <property name="url"> 138 <value>jdbc:mysql:// :3306/acegi</value> 139 </property> 140 <property name="username"> 141 <value>acegi</value> 142 </property> 143 <property name="password"> 144 <value>acegi</value> 145 </property> 146 </bean> Der authenticationmanager leitet alle Requests an eine Kette von AuthenticationProviderern weiter. In unserem Fall benützen wir den daoauthenticationprovider (Zeile 112). Der daoauthenticationprovider ist ein einfach zu verstehender Provider, der einen Benutzername und ein Passwort mit einem Repository abgleichen kann. Das Repository kann eine Datenbank oder ein XML sein. Wir haben uns entschieden, eine Datenbank zu verwenden. Daher müssen wir auf Zeile 127 einen userdetailsservice initialisieren, der die Klasse JdbcDaoImpl implementiert (Zeile 133). Die JdbcDaoImpl- Klasse referenziert wiederum auf ein datasource-objekt, das die Verbindungsparameter zur Datenbank enthält. Auf Zeile 142 laden wir den Treiber der Mysql-Datenbank. Bei Verwendung einer anderen Datenbank muss der entsprechende Treiber angegeben werden. Auf Zeile 140 und 143 geben wir noch den Benutzernamen und das Passwort mit, damit wir berechtigt sind, mit der Datenbank eine Verbindung aufzubauen. 65

66 Kapitel 5. Acegi Security Das Datenbankschema: Abbildung 5.4.: Login-SQL-Schema [6] Verwendet man das von Acegi Security vorgegebene Datenbankschema, kann der daoauthenticationprovider die SQL-Abfragen selber generieren. 147 <!-- End authentication config --> 148 Listing 5.10: «applicationcontext.xml» 149 <!-- Start authorization config --> 150 <bean id="accessdecisionmanager" 151 class="org.acegisecurity.vote.unanimousbased"> 152 <property name="decisionvoters"> 153 <list> 154 <ref bean="rolevoter" /> 155 </list> 156 </property> 157 </bean> <bean id="rolevoter" class="org.acegisecurity.vote.rolevoter"> 160 <property name="roleprefix"> 161 <value>role_</value> 162 </property> 163 </bean> Das AccessDecisionManager Bean auf Zeile 157 erhält die Benutzerinformationen und entscheidet, ob der Benutzer Zugang auf die Ressource erhält oder nicht. Der AccessDecisionManager benützt einen Voter, der herausfinden kann, ob der Benutzer autorisiert ist oder nicht. 66

67 Kapitel 5. Acegi Security 5.4. Integration in JSP Ein Vorteil von Acegi Security ist auch, dass man bestimmte Bereiche sichtbar bzw. unsichtbar machen kann, je nachdem welchen Rollenstatus der eingeloggte User (Admin, User) hat. Zum Beispiel wird in der «header.jsp» Datei der Administrator Button für Nicht-Administratoren deaktiviert. Listing 5.11: «applicationcontext.xml» 165 <authz:authorize ifallgranted="role_admin"> 166 <center> 167 <a href="../admin/userlist.html"><img src="images/admin.gif" border= 0 ></ a> 168 </center> 169 </authz:authorize> Die Acegi Security Tags auf Zeile 165 sorgen dafür, dass nur ein bestimmter, definierter Bereich gesichert wird. Das «admin.gif» ist also nur für die Benutzer sichtbar die den Rollenstatus ROLE_ADMIN besitzen. Abbildung 5.5.: Eingeloggt als Administrator 67

68 Kapitel 5. Acegi Security 5.5. Admin-Bereich Ist man als Administrator eingeloggt (ROLE_ADMIN), kann man über den Administrator- Button in den Admin-Bereich gelangen. Abbildung 5.6.: Administrator-Button zum Admin-Bereich Über den Admin-Bereich kann man auf der Datenbank Benutzer hinzufügen und wieder löschen. Zudem kann einem User eine Rolle und der Status zugewiesen werden. Abbildung 5.7.: Admin-Bereich 1. Der Username muss zwingend angegeben werden. Ohne Username kann kein neuer Benutzer erzeugt werden. 2. Das Passwort ist optional, sollte aber angegeben werden. 3. Über die Active Checkbox kann man Benutzer aktivieren oder deaktivieren. (Checked = Aktiv Unchecked = Inaktiv) 4. Bei der Rollenverteilung bedeutet: Access for Adminpage: Wenn diese Option gesetzt ist, kann man sich in den Admin-Bereich einloggen. Modifikationen sind möglich. Access for INDI WebClient: Wenn diese Option gesetzt ist, kann man sich in die INDI-WebClient-Oberfläche einloggen. Modifikationen sind möglich. User has restricted permissions: Wenn diese Option gesetzt ist kann man sich in die INDI-WebClient-Oberfläche einloggen. Modifikationen sind nicht möglich. 68

69 Kapitel 6. DIMM-Schnittstelle 6.1. Zweck der Schnittstelle Ziel der DIMM-Schnittstelle ist es, eine Möglichkeit zu schaffen, um binäre Bilddaten vom INDI-Server auf einen Webclient übertragen zu können. In unserem Fall verbindet diese Funktion die beiden Teilprojekte KWIRC und Differential Image Motion Monitor. Letzteres wird von Mitat Cingöz und Yves Rauser entwickelt BLOB-Übertragungsmechanismus Ein INDI-Server verfügt über einen Mechanismus, um eine Vielzahl binärer Daten- Streams zwischen Endgerät und Client auszutauschen. Ein Client hat eine Auswahl an Möglichkeiten, um den Server anzuweisen, wie BLOB-Daten empfangen werden sollen. Beim ersten Verbindungsaufbau ist der BLOB-Datenverkehr by default unterdrückt. Mit dem <enableblob>modus </enableblob> Tag kann der Client aber jederzeit den Server anweisen Daten auszuliefern werden. Dabei gibt es drei verschiedene Modi: Only - Es werden auf diesem Kanal nur noch BLOB-Daten übertragen. Also - Die BLOB-Daten werden mit den anderen Properties gemischt übertragen. Never - Keine BLOB-Datenübertragung. Die Daten werden vor der Übertragung auf dem INDI-Server mit Base64 codiert. Damit lassen sich Probleme beim XML-Parsen verhindern. Jedoch wächst so das Datenvolumen um rund ein Drittel an, da bei Base64 jeweils drei Bytes in vier abgelegt werden. Um die Datenmenge wieder zu reduzieren, kann vor dem Base64-Encoding mit ZLib die binäre Datei verkleinert werden. Die Hersteller des INDI-Clients schlagen drei bestimmte Formate für Bild und Videoübertragung vor. Diese werden praktisch von allen Clients unterstützt. Hier die Liste der möglichen Formatangaben eines BLOB aus dieser Kategorie: 69

70 Kapitel 6. DIMM-Schnittstelle.fits - Ein FITS (Flexible Image Transport System)- Datensatz. Ein FITS wird nicht fragmentiert, sondern am Stück übermittelt..fits.z - Ein FITS, welches zusätzlich mit zlib komprimiert worden ist..stream - Ein Live Video Stream. Wird bei der Übertragung in mehrere Teile fragmentiert..ccdpreview - Übermittelt einen CCD-Preview-Datensatz. Dieser wird fragmentiert übertragen Flexible Image Transport System FITS ist ursprünglich in den späten 70er-Jahren entwickelt worden. Es ist ein Archivierungsund Austauschformat für astronomische Daten. FITS ist daher mehr als bloss ein gewöhnliches Bildformat wie JPEG oder GIF. Es ist zusätzlich im Stande, wissenschaftliche Daten in zweidimensionalen Tabellen abzulegen. Ein FITS enthält ein oder mehrere Header und Data Units (HDU). Das erste HDU nennt man «Primary HDU», es enthält ein n-dimensionales array mit Bildpunkten wie 1-D Spektren, 2-D Bilder, 3-D Daten Cube. Dabei werden fünf verschiedene Datentypen unterstützt: unsigned 8-bit bytes, 16 und 32-bit signed integers, und 32/64-bit single oder double precision floating point reals. FITS kann auch 16 und 32-bit unsigned integers speichern. Jedes weitere zusätzliche HUD wird als «FITS extensions» bezeichnet. Es gibt davon drei Typen: Image Extension - n-dimensionales array mit Pixeln. ASCII Table Extension - Spalten und Zeilen mit Daten im ASCII-Format. Binary Table Extension - Spalten und Zeilen in binärem Datenformat. Jedes HUD verfügt über einen ASCII-formatierten «Header Unit», gefolgt von einem optionalen «Data Unit». [5] 1 1 Partielle Übersetzung von NASA - Overview of the FITS Data Format. 70

71 Kapitel 6. DIMM-Schnittstelle 6.4. Implementation für die Verarbeitung von FITS-Daten 6.5. Ziele Dem Benutzer des INDI-Web-Clients soll es möglich sein, FITS Bilder von einem Gerät abzurufen, um diese nach der Übertragung im Browser betrachten zu können. Die Bilddaten können im Browser auf verschiedene Arten abgerufen werden: Das Bild des primären HDU als JPEG im neuen Browser-Fenster. Das FITS kann in einem Applet geöffnet und professioneller betrachtet werden. Die FITS-Daten können auf der Festplatte abgelegt und in einem anderen Programm geöffnet werden Anpassung der BLOB-Visualisierung Für die Steuerung der Funktionen muss die Anzeige des BLOB-Elements auf der Webseite um einige Schaltflächen erweitert werden. Abbildung 6.1.: Die BLOB-Funktionen in der Übersicht 1. Anzeige des Property Typs Binary Large Object. 2. BLOB-Datenaustausch ein- und ausschalten. 3. Bild wird in JPEG konvertiert und in einem separaten Browser-Fenster angezeigt. 4. Ein empfangenes FITS wird mit einem Applet in einem separaten Browser-Fenster geöffnet. 5. Der BLOB-Datensatz kann über ein Browser-Fenster auf der Festplatte abgelegt werden. 71

72 Kapitel 6. DIMM-Schnittstelle 6.7. Implementation Im XML Parser werden in einem ersten Schritt die eintreffenden BLOB-Daten mit Base64 decodiert: 1 // Check on BLOB data format 2 i f (checkattribute(e, "format")){ 3 Listing 6.1: Decodieren der BLOBs mit Base64 4 // Set property busy 5 pobject.setpstate(lampstates.busy); 6 7 // Store datas into a single string 8 String b64data = e.getvalue().trim(); 9 10 // Decode with Base64 11 byte [] dataset = Base64.decode(b64data); Danach wird der Datentyp festgelegt und bei Bedarf eine Dekomprimierung vorgenommen. Die empfangenen Daten werden dann in einem byte in der jeweiligen Objekt- Instanz der BLOB-Properties abgelegt. Listing 6.2: Format feststellen und bei Bedarf dekomprimieren 1 i f (e.getattributevalue("format").equals(".fits")){ 2 3 // Set data format to FITS 4 bobject.setbdataformat("fits"); 5 6 i f (dataset!= null){ 7 8 // Store raw fits data to raw buffer 9 bobject.setbblobraw(dataset); } // Set property ok 14 pobject.setpstate(lampstates.ok); 15 } // Check on.fits.z format 18 else i f (e.getattributevalue("format").equals(".fits.z")){ // Set data format to FITS 21 bobject.setbdataformat("fits"); i f (dataset!= null){ // First decompress data set 26 byte [] decompresseddata = zipinflater.decompress(dataset, size); i f (decompresseddata!= null){ 72

73 Kapitel 6. DIMM-Schnittstelle // Store raw fits data to raw buffer 31 bobject.setbblobraw(decompresseddata); 32 } 33 } // Set property ok 36 pobject.setpstate(lampstates.ok); 37 } Für das Abrufen des Bildes als JPEG wurde ein neues Servlet mit der Bezeichnung «BLOBJpegPicture.java» (Kontext app/getjpeg) geschrieben. Dieses holt die Daten aus dem byte [] Puffer des BLOB-Property-Objekts und wandelt diese mit Hilfe der Methoden im FITS Applet der NASA in ein JPEG-Bild um. Listing 6.3: Das Servlet liefert ein JPEG-Bild an den Client zurück 1 i f (b.getbblobraw()!= null && b.getbdataformat().equals("fits")){ 2 t r y { 3 4 response.setheader("content-type","image/jpeg"); 5 OutputStream os = response.getoutputstream(); 6 os.write(fitsprocessor.processfits(b.getbblobraw())); 7 } catch (IOException e) { 8 // TODO Auto-generated catch block 9 e.printstacktrace(); 10 } 11 } Listing 6.4: Hier wird das FITS in ein JPEG umgewandelt 1 public byte[] processfits (byte [] rawdatas){ 2 3 t r y { 4 5 // Create ByteArrayInputStream of byte[]. 6 InputStream in = new ByteArrayInputStream(rawDatas); 7 8 // Generate InputStreamFitsFile. 9 InputStreamFitsFile isff = new InputStreamFitsFile(in); // Select HDU and get FitsData out of it 12 FitsHDU hdu = isff.gethdu(0); 13 //FitsHeader header = hdu.getheader(); 14 FitsData data = hdu.getdata(); // Generate a FitsImageViewer and RealImageProducer 17 FitsImageViewer fiv = new FitsImageViewer((FitsImageData) data); 18 FitsImageData fid = (FitsImageData) data; 19 RealImageProducer view = fid.createview(); 20 ColorModel cm = fiv.makecolormodel(color.black, Color.white); // Now generate a java image 23 ImageDigitizer digitizer = new ImageDigitizer(view, cm); 73

74 Kapitel 6. DIMM-Schnittstelle 24 digitizer.setimagesource(view); 25 Toolkit toolkit = fiv.gettoolkit(); 26 Image image = toolkit.createimage(digitizer); // Generate a buffered image 29 BufferedImage bimg = null; 30 i n t w = image.getwidth(null); 31 i n t h = image.getheight(null); 32 i n t [] pixels = new i n t [w * h]; 33 PixelGrabber pg = new PixelGrabber(image, 0, 0, w, h, pixels, 0, w); 34 t r y { 35 pg.grabpixels(); 36 } catch (InterruptedException ie) { 37 ie.printstacktrace(); 38 } 39 bimg = new BufferedImage(w, h, BufferedImage.TYPE_INT_RGB); 40 bimg.setrgb(0, 0, w, h, pixels, 0, w); // Prepare ByteArrayOutputStream. It will hold the JPEG image. 43 ByteArrayOutputStream outstream = new ByteArrayOutputStream(); // Encode to JPEG 46 JPEGImageEncoder jpeg = JPEGCodec.createJPEGEncoder(outStream); 47 JPEGEncodeParam param = jpeg.getdefaultjpegencodeparam(bimg); 48 i n t quality = 100; 49 quality = Math.max(0, Math.min(quality, 100)); 50 param.setquality(( f l o a t )quality / 100.0f, false); 51 jpeg.setjpegencodeparam(param); 52 jpeg.encode(bimg); // Save to byte array in BLOB object. 55 return outstream.tobytearray(); } catch (IOException exeption) { 58 // TODO Auto-generated catch block 59 exeption.printstacktrace(); 60 } 61 return null; 62 } Beim direkten Anzeigen des Bildes mit dem NASA Applet fits.jar wird in einem ersten Schritt mit dem Servlet «BLOBRawData.java» (Kontext app/getraw) eine kleine HTML-Seite generiert, welche das Applet ausführt und das FITS-Bild beim selben Servlet als binäre Datei abholt. Listing 6.5: Das Applet wird durch den generierten HTML-Code aufgerufen 1 <applet archive="fits1.3.jar" 2 code="eap.fitsbrowser.browserapplet.class" width="800" height="600"> 3 <param name="file" value="getraw?device=ccd%20simulator&pname=video&ename =CCD1"> 4 Your browser is ignoring the applet tag. 5 </ applet> 74

75 Kapitel 6. DIMM-Schnittstelle Listing 6.6: Die gewünschten binären Daten werden vom Servlet ausgegeben 1 if (b.getbblobraw()!= null){ 2 try { 3 response.setheader("content-type","application/blob"); 4 OutputStream os = response.getoutputstream(); 5 os.write(b.getbblobraw()); 6 os.flush(); 7 } catch (IOException e) { 8 // TODO Auto-generated catch block 9 e.printstacktrace(); 10 } 11 } Da beide Teilaufgaben im selben Servlet erledigt werden, muss beim Aufruf des Servlets der Parameter «action=callfitsapplet» mitgegeben werden, wenn das Applet ausgeführt werden soll. Bei der Funktion zum Speichern auf der Festplatte wird das selbe Servlet verwendet, der Parameter «action» wird dazu einfach weggelassen. Die Daten werden nun nicht in das Applet geladen, sondern direkt an den Browser geschickt. 75

76 Kapitel 7. XML-Abstraktion und XML-Verarbeitung 7.1. Das INDI-XML-Protokoll Der INDI-Server kommuniziert mit seinen Clients mit einer XML-artigen Struktur. Für jede Änderung wird eine Nachricht mit einem Datensatz verfasst und abgeschickt. Die XML-Datenstruktur ist im White Paper der INDI Library beschrieben INDI Properties Ein Property beschreibt eine spezielle Eigenschaft eines Geräts. Beim Austauschen von Informationen zwischen Server und Clients werden immer Properties angesprochen. Ein Property kann anhand folgender Merkmale eindeutig identifiziert werden: Propertyname (Attribut: name) Gerätezugehörigkeit (Attribut: device) Es gibt 5 verschiedene Property-Typen: Switch (Schalter) Text (Beliebige Zeichen) Number (Formatierte Zahl) Light (Lampe ok busy idle alert) BLOB (Binary Large OBjects) Properties können mehrere Elemente aufnehmen. Die Elemente werden dann zu einer Property-Gruppe zusammengefasst im GUI dargestellt und können sogar mit Regeln voneinander abhängig gemacht werden. Ein Element hat immer einen Wert der zum Property-Typ passt. 76

77 Kapitel 7. XML-Abstraktion und XML-Verarbeitung Attribute der Properties und Elemente Properties Device (Gerätezugehörigkeit) Name (Propertyname) Label (Bezeichner im GUI) Group (Gruppenzugehörigkeit) State (Statusanzeige des Property (ok idle busy alert)) Perm (Zugriffsregeln (ro wo rw)) Timeout (Gültigkeitsdauer) Timestamp (Zeitstempel der Erstellung) Message (Mitteilung an den Client) Elements Name (Elementname) Label (Bezeichner im GUI) Spezielle Attribute propertystate - Lampenanzeige (Idle = grau Ok = grün Busy=gelb Alert=rot) switchrule - Verhalten der Schalter in einer Property-Gruppe (OneOfMany At- MostOne AnyOfMany) propertyperm - Schreib und Leserechte für alle Benutzer (ro wo rw) (read only write only read and write) Lights können nur (Read-Only)Permissions haben. Text und Numbers können alle Permissions haben. Switches können nur (Read-Only) oder (Read-Write) haben. Die Switch-Rules sind wie folgt zu verstehen: OneOfMany - Nur ein Schalter aus vielen ist jeweils aktiv. AtMostOne - Nur ein Schalter aus vielen ist aktiv, oder keiner. AnyOfMany - Alle Schalter können aktiv oder inaktiv sein. 77

78 Kapitel 7. XML-Abstraktion und XML-Verarbeitung Definitionen der Properties (Server to Client) Beim ersten Verbindungsaufbau zum INDI-Server, muss jeder Client zuerst alle Properties abfragen. Dies geschieht mit folgendem Request: Listing 7.1: Mit dieser Anfrage schickt der INDI-Server alle Property-Definitionen 1 <getproperties version= 1.5 /> Der INDI-Server sendet dann eine Property nach der anderen an den anfragenden Client. Dieser muss die Properties dann aufbereiten, um ein passendes GUI anzeigen zu können. Die XML Tags für die Definition von Properties: deftextvector defnumbervector defswitchvector deflightvector defblobvector Für die Elemente: deftext defnumber defswitch deflight defblob Hier ein Beispiel: Listing 7.2: Definition einer Switch Property 1 <defswitchvector device="camera" name="binning" rule="oneofmany" 2 state="ok" perm="w" timeout="0" label="binning"> 3 <defswitch name="one" label="switch one">off</defswitch> 4 <defswitch name="two" label="switch two">on </defswitch> 5 <defswitch name="three" label="switch three">off</defswitch> 6 <defswitch name="four" label="switch four">off</defswitch> 7 </defswitchvector> Wie man erkennen kann besitzen das Property und die Elemente einige Attribute und die Elemente auch Werte. 78

79 Kapitel 7. XML-Abstraktion und XML-Verarbeitung Update der Properties (Server to Client) Wenn Werte sich verändern, müssen die verbundenen Clients darüber in Kenntnis gesetzt werden. Dies geschieht mit dem Update Tag <setxxx>: Die XML Tags für das Update von Properties: settextvector setnumbervector setswitchvector setlightvector setblobvector Für die Elemente: onetext onenumber oneswitch onelight oneblob Es werden immer alle Elemente des Property übermittelt: Listing 7.3: Definition einer Switch Property 1 <setswitchvector device="camera" name="binning" state="ok" 2 timestamp=" t16:04:02" message="binning changed to 1:1"> 3 <oneswitch name="two">off</oneswitch> 4 <oneswitchname="one">on"</oneswitch> 5 </setswitchvector> Update der Properties (Client to Server) Löst ein Benutzer auf seiner Oberfläche einen Event aus, so muss der Server davon in Kenntnis gesetzt werden. Dies geschieht mit dem Update Tag <newxxx>: Die XML Tags für das Update von Properties: newtextvector newnumbervector newswitchvector 79

80 Kapitel 7. XML-Abstraktion und XML-Verarbeitung newlightvector newblobvector Die Element Tags sind gleich wie bei der <setxxx> Anweisung Spezielle Befehle Eine Message wird entweder im Verbund mit einem Property Tag gesendet. Jedoch geht das auch direkt mit dem Message Tag: Listing 7.4: Das Versenden einer separaten Message 1 <message device="camera" timestamp=" :06:20" 2 message="tec is approaching target temperature"/> Auch für das Löschen eines Properties gibt es einen XML-Befehl: Listing 7.5: Löschen eines oder mehreren Properties 1 <delproperty device="camera" name="connect" timestamp=" :06:20" message="delete CONNECTION Property"/> Ohne Angabe eines Property-Namens müssen alle Property des gesamten Devices gelöscht werden. Listing 7.6: Ein- / Ausschalten von BLOBs 1 <enableblob device="camera" name="blobstream">only</enableblob> Standardmässig sind BLOB Properties ausgeschaltet (Never). Man kann sie bewusst einschalten. Man muss dann aber entscheiden, ob man die BLOB-Daten zusätzlich zu den anderen Informationen haben möchte (Also) oder nur noch die BLOB-Daten zugesandt werden sollen (Only). BLOB-Datensätze können von INDI wahlweise mit dem Base64 Algorithmus kodiert werden. BLOBs belasten das Netzwerk stärker als die restlichen Informationsträger der Library Abstraktionsprinzip Bei jedem Refreshrequest, Gruppen- oder Device-Wechsel auf dem User Interface im Browser jedes Web-Benutzers, werden etliche Informationen benötigt, um die Anzeige aufbauen zu können. Da die Daten vom INDI-Server fortlaufend in unserer Applikation eintreffen und sich mit der Zeit verändern, wäre es nicht sehr effizient, zur Ermittlung eines aktuellen Property-Attributs sämtliche Veränderungen anhand aller eingetroffenen Informationen zu rekonstruieren. 80

81 Kapitel 7. XML-Abstraktion und XML-Verarbeitung Es müssten ja alle XML Records dazu im Speicher gehalten werden. Aber was die Idee so unmöglich macht ist, dass alle XML-Daten zur Bestimmung eines Wertes immer und immer wieder geparst werden müssten. Eine bessere Lösung wäre ein zentrales, immer aktuelles XML-Dokument zu führen. Das wäre mit JDOM durchaus eine gangbare Lösung, da die Elemente als Objekte im Speicher angelegt werden. Auch von der Geschwindigkeit her wäre es denkbar, diese Variante anzuwenden. Schlussendlich haben wir uns aber entschieden, eine eigene Abstraktion in Klassen umzusetzen. Die Gründe, die dafür sprechen, sind: Sehr übersichtlich. Klassen und Variablen haben passende Namen. Attribute sind private Variablen. Mit «getter()» und «setter()» Methoden sind die Objekte als Bean nutzbar! Einfach zu verwalten, schnell im Zugriff, effizienter Parsingvorgang. Synchronisierte Zugriffe auf die Abstraktion einfach realisierbar. Vor allem die direkte Verwendung als Bean ist ein grosser Vorteil. Bei der JDOM-Variante hätte da ein Mapping mit Service-Klassen Abhilfe geschaffen Strukturierung der XML-Abstraktion Die Strukturierung der INDI-Komponenten, ist nach der selben Philosophie der Entwickler des Frameworks aufgebaut. So haben Property-Klassen die Möglichkeit, Element- Klassen in einer Liste zu verwalten. Es passiert also eigentlich genau das Umgekehrte wie auf dem INDI-Server. Dort sind die Daten nämlich erst strukturiert als Treiber im Speicher des Hosts abgebildet. Danach wird diese Information in XML umgewandelt. Der INDI-Client nimmt das XML entgegen und interpretiert dieses mit dem Parser. Dieser legt nun wieder ein Abbild der Struktur im Speicher an. Was unser Abbild den INDI-Treibern bei der Struktur voraus hat, ist die Möglichkeit, Klassen einsetzen zu können. So sind kleinere Optimierungen durch Vererbung möglich. Die ganzen Properties werden von der Klasse «XMLAbstraction.java» verwaltet. Dazu wird eine entsprechende «ArrayList» geführt. Die Klasse implementiert einen Singleton- Mechanismus, d.h. die Klasse sorgt dafür, dass nur eine einzige Instanz existieren kann. Somit gibt es also genau eine einzige, dafür aber zentral zugängliche Abstraktion. Die Struktur bleibt aber, wie es INDI vorsieht, hierarchisch. Zur Abfrage stehen einige spezielle Methoden in der Klasse «XMLAbstraction.java» zur Verfügung. Es gibt z.b. 81

82 Kapitel 7. XML-Abstraktion und XML-Verarbeitung eine Methode, die aus allen vorhandenen Properties die verschiedenen Devices eindeutig ermitteln kann. Andere Methoden benötigen zusätzlich Parameter um z.b. eine bestimmte Property lokalisieren zu können. Die Listen sind in den Verwalterklasse jeweils mit einem «synchronized» Mechanismus gegen konkurrenzierende Zugriffe geschützt. Das UML-Diagramm zeigt nun den Aufbau der Abstraktion: Abbildung 7.1.: UML der Abstraktionsklasse und den INDI-Komponenten 82

83 Kapitel 7. XML-Abstraktion und XML-Verarbeitung 7.4. Der XML Parser Im File «XMLParser.java» werden die XML-Daten des INDI-Servers analysiert und die Daten in die XML-Abstraktion überführt. Hier soll nun kurz gezeigt werden, wie der Parser aufgebaut ist. Von der «SocketConnection.java»-Klasse erhält der Parser jeweils den Aufruf einen XML String auszuwerten. Die XML-Daten enthalten pro Aufruf jeweils die Beschreibung genau eines Properties. Listing 7.7: Aufruf des Parsers - ein Property wird als XML String übergeben 1 // Parse Property 2 t h i s.indimain.getindixml().parsestring(xmldoc); Im Parser wird der String in einem ersten Schritt in ein verwertbares XML-Dokument übersetzt: Listing 7.8: Der XML String wird vom «SAXBuilder» interpretiert 1 public void parsestring(string xml) { 2 3 this.xmlstring = xml; 4 5 logger.debug(this.xmlstring); 6 7 this.builder = new SAXBuilder(); 8 9 t r y { 10 doc = t h i s.builder.build(new StringReader( t h i s.xmlstring)); } catch (JDOMException e) { e.printstacktrace(); 15 return; 16 } catch (IOException e) { e.printstacktrace(); 19 return; 20 } // XML parsen 23 parseproperties(); // Änderungen im Datensatz dem Ajax-Manager mitteilen 26 i f (this.propertieschanged){ 27 t h i s.indimain.getversionmanager().getversion("devicelist"). informationupdate(); 28 } this.doc = null; 31 this.builder = null; 32 } 83

84 Kapitel 7. XML-Abstraktion und XML-Verarbeitung Anschliessend erfolgt der Aufruf der Methode «parseproperties()» der «XMLParser»- Klasse. In dieser Methode wird der Property-Präfix ausgewertet. Dazu nochmal eine kleine Übersicht über die verschiedenen Präfixe: Präfix Beschrieb Im XML-Parser verwendet def Server definiert ein Property. ja set Server meldet eine Änderung in einem Property. ja new Ein Client meldet dem Server eine Änderung in einem nein Property. message Eine Systemnachricht vom Server. ja delproperty Server weist den Client an, ein Property zu löschen. Nicht implementiert Tabelle 7.1.: Die verwendeten Präfixe im XML-Parser 1 // Properety bearbeiten 2 Element p = (Element) l.get(i); 3 Listing 7.9: Auswertung der Property-Präfixe 4 // Server definiert neue Properties <defxxxxx..> 5 i f (p.getname().startswith("def")) { 6 7 addproperty(p); 8 } 9 // Server meldet Änderungen in einem Property <setxxxxx..> 10 else i f (p.getname().startswith("set")) { changeproperty(p); 13 } 14 // Server schickt eine Message <messagexxxxx..> 15 else i f (p.getname().startswith("message")) { addmessage(p.getattributevalue("timestamp").trim() + " : " + p. getattributevalue("message").trim()); 18 } 19 // Server will ein Property löschen <delpropertyxxxxx..> 20 else i f (p.getname().startswith("delproperty")) { // Currently not implementet 23 } Hier wird nun erstmals unterschieden, ob ein neues Property-Objekt angelegt werden muss (def) oder nicht (set). Je nachdem werden die Methoden «addproperty()» oder «changeproperty()» aufgerufen. Bei «addproperty» (Listing: 7.10) wird erst das neue Property erzeugt und danach die Methoden «setpropertyvalues()» und «parseelements()» aufgerufen, um die Elemente 84

85 Kapitel 7. XML-Abstraktion und XML-Verarbeitung und Parameter dem Property hinzuzufügen. Am Schluss wird das neue Property mit «addindiproperty()» bei der XML-Abstraktionsklasse angemeldet. Listing 7.10: Erstellen eines neuen Properties bei «def» Präfix 1 // Neues Property Objekt erzeugen 2 Property pobject = new Property(); 3 4 // Alle Werte setzen 5 setpropertyvalues (pobject, p); 6 7 // Alle Elemente dem Property hinzufügen. 8 parseelements(p, pobject); 9 10 // Property ablegen, falls noch nicht in der Liste vorhanden. 11 // Prüft auf Geräte, Gruppen und Propertyname 12 i f (! t h i s.abstraction.checkproprtyexist(pobject.getpdevice(), 13 pobject.getpname())){ t h i s.abstraction.addindiproperty(pobject); t h i s.propertieschanged = true; 18 } Bei der Methode «changeproperty()» gibt es nur einen kleinen Unterschied (Listing: 7.11). Hier wird kein neues Property angelegt, sondern das bestehende Property gesucht. Danach wird mit dem Property genau so verfahren, wie es bei «addproperty» beschrieben wird. Am Ende muss das Objekt jedoch nicht nochmal der XML-Abstraktion bekannt gemacht werden, da es ja schon in der Liste angemeldet ist. 1 // Property holen Listing 7.11: Abändern eines Properties bei «set» Präfix 2 Property pobject = t h i s.abstraction.getindiproperty(p.getattributevalue(" device"), p.getattributevalue("name")); 3 4 i f (pobject!= null){ 5 6 // Alle Werte setzen 7 setpropertyvalues (pobject, p); 8 9 // Elemente des Properties updaten. 10 parseelements(p, pobject); 11 } Auf diese Weise werden doppelte Einträge in der XML-Abstraktion verhindert. Das Gleiche gilt natürlich auch für das Einfüllen der INDI-Elemente in die Properties. Dort wird ebenfalls geprüft, ob bereits ein Element mit gleichem Namen existiert. Falls nicht wird ein neues erzeugt, ansonsten werden die Attribute des alten Elements aktualisiert und in der Liste belassen. Listing 7.12: Prüfung ob ein Element schon in der Property angemeldet worden ist 1 // Altes Element suchen 85

86 Kapitel 7. XML-Abstraktion und XML-Verarbeitung 2 Text tobject = (Text)pObject.getINDIElement(e.getAttributeValue("name")); 3 4 // Wenn nichts gefunden wird neues Objekt anlegen 5 i f (tobject == null){ 6 // Neues Text-Element erzeugen 7 tobject = new Text(); 8 // Text Element in Liste von Property Element einfügen 9 pobject.addindielement(tobject); 10 } Zum Schluss soll noch kurz auf darauf eingegangen werden, wie Messages verarbeitet werden. Messages gelangen auf zwei verschiedene Wege zum Client: Innerhalb eines Property-XML-Elements. In einem separaten Message-XML-Element. Beim Empfang einer Message wird diese als String in die Message-Liste in der XML- Abstraktion übertragen. Ausserdem wird der übermittelte Zeitstempel angehängt. Listing 7.13: Hinzufügen einer Message in die XML-Abstraktion 11 i f (checkattribute(p, "message")){ // Add message to message list 14 addmessage(p.getattributevalue("timestamp").trim() + " : " + p. getattributevalue("message").trim()); 15 } Die verwendeten Listen sind mit einem «synchronized»-mechanismus gegen konkurrenzierende Zugriffe geschützt. Dies ist nötig, da verschiedene Thread-Prozesse darauf zugreifen müssen Schnittstellen für MVC Services Die Daten in der XML-Abstraktion müssen für die Services der GUI-Anzeige nochmals speziell aufbereitet werden. Das liegt daran, dass für bestimmte Elemente auf der Seite ganz bestimmte gleichartige Informationen aus allen Properties benötigt werden. Um den Zugriff vereinfachen zu können, sind zu diesem Zweck einige Methoden erstellt worden. Diese könnten als Schnittstelle für die Services bezeichnet werden. Hier eine Übersicht dazu: 86

87 Kapitel 7. XML-Abstraktion und XML-Verarbeitung Methode Parameter Beschrieb getindiproperty getdevicenamelist getgroupnamelist getpropertylist checkpropertyexist propertyname (String) devicename (String) devicename (String) devicename (String) groupname devicename (String) propertyname (String) Holt ein einziges Property unter Angabe von Namen und Gerät aus der XML- Abstraktion. Liefert eine Liste aller Gerätenamen. Jedes Property kennt seine Gerätezugehörigkeit. Durch Herausfiltern aller verschiedenen Gerätenamen aus allen Properties wird die Liste zusammengestellt. Aus dieser Liste entsteht die Device-Liste auf dem Web- Interface. Liefert eine Liste aller Gruppennamen innerhalb einer Device-Gruppe. Im Gegensatz zur Device-Liste, wird die Gruppenliste nur aus den Properties einer abgegebenen Device-Gruppe zusammengestellt. Diese Liste wird verwendet, um die Web Tabs eines Geräts aufbauen zu können. Liefert eine Liste aller Devices einer bestimmten Gruppe unter Angabe von Gruppennamen und Device-Namen. Durch Auswerten all dieser Properties entsteht die Anzeige im Web-Tabarea. Prüft die Existenz eines bestimmten Properties. Diese Methode wird im XML- Parser verwendet, um zu prüfen, ob ein Property neu erstellt, oder bloss aktualisiert werden muss. Tabelle 7.2.: Die verwendeten Präfixe im XML-Parser 87

88 Kapitel 8. Das Web Interface - Design, Aufbau und Bedienung 8.1. Design Entwirft man ein Designkonzept für eine Webpage, so sollte man zuerst einmal wissen wer die eigentliche Zielgruppe ist. In unserem Fall sind es Techniker die keine grossen Wert auf Schnickschnack legen. Grosser grafischer Aufwand spricht also dagegen, schlichtes und technisches Aussehen eher dafür. Bei der Realisation wurden genau diese Punkte berücksichtigt. Auf grosse Grafiken wurde ebenfalls verzichtet, da man einen reaktionsschnellen Seitenaufbau bevorzugt. Um die Webseite trotzdem ansprechbar zu machen, wurde viel CSS eingesetzt. Das zentrale, ausgelagerte CSS File liegt im Verzeichniss «/css/indi.css», es enthält alle Formatierungen. Schauen wir uns die Formularfelder der Webseite genauer an: Formularfelder wurden dem übrigen Design angepasst, im indi.css wurde extra eine CSS-Klasse angelegt, in diesem Fall «.inputport» und «.inputhost». Listing 8.1: «/css/indi.css» 115.inputport 116 { 117 border: 1px solid; 118 background-color: #f5f5f5; 119 width:30px; 120 height:15px; 121 font-family: Arial, Helvetica, sans-serif; 88

89 Kapitel 8. Das Web Interface - Design, Aufbau und Bedienung 122 font-size: 10px; 123 } inputhost 126 { 127 border: 1px solid; 128 background-color: #f5f5f5; 129 width:70px; 130 height:15px; 131 font-family: Arial, Helvetica, sans-serif; 132 font-size: 10px; 133 } Es wurde grossen Wert auf die Browserkompatibilität gelegt, Internet Explorer ab der Version 5.5 und Firefox ab der Version 1.5 werden dabei vollumfänglich unterstützt Benutzerbedienbarkeit Abbildung 8.1.: Navigation Die Webseite wurde aus Benutzersicht so aufgebaut, dass sie einem gewissen Standard entspricht: Navigation auf der linken Seite, der Content ausgemittelt. Im Content- 89

90 Kapitel 8. Das Web Interface - Design, Aufbau und Bedienung Bereich wurden Tabs eingesetzt. Mit Tabs kann enorm viel Inhalt übersichtlich dargestellt werden. Die Gerätenavigationsleiste wurde gemäss Web-Standard auf der linken Seite platziert, Links werden in blauer Schrift und unterstrichen dargestellt. Abbildung 8.2.: Web Tabs Web Tabs eignen sich ideal, um den dynamischen Inhalt der Geräteeigenschaften anzuzeigen. Web Tabs sind praktisch und jedem Benutzer ein Begriff, da die in Standardsoftware oft eingesetzt werden Aufbau der Webseite Beim Aufbau der Webseite wurde grundsätzlich folgendes beachtet. Zur Darstellung der Elemente wurden Tabellen eingesetzt. Tabellen eignen sich besser als Layers, wenn die Elemente darin dynamisch generiert werden. Bei einer Bildschirmauflösung von 1024 * 768 soll auf der Startseite kein horizontales Scrolling nötig sein. 90

91 Kapitel 8. Das Web Interface - Design, Aufbau und Bedienung Alle Elemente werden zentriert (z.b. Haupttabelle) Das Gerüst bildet die Haupttabelle im File start.jsp. Die «css»-klasse die darauf zugreift, stellt die Tabellenränder mit einem dünnen Rand (1px solid) dar. Listing 8.2: Das Hauptgerüst befindet sich in der start.jsp 39 <table width="860" cellspacing="5" cellpadding="5" align="center" class="haupttable"> Innerhalb der Haupttabelle wurden fünf Sektoren unterteilt: Header, Footer, Div tabarea Content, Messagebox und Navigation. In jedem dieser Sektoren wird das entsprechende «.jsp»-file per Include eingelesen. Listing 8.3: Hier wird der header.jsp per include eingelesen 42 <jsp:include page="header.jsp" flush="true" /> Das Einlesen der Include-Dateien hat den Vorteil, dass der Quellcode übersichtlich und lesbar wird, da er ausgelagert wird. Zusätzlich können Modifikationen einfacher getätigt werden. Abbildung 8.3.: Aufteilung der Sektoren innerhalb der Hauptabelle 1. Header /header.jsp 91

92 Kapitel 8. Das Web Interface - Design, Aufbau und Bedienung 2. Navigation /navigation.jsp 3. Content wird als Div eingelesen tabarea 4. Messagebox /messagebox.jsp 5. Statusbar /statusbar.jsp 6. Footer /footer.jsp 8.4. Elemente der Webseite Im Server-Connection-Bereich, muss der Zielhost und der Port des INDI-Deamons angegeben werden. Mit dem «Connect»-Button wird die Verbindung aufgebaut, mit «Disconnect» wieder getrennt. Die Statusanzeige informiert über den Zustand des Verbindungsaufbaus. Nach dem Verbindungsaufbau erscheint die Navigationsliste der vorhandenen Geräte. Wenn nun ein Gerät aufgerufen wird, erscheint auf der rechten Seite eine Web Tabbar mit allen Property-Gruppen. Unterhalb werden die Elemente des ersten Tabs geladen. 92

93 Kapitel 8. Das Web Interface - Design, Aufbau und Bedienung Jede Gruppe enthält eine Reihe verschiedener Properties. Auf dem Bild ist ein Switch, Text und Number-Property abgebildet. Bei numerischen Properties kann mit der Maus auf dem Eingabefeld ermittelt werden, was die maximalen und minimalen Eingabewerte für das Feld sind. In der Messagebox erscheinen die Log-Meldungen des INDI-Servers. 93

94 Kapitel 9. Sichere Verbindung mit SSL 9.1. Einleitung Neben der Benutzerauthentifizierung soll ein sicherer Kommunikationskanal zwischen Client und Server erstellt werden. Sowohl Apache wie auch Tomcat unterstützen SSL SSL-Verschlüsselungübersicht SSL ist ein Verschlüsselungsprotokoll für Kommunikation im Internet. Mit SSL wird eine gesicherte Kommunikation zwischen Webserver und Browser ermöglicht. Alle Daten werden vor der Übertragung verschlüsselt und nach dem Empfang wieder entschlüsselt. Dabei werden symmetrische Schlüssel verwendet, welche aus Zertifikaten und privaten Schlüsseln mittels SSL-Handshake-Protokoll gesichert erzeugt werden Zertifikate Neben der Verschlüsselung ermöglicht SSL dank Zertifikaten auch eine Authentifizierung. Wird eine SSL verschlüsselte Webseite aufgerufen, welche Zertifikate benützt, die nicht durch eine Certificate Authority herausgegeben worden sind, so erscheint im Webbrowser die Nachfrage, ob das Zertifikat akzeptiert werden soll oder nicht. Auf öffentliche Zertifikate oder sog. Public Certificates kann frei zugegriffen werden, wohingegen private Schlüssel oder Private Keys gesichert aufbewahrt werden müssen. Dieses System basiert auf der mathematischen Beziehung (digitale Signatur) zwischen einem privaten Schlüssel und dem dazugehörigen öffentlichen Zertifikat. Aufgrund dieser Beziehung kann eine vertrauenswürdige Verbindung hergestellt werden. [7] Zertifikate können bei einer CA (Certificate Authority) erworben werden. 94

95 Kapitel 9. Sichere Verbindung mit SSL 9.2. OPEN SSL Das Kommandozeilentool OpenSSL ist eine Open-Source-Implementierung des Secure Sockets Layer (SSL v2/v3) und Transport Layer Security (TLS v1). Neben dem Erstellen von sicheren Verbindungen, z.b. über HTTPS, bietet OpenSLL weitere Funktionen wie das Erstellen von Schlüsseln und von X.509-Zertifikaten sowie deren Verwaltung. Darüber hinaus stellt OpenSSL eine grosse Anzahl weiterer kryptografischer Funktionen zur Verfügung, auf deren Funktionen hier nicht weiter eingegangen wird. Certificate Authority Client Server 4 Abbildung 9.1.: SSL-Funktionsübersicht 1. Die Certificate Authority muss beim Client Browser registriert werden. VeriSign, TC TrustCenter, Signtrust, TeleSec, Thawte etc.. sind bereits registriert, andernfalls muss die Verbindung bestätigt werden. 2. Der Server macht ein Certificate Request (server.csr) an die Certificate Authority. 3. Wird der Request mit dem CA-Passwort bestätigt, so wird ein Server Zertifikat (client.crt) herausgegeben. 4. Ruft ein Client den Server auf, so schickt der Server dem Client das Server-Zertifikat und baut eine verschlüsselte Verbindung auf. 95

96 Kapitel 9. Sichere Verbindung mit SSL X.509 X.509 ist ein ITU-T-Standard für digitale Zertifikate und Authentifizierungsdienste, aus dem Namen und digitale Signatur des Ausstellers hervorgehen. X.509 ist Teil des Verzeichnisdienstes X.500 für weltweite, verteilte und offene Systeme. X.509 unterstützt verschiedenste Protokolle zur Übertragung elektronischen Dateien und Mails und dient auch der Authentifizierung gegenüber Websites. Ein X.509 Zertifikat enthält das Ablaufdatum, die Seriennummer, die Certificate Authority, den Personen-, Server- und Domain-Namen, das verwendete Public-Key-Verfahren der öffentlichen Schlüssel und eine digitale Unterschrift. Certificate Authority Server Client 5 6 Abbildung 9.2.: SSL-Funktionsübersicht mit Client-Authentifikation 1. Der Server macht ein Certificate Request (server.csr) an die Certificate Authority. 2. Wird der Request mit dem CA-Passwort bestätigt, so wird ein Server-Zertifikat (server.crt) herausgegeben. 3. Der Client schickt ein Request File (client.csr) an die Certificate Authority. 96

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

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

Agenda. Ingo Ebel (ie007) Benjamin Müller (bm032) Was ist AJAX? Sicherheit Vor- und Nachteile. AJAX Frameworks. Wozu benötigt Client/Server

Agenda. Ingo Ebel (ie007) Benjamin Müller (bm032) Was ist AJAX? Sicherheit Vor- und Nachteile. AJAX Frameworks. Wozu benötigt Client/Server AJAX Agenda Ingo Ebel (ie007) Was ist AJAX? Wozu benötigt Client/Server Sicherheit Vor- und Nachteile Benjamin Müller (bm032) AJAX Frameworks GWT ATF Ingo Ebel - ie007 2 Web 2.0 Ingo Ebel - ie007 3 Ingo

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

Praktikum Spring MVC. 1.2. Spring integrieren In der pom.xml Einträge für Spring hinzufügen.

Praktikum Spring MVC. 1.2. Spring integrieren In der pom.xml Einträge für Spring hinzufügen. Praktikum Spring MVC Aufgabe 1 Im ersten Teil des Praktikums wird eine Test Webapplikation entwickelt, anhand derer einige Konzepte von Spring nachvollzogen werden können. Dabei handelt es sich um Spring

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

Um asynchrone Aufrufe zwischen Browser und Web Anwendung zu ermöglichen, die Ajax Hilfsmittel DWR ist gebraucht.

Um asynchrone Aufrufe zwischen Browser und Web Anwendung zu ermöglichen, die Ajax Hilfsmittel DWR ist gebraucht. Technisches Design Inhalt Design Übersicht Menü und DispatcherServlet DWR Servlet Viewer Servlets Controllers Managers Sicherheit Anwendung Architektur Component Diagram Deployment Diagram Komponente Sequence

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

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

Java zur Realisierung von Internetanwendungen

Java zur Realisierung von Internetanwendungen Java zur Realisierung von Internetanwendungen Elementare Web-Programmierung HTTP Web-Browser Web-Browser GET http://www.zw.fh-kl.de/beispiel.htm Beispiel Ein

Mehr

Netzwerk Technologien in LabVIEW

Netzwerk Technologien in LabVIEW Netzwerk Technologien in LabVIEW von Dirk Wieprecht NI Germany Hier sind wir: Agenda Agenda Bedeutung des Ethernet für die Messtechnik Ethernet-basierende Technologien in LabVIEW Low Level- TCP/IP Objekt

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

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

Web-Anwendungsentwicklung mit dem Delivery Server

Web-Anwendungsentwicklung mit dem Delivery Server Web-Anwendungsentwicklung mit dem Delivery Server Java-Framework auf Basis der Open API Bernfried Howe, Webertise Consulting GmbH WEBertise Consulting Dipl. Informatiker (Wirtschaftsinformatik) 2001-2010

Mehr

Inhalt: Konfiguration: web.xml ; server.xml Workflow: Weiterleitung von Requests Lektion II-IV Lektion V-VI

Inhalt: Konfiguration: web.xml ; server.xml Workflow: Weiterleitung von Requests Lektion II-IV Lektion V-VI Servlet II Inhalt: Konfiguration: web.xml ; server.xml Workflow: Weiterleitung von Requests Lektion II-IV Lektion V-VI 3-1 1. Grundlagen 2. Servlets 3. JSP 4 1.1. JAR Files 4 1.2. TCP/IP, Sockels 4 1.3.

Mehr

XPages Good to know. Benjamin Stein & Pierre Hein Stuttgart 7. Mai 2015

XPages Good to know. Benjamin Stein & Pierre Hein Stuttgart 7. Mai 2015 XPages Good to know Benjamin Stein & Pierre Hein Stuttgart 7. Mai 2015 Agenda 1. Einführung Was sind XPages? 2. Allgemeine Tipps Allgemeine Tipps für die Verwendung von XPages 3. Designer Tipps Tipps für

Mehr

AJAX. Autor: Othmane Mihfad omihfad@hotmail.com

AJAX. Autor: Othmane Mihfad omihfad@hotmail.com AJAX Autor: Othmane Mihfad omihfad@hotmail.com Was ist AJAX? Ajax ist die Abkürzung für: Asyncronous JavaScript And XML Ajax stellt eine Kombination aus mehreren Technologien da: Javascript XML und XMLHTTPRequest

Mehr

Einstieg in AJAX-Programmierung

Einstieg in AJAX-Programmierung www.happy-security.de präsentiert: Einstieg in AJAX-Programmierung Autor: Tsutomu Katsura Datum: 26. Mai 2006 Herzlich willkommen zu meinem kleinen Tutorial über AJAX-Programmierung. Ich möchte hier nicht

Mehr

Rechnernetze Projekt SS 2015

Rechnernetze Projekt SS 2015 30/03/15 Seite 1 Aspektorientierte Programmierung logische Aspekte (Concerns) im Programm separieren Crosscutting Concerns (Ziel: generische Funktionalitäten über mehrere Klassen hinweg zu verwenden -

Mehr

JSP Grundlagen. JEE Vorlesung Teil 5. Ralf Gitzel ralf_gitzel@hotmail.de

JSP Grundlagen. JEE Vorlesung Teil 5. Ralf Gitzel ralf_gitzel@hotmail.de JSP Grundlagen JEE Vorlesung Teil 5 Ralf Gitzel ralf_gitzel@hotmail.de 1 Übersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht JSP Konzept Model-View-Controller mit JSPs JSP Expression Language EL Literale

Mehr

Programmieren 2 (Prof. Hasbargen) Klausur

Programmieren 2 (Prof. Hasbargen) Klausur Programmieren 2 (Prof. Hasbargen) 1 Klausur Aufgabe 1 (10 Punkte) Dynamisierung von HTML-Seiten HTML-Seiten sind eine gängige Art und Weise, Informationen darzustellen. Nennen Sie die Gründe, welche Vorteile

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

AJAX SSL- Wizard Referenz

AJAX SSL- Wizard Referenz AJAX SSL- Wizard Referenz Version 1.0.2+ - 04.04.2011 Präambel Die vorliegende Dokumentation beschreibt den AJAX basierten SSL- Wizard der CertCenter AG. Der SSL- Wizard kann mit wenigen Handgriffen nahtlos

Mehr

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE

DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE DOKUMENTATION MAAS - MONITORING AS A SERVICE DRESDEN, 08.10.2009 CHRISTIAN.KNAUER@INF.TU-DRESEDEN.DE Dokumentation MaaS - Monitoring as a Service Inhalt 1. MaaS - Monitoring as Service... 3 1.1 Einleitung...

Mehr

php Hier soll ein Überblick über das Erstellen von php Programmen gegeben werden. Inhaltsverzeichnis 1.Überblick...2 2.Parameterübergabe...

php Hier soll ein Überblick über das Erstellen von php Programmen gegeben werden. Inhaltsverzeichnis 1.Überblick...2 2.Parameterübergabe... php Hier soll ein Überblick über das Erstellen von php Programmen gegeben werden. Inhaltsverzeichnis 1.Überblick...2 2.Parameterübergabe...7 3.Zugriff auf mysql Daten...11 Verteilte Systeme: php.sxw Prof.

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

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

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

Zugriff auf die Installation mit dem digitalstrom- Konfigurator mit PC und Mac

Zugriff auf die Installation mit dem digitalstrom- Konfigurator mit PC und Mac Zugriff auf die Installation mit dem digitalstrom- Konfigurator mit PC und Mac Zusatz zum digitalstrom Handbuch VIJ, aizo ag, 15. Februar 2012 Version 2.0 Seite 1/10 Zugriff auf die Installation mit dem

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

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

Call Button / HTTP - Systembeschreibung

Call Button / HTTP - Systembeschreibung Call Button / HTTP - Systembeschreibung Detlef Reil, 14.03.2004, zu Call Button, Version 040127, V1.50 Beta! Software System Für die Kommunikation zwischen den Call Buttons und der Applikation war bisher

Mehr

Java zur Realisierung von Internetanwendungen

Java zur Realisierung von Internetanwendungen Java zur Realisierung von Internetanwendungen MVC, JSP, Custom und Core Tags Darstellungsschicht Anwendungsschicht Datenschicht Architektur Browser Applikationsserver mit Servlet-Container DB-Server Web2-2

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

Die Cargo Plattform bietet einen sicheren und einfachen Datentransfer mit einem modernen Web- Interface.

Die Cargo Plattform bietet einen sicheren und einfachen Datentransfer mit einem modernen Web- Interface. Die Cargo Plattform bietet einen sicheren und einfachen Datentransfer mit einem modernen Web- Interface. Inhaltsverzeichnis Erste Schritte Anmelden 2 Startseite 3 Dateimanager 4 CargoLink 5 Freigaben 6

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

Elektronische Vollmachten - Demonstrator

Elektronische Vollmachten - Demonstrator www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Elektronische Vollmachten - Demonstrator Version 1.0.0, 09.01.2007 DI

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

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Softwareentwicklung mit JAVA EE

Softwareentwicklung mit JAVA EE Softwareentwicklung mit JAVA EE Beispiel Framework: Struts Was ist? Open Source Framework zum Bau von Web Applikationen Home Page http://jakarta.apache.org/struts Teil des Apache Jakarta Project Unterstützt

Mehr

Web-Services Implementierung

Web-Services Implementierung Web-Services Implementierung Praktikum Informationsintegration 8.11.2005 Agenda Aktueller Stand / Abgabe Implementierung Wie geht das mit Java und Tomcat? Service Client 2 Abgabe Teil 1 Ein paar Zahlen

Mehr

Schritt 4: Hallo Enterprise Bean

Schritt 4: Hallo Enterprise Bean Prof. Dr. Th. Letschert FB MNI JEE Schritt 4: Hallo Enterprise Bean Einstieg: EJBs erzeugen und nutzen Meine erstes EJB Projekt Enterprise Beans sind eine Backend Technologie, die mit unterschiedlichen

Mehr

G s e a s m a t m ar a ch c i h tek e tur u I und IoC

G s e a s m a t m ar a ch c i h tek e tur u I und IoC Gesamtarchitektur I und IoC Schichten einer Web-Anwendung Initiiert durch J2EE und Spring: Strukturierte Sicht auf UI und Fachlogik (Domäne) Ergibt 5 Schichten: Man unterscheidet Präsentations- und Domänenmodell!

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

Erfahrungen und Erkenntnisse. Klaus Richarz, HBT GmbH

Erfahrungen und Erkenntnisse. Klaus Richarz, HBT GmbH Erfahrungen und Erkenntnisse Klaus Richarz, HBT GmbH Java Enterprise Edition 5.0 JBoss Seam Konsequenzen für Realisierung Qualitätssicherung Build & Deployment Fazit & Empfehlungen JBoss Seam in Projekten,

Mehr

2. Interaktive Web Seiten. action in Formularen. Formular. Superglobale Variablen $ POST, $ GET und $ REQUEST. GET und POST

2. Interaktive Web Seiten. action in Formularen. Formular. Superglobale Variablen $ POST, $ GET und $ REQUEST. GET und POST 2. Interaktive Web Seiten GET und POST Die Übertragungsmethoden GET und POST sind im http Protokoll definiert: POST: gibt an, dass sich weitere Daten im Körper der übertragenen Nachricht befinden: z.b.

Mehr

SINT Rest App Documentation

SINT Rest App Documentation SINT Rest App Documentation Release 1.0 Florian Sachs September 04, 2015 Contents 1 Applikation 3 2 Rest Service 5 3 SOAP Service 7 4 Technologiestack 9 5 Deployment 11 6 Aufgabe 1: Google Webservice

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. Servlets Ein kleiner Einstieg. Kurze Java Historie. Erinnerung: Internet Anwendungen. Konzept eines Seitenaufrufs

4. Servlets Ein kleiner Einstieg. Kurze Java Historie. Erinnerung: Internet Anwendungen. Konzept eines Seitenaufrufs 4. s Ein kleiner Einstieg Erinnerung: HTTP und HTML Idee von Web n und Containern Erstellung einfacher s (zunächst software technisch übelst unstrukturiert) Literatur: B. Basham, K. Sierra, B. Bates, Head

Mehr

HVS32. ein Versandsystem das immer passt. Dokumentation. SAP-IDoc Schnittstelle

HVS32. ein Versandsystem das immer passt. Dokumentation. SAP-IDoc Schnittstelle ein Versandsystem das immer passt Dokumentation SAP-IDoc Schnittstelle Inhalt 1 HVS32 Anbindung an SAP mit IDocs...2 1.1 Integration...2 1.1.1 HVS32...2 1.1.2 HVS32-Gateway...2 1.2 Ablauf...3 2 IDoc Typen...4

Mehr

3 Anwendungsarchitektur und Entwicklungsumgebung

3 Anwendungsarchitektur und Entwicklungsumgebung 21 3 Anwendungsarchitektur und Bei den Entwicklern von Web-basierten Dialogsystemen hat sich im Laufe der Zeit eine Vorgehensweise im Design von Anwendungen entwickelt, dies es ermöglicht, flexible Web-Dialoge

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

Variablen manipulieren per JDI

Variablen manipulieren per JDI Variablen manipulieren per JDI Zusammenfassung Jede moderne Java IDE verfügt über eine mächtige und dennoch meist einfach zu bedienende Benutzeroberfläche die das finden von Fehlern in lokalen oder entfernt

Mehr

Apparo Fast Edit Datenmanagement mit der Standalone Version Technische Übersicht

Apparo Fast Edit Datenmanagement mit der Standalone Version Technische Übersicht Apparo Fast Edit Datenmanagement mit der Standalone Version Technische Übersicht 2 Apparo Fast Edit ist die das Standardprogramm für unternehmensweite Dateneingabe, mit der Sie Daten ändern, importieren

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

Sitzungszustand. Vorläufige Version 309 c 2005 Peter Thiemann

Sitzungszustand. Vorläufige Version 309 c 2005 Peter Thiemann Sitzungszustand Gruppierung von Anfragen zu Sitzungen (Sessions) Klasse HttpServletRequest Methode HttpSession getsession (bool create) liefert aktuelle Sitzungsobjekt Zustand lokal zur Anwendung (ServletContext)

Mehr

Anwendung eines Enterprise Java Beans

Anwendung eines Enterprise Java Beans Anwendung eines Enterprise Java Beans EJB Server EJB Container Remote Interface Home Interface EJB Object Der EJB Container kümmert sich um die Kommunikation des Beans mit anderen Komponenten, wobei er

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

PDF FormServer Quickstart

PDF FormServer Quickstart PDF FormServer Quickstart 1. Voraussetzungen Der PDF FormServer benötigt als Basis einen Computer mit den Betriebssystemen Windows 98SE, Windows NT, Windows 2000, Windows XP Pro, Windows 2000 Server oder

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

MOCCA. Installation und Konfiguration der Online-BKU

MOCCA. Installation und Konfiguration der Online-BKU www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria MOCCA Installation und Konfiguration der Online-BKU Change History V1.0

Mehr

LDAP für HiPath OpenOffice ME V1 Installation von ESTOS Metadir unter Windows XP

LDAP für HiPath OpenOffice ME V1 Installation von ESTOS Metadir unter Windows XP LDAP für HiPath OpenOffice ME V1 Installation von ESTOS Metadir unter Windows XP Inhaltsverzeichnis Dokumenteninformation... 2 Voraussetzungen... 2 Einschränkungen... 2 Installation von ESTOS Metadir...

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

Erweiterung für Premium Auszeichnung

Erweiterung für Premium Auszeichnung Anforderungen Beliebige Inhalte sollen im System als Premium Inhalt gekennzeichnet werden können Premium Inhalte sollen weiterhin für unberechtigte Benutzer sichtbar sein, allerdings nur ein bestimmter

Mehr

Eclipse Equinox als Basis für Smart Client Anwendungen. Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007

Eclipse Equinox als Basis für Smart Client Anwendungen. Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007 Eclipse Equinox als Basis für Smart Client Anwendungen Christian Campo, compeople AG, 5.7.2007 Java Forum Stuttgart 2007 Übersicht Definition / Architektur Smart Client Smart Client mit RCP / Equinox Gesamtfazit

Mehr

MVB3. Einrichten eines Servers für MVB3 ab Version 3.5. Admin-Dokumentation. Inhalt V3.05.001

MVB3. Einrichten eines Servers für MVB3 ab Version 3.5. Admin-Dokumentation. Inhalt V3.05.001 V3.05.001 MVB3 Admin-Dokumentation Einrichten eines Servers für MVB3 ab Version 3.5 Inhalt Organisatorische Voraussetzungen... 1 Technische Voraussetzungen... 1 Konfiguration des Servers... 1 1. Komponenten

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

Spring Surf Wiederkehr Patrick Consultant 25.1.2011

Spring Surf Wiederkehr Patrick Consultant 25.1.2011 Spring Surf Wiederkehr Patrick Consultant 25.1.2011 Inhaltsverzeichnis 1. Spring Surf von Alfresco... 3 1.1 Was ist Spring Surf und was kann es... 3 1.2 Was ist Spring Surf nicht... 3 2. Einführung Alfresco...

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

Java Servlet Technology

Java Servlet Technology 0 Java Servlet Technology Seminar Medientechnik Christina Eicher 30. Juni 2003 1 Übersicht: 1. Was ist ein Servlet? 2. Cookies und Sessions 3. Die Servlet-Klassen und das Servlet-Interface 4. Der Servlet-Container

Mehr

Collax Web Application

Collax Web Application Collax Web Application Howto In diesem Howto wird die Einrichtung des Collax Moduls Web Application auf einem Collax Platform Server anhand der LAMP Anwendung Joomla beschrieben. LAMP steht als Akronym

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

VWA Rhein-Neckar Dipl.-Ing. Thomas Kloepfer. Kommunikation I (Internet) Übung 4 PHP

VWA Rhein-Neckar Dipl.-Ing. Thomas Kloepfer. Kommunikation I (Internet) Übung 4 PHP VWA Rhein-Neckar Dipl.-Ing. Thomas Kloepfer Kommunikation I (Internet) Übung 4 PHP SS 2004 Inhaltsverzeichnis 1. PHP die serverseitige Programmiersprache...1 1.1. PHP - Bereiche in HTML definieren...1

Mehr

VMware Workspace Portal- Benutzerhandbuch

VMware Workspace Portal- Benutzerhandbuch VMware Workspace Portal- Benutzerhandbuch Workspace Portal 2.1 Dieses Dokument unterstützt die aufgeführten Produktversionen sowie alle folgenden Versionen, bis das Dokument durch eine neue Auflage ersetzt

Mehr

Glossarverwaltung GV3

Glossarverwaltung GV3 Glossarverwaltung GV3 Designbeschreibung VQWiki Leszek Kotas Sebastian Knappe Gerrit Mattausch Raimund Rönn 23. Mai 2004 Inhaltsverzeichnis 1 Allgemeines 3 1.1 Kurzcharakteristik.................................

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

CloudMatic V1.0. Inhalt

CloudMatic V1.0. Inhalt CloudMatic V1.0 Inhalt Einleitung... 2 CCUs hinzufügen... 3 meine-homematic.de... 4 Eigenes VPN... 4 View Editor... 5 Übersicht... 5 Allgemeine Einstellungen... 6 Kanäle hinzufügen... 6 Spezielle Kanäle...

Mehr

MGE Datenanbindung in GeoMedia

MGE Datenanbindung in GeoMedia TIPPS & TRICKS MGE Datenanbindung in GeoMedia 10. September 2002 / AHU INTERGRAPH (Schweiz) AG Neumattstrasse 24, CH 8953 Dietikon Tel: 043 322 46 46 Fax: 043 322 46 10 HOTLINE: Telefon: 043 322 46 00

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

Websockets: Leichtgewichtige Verbindungen für Web-Applikationen

Websockets: Leichtgewichtige Verbindungen für Web-Applikationen Websockets: Leichtgewichtige Verbindungen für Web-Applikationen Seite: 1 / 16 Über mich Stefan Neufeind Mit-Geschäftsführer der SpeedPartner GmbH aus Neuss ein Internet-Service-Provider (ISP) Individuelle

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

FH LU JEE Vorlesung SS 2010. Ralf Gitzel ralf_gitzel@hotmail.de

FH LU JEE Vorlesung SS 2010. Ralf Gitzel ralf_gitzel@hotmail.de FH LU JEE Vorlesung SS 2010 Ralf Gitzel ralf_gitzel@hotmail.de 1 Einführung + Organisatorisches Ralf Gitzel ralf_gitzel@hotmail.de 2 Dozent Dr. Ralf Gitzel Promotion an der Universität Mannheim in Wirtschaftsinformatik

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

In diesem Dokument wird Tomcat als Beispiel Servletengine und Apache als Beispiel Webserver verwendet.

In diesem Dokument wird Tomcat als Beispiel Servletengine und Apache als Beispiel Webserver verwendet. JArt Administration Installation Voraussetzungen: 1. Java Rutime Environment Version 1.4.2 oder höher 2. Java Servletengine (Tomcat wird empfohlen) (anbindung der Servletengine an Apache oder IIS empfohlen)

Mehr

Crashkurs http - CGI/Servlets(JSF) - Viewer

Crashkurs http - CGI/Servlets(JSF) - Viewer jkrueger(at)cebitec.uni-bielefeld.de http TCP Referenzmodell : ApplicationLayer zustandloses Protokoll textbasiert für Hypertext entwickelt ist es nicht darauf beschränkt Nachrichten : Request : Client

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

DOKUMENTATION. CaptchaAd mit Java. Die Schritte zur Integration des CaptchaAd-Modul im Einzelnen

DOKUMENTATION. CaptchaAd mit Java. Die Schritte zur Integration des CaptchaAd-Modul im Einzelnen CaptchaAd mit Java Stand: 26. Juli 2011 Sehr geehrter Nutzer von CaptchaAd! Damit die Integration von CaptchaAd Ihnen noch leichter fällt, haben wir die notwendigen Schritte in diesem Leitfaden zusammen

Mehr

Icinga Teil 2. Andreas Teuchert. 25. Juli 2014

Icinga Teil 2. Andreas Teuchert. 25. Juli 2014 Icinga Teil 2 Andreas Teuchert 25. Juli 2014 1 Nagios-Plugins Programme, die den Status von Diensten überprüfen können liegen in /usr/lib/nagios/plugins/ werden von Icinga aufgerufen, geben Status über

Mehr

E-Commerce: IT-Werkzeuge. Web-Programmierung. Kapitel 4: Einführung in JavaScript Stand: 03.11.2014. Übung WS 2014/2015. Benedikt Schumm M.Sc.

E-Commerce: IT-Werkzeuge. Web-Programmierung. Kapitel 4: Einführung in JavaScript Stand: 03.11.2014. Übung WS 2014/2015. Benedikt Schumm M.Sc. Übung WS 2014/2015 E-Commerce: IT-Werkzeuge Web-Programmierung Kapitel 4: Stand: 03.11.2014 Benedikt Schumm M.Sc. Lehrstuhl für ABWL und Wirtschaftsinformatik Katholische Universität Eichstätt-Ingolstadt

Mehr

Tomcat Konfiguration und Administration

Tomcat Konfiguration und Administration Tomcat Konfiguration und Administration Seminarunterlage Version: 8.01 Version 8.01 vom 4. Februar 2015 Dieses Dokument wird durch die veröffentlicht.. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

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

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

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

ORACLE Business Components for Java (BC4J) Marco Grawunder

ORACLE Business Components for Java (BC4J) Marco Grawunder ORACLE Business Components for Java (BC4J) Marco Grawunder Gliederung 2 Probleme von J2EE/EJB J2EE-Pattern Lösungsansatz: BC4J Architektur einer BC4J-Anwendung Komponenten Entity Objects View Objects Application

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

Anleitung: Notebook für den Betrieb in der DHBW einrichten und nutzen

Anleitung: Notebook für den Betrieb in der DHBW einrichten und nutzen Anleitung: Notebook für den Betrieb in der DHBW einrichten und nutzen 1 Inhaltsverzeichnis 1 Zugangsdaten an der DHBW... 3 2 OpenVPN Client installieren... 4 3 OpenVPN starten und mit dem Lehrenetz der

Mehr

Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen

Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen ewon - Technical Note Nr. 005 Version 1.3 Gateway für netzwerkfähige Komponenten ewon kann als Gateway für alle netzwerkfähigen Komponenten dienen 08.08.2006/SI Übersicht: 1. Thema 2. Benötigte Komponenten

Mehr