Reengineering einer Middleware (KOOP) für die transparenteund lose Kopplung von WebFrontends (CMS,...

Bachelorarbeit

Reengineering einer Middleware (KOOP) für die transparenteund lose Kopplung von WebFrontends (CMS, Extranet- undInternetanwendungen) mit Komponenten verschiedener java-basierter Anwendungsbackends

Zur Erlangung des akademischen Grades einesBachelor of Science- Bachelor Informatik -

Fakultät InformatikReferent: Prof. Dr. Oliver BraunKorreferent: Prof. Dr. Klaus Chantelau

eingereicht von:Nico PleyerMatr.-Nr. 280408Marienstraße 398693 Martinroda

Schmalkalden, den 14.12.2011

Abstract

Koop is a proprietary middleware, which was developed as a XML based commu-nication platform twelve years ago. This bachelor thesis decribes that middleware.By now Koop is a bit too old for just refactoring it. These days most of Koopswork could be done by standard technologies or frameworks. For that reason thisthesis should give an overview of possible options. The assembly of the middlewareand the lifecycle during requests will be analysed and decribed in the course of thisthesis. The aim is to establish technical requirements for a new approach. In con-sideration of these technical requirements current technologies will be contemplatedand evaluated. Furthermore a concept will be developed for the new approach. Thisconcept is described by the help of a technical prototype.

Zusammenfassung

Koop ist eine proprietäre Middleware, die vor zwölf Jahren für eine XML basierteKommunikation entwickelt wurde. Diese Arbeit beschäftigt sich mit der Analyse derMiddleware. Viele der Aufgaben von Koop werden heute bereits von Standardtech-nologien und Frameworks angeboten. Diese Arbeit gibt einen Überblick über einigeder verschiedenen Möglichkeiten, beim erstellen eines neuen Ansatzes. Es wird derAufbau der Middleware und die Abläufe, während einer Anfrage an das System,beschrieben. Ziel ist es, aus der Analyse resultierend, Anforderungen an einen neu-en Ansatz der Middleware zu erstellen. Unter Berücksichtigung der Anforderungenwerden aktuelle Technologien betrachtet und bewertet. Weiterhin wird ein Kon-zept für einen neuen Ansatz erarbeitet und anhand eines technischen Durchstichsbeschrieben.

Inhaltsverzeichnis

1 Einleitung 11.1 Die Anwendungen InetP und Koop . . . . . . . . . . . . . . . . . . . 11.2 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Analyse der Koop-Middleware 32.1 Aufbau des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Koop-Frontend . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Koop-Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Abläufe im System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Änderungsaufwände . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Spezifikation der Anforderungen 93.1 Beschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.2.1 Standardtechnologie . . . . . . . . . . . . . . . . . . . . . . . 93.2.2 Mandantenfähigkeit . . . . . . . . . . . . . . . . . . . . . . . . 93.2.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.4 Wartungsaufwand . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.5 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.6 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.7 Protokoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.8 Redaktionierbarkeit . . . . . . . . . . . . . . . . . . . . . . . . 103.2.9 Seitenaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.10 Sessionverknüpfung . . . . . . . . . . . . . . . . . . . . . . . . 113.2.11 JavaScript und AJAX Unterstützung . . . . . . . . . . . . . . 11

3.3 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Aktuelle Technologien 134.1 Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1.1 Apache Struts . . . . . . . . . . . . . . . . . . . . . . . . . . . 134.1.2 Google Web Toolkit . . . . . . . . . . . . . . . . . . . . . . . 134.1.3 JavaServer Faces 2.0 . . . . . . . . . . . . . . . . . . . . . . . 144.1.4 Java Portlets 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . 154.1.5 Java Architecture for XML Binding . . . . . . . . . . . . . . . 164.1.6 Java Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Bewertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Nico PleyerIV

Inhaltsverzeichnis Fachhochschule Schmalkalden WS 2011/12

5 Lösungsansätze 195.1 Verteilte Portlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.2 Eigenentwicklung von Tools . . . . . . . . . . . . . . . . . . . . . . . 205.3 Proxy-Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6 Beschreibung der Lösung 216.1 Voraussetzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216.2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.3.1 Frontendanwendung . . . . . . . . . . . . . . . . . . . . . . . 236.3.2 Backendanwendung . . . . . . . . . . . . . . . . . . . . . . . . 35

7 Zusammenfassung und Ausblick 38

Literaturverzeichnis 40

A Anhang 42A.1 Quelltext des ProxyServlet . . . . . . . . . . . . . . . . . . . . . . . . 42A.2 Beispiel einer Transport-XML . . . . . . . . . . . . . . . . . . . . . . 46A.3 Abbildungen der Backendanwendung . . . . . . . . . . . . . . . . . . 47A.4 Installation der Anwendungen . . . . . . . . . . . . . . . . . . . . . . 49

Eidesstattliche Erklärung 53

Nico PleyerV

1 EinleitungIn diesem Kapitel werden die Middleware Koop sowie die Anwendung InetP, im Um-feld dessen diese Arbeit entstand, vorgestellt. Weiterhin wird die Aufgabenstellungder Arbeit erläutert und auf die Motivation, die hinter dem Umbau der Middlewaresteht, eingegangen.

1.1 Die Anwendungen InetP und KoopDie Inverso GmbH ist ein im Jahr 1997 gegründetes Unternehmen und bietet alsSoftware- und Consultinghaus IT-Lösungen für Finanzdienstleister an. Die Ent-wicklung der Software-Lösungen erfolgt in verschiedenen Projekten. Diese Arbeitentstand im Rahmen des Projektes Internet für Privatkunden (InetP), einem Pro-jekt zur Implementierung, Weiterentwicklung und Wartung von Internetauftrittenfür Versicherungskunden. Den Kunden wird mit dem Onlineauftritt die Möglichkeitgeboten, Informationen zu Produkten und Ansprechpartnern abzurufen. Weiterhinkönnen Beiträge zu angebotenen Versicherungen berechnet sowie Schadens- oderÄnderungsmeldungen verschickt werden.1

Das Kooperationsmodell (Koop) ist eine Middleware und entstand als Teil des InetPvor etwa zwölf Jahren. Ziel war es, eine auf der Extensible Markup Language (XML)basierte Kommunikationsplattform zu schaffen. Über diese können Frontendsyste-me, wie ein Content Management System (CMS), unabhängig von ihrer gewähltenTechnologie, mit Backendsystemen verschiedener Ausprägung kommunizieren. Die-ser Ansatz ähnelt dem Simple Object Access Protocol (SOAP)-Standard und wurdeentwickelt, als es SOAP noch nicht gab.

Abbildung 1.1: Kommunikation zwischen Koop Front- und Backend,Quelle: eigene Darstellung

1Vgl. [Invc]

Nico Pleyer Seite 1 von 53

1. Einleitung Fachhochschule Schmalkalden WS 2011/12

Koop war ursprünglich dazu angedacht, unterschiedliche Front- und Backendsystemeverschiedener Versicherungsunternehmen miteinander zu verbinden. Derzeit werdeneinige unterschiedliche Anwendungen über Koop miteinander verbunden. Abbildung1.1 soll den dargestellten Sachverhalt verdeutlichen.Die Kommunikation zwischen den einzelnen Anwendungen, hier als APP darge-stellt, erfolgt ausschließlich über die Koop-Komponenten am jeweiligen Front- undBackendsystem. Durch die Verwendung von Koop ist es beispielsweise möglich, dassAPP1 auf seinen eigenen Backendservice zugreift aber auch auf den Service derAPP2.

1.2 AufgabenstellungDas Thema der Arbeit ist es, die bereits bestehende Middleware Koop zu analysie-ren sowie die Rahmenbedingungen zur Systemkopplung und den Entwicklungspro-zessen zu erfassen. Diese Rahmenbedingungen stellen Funktionen, Leistungen undverschiedene Kriterien des Systems dar. Des Weiteren sollen die Rahmenbedingun-gen bezüglich ihres aktuellen Bedarfs bewertet werden, um daraus Anforderungen aneinen neuen Ansatz zu erstellen. Weiterhin sollen aktuelle Technologien und Stan-dards betrachtet und hinsichtlich ihrer Einsetzbarkeit analysiert werden. Mit Hilfeder identifizierten Anforderungen und der Bewertung der Technologien soll ein Kon-zept erarbeitet werden, welches einen neuen Ansatz beschreibt. Auf der Grundlagedieses Konzeptes soll ein Prototyp, in Form eines technischen Durchstichs umgesetztwerden. Mit Hilfe dieser Arbeit soll ein Überblick über aktuelle Webtechnologiengeschaffen werden, um herauszufinden inwieweit es möglich ist, Koop oder einenKoop-ähnlichen Ansatz mit Standardtechnologien umzusetzen.

1.3 MotivationDie Hintergründe für den Umbau der Middleware sind sehr vielseitig. Zum einenist das System bereits relativ alt und greift somit kaum auf aktuelle Standardszurück. Weiterhin sind Arbeitsabläufe in der Wartung des Systems komplex undzum Teil sehr aufwändig. Koop ist formular- beziehungsweise seitenbasiert. DasZiel ist es mehr Interaktivität, zum Beispiel durch Asynchronous JavaScript andXML (AJAX), zu gewährleisten und weniger XML-Transformationen durchführenzu müssen. Zum anderen ist Koop eine Eigenentwicklung und bietet somit einigeVorteile, da es genau auf die benötigten Anforderungen abgestimmt ist. Diese Vor-teile gilt es herauszufinden und für einen neuen Ansatz zu berücksichtigen.Die Entwicklung von Features für die Middleware und die gesamte Anwendung InetPist sehr komplex und umständlich. Daher ist eines der Ziele, diese Software so um-zugestalten, dass Arbeitsabläufe vereinfacht werden. So soll schneller und besser aufKundenanfragen reagiert werden können. Koop wurde bisher wenig weiterentwickelt.Es ist daher nicht ohne weiteres möglich, moderne Konzepte der Softwareentwick-lung, aktuelle Webtechnologien oder Standards in der Entwicklung zu nutzen. Ausdiesen Gründen wird versucht, einen neuen Ansatz zu formulieren.


2 Analyse der Koop-MiddlewareDas folgende Kapitel stellt den Aufbau der ursprünglichen Koop-Middleware vor undbeschreibt die Abläufe während einer Anfrage an das System. Weiterhin werden dieAufwände vorgestellt, welche während Wartungsaufgaben entstehen können.

2.1 Aufbau des Systems

Abbildung 2.1: InetP Systemübersicht, Quelle: eigene Darstellung

Eine Koop-Anwendung besteht aus Frontend- und Backendsystemen, welche wieder-um aus verschiedenen Modulen aufgebaut sind. Diese Systeme werden im Folgendenals Koop-Frontend und Koop-Backend bezeichnet. Die Kommunikation zwischen denSystemen erfolgt über das Koop-Protokoll, dass inzwischen auf SOAP aufbaut. Fürden Datenaustausch wird ein XML-Format verwendet, welches im weiteren VerlaufKoop-XML genannt wird. Über dieses XML werden Informationen ausgetauscht, diefür den jeweiligen Dienst am Backend benötigt werden. Die Struktur des Koop-XMLund somit auch die Informationen die gesendet werden, wird durch einen Satz vonSchema-Definitionen festgelegt.Im Anhang befindet sich Listing A.3, welches ein Beispiel für das Koop-XML einerBegrüßungsseite, nach dem Einloggen des Nutzers darstellt. Dieses könnte als Ant-wort des Backends gesendet werden. Die Schema-Definition des Koop-XML enthältdie folgenden Elemente.


2. Analyse der Koop-Middleware Fachhochschule Schmalkalden WS 2011/12

SERVICE - Dieses Element ist ein eindeutiger Identifier, für die am Backend aus-zuführende Aktion. Der Wert des Elementes dient ebenfalls dazu die entspre-chende XML-Vorlage zu bestimmen.

ERROR - Zur Übertragung technischer Fehler auf Seiten des Backends kann diesesElement genutzt werden.

TRANSFORM_ID - Die Ergebnisdaten des Backends werden in einer passendenHTML-Seite angezeigt. Diese Seite wird per Extensible Stylesheet Language(XSL) und CMS-Templates erzeugt. Um die entsprechende XSL-Datei amFrontend auszuwählen, wird ein eindeutiger Bezeichner benötigt. Dieser wirdüber das Element TRANSFORM_ID übertragen und bereitgestellt.

PARAM - Falls benötigt, können über das Element PARAM noch weitere Steuer-parameter an das Backend gesendet werden. Hierfür stehen zum Beispiel diefolgenden Parameter zur Verfügung: AID, SECURETOKEN, SESSION_ID.

CONTENT - Das fachliche XML, also die befüllte XML-Vorlage, wird immer übereine CDATA-Sektion im Element CONTENT übertragen.

VU_SESSION_ID - In diesem Element wird die Nutzerabhängige SessionID über-tragen. Diese wird beim ersten Request vom Backend erzeugt und an dasFrontend gesendet. Bei weiteren Anfragen wird sie immer über dieses Elementmitgesendet.

USER_LEVEL - Für die Überprüfung von Berechtigungen eines Nutzers wird des-sen Anmeldestatus benötigt. Unter anderem sind folgende Userlevel bekannt:1 - für nicht angemeldete Nutzer2 - für angemeldete Nutzer.

Tabelle 2.1: Elemente des Koop-XML, Quelle: Vgl. [Invb, S. 49f.]

Wenn aus einem anderen Projekt oder Softwaresystem auf Koop-Backendserviceszugegriffen werden soll, muss in diesem Projekt eine eigene Koop-Komponente in-tegriert werden. Sobald diese Komponente implementiert ist, können die Dienstedes Koop-Backends genutzt werden. Abbildung 2.1 soll diesen Zusammenhang ver-deutlichen. Derzeit werden die Anwendungen Extranet und Wind über die Koop-Middleware angebunden.Die Anwendung Extranet ist ein Serviceportal für Geschäfts- und Vertriebspartnervon Versicherungsunternehmen. Extranet bindet einige Tarifrechner zur Berechnungvon angebotenen Versicherungen, über Koop an. Wind hingegen ist ein Unwetter-warnservice. Kunden erhalten Informationen zum Wetter für einen, von ihnen be-stimmten, Postleitzahl-Bereich.2

In den folgenden Abschnitten wird der Aufbau der einzelnen Komponenten nähererläutert.

2Vgl. [Invc]



2.1.1 Koop-Frontend

Das Koop-Frontend baut auf dem Interceptor-Entwurfsmuster auf. Dieses Musterermöglicht eine einfache Konfiguration und Erweiterung der Software, ohne größereÄnderungen am System selbst durchführen zu müssen. In Abbildung 2.2 wird derAufbau des Koop-Frontends dargestellt.

Abbildung 2.2: Aufbau des Koop-Frontends, Quelle: eigene Darstellung

Das Modul KoopService vermittelt zwischen der Interceptor-Chain und dem CMS-Modul am Koop-Frontend.Die Interceptor-Chain ist aus mehreren Interceptoren zusammengesetzt. Diese wer-den nacheinander abgearbeitet. Die Interceptoren ExceptionInterceptor und Session-Interceptor sind für das Exception- beziehungsweise das Sessionhandling einer An-frage zuständig. Der Unmarshaller ist für das Lesen eines Requests verantwortlich,wohingegen der Marshaller ein Response-Objekt schreibt. Der DispatchInterceptorstößt die eigentliche Verarbeitung einer Anfrage an. Die Verarbeitung der Request-beziehungsweise Response-Daten sowie des Koop-XML wird dann durch den Trans-formInterceptor ausgeführt. Der letzte Interceptor in der Verarbeitungskette, derRequest-Interceptor, leitet die Anfrage an das Modul RequestDelegate weiter.RequestDelegate baut wiederum eine Verbindung über das Hypertext Transfer Protocol(HTTP) zum geforderten Backendservice auf und verpackt die Anfrage in ein SOAP-Objekt. Die Verbindung über HTTP aufzubauen ist nur eine mögliche Variante. Wei-tere Möglichkeiten sind der Verbindungsaufbau über den Java Message Service oderMQSeries. RequestDelegate nimmt weiterhin die Antwortdaten des Backends entge-gen und reicht diese in umgekehrter Reihenfolge wieder durch die Interceptor-Chain.Dabei werden die Antwortdaten wieder aufbereitet, geprüft und die geforderte Seite,aus XSL- und CMS-Templates aufgebaut.

2.1.2 Koop-Backend

Das Koop-Backend kann in den ProtokollHandler, RequestDispatcher, Datenkon-verter und das Command-Framework unterteilt werden. Abbildung 2.3 zeigt den



Abbildung 2.3: Aufbau des Koop-Backends, Quelle: Vgl. [Inva, S. 22]

Aufbau des Koop-Backends.Der ProtokollHandler nimmt Anfragen des Frontends, in Form des Koop-XML ent-gegen und wertet diese aus. Weiterhin wird aus der Koop-spezifischen Anfrage einProtokollneutraler Request erzeugt, um somit die Verwendung verschiedener Pro-tokolle zu gewährleisten. Außerdem nimmt er das Response-Objekt des RequestDis-patcher entgegen und erzeugt daraus die Koop-XML-Antwort.Die Abarbeitung der Anfrage führt der RequestDispatcher aus. Er ermittelt denangeforderten Service, ruft den Datenkonverter auf und stößt das Bearbeiten desKommandos an.Der Datenkonverter wandelt die Daten aus der Koop-XML-Struktur in ein Business-Objekt um, so dass diese von den entsprechenden Kommandos benutzt werden kön-nen. Er konvertiert ebenfalls die Antwortdaten in das Koop-XML-Format zurück.Das Command-Framework stellt die Geschäftslogik des Systems dar. Jedes Kom-mando steht für einen Use Case, der am Frontend angestoßen wurde. Diese Aktionenkönnen zum Beispiel Tarifberechnungen, Anmeldungen im Kundenbereich oder dasSenden allgemeiner Meldungen sein. Die einzelnen Kommandos werden über eineneindeutigen Identifizierer, der ServiceID, bestimmt und erkannt.3

2.2 Abläufe im SystemDas Koop-Frontend empfängt eingehende Anfragen des Nutzers und wandelt diesein das Koop-XML-Format um. Anschließend wird das Koop-XML an die Transport-schicht übergeben. Am Backendsystem, der jeweiligen Fachanwendung, wird dieAnfrage verarbeitet und zurück an das Koop-Frontend gesendet. Die XML-Antwortwird aus der Transportschicht entnommen und dem Nutzer präsentiert. Um dieAbläufe im Detail besser nachvollziehen zu können, werden diese anhand eines Bei-spiels genauer beschrieben. Als Beispiel dient das Berechnen eines Tarifes für eineangebotene Versicherung.

3Vgl. [Inva, S. 22f.]



Für die Berechnung eines Tarifes sind verschiedene Nutzereingaben erforderlich. Die-se werden über ein Hypertext Markup Language (HTML)-Formular erfasst. Nachdem Absenden der Anfrage, zum Beispiel durch den Klick auf einen Berechnen-Button, liest das Koop-Frontend den Request. Dabei wird geprüft, welcher Serviceam Backend ausgeführt werden soll. Hierfür dient die Datei Service.xml. Sie defi-nert alle vom Backend angebotenen Dienste. Diese sind in Form eines eindeutigenIdentifizierers, der ServiceID, festgelegt und in den HTML-Formularen, für jede Ak-tion hinterlegt. Ist der Service registriert, wird die Anfrage als Koop-XML an dasBackend gesendet, andernfalls wird ein technischer Fehler ausgegeben. Sobald dasKoop-Backend die Anfrage erhalten hat, wird auch hier der Service ermittelt. Fürdiesen wird nun ein Konverter gewählt, mit dessen Hilfe das Koop-XML in ein Java-Objekt konvertiert wird. Im Anschluss daran wird das Kommando beziehungsweisedie Aktion ausgeführt. Diese gibt eine TransformID zurück. Mit Hilfe der Transfor-mID wird wieder ein Konverter gewählt, welcher die Ergebnisdaten in das Koop-XML-Format konvertiert. Welche Konverter für die jeweiligen IDs zu wählen sind,wird in der Datei mapping.xml definiert. Das erzeugte Koop-XML wird nun zurückan das Koop-Frontend gesendet. Hier wird die Zielseite, für die Ausgabe, bestimmtund samt Inhalt angezeigt. Die Seite setzt sich aus dem Koop-XML und einemXSL-Template zusammen, welches über die TransformID bestimmt wird. Das Map-ping einer TransformID zu einem XSL-Template wird in der Datei Transform.xmlfestgelegt. Abbildung 2.4 stellt diese Abläufe dar.

Abbildung 2.4: Ablauf einer Anfrage, Quelle: eigene Darstellung

Während einer Anfrage werden ebenfalls Sessiondaten erzeugt und zwischen Koop-Frontend und -Backend ausgetauscht. So sind die verschiedenen Systeme immer überden Status eines Nutzers informiert und können eine Session am Frontend mit der amBackend verknüpfen. Dieses Verhalten ist notwendig, um zum Beispiel Antwortdatenden jeweiligen Nutzer zuordnen zu können. Die erzeugten Daten werden weiterhinfür die Navigationssteuerung genutzt. Über sie wird festgestellt, ob ein Nutzer be-stimmte Seiten sehen kann und welche Seite auf eine Anfrage hin angezeigt werdensoll.



2.3 ÄnderungsaufwändeDie Wartung des Systems besteht zu großen Teilen aus Änderungen und Anpassun-gen an der Nutzeroberfläche sowie dem Aktivieren und Deaktivieren von Funktionen.Diese Aufgaben können sehr fehleranfällig sein. Dienste beziehungsweise Funktionenwerden in XML- und Properties-Dateien festgelegt und konfiguriert. Die Elementeeiner anzuzeigenden Seite werden als XSL-Templates definiert und am Frontend mitden entsprechenden Inhalten befüllt.Fehleranfällig sind diese Aufgaben deshalb, weil die verschiedenen Konfigurations-dateien stark miteinander verbunden sind. Die Anpassungen müssen demnach nichtnur an einer Stelle umgesetzt werden. Das folgende Beispiel soll zeigen, welche Ar-beitsschritte notwendig sind um ein neues Element, etwa eine Auswahlliste, in eineSeite einzubetten. Diese Schritte müssen durchgeführt werden, um die Änderungenauf einem Entwicklersystem anzupassen und anschließend auf einem lokalen Anwen-dungsserver zu veröffentlichen.

• Hinzufügen des Elementes zur XSL-Datei• die Schema-Definition des Koop-XML anpassen• die Vorlage des Koop-XML anpassen• mit Hilfe des Datenkonverters die zu der Vorlage des Koop-XML passenden

Java-Klassen neu generieren• die generierten Vorlagen an die korrekte Stelle der Projekthierarchie kopieren• die XSL-Datei und XML-Vorlage im CMS veröffentlichen• das CMS aktualisieren• eventuelle Anpassung des Datenbankmapping, falls das Element einen Daten-

bankzugriff benötigt• den Anwendungsserver neustarten

Dieses Beispiel zeigt, wie umfangreich eine relativ simple Änderung der Oberflächewerden kann. Wird der Anwendung neue Funktionalität hinzugefügt, müssen weiter-hin einige der XML-Konfigurationsdateien angepasst werden. Diese Arbeitsschrittesind fehleranfällig und gehören zu den Aufgaben, die am häufigsten durchgeführtwerden müssen. Aus diesem und einigen weiteren Gründen soll ein Umbau der Koop-Middleware initiiert werden. Hierdurch soll eine bessere Wartbarkeit der gesamtenInetP-Anwendung entstehen und Abläufe in der Weiterentwicklung verbessert wer-den.


3 Spezifikation der AnforderungenDieses Kapitel beschreibt die Zielsetzungen für einen neuen Ansatz der MiddlewareKoop anhand der gestellten Aufgabe. Weiterhin werden die einzelnen Anforderungendefiniert und bezüglich ihres aktuellen Bedarfs bewertet.

3.1 BeschreibungDie erstellten Anforderungen beschreiben Funktionen, die der neue Ansatz erfüllensollte. Diese sind allerdings eher Richtlinien und müssen nicht alle zwingend vondiesem Ansatz unterstützt werden. Es wäre jedoch von Vorteil, die Anforderungenmit einer Wichtung der Stufe drei zu erfüllen.Die Anforderungen beruhen auf Funktionen, welche im jetzigen System angebotenund unterstützt werden. Eine Bewertung nach Prioritäten erfolgte durch das Ent-wicklerteam des InetP-Projektes.

3.2 AnforderungenIn den folgenden Unterpunkten werden die identifizierten Anforderungen ausführli-cher betrachtet und dargelegt. Diese Anforderungen wurden während der Analyseder Koop-Middleware formuliert.

3.2.1 Standardtechnologie

Bei der Entwicklung des neuen Systems sollte nach Möglichkeit auf Standardtech-nologien zurückgegriffen werden. Diese können Technologien sein, die zum Beispielin einem Java Specification Request (JSR), durch den Java Community Processbeschrieben sind. Auf Standards und Spezifikationen anderer anerkannter Organi-sationen kann ebenfalls zurückgegriffen werden.

3.2.2 Mandantenfähigkeit

Das System soll die Möglichkeit bieten, neue Mandanten beziehungsweise Koop-Klienten in das System aufzunehmen. Hierbei sollte es möglich sein, die Klientenohne zu großen Programmier- und Konfigurationsaufwand anzubinden.


3. Spezifikation der Anforderungen Fachhochschule Schmalkalden WS 2011/12

3.2.3 Performance

Die Performance des neuen Systems sollte sich nicht verschlechtern. Aus der Ver-wendung neuer Webtechnologien sollte sich möglichst eine Verbesserung der Ar-beitsleistung ergeben. Weiterhin soll der Overhead beim Datenaustausch zwischenKoop-Frontend und -Backend so gering wie möglich gehalten werden.

3.2.4 Wartungsaufwand

Der Wartungsaufwand soll so gering wie möglich gehalten werden. Das heißt, dassÄnderungen am System einen minimalen Aufwand verursachen. Werden neue Mo-dule für das System entwickelt, sollten sich diese ebenso einfach integrieren lassen.Dabei sollten keine großen Änderungen am System selbst benötigen werden.

3.2.5 Sicherheit

Das Backend soll aus dem Internet für den Endkunden nicht direkt erreichbar sein.Weiterhin soll die Möglichkeit bestehen, Nutzer in Gruppen oder Userlevel eintei-len zu können. Die Navigation am Frontend soll in Abhängigkeit des Userlevel amBackend gesteuert werden können. Des Weiteren sollte es einfach möglich sein, dieEingabedaten des Nutzers zu Validieren und zu Plausibilisieren. Außerdem ist einedirekte Unterstützung zur Testintegration und Fehlersuche wünschenswert.

3.2.6 Konfiguration

Der Konfigurationsaufwand sollte so gering wie möglich gehalten werden. Dennochsollte es möglich sein, in Abläufe beziehungsweise Prozesse einzugreifen, ohne An-passungen am Code durchführen zu müssen. Weiterhin sollten die Abläufe einfach zukonfigurieren sowie das Datenmapping zur Oberfläche so einfach wie möglich gehal-ten werden. Änderungen an der Nutzeroberfläche sollten ebenfalls geringe Aufwändeverursachen.

3.2.7 Protokoll

Das Protokoll für den Informationsaustausch zwischen Koop-Frontend und -Backendsollte wählbar und nach Möglichkeit austauschbar sein.

3.2.8 Redaktionierbarkeit

Das System sollte die Möglichkeit zur Verfügung stellen, einfache Änderungen wieTextanpassungen, ohne ein Deployment am Koop-Frontend durchzuführen. Weiter-hin sollte die Möglichkeit geboten werden, die Nutzeroberfläche durch Templatesaufzubauen und zu gestalten. Die Nutzeroberfläche sollte ein einheitliches und mo-dernes Look & Feel ermöglichen.



3.2.9 Seitenaufbau

Die Seiten sollten nicht bei jedem Request komplett neu aufgebaut werden. Das Sy-stem sollte die Möglichkeit zur Verfügung stellen, Teile beziehungsweise Fragmenteeiner Seite einzeln zu laden und zu rendern. Des Weiteren sollte die Navigation überdie Browserfunktionen berücksichtigt werden. Die Seiten sollen, nach Möglichkeit,im Backend definiert und im Frontend, aus den vorhandenen Templates, zusammen-gebaut werden.

3.2.10 Sessionverknüpfung

Die Session im Koop-Frontend soll mit der Session im Backend verbunden werdenkönnen, so dass diese synchron laufen und zum Beispiel immer über den aktuellenStatus eines Nutzers informiert sind. Weiterhin sollte die Anwendung möglichst nurüber eine Domain erreichbar sein, trotz verschiedener Backendanwendungen.

3.2.11 JavaScript und AJAX Unterstützung

Die Unterstützung von AJAX soll nach Möglichkeit gegeben sein. Die Anwendungsollte aber auch ohne aktiviertes JavaScript im Browser ausführbar sein.

3.3 BewertungAus Entwicklersicht sind die Punkte zur Mandantenfähigkeit, Redaktionierbarkeitsowie alle Punkte die Konfigurations- und Wartungsaufwand betreffen am wichtig-sten. Durch diese Anforderungen sollen die Prozesse in der Weiterentwicklung undWartung des Systems vereinfacht werden. Fehleranfällige Arbeitsabläufe sollten so-mit vermieden werden.Aus Sicht der Kunden sind die Punkte zur Sicherheit, Performance, Standardtech-nologie und ebenfalls die Punkte zu anfallenden Wartungsaufwand sehr interessant.Weiterhin sind Standardtechnologien bevorzugt, da diese meist einen guten undlangfristigen Support bieten. Punkte zum Thema Sicherheit und Performance neh-men aber sicher die höchsten Prioritäten ein.Die folgende Tabelle 3.1 bewertet die Anforderungen anhand ihrer Wichtigkeit. An-forderungen mit der Wichtung drei nehmen die höchste Priorität ein und sollten vonder entsprechenden Lösung unterstützt werden. Die Anforderungen mit der Wich-tung eins sind nicht zwingend erforderlich.



Kriterium Erläuterung StufeMandantenfähigkeit Können neue Mandanten einfach angebunden

werden?3

KonfigurationWie hoch ist der Konfigurationsaufwand? 3Wie einfach ist das Datenmapping? 3Können Arbeitsabläufe ohne Anpassungen amCode geändert werden?

3

Sessionverknüpfung Kann die Session von Front- und Backend ver-bunden werden?

3

Ist die Anwendung über eine Domain erreichbar? 3AJAX Wird AJAX von der Technologie unterstützt? 3Redaktionierbarkeit Wird ein einheitliches Look & Feel durch Tem-

plating ermöglicht?3

Standardtechnologie Basiert die Technologie auf anerkannten Stan-dards?

2

Wie gut ist die Toolunterstützung? 2

Performance Wie performant ist die Technologie? 2Wie aufwändig/komplex ist ein Request? 2

Sicherheit Ist das Backend für Kunden direkt erreichbar? 2Ist eine Validierung der Eingabe leicht möglich? 2

Seitenaufbau Wird die Seite immer komplett neu aufgebaut? 2Wird die Navigation über den Browser berück-sichtigt?

2

Protokoll Ist das Protokoll für Datenaustausch wählbar? 1Redaktionierbarkeit Lassen sich einfache Änderungen an der Oberflä-

che ohne Deployment durchführen?1

JavaScript Ist die Arbeit ohne aktives JavaScript möglich? 1

Wartungsaufwand Wie hoch ist der Aufwand in der Wartung? 1Gibt es eine direkte Unterstützung für Tests? 1

Tabelle 3.1: Bewertung der Anforderungen, Quelle: eigene Darstellung


4 Aktuelle TechnologienIn diesem Kapitel werden einige Webtechnologien vorgestellt, welche für einen Lö-sungsansatz in Betracht gezogen wurden. Die Technologien werden kurz beschriebenund anhand der Anforderungen bewertet. Es wird weiterhin geklärt, weshalb einigeder Technologien für den Lösungsansatz vorgeschlagen beziehungsweise verwendetwurden und andere nicht.

4.1 TechnologienIn den folgenden Abschnitten werden die untersuchten Webtechnologien beschriebenund nach den erstellten Anforderungen bewertet.

4.1.1 Apache Struts

Apache Struts ist ein flexibles, auf Standard-Technologien wie Java Servlets, JavaBe-ans und XML basierendes Webframework. Struts bietet viele für die Webentwicklungbenötigte Funktionen an und erleichtert somit die Entwicklung von Anwendungen.Es wurde im Jahr 2001 veröffentlicht und ist seit dem Jahr 2004 Teil der ApacheSoftware Foundation4. Weiterhin liegt Struts dem Model-View-Controller-Prinzipzugrunde, welches einen klaren Schnitt zwischen dem Datenmodell, der Ansicht undder Steuerungslogik vorsieht.5 Das Framework stellt die Komponenten zur Steue-rungslogik und der Ansicht zur Verfügung. Um das Datenmodell umzusetzen kannStruts mit weiteren Technologien verbunden werden. Es ist ebenso möglich eineandere Technologie für die Ansicht einzusetzen.6

Struts bietet eine Unterstützung für AJAX. Außerdem ist es einfach durch Pluginszu erweitern und lässt sich mit verschiedenen Technologien kombinieren. Es nimmtdem Entwickler einige Aufgaben ab, kann aber den Quellcode unter Umständenschwer lesbar und komplexer machen.

4.1.2 Google Web Toolkit

Das Google Web Toolkit (GWT) ist ein Entwicklungswerkzeug, mit dem es möglichist, Webanwendungen in JavaScript zu erstellen. Die Entwicklung der Anwendungerfolgt in Java. Durch den mitgelieferten Compiler erstellt GWT aus dem Java Quell-text browserunabhängigen JavaScript und HTML Code. GWT stellt zwei verschie-

4http://www.apache.org/5Vgl. [FFSB05, S. 549]6Vgl. [Apa]


http://www.apache.org/

4. Aktuelle Technologien Fachhochschule Schmalkalden WS 2011/12

dene Modi bereit. Der Hosted Mode erlaubt es dem Entwickler, den erstellten JavaQuelltext zu debuggen. Im Web Mode hingegen, wird die Anwendung in JavaScriptund HTML übersetzt und kann zur Ausführung auf einem Webserver veröffentlichtwerden. Mit GWT ist es möglich, die Nutzeroberfläche komplett in Java-Code zuerstellen, ähnlich wie das Arbeiten mit Swing7. Es bietet weiterhin bereits einigeStandard Oberflächenelemente an und bringt ein integriertes Testframework mit.GWT wurde im Jahr 2006 von Google als Open-Source-Software veröffentlicht.8

Das GWT-Framework hat den Nachteil, dass es sich schwer in bestehende Weban-wendungen integrieren lässt. Durch die Übersetzung von Java-Code nach JavaScript,kann die Arbeit mit GWT zum Teil eingeschränkt werden. Dies ist auf ein wenigerumfangreiches Funktionsangebot von JavaScript zurückzuführen.Ein Vorteil von GWT ist, dass bei der Entwicklung der HTML-Seiten nicht mehrauf unterschiedliche Browser Rücksicht genommen werden muss. GWT compiliertden Quellcode browserunabhängig und nimmt dem Entwickler so eine beschwerlicheAufgabe ab. Des Weiteren sind AJAX-Probleme, das Nutzen der Browsernavigationund das Setzen von Lesezeichen, bereits umgesetzt.9 GWT setzt somit bereits einigewichtige Aufgaben der Webentwicklung um.

4.1.3 JavaServer Faces 2.0

JavaServer Faces (JSF) ist eine Technologie zur Entwicklung von Webanwendun-gen. Sie basiert auf der Servlet- sowie der JavaServer Pages-Technologie und istTeil des Java Platform, Enterprise Edition Standards. Für die Entwicklung vonJSF-Webanwendungen reicht ein einfacher Servlet-Container, wie zum Beispiel derApache Tomcat. Die Version 2.0 des JSF-Standards liegt seit dem Jahr 2009 durchden JSR-314 vor. Wie Apache Struts und viele andere Webframeworks, wurde auchJSF nach dem Model-View-Controller-Prinzip konzipiert.10

Einer der größten Vorteile von JSF 2.0 ist, dass keine Konfigurationsdateien benö-tigt werden. Alle Konfigurationen können direkt im Quelltext mit Hilfe von Anno-tationen erfolgen. Ein weiterer Vorteil ist eine bereits im Standard vorgesehen Un-terstützung für AJAX. Weiterhin beherrscht JSF einen Templating-Mechanismus.Über diesen können Komponenten definiert und auf verschiedenen Seiten wieder-verwendet werden. Außerdem können Elementen wie zum Beispiel Eingabefelder,Auswahllisten, etc. Valitatoren zugewiesen werden, welche die Eingaben prüfen. JSFermöglicht des Weiteren eine automatische Zustandsspeicherung. Dabei wird der Le-benszyklus eines Objektes, je nach Definition, automatisch verwaltet. Aufgrund des-sen, dass JSF ein offizieller Standard ist, wird die Erstellung von JSF-Anwendungendurch diverse Entwicklungswerkzeuge unterstützt.Der JSF-Standard erfüllt einige der gestellten Anforderungen. Es ist jedoch vonVorteil, diese Technologie mit weiteren zu kombinieren, um eine größere Anzahl derAnforderungen abzudecken.

7Eine Komponentenbibliothek zum Erstellen von grafischen Benutzeroberflächen.8Vgl. [Goo]9Vgl. [Sta]

10Vgl. [MKM09, S. 5ff.]



4.1.4 Java Portlets 2.0

Ein Java Portlet ist eine Webanwendung, die in einer Portalseite dargestellt undverwaltet wird. Eine Portalseite kann dabei mehrere Portlets enthalten. Das Portleterzeugt HTML-Code-Fragmente und gibt diese an das Portal zur Anzeige weiter.Jedes Java Portlet wird, wie in Abbildung 4.1 zu sehen, als Fenster oder auch PortalWindow dargestellt. Dieses Portal Window besteht wiederum aus einer Titelzeileund dem Portal Fragment, in welchem der eigentliche Inhalt des Portlets zu sehenist.11 Portlets sind Teil des Java-Standards. Version 2.0 der Java Portlets liegt seitdem Jahr 2008 durch den JSR-286 vor. Sie setzen auf dem Servlet-Standard auf undwerden in einem Portlet-Container ausgeführt.12

Abbildung 4.1: Aufbau einer Portalseite, Quelle: [LH09]

Portlets bieten einen weiteren Standard an, den Web Services for Remote Portlets(WSRP), welcher durch die Organization for the Advancement of Structured Infor-mation Standards (OASIS) definiert wurde. Dieser Standard dient zur Kommunika-tion zwischen Remote Portlets, also verteilten Portlets.13 Das hat den Vorteil, dassdie Transportschicht bereits implementiert ist. Die Kommunikation zwischen Koop-Frontend und -Backend würde somit über einen offiziellen Standard erfolgen. DesWeiteren bietet der Portlet-Standard ab der Version 2.0 bereits eine Unterstützungfür AJAX an. Sie bieten vielfältige Möglichkeiten in der Anwendung und lassensich mit Oberflächentechnologien wie JavaServer Pages, JSF, Apache Wicket undweiteren kombinieren. Die Verbindung zwischen Java Portlets 2.0 und JSF 1.2 zumBeispiel, ist durch den JSR-329 in einem eigenen Standard festgehalten.11Vgl. [LH09]12Vgl. [Hep08]13Vgl. [Tho08]



Diese Technologie hält allerdings auch einige Nachteile bereit. So ist zum Beispiel dieKonfiguration eines Portlets sehr umständlich, wenn es darum geht, sie den gestelltenAnforderungen entsprechend anzupassen. Es ist zum Beispiel nicht einfach möglichein Portlet zu erstellen, welches AJAX und den WSRP-Standard unterstützt. DieKonfiguration kann außerdem für die unterschiedlichen Portalserver stark variieren.Dies sind aber in der Regel einmalige Aufwände. Bei der Konfiguration von Port-lets, welche nur AJAX oder nur WSRP unterstützen sollen, gibt es keine größerenSchwierigkeiten. Probleme treten erst auf, sobald ein Portlet sehr viele Funktionenunterstützen soll.

4.1.5 Java Architecture for XML Binding

Java Architecture for XML Binding (JAXB) ist ein Java-Standard, der in der Version2.0 durch den JSR-222 spezifiziert wurde. JAXB ist eine Programmierschnittstellezum Abbilden von Java-Objekten beziehungsweise JavaBeans auf XML-Dokumente.Die Regeln zum Abbilden der Elemente werden entweder mit Hilfe von Annotationenin den Java-Objekten festgelegt oder über eine Schema-Datei. Im Fall der Schema-Datei generiert JAXB selbstständig die zugehörigen JavaBeans.14 JavaBeans sindin der Regel einfach gehaltene Datenobjekte, welche nur Attribute besitzen undZugriffsmethoden auf diese bereitstellen.

Abbildung 4.2: Aufbau einer JAXB-Anwendung, Quelle: [OM03]

Der Aufbau einer JAXB-Anwendung gestaltet sich wie folgt. Aus einer vorhandenenSchema-Definition werden Java-Objekte erstellt. Falls diese Objekte bereits existie-ren, müssen Annotationen hinzugefügt werden, welche die Regeln für eine XML-Abbildung festlegen. Für das Schreiben von Java-Objekten in ein XML-Dokumentwird der Marshaller benötigt. Er schreibt die Daten des Objektes, laut Schema-Datei in das XML-Dokument. Der Unmarshaller wird für das Lesen eines XML-Dokuments benötigt. Mit Hilfe des Unmarshallers können die XML-Dokumente14Vgl. [OM03]



eingelesen und in das zugehörige Java-Objekt geschrieben werden. Abbildung 4.2soll diese Zusammenhänge verdeutlichen.Vorteil dieser Programmierschnittstelle ist, dass sich der Entwickler nicht mit derreinen XML-Verarbeitung auskennen muss. Es reicht aus, eine einfache Schema-Definition zu erstellen sowie die Methoden zum Lesen und Schreiben aufzurufen. Dieeigentliche Bearbeitung der XML-Dokumente übernimmt die JAXB-Schnittstelle.JAXB kann, in einem neuen Ansatz der Koop-Middleware, den Datenkonverter er-setzen oder verbessern. Weiterhin kann es für die Aufbereitung der Daten des Koop-XML genutzt werden.

4.1.6 Java Servlet

Java Servlets sind Klassen, die von Klienten ausgehende Anfragen entgegen nehmenund Verarbeiten. Sie dienen als Basis für viele der bereits vorgestellten Technologi-en. Der Standard wurde in der Version 2.5, durch den JSR-154 beschrieben. Servletswerden auf Webservern, in einem Servlet-Container ausgeführt und erzeugen dyna-mische Inhalte einer Webanwendung. Alle Servlets implementieren die Schnittstellejavax.servlet.Servlet oder erweitern eine Klasse, die diese Schnittstelle implemen-tiert. In den meisten Fällen erweitern Servlets die Klasse HttpServlet.15

Die Vorteile dieser Technologie liegen darin, dass ein Servlet alle Anfragen des Brow-sers entgegennehmen kann, bevor diese die Backendanwendung erreichen. Somitkönnen die Anfragen, vor dem Weiterleiten an das Backend und vor der Ausgabe imBrowser, manipuliert werden. Weiterhin lassen sich mit Hilfe dieser Technologie vieleder gestellten Anforderungen Umsetzen. Dies ist allerdings mit einigem Aufwand, inder Entwicklung der verschiedenen Komponenten verbunden, welche diese Anforde-rungen umsetzen. Servlets erlauben des Weiteren eine Verwendung unterschiedlicherWebtechnologien, in der Backendanwendung. Da sie die Anfragen des Browsers „ab-fangen“ und durchreichen, ist die verwendete Technologie des Backends, an dieserStelle, irrelevant.Die Java Servlet Technologie bietet sehr viele Möglichkeiten, in der Umsetzung dergestellten Anforderungen. Aus diesem Grund wurde sie für einen technischen Durch-stich näher betrachtet.

4.2 BewertungDie beschriebenen Technologien waren Teil der Recherchen, zur Erstellung einesneuen Ansatzes der Koop-Middleware. Diese Technologien erfüllen, einzeln betrach-tet, allerdings zu wenige der gestellten Anforderungen. Aus diesem Grund fiel dieEntscheidung, mehrere Technologien zu kombinieren.Für eine nähere Betrachtung wurde etwa eine Kombination aus Java Portlets 2.0und JavaServer Faces 2.0 untersucht. Die Spezifikationen der beiden Standards lösenbereits einige der gestellten Anforderungen und boten somit, zumindest theoretisch,

15Vgl. [Ull10, Kap. 17.16 Servlets]



eine geeignete Grundlage. Weiterhin wurde die Kombination von Java Servlets sowieJavaServer Face 2.0 untersucht und der technische Durchstich auf dieser aufgebaut.Im weiteren Verlauf der Arbeit werden diese Technologieverknüpfungen näher er-läutert. Hierbei wird auf Vor- und Nachteile eingegangen und ein mögliches Archi-tekturszenario beschrieben.


5 LösungsansätzeDieses Kapitel beschreibt Lösungsansätze, die während der Ausarbeitung näher be-trachtet wurden und für einen technischen Durchstich in Frage kamen. Für einemögliche Lösung wurden einige Technologien untersucht und anhand der erstelltenAnforderungen bewertet.

5.1 Verteilte PortletsEin Lösungsansatz, welcher in die nähere Auswahl für einen technischen Durchstichkam, ist die Umsetzung mit Hilfe eines Portalservers. Der Portlet-Standard erfüllt,zumindest in der Theorie, sehr viele der gestellten Anforderungen. Er bietet bereitseine Lösung zum Arbeiten mit verteilten Anwendungen, den WSRP-Standard. Da-durch ist es möglich das Frontend- und das Backendsystem voneinander zu trennen,wobei die Transportschicht bereits durch den Standard definiert und von den mei-sten Portalservern implementiert ist. Weiterhin können Portlets mit verschiedenenWebtechnologien kombiniert werden. Für die Kombination von Portlets und JSFexistiert ein durch den Java Community Process definierter Standard.Der Lösungsansatz sieht als Frontendsystem den Portalserver GateIn16 in der Versi-on 3.1.0 vor. Am Backendsystem kann ebenfalls GateIn eingesetzt werden. Es wäreallerdings auch ausreichend einen Portlet-Container zu verwenden, solange dieserdie benötigten Standards unterstützt. Die Anwendungen beziehungsweise Portlets,auf den verschiedenen Systemen, würden dann über den WSRP-Standard kommu-nizieren.Dieser Ansatz bietet einige Vorteile. Es werden bereits viele der Probleme, die Koopmit sich bringt, durch Standards definiert. Hierfür müssen somit keine eigenen Lö-sungen erstellt werden. Auf der anderen Seite ist der Portlet-Standard noch relativunausgereift. Die Dokumentationen vieler Portalserver sind nur schwer nachzuvoll-ziehen oder veraltet. Weiterhin ist es schwierig, den Portalserver oder auch die Port-lets so zu konfigurieren, dass sie den gestellten Anforderungen gerecht werden. Dasheißt, dass sich verschiedene Funktionen der Portlets nicht miteinander verbindenlassen. So lässt sich zum Beispiel die AJAX-Funktionalität eines JSF-Portlets, inden verwendeten Portalservern, nicht über den WSRP-Standard nutzen.Der beschriebene Lösungsansatz wurde nach Absprache mit dem Entwicklerteamwieder verworfen. Es konnte während der Ausarbeitung keine geeignete Konfigurati-on gefunden werden, um die Anwendung den gestellten Anforderungen anzupassen.

16http://www.jboss.org/gatein


http://www.jboss.org/gatein

5. Lösungsansätze Fachhochschule Schmalkalden WS 2011/12

5.2 Eigenentwicklung von ToolsEine denkbare Lösung wäre ebenfalls das bestehende Koop-System beizubehaltenund für die Wartung einige Tools zu entwickeln. Diese Tools sollen die Entwicklerin Form von Generatoren unterstützen und ihnen fehleranfällige Arbeitsschritte ab-nehmen. Vorstellbar wäre der Einsatz zum Beispiel bei der XML-Konfiguration, dadiese häufig geändert beziehungsweise ergänzt wird. Hier hätte der Einsatz eines Ge-nerators eine Zeiteinsparung in der Wartung zur Folge. Weiterhin werden potentielleFehler minimiert.Von der Idee, Tools für die Entwickler zu erstellen, wurde allerdings schon früh Ab-stand genommen, da dies einen enormen Aufwand verursachen würde. Zum einenmüssen diese Tools von Grund auf selbst entwickelt werden. Zum anderen müssendann auch die Tools gewartet und gepflegt werden. Ändern sich die Prozesse desKoop-Systems, müssen die Tools angepasst werden. Dies verursacht zu große Auf-wände und stellt ein zu hohes Risiko dar.

5.3 Proxy-ServletDieser Lösungsansatz baut auf dem Servlet- sowie dem JSF-Standard auf. Er siehtals Frontendanwendung ein Servlet vor, dass die Anfragen an eine Backendan-wendung weiterleitet. Das Backendsystem generiert den fertigen HTML-Code undsendet diesen wieder an das Servlet zurück. Am Frontend kann der HTML-Codedurch weitere Komponenten bearbeitet und manipuliert werden. Durch diesen An-satz ist es möglich, relativ einfach, verschiedene Backendanwendungen anzubinden.Das Backend benötigt keine zusätzlichen Informationen über das Frontendsystemund kann somit eine eigenständige Anwendung sein.Diese Lösung verwendet zwei Apache Tomcat17 in der Version 6.0.2, welche dasFront- beziehungsweise Backend darstellen sollen. Jede Anwendung wird dabei aufeinem Applicationserver verteilt. Für die Verwendung der beiden Applicationserver,auf einem System, muss eine Konfiguration der Ports erfolgen. Dies wird in denfolgenden Kapiteln näher erläutert.Die Entwicklung des Servlets gestaltet sich relativ einfach und durch einige zusätz-liche Komponenten lässt sich dieses auch an viele der gestellten Anforderungen an-passen. Das bedeutet allerdings, dass eine Reihe von Aufwänden in der Entwicklunganfallen können.Aus dem Grund heraus, dass dieser Ansatz viele der Anforderungen erfüllt und rela-tiv einfach zu implementieren ist, wurde er für den technischen Durchstich gewählt.Im folgenden Kapitel wird dieser Lösungsansatz genauer beschrieben und erklärt.

17http://tomcat.apache.org/


http://tomcat.apache.org/

6 Beschreibung der LösungDer Ansatz, welcher für den technischen Durchstich gewählt wurde, wird in die-sem Kapitel beschrieben. Es wird auf die verwendete Software eingegangen und dieArchitektur der Anwendung erläutert. Weiterhin wird der Durchstich anhand vonQuelltext-Beispielen genauer beschrieben.

6.1 VoraussetzungenFür die Umsetzung des technischen Durchstichs kommt am Frontendsystem einServlet in Kombination mit dem Apache HttpClient18 zum Einsatz. Das Backend-system ist eine einfache JSF 2.0 Anwendung. Die Anwendungen wurden mit Hilfeder Entwicklungsumgebung Eclipse Java EE IDE for Web Developers19, in der In-digo SR1 Version erstellt. Die Entwicklungsumgebung wurde um das Maven-Pluginm2eclipse20 erweitert. Dieses ist ein Build-Tool, mit dem die Anwendungen erstelltund verwaltet werden können. Als Applicationserver kommen zwei Apache Tom-cat der Version 6.0.2 zum Einsatz. Weiterhin wird die Bibliothek Apache HttpCli-ent in der Version 4.1.2 verwendet, um eine Verbindung zwischen dem Front- undBackendsystem aufzubauen. Die Backendanwendung nutzt die Apache MyFaces21

Implementierung der JavaServer Faces in der Version 2.1.0.Die Entscheidung fiel auf den Tomcat, da dieser leicht zu installieren und zu konfigu-rieren ist. Weiterhin ist er sehr performant und auch Firmenintern konnten bereitseinige Erfahrungen mit dem Tomcat gesammelt werden. Die beiden Anwendungenwurden zusammen auf einem lokalen Entwicklersystem erstellt und getestet. Ausdiesem Grund müssen die Konfigurationen der beiden Applicationserver angepasstwerden. Beide Applicationserver müssen an unterschiedlichen Ports auf eingehen-de Anfragen warten. Der Port kann in der Datei server.xml, im conf Verzeichnisdes Tomcat, geändert werden. Listing 6.1 zeigt den betreffenden Abschnitt dieserDatei.

Listing 6.1: Port-Konfiguration des Tomcat in der server.xml1 <Connector port="8080"2 protocol ="HTTP /1.1"3 connectionTimeout ="20000"4 redirectPort ="8443"5 />

18http://hc.apache.org/httpcomponents-client-ga/19http://www.eclipse.org/20http://eclipse.org/m2e/21http://myfaces.apache.org/


http://hc.apache.org/httpcomponents-client-ga/

http://www.eclipse.org/

http://eclipse.org/m2e/

http://myfaces.apache.org/

6. Beschreibung der Lösung Fachhochschule Schmalkalden WS 2011/12

Es muss lediglich das port-Attribut bearbeitet werden. Beide Applicationserver müs-sen auf unterschiedlichen Ports laufen, wie zum Beispiel 8080 und 8081.In Bezug auf die Anforderungen bietet diese Lösung einige Vorteile. Zum einen bautsie auf den Standardtechnologien Servlet und JSF auf und kann leicht durch weitereTechnologien erweitert werden. Zum anderen erfüllt JSF durch seinen Templating-Mechanismus nicht nur den Punkt der Mandantenfähigkeit, sondern bringt aucheine sehr gute Unterstützung für AJAX-Anfragen mit. Weiterhin kann der War-tungsaufwand verringert werden, da sich JSF nach dem Prinzip Convention-over-Configuration konfigurieren lässt. Somit können einige der Konfigurationsdateienentfallen und Einstellungen direkt im Quelltext per Annotation vorgenommen wer-den. Ein weiterer Vorteil von JSF ist die automatisierte Zustandsverwaltung. AmBackend wird eine eindeutige Nummer generiert, über die der Nutzer am Frontenderkannt wird. Dies geschieht in der JSF-Implementierung. Der Entwickler muss sichalso nicht mit der Implementierung einer Sessionverwaltung am Backendsystem be-fassen. Es muss lediglich am Frontend eine Möglichkeit geschaffen werden, die Sit-zung der Backendanwendung „wiederzuerkennen“. Ein weiterer Vorteil dieser Lösungist, dass eine Kommunikation über das HTTPS-Protokoll22, mit Hilfe des HttpCli-ent, einfach umzusetzen ist.Ein Nachteil ist hingegen, dass das Protokoll, durch die Verwendung des ApacheHttpClient, vorerst auf HTTP festgelegt ist. Weiterhin fallen einige Arbeiten an,um beispielsweise ein Content Management System am Frontend einzubinden. Dadiese Aufwände in der Regel nur einmalig sein werden und diese Lösung viele Vorteileaufweist, wurde sie für den technischen Durchstich gewählt.

6.2 ArchitekturDer technische Durchstich besteht aus zwei Anwendungen, der Frontend- und derBackendanwendung. Ein am Frontend liegendes Servlet wartet auf eingehende An-fragen des Browsers. Dieses Servlet nimmt die Anfragen des Browsers entgegen,bereitet sie auf und sendet sie an die Backendanwendung. Es empfängt die Antwortdes Backends und leitet diese an den Browser, zur Präsentation für den Nutzer, wei-ter. Mit Hilfe des Servlets ist es außerdem möglich, die Antwort-Daten des Backends,am Frontend zu bearbeiten und zu manipulieren. Abbildung 6.1 zeigt den grobenAufbau des technischen Durchstichs.

Abbildung 6.1: Aufbau des technischen Durchstichs, Quelle: eigene Darstellung

22Die Kommunikation erfolgt über eine gesicherte HTTP-Verbindung.



Die Kommunikation zwischen Front- und Backend erfolgt, bedingt durch den ApacheHttpClient, über das HTTP-Protokoll. Der HttpClient eröffnet in der doGet()- be-ziehungsweise doPost()-Methode des Servlets, je nach Typ der Anfrage, einen neuenRequest. Diesem werden die Parameter und Meta-Daten der ursprünglichen Anfrageübergeben. Anschließend wird der neu erstellte Request an das Backend weiterge-reicht. Durch dieses Verhalten wird eine zusätzliche „Station“ in den Lebenszyklusder Anfrage eingebaut, an der die Antwort-Daten noch beeinflusst werden können.Die JSF-Anwendung am Backend soll die Business-Logik des Systems darstellen.Eine Besonderheit dieses Ansatzes ist es, dass sich die Anwendung so verhält, wie beieinem direkten Zugriff auf das Backend. Die Backendanwendung benötigt keine wei-teren Informationen über das Frontend und kann somit eine komplett eigenständigeAnwendung sein. Aus diesem Grund ist es möglich, die Anwendung am Backendeinfach auszutauschen. Es muss unter Umständen lediglich die Konfiguration desProxyServlets angepasst werden. Für das Frontend ist es außerdem gleichgültig,welche Technologie für die Backendanwendung verwendet wurde.Der technische Durchstich weist derzeit noch einige Nachteile auf. Im momenta-nen Zustand müssen beispielsweise die Anwendungen am Front- und Backend gleichheißen. Dieses Problem wird mit Hilfe der Maven-Konfiguration umgangen, indemfestgelegt wird, dass beide Anwendungen unter dem gleichen Namen erstellt wer-den. Es ist jedoch auch möglich, dieses Problem durch ein geeignetes Mapping derUniform Resource Locator (URL), in der Serverkonfiguration zu handhaben. DasProblem mit Hilfe von Maven zu lösen, war für den technischen Durchstich ersteinmal ausreichend. Später empfiehlt es sich jedoch, auf eine geeignete Serverkonfi-guration zurückzugreifen.

6.3 ImplementierungDie folgenden Abschnitte beschreiben die Anwendungen des technischen Durchstichsam Frontend- und Backendsystem. Hierbei wird die technische Seite der Anwendun-gen anhand von Quelltext-Ausschnitten erläutert.

6.3.1 Frontendanwendung

Die Frontendanwendung wurde mit dem Build-Tool Maven erstellt und verwal-tet. Entwickelt wurde sie mit der Entwicklungsumgebung Eclipse Java EE IDEfor Web Developers. Abbildung 6.2 zeigt den Aufbau der Anwendung, in einerStandard-Maven-Projektstruktur. Das Verzeichnis src/main/java enthält dabei denJava-Quellcode. Das Verzeichnis src/main/webapp beinhaltet Konfigurationen undzusätzliche Ressourcen wie HTML-Seiten und Bilder der Webanwendung. In demVerzeichnis target wird, nach dem Build-Prozess23, die fertige Webanwendung abge-legt. Abhängigkeiten des Projektes sowie Einstellung zum Build-Prozess werden inder pom.xml definiert. In der Datei web.xml wird die Konfiguration der Webappli-kation vorgenommen. Weitere Informationen und eine genauere Beschreibung zur

23Der Prozess, während dem, die fertige Webanwendung erstellt wird.



Abbildung 6.2: Projektstruktur der Frontendanwendung,Quelle: eigene Darstellung (erstellt mit Eclipse)

Maven-Projektstruktur befinden sich auf der Webseite24 des Maven Projektes.Die Frontendanwendung stellt ein Servlet dar, welches die Klasse HttpServlet er-weitert. Servlets müssen die Schnittstelle javax.servlet.Servlet implementieren. DasGenericServlet implementiert diese Schnittstelle und stellt somit die Grundlage fürdas HttpServlet dar. Dieses erweitert das GenericServlet um einige, für das HTTP-Protokoll, spezifische Methoden.25

Durch das Erweitern der Klasse HttpServlet müssen mindestens die beiden Metho-den doGet() und doPost() überschrieben werden. Diese Methoden behandeln dieGET- bezwiehungsweise POST-Anfragen, die durch den Nutzer, über den Brow-ser abgesetzt werden. Abbildung 6.3 zeigt das Klassendiagramm der Frontendan-wendung. Die Klasse ProxyServlet ist dabei das Servlet, welches die Anfragen desNutzers entgegen nimmt und an das Backend weiterleitet. ServletHelper ist eineHilfsklasse26, die statische Methoden zur Bearbeitung der Request- und Response-Daten anbietet. Session repräsentiert ein Sitzungsobjekt und enthält alle nötigenDaten, um die Sitzungen von Front- und Backend miteinander zu verknüpfen. DieKlasse SessionHandler ist nach dem Singleton-Muster konzipiert. Dieses sieht vor,dass nur eine Instanz der Klasse erstellt werden kann.27 Die Klasse enthält eine Li-24http://maven.apache.org/25Vgl. [Ull10, Kap. 17.16 Servlets]26Stellt Methoden bereit, die aus der eigentlichen Klasse ausgelagert wurden.27Vgl. [FFSB05, S. 177]


http://maven.apache.org/


ste aller offenen Sitzungen der Anwendung und stellt Methoden bereit, um auf diesezuzugreifen.Trifft am Server eine Anfrage des Browsers ein, wird ermittelt, um welchen Typ derAnfrage es sich handelt. In den folgenden Abschnitten werden die Methoden zurBehandlung von GET- beziehungsweise POST-Anfragen näher erläutert.

Abbildung 6.3: Klassendiagramm der Frontendanwendung,Quelle: eigene Darstellung

HTTP GET-Anfragen

Im erstellten Durchstich werden GET-Anfragen zum einen bei initialen Aufrufender Seite angestoßen und zum anderen um Ressourcen wie Cascading Style Sheets28,Java Scripts oder Bilder zu laden. Bei einer GET-Anfrage können Daten aus HTML-Formularen, über die URL, an den Server geschickt werden.29 Beim Eintreffen einerAnfrage leitet der HttpClient diese an die Backendanwendung weiter. Hierfür ist esnötig die Request-Parameter und -Header auszulesen und der Anfrage des HttpCli-ent zu übergeben.

28Eine Sprache zum Definieren von Seitenlayouts.29Vgl. [Ker11, Kap. 4.6.5 Verschiedene Internet-Anwendungsprotokolle]



Um die Bearbeitung der Anfragen besser zu überblicken, wurden diese in verschie-dene Phasen eingeteilt. Abbildung 6.4 zeigt die einzelnen Phasen, welche sich sowohlim Quelltext der Anwendung als auch im weiteren Verlauf der Arbeit wiederfinden.

Abbildung 6.4: Phasen der Bearbeitung einer Anfrage,Quelle: eigene Darstellung

Phase - initIn diesem Abschnitt wird die Sitzung des Nutzers der aktuellen Anfrage zugeordnet.Ein Session-Objekt enthält in diesem Fall, die SitzungsID des Frontends und die desBackends. Weiterhin wird der Userlevel des Nutzers der Sitzung zugeordnet. Trifftam Frontend eine Anfrage ein, generiert das Servlet eine SessionID. Mit Hilfe dieserID und des SessionHandlers wird die Liste der offenen Sitzungen durchsucht. Enthältdie Liste bereits eine Sitzung mit der SessionID des Frontends, wird diese aus derListe gelesen und für die weitere Bearbeitung der Anfrage verwendet. Für den Fall,dass die Sitzung noch nicht existiert, wird ein neues Session-Objekt erzeugt. Listing6.2 zeigt, wie diese Phase umgesetzt ist.

Listing 6.2: Initialisieren der Sitzung1 Session current ;2 if ( sHandler . containsFEId (req. getSession ().getId ()))3 current = sHandler . getSessionByFEId (4 req. getSession ().getId ());5 else {6 current = new Session ();7 current . setSessionFE (req. getSession ().getId ());8 }

Das Sessionhandling der Anwendung ist noch sehr unausgereift. Zum Beispiel ist dasAufräumen beendeter Sitzungen, in diesem Beispiel noch nicht umgesetzt. Besondersbeachtet werden sollte außerdem das Abstimmen der Timeout-Zeiten der Front- undBackendsitzungen. Für einen produktiven Einsatz empfiehlt es sich, aus Gründen derSicherheit, die Sitzungsverwaltung zu verbessern und zu erweitern. Ein mögliches



Szenario wäre es ebenfalls, dass vorhandene Sessionhandling des derzeitigen Koop-Ansatzes an den neuen Ansatz anzupassen.Phase - set requested URLDie nächste Phase besteht darin, ein Objekt des HttpClient und der Http-Methodezu erstellen. Listing 6.3 zeigt das Deklarieren und Initialisieren der Objekte desHttpClient sowie der HTTP GET-Methode.

Listing 6.3: Deklaration und Initialisierung des HttpClient1 HttpClient client = new DefaultHttpClient ();2 HttpGet httpget = new HttpGet (3 ServletHelper . editUrl (req)+4 ServletHelper . getUrlQuery (req));

Dem Objekt der GET-Methode wird im Konstruktor die URL der Backendanwen-dung übergeben. Mit Hilfe der Methoden editUrl() und getUrlQuery() wird die Zie-ladresse des Backendsystem erstellt. Beide sind in der Hilfsklasse ServletHelper im-plementiert. Listing 6.4 und 6.5 bilden diese Methoden ab.

Listing 6.4: Methode zum Bearbeiten der Anfrage-URL1 public static String editUrl ( HttpServletRequest req) {2 String url = req. getRequestURL (). toString ()3 . replace (SRC_URL , DEST_URL );4 if ( containsSessionId (req))5 url = url. substring (0,url. indexOf (";"));6 return url;7 }

Die Methode editUrl() ersetzt zuerst den Host der Anfrage-URL, um die Anfrage andas Backendsystem weiterzuleiten. Die Konstante SRC_URL definiert hierbei dieURL des ProxyServlets und die Konstante DEST_URL die der Backendanwendung.Weiterhin wird überprüft, ob die Anfrage-URL den Parameter jsessionid enthält.Bei einer initialen Anfrage wird am Backend eine SessionID erzeugt, über welcheder Nutzer, bei weiteren Anfragen, identifiziert werden kann. Diese ID wird vomBackend, über die URL, an das Servlet zurückgesendet. Aus Sicherheitsgründen wirddiese Nummer durch das Servlet aus der URL entfernt und nur noch als Cookie30

ausgetauscht.

Listing 6.5: Methode zum Lesen des Query-Strings1 public static String getUrlQuery ( HttpServletRequest req){2 String qry = req. getQueryString ();3 if (qry == null)4 return "";5 else6 return "?"+qry;7 }

Mit Hilfe der Methode getUrlQuery() wird der Query-String aus der Anfrage-URLausgelesen. Über diese Zeichenkette können zusätzliche Parameter übertragen wer-30Eine kleine Textdatei zum Speichern von Nutzerdaten.



den. Enthält die URL keine Parameter, gibt die Methode eine leere Zeichenkettezurück. Andernfalls wird der Query, beginnend mit einem ?, zurückgegeben. Die-ses Verfahren kommt nur für die GET-Methode zum Einsatz, da die Parameter derPOST-Methode im HTTP-Body gesendet werden.Phase - set request parametersNachdem die Zieladresse der Backendanwendung gesetz wurde, werden die Request-Parameter und -Header ausgelesen und dem Objekt der GET-Methode übergeben.In Listing 6.6 und 6.7 wird beschrieben welche Schritte hierfür nötig sind.

Listing 6.6: Setzen der Request-Parameter in der GET-Methode1 Map <String ,String []> params = req. getParameterMap ();2 for (String key : params.keySet ()) {3 httpget . getParams ()4 . setParameter (key , params.get(key)[0]);5 }

Für das setzen der Request-Parameter ist es nötig alle Parameter auszulesen unddie erhaltene Map31 zu durchlaufen. Hierbei wird jedes Key-Value-Paar der Map andas Objekt der GET-Methode übergeben.Diese Phase ist im technischen Durchstich ebenfalls noch kritisch zu betrachten.Die Anfrage-Parameter werden ungefiltert an das Backend durchgereicht, was eineManipulation von „außen“ ermöglicht. Es bietet sich hier an, einen Filter auf derBasis des Chain of Responsibility-Musters32 zu entwickeln. Dieses ermöglicht es, denFilter einfach zu erweitern und zu konfigurieren.Phase - set request headers

Listing 6.7: Setzen der Request-Header in der GET-Methode1 Enumeration <String > e = req. getHeaderNames ();2 while (e. hasMoreElements ()) {3 String name = e. nextElement ();4 String value = req. getHeader (name);5

6 if ("accept". equalsIgnoreCase (name)7 && value. contains ("text/html")) {8 isHtml = true;9 }

10

11 if (!"content -length". equalsIgnoreCase (name)) {12 if ("cookie". equalsIgnoreCase (name)13 && value. contains (" JSESSIONID ")) {14 value = " JSESSIONID ="+ current . getSessionBE ()15 +"; Path =/jsf2 - example ";16 }17

18 httpget . setHeader (name ,value);19 }20 }

31Eine Datenstruktur, in welcher die Daten als Key-Value-Paare angeordnet sind.32[FFSB05, S. 616f.]



Das Setzen der Request-Header gestaltet sich ähnlich. Die Header werden in einerEnumeration33 ausgelesen und durchlaufen. Dabei werden die einzelnen Elementewieder dem Objekt der GET-Methode übergeben. Während der Übergabe der Ele-mente müssen einige Spezialfälle beachtet werden. Zum einen wird der Wert desaccept-Header geprüft. Dieser Header legt fest, von welchem Typ der Inhalt einesResponse sein darf. In diesem Fall soll für Antworten mit einem HTML-Inhalt, dieVariable isHtml auf den Wert true gesetzt werden. Der Wert dieser Variable wirdspäter dazu verwendet, um den Typ der Antwort leichter zu ermitteln. Weiterhinwerden die Header auf ihren Namen geprüft. Das Element mit dem Namen content-length wird an dieser Stelle herausgefiltert, da dieser später automatisch gesetztwird. Wenn der cookie-Header die SessionID enthält, wird die ID des Frontends mitder des Backends ausgetauscht. Somit wird sichergestellt, dass der Nutzer von derBackendanwendung wiedererkannt wird.Phase - executing requestIm Anschluss kann die Anfrage über den HttpClient abgesetzt werden. Listing 6.8zeigt wie dies im Quelltext umgesetzt ist.

Listing 6.8: Senden eines Request über die GET-Methode1 ResponseHandler <String > responseHandler =2 new BasicResponseHandler ();3

4 if(isHtml) {5 HttpResponse response = client. execute ( httpget );6 responseBody = responseHandler7 . handleResponse ( response );8 Session tmp = setSessionData (req , response );9 current . setSessionBE (tmp. getSessionBE ());

10 sHandler . addSession ( current );11

12 res = ServletHelper13 . handleResponseHeader (current , res , response );14 } else {15 responseBody = client16 . execute (httpget , responseHandler );17 }

Der ResponseHandler verarbeitet die Antwort des Servers und gibt den Inhalt dieserals String zurück. Die Abfrage prüft, von welchem Typ der Inhalt dieser Anfrageist. Wurde, wie in Listing 6.7 beschrieben, die Variable isHtml auf den Wert truegesetzt, handelt es sich bei der Antwort um ein HTML-Formular. Die Antwort desBackends wird in das Objekt response geschrieben. Dieses wird anschließend an denResponseHandler übergeben und in der Methode handleResponse() verarbeitet. DieMethode liest den HTML-Inhalt der Antwort aus und schreibt diesen in die Zeichen-kette responseBody. Der nächste Schritt besteht darin, die Sessiondaten der aktuellenAnfrage zu behandeln. Die Methode setSessionData() wird in Listing 6.9 erläutert.Das bearbeitete Session-Objekt wird anschließend der Liste aller offenen Sitzungenhinzugefügt. Als letztes werden die Header der Backend-Antwort übernommen und

33Eine Sammlung von Daten, mit dessen Hilfe über Mengen iteriert werden kann.



in das Response-Objekt des ProxyServlet geschrieben. Dies geschieht mit Hilfe derMethode handleResponseHeader(), welche in Listing 6.10 beschrieben wird.Erwartet die Anfrage keine HTML-Antwort, wird sie mit Hilfe des ResponseHandlerabgesetzt. Der Inhalt wird dabei direkt in die Zeichenkette responseBody geschrie-ben. Dies ist zum Beispiel der Fall, wenn Bilder oder Style-Sheets geladen werden.

Listing 6.9: Methode zum Behandeln der Sessiondaten1 private Session setSessionData ( HttpServletRequest req ,2 HttpResponse res) {3 Session session = new Session ();4 String frontId = req. getSession ().getId ();5 String backId = null;6 String level = null;7

8 if (res. containsHeader (" userlevel ")) {9 level = res. getFirstHeader (" userlevel ")

10 . getValue ();11 }12

13 if (res. containsHeader ("set -cookie")) {14 Header [] headers = res. getHeaders ("set -cookie");15 for (Header h: headers ) {16 if (h. getValue (). contains (" JSESSIONID ")) {17 String value = h. getValue ();18 backId = value. substring (value. indexOf ("=")+1,19 value. indexOf (";"));20 }21 }22 }23

24 if (backId == null)25 backId = sHandler . getBEIdByFEId ( frontId );26

27 if (level == null)28 level = sHandler . getUserlevelByFEId ( frontId );29

30 session . setSessionFE ( frontId );31 session . setSessionBE (backId);32 session . setUserlevel (level);33

34 return session ;35 }

Die Methode setSessionData() ist für das Bearbeiten der Sessiondaten zuständig. Sieprüft, ob die Antwort des Backends einen Userlevel enthält. Falls dieser vorhandenist, wird sein Wert ausgelesen und in der Zeichenkette level gespeichert. Um denUserlevel einem Nutzer zuordnen zu können, wird die SessionID benötigt. Diesewird bei initialen Anfragen an das Backend über den set-cookie-Header gesendet.Aus diesem Header wird die ID herausgelesen und abgespeichert. Wurde der Headernicht gesendet, existiert ein Cookie, welches die ID enthält. Wenn dieses Cookiebesteht, wurde die BackendID bereits dem Session-Objekt hinzugefügt. Aus diesem



kann dann die SessionID des Backends gelesen werden. Anschließend werden dieSessiondaten in einem temporären Session-Objekt gespeichert und von der Methodezurückgeben. Die Daten werden nun in die Liste der Sitzungen aufgenommen.

Listing 6.10: Methode zum Übernehmen der Response-Header1 public static HttpServletResponse handleResponseHeader (2 Session aSession , HttpServletResponse res ,3 HttpResponse response ) {4 Header [] headers = response . getAllHeaders ();5

6 for (Header h: headers ) {7 String name = h. getName ();8 String value = h. getValue ();9

10 if ("set -cookie". equalsIgnoreCase (name)11 && value. contains (" JSESSIONID ")) {12 value = " JSESSIONID ="+ aSession . getSessionFE ()13 +"; Path =/jsf2 - example ";14 }15

16 res. addHeader (name , value);17 }18 return res;19 }

Die ausgelagerte Methode handleResponseHeader() befindet sich in der HilfsklasseServletHelper. Diese Methode übernimmt die Response-Header des Backends undschreibt sie in das HttpServletResponse-Objekt des ProxyServlets. Hierfür werdendie Header in das Array headers ausgelesen. Diese Datenstruktur wird anschließenddurchlaufen und jedes Element dem HttpServletResponse-Objekt hinzugefügt. Wirdwährend dem Durchlaufen des Arrays auf den set-cookie-Header getroffen, erfolgtwie auch vor dem Senden der Anfrage, ein Mapping der SessionID. In diesem Fallwird allerdings die ID der Backendanwendung, mit der des Frontend ersetzt.Phase - print responseNachdem die Anfrage abgesetzt und die Antwortdaten ausgelesen wurden, müssendiese noch zur Anzeige ausgegeben werden. Hierfür gibt es zwei Methoden, welchein Listing 6.11 und 6.12 beschrieben werden.

Listing 6.11: Methode zum Ausgeben von HTML-Antworten1 private void manipulateResponse ( Session aSession ,2 HttpServletResponse res , String response )3 throws IOException {4 ServletOutputStream out = res. getOutputStream ();5

6 out. println ( getDeclaration ( response ));7 out. println ("<html xmlns="8 +"\" http :// www.w3.org /1999/ xhtml \">");9 out. println ( getHead ( response ));

10 out. println (" <body >");11 out. println (" <h1 > Zustand - "12 + getState ( aSession . getUserlevel ())+" </h1 >");



13 out. println ( getContent ( response ));14 out. println (" </body >");15 out. println (" </html >");16

17 out.flush ();18 }

Die MethodemanipulateResponse() wird ausgeführt, wenn die Antwort des BackendsHTML ist. In diesem Fall wird, um die Seite der Backendanwendung herum, eineÜberschrift mit dem aktuellen Zustand des Nutzers ausgegeben. Dieses Verhaltensoll zeigen, dass sich die Anwendung in ein Content Management System integrierenlässt und wie Daten von der Backendanwendung an das ProxyServlet übermitteltwerden können. Bei den Aktionen login und logout wird, am Backend, der Userlevelin den ResponseHeader geschrieben und an das Frontend gesendet. Hier wird inAbhängigkeit des Userlevels jeweils eine andere Überschrift ausgegeben. Die Ausgabedes Userlevels erfolgt durch die Methode getState(). Weiterhin wird die HTML-Seitedes Backends in verschiedene Teile zerlegt. Mit Hilfe der Methoden getDeclaration(),getHead() und getContent() werden die einzelnen Teilstücke gelesen und in die Seitedes Frontends eingebettet.

Listing 6.12: Methode zum Ausgeben von Ressourcen1 private void printResponse ( HttpServletResponse res ,2 String result) throws IOException {3 ServletOutputStream out = res. getOutputStream ();4

5 out. println (result);6

7 out.flush ();8 }

Alle Antworten die kein HTML enthalten, werden ohne Manipulation ausgegeben.Dies können Beispielsweise Antworten auf AJAX-Anfragen, Bilder oder andere Res-sourcen sein.Der vollständige Quelltext der GET-Methode befindet sich im Anhang, in ListingA.1.

HTTP POST-Anfragen

POST-Anfragen wiederum, werden beim Ausführen von Aktionen, auf einer Sei-te, angestoßen. Diese Aktionen sind zum Beispiel das Klicken auf einen Link oderButton. AJAX-Anfragen werden ebenfalls über die POST-Methode versendet.Bei einer POST-Anfrage werden Daten aus HTML-Formularen an den Server über-tragen, indem sie dem HTTP-Body der Anfrage hinzugefügt werden. In diesemHTTP-Body werden die Nutzdaten gesammelt an das Backend versendet.34 DerVorteil dieser Methode ist, dass die Nutzdaten nicht ohne weiteres am Bildschirmabgelesen werden können.

34Vgl. [Ker11, Kap. 4.6.5 Verschiedene Internet-Anwendungsprotokolle]



Phase - initDas Ausführen der POST-Methode funktioniert im Grunde nach dem gleichen Prin-zip, wie das der GET-Methode. Listing 6.2 zeigt das Initialisieren der Session, wasfür die POST-Methode ebenso gilt wie, für die GET-Methode. Es wird auch hiergeprüft, ob die Session bereits existiert und gegebenenfalls aus der Liste gelesen.Andernfalls wird eine neue Session erzeugt.Phase - set requested URLAuch für die POST-Methode wird das Objekt des HttpClient sowie das Objekt derHTTP-Methode erstellt. Hier wird allerdings ein Objekt entsprechend der POST-Methode genutzt. Listing 6.13 zeigt das Erstellen dieser Objekte.

Listing 6.13: POST Objekt initialisieren und deklarieren1 HttpClient client = new DefaultHttpClient ();2 HttpPost httppost = new HttpPost (3 ServletHelper . editUrl (req));

Im Gegensatz zur GET-Methode wird hier der Query-String in der URL vernachläs-sigt, da die Parameter ausschließlich im Body der HTTP-Anfrage versendet werden.Phase - set request parametersEinen weiteren Unterschied zur GET-Methode stellt das Setzen der Request-Para-meter dar. In Listing 6.14 wird gezeigt, wie diese an das Objekt der POST-Methodeübergeben werden.

Listing 6.14: Setzen der Request-Parameter in der POST-Methode1 List < NameValuePair > nameValuePairs =2 new ArrayList <NameValuePair >();3 Map <String ,String []> params = req. getParameterMap ();4

5 for (String key : params.keySet ()) {6 nameValuePairs .add(7 new BasicNameValuePair (key ,params.get(key)[0]));8 }9

10 httppost . setEntity (11 new UrlEncodedFormEntity ( nameValuePairs , "UTF -8"));

Die Parameter werden auch hier als Map ausgelesen. Beim Durchlaufen der Map,werden die Parameter allerdings in einer Liste zwischengespeichert und anschlie-ßend gesammelt an das Objekt der POST-Methode übergeben. Hier ist in einemproduktiven Einsatz ebenfalls ein Filter zu verwenden, über den geprüft wird, wel-che Parameter an das Backend gesendet werden.Phase - set request headersWährend dem Setzen der Request-Header wird bei der POST-Methode nicht zwi-schen HTML-Inhalten und anderen Ressourcen unterschieden. Hier werden AJAX-Anfragen von „normalen“ Anfragen getrennt. Wie in Listing 6.15 dargestellt, werdendie Header auf ihren Namen geprüft. Handelt es sich um einen faces-request mit demWert partial/ajax, also einen AJAX-Request, wird die Variable isAjax auf den Werttrue gesetzt. Diese Variable wird für die weitere Bearbeitung der Anfrage benö-



tigt. Weiterhin erfolgt auch hier ein Mapping der Session des Frontends auf die desBackends.

Listing 6.15: Setzen der Request-Header in der POST-Methode1 Enumeration <String > e = req. getHeaderNames ();2 while (e. hasMoreElements ()) {3 String name = e. nextElement ();4 String value = req. getHeader (name);5

6 if ("faces - request ". equalsIgnoreCase (name)7 && " partial /ajax". equalsIgnoreCase (value)) {8 isAjax = true;9 }

10

11 if (!"content -length". equalsIgnoreCase (name)) {12 if ("cookie". equalsIgnoreCase (name)13 && value. contains (" JSESSIONID ")) {14 value = " JSESSIONID ="+ current . getSessionBE ()15 +"; Path =/jsf2 - example ";16 }17 httppost . setHeader (name ,value);18 }19 }

Phase - executing requestDas Senden der Anfrage erfolgt hier ohne Abfrage des Inhalts-Typen. Eine POST-Anfrage wird, wie eine Anfrage mit HTML-Inhalt in der doGet()-Methode gesen-det, da hier keine Ressourcen angefragt werden. Listing 6.16 zeigt das Senden einerPOST-Anfrage. Im Gegensatz zur GET-Anfrage wird hier allerdings nur der User-level gesetzt, da sich dieser nur bei POST-Anfragen ändert.

Listing 6.16: Senden eines Request über die POST-Methode1 ResponseHandler <String > responseHandler =2 new BasicResponseHandler ();3 HttpResponse response = client. execute ( httppost );4 responseBody = responseHandler5 . handleResponse ( response );6 Session tmp = setSessionData (req , response );7 current . setUserlevel (tmp. getUserlevel ());8 sHandler . addSession ( current );9

10 res = ServletHelper11 . handleResponseHeader (current , res , response );

Phase - print responseDas Ausgeben der Antwort erfolgt hier in Abhängigkeit des Typs der Anfrage. Han-delt es sich um einen AJAX-Request wird die Antwort mit Hilfe der Methode prin-tResponse(), wie in Listing 6.12, ausgegeben. Alle anderen Antworten werden, wiein Listing 6.11 beschrieben, über die Methode manipulateResponse() angezeigt.Der vollständige Quelltext der POST-Methode befindet sich im Anhang, in ListingA.2.



6.3.2 Backendanwendung

Die Backendanwendung ist eine Beispiel-Anwendung, welche die Funktionen desProxyServlets darstellen und belegen soll. Sie wird aus diesem Grund nicht im De-tail beschrieben. Die Anwendung ist ebenfalls ein auf Maven basierendes Projektund wurde mit der Entwicklungsumgebung Eclipse Java EE IDE for Web Devel-opers entwickelt. Die Struktur des Projektes ist dem der Frontendanwendung ähn-lich. Hier werden allerdings einige zusätzliche Ressourcen benötigt. Diese befindensich hauptsächlich im Verzeichnis src/main/webapp. Dessen Unterverzeichnis meta-inf/includes enthält dabei vor allem Seitendefinitionen und template-Dateien, welcheauf den verschiedenen Seiten verwendet werden. Die reinen Seiteninhalte liegen imVerzeichnis pages. Im Verzeichnis resources befinden sich zum Beispiel Bilder undCascading Style Sheets. Abbildung A.1 zeigt die Struktur der gesamten Anwendung.Diese basiert auf JavaServer Faces und wurde mit der Apache MyFaces Implementie-rung umgesetzt. Sie stellt einige Funktionen einer Nutzerverwaltung zur Verfügungund bietet ebenfalls ein Beispiel für AJAX-Anfragen. Es ist möglich, sich mit einemNutzer beziehungsweise Administrator am System anzumelden und je nach Nut-zertyp verschiedene Aktionen auszuführen. Als Administrator ist es beispielsweisemöglich, seine Nutzerdaten zu ändern oder eine Liste aller vorhanden Nutzer ein-zusehen. Als einfacher Nutzer ist es jedoch nur möglich, seine eigenen Daten zuändern.Das Klassendiagramm in Abbildung A.2 zeigt eine Übersicht der erstellten Klas-sen. JSF ist nach dem Model-View-Controller-Prinzip konzipiert, genauer gesagtdem Model2. Dieses ist eine für Webanwendungen spezialisierte Variante des Model-View-Controller-Prinzips und teilt die Anwendung demnach in die drei BereicheModel, View und Controller. Die View Komponente stellen hierbei Faclets, also diexhtml-Dateien dar. Sie enthalten den Inhalt der Seiten und bilden somit die Benut-zerschnittstelle ab. Die Klasse User enthält das Datenmodell der Anwendung. In ihrwird festgelegt, welche Attribute ein Nutzer hat und wie diese abgespeichert werden.Die Klasse UserBean fungiert als Verbindung zwischen dem Datenmodell und derView-Komponente. Der Controller wird durch ein Servlet dargestellt, welches durchdie JSF-Implementierung bereitgestellt wird.35

Wird auf der Nutzeroberfläche eine Aktion angestoßen, beispielsweise durch dasKlicken auf den Login-Button, wird in der Klasse UserBean die Methode login()aufgerufen. Listing 6.17 zeigt die login()-Methode.

Listing 6.17: Methode zum Ausführen der Login-Aktion1 public String login () {2 if ( checkLogin ()) {3 ExternalContext context =4 FacesContext . getCurrentInstance ()5 . getExternalContext ();6

7 user. setLevel (User. LEVEL_ON );8 context . setResponseHeader (" Userlevel ",9 ""+user. getLevel ());

35[MKM09, S. 5]



10

11 if (user. getType () == User. TYPE_USER ) {12 navigation = Pages. T_NAVI_USER ;13

14 return Pages.P_HOME;15 } else if(user. getType () == User. TYPE_ADMIN ) {16 navigation = Pages. T_NAVI_ADMIN ;17 users = services . findAll ();18

19 return Pages. A_ADMIN ;20 }21 }22 return Pages. E_LOGIN_FAIL ;23 }

Hier wird über die Hilfsmethode checkLogin() geprüft, ob der Nutzer, mit demversucht wurde sich einzuloggen, in der Datenbasis existiert. Eine Liste mit allenverfügbaren Nutzern wird beim Start der Anwendung, in der Klasse UserServices,angelegt. Ist der Nutzer vorhanden, wird sein Userlevel geändert und als Response-Header gesetzt. So kann der Userlevel am Frontend empfangen werden. Weiterhinwird der Typ des Nutzers geprüft. Derzeit gibt es die Typen TYPE_USER undTYPE_ADMIN, um zwischen normalen Nutzern und Administratoren zu unter-scheiden. In Abhängigkeit von diesen wird ein entsprechender Verweis auf die Seitezurückgegeben, welche als Antwort auf die login-Aktion angezeigt werden soll. AlleVerweise auf Seiten sind in der Klasse Pages als Konstanten hinterlegt.Um eine Klasse als ManagedBean festzulegen, also als Verbindung zwischen Modelund View, muss diese mit der Annotation @ManagedBean(name = BEAN_NAME)und einem entsprechenden Namen für den Zugriff versehen werden. Weiterhin mussihr ein Scope zugewiesen werden, was ebenfalls mit Hilfe einer Annotation geschehenkann. Dieser legt fest, wie lange ein Objekt der Klasse verfügbar ist. Hier sind diefolgenden Optionen möglich.

@NoneScoped - Die Managed-Bean wird nicht gespeichert und bei jedem Aufrufneu erstellt.

@RequestScoped - Die Managed-Bean lebt für die Zeitdauer einer HTTP-Anfrage.

@ViewScoped - Die Lebensdauer der Managed-Bean ist an die Ansicht geknüpft,in der sie verwendet wird.

@SessionScoped - Die Managed-Bean lebt für die Dauer einer Sitzung, in der derBenutzer mit der Anwendung verbunden ist.

@ApplicationScoped - Für die gesamte Lebensdauer der Anwendung ist nur einefür alle Benutzer gleiche Instanz dieser Managed-Bean vorhanden.

Tabelle 6.1: Scopes einer ManagedBean,Quelle: [MKM09, S. 33]



Die Klasse UserBean verwendet den Session-Scope und ist somit über die Dauer einerSitzung verfügbar. Die Klasse UserServices muss dagegen den Application-Scopeverwenden, um immer verfügbar zu sein. Hierdurch wird es möglich diese Klasse alseine Art Datenbankersatz zu verwenden und Änderungen an den Nutzerdaten zuspeichern.Wie bereits erwähnt, soll diese Anwendung lediglich die Funktionalität der Fronten-danwendung demonstrieren und bestätigen. Der vollständige Quelltext der Anwen-dung liegt allerdings der Arbeit bei.


7 Zusammenfassung und AusblickIm Laufe dieser Arbeit wurde die Middleware Koop analysiert und ein neuer Ansatzdieser Software, in Form eines technischen Durchstichs erstellt. Dieser Durchstichunterliegt einigen Anforderungen, welche während der Analyse aufgestellt wurden.Es wurden weiterhin verschiedene Webtechnologien betrachtet und anhand der An-forderungen bewertet, um so geeignete Lösungen für einen neuen Ansatz zu finden.Das Ziel der Arbeit war es, möglichst viele der erarbeiteten Anforderungen in dasneue Konzept aufzunehmen und eine Anwendung zu erstellen, welche beispielhafteinige Funktionen und somit auch Anforderungen umsetzt. Hier standen vor allemdie Themen Standardtechnologien, AJAX-Unterstützung und ein minimaler Konfi-gurationsaufwand im Mittelpunkt. Allerdings ist auch der erstellte Durchstich nichtperfekt und somit konnten einige der Anforderungen noch nicht umgesetzt wer-den. So ist zum Beispiel der Punkt der Mandantenfähigkeit im derzeitigen Standder Anwendung nicht implementiert. Dies sollte aber, zumindest theoretisch, durchden Templating-Mechanismus der JSF-Implementierung, relativ einfach umzuset-zen sein. Andere Punkte können unter hinzunahme verschiedener Frameworks erfülltwerden. Hierfür sind allerdings weitere Recherchen und Analysen nötig. Beispielswei-se könnte es ebenso möglich sein, Klassen der JSF-Implementierung zu überschreibenund so in den JSF-Lebenszyklus einzugreifen. Hierdurch würde sich die Möglichkeitergeben, Sitzungsdaten an einer zentralen Stelle, wie zum Beispiel vor dem Absen-den eines Response, zu setzen. Weiterhin könnte versucht werden, JSF insoweit zubeeinflussen, dass nur noch Teile eines HTML-Formulars an das Frontend gesendetwerden. Dadurch würde das Zerlegen der Seite am Frontend entfallen.Einige Erweiterungen für den Durchstich könnten zum Beispiel sein, die Navigationam Frontend durchzuführen beziehungsweise die Frontendanwendung in ein Con-tent Management System zu integrieren. Über dieses könnte anschließend die Na-vigation und Ressourcen verwaltet werden. Ein interessantes Thema ist ebenfalls,die Frontendanwendung in Kombination mit Marketing-Kampagnen zu realisieren.Marketing-Kampagnen sind, im InetP-Umfeld, Sonderaktionen bei denen Kundenbestimmte, zeitlich begrenzte Angebote gemacht werden. Diese Anwendungen sindmeist relativ einfach aufgebaut und schnell zu implementieren. Weiterhin gehen die-se meist einen etwas anderen Weg als die eigentliche InetP-Anwendung und sindnicht zu stark an das System gekoppelt. Dieses Beispiel wäre eine denkbare Mög-lichkeit, den neuen Ansatz für erste praktische Tests umzusetzen und auch produktiveinzusetzen.Für den produktiven Einsatz ist der Ansatz allerdings noch zu unausgereift. Hiersind weitere Entwicklungen, vor allem in den Bereichen Sitzungsverwaltung undSicherheit nötig. Das Design der Anwendung kann weiterhin durch verschiedeneEntwurfsmuster der Softwareentwicklung verbessert werde. Es bietet sich hier vor


7. Zusammenfassung und Ausblick Fachhochschule Schmalkalden WS 2011/12

allem das Muster Chain of Responsibility an. Dieses kann dazu eingesetzt werden,den bereits erwähnten Filter, für das Senden der Anfrage-Parameter, zu entwickeln.Ein weiterer denkbarer Einsatz dieses Musters wäre, es ähnlich wie das Interceptor-Muster in der bestehenden Koop-Middleware zu verwenden. Dies würde vor allemdie Konfiguration und Erweiterbarkeit der Anwendung verbessern.Eine andere Möglichkeit ist es, den neuen Ansatz in die „alte“ Koop-Middleware zuintegrieren und somit die bewährten Konzepte, zu den genannten Themen anzupas-sen und zu nutzen. Dabei wären allerdings erhebliche Änderungen an der bestehen-den Koop-Middleware nötig.Die Arbeitsweise mit dem, im technischen Durchstich verwendeten Ansatz würdesich dahingehend ändern, dass die Koop-Komponente nur noch am Frontend um-gesetzt werden müsste. Die Backendanwendungen sind somit eigenständige Anwen-dungen und benötigen keine zusätzlichen Komponenten.


Literaturverzeichnis[Apa] Apache Software Foundation: Apache Struts. http://struts.

apache.org/. – [Online, Stand 28.10.2011]

[FFSB05] Freeman, Eric ; Freeman, Elisabeth ; Sierra, Kathy ; Bates, Bert:Entwurfsmuster von Kopf bis Fuß. O’Reilly, 2005

[Goo] Google Inc.: Google Web Toolkit. http://code.google.com/intl/de-DE/webtoolkit/overview.html. – [Online, Stand 28.10.2011]

[Hep08] Hepper, Stefan: Java Portlet Specification 2.0 (Final Relea-se). http://jcp.org/aboutJava/communityprocess/final/jsr286/index.html. Version: Januar 2008. – [Online, Stand 23.11.2011]

[Inva] Inverso GmbH: Architektur InetP. – internes Dokument

[Invb] Inverso GmbH: Entwickler-Leitfaden InetP. – internes Dokument

[Invc] Inverso GmbH: Projekte. http://www.inverso.de/inverso/projekte/index.html. – [Online, Stand 11.11.2011]

[Ker11] Kersken, Sascha: IT-Handbuch für Fachinformatiker. Galileo Compu-ting, 2011; http://openbook.galileocomputing.de/it_handbuch/. –[Online, Stand 17.11.2011]

[LH09] Laprun, Chris ; Heute, Thomas: JBoss Portal 2.7.1 - ReferenceGuide. http://docs.jboss.org/jbportal/v2.7.1/referenceGuide/html/tutorials.html. Version: Januar 2009. – [Online, Stand23.11.2011]

[MKM09] Marinschek, Martin ; Kurz, Michael ; Müllan, Gerald: JavaServerFaces 2.0: Grundlagen und erweiterte Konzepte. dpunkt Verlag, 2009;http://jsfatwork.irian.at/semistatic/introduction.html. – [On-line, Stand 30.11.2011]

[OM03] Ort, Ed ; Mehta, Bhakti: Java Architecture for XML Binding(JAXB). http://www.oracle.com/technetwork/articles/javase/index-140168.html. Version:März 2003. – [Online, Stand 11.11.2011]

[Sta] Stahl, Jens: Vorstellung des Google Web Toolkit. http://www.ordix.de/ORDIXNews/1_2007/Java_J2EE/google_web_toolkit_ajax.html. –[Online, Stand 11.11.2011]

Nico Pleyer40

http://struts.apache.org/

http://struts.apache.org/

http://code.google.com/intl/de-DE/webtoolkit/overview.html

http://code.google.com/intl/de-DE/webtoolkit/overview.html

http://jcp.org/aboutJava/communityprocess/final/jsr286/index.html

http://jcp.org/aboutJava/communityprocess/final/jsr286/index.html

http://www.inverso.de/inverso/projekte/index.html

http://www.inverso.de/inverso/projekte/index.html

http://openbook.galileocomputing.de/it_handbuch/

http://docs.jboss.org/jbportal/v2.7.1/referenceGuide/html/tutorials.html

http://docs.jboss.org/jbportal/v2.7.1/referenceGuide/html/tutorials.html

http://jsfatwork.irian.at/semistatic/introduction.html

http://www.oracle.com/technetwork/articles/javase/index-140168.html

http://www.oracle.com/technetwork/articles/javase/index-140168.html

http://www.ordix.de/ORDIXNews/1_2007/Java_J2EE/google_web_toolkit_ajax.html

http://www.ordix.de/ORDIXNews/1_2007/Java_J2EE/google_web_toolkit_ajax.html

Literaturverzeichnis Fachhochschule Schmalkalden WS 2011/12

[Tho08] Thompson, Rich: WSRP v2.0 Specification. http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec-os-01.html. Version:April 2008. – [On-line, Stand 11.11.2011]

[Ull10] Ullenboom, Christian: Java ist auch eine Insel. Galileo Computing,2010; http://openbook.galileocomputing.de/javainsel/. – [Online,Stand 17.11.2011]

Nico Pleyer41

http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec-os-01.html

http://docs.oasis-open.org/wsrp/v2/wsrp-2.0-spec-os-01.html

http://openbook.galileocomputing.de/javainsel/

A Anhang

A.1 Quelltext des ProxyServlet

Listing A.1: doGet()-Methode des ProxyServlet1 @SuppressWarnings (" unchecked ")2 @Override3 protected void doGet( HttpServletRequest req ,4 HttpServletResponse res)5 throws ServletException , IOException {6 HttpClient client = new DefaultHttpClient ();7 Session current ;8 String responseBody = "";9 boolean isHtml = false;

10

11 // --- init ---12 if ( sHandler . containsFEId (req. getSession ().getId ()))13 current = sHandler . getSessionByFEId (14 req. getSession ().getId ());15 else {16 current = new Session ();17 current . setSessionFE (req. getSession ().getId ());18 }19

20 try {21 // --- set requested URL ---22 HttpGet httpget =23 new HttpGet ( ServletHelper . editUrl (req)+24 ServletHelper . getUrlQuery (req));25

26 // --- set request parameters ---27 Map <String ,String []> params =28 req. getParameterMap ();29 for (String key : params.keySet ()) {30 httpget . getParams ()31 . setParameter (key , params.get(key)[0]);32 }33

34 // --- set request headers ---35 Enumeration <String > e = req. getHeaderNames ();36 while (e. hasMoreElements ()) {37 String name = e. nextElement ();38 String value = req. getHeader (name);39 if ("accept". equalsIgnoreCase (name) &&40 value. contains ("text/html")) {

Nico Pleyer42

A. Anhang Fachhochschule Schmalkalden WS 2011/12

41 isHtml = true;42 }43 if (!"content -length". equalsIgnoreCase (name)) {44 if ("cookie". equalsIgnoreCase (name)45 && value. contains (" JSESSIONID ")) {46 value = " JSESSIONID ="47 + current . getSessionBE ()48 +"; Path =/jsf2 - example ";49 }50 httpget . setHeader (name ,value);51 }52 }53

54 // --- executing request ---55 ResponseHandler <String > responseHandler =56 new BasicResponseHandler ();57 if(isHtml) {58 HttpResponse response = client. execute ( httpget );59 responseBody = responseHandler . handleResponse (60 response );61 Session tmp = setSessionData (req , response );62 current . setSessionBE (tmp. getSessionBE ());63 sHandler . addSession ( current );64

65 res = ServletHelper . handleResponseHeader (66 current , res , response );67 } else {68 responseBody = client. execute (httpget ,69 responseHandler );70 }71

72 // --- print response ---73 if (isHtml)74 manipulateResponse (current , res , responseBody );75 else76 printResponse (res , responseBody );77 } finally {78 client. getConnectionManager (). shutdown ();79 }80 }

Listing A.2: doPost()-Methode des ProxyServlet1 @SuppressWarnings (" unchecked ")2 @Override3 protected void doPost( HttpServletRequest req ,4 HttpServletResponse res)5 throws ServletException , IOException {6 HttpClient client = new DefaultHttpClient ();7 Session current ;8 String responseBody = "";9 boolean isAjax = false;

10

11 // --- init ---

Nico Pleyer43


12 if ( sHandler . containsFEId (req. getSession ().getId ()))13 current = sHandler . getSessionByFEId (14 req. getSession ().getId ());15 else {16 current = new Session ();17 current . setSessionFE (req. getSession ().getId ());18 }19

20 try {21 // --- set requested URL ---22 HttpPost httppost =23 new HttpPost ( ServletHelper . editUrl (req));24

25 // --- set request parameters ---26 List < NameValuePair > nameValuePairs =27 new ArrayList <NameValuePair >();28 Map <String ,String []> params =29 req. getParameterMap ();30 for (String key : params.keySet ()) {31 nameValuePairs .add(32 new BasicNameValuePair (key ,33 params.get(key)[0]));34 }35

36 httppost . setEntity (37 new UrlEncodedFormEntity ( nameValuePairs ,38 "UTF -8"));39

40 // --- set request headers ---41 Enumeration <String > e = req. getHeaderNames ();42 while (e. hasMoreElements ()) {43 String name = e. nextElement ();44 String value = req. getHeader (name);45

46 if ("faces - request ". equalsIgnoreCase (name)47 && " partial /ajax". equalsIgnoreCase (value)) {48 isAjax = true;49 }50

51 if (!"content -length". equalsIgnoreCase (name)) {52 if ("cookie". equalsIgnoreCase (name)53 && value. contains (" JSESSIONID ")) {54 value = " JSESSIONID ="55 + current . getSessionBE ()56 +"; Path =/jsf2 - example ";57 }58 httppost . setHeader (name ,value);59 }60 }61

62 // --- executing request ---63 ResponseHandler <String > responseHandler =64 new BasicResponseHandler ();65 HttpResponse response = client. execute ( httppost );

Nico Pleyer44


66 responseBody = responseHandler . handleResponse (67 response );68 Session tmp = setSessionData (req , response );69 current . setUserlevel (tmp. getUserlevel ());70 sHandler . addSession ( current );71

72 res = ServletHelper . handleResponseHeader (73 current , res , response );74

75 // --- print response ---76 if (isAjax)77 printResponse (res , responseBody );78 else79 manipulateResponse (current , res , responseBody );80 } finally {81 client. getConnectionManager (). shutdown ();82 }83 }

Nico Pleyer45


A.2 Beispiel einer Transport-XML

Listing A.3: Beispiel der Transport-XML einer Begrüßungsseite,Quelle: in Anlehnung an [Invb, S. 50f.]

1 <?xml version ="1.0" encoding ="UTF -8"?>2 <!DOCTYPE UNI_TRANSPORT SYSTEM3 "../ dtd/uni/ uni_transport .dtd">4 <UNI_TRANSPORT >5 <SERVICE ></ SERVICE >6 <ERROR ></ERROR >7 <TRANSFORM_ID >PREMIUM_HOME_VKB </ TRANSFORM_ID >8 <VU_SESSION_ID ></ VU_SESSION_ID >9 <USER_LEVEL >2</ USER_LEVEL >

10 <CONTENT >11 <![ CDATA [<?xml version ="1.0" encoding ="ISO -8859 -1"?>12 <!DOCTYPE KUNDENREGISTRIERUNG SYSTEM13 "../ dtd/ kundenregistrierung .dtd">14 <KUNDENREGISTRIERUNG >15 <UNI_KUNDENREGISTRIERUNG >16 <UNI_ALLG_ADR >17 <ADR_NAME >18 <ADR_NACHNAME >19 <UNI_DC >20 <FACH_VAL >Mustermann </ FACH_VAL >21 </UNI_DC >22 </ ADR_NACHNAME >23 <ADR_ANREDE >24 <UNI_DC >25 <FACH_VAL >Herr </ FACH_VAL >26 </UNI_DC >27 </ ADR_ANREDE >28 </ ADR_NAME >29 </ UNI_ALLG_ADR >30 <ANMELDEDATEN >31 <BENUTZER_KENNUNG >32 <UNI_DC >33 <FACH_VAL >Muster </ FACH_VAL >34 </UNI_DC >35 </ BENUTZER_KENNUNG >36 </ ANMELDEDATEN >37 <LETZTE_ERFOLGR_ANMELDUNG >38 <LETZTE_ERFOLGR_ANM_DATUM >39 <UNI_DC >40 <FACH_VAL >1.01.2011 </ FACH_VAL >41 </UNI_DC >42 </ LETZTE_ERFOLGR_ANM_DATUM >43 </ LETZTE_ERFOLGR_ANMELDUNG >44 </ UNI_KUNDENREGISTRIERUNG >45 </ KUNDENREGISTRIERUNG >]]>46 </CONTENT >47 </ UNI_TRANSPORT >

Nico Pleyer46


A.3 Abbildungen der Backendanwendung

Abbildung A.1: Projektstruktur der Backendanwendung,Quelle: eigene Darstellung (erstellt mit Eclipse)

Nico Pleyer47


Abbildung A.2: Klassendiagramm der Backendanwendung,Quelle: eigene Darstellung

Nico Pleyer48


A.4 Installation der AnwendungenUm den technischen Durchstich auf einem System zu installieren sind lediglich zweiInstallationen des Apache Tomcat 6 nötig. Diese müssen, wie bereits im Laufe derArbeit beschrieben, konfiguriert werden. Mit Hilfe der folgenden Schritte können dieAnwendungen über den Browser erreicht werden.(1) Wie in Listing 6.1 beschrieben, die Ports an denen die Server auf eingehende

Anfragen warten sollen ändern. Diese müssen sich voneinander unterscheiden.Beispielsweise können die Ports 8080 und 8081 verwendet werden.

(2) Die beiden Anwendungen müssen anschließend auf je einem Server verteilt wer-den. Das .war-Archiv der jeweiligen Anwendung muss hierfür in das Verzeich-nis webapps der Tomcat-Installation kopiert werden.

(3) Die Webserver können nun über die Tomcat6.exe, im bin-Verzeichnis gestartetwerden.

Anschließend können die Anwendungen, über die folgenden URLs, im Browser er-reicht werden.

• http://localhost:8080/jsf2-example/• http://localhost:8081/jsf2-example/

Gegebenenfalls müssen die Ports an die jeweilige Serverkonfiguration beziehungs-weise an die Konfiguration des ProxyServlet angepasst werden. Das ProxyServletverwendet standardmäßig die beiden oben genannten Ports.Ist die Anwendung installiert, können die folgenden Nutzer zur Anmeldung verwen-det werden. Weitere Nutzer können in der Methode initUsers(), der Klasse UserSer-vices, angelegt werden.

Nutzer Passwortadmin adminuser1 user1user2 user2

Tabelle A.1: Nutzer der Backendanwendung, Quelle: eigene Darstellung

Zur Weiterentwicklung beziehungsweise zum Analysieren der Anwendungen, könnendie Projekte in Eclipse importiert werden. Die Eclipse Java EE IDE for Web De-velopers bietet hierzu eine Funktion an, die über den Menüpunkt File > Import...erreicht werden kann. Über die Kategorie General und den Punkt Existing Projectsinto Workspace können die Projekte in den Eclipse Workspace integriert werden. Esempfiehlt sich in der Entwicklungsumgebung das Plugin m2eclipse zu installieren.Mit Hilfe dessen können die Projekte über die Kategorie Maven und den PunktExisting Maven Projecs direkt als Maven-Projekte eingebunden werden.

Nico Pleyer49

http://localhost:8080/jsf2-example/

http://localhost:8081/jsf2-example/

Abbildungsverzeichnis

1.1 Kommunikation zwischen Koop Front- und Backend . . . . . . . . . . 1

2.1 InetP Systemübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Aufbau des Koop-Frontends . . . . . . . . . . . . . . . . . . . . . . . 52.3 Aufbau des Koop-Backends . . . . . . . . . . . . . . . . . . . . . . . 62.4 Ablauf einer Anfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

4.1 Aufbau einer Portalseite . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Aufbau einer JAXB-Anwendung . . . . . . . . . . . . . . . . . . . . . 16

6.1 Aufbau des technischen Durchstichs . . . . . . . . . . . . . . . . . . . 226.2 Projektstruktur der Frontendanwendung . . . . . . . . . . . . . . . . 246.3 Klassendiagramm der Frontendanwendung . . . . . . . . . . . . . . . 256.4 Phasen der Bearbeitung einer Anfrage . . . . . . . . . . . . . . . . . 26

A.1 Projektstruktur der Backendanwendung . . . . . . . . . . . . . . . . . 47A.2 Klassendiagramm der Backendanwendung . . . . . . . . . . . . . . . 48

Nico Pleyer50

Tabellenverzeichnis

2.1 Elemente des Koop-XML . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1 Bewertung der Anforderungen . . . . . . . . . . . . . . . . . . . . . . 12

6.1 Scopes einer ManagedBean . . . . . . . . . . . . . . . . . . . . . . . . 36

A.1 Nutzer der Backendanwendung . . . . . . . . . . . . . . . . . . . . . 49

Nico Pleyer51

Listings

6.1 Port-Konfiguration des Tomcat in der server.xml . . . . . . . . . . . . 216.2 Initialisieren der Sitzung . . . . . . . . . . . . . . . . . . . . . . . . . 266.3 Deklaration und Initialisierung des HttpClient . . . . . . . . . . . . . 276.4 Methode zum Bearbeiten der Anfrage-URL . . . . . . . . . . . . . . . 276.5 Methode zum Lesen des Query-Strings . . . . . . . . . . . . . . . . . 276.6 Setzen der Request-Parameter in der GET-Methode . . . . . . . . . . 286.7 Setzen der Request-Header in der GET-Methode . . . . . . . . . . . . 286.8 Senden eines Request über die GET-Methode . . . . . . . . . . . . . 296.9 Methode zum Behandeln der Sessiondaten . . . . . . . . . . . . . . . 306.10 Methode zum Übernehmen der Response-Header . . . . . . . . . . . . 316.11 Methode zum Ausgeben von HTML-Antworten . . . . . . . . . . . . 316.12 Methode zum Ausgeben von Ressourcen . . . . . . . . . . . . . . . . 326.13 POST Objekt initialisieren und deklarieren . . . . . . . . . . . . . . . 336.14 Setzen der Request-Parameter in der POST-Methode . . . . . . . . . 336.15 Setzen der Request-Header in der POST-Methode . . . . . . . . . . . 346.16 Senden eines Request über die POST-Methode . . . . . . . . . . . . . 346.17 Methode zum Ausführen der Login-Aktion . . . . . . . . . . . . . . . 35

A.1 doGet()-Methode des ProxyServlet . . . . . . . . . . . . . . . . . . . 42A.2 doPost()-Methode des ProxyServlet . . . . . . . . . . . . . . . . . . . 43A.3 Beispiel der Transport-XML einer Begrüßungsseite . . . . . . . . . . 46

Nico Pleyer52

Eidesstattliche ErklärungIch versichere an Eides Statt durch meine eigenhändige Unterschrift, dass ich dievorliegende Arbeit selbstständig und ohne fremde Hilfe angefertigt habe. Alle Stel-len, die wörtlich oder dem Sinn nach auf Publikationen oder Vorträgen andererAutoren beruhen, sind als solche kenntlich gemacht. Ich versichere außerdem, dassich keine andere als die angegebene Literatur verwendet habe. Diese Versicherungbezieht sich auch auf alle in der Arbeit enthaltenen Zeichnungen, Skizzen, bildlichenDarstellungen und dergleichen.

Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch nochnicht veröffentlicht.

Martinroda,den 11. Dezember

2011Ort, Datum Nico Pleyer

Nico Pleyer53

Reengineering einer Middleware (KOOP) für die transparenteund lose Kopplung von WebFrontends (CMS,...

Documents

Transcript of Reengineering einer Middleware (KOOP) für die transparenteund lose Kopplung von WebFrontends (CMS,...