1 Kurzfassung II

1 Kurzfassung

Portaltechnologien bieten eine ideale Grundlage, um dem Anwender eine auf seine Bed¨ urfnisse zugeschnittene Bedienoberfl¨ ache abzubilden. Um dies zu erreichen wird die Software in Module gegliedert. Diese werden dann in Form von Portlets im Portal deployed ¹ und k¨ onnen von einem

Anwender auf Basis seiner Berechtigungen im Portal angezeigt werden. Der Autor Timo Kussmaul hat in einem Artikel der Fachzeitschrift Java Spektrum aus dem Jahr 2005 die Begriffe Portlet und Portal wie folgt definiert:

“Ein Portal bildet die Pr¨ asentationsschicht eines web-basierten Informationssystems und integriert die Inhalte verschiedener Anwendungen und Anwendungskomponenten. [...] Ein Portlet ist eine Web-basierte Java-Komponente, die von einem Portlet-Container verwaltet wird, Anfragen (Requests) verarbeitet und dynamisch Inhalte erzeugt.” [10, S. 39]

Der Einsatz der Portaltechnolgie wurde von der Firma Siemens schon mehrfach erfolgreich durchgef¨ uhrt. Aufgrund des stetig wachsenden Planungskontextes in der Industrie muss ein Ziel der zuk¨ unftigen Entwicklungen sein, dass die Informationen nicht nur st¨ arker verdichtet, sondern vom Benutzer auch zentral gesteuert werden k¨ onnen. Aus diesem Grund muss eine Kommunikation auch ¨ uber Portletgrenzen hinweg erfolgen k¨ onnen.

Die Erreichung dieses Ziels bietet dann die M¨ oglichkeit, darstellende Elemente in einem Portal von einem zentralen Portlet aus zu steuern.

Ziel dieser Bachelorarbeit ist es, eine Strategie zur Interportletkommunikation zu evaluieren und am Beispiel des TAMS-Projekts der Siemens AG im Kontext der Flughafenressourcenplanung zu implementieren.

¹ Als Deployment bezeichnet man die Installation einer Applikation in einem speziellen Kontext.

Fabian Pagel Siemens AG

2 Danksagung III

2 Danksagung

Ganz besonders m¨ ochte ich meinem Betreuer Dr. Hanno Walischewski und meinem Zweitgutachter Prof. Dr. Andreas Judt danken. Dr. Hanno Walischewski und Dietmar B¨ ohme m¨ ochte ich zus¨ atzlich f¨ ur das Thema selbst danken und f¨ ur ihr großes Engagement in der nicht einfachen Betreuungssituation ¨ uber mehrere hundert Kilometer. Trotz dieser Umst¨ ande haben sie mich stets in die richtige Richtung gelenkt.

Sehr dankbar bin ich auch all meinen Arbeitskollegen, die mir stets mit Rat und Tat zur Seite standen, wenn einmal etwas nicht funktioniert hat. Auch hier war die Entfernung zwischen Konstanz und Braunschweig oft ein Grund, aber kein Hindernis.

Bedanken m¨ ochte ich mich auch bei meinen Eltern Wolfgang und Evelin Pagel, sowie Cornelia Siebig f¨ ur das Aufsp¨ uren einiger sprachlicher und logischer Unstimmigkeiten. Der selbe Dank gilt meiner Schwester Stephanie, die mit geschultem Auge die gesamte Arbeit durchgegangen ist und zahlreiche sprachliche Fehler aufgedeckt hat.

Zuletzt m¨ ochte ich mich auch noch einmal bei Conny bedanken, denn sie war ein willkommener und liebreizender Grund, die Arbeit am Wochenende einmal ruhen zu lassen.

Fabian Pagel Siemens AG

Inhaltsverzeichnis IV

Inhaltsverzeichnis   

1  Kurzfassung  II

2  Danksagung  III

3  Einleitung  1

4  Aufgabenstellung  2

4.1  Zielsetzung  2

4.2  Verwendete Technologien  2

4.3  Aufbau der Architektur  3

5  Methoden  5

5.1  Interportletkommunikaton  5

5.1.1  Portlet 2.0 JSR 286  5

5.1.2  Portlet Messaging Library  6

5.1.3  ICEfaces AJAX-Push  7

5.2  Chartintegration  10

5.2.1  Techniken  10

5.2.2  Frameworks  11

5.3  Testm oglichkeiten  15

5.3.1  Techniken  15

5.3.2  Frameworks  16

6  Ergebnisse  18

6.1  Interportletkommunikation  18

6.2  Charting  33

6.3  Integration  39

6.4  Tests  40

7  Diskussion der Ergebnisse  46

8  Schlussfolgerungen  48

9  Zusammenfassung  49

Abbildungsverzeichnis   50

Fabian  Pagel Siemens AG  

Inhaltsverzeichnis V

Listings   51

Glossar   52

Literaturverzeichnis   54

Fabian  Pagel Siemens AG  

3 Einleitung 1

3 Einleitung

Aktuell wird auf Wunsch des Kunden in der Industrie und im Zuge des Web 2.0 Hypes vermehrt auf Webtechnologien gesetzt. Die Firma Siemens setzt hierbei auch auf die so genannten Portaltechnologien. Diese bieten die M¨ oglichkeit den Steuerungs- und Planungskontext durch austauschbare Modulen anzupassen.

Durch die zunehmende Informationsdichte wird der Anwender immer st¨ arker gefordert, so dass schon bei der Entwicklung der Weboberfl¨ ache darauf geachtet werden muss, dass nur die relevanten Informationen angezeigt werden und die Module sich untereinander abgleichen. In Bezug auf die Portaltechnogien ist die erste Anforderung aufgrund der Modularisierbarkeit bereits abgedeckt. Die zweite Anforderung soll auf Basis der Interportletkommunikation evaluiert und am Beispiel der Steuerung von zwei Charts in der Flughafenressourcenplanung implementiert werden.

Dazu muss neben der Evaluierung der Interportletkommunikation auch noch der Einsatz eines geeigneten Charting-Frameworks erfolgen.

Fabian Pagel Siemens AG

4 Aufgabenstellung 2

4 Aufgabenstellung

In diesem Kapitel soll die Aufgabenstellung konkretisiert und die Vorgaben der Firma Siemens in Bezug auf diese Arbeit dargestellt werden. Die Vorgaben teilen sich dabei in die aktuell verwendeten Technologien und die Architektur f¨ ur die Integration der Beispielapplikation auf.

4.1 Zielsetzung

Die Zielsetzung dieser Arbeit ist die Evaluierung verschiedener Ans¨ atze mit denen in zuk¨ unftigen Projekten der Siemens AG Portlets untereinander kommunizieren k¨ onnen. Dabei ist die Idee, in der Beispielimplementierung Charts auf Basis eines Steuerungsportlets zu konfigurieren. Bisher wurden Charts nur zur einfachen Visualisierung von IST-Zust¨ anden verwendet. Im Zuge dieser Arbeit ist ein zus¨ atzliches Ziel die Integration eines geeigneten Chartingframeworks in das ICEfaces Framework. Dabei soll, falls m¨ oglich, ein besonderes Augenmerk auf die folgenden Punkte der Chartimplementierung gelegt werden:

• Aktualisierung der Charts bei neuen Daten

• Beispielapplikation unter Verwendung eines Balkendiagramms

• Umschaltung zwischen fixierter und fortlaufender Zeitachse

• Steuerung mehrerer Charts durch IPC

Die bestehende Technologie wird im folgenden Kapitel n¨ aher beleuchtet. Um die L¨ osungsans¨ atze auch zuk¨ unftig nutzen zu k¨ onnen, wurde weiterhin definiert, dass die gesamte Funktionalit¨ at der Beispielapplikation durch Tests abgedeckt und in den DailyBuild-Mechanismus zu integrieren sind.

4.2 Verwendete Technologien

Die Siemens AG in Konstanz setzt bei der Entwicklung von Webanwendungen auf eine Vielzahl von verschiedenen Tools und Frameworks. Wegweisend dabei ist die Verwendung des so genannten Liferay-Portals ² . Das Liferay-Portal ist die Grundlage f¨ ur die Entwicklung und bie-

tet aufgrund der Modularisierbarkeit sehr gute M¨ oglichkeiten, um dem Benutzer nur die f¨ ur ihn wichtigen Informationen anzuzeigen.

Liferay Portal bietet dabei die folgenden Kernfunktionalit¨ aten:[20]

• Sichere Authentifizierung und rollenbasierte Autorisierung ¨ uber Single Sign-on

² http://www.liferay.com

Fabian Pagel Siemens AG

4 Aufgabenstellung 3

• Personalisierung der Seiten sowie Anordnung von Web-Elementen durch die Benutzer mittels Drag and Drop • Automatischer Upload von Dateien mittels WebDAV

• Taggen und Suchen von Web-Inhalten, Dokumenten, Benachrichtigungen, etc.

• Mehrsprachige Benutzerf¨ uhrung sowie Unterst¨ utzung von mehrsprachigen Organisationen

• Plattformunabh¨ angigkeit, Skalierbarkeit und Replikationsunterst¨ utzung

Die Verwendung des Liferay-Portals schr¨ ankt wiederum auch die zur Verf¨ ugung stehenden Fra-meworks ein. Die Firma Siemens nutzt zur Entwicklung von Portalapplikationen JSF in Verwendung mit dem ICEfaces-Framework.

JavaServer Faces ist im Java Specification Request 127 definiert und wird als Framework zur Entwicklung von Weboberfl¨ achen eingesetzt. Dabei baut es auf die Technologie von Servlets und JSP auf.

ICEfaces ist ein AJAX-basiertes Framework und bringt eine Vielzahl an Webkomponenten zur GUI-Entwicklung mit. Dabei setzt ICEfaces auf JSF auf und bietet die M¨ oglichkeit zur Entwicklung von Rich Clients im Java-EE Umfeld. Besonders hervorzuheben ist neben der nahtlosen Integration in die JEE-Technolgie, auch die Unterst¨ utzung f¨ ur die Portletentwicklung. Wichtig dabei ist es zu wissen, dass ICEfaces 1.x auf die JSR 168 aufsetzt und somit nur die Portlet 1.0 Technologie unterst¨ utzt. Erst mit der Portlet 2.0 (JSR286) Spezifikation ist auch die Interportletkommunikation spezifiziert. ICEfaces plant mit der Version 2.x auch die neue Spezifikation umzusetzen.[12, vgl. Kap. 6.5.4] Damit w¨ are es dann m¨ oglich, die Kommunikation zwischen Portlets auch direkt herzustellen.

In Bezug auf das Testframework sind kein Vorgaben gesetzt. Zur Auswahl stehen Unit- und Integrationstests sowie Webtests. Die Wahl eines geeigneten Ansatzes f¨ ur die Implementierung der Tests wird auf Basis vorhergehenden Technologieentscheidung getroffen. Diese Vorgaben sind ausschlaggebend f¨ ur die Wahl der richtigen L¨ osung und dem Einsatz weiterer Tools und Frameworks.

4.3 Aufbau der Architektur

Die Firma Siemens hat schon bei der Einf¨ uhrung von Portalapplikationen darauf geachtet, dass diese leicht skalierbar und somit effizient an die Kundenbed¨ urfnisse angepasst werden k¨ onnen. Dazu setzt man auf ein Cluster von Weblogic Applikationsservern, die untereinander einen Ver-bund bilden und wiederum auf eine oder mehrere Datenbanken zugreifen k¨ onnen. Jeder Applikationsserver ist mit der gleichen Software best¨ uckt. So wird neben der Business Logik auch Liferay auf dem Applikationsserver deployed.

Fabian Pagel Siemens AG

4 Aufgabenstellung 4

Die einzelnen Portlets k¨ onnen dann wiederum im Liferayportal als so gennante Portletcontainer deployed werden. Jeder Portletcontainer ist ein eigenst¨ andiges Modul mit eigenem Classloader, wenn dieser separat deployed wird. Dieses Prinzip gilt auch im Applikationsserver. Um die Portalseiten an die Clients ausliefern zu k¨ onnen, agieren auf dem Applikationsserver ein oder mehrere Webserverinstanzen, die wiederum ¨ uber das HTTP-Protokoll an die Clients

gebunden werden. Um die Skalierbarkeit hierbei zu gew¨ ahrleisten, w¨ are zum Beispiel der Einsatz eines Loadbalancers auf Basis eines Apache-Webservers denkbar.

Fabian Pagel Siemens AG

5 Methoden 5

5 Methoden

In diesem Abschnitt werden die zur Auswahl stehenden Methoden n¨ aher betrachtet. Hierbei wird zwischen Portletkommunikation und Chartintegration unterschieden. Diese beiden Themen sind voneinander losgel¨ ost und werden daher in diesem Kapitel getrennt betrachtet.

5.1 Interportletkommunikaton

Interportletkommunikation beschreibt den Vorgang, wie zwei unabh¨ angige Portlets innerhalb eines Portals Daten untereinander austauschen k¨ onnen.

Mit der Spezifikation des JSR 168, den Kussmaul in seinem Artikel[10, S. 39ff] behandelt, wird das Portlet n¨ aher beschrieben. Ziel ist es die Portalkomponenten von den Portalen verschiedener Anbieter loszul¨ osen und somit eine Plattformunabh¨ angigkeit zu erzeugen. Zum Zeitpunkt der Spezifikation wurde die Interportletkommunikation nicht n¨ aher betrachtet. Somit gibt es keinen einheitlichen Standard zur Kommunikation zwischen den Portalkomponenten. Erst mit der Spezifikation des Portlets 2.0 (JSR286) und der Ver¨ offentlichung im Jahr 2008 wurde die IPC mitaufgenommen. Dieser Ansatz wird im folgenden Unterkapitel 5.1.1 n¨ aher betrachtet.

5.1.1 Portlet 2.0 JSR 286

Wie aus der Einleitung zu diesem Kapitel hervorgeht, handelt es sich bei der Portlet 2.0 Spezifikation um eine Erweiterung der bestehenden Portlet 1.0 Spezifikation aus dem Jahr 2003. Die aktuelle Portletspezifikation wurde 2008 verabschiedet und bringt wesentliche Neuerungen f¨ ur Portlets mit sich. Mit diesem Thema hat sich auch der Autor Reza Nazarian in der Fachzeitschrift Java Spektrum[14, S. 32ff] besch¨ aftigt. Er stellt hierbei die wesentlichen Neuerungen wie folgt heraus:

“JSR 286 im ¨ Uberblick • Events f¨ ur aktives Messaging

• Innerhalb des Portals verf¨ ugbare Public Render Parameters

• Verbesserte AJAX-Unterst¨ utzung

• Portlet Filter

• Verbessertes JSP/Servlet-Dispatching”[14, S. 32]

In Bezug auf die Kommunikation zwischen den Portlets stellt der Autor des Artikels heraus, dass nun erstmals ein Eventing zwischen Portlets m¨ oglich ist. Dadurch k¨ onnen einfache Datentypen oder per JAXB nach XML serialisierbare Java-Objekte verwendet werden.

Fabian Pagel Siemens AG

5 Methoden 6

Er warnt aber auch davor, dass dies kein verl¨ asslicher Ersatz f¨ ur bestehendes Messaging, wie zum Beispiel JMS sei, da Portlets nicht f¨ ur die Zustellung der Events garantieren m¨ ussen. Somit geht aus der JSR 286 Spezifikation klar hervor, dass nun verschiedene Mechanismen existieren, um die IPC direkt implementieren zu k¨ onnen. Setzt man die Spezifikation jedoch in Bezug zu den bereits eingesetzten Technologien im Siemens Umfeld, so wird klar, dass aufgrund der eingesetzten Version von ICEfaces 1.8.3 im aktuellen Projekt die Vorteile der JSR 286 nicht verwendet werden k¨ onnen.

F¨ ur zuk¨ unftige Projekte sollte man jedoch im Blick behalten, dass ICEfaces plant, mit der Version 2.x die neue Spezifikation f¨ ur Portlets umzusetzen (s. Kap. 4.2). Dadurch k¨ onnte der Einsatz von IPC deutlich effizienter werden, denn wie Nazarian schreibt, ist auch schon mit der JSR 168 eine IPC m¨ oglich, jedoch aufgrund der Verwendung von Sessionparametern nur sehr eingeschr¨ ankt.

5.1.2 Portlet Messaging Library

Die Portlet Messaging Library[15] ist eine Bibliothek zur Erweiterung der Portlet 1.0 Spezifikation, um die fehlende Interportletkommunikation. Dabei bedient sich die Portlet Messaging Library diverser vorhandener Mittel, die im Folgenden kurz im Zusammenhang mit der Funktionalit¨ at erl¨ autert werden.

Wie in Abbildung 1 ersichtlich, basiert die Kommunikation auf dem Session Application Scope. Dieser ist ¨ uber die gesamte Applikation hinweg verf¨ ugbar und somit k¨ onnen Portlets auch

Fabian Pagel Siemens AG

5 Methoden 7

uber Portalseiten hinweg Werte untereinander austauschen. Dabei sind laut dem Autor der ¨

Bibliothek[15] verschiedene Einschr¨ ankungen vorhanden:

• Das Caching von Portlets kann verhindern, dass ein ge¨ anderter Wert in einer View dargestellt wird.

• Ein nachtr¨ agliches Hinzuf¨ ugen von Portlets verhindert, dass diese mit bereits existierenden Portlets kommuzieren k¨ onnen.

Ein weiterer Punkt, der nicht auf der Webseite aufgef¨ uhrt ist, ist die Tatsache das keine AJAX-Unterst¨ utzung vorhanden ist. Das bedeutet, dass das Senden einer Nachricht die verkn¨ upften Portlets nicht per Ajax automatisch aktualisiert. Diese Funktionalit¨ at m¨ usste nachtr¨ aglich implementiert werden. Weiterhin liegen aufgrund des Alters der Bibliothek keine Informationen auf eine m¨ ogliche Wechselwirkung mit dem ICEfaces Framework vor. Jedoch ist diesem Framework positiv anzumerken, dass es die Verfolgbarkeit zwischen lokalen und globalen Verkn¨ upfungen gew¨ ahrleistet. Auch eine nachtr¨ agliche ¨ Anderung der Ver-

kn¨ upfungen ist durch den Portaladministrator oder den Anwender m¨ oglich, ohne dass daf¨ ur der Code der Anwendung ge¨ andert werden muss.

5.1.3 ICEfaces AJAX-Push

Bei AJAX-Push handelt es sich um eine Technologie, die mit dem ICEfaces Framework geliefert wird. Bei fast allen verf¨ ugbaren Javascript-AJAX-Frameworks besteht das Problem, dass diese nur vom Client initiierte Anfragen verarbeiten. Dieses Verhalten ist jedoch durch die Implementierung der XMLHttp-Schnittstelle gepr¨ agt, die vom Client bei Bedarf erzeugt wird und entweder einen synchronen oder einen asynchronen Request an einen Server absetzt. Das ICEfaces Framework geht hierbei einen Schritt weiter und baut schon beim ersten Aufruf einer Seite auf einem Client diese Verbindung auf. Damit die Verbindung nicht in ein Timeout l¨ auft, werden vom Server immer wieder Nachrichten an den Client gesandt. Dadurch wird ein dauerhafter R¨ uckkanal zum Client realisiert, der bisher in der Implementierung der XMLHttp-Schnittstelle in Browsern so nicht vorgesehen war. Die Abbildung 2 zeigt zun¨ achst den erweiterten Ajax Zyklus, bei dem nur inkrementelle Updates an den Client ¨ ubertragen werden. Dabei wird zun¨ achst eine asynchrone Anfrage mittels XMLHttp (AJAX) an den Server ubermittelt (Schritt 1). Diese Anfrage startet den JSF-Lifecycle mit der Phase Application State ¨

Change (Schritt 2). In der darauffolgenden Renderphase wird der Komponentenbaum neu aufgebaut (Schritt 3). Im Gegensatz zur Standard JSF Implementierung werden im Schritt 4 die ¨ Anderungen des Komponentenbaums mit dem zuvor erstellten Komponentenbaum verglichen und nur ein inkrementelles Update an den Client ¨ ubertragen (Schritt 5), der dieses wiederum in seinen Komponentenbaum einbindet (Schritt 7).

Fabian Pagel Siemens AG