Entwicklung eines Unternehmensportals

Transkript

1 F Entwicklung eines Unternehmensportals Enterprise Portal Development Dominique Brogard Master Abschlussarbeit Betreuer: Prof. Dr. Andreas Künkler Trier,

2 Kurzfassung Der Einsatz von Unternehmensportalen zum Austausch oder zur Erweiterung von Intranets ist eine zukunftsträchtige Lösung, welche in der Java-Welt vor allem durch die zugehörige Portlet-Spezifikation an Attraktivität gewonnen hat, da die Festlegung auf die Verwendung bestimmter Produkte und die somit entstehende Abhängigkeit von zugehörigen Herstellern stetig abnimmt. Unternehmensportale bieten die Möglichkeit diversifizierte Informationen für ihre Benutzer effizient, strukturiert und personalisiert darzustellen. Sie erlauben die Integration externer Anwendungen in Form so genannter Portlets. In der vorliegenden Ausarbeitung wird anhand des Liferay Portal Professional, die Einrichtung eines Unternehmensportals, sowie die Entwicklung zugehöriger Portlets veranschaulicht. Letzteres findet unter Anwendung des Unified Process als Beispiel eines iterativen und evolutionären Entwicklungsprozesses statt. The use of enterprise portals for the exchange via or the extension of existing intranet systems is bound to be a seminal solution, one which (in the Java world at least) has gained much influence since the advent of the recent Java Portlet specification, mainly due to the fact that it reduces dependencies on specific products or product vendors. Enterprise portals provide the ability to present a wide diversity of information in ways that are not only efficient and well-structured, but also equally adapted to ones personal viewing preferences as well. They allow the integration of external applications in the form of so-called Portlets. The report at hand shall demonstrate the creation of an enterprise portal by means of leveraging the Liferay Portal Professional product, along with the development of some of the necessary Portlets and other customizations. The latter shall be built upon the Unified Process as an example for an iterative and evolutionary development process.

3 Inhaltsverzeichnis 1 Einleitung Problemstellung Aufgabenstellung und Zielsetzung Durchführung Einrichtung des Unternehmensportals Technische Funktionsweise und Begriffserläuterungen Installation des Portal Frameworks Benutzereinrichtung und -verwaltung Nutzung des Content Management Systems Anpassung der Benutzeroberfläche Java Portlets: Spezifikation und Entwicklung Spezifikationsspezifische Begriffsdefinitionen Portalseiten und ihre Erzeugung Lebenszyklus eines Portlets Der PortletMode und seine Verwendung Der WindowState und seine Verwendung Das PortletURL Objekt und seine Verwendung Erläuterung des Portlet Requests Erläuterung der Portlet Response Das PortletPreferences Interface Das PortletSession Interface Das PortletContext Interface Portlets im Zusammenhang mit Servlets Die Time Reporting Portletanwendung Verwendete Technologien Die Technologie Hibernate und ihre Anwendung Das DAO Pattern Das Spring Framework und seine Anwendung Die Verwendung der Portlet Tag Library und des Model Objektes innerhalb einer JSP

4 Inhaltsverzeichnis IV Konfiguration des Portlet Deployment Descriptors Anwendung des Unified Process Zugehörige Entwicklungsphasen Zugehörige Entwicklungsdisziplinen UP vs. RUP Anwendung des UP am Beispiel der Entwicklung des Alfresco Explorer Portlets Zusammenfassung Literatur Glossar

5 Abbildungsverzeichnis 4.1 Portalseite und ihre Elemente Verwaltungshierarchie innerhalb des Portals Beispielhafte Ressourcen- und Rechteverwaltung Konzeptioneller Aufbau eines Liferay Themes Schematischer Ablauf der Erzeugung einer Portalseite Skizze der unterschiedlichen Abläufe beider Requesttypen Entitäten der Time Reporting Anwendung und ihre Beziehungen Auszug aus der Tabelle MEMBERROLES Module des Spring Frameworks UP Disziplinen Angepasster UP zur Entwicklung des Alfresco Explorer Portlets

6 1 Einleitung Seit dem Einzug des Internet als festem Bestandteil der informationstechnologischen Infrastruktur in Unternehmen und dessen Verwendung als globale Kommunikationsplattform zum Austausch von Informationen mit externen Partnern und Kunden, hat sich eine Vielzahl konzeptionell und technologisch gleichartiger Plattformen entwickelt, deren gemeinsames primäres Ziel die Bereitstellung von Informationen und der Austausch von Daten ist. Unterschiedliche Ansätze, verbunden mit unterschiedlichen Verwendungszwecken, haben im Laufe der Zeit zur Herausbildung einer Vielzahl an Produktkategorien geführt. Ob Intranet, Extranet oder Portal 1, diese schwer abzugrenzenden Begriffe haben sich zu Schlagwörtern der im Kontext der Geschäftsprozessoptimierung auftauchenden Frage nach einer technisch homogenen Unternehmensplattform entwickelt. Der Begriff Portal muss in Abhängigkeit des zugehörigen Kontextes unterschiedlich verstanden werden. Die auf die Informatik bezogene, ursprüngliche Bedeutung des Ausdrucks Portal findet ihre Verwendung in der Beschreibung einer Einstiegsseite in das Internet, wie sie von verschiedenen Providern 2 angeboten wird, um dem Benutzer einen zentralen und übersichtlichen Ausgangspunkt zu bieten [KGHV04, Kapitel 1, Abschnitt 1]. Aus dieser ursprünglichen Idee heraus hat sich eine weitere Portalform im Zuge ständiger Erweiterungen und konzeptioneller Änderungen entwickelt. Die ursprüngliche Idee des Portals als zentraler Einstiegspunkt wurde dabei übernommen, von Firmen aufgegriffen und an deren Bedürfnisse angepasst. Durch diese Anpassung an einen neuen Kontext unterscheidet sich der Funktionsumfang in vielen Bereichen von der vorangegangenen Form. Diese neue Portalform wird auch als Enterprise Portal (dt.: Unternehmensportal) bezeichnet. Unternehmensportale bieten ihren Benutzern personalisierten Zugriff auf unternehmensspezifische Informationen und Prozesse (bzw. Prozessinstanzen). Der Benutzer erhält auf diese Weise ausschließlich Zugriff auf solche Informationen, die entsprechend seiner Rolle im Unternehmen für ihn relevant sind. Auch fungie- 1 lat.: porta, Pforte 2 hier: Anbieter von Telekommunikationsdiensten, wie z.b. AOL, T-Online

7 1 Einleitung 2 ren Unternehmensportale als Integrationsplattformen mit dem Ziel, dem Benutzer einen zentralen Zugang auf firmeninterne Anwendungen zu bieten. Durch die dabei angestrebte Vereinheitlichung der unterschiedlichen Benutzeroberflächen, sowie die Reduzierung auf eine einmalige Anmeldung am Portal an Stelle einer einzelnen Authentifizierung für jede Anwendung, wird deren Handhabung insgesamt vereinfacht. Die Entwicklung von Unternehmensportalen geschieht in der Regel unter Verwendung so genannter Portal-Standard-Software. Portal-Standard-Software Produkte dienen als vorgefertigtes Portalgerüst und stellen bereits entsprechende Funktionalität zur Verfügung, welche die verschiedenen Aspekte eines Unternehmensportals berücksichtigt, wie z.b. den bereits beschriebenen Aspekt der Personalisierung. Im Zuge der Entwicklung von Portal-Standard-Software Produkten entstand gleichzeitig eine Reihe zugehöriger Schnittstellenspezifikationen, welche die Integration externer Anwendungen und die Anbindung von einheitlichen Frontends 3 unterstützen. Die vorliegende Masterabschlussarbeit, deren Ausführungsort das Informatikunternehmen infeurope ( mit Sitz in Luxembourg ist, befasst sich mit der Entwicklung eines an das Unternehmen angepassten Enterprise Portal. Die Schwerpunkte der Firma infeurope liegen in der Durchführung von inhouse Projekten zur Entwicklung kundenspezifischer Software, vorwiegend im Bereich europäischer Verwaltungseinrichtungen, sowie in der Unterstützung von externen Softwareentwicklungen durch Bereitstellung von Entwicklungskräften. Neben Standardprodukten, wie z.b. dem herkömmlichen Microsoft Office Paket, verwenden die Mitarbeiter des Unternehmens eine Reihe von teilweise selbst programmierten Anwendungen zur Durchführung alltäglicher Aufgaben. Dazu gehören z.b. Resource-Planning- und Projektverwaltungssysteme sowie Foren und Templatearchive. Diese teilweise webbasierten und von allen Mitarbeitern benutzten Anwendungen bilden gemeinsam ein heterogenes Netz von Einzelanwendungen, welches als das Intranet des Unternehmens infeurope bezeichnet werden kann. Dieser Sachverhalt bildet die Ausgangsbasis der in diesem Dokument beschriebenen Masterarbeit, deren Ziel die Homogenisierung des zum Startzeitpunkt der Arbeit vorliegenden Intranet ist. Zentraler Baustein der Realisierung ist dabei die open-source Portal-Standard-Software Liferay Portal Professional, welche im Zuge der Durchführung eingerichtet und angepasst werden muss. Dieses zu Anfang leere Portalgerüst ist der Ausgangspunkt zur Integration von Altanwendungen bzw. zur komponentenbasierten Erweiterung der Portalfunktionalität in Form so genannter Portlets. 3 Ein Frontend bezeichnet den vorderen, an den Benutzer gerichteten Teil eines Systems. Dazu gehören sowohl die Darstellungskomponenten der Anwendung als auch die zugehörigen Steurerungselemente.

8 2 Problemstellung Betrachtet man die Entstehung von Firmennetzwerken, wie z.b. dem Intranet, so wird ersichtlich, dass sich diese Technologien aus einem Evolutionsprozess heraus basierend auf bestehenden Technologien entwickelt haben. Die Verbreitung des Internet kann dabei als wesentlicher Antrieb angesehen werden. Mit ihrem Beginn geht auch gleichzeitig die heute weit verbreitete Unternehmenspräsentation im World Wide Web (WWW) einher, die schnell zu einer Fülle an global verfügbaren Informationen führte. Parallel zu dieser Entwicklung begann die Entstehung von ausgeprägten informationstechnologischen Infrastrukturen in Unternehmen, nicht zuletzt als logische Konsequenz des ständigen ökonomischen Bestrebens nach Verbesserungen und Neuerungen, orientiert am Vorbild des Internet. Dabei fanden sowohl technologische als auch konzeptionelle Elemente des Internet Einzug in Firmenstrukturen. Die rein technisch betrachtete Entstehung von Firmenrechnernetzen stellt somit die notwendige Basis der konzeptionellen Idee des Intranet dar. Wesentliche Schwachpunkte des Intranet Intranets haben sich in der Vergangenheit als eine Methode der unternehmensinternen Informationsverbreitung etabliert [KGHV04, Kapitel 2.1, Abschnitt Intranet und Extranet]. Es zeigt sich jedoch, dass sie im Zuge ständiger Optimierung der IT-Infrastrukturen auf Grund steigender Anforderungen den heutigen Ansprüchen nicht mehr gerecht werden können. Im Folgenden werden allgemeine Schwächen dieses Netztyps (Bezug nehmend auf das Unternehmen infeurope) diskutiert, dessen IT-Infrastruktur, wie bereits in Kapitel 1 erwähnt, die Struktur eines klassischen Intranet aufweist. Ein typisches Merkmal firmeninterner Netzwerke stellt der eingeschränkte Zugriff dar. Dies ist verständlich, denn im Gegensatz zum Internet sollen hier die im Netz befindlichen Informationen nur einer bestimmten Personengruppe, nämlich den Mitarbeitern, zur Verfügung gestellt werden. Eine unzureichende Beschränkung kann in diesem Zusammenhang oftmals fatale Folgen haben. Wie aber

9 2 Problemstellung 4 lässt sich ein heterogenes Netz am besten vor unbefugten Zugriffen schützen? Gerade bei dieser Netzart, bei der auf Grund eines mangelnden gemeinsamen Einstiegspunktes keine zentrale Zugriffskontrolle realisiert werden kann und dennoch die Anforderungen zum Schutz vor unbefugten Zugriffen extrem hoch sind, ist die am häufigsten realisierte Lösung eine totale Sperrung des Zugriffs von außen. Diese Lösung birgt ein hohes Maß an Sicherheit, führt jedoch zu Problemen, falls die Forderung nach der Möglichkeit eines befugten Zugriffs von außen entsteht. Eine vergleichbare Situation liegt zu Beginn der Masterarbeit im Unternehmen infeurope vor. Firmeneigenen Entwicklungskräften, die sich im Außendienst befinden, ist es nicht möglich, notwendige interne Anwendungen zu verwenden, da eine totale Zugriffssperrung von außen vorliegt. Eine weitere Schwäche des Intranet ist die Ortstransparenz der im Netzwerk vorhandenen Anwendungen. In der Regel kann hier jede Anwendung für sich als einzelner, selbstständiger Bestandteil des Systemnetzes betrachtet werden, dessen Erreichbarkeit über einen eigenen Uniform Resource Locator (URL) gewährleistet wird. Es lässt sich nicht abstreiten, dass dieses Verhalten auch Vorzüge besitzt. Vergleichbare dezentrale Ansätze weisen einen eindeutigen Vorteil hinsichtlich der Wahrscheinlichkeit eines Komplettausfalls gegenüber vergleichbaren zentralen Ansätzen auf: Fällt eine Anwendung aus, so kann dennoch auf alle anderen zugegriffen werden. Dieser Ansatz beinhaltet jedoch auch Nachteile: Das Wissen um die Existenz bereitgestellter Dienste befindet sich nicht innerhalb des Intranet, sondern wird seitens des Benutzers vorausgesetzt. Verfügt ein Benutzer nicht über die Kenntnis der Existenz einer Anwendung, so ist die Anwendung für den Benutzer in gleichen Maßen auch nicht nutzbar 1. Diese Problematik ist auch innerhalb von infeurope sowohl im Bezug auf neue Mitarbeiter als auch auf neue, dem Firmennetzwerk hinzugefügte, Anwendungen bekannt. Die wohl größte Schwäche heterogener Firmennetzwerke findet sich allerdings in der netzzugehörigen heterogenen Sicherheitspolitik, mit der auch gleichzeitig die in den meisten Fällen benötigte Personalisierung einhergeht. Wie bereits erwähnt, können in einem Intranet die einzelnen Anwendungen als selbstständige Elemente betrachtet werden, da in der Regel keine Abhängigkeiten untereinander bestehen. Aus dieser Selbstständigkeit resultiert eine lästige Authentifizierungseigenschaft, da ein Firmennetzwerk, neben der allgemeinen Zugriffsbeschränkung auf einen befugten Personenkreis, eine weitere feinere Klassifizierung von Zugriffsrechten benötigt, die keine Allgemeingültigkeit besitzt, sondern innerhalb des Netzwerkes von Anwendung zu Anwendung verschieden sein kann. In einem Intranet besitzt daher in der Regel jede zugehörige Anwendung ihre eigene Authentifizierungskontrolle. Nicht selten haben Benutzer auf Grund der unterschiedlichen Password- Policies einzelner Anwendungen innerhalb eines Intranet mit einer Unmenge von 1 An dieser Stelle sei darauf hingewiesen, dass ein Intranet per Definition [Kapitel 2.1, Abschnitt Intranet und Extranet] durchaus eine zentrale Linkliste für den Zugriff auf zugehörige Anwendungen aufweisen kann. Zum Zeitpunkt der vorliegenden Arbeit beinhaltet das Intranet der Firma infeurope jedoch keine derartige zentrale Linksammlung

10 2 Problemstellung 5 Benutzernamen und Passwörtern zu kämpfen [Koc06]. Eine allgemeingültige Personalisierung ist somit nicht möglich und auf Grund der zahlreichen anwendungsspezifischen und nicht standardisierten Personalisierungsfunktionen nicht realisierbar. Gleichzeitig muss durch diesen dezentralen Ansatz für die Verwaltung von Zugriffsrechten ein deutlich höherer Aufwand zur Wartung und Pflege betrieben werden, als dies der Fall bei einem vergleichbaren zentralen Ansatz wäre. Als Beispiel sei an dieser Stelle der Prozess aufgeführt, der bei infeurope von den zuständigen Systemadministratoren durchlaufen werden muss, nachdem ein neuer Mitarbeiter eingestellt wurde. Dabei muss in jeder durch den Mitarbeiter anschließend zu benutzenden Anwendung, welche eine Authentifizierung verlangt, ein neues Benutzerkonto mit der zugehörigen Einstellung der Zugriffsrechte eingerichtet werden. Verlässt ein Mitarbeiter das Unternehmen, so müssen seine zahlreichen Benutzerkonten auf die gleiche Weise wieder entfernt bzw. deaktiviert werden. Unternehmensportale als direkter Nachfolger des Intranet Die im Vorangegangenen beschriebene Problematik von Intranetlösungen ist allgemeingültig. Sie findet sich daher nicht nur im Unternehmen infeurope, sondern auch in vielen anderen Unternehmen, die eine ähnliche IT-Infrastruktur aufweisen, wieder. Im Laufe der Zeit kam es daher zu einer Reihe von Weiterentwicklungen, stets in dem Bestreben, das klassische Intranet zu verbessern und die aufgeführten Schwächen zu beheben. Unternehmensportale sind eine solche direkte Weiterentwicklung bestehender Internet- bzw. Intranettechnologien [KGHV04, Kapitel 2.1, Abschnitt Unternehmensportale]. Sie beinhalten entsprechende Lösungsansätze zu den oben beschriebenen Problemen und bieten einen zentralen Lösungsansatz eines Firmennetzwerkes an. Unternehmensportale unterstützen vor allem durch ihre zugehörigen standardisierten Schnittstellenspezifikationen die Entwicklung einer homogenen Benutzeroberfläche, während sie gleichzeitig die Integration heterogener Anwendung ermöglichen. Sie erlauben einen zentralen Zugriff über Single-Sign-On und erleichtern somit die tägliche Arbeit der Mitarbeiter. Aus den im vorherigen Abschnitt aufgeführten Gründen fiel die Entscheidung der Firma infeurope, die bisherige Intranetlösung durch Entwicklung eines Unternehmensportals zu ersetzen bzw. zu erweitern. Die dabei entstehende Problematik einer Überführung der im Intranet vorhandenen Businesslogik in ein Enterprise Portal ist Teil der vorliegenden Masterarbeit.

11 3 Aufgabenstellung und Zielsetzung Sowohl die Aufgabenstellung als auch die Zielsetzung lassen sich in unterschiedliche Bereiche gliedern. Aus der in Kapitel 2 beschriebenen Problemstellung lässt sich bereits die Erstellung eines Unternehmensportals als übergeordnete Aufgabenstellung ableiten. Diese soll im Folgenden genauer definiert und untergliedert werden. Dabei muss der zur Verfügung stehende Entwicklungszeitraum von sechs Monaten berücksichtigt werden. Außerdem beinhaltet die Aufgabenstellung neben der eigentlichen Produkterstellung weitere Aspekte, welche sich sowohl auf die Art und Weise der zugehörigen Softwareentwicklung als auch auf die zu verwendenden Technologien bezieht. Im Folgenden werden die einzelnen Teilaufgaben und -ziele der Masterarbeit aufgeführt und erläutert. Entwicklung eines Unternehmensportals Dieser Aufgabenbereich umfasst die Einrichtung, Konfiguration und Anpassung der Portal-Standard-Software Liferay Portal Professional des Unternehmens Liferay ( Sie bildet die Basis des zu erstellenden Enterprise Portal. Diese Vorgabe beinhaltet gleichzeitig die Verwendung der Technologie Java. Der Aufgabenbereich umfasst die Installation des Portals, die visuelle Anpassung durch Erstellung eines Schemas sowie das Festlegen und Einrichten von Rollen und Benutzergruppen, wobei Letzteres eine Analyse der im Unternehmen verteilten Rollen und Verantwortungen umfasst. Da auf Grund des relativ kurzen Entwicklungszeitraums eine vollständige Überführung der im Intranet befindlichen Einzelanwendungen in das Unternehmensportal nicht möglich ist, wird eine Referenzimplementierung einer oder mehrerer Altanwendungen angestrebt, deren Aufgabe unter anderem darin besteht, als beispielhaftes Modell zur Überführung weiterer Anwendungen zu fungieren. Des Weiteren sollen dem Portal beigefügte Standardportlets aus Zeitgründen nach Möglichkeit Eigenentwicklungen vorgezogen werden.

12 3 Aufgabenstellung und Zielsetzung 7 In Verbindung mit der zu verwendenden Portal-Standard-Software Liferay Portal Professional bildet die durch den Java Community Process (JCP) im Java Specification Request (JSR) 168 erstellte Java Portlet Specification die wichtigste konzeptionelle Grundlage. Das Portal dient dabei als Portlet-Container, dessen Aufgabe in der Verwaltung und Ausführung von Portlets besteht. Die dem Portal zugehörigen Anwendungen müssen daher alle Anforderungen der Portlet- Spezifikation erfüllen. Die Portlet-Spezifikation bildet einen wichtigen Teil der theoretischen Grundlage der Masterarbeit, sie wird daher in der vorliegenden Ausarbeitung ausführlich beschrieben. Integration eines Dokument Management Systems Dokument Management Systeme (DMS) bilden einen wichtigen Bestandteil der IT-Infrastruktur größerer Unternehmen. Sie ermöglichen ein geordnetes und übersichtliches Lagern von großen Datenmengen und bieten umfangreiche Funktionalität im Umgang mit Daten bzw. Dokumenten. Das Unternehmen Alfresco ( ist Kooperationspartner von infeurope und Hersteller von Dokument Management Systemen. Alfresco kombiniert bewährte open-source Komponenten mit neuen Lösungsansätzen, wie zum Beispiel Aspektorientierung, und hat sich schnell zu einer wichtigen Größe im Enterprise- Content-Management-Markt entwickelt [vr06, 2.Abschnitt]. Die Aufgabenstellung beinhaltet daher die Anbindung des Alfresco DMS an das Portal sowohl zur eigenen Verwendung als auch zu demonstrativen Zwecken. Diese Aufgabe lässt sich unterteilen in die Installation und Konfiguration des zur Verfügung gestellten DMS sowie die Anbindung des Systems in das Portal in Form eines Portlets. Vorgehensweise der Softwareentwicklung Als Vorgehensmodell der zugehörigen Softwareentwicklung des Portals soll der Unified Process (UP) angewandt werden. Er beschreibt einen iterativ/inkrementellen Entwicklungsprozess. Das nach Abschluss jeder Iteration entwickelte Produkt stellt eine Untermenge des finalen Produktes dar. Der UP erlaubt eine flexible und an das jeweilige Projekt angepasste Vorgehensweise. Eine formale Beschreibung des UP einschließlich der Beschreibung aller beteiligten Akteure und der resultierenden Ergebnisse einer Tätigkeit findet sich im Rational Unified Process (RUP) wieder. Die zugehörige Software, der Rational Method Composer, erlaubt die formale Beschreibung eigener, projekt- oder firmenspezifischer Vorgehensweisen, die dem Konzept des UP bzw. RUP folgen. Als Nebenprodukt der Portalentwicklung soll durch Anwendung und Anpassung des UP eine zielgerichtete Vorgehensweise zur Entwicklung weiterer Portlets

13 3 Aufgabenstellung und Zielsetzung 8 bzw. zur Erweiterung des Unternehmensportals entstehen. Sie beinhaltet die Auflistung der projektbezogenen Rollen und Akteure, sowie die Auflistung der in jeder Entwicklungsphase erzeugten Ergebnisse bzw. Produkte. Die Anwendung des UP wird am Beispiel der Entwicklung eines Portlet veranschaulicht.

14 4 Durchführung Das vorliegende Kapitel beinhaltet die Beschreibung der im Verlauf der Masterarbeit durchgeführten Tätigkeiten. Es wird darauf hingewiesen, dass die folgende schriftliche Ausführung sich nicht an der Chronologie der zugehörigen praktischen Ausführung orientiert. Viel mehr werden dem Leser die bei der praktischen Durchführung angewandten theoretischen Kenntnisse hinsichtlich der verwendeten Technologien und Konzepte aufgezeigt und vermittelt. Die Ausarbeitung ist in die folgenden theoretischen Schwerpunkte gegliedert. Angelehnt an die praktische Durchführung umfasst jeder Bereich zur Veranschaulichung und zum besseren Verständnis beispielhafte Auszüge aus der zugehörigen praktischen Anwendung. Der erste Abschnitt umfasst die Einrichtung des Unternehmensportals. Hier wird die verwendete Portal-Standard-Software aufgeführt. Das Kapitel beschäftigt sich mit dem Aufsetzen, Einrichten und Anpassen des Unternehmensportals. Aufgezeigt werden die verschiedenen Konfigurationsmöglichkeiten des Portals. In diesem Abschnitt werden außerdem die dem Portal zugehörigen grundlegenden Begriffe aufgeführt und erläutert. Das darauf folgende Kapitel beinhaltet den technologischen Kern der vorliegenden Masterarbeit. Im Mittelpunkt steht dabei die Entwicklung eines Portlets unter Verwendung der zugehörigen Java Portlet Specification. Dieser Abschnitt ist stark technologisch orientiert und behandelt im Zusammenhang mit der Erläuterung und Veranschaulichung von Portlets auch die Themen Spring Framework und Hibernate, sowie das Konzept des Portlet-Containers. Der letzte Abschnitt beinhaltet die Anwendung des UP als Vorgehensweise in der Softwareentwicklung, sowie einen Vergleich mit dem konkurrierenden Wasserfall -Entwicklungsprozess. Dabei werden sowohl die einzelnen Entwicklungsphasen als auch die zugehörigen Entwicklungsdisziplinen aufgeführt und erläutert. Außerdem wird die Anwendung des UP am Beispiel der Entwicklung eines Portlets demonstriert.

15 4.1 Einrichtung des Unternehmensportals Einrichtung des Unternehmensportals Wie bereits in Kapitel 1 erwähnt gilt die Verwendung der Portal-Standard-Software von Liferay als Vorgabe dieser Masterarbeit. Begonnen wurde mit der Entwicklung der Portal-Standard-Software bereits vor sieben Jahren. Die seit Ende 2006 bereitgestellte Version des Portal Frameworks stellt heute das Flaggschiff des Unternehmens Liferay dar. Bereits die frühere Version geht in einer Studie des Münchner IT-Dienstleisters Pentasys laut [Ale05] im Vergleich mit den bekanntesten konkurrierenden open-source Lösungen Gridsphere (Version 2.0.2), Jetspeed 2 (Milestone 1), JBoss Portal (Version 2.0 Beta 1) und Exo Platform (Version 1.0) unter den Aspekten Administration, Support, Content-Verwaltung, Portlets und Personalisierung als eindeutiger Sieger hervor. Das Portal Framework von Liferay gibt es in zwei verschiedenen Ausgaben, deren Unterschied sich ausschließlich im Backend 1 definiert. Während sich die Enterprise Edition durch Verwendung der Technologie Enterprise Java Bean (EJB) sowie deren Dienste zur Integration und Anbindung an einen Java Enterprise Edition (J2EE) Applicationserver eignet, bietet die Professional Edition unter Verwendung des Spring Frameworks und so genannter Plain Old Java Objects (POJOs) die Möglichkeit, als stand-alone Applikation innerhalb eines Servlet- Containers zu laufen. Letztere Ausgabe bildet die Ausgangsbasis dieser Masterarbeit. Das von Liferay bereitgestellte Liferay Portal Professional steht als open-source Portal Software zur Verfügung. Die Benutzung ist daher kostenlos. Das Unternehmen finanziert sich ausschließlich über das umfassende zugehörige Dienstleistungsangebot, welches nicht zwingend von einem Nutzer des Produktes in Anspruch genommen werden muss. Zur Durchführung der vorliegenden Masterarbeit wurden neben der Verwendung des Portals keine weiteren Dienstleistungen der Firma Liferay in Anspruch genommen, sondern ausschließlich die unter [Lif07] bereitgestellte Dokumentation verwendet, die im Folgenden auch als Quelle aufgeführt wird Technische Funktionsweise und Begriffserläuterungen Im Folgenden werden die beiden Begriffe Portal und Portlet erläutert. Der Schwerpunkt liegt hierbei auf der technischen Betrachtungsweise. Eine weiterführende Erklärung der beiden Begriffe findet sich in Kapitel 4.2. Ein Portal ist technisch betrachtet eine Webanwendung, die verschiedene Inhalte, Dienste und Funktionen bereitstellt. Dabei beinhaltet der Funktionsumfang 1 Das Backend bezeichnet den Teil einer Software, der die Bearbeitung der eigentlichen Aufgabe übernimmt. Im Gegensatz dazu steht das Frontend einer Anwendung, welches die Benutzerschnittstelle bereitstellt.

16 4.1 Einrichtung des Unternehmensportals 11 Möglichkeiten zur Integration weiterer Inhalte und Dienste in Form so genannter Portlets. Der Zugriff auf ein Portal erfolgt über einen Webbrowser und benötigt keine Installation auf Seiten des Benutzers. Wichtigstes Merkmal eines Portals ist der Aspekt der Personalisierung, d.h. Portale ermöglichen die Bereitstellung von unterschiedlichen Daten und Informationen in Abhängigkeit des jeweiligen Benutzers. Betrachtet man ein Portal als zentrale Plattform mit der Möglichkeit, eine Vielzahl unterschiedlicher Informationsquellen daran anzubinden, so lässt sich in diesem Zusammenhang auch das Prinzip des Single Sign On (SSO) erklären. Der Begriff SSO steht für das einmalige Anmelden an einem Portalsystem, wobei die weiterführende(n) Anmeldung(en) an den dem Portal untergeordneten externen Applikationen durch entsprechende Funktionalität des Portals abgedeckt wird. SSO rührt daher aus der Anforderung an Portale als Integrationsplattform zu dienen. Aus diesem Zusammenhang lässt sich eine weitere Funktionalität ableiten: Um den oben beschriebenen Ansprüchen gerecht zu werden, benötigt ein Portal eine ausgeprägte und feingranulare Benutzerverwaltung. Des Weiteren erheben sich neben den oben genannten Anforderungen weitere technische Ansprüche: Portale benötigen auf Grund ihrer Integrationsfunktionalität ein hohes Maß an Interoperabilität. Die Fähigkeit der Kommunikation und Zusammenarbeit von unterschiedlichen Systemen verlangt die Definition und Einhaltung gemeinsamer Standards. Das Festlegen von gemeinsamen Richtlinien dient der Kompabilität. Als Beispiel sei an dieser Stelle, Bezug nehmend auf das aufgeführte Prinzip des SSO, die notwendige Übergabefunktionalität von Benutzereigenschaften (z.b. Benutzername oder adresse) an angebundene Applikationen genannt. Diese Funktionalität trägt dazu bei, dass das Portal an Stelle des Benutzers die Anmeldung an integrierten Anwendungen automatisiert durchführen kann. Auf der Technologie Java basierende Portale bedienen sich zur Schaffung der notwendigen Interoperabilität der zugehörigen Java Portlet Specification. Die folgende Erläuterung der Spezifikation wird zum allgemeinen Verständnis der in diesem Abschnitt der Ausarbeitung aufgeführten Thematik der detaillierten Beschreibung der Spezifikation in Kapitel 4.2 vorweg genommen. Die Portlet-Spezifikation dient der Definition der dem Portal zugehörigen Schnittstelle zur Integration von externen Anwendungen. Sie beinhaltet standardisierte Kommunikationsmodelle und legt notwendige Eigenschaften fest, die eine anzubindende Applikation erfüllen muss. Alle durch ein Java-basiertes Portal integrierbaren Systeme, welche die Anforderungen der Spezifikation erfüllen, werden als (Java) Portlet bezeichnet. Die Java Portlet Specification beinhaltet unter anderem die visuellen Anforderungen an Portlets. Aus der Tatsache, dass Portale webbasierte Systeme sind und somit auf dem Hypertext Transfer Protocol (HTTP) basieren, resultieren entsprechende Anforderungen an Portlets. Die Darstellung eines Portals geschieht im klassischen Sinne innerhalb eines Webbrowsers über Hypertext Markup Language (HTML)-Seiten, die in diesem Zusammenhang auch Portalseiten genannt wer-

17 4.1 Einrichtung des Unternehmensportals 12 den. Eine Portalseite kann (neben weiteren portalspezifischen Elementen) ein oder mehrere Portlets darstellen. Das grundlegende Aussehen eines Portlets ist durch die Spezifikation festgelegt. Die Portletdarstellung ist dabei in die folgenden, verschiedenen Elemente aufgeteilt: Portletfenster Portletfragment Dekorations- und Kontrollelemente Ein Portletfenster besteht aus einem Portletrahmen (optional, d.h. nicht Teil der Spezifikation, sondern liferayspezifisch), sowie einer Reihe von Dekorationsund Kontrollelementen und einem Portletfragment. Das Portletfragment repräsentiert den eigentlichen visuellen Inhalt eines Portlets, der sich zur Laufzeit durch Benutzerinteraktion ändern kann. Der Portletrahmen umschließt das Portletfragment und die Dekorations- und Kontrollelemente. Er bildet zugleich den äußeren Rahmen des Portletfensters. Der Portletrahmen ist in vielen Portalen optional zuschaltbar, und kann daher bei der Darstellung auch weggelassen werden. Abbildung 4.1 skizziert den beschriebenen Zusammenhang zwischen Portalseite, Portlets und zugehörigen Elementen. Abbildung 4.1. Portalseite und ihre Elemente

18 4.1 Einrichtung des Unternehmensportals Installation des Portal Frameworks Auf eine detaillierte Beschreibung der Installation des Liferay Portal Professional wird an dieser Stelle nicht eingegangen. Es sei jedoch darauf hingewiesen, dass in dieser Masterarbeit das von Liferay bereitgestellte Tomcat Bundle 2 (Version 4.2.1) verwendet wurde, unter dessen Verwendung sich die einfachste Form einer Installation realisieren lässt. Das Bundle beinhaltet die aktuellste Ausgabe des Liferay Portal Professional sowie die zum Zeitpunkt der Durchführung aktuellste Ausgabe des von der Apache Software Foundation ( bereitgestellten Servlet-Containers Apache Tomcat (Version ), auf welchem das Portal bereits vorab aufgesetzt ist. Voraussetzung zur Verwendung dieses Bundles ist die Verwendung des Java Development Kit (JDK) der Firma Sun Microsystems ( ab Version 5. Das Portal Framework kann in Verbindung mit einer Vielzahl von Datenbanken verwendet werden. Die Installationspakete beinhalten standardmäßig eine im Portal eingebettete Datenbank, die allerdings lediglich zu Entwicklungszwecken geeignet ist, da sie keine Multi-User-Fähigkeit beinhaltet. Für die vorliegende Arbeit wurde daher zusätzlich ein MySQL Datenbankserver (Version 5.0) installiert und eingerichtet und die vom Portal Framework standardmäßig genutzte, eingebettete Datenbank durch eine entsprechend konfigurierte MySQL Datenbank ersetzt. Eine detaillierte Installationsanleitung findet sich unter [SCM + 06a, Seite 21] Benutzereinrichtung und -verwaltung Das Portal Framework von Liferay bietet ein großes Maß an Flexibilität hinsichtlich seiner Anpassung an vorliegende Unternehmensstrukturen und deren korrekte Projektion in die Portalstruktur. Die Einrichtung der Portalbenutzer geschieht unter Verwendung entsprechender Konfigurationsportlets. Das Portal unterscheidet dabei drei hierarchisch unterschiedliche Verwaltungsebenen. Die höchste Verwaltungsebene ist die Enterprise Administration (dt.: Unternehmensverwaltung). Sie umfasst ganzheitlich das Unternehmen. Zugehörige Administratoren besitzen die maximalen Zugriffsrechte. Ihnen untergeordnet ist die Organization Administration (dt.: Organisationsverwaltung). Dabei wird dem konzeptionellen Modell gefolgt, welches in Abbildung 4.2 dargestellt ist. Demnach können einem Unternehmen beliebig viele Organisationen angehören, vergleichbar einem Konzern, dem beliebig viele Tochterunternehmen untergeordnet sind. Die unterste Verwaltungsebene ist die Location Administration (dt.: Standortverwaltung). Sie entspricht im realen Abbild einer Zweigstellenverwaltung. Jeder Benutzer bzw. Mitarbeiter ist genau einer Standortverwaltung zugeordnet. 2 engl. Bezeichnung für ein Softwarepaket

19 4.1 Einrichtung des Unternehmensportals 14 Abbildung 4.2. Verwaltungshierarchie innerhalb des Portals Die Administratoren der unterschiedlichen Ebenen besitzen die der jeweiligen Verwaltung zugeordneten Rechte. So kann z.b. ein Administrator einer Organisationsverwaltung A ausschließlich die ihm untergeordneten Mitarbeiter sowie deren Rechte und Rollen verwalten. Mitarbeiter, die einer anderen Organisationsverwaltung zugehören, sind für die Organisationsverwaltung A transparent. Neben der administrativen Zugehörigkeit existieren noch weitere Organisationseinheiten, denen ein Benutzer angehören kann. Communities (dt.: Gemeinschaften) repräsentieren Mitarbeitereinheiten, die sich über ein gemeinsames Interesse oder eine gemeinsame Qualifikation definieren. Ein Mitarbeiter kann einer Community direkt, daher über seine Person selbst, oder indirekt, durch seine Zugehörigkeit zu einer bestimmten Verwaltungseinheit, angehören. Auch wird zwischen offenen und geschlossenen Communities unterschieden: In einer offenen Community ist die Mitgliedschaft freiwillig. Jedem Mitarbeiter der zugehörigen Verwaltungseinheit ist der Zugang bzw. Austritt freigestellt. Die Mitgliederverwaltung in geschlossenen Communities geschieht jedoch über die jeweils übergeordnete Verwaltungseinheit. Beispiel für eine Community sind die Mitarbeitereinheiten Support, Content Manager oder Developer. Die Rechteverwaltung des Portals ist den im Vorangegangenen beschriebenen Verwaltungseinheiten zugehörig. Das Portal Framework von Liferay stellt dafür ein feingranulares Zugriffssystem bereit, das eine detaillierte und genaue Vergabe von Rechten ermöglicht. Jedes Objekt innerhalb des Portals auf welches durch den Benutzer zugegriffen werden kann, wird als Resource (dt.: Ressource) bezeichnet. Eine Ressource kann z.b. eine Portlet, ein bestimmter (personalisierter) Inhalt eines Portlets oder eine beliebige Datei sein. Jede Ressource kann genau einem der drei folgenden Verantwortungsbereiche zugeordnet sein:

20 4.1 Einrichtung des Unternehmensportals 15 Unternehmenszugehörigkeit: Die zugehörigen Ressourcen stehen dem ganzen Unternehmen zur Verfügung. Die Zugriffsrechte werden durch die Unternehmensverwaltung administriert. Eine entsprechende Ressource könnte z.b. ein News Portlet sein, welches allen Mitarbeitern des Unternehmens die neuesten Nachrichten anzeigt. Communityzugehörigkeit: Ressourcen dieses Bereichs sind einer bestimmten Community zugeordnet. Die Zugriffsrechte werden über die übergeordnete Verwaltungsebene bestimmt. So kann z.b. auf den Inhalt eines Forums der Community Developer nur durch Mitglieder derselben Community zugegriffen werden. Benutzerzugehörigkeit: Zugehörige Ressourcen sind genau einem Benutzer zugeordnet. Die Zugriffsrechte werden durch die Standortverwaltung administriert. Ein Mail Portlet bietet einem Benutzer die Möglichkeit, s zu versenden, zu empfangen und zu verwalten. Der Inhalt dieses Portlets ist personalisiert, d.h. jedem Benutzer ist ein bestimmter Inhalt zugeordnet. Die Zugriffsrechte des Mail Portlets sind daher benutzerzugehörig. Die Zugriffsrechte auf Ressourcen werden durch Permissions (dt.: Genehmigungen) geregelt. Eine Genehmigung erteilt einem Benutzer das Recht, eine bestimmte Handlung auf einer Ressource auszuführen. Ein Benutzer kann z.b. die Genehmigung haben, Beiträge eines Forums zu lesen, ohne dabei das Recht zu haben Beiträge hinzuzufügen oder zu bearbeiten. Eine Role (dt.: Rolle) innerhalb des Portals definiert sich durch eine Menge von Genehmigungen. Die Rolle des Forumsadministrators beinhaltet z.b. alle Genehmigungen, die für die Administration eines Forums benötigt werden (Benutzerverwaltung, Kategorieverwaltung, Beitragsverwaltung, usw. ). Wird einem Benutzer diese Rolle zugewiesen, so besitzt er alle zugehörigen Genehmigungen. Eine beispielhafte Ressourcen- und Rollensituation ist in Abbildung 4.3 dargestellt. Auf eine detaillierte Beschreibung der praktischen Durchführung zur Einrichtung von Benutzern, Rollen und Rechten wird an dieser Stelle nicht eingegangen. Entsprechende Informationen zum dargestellten Sachverhalt finden sich in [SCM + 06c] Nutzung des Content Management Systems (Web) Content Management Systeme (CMS) bilden einen wichtigen Bestandteil ausgereifter Portal Frameworks. Ihre Funktionalität ermöglicht eine gemeinschaftliche Erstellung, Bearbeitung und Verwaltung von (meist strukturierten) Inhalten (engl.: Content). Dabei stellt ein CMS in der Regel entsprechende Funktionen zur Verfügung, die eine möglichst flexible Darstellung des Inhalts zulassen. Das Portal Framework von Liferay beinhaltet ein solches CMS, dessen Benutzung unter Verwendung zugehöriger Portlets stattfindet. Dieses Kapitel beschäftigt sich mit der

21 4.1 Einrichtung des Unternehmensportals 16 Abbildung 4.3. Beispielhafte Ressourcen- und Rechteverwaltung konzeptionellen Funktionsweise des von Liferay innerhalb des Portals mitgeführten CMS. Eine ausführliche Beschreibung zur praktischen Anwendung findet sich unter [SCM + 06b]. Um eine möglichst flexible und wieder verwendbare Darstellung von Inhalten zu erreichen, bedient sich das CMS von Liferay des gängigen Konzeptes der Aufteilung eines Inhaltes in drei verschiedene Bereiche, die im Folgenden beschrieben werden. Strukturen Structures (dt.: Strukturen) repräsentieren die inhärente Struktur gleichartiger Inhalte eines Typs. Beim Erzeugen einer Struktur wird der Aufbau eines bestimmten Inhaltes in einzelne Elemente unterteilt. Die resultierende Gliederung bildet ein vordefiniertes Basisgerüst für einen Artikel 3. Die Struktur einer einfachen Stellenanzeige, die auf der eigenen Website eines Unternehmens angezeigt werden soll, könnte z.b. die folgenden Elemente beinhalten: Jobtitle (dt.: Berufsbezeichnung) Short description (dt.: Kurzbeschreibung) 3 Die Bedeutung des Begriffs Artikel in diesem Zusammenhang wird im Folgenden erklärt.

22 4.1 Einrichtung des Unternehmensportals 17 Searched profile (dt.: Bewerberprofil) Contact (dt.: Kontaktdaten) Das Aufstellen von Strukturen dient der Harmonisierung von kategorisch gleichen Inhalten. Das Erstellen einer Struktur wird in Liferay über das Journal Portlet realisiert. Für das für eine Strukturdefinition verwendete Format wird die Extensible Markup Language (XML) verwendet. Der folgende XML Code definiert die Struktur der im Vorherigen aufgeführten beispielhaften Stellenanzeige: <?xml version="1.0"?> <root> <dynamic-element name="jobtitle" type="text"/> <dynamic-element name="short-description" type="text"/> <dynamic-element name="searched-profile" type="text-area"/> <dynamic-element name="contact" type="text"/> </root> Schablonen Templates (dt.: Schablonen) bilden ein Gerüst zur Darstellung eines Inhaltes. Sie repräsentieren den visuellen Rahmen. Ausgehend von einer vorliegenden Struktur definiert ein Template wie und wo ein Strukturelement auf einer Portalseite dargestellt werden soll. Ein Template basiert immer auf genau einer Struktur. Einer Struktur hingegen können mehrere Templates zugewiesen werden. Templates dienen einer einheitlichen Darstellung von Inhalten auf einer Portalseite. Die Erstellung eines Templates erfolgt in Liferay ebenfalls über das Journal Portlet. Templates können sowohl im Extensible Stylesheet Language (XSL) als auch im Velocity Markup (VM) Format definiert werden. Der folgende Code veranschaulicht ein beispielhaftes Template, welches auf der oben aufgeführten Struktur basiert und dabei das VM Format verwendet. <html> <head><title>$jobtitle.getdata()</title></head> <body> <table border="1" width="600"> <tr> <td>jobtitle</td><td>$jobtitle.getdata()</td> </tr> <tr> <td>short description</td> <td>$short-description.getdata()</td> </tr> <tr> <td>searched Profile</td>

23 4.1 Einrichtung des Unternehmensportals 18 <td>$searched-profile.getdata()</td> </tr> <tr> <td>please contact</td><td>$contact.getdata()</td> </tr> </table> </body> </html> Artikel Articles (dt.: Artikel) repräsentieren den eigentlichen Informationsgehalt eines Inhaltes. Ihre Erstellung basiert auf einer existierenden Struktur. In Liferay können an einen Artikel zusätzliche Attribute angebunden werden. So kann z.b. ein zeitlicher Rahmen angegeben werden, innerhalb dessen ein Artikel gültig ist. Jeder Artikel muss vor seiner Publikation explizit freigegeben werden. Eine Struktur, ein Template sowie ein Artikel bilden gemeinsam einen Inhalt. Die Darstellung solcher Inhalte im Portal wird ebenfalls über Portlets realisiert. Strukturen und Templates können beliebig oft wieder verwendet werden. Unter Verwendung der im Vorherigen beschriebenen Funktionalität können einzelne Portalseiten schnell und leicht erstellt und verändert werden Anpassung der Benutzeroberfläche Die visuelle Anpassung des Portals ist Teil des kundenorientierten Individualisierungsprozesses. Wichtiger Bestandteil des dabei verwendeten Konzeptes zur Realisierung ist die Portlet-Spezifikation, welche zu einem großen Teil die technisch konzeptionelle Grundlage einer einheitlichen Darstellung bildet. Die Portlet- Spezifikation wird in Kapitel 4.2 detailliert behandelt. Sie wird an dieser Stelle nicht weiter aufgeführt, da sie für die folgende Beschreibung der visuellen Anpassung nicht benötigt wird. Die Darstellung des Portals im Browser wird in Liferay über ein so genanntes Theme (dt.: Thema, hier: Darstellungsmuster) realisiert. Ein Theme repräsentiert bzw. beschreibt eine Darstellungsvariante der Benutzerschnittstelle. Die Verwendung von Themes ist personalisiert, so dass alle Benutzer unabhängig voneinander unterschiedliche Themes verwenden können. Liferay Themes Ein Liferay Theme kann als eine Anleitung verstanden werden. Es dient der Steuerung des so genannten Look and Feel einer Portalseite. Themes beinhalten auch eine Beschreibung zur Darstellung von Portlets, der wichtigsten Komponente einer

24 4.1 Einrichtung des Unternehmensportals 19 Portalseite. Die folgenden zwei Gründe liegen der Verwendung dieses Konzeptes zu Grunde: einheitliche und homogene Darstellung von inhaltlich unterschiedlichen bzw. unabhängigen Applikationen Erhöhung der Flexibilität zur individuellen visuellen Anpassung Die innerhalb eines Themes befindlichen Informationen lassen sich in zwei unterschiedliche Kategorien gliedern: Zum einen beinhaltet jedes Theme Darstellungsanforderungen an visuelle Portalkomponenten bzw. -eigenschaften, wie z.b. die Hintergrundfarbe oder das Hintergrundbild einer Portalseite. Diese Elemente sind liferayspezifisch und somit nicht Teil der Portlet-Spezifikation. Zum anderen muss jedes Theme genaue Vorgaben hinsichtlich der visuellen Benutzerschnittstelle von Portlets gemäß der zugehörigen Spezifikation definieren. Beispiel hierfür sind das Festlegen der zu verwendenden Schriftarten und Schriftgrößen, sowie Form und Farbe eines Portlets. Die Auswahl eines Themes geschieht zur Laufzeit durch den Benutzer. Jeder, dem Benutzer zugehörige, Portalseite kann dabei ihr eigenes Theme zugewiesen werden. Entwicklung eines Themes In seiner Standardausführung beinhaltet das Portal von Liferay bereits eine Reihe von vorgefertigten Themes. Diese dienen der Veranschaulichung und bilden gleichzeitig die Ausgangsbasis für die Entwicklung eigener Darstellungsmuster. Die grundsätzliche Funktionsweise basiert auf der Erstellung von Templates, welche zur Laufzeit bei der automatischen Generierung einzelner Portalseiten- bzw. Portletfragmente von der zuständigen Systemkomponente als Schablone verwendet werden. Im Folgenden werden der grundlegende Aufbau und die wichtigsten Zusammenhänge innerhalb eines Themes vereinfacht aufgezeigt. Weitere Informationen finden sich unter [Fer07]. Die folgenden Technologien werden zur Entwicklung eines Themes in Liferay verwendet. Hypertext Markup Language (HTML) Cascading Style Sheets (CSS) Extensible Markup Language (XML) JavaScript Velocity Markup (VM) JavaServer Pages (JSP) Die Erstellung eines Templates geschieht durch Nutzung der Technologien HTML und CSS. Hierbei kann unter Verwendung herkömmlicher HTML-Tags

25 4.1 Einrichtung des Unternehmensportals 20 das grundlegende Aussehen einer Portalseite bzw. eines Portlets festgelegt werden. Dabei wird unterstützend CSS eingesetzt, um eine möglichst flexible visuelle Anpassung zu ermöglichen. Das Festlegen von portletspezifischen Farbwerten findet in einer vordefinierten XML-Datei statt (liferay-look-and-feel.xml). Zum Einbinden der festgelegten Farbwerte aus der XML-Datei in ein Template verwendet Liferay die Technologie VM. Der dadurch entstehende grundlegende Vorteil liegt sowohl in der Minimierung redundanter Daten als auch in der dateiorientierten Gruppierung gleichartiger Informationen. Neben den aufgeführten Elementen kann ein Template weitere Informationen und Elemente beinhalten. Für das Einbinden dynamischer Elemente, wie z.b. das ereignisgesteuerte Anzeigen von Bildern, wird sowohl JSP als auch JavaScript verwendet. Abbildung 4.4 skizziert die vereinfachte Struktur eines Liferay Themes. Abbildung 4.4. Konzeptioneller Aufbau eines Liferay Themes Selbstentwickelte Themes können in Liferay dem Portal zur Laufzeit als Web Archive (WAR)-Datei hinzugefügt werden. Das so genannte Deployment (dt.: Auslieferung) wird automatisiert durch das Portal ausgeführt.

26 4.2 Java Portlets: Spezifikation und Entwicklung Java Portlets: Spezifikation und Entwicklung Die Java Portlet Specification ist ein wichtiger Bestandteil der konzeptionellen Grundlage von Portalen. Sie wurde im Rahmen des JCP als Standard entwickelt und im Oktober 2003 in ihrer bis heute aktuellen Version 1.0 veröffentlicht. Primäres Ziel der Spezifikation ist die Beseitigung der bis zu ihrem Erscheinen vorherrschenden Inkompatibilität unter Portalsystemen in der Java-Welt. Im Folgenden werden zunächst die wichtigsten Elemente der Spezifikation aufgeführt und erläutert. Ziel ist es, dem Leser die wesentlichen und grundlegenden Kenntnisse der Spezifikation zu vermitteln, die für das Verständnis und den weiteren Verlauf der vorliegenden Masterarbeit benötigt werden. Die vollständige Spezifikation findet sich unter [AH03]. Im zweiten Teil dieses Kapitels wird am Beispiel der Entwicklung des Time Reporting Portlets die Implementierung des Standards veranschaulicht. In diesem Zusammenhang werden auch die beiden Technologien Spring Framework und Hibernate vorgestellt Spezifikationsspezifische Begriffsdefinitionen Die folgenden Begriffe repräsentieren grundlegende Elemente der Java Portlet Specification. Die aufgeführten Definitionen finden sich in [AH03, Seite 13]. Portal Portale sind webbasierte Anwendungen, welche sich primär durch den Aspekt der Personalisierung und des SSO auszeichnen. Ihre Hauptaufgabe liegt in der Aggregation 4 von Inhalten aus verschiedenen Informationsquellen, sowie in der Bereitstellung entsprechender (zugehöriger) Darstellungskomponenten. Portlet Ein Portlet ist eine auf der Technologie Java basierende Webkomponente, die durch einen Portlet-Container verwaltet wird. Portlets finden ihre Verwendung innerhalb eines Portals, wo sie als pluggable (dt.: ansteckbar, hier: leicht hinzufügbare bzw. entfernbare) Darstellungskomponenten von Informationen verschiedener Quellen zum Anzeigen dynamischen Inhalts genutzt werden. Der durch ein Portlet generierte Inhalt wird als Fragment bezeichnet. Ein Fragment beinhaltet in einer Markup-Sprache (z.b. HTML, XML) verfasste Inhalte auf solche Weise, dass es mit weiteren Fragmenten aggregiert ein vollständiges Dokument bildet. Mittels der Aggregation von Fragmenten unterschiedlicher Portlets 4 Der Begriff Aggregation beschreibt in diesem Zusammenhang die Darstellung von Inhalten unterschiedlicher Quellen auf einer Webseite.

27 4.2 Java Portlets: Spezifikation und Entwicklung 22 werden in einem Portal Portalseiten erzeugt. Der Lebenszyklus eines Portlets wird dabei durch den zugehörigen Portlet-Container verwaltet. Die Kommunikation mit einem Portlet erfolgt entsprechend des zugrunde liegenden HTTP-Protokolls auf Basis des Request/Response Musters. Sie wird durch entsprechende Funktionalität des Portals realisiert. Ein Benutzer kommuniziert mit einem Portlet durch Interaktion mit dem erzeugten, gegebenenfalls personalisierten, Inhalt, wobei das zugehörige Portal für den Austausch der Informationen zuständig ist. Portlet-Container Die Aufgabe eines Portlet-Containers liegt in der Steuerung und Ausführung von Portlets, sowie in der Bereitstellung der benötigten Systemumgebung. Der Portlet- Container verwaltet die jeweiligen Lebenszyklen seiner Portlets und leitet alle Requests, die er durch das Portal erhält, an die zugehörigen Portlets weiter. Portlet- Container und Portal können in der Praxis sowohl als zwei getrennte als auch in Form einer zusammengesetzten Komponente auftreten Portalseiten und ihre Erzeugung Eine Portalseite setzt sich aus verschiedenen Elementen zusammen. Sie repräsentiert eine Aggregation der visuellen Komponenten mehrerer Portlets. Die Darstellung jedes Portlets besteht primär aus dem zum jeweiligen Zeitpunkt durch das Portlet selbst generierten Inhalt: dem Fragment. Jedem Fragment werden bei Erstellung einer Portalseite weitere Elemente durch das Portal hinzugefügt. Auf diese Weise erhält jedes Fragment einen Titel sowie portletspezifische Schaltflächen und eventuelle portalspezifische Dekorationselemente, wie z.b. einen Portletrahmen. Zusammengefasst bilden diese Elemente gemeinsam ein Portletfenster. Abbildung 4.1 veranschaulicht den beschriebenen Zusammenhang. Die Erzeugung einer Portalseite erfolgt zur Laufzeit in Abhängigkeit der eingehenden Anfrage. Bei Betreten des Portals durch einen Benutzer, z.b. durch Aufruf der zugehörigen URL in einem Browser, wird der einkommende Request durch das Portal an den Portlet-Container weitergeleitet. Dieser wiederum splittet die Anfrage auf und leitet sie an alle durch den Request betroffenen Portlets weiter. Im Gegenzug erhält der Portlet-Container von allen betroffenen Portlets als Antwort ein Fragment. Diese leitet er weiter an das Portal, welches unter Verwendung der übergebenen Fragmente die auf den zuvor erhaltenen Request passende Portalseite erzeugt. Die Portalseite wird anschließend als Response an den Benutzer zurückgesandt. Der hier aufgeführte Ablauf ist schematisch in Abbildung 4.5 dargestellt.

28 4.2 Java Portlets: Spezifikation und Entwicklung 23 Abbildung 4.5. Schematischer Ablauf der Erzeugung einer Portalseite Lebenszyklus eines Portlets Der Lebenszyklus eines Portlets wird durch den übergeordneten Portlet-Container verwaltet. Dabei durchläuft jedes Portlet unterschiedliche Phasen, die im Folgenden erläutert werden. In der Praxis wird jede Lebensphase durch eine entsprechende Methode des Portlets repräsentiert. Die dabei verwendeten Methoden sind fester Bestandteil des zur Spezifikation zugehörigen Portlet Interfaces, welches zwingend von jedem Portlet implementiert werden muss. Instanzierung Für das Laden und Erzeugen eines Portlets ist der zuständige Portlet-Container verantwortlich. Die Instanzierung eines Portlets kann sowohl statisch, d.h. beim Start des Portlet-Containers erfolgen als auch dynamisch zur Laufzeit auf Anfrage eines Benutzers. Das Laden einer Portlet Klasse geschieht unter Verwendung des ClassLoaders des übergeordneten Servlet-Containers. Initialisierung Nach erfolgreichem Erzeugen durchläuft jedes Portlet die Initialisierungsphase. Realisiert wird diese Phase über den Aufruf der Methode init durch den Portlet- Container. Erst nach Abschluss dieser Phase steht das Portlet dem Benutzer des Portals zur Verfügung. Die Methode init ermöglicht dem Portlet das eigenständige Laden bzw. Initialisieren von Ressourcen, die es im weiteren Verlauf seiner Verwendung benötigt. Beispiel hierfür könnte das Laden von Konfigurationsdateien sein oder die Initialisierung einer Datenbankverbindung. Der Portlet-Container übergibt jedem Portlet bei Aufruf der Methode init ein Konfigurationsobjekt, welches das ebenfalls zur Spezifikation zugehörige Interface PortletConfig implementiert. Das Konfigurationsobjekt beinhaltet Informationen, wie z.b. Initialisierungsparameter und bietet dem Portlet Zugriff auf weitere Objekte innerhalb der Systemumgebung.

29 4.2 Java Portlets: Spezifikation und Entwicklung 24 Anfragebehandlung Nach Abschluss der beiden beschriebenen Phasen steht ein Portlet dem Benutzer eines Portals für Anfragen zur Verfügung. Diese Phase kann als Hauptabschnitt innerhalb des Lebenszyklus eines Portlets bezeichnet werden, da sie keiner bestimmten zeitlichen Begrenzung unterliegt. Es sei jedoch erwähnt, dass trotz der Bereitschaft zur Anfragebehandlung durchaus die Möglichkeit besteht, dass ein Portlet innerhalb seiner Lebensdauer letztendlich keine einzige Anfrage behandelt. Die Bearbeitung eines Requests unterscheidet sich in Abhängigkeit von der Anfrage, wobei in zwei verschiedene Requestarten unterschieden wird. Ein action Request wird durch den Portlet-Container an die Methode processaction des betroffenen Portlets delegiert. Einer solchen Anfrage folgt i.d.r. die Ausführung einer bestimmten Aktion im Backend des Portlets. Die Ausführung der Methode processaction geht daher normalerweise mit einem Zustandswechsel des Portlets einher. Im Gegensatz dazu steht die Behandlung eines render Request, welche durch Aufruf der Methode render bearbeitet wird. Diese Methode dient der Erzeugung eines aktualisierten Inhalts in Abhängigkeit des Zustandes, in dem sich ein Portlet befindet. Dies entspricht der Erzeugung des für die Darstellung benötigten Fragments eines Portlets. Dem Aufruf eines action Requests folgt normalerweise der Aufruf ein oder mehrerer render Requests. Dies rührt daher, dass der Zustandswechsel eines Portlets i.d.r. eine Aktualisierung der Benutzerschnittstelle zur Folge hat. Da der Zustandswechsel eines Portlets Auswirkungen auf andere Portlets haben kann, werden durch das Portal automatisch alle auf der Portalseite befindliche Portlets aufgefordert ihre Benutzerschnittstellen zu aktualisieren. Ein action Request führt daher zu einem render Request für jedes auf derselben Portalseite befindliche Portlet. Generell gilt die Aussage, dass bei Ausführung eines render Requests auf einem Portlet alle auf der gleichen Portalseite befindlichen Portlets aufgefordert werden, ihre zugehörigen Benutzerschnittstellen zu aktualisieren. Beendigung Der Lebenszyklus eines Portlets endet mit der Beendigungsphase. Diese Phase wird mit dem Aufruf der Methode destroy durch den Portlet-Container eingeleitet. Das Portlet verwendet die Methode destroy, um vor seiner Beendigung mögliche Ressourcen freizugeben und seinen aktuellen Zustand gegebenenfalls zu persistieren. Mit Eintritt in die Beendigungsphase geht auch gleichzeitig die Verfügbarkeit des Portlets zu Ende Der PortletMode und seine Verwendung Portlets beinhalten eine funktionale Gliederung der zur Laufzeit durchlaufenen Systemzustände. Zu diesem Zweck werden die so genannten Portlet Modes (dt.:

30 4.2 Java Portlets: Spezifikation und Entwicklung 25 Abbildung 4.6. Skizze der unterschiedlichen Abläufe beider Requesttypen Portlet Modi) verwendet. Sie werden von Portlets als Entscheidungskriterium sowohl bei Ausführung von Aktionen als auch bei Generierung von Inhalten verwendet und dienen gleichzeitig dem Portal als wichtiges Kriterium zur Verwaltung der innerhalb eines Portlets vorliegenden, feingranularen Zugriffsrechte. Jedes Portlet befindet sich zur Laufzeit in genau einem Portlet Modus. Der Übergang in einen neuen Modus geschieht i.d.r innerhalb der in Kapitel beschriebenen Methode processaction, er kann aber explizit auch auf Seiten der Benutzerschnittstelle durch entsprechende Angaben innerhalb eines Requests eingeleitet werden. Die Portlet-Spezifikation beinhaltet drei vordefinierte Portlet Modi, welche im Folgenden aufgeführt und erläutert werden. Die Art und Weise der Verwendung einzelner Modi im Zusammenhang mit der zugehörigen Funktionalität eines Portlets ist nicht durch die Spezifikation festgelegt. Sie unterliegt der freien Entscheidung des Entwicklers. VIEW Modus Der VIEW Modus ist der am Häufigsten verwendete Modus, er repräsentiert daher auch gleichzeitig den Standardmodus eines Portlets. Er wird verwendet zur Darstellung von Informationen und bietet dem Benutzer die Möglichkeit mit dem Portlet zu interagieren, um z.b. zwischen verschiedenen Anzeigefenstern zu navigieren. Die in diesem Modus angezeigten Informationen reflektieren i.d.r. den aktuellen Systemzustand des Portlets. Der VIEW Modus muss von jedem Portlet unterstützt werden. EDIT Modus Innerhalb des EDIT Modus stellt ein Portlet die Funktionalität zur Verfügung, welche vom Benutzer benötigt wird, um benutzerorientierte Daten einzugeben und zu verwalten. Beispiel hierfür könnte die Bereitstellung von Formularen sein zur

31 4.2 Java Portlets: Spezifikation und Entwicklung 26 benutzerspezifischen Konfiguration der Portletoberfläche. Der EDIT Modus ist optional. Er muss daher nicht zwingend von einem Portlet unterstützt werden. HELP Modus Der HELP Modus wird verwendet, um dem Benutzer Hilfsinformationen anzuzeigen, welche Auskunft über die Funktionalität und die Bedienung des Portlets geben. Ähnlich wie der EDIT Modus ist auch dieser Modus optional. Neben den durch die Spezifikation vordefinierten Modi steht es dem Entwickler frei, eigene Portlet Modi zu verwenden. Gleichzeitig kann auch jedes Portal seine spezifischen Modi besitzen. Aus Kompatibilitätsgründen muss der Portletentwickler daher beim Auftreten inkompatibler Portlet Modi entsprechende Mapping- Regeln angeben, welche dem Portal Auskunft darüber geben, auf welche Weise portletspezifische Modi zur Laufzeit portalspezifischen Modi zugewiesen werden sollen Der WindowState und seine Verwendung Ein Window State (dt.: Fensterzustand) beeinflusst die Darstellung eines Portlets. Er gibt Auskunft darüber, wie viel Platz einem Portlet zur Darstellung seines Inhalts auf einer Portalseite zur Verfügung steht. Die Angabe des Fensterzustands wird sowohl vom Portlet bei der Generierung des Inhalts als auch vom Portal zum Aufbau einer Portalseite verwendet. Ein Zustandswechsel kann entweder im Zuge eines action Requests innerhalb der Methode processaction stattfinden oder explizit auf Seiten der Benutzeroberfläche gefordert werden. Angelehnt an die bekannte Darstellungsweise von Programmfenstern im Betriebssystem Windows beinhaltet die Portlet-Spezifikation drei verschiedene Fensterzustände, welche im Folgenden aufgeführt werden. Die Spezifikation beinhaltet keine genaue Darstellungsvorschrift, welche durch Portale eingehalten werden muss. Die Darstellungsart der einzelnen Zustände ist daher portalspezifisch. Normal Fensterzustand Der Normal Fensterzustand wird immer dann von einem Portlet verwendet, wenn sein Inhalt zusammen mit anderen Portlets auf einer Portalseite angezeigt wird. Dabei wird jedem Portlet eine bestimmte Fläche der Portalseite zugeteilt. In Abhängigkeit der Inhaltsmenge muss ein Portlet bei Erhalt dieses Fensterzustands den Inhalt des zu erstellenden Portletfragments einschränken bzw. kürzen. Die Implementierung dieser Funktionalität ist jedoch dem Portletentwickler freigestellt.

32 4.2 Java Portlets: Spezifikation und Entwicklung 27 Maximized Fensterzustand Im Gegensatz zum Normal Fensterzustand kann der Maximized Fensterzustand immer nur einem Portlet auf einer Portalseite zugewiesen werden. Dem Portlet wird dadurch mitgeteilt, dass es im Vergleich zu allen anderen Portlets eine größere Fläche der Portalseite zur Darstellung seines Inhalts zur Verfügung gestellt bekommt. In vielen Portalen entspricht der Maximized Zustand einer alleinigen Darstellung auf einer Portalseite. Minimized Fensterzustand Die Darstellung eines Portlets im Minimized Fensterzustand beinhaltet i.d.r. einen minimalen oder keinen Inhalt. Häufig werden in diesem Fensterzustand nur der Titel und eine entsprechende Schaltfläche zum Wechseln des aktuellen Fensterzustands dargestellt Das PortletURL Objekt und seine Verwendung Fast immer beinhaltet die Darstellung eines Portlets Verlinkungen auf weitere Inhalte des gleichen Portlets oder des zugehörigen Portals. Zu diesem Zweck werden URLs erzeugt und verwendet, die entweder auf das Portlet selbst oder auf weitere dem Portal zugehörige Portlets verlinken. Als Beispiel einer Verlinkung auf sich selbst sei an dieser Stelle das Abschicken eines Formulars aufgeführt, welches durch das selbige Portlet verarbeitet werden soll. Alle URLs dieser Art werden als PortletURL bezeichnet. Die Repräsentation solcher URLs geschieht durch Erzeugung von PortletURL Objekten, welche das zur Spezifikation zugehörige PortletURL Interface implementieren müssen. In der Praxis erfolgt das Generieren eines solchen Objektes über Aufruf der Methode createactionurl bzw. createrenderurl des RenderResponse Interfaces. Aufbauend auf den beiden in Kapitel aufgeführten Requestarten wird zwischen zwei verschiedenen Typen von PortletURL Objekten unterschieden. Ein PortletURL Objekt, welches durch Aufruf der oben aufgeführten Methode createrenderurl erzeugt wird, wird vom Portal zu einem render Request verarbeitet, der anschließend an das zugehörige Portlet delegiert wird und dort zum Aufruf der Methode render führt. Dabei muss durch das Portal sichergestellt werden, dass die an das PortletURL Objekt übergebenen Parameter an den render Request weitergereicht werden. Ein PortletURL Objekt, welches durch Aufruf der oben aufgeführten Methode createactionurl erzeugt wird, wird vom Portal als action Request an das betreffende Portlet delegiert und führt zum Aufruf der Methode processaction, mit anschließendem Aufruf der Methode render. Auch hier müssen die zugehörigen

33 4.2 Java Portlets: Spezifikation und Entwicklung 28 Parameter an das in diesem Fall vorliegende ActionRequest Objekt weitergereicht werden. Das Anbinden von Parametern an ein PortletURL Objekt geschieht unter Verwendung der Methoden setparameter bzw. setparameters. Zusätzlich zu den übergebenen Parametern kann ein PortletURL Objekt weitere Informationen beinhalten, wie z.b. einen Window State (siehe Kapitel 4.2.5) oder einen Portlet Mode (siehe Kapitel 4.2.4). Der folgende Quellcodeauszug veranschaulicht das Erzeugen eines PortletURL Objektes mit anschließendem Anbinden eines Parameters sowie eines Window State und eines Portlet Mode.... PortletURL url = response.createrenderurl(); url.setparameter("parametername","parameterwert"); url.setwindowstate(windowstate.normal); url.setportletmode(portletmode.view); Erläuterung des Portlet Requests Die im Vorangegangenen aufgeführten Request Objekte sind ein wesentlicher Bestandteil der Spezifikation. Sie beinhalten wichtige Informationen wie z.b. Parameter, Portlet Mode oder Window State und bilden zusammen mit den Response Objekten die Kommunikationsplattform zwischen einem Portlet und seiner HTTPbasierten Benutzerschnittstelle. Wie bereits in Abschnitt und aufgeführt, beinhaltet die Spezifikation zwei unterschiedliche Requesttypen. Ein action Request basiert auf dem ActionRequest Interface. Alle render Requests hingegen implementieren das RenderRequest Interface. Die gemeinsame Grundlage beider Schnittstellen bildet das übergeordnete PortletRequest Interface. Ein action Request wird durch das Portal an die Methode processaction des betroffenen Portlets delegiert. Ergebnis dieser Methode ist u.a. ein render Request, der an die Methode render weitergereicht wird. Neben den oben aufgezeigten Informationen besitzt jedes Request Objekt weitere Eigenschaften, welche im Folgenden kurz erläutert werden. Request Attributes sind Objekte, die innerhalb einer Anfrage mit einem Portlet assoziiert werden. Request Attribute können sowohl durch das betroffene Portlet als auch durch das Portal gesetzt werden. Sie ermöglichen den Austausch von Daten mit übergeordneten Servlets oder JSPs. Request Properties bilden einen weiteren Bestandteil eines Request Objektes. Sie beinhalten portalspezifische Informationen und bieten Zugriff auf den Inhalt des zum Request zugehörigen HTTP-Headers.

34 4.2 Java Portlets: Spezifikation und Entwicklung 29 Security Attributes geben Auskunft über sicherheitsrelevante Informationen bezüglich der Verbindung und des Benutzers. Sie unterstützen die Steuerung und Kontrolle von Zugriffsrechten. Das Local Attribute wird vom Portlet im Zuge der Internationalisierung benötigt. Es informiert das Portlet darüber, welche Sprache der Benutzer zum Zeitpunkt der Anfrage verwendet bzw. im Portal eingestellt hat. Auf diese Weise kann es bei der Erstellung des Response Objektes und somit auch des zugehörigen Fragments bzw. der zugehörigen Ausgabe entsprechend reagieren Erläuterung der Portlet Response Ein Response Objekt bildet das Gegenstück zum Request Objekt. Es enthält alle Informationen, die nach einer Anfragebehandlung vom Portlet an den Portlet- Container zurückgeschickt werden. Das Portal bzw. der Portlet-Container verwendet die übergebenen Informationen zum Erstellen der aktualisierten Portalseite. Ein Response Objekt wird bei Eintreffen eines Request Objektes vom Portlet- Container zusammen mit diesem an das betroffene Portlet übergeben. Ähnlich wie bei den Request Objekten beinhaltet die Spezifikation zwei unterschiedliche Responsetypen. Jedes ActionResponse Objekt besitzt die Methoden des gleichnamigen Interfaces. Jedes RenderResponse Objekt hingegen basiert auf dem RenderResponse Interface. Beide Schnittstellen sind vom PortletResponse Interface abgeleitet. Das ActionResponse Objekt wird zusammen mit einem ActionRequest Objekt beim Aufruf der Methode processaction eines Portlets übergeben. Es bietet dem Entwickler die Möglichkeit, den Portlet Mode sowie den Window State festzulegen. Außerdem kann über die Methode sendredirect eine URL angegeben werden, auf welche nach Abschluss der Anfragebehandlung durch den Portlet-Container verwiesen werden soll. Wird anschließend die Methode render des Portlets aufgerufen, so hat der Entwickler über das ActionResponse Objekt die Möglichkeit, über entsprechende Methoden Parameter aus dem ActionRequest Objekt an das weiterführende RenderRequest Objekt zu übergeben. Ein RenderResponse Objekt wird immer zusammen mit einem RenderRequest Objekt beim Aufruf der Methode render an das Portlet übergeben. Es stellt entsprechende Funktionalität zur Verfügung, um die Darstellung des Portlets auf der folgenden Portalseite an den Portlet-Container zu übergeben Das PortletPreferences Interface Um Portale in ihrer Personalisierungsfunktionalität zu unterstützen, beinhaltet die Portlet-Spezifikation das so genannte PortletPreferences Interface. Zugehörige

35 4.2 Java Portlets: Spezifikation und Entwicklung 30 Objekte bieten die Möglichkeit, personalisierte Konfigurationseinstellungen von Portlets zu speichern. Das persistieren des Inhalts solcher Objekte ist Aufgabe des Portlet-Containers. Ein Portlet ist weder am Erzeugungs- noch am Zerstörungsprozess seines zugehörigen PortletPreferences Objektes beteiligt. Diese Aufgaben unterliegen ebenfalls dem Portlet-Container. Portlets können ausschließlich über die bereitgestellten Methoden des Interfaces mit einem PortletPreferences Objekt kommunizieren. Jedes Portlet besitzt genau ein PortletPreferences Objekt pro Benutzer Das PortletSession Interface Sessions spielen eine wichtige Rolle für das Erkennen zusammengehöriger Anfragen. Sie ermöglichen eine sinnvolle Kommunikation, die über einen einmaligen Austausch von Informationen hinausgeht. Die am häufigsten von Webanwendungen verwendete Variante beruht auf der Generierung einer eindeutigen Session-ID, welche bei der Übertragung von Nachrichten zwischen Client und Server ständig mit übergeben wird. Auf diese Weise kann eine Webanwendung jeder erhaltenen Nachricht einen bestimmten Client zuordnen. Dies ermöglicht der Anwendung eine Folge von Nachrichten als einen zusammenhängenden Prozess zu erkennen. Die Portlet-Spezifikation beinhaltet zur Verwendung von Sessions das Portlet- Session Interface. Jede Portletanwendung 5 besitzt für jeden zur Laufzeit angemeldeten Benutzer genau ein PortletSession Objekt. Die Verwaltung der PortletSession Objekte gehört zum Aufgabenbereich des Portlet-Containers. Er entscheidet welches Request bzw. Response Objekt welchem PortletSession Objekt zugeordnet wird. PortletSession Objekte bieten dem Entwickler die Möglichkeit, zusätzliche Objekte anzubinden. Hierfür legt der Entwickler den Gültigkeitsbereich des jeweiligen Objektes selbst fest. Das PortletSession Interface unterscheidet dabei in zwei verschiedene Bereiche. Objekte, die unter dem Gültigkeitsbereich APPLICATION SCOPE an ein PortletSession Objekt gebunden werden, sind innerhalb einer Portletanwendung für jedes zugehörige Portlet(fenster) zugänglich. Im Gegensatz dazu steht der PORTLET SCOPE. Er beschränkt den Zugriff auf genau das Portlet(fenster), welches dem PortletSession Objekt das betroffene Objekt hinzugefügt hat. Der folgende Quellcodeauszug demonstriert das Anbinden von Objekten an ein Session Objekt.... PortletSession session = request.getportletsession(); session.setattribute("username","armin admin", 5 Eine Portletanwendung besteht i.d.r. aus einem Portlet, kann aber auch aus mehreren Portlets bestehen, die ein gemeinsames Backend besitzen.

36 4.2 Java Portlets: Spezifikation und Entwicklung PortletSession.APPLICATION_SCOPE); Technisch betrachtet basiert jede PortletSession auf einer HTTPSession, welche das Äquivalent der Servlet-Spezifikation zu einer PortletSession darstellt. Dies hängt damit zusammen, dass ein Portlet-Container immer innerhalb eines Servlet-Containers läuft. Der hierdurch entstehende Vorteil besteht in dem gemeinsamen Zugriff auf anwendungsspezifische Daten einer Session durch zugehörige Servlets und JSPs. Aufgabe des Portlet-Containers ist hierbei die Gültigkeit einer Session zu synchronisieren. Wird eine PortletSession für ungültig erklärt, so muss die zugehörige HTTPSession ebenfalls ungültig gemacht werden, und umgekehrt Das PortletContext Interface Das PortletContext Interface definiert die Sicht eines Portlets auf die zugehörige Portletanwendung. Hierfür stellt der Portlet-Container pro Portletanwendung ein PortletContext Objekt zur Verfügung, welches jedem zugehörigen Portlet Zugriff auf (Initialisierungs)-Attribute und Ressourcen der Portletanwendung bietet. Als erweiterte Webanwendung basiert jede Portletanwendung auf einem Servlet. Sie besitzt daher auch einen ServletContext, gemäß dem zur Servlet-Spezifikation zugehörigen ServletContext Interface. Alle Initialisierungsparameter des Portlets entsprechen denen des zugehörigen Servlets. Sie werden gemeinsam im Deployment Descriptor der Webanwendung definiert (d.h. in der Datei web.xml). PortletContext und ServletContext einer Portletanwendung beinhalten daher die gleichen Initialisierungsparameter. Ähnlich der Funktionsweise des in Kapitel beschriebenen PortletSession Interfaces, beinhaltet ein ServletContext Objekt gleichzeitig alle im zugehörigen PortletContext Objekt abgespeicherten Objekte und umgekehrt. Servlets, JSPs und Portlets einer Portletanwendung greifen somit auf gemeinsame Kontextinformationen zu. In der Praxis wird dieser Sachverhalt oftmals von Portlets verwendet, um die Ausgabenerzeugung der Benutzerschnittstelle an JSPs zu delegieren. In diesem Zusammenhang tritt das PortletRequestDispatcher Interface auf. Ein PortletRequestDispatcher Objekt dient als Wrapper-Objekt, dessen Aufgabe die Weiterleitung der Anfrage zur Erzeugung einer Ausgabe eines Portlets an eine serverseitige Ressource ist (z.b. Servlet, HTML-Datei, JSP-Datei). Der Zugriff eines Portlets auf ein PortletRequestDispatcher Objekt erfolgt über Aufruf der Methoden getrequestdispatcher und getnameddispatcher des zugehörigen PortletContext Objektes. Dabei müssen entweder Pfad oder Name des gewünschten Objektes angegeben werden. Die Benutzung muss in der Methode render des betroffenen Portlets erfolgen, da das PortletRequestDispatcher

37 4.2 Java Portlets: Spezifikation und Entwicklung 32 Objekt Zugriff auf den RenderRequest und die RenderResponse haben muss, welche ihm durch die Methode include vom Portlet übergeben werden müssen. Der folgende Quellcode zeigt einen Ausschnitt aus einer Methode render und veranschaulicht die Anwendung des PortletRequestDispatcher Interfaces.... String path = "/file.jsp"; PortletRequestDispatcher rd = context.getrequestdispatcher(path); rd.include(renderrequest,renderresponse); Portlets im Zusammenhang mit Servlets Gemessen an der Definition der Servlet-Spezifikation [Cow01, Abschnitt SRV.9] ist jede Portletanwendung eine Web-Applikation. Der Aufbau einer Portletanwendung entspricht daher dem einer Servletanwendung. Neben optionalen JSPs, HTML- Seiten und anderen, serverseitigen Ressourcen beinhaltet jede Portletanwendung zusätzlich ein oder mehrere Portlets, sowie einen für alle Portlets gemeinsamen Deployment Descriptor. Um den Anspruch gerecht zur werden als vollständige Applikation ohne zusätzliche Ressourcen lauffähig zu sein, wird das so genannte Packaging (dt.: Verpacken) verwendet. Web-Applikationen werden bei ihrem Deployment in Form eines Web Archive (WAR) an einen Web-Server übergeben. WARs beinhalten alle durch die Anwendungen benötigen Ressourcen. Ihr Aufbau ist in der Servlet-Spezifikation festgelegt. Beinhaltet ein WAR eine Portletanwendung so enthält es zusätzliche Elemente. Der grobe Aufbau einer WAR-Datei kann wie folgt beschrieben werden: optionale Ressourcen, wie z.b. JSPs, HTML-Seiten, Bilder ein WEB-INF Verzeichnis mit den folgenden Elementen web.xml portlet.xml ein lib-verzeichnis mit benötigten Java Archives (JARs) (optional) ein classes-verzeichnis mit allen Servlet und Portlet Klassen (optional) Für die Verwaltung aller Komponenten der Portletanwendung, mit Ausnahme der Portlets, ist der Servlet-Container zuständig. Portlets werden durch den Portlet-Container verwaltet, welcher auf dem Servlet-Container aufgesetzt ist. Beinhaltet eine Web-Applikation eine Portletanwendung, so findet sich im WEB-INF Verzeichnis des zugehörigen WAR die Datei portlet.xml. Diese stellt den Portlet Deployment Descriptor dar. Ähnlich der Funktionsweise des Servlet Deployment Descriptors enthält die Datei portlet.xml zwei unterschiedliche Arten von Definitionen: Definitionen der Portletanwendung Definitionen der einzelnen Portlets

38 4.2 Java Portlets: Spezifikation und Entwicklung 33 Die aufgeführten Definitionsarten unterscheiden sich in ihrem Gültigkeitsbereich. Definitionen der Portletanwendung gelten zur Laufzeit global, d.h. innerhalb der ganzen Anwendung. Beispiel für eine solche Definition könnte das Festlegen eines eigenen Portlet Modus (siehe Kapitel 4.2.4) sein, der innerhalb der Anwendungen von allen Portlets genutzt werden soll. Im Gegensatz dazu stehen Definitionen, die einzelnen Portlets angehören. Darunter fallen z.b. portletspezifische Initialisierungsparameter, wie der Name eines Portlets. Der Deployment Descriptor unterstützt im Zuge der Internationalisierung auch Lokalisierung, er erlaubt daher die Angabe von Parametern, welche in Abhängigkeit der im Portal eingestellten Sprache verwendet werden. Die Portlet-Spezifikation basiert im Wesentlichen auf der Servlet-Spezifikation. In vielen Teilbereichen der Portlet-Spezifikation findet sich daher die Verwendung der durch die Servlet-Spezifikation definierten Infrastruktur. Als Beispiel seien an dieser Stelle die Bereiche das Deployment, der Aufbau einer Web-Applikation, die Session-Verwaltung und die Lebenszyklus-Verwaltung genannt. Die wichtigsten Gemeinsamkeiten werden im Folgenden aufgezählt. Sowohl Portlets als auch Servlets sind Java-basierte Webkomponenten. Beide Technologien benötigen als Laufzeitumgebung einen spezifischen Container. Portlets und Servlets generieren dynamischen Inhalt. Der Lebenszyklus wird durch den übergeordneten Container verwaltet. Beide Technologien verwenden das Request/Response Paradigma zur Interaktion mit einem Webclient. Die grundlegenden Unterschiede zwischen beiden Technologien lassen sich wie folgt darstellen: Ein Portlet ist nicht eindeutig über einen herkömmlichen URL zu identifizieren. Die Ausgabe eines Portlets bildet kein vollständiges Dokument, im Gegensatz zur Ausgabe eines Servlets. Portlets erzeugen lediglich Markup-Fragmente 6. Es ist Aufgabe des Portals bzw. Portlet-Containers, durch Aggregation mehrerer Portletfragmente eine vollständige Portalseite zu erstellen. Ein Web Client interagiert mit einem Portlet über ein Portal. Portlets verwenden ein detaillierteres Request/Response Modell (Unterteilung in action/render Request bzw. action/render Response). Portlets verwenden Portlet Modes und Window States. Auf einer Portalseite können mehrere Portletinstanzen existieren. 6 Markup-Fragmente repräsentieren Ausschnitte einer Portalseite. Um zu gewährleisten, dass Markup- Fragmente keine vollständigen Dokumente darstellen, unterliegt ihr Inhalt bestimmten Restriktionen. Ein HTML Markup-Fragment darf z.b. die folgenden Tags nicht beinhalten: <base>, <body>, <iframe>, <frame>, <frameset>, <head>, <html>, <title>

39 4.2 Java Portlets: Spezifikation und Entwicklung Die Time Reporting Portletanwendung Im Folgenden wird die Implementierung der Portlet-Spezifikation anhand der Entwicklung der Time Reporting Portletanwendung veranschaulicht. Der Schwerpunkt liegt dabei auf einer technischen Betrachtungsweise des dargestellten Entwicklungsverlaufs. Bezug nehmend auf die Aufgabenstellung dient die Entwicklung der Anwendung unter anderem als Referenzimplementierung bezüglich der Verwendung der angewandten Technologien. Dem Leser wird zum allgemeinen Verständnis im Folgenden die grundlegende Funktionsweise der Anwendung erläutert. Aufgabe der Time Reporting Portletanwendung ist das Verwalten von Einträgen über Tätigkeiten, die durch Mitarbeiter des Unternehmens durchgeführt wurden. Jeder Mitarbeiter kann gleichzeitig an mehreren Projekten arbeiten, in denen er wiederum unterschiedliche Rollen einnehmen kann. In Abhängigkeit von der Rolle, die ein Mitarbeiter in Rahmen eines Projektes besitzt, wird die Durchführung verschiedener Tätigkeiten verlangt. So ist z.b. das Spezifizieren der Requirements (dt.: Anforderungen) Aufgabe eines Analysten. Der gleiche Mitarbeiter, dessen Mitgliedschaft in einem Projekt die Rolle eines Analysten beinhaltet, kann in einem anderen Projekt in der Rolle des Architekten tätig sein. Die Portletanwendung benötigt daher eine Projektverwaltung, welche dem jeweiligen Projektmanager die Möglichkeit bietet, nach Bedarf Rollen und Tätigkeiten festzulegen und diese den Mitgliedern seines Projektes individuell zuzuweisen. Auf diese Weise erhält jeder Mitarbeiter einen personalisierten Zugang zur Portletanwendung, indem er ausschließlich Einträge (gemäß der ihm zugewiesenen Rolle(n)) auf Projekten tätigen kann, in denen er eine Mitgliedschaft besitzt. Das Eröffnen bzw. Schließen eines Projektes darf nicht jedem Mitarbeiter des Unternehmens möglich sein. Benutzer, denen dieses Recht zusteht, benötigen daher eine besondere Rolle. Unabhängig der projektbezogenen Rollen unterscheidet die Portletanwendung daher die zwei folgenden Benutzerrollen, welche sich auf die Benutzung der Anwendung selbst beziehen. Time Reporting Administrator Time Reporting Standardbenutzer Der konzeptionellen Funktionsweise eines Portals folgend, findet die Verwaltung der Benutzerrollen nicht innerhalb der Portletanwendung statt, sondern wird unter Verwendung der Benutzer - und Rollenverwaltung ausgeführt, welche durch das Portal bereitgestellt wird. Diese Vorgehensweise bietet die Möglichkeit, im Portal allgemeingültige Rollen zu verwenden und erspart somit eine zusätzliche Benutzerverwaltungskomponente innerhalb der Anwendung. Die grundlegende Funktionalität, welche einem Standardbenutzer zur Verfügung gestellt wird, beinhaltet das Hinzufügen, Bearbeiten und Löschen von Arbeitseinträgen. Ein Arbeitseintrag (engl.: work entry) repräsentiert eine durchgeführte Arbeitsleistung auf einem Projekt. Projekte werden in öffentliche und private Projek-

40 4.2 Java Portlets: Spezifikation und Entwicklung 35 te unterschieden. Öffentliche Projekte sind (falls nicht explizit durch einen Administrator anders konfiguriert) für jeden Benutzer der Portletanwendung zugänglich. Im Gegensatz dazu stehen private Projekte. Sie verlangen eine explizite Mitgliedschaft, welche einem Benutzer durch den verantwortlichen Projektmanager zugewiesen werden kann. Die Verwaltung der Arbeitseinträge ist personalisiert, d.h. ein Standardbenutzer kann ohne zusätzliche Rechte nur auf seine eigenen Arbeitseinträge zugreifen. Jeder Benutzer kann pro Projekt nur eine Mitgliedschaft besitzen. Eine Mitgliedschaft beinhaltet die Rollen und Rechte eines Mitgliedes innerhalb eines Projektes. Neben den projektbezogenen Rollen besitzt jede Mitgliedschaft ein Benutzerprofil. Profile geben Auskunft über die Rechte eines Benutzers. Sie gelten ähnlich den Rollen nur innerhalb eines Projektes. Ein Benutzer kann daher auf unterschiedlichen Projekten verschiedene Profile besitzen. Die Portletanwendung unterscheidet die vier folgenden Benutzerprofile: Standardmitglied: Standardmitglieder haben das Recht, gemäß der ihnen zugewiesenen Rollen auf einem Projekt Arbeitseinträge hinzu zufügen. Ihr Zugriff beschränkt sich auf eine personalisierte Verwaltung ihrer eigenen Arbeitseinträge. geschäftsführendes Mitglied: Geschäftsführende Mitglieder haben neben den Rechten eines Standardmitgliedes Zugriff auf die Projektstatistik. Standardmitglied mit administrativen Rechten: Standardmitglieder mit administrativen Rechten haben neben den Rechten eines Standardmitgliedes Zugriff auf die Projektkonfiguration, sowie auf die Projektstatistik. Gemeinsam mit dem Projektmanager sind sie für die Rollen- und Mitgliederverwaltung zuständig. Sie haben vollen Zugriff auf die Arbeitseintragsverwaltung jedes Projektmitgliedes. Projektmanager: Ein Projekt besitzt immer genau einen Projektmanager. Er besitzt die gleichen Rechte wie ein Standardmitglied mit administrativen Rechten. Die Mitgliedschaft des Projektmanagers kann aber im Gegensatz zu allen anderen Projektmitgliedern weder deaktiviert noch gelöscht werden. Neben der Rolle des Standardbenutzers stellt die Portletanwendung eine weitere Rolle bereit. Der Time Reporting Administrator besitzt die gleichen Rechte und Funktionen wie ein Standardbenutzer. Darüber hinaus hat er Zugriff auf den Administrationsbereich der Portletanwendung. Dieser erlaubt die Verwaltung aller Projekte. Administratoren können neue Projekte anlegen, Projektmanager auswechseln sowie existierende Projekte sperren bzw. schließen. Ein geschlossenes Projekt ist für seine Mitglieder unzugänglich. Es kann jedoch jederzeit durch den Time Reporting Administrator wiedereröffnet werden. Zusätzlich bietet der Administrationsbereich vollen Zugriff auf alle Projektkonfigurationen und -statistiken. Dabei besitzt ein Administrator dieselben Rechte wie der jeweilige Projektmanager.

41 4.2 Java Portlets: Spezifikation und Entwicklung Verwendete Technologien Die Time Reporting Portletanwendung unterliegt einer mehrschichtigen Anwendungsarchitektur. Die Darstellung des Portlets auf einer Portalseite im Browser des Benutzers entspricht der obersten Anwendungsschicht: dem Presentationlayer (dt.: Präsentationsebene). Die Präsentationsebene bildet die Benutzerschnittstelle der Anwendung. Ihrer Entwicklung liegt vor allem der Einsatz der Technologie JSP zugrunde. Die wesentliche Aufgabe dieser Technologie ist die dynamischen Erzeugung von HTML (oder auch XML) Ausgaben, sowie das Einbetten von Java- Code in statischen Inhalten. Insbesondere wurde in diesem Zusammenhang die JavaServer Pages Standard Tag Library (JSTL) verwendet. Die unterhalb der Präsentationsebene liegende Anwendungsschicht ist der Applicationlayer (dt.: Applikationsebene). Die Applikationsebene beinhaltet die eigentliche Logik der Time Reporting Anwendung. Basierend auf dem Model-View- Controller (MVC) Architekturmuster ist die Applikationsebene unter anderem für die Steuerung der Benutzerschnittstelle verantwortlich. Das MVC Architekturmuster findet seine Anwendung im Time Reporting Portlet durch Verwendung des Spring Frameworks und dessen seit Version 2.0 zugehöriger Komponente, dem Spring MVC Portlet. Neben dieser Komponente bedient sich die Applikationsebene des Inversion of Control (IoC)-Containers, dessen Aufgabe in der Verwaltung benötigter Ressourcen und Objekte (auch Beans genannt) besteht. Die unterste Anwendungsschicht bildet der Persistencelayer (dt. Persistenzebene). Die Persistenzebene dient der Trennung von Daten(-speicherung) und fachlicher Logik. Ihre Aufgabe besteht im Zusammenhang mit der Verwendung von Datenbanken in der automatischen Überführung eines objektorientierten Modells in ein relationales Modell. Das so genannte Mapping befasst sich daher mit dem Abbilden von Anwendungsobjekten in einer Datenbank. Das Time Reporting Portlet verwendet zur Bewältigung dieser Aufgabe die Technologie Hibernate, welche im Zusammenspiel mit dem Spring Framework durch entsprechende Integrationskomponenten eine solide Mapping-Funktionalität zur Verfügung stellt Die Technologie Hibernate und ihre Anwendung Enterprise Information Systems (EIS) sind eine weit verbreitete Systemart. Sie finden ihre Anwendung in allen größeren Unternehmen. EIS dienen der Verwaltung von strukturierten Informationen. Ihre Aufgabe liegt in der Bereitstellung und in dem Austausch von Daten unter verschiedenen Benutzern (an verschiedenen Orten)[BK05]. Das Abspeichern der auftretenden Informationen wird durch die Verwendung von Datenbank Management Systemen realisiert. Dabei hat sich im Laufe der Zeit die Verwendung relationaler Datenbanken durchgesetzt.

42 4.2 Java Portlets: Spezifikation und Entwicklung 37 Mit dem Einzug objektorientierter Programmiersprachen und der Anwendung objektorientierter Denkmuster bei der Entwicklung von Systemen unter gleichzeitiger Verwendung relationaler Datenbanken entstand das Problem des objekt /relationalen Paradigmas. Die Erklärung findet sich in der unterschiedlichen Repräsentation der Daten in einem relationalen System im Vergleich zur Darstellung des Objektnetzes einer typischen, objektorientierten Anwendung. Einen strukturierten Lösungsansatz zur Behebung dieses Problems bietet das so genannte Object/relational mapping (ORM). ORM steht für das Persistieren der Objekte einer Anwendung in entsprechenden Tabellen einer relationalen Datenbank. Die seit 2001 entwickelte Technologie Hibernate ist eine open-source Implementierung des ORM. Sie beinhaltet einen generischen Lösungsansatz. Ihr Anwendungsbereich liegt in der Persistenzebene von objektorientierten Anwendungen, deren Daten in einer Structured Query Language (SQL)-basierten, relationalen Datenbank abgelegt werden sollen. Portal-Systeme und ihre Komponenten gehören zur Kategorie der EIS. Sie werden von Unternehmen verwendet, um verschiedenen Benutzer unterschiedliche Informationen zugänglich zu machen. Das Time Reporting Portlet kann an dieser Stelle als Beispiel für ein klassisches EIS aufgeführt werden. Im Folgenden werden die verschiedenen Objekttypen (auch Entitäten genannt) aufgeführt, welche im Verlauf der Anwendung unter Verwendung des ORM persistiert, d.h. in einer Datenbank abgespeichert werden. Entitäten der Time Reporting Portletanwendung Ein Objekt der Klasse User repräsentiert innerhalb der Anwendung einen Benutzer. Ein User Objekt dient der abstrahierten Abbildung eines realen Benutzers innerhalb des Systems und beinhaltet daher nur solche Attribute, die für die Portletanwendung von Bedeutung sind. Zur eindeutigen Identifikation verwendet die Time Reporting Anwendung die adresse des jeweiligen Mitarbeiters. Daneben beinhaltet jedes User Objekt Vor- und Nachname eines Benutzers sowie das Einrichtungsdatum. Die Klasse Activity dient der Beschreibung von Tätigkeitsfeldern. In Abhängigkeit der Thematik verlangt jedes Projekt die Durchführung bestimmter Tätigkeiten innerhalb des zugehörigen (Entwicklungs-)Prozesses. Klassische Tätigkeiten eines typischen Projektes sind z.b. das Spezifizieren der Anforderungen, das Erstellen eines Objekt Modells oder die Entwicklung eines Prototypen. Die Repräsentation einer Tätigkeit geschieht im Time Reporting Portlet mittels Activity Objekten. Eine Aktivität ist genau einem Projekt zugeordnet. Neben einem Namen besitzt jede Aktivität die Attribute estimatedtime und currenttime. Die Time Reporting Anwendung erlaubt bei Erstellung eines neuen Activity Objektes die Angabe eines Zeitwertes, der eine Schätzung der benötigten Zeit zum Abschluss des betroffenen Tätigkeitsfeldes darstellt. Dieser Schätzwert entspricht i.d.r. dem Zeitwert,

43 4.2 Java Portlets: Spezifikation und Entwicklung 38 der bei der Berechnung zur Erstellung des Angebotes für die jeweilige Tätigkeit veranschlagt wurde. Er wird im Attribut estimatedtime hinterlegt. Dem gegenüber steht die aktuell benötigte Zeit, welche sich über das Auswerten der zugehörigen Arbeitseinträge berechnen lässt. Dieser Wert wird in currenttime abgelegt. Objekte der Klasse Profile entsprechen den in Kapitel aufgeführten Benutzerprofilen. Die Anzahl der möglichen Profile ist fest. Ein Benutzer besitzt für jedes Projekt in der Time Reporting Anwendung genau ein Profil, welches seine Rechte auf dem betroffenen Projekt festlegt. Ein Profile Objekt beinhaltet als Attribut lediglich einen Profilnamen. Jedes Projekt beinhaltet verschiedene Rollen, welche den Mitgliedern eines Projektes zugewiesen werden. Eine Rolle ist immer projektbezogen, d.h. jede Rolle gehört genau einem Projekt an. Die Verwaltung geschieht über die Projektkonfiguration. Die Klasse Role repräsentiert eine Rolle im Time Reporting Portlet. Ähnlich einer Aktivität besitzt ein Role Objekt die Attribute rolename, estimatedtime und currenttime. Neben den aufgeführten Eigenschaften beinhaltet jede Rolle eine Menge von Aktivitäten. Dies entspricht auch dem Abbild aus der Realität. Jeder Mitarbeiter übernimmt als Mitglied innerhalb eines Projektes eine bestimmte Rolle 7. Das Ausüben dieser Rolle geschieht über die Durchführung bestimmter Tätigkeiten. Die Aufgaben eines Analysten unterscheiden sich von denen eines Architekten. Zugehörige Aktivitäten der Rolle eines Entwicklers wiederum unterscheiden von denen eines Architekten. Die Projektkonfiguration der Time Reporting Anwendung bietet daher die entsprechende Funktionalität zur Zuweisung von Activity Objekten an ein Role Objekt. Die beiden Attribute estimatedtime und currenttime berechnen sich über die untergeordneten Aktivitäten einer Rolle. Die Klasse Project dient der Repräsentation eines Projektes innerhalb des Systems. Ein Project Objekt beinhaltet die Attribute projectname, projectmanager, created, active, general und closed. Ein Projekt besitzt immer einen Projektmanager sowie ein Erstelldatum. Das Attribut active liefert Auskunft über den aktuellen Status eines Projektes. Offene Projekte ( active=true) sind für alle Projektmitglieder zugänglich. Ein Projekt ist standardmäßig offen. Geschlossene Projekte ( active=false) gelten als gesperrt oder beendet und sind nur Administratoren der Portletanwendung zugänglich. Das Attribut general gibt an, ob es sich bei der betroffenen Projektinstanz um eine private( general=false) oder öffentliche ( general=true) handelt. Das Datum der Umstellung des Attributes active auf FALSE wird in der Eigenschaft closed festgehalten. Jedes Projekt beinhaltet neben den aufgeführten Attributen eine bestimmte Anzahl an Rollen und Aktivitäten. Außerdem besitzt jedes Projekt eine bestimmte Menge an Mitgliedschaften. 7 Diese Aussage stellt eine vereinfachte Darstellung dar, da einem Mitarbeiter auch mehrere Rollen in einem Projekt zugewiesen werden können.

44 4.2 Java Portlets: Spezifikation und Entwicklung 39 Für die Abbildung einer Mitgliedschaft wird die Klasse Membership verwendet. Ein Membership Objekt dient als Bindeglied zwischen einem User Objekt und einem Project Objekt. Die Kombination User/Project ist eindeutig für jede Mitgliedschaft, da jeder Benutzer nur eine Mitgliedschaft pro Projekt besitzen kann. Jede Mitgliedschaft beinhaltet ein Profil. Die Attribute added, active und lastlog beinhalten zusätzliche Informationen. Das Attribut active gibt Auskunft darüber, ob eine Mitgliedschaft aktiv oder gesperrt ist. Eine gesperrte Mitgliedschaft verbietet dem betroffenen Mitglied den Zugriff auf das zugehörige Projekt. Die Eigenschaft added repräsentiert das Einrichtungsdatum der Mitgliedschaft. Über lastlog lässt sich der letzte Zugriff des betroffenen Mitgliedes eines Projektes feststellen. Außerdem beinhaltet jede Mitgliedschaft die Menge der zugewiesenen Rollen und die Menge der auf der Mitgliedschaft basierenden Arbeitseinträge. Arbeitseinträge werden durch die Klasse WorkEntry definiert. Jeder Arbeitseintrag gehört einer Mitgliedschaft an, welche auch gleichzeitig die Zuordnung zu einem Projekt oder Benutzer zulässt. Daneben verweist ein Arbeitseintrag sowohl auf die Rolle als auch auf die Aktivität unter Verwendung derer die betroffene Eintragung getätigt wurde. Ein WorkEntry Objekt beinhaltet die zusätzlichen Attribute comment, duration und day. Das Attribut comment bietet einem Benutzer die Angabe von zusätzlichen Informationen bei der Erstellung eines Arbeitseintrags. Durch die Eigenschaften duration und day werden die Dauer der Arbeit und der Tag der Eintragung festgehalten. Dieser muss nicht zwingend dem Zeitraum der Tätigkeitdurchführung entsprechen. Benutzer können auch nachträglich Einträge über Tätigkeiten hinzufügen. Außerdem kann sich die Ausübung einer bestimmten Tätigkeit über mehrere Tage erstrecken. Ein WorkEntry Objekt besitzt daher eine Menge von Tagen, welche gemeinsam den Tätigkeitszeitraum festlegen. Abbildung 4.7 skizziert den beschriebenen Zusammenhang der aufgeführten Entitäten der Time Reporting Portletanwendung. Anwendung von Hibernate am Beispiel der Entität Membership Im Folgenden wird am Beispiel der Entität Membership die Anwendung der Technologie Hibernate demonstriert. Die Portletanwendung verwendet im Backend eine relationale Datenbank. Die Entwicklung der Anwendung verlangt daher sowohl die Erstellung eines objektorientierten als auch die eines relationalen Modells. Ohne ORM hätte dies die manuelle Entwicklung zweier Modelle zur Konsequenz. Zum einen die Erstellung der benötigten Java-Klassen als formale Definition der verwendeten Objekte. Zum anderen die Erzeugung des Datenbankmodells durch Erstellung der benötigten Tabellen unter Verwendung von SQL. Durch Anwendung von Hibernate muss lediglich eines der beiden geforderten Modelle erstellt werden. Die Erzeugung des zweiten Modells findet automatisiert statt. Sie wird von Hibernate übernommen. Der Entwickler hat dabei die freie Auswahl über das von Hand zu erzeugende Modell, wobei die automatische Generierung des objektorientierten Modells unter Verwendung eines relationalen Modells mit Einschränkungen ver-

45 4.2 Java Portlets: Spezifikation und Entwicklung 40 Abbildung 4.7. Entitäten der Time Reporting Anwendung und ihre Beziehungen bunden ist. Zum einen werden dafür zusätzliche datenbankorientierte Codegeneratoren benötigt. Ein Beispiel für einen solchen Codegenerator ist die open-source Anwendung Middlegen. Zum anderen kann bei dieser Variante die Transformation nicht zur Laufzeit durchgeführt werden. Bei der Entwicklung der Time Reporting Portletanwendung wurde die Variante der automatischen Erzeugung des relationalen Modells verwendet. Die Erstellung der so genannten persistent classes (dt.: persistenten Klassen) auf Seiten des objektorientierten Modells wurde daher manuell durchgeführt. Um eine korrekte Transformation durchführen zu können benötigt Hibernate zum gegebenen Modell, also der Beschreibung der Klasse, zusätzliche Metadaten. Für die Angabe der benötigten Metadaten existieren verschiedene Möglichkeiten, wie z.b. die Verwendung von XDoclet. Das Time Reporting Portlet verwendet zur Deklaration der Metadaten zusätzliche XML-mapping-Dokumente. Seit der im Oktober 2006 eingeführten Version 3.2 von Hibernate besteht nunmehr auch die Möglichkeit, die benötigten Metadaten unter Verwendung von Java Annotation zu deklarieren. Die Klasse Membership ist Teil des objektorientierten Modells der Portletanwendung. Sie wird im Zusammenhang mit Hibernate auch als peristente Klasse bezeichnet. Ihr Aufbau entspricht dem eines klassischen POJO. Die Verwendung von POJOs hat sich im Zusammenhang mit Hibernate als best practices (dt.: gute Erfahrungen) erwiesen. Listing 4.1 zeigt die wichtigsten Abschnitte der Implementierung der Klasse Membership auf.

46 4.2 Java Portlets: Spezifikation und Entwicklung 41 Listing 4.1. Implementierung der Klasse Membership 1 2 public c l a s s Membership implements Comparable<Membership> 3 { 4 / Define p r o p e r t i e s / 5 private long id ; 6 private P r o j e c t p r o j e c t ; 7 private User u s e r ; 8 private P r o f i l e p r o f i l e ; 9 private Boolean a c t i v e ; 10 private Date added ; 11 private Date l a s t l o g ; 12 private Set <Role> r o l e s = new HashSet<Role >(); 13 private Set <WorkEntry> w o r k e n t r i e s = new TreeSet<WorkEntry >(); / Define S e t t e r / Getter methods / 16 public Long g e t I d ( ) { 17 return id ; 18 } 19 public void s e t I d ( long id ){ 20 this. id = id ; 21 } public User getuser ( ) { 24 return u s e r ; 25 } 26 public void s e t U s e r ( User u s e r ){ 27 this. u s e r = u s e r ; 28 } public Set g e t R o l e s ( ) { 33 return r o l e s ; 34 } 35 public void s e t R o l e s ( Set<Role> r o l e s ){ 36 this. r o l e s = r o l e s ; 37 } 38 public void addrole ( Role r o l e ){ 39 r o l e s. add ( r o l e ) ; 40 } / Define t h e c r i t e r i o n to compare two membership o b j e c t s / 45 public int compareto ( Membership m){ 46 return this. getuser ( ). getlastname ( ). 47 comparetoignorecase (m. getuser ( ). getlastname ( ) ) ; 48 } }

47 4.2 Java Portlets: Spezifikation und Entwicklung 42 Die Klasse Membership besitzt implizit einen leeren Konstruktor. Die Bereitstellung eines leeren Konstruktors ist für alle persistenten Klassen im Zusammenhang mit Hibernate Pflicht, da Hibernate bei der Erzeugung von Objekten persistenter Klassen den Aufruf Constructor.newInstance() der Java Reflection API verwendet. Neben einem leeren Konstruktor benötigt Hibernate für jede Property (dt.: Eigenschaft) zugehörige Zugangsmethoden, welche allgemein als Getter/Setter Methoden bekannt sind. Bezug nehmend auf die JavaBean Specification verlangt Hibernate eine korrekte Namensgebung der Methoden. Eine Setter Methode muss immer mit dem Präfix set gefolgt vom Namen der betroffenen Property, wobei der erste Buchstabe groß geschrieben wird, beginnen. Ähnlich verhält es sich bei Getter Methoden mit der Ausnahme, dass bei einer Property vom Typ Boolean auch das Präfix is verwendet werden darf. Um die eindeutige Identifizierung eines Objektes in seinem relationalen Abbild zu gewährleisten, findet sich in jeder persistenten Klasse eine zusätzliche Property, das identifier attribute (dt.:identifikationsattribut). In der Klasse Membership wird das Identifikationsattribut durch das Attribut id vom Typ long vertreten. Es dient als eindeutiger Primärschlüssel beim Ablegen eines Objektes in einer Tabelle der Datenbank. Besitzen zwei Membership-Instanzen den gleichen Wert als Identifikationsattribut, so basieren sie auf einem gemeinsamen Datensatz in der Datenbank. Hibernate benötigt zur Durchführung des ORM neben der Implementierung der Klasse zusätzliche Daten. Diese Daten werden als ORM-Metadaten bezeichnet. Sie dienen als Transformationsregeln zur Überführung des objektorientierten Modells. Die Angabe der ORM-Metadaten soll am Beispiel der Klasse Membership veranschaulicht werden. Das folgende XML-mapping-Dokument beinhaltet die benötigten Transformationsregeln. Listing 4.2. ORM -Metadaten der Klasse Membership 1 2 <?xml version= 1. 0?> 3 <!DOCTYPE hibernate mapping PUBLIC 4 //Hibernate / Hibernate Mapping DTD 3.0//EN 5 h t t p : // h i b e r n a t e. s o u r c e f o r g e. net / hibernate mapping 3.0. dtd > 6 7 <hibernate mapping> 8 9 <c l a s s 10 name= lu. i n f e u r o p e. epp. t i m e r e p o r t i n g. p e r s i s t e n c e. e n t i t i e s. Membership 11 t a b l e= MEMBERSHIP > <i d name= i d column= MEMBERSHIP ID > 14 <g e n e r a t o r c l a s s= n a t i v e /> 15 </ i d> 16

48 4.2 Java Portlets: Spezifikation und Entwicklung <many to one name= p r o j e c t column= PROJECT ID 18 c l a s s= lu. i n f e u r o p e. epp. t i m e r e p o r t i n g. p e r s i s t e n c e. e n t i t i e s. P r o j e c t 19 not n u l l= t r u e /> <many to one name= u s e r column= USER ID 22 c l a s s= lu. i n f e u r o p e. epp. t i m e r e p o r t i n g. p e r s i s t e n c e. e n t i t i e s. User 23 not n u l l= t r u e /> <many to one name= p r o f i l e column= PROFILE ID 26 c l a s s= lu. i n f e u r o p e. epp. t i m e r e p o r t i n g. p e r s i s t e n c e. e n t i t i e s. P r o f i l e 27 not n u l l= t r u e /> <property name= added type= timestamp /> <property name= l a s t l o g type= timestamp /> <property name= a c t i v e /> <s e t name= r o l e s t a b l e= MEMBERROLES > 36 <key column= MEMBERSHIP ID /> 37 <many to many 38 c l a s s= lu. i n f e u r o p e. epp. t i m e r e p o r t i n g. p e r s i s t e n c e. e n t i t i e s. Role 39 column= ROLE ID /> 40 </ s e t> <s e t name= w o r k e n t r i e s s o r t= n a t u r a l > 43 <key column= MEMBERSHIP ID /> 44 <one to many 45 c l a s s= lu. i n f e u r o p e. epp. t i m e r e p o r t i n g. p e r s i s t e n c e. e n t i t i e s. WorkEntry /> 46 </ s e t> </ c l a s s> </ hibernate mapping> Jedes XML-mapping-Dokument unterliegt einer Document Type Declaration (DTD), anhand derer die syntaktische Korrektheit der XML-Datei geprüft werden kann. Der Verweis auf die anzuwendende DTD findet sich in Listing 4.2 in den Zeilen 3-5. Der eigentliche Inhalt des XML-Dokumentes befindet sich innerhalb des Elementes <hibernate-mapping>. Hier werden die Mapping-Regeln für beliebig viele persistente Klassen deklariert. Die Regeln einer Klasse werden zusammen innerhalb eines <class> Elementes angegeben. Da in der Time Reporting Anwendung jede persistente Klasse ihr eigenes XML-mapping-Dokument besitzt, beinhaltet das in Listing 4.2 aufgeführte <hibernate-mapping> Element nur ein <class> Element. Das Attribut name des <class> Elementes wird verwendet, um auf die persistente Klasse zu verweisen, deren Mapping-Regeln innerhalb des Elementes beschrieben werden. Dabei wird der komplette Namensraum der Klasse angegeben (siehe Zeile 10). Das Attribut table beinhaltet den gewünschten Tabellennamen, der bei Erstellung bzw. Verwendung des relationalen Modells angewandt werden

49 4.2 Java Portlets: Spezifikation und Entwicklung 44 soll. Die Angabe ist optional, d.h. wird kein Tabellennamen explizit angegeben, verwendet Hibernate den Klassennamen als Tabellennamen. Das <id> Element wird verwendet um die Mapping-Informationen des Identifikationsattributes der betroffenen Klasse zu definieren. Über das Attribut name wird der Name der Property angegeben, welche die Aufgabe der eindeutigen Identifizierung in der Datenbank 8 übernimmt. Jede persistente Klasse der Time Reporting Anwendung besitzt daher die zusätzliche Property id zur Bestimmung der database identity (dt.: Datenbankidentität) 9. Neben dem Attributsnamen kann zusätzlich über die Eigenschaft column der gewünschte Spaltennamen angegeben werden, der für die Darstellung des Identifikationsattributes als Primärschlüssel in der Tabelle verwendet wird (siehe Zeile 13). Wird kein Spaltenname explizit angegeben, so verwendet Hibernate den Namen des Attributes aus der Klasse. Das Identifikationsattribut einer persistenten Klasse muss nicht zwingend zusätzlich hinzugefügt werden. Hierfür können auch vorhandene Attribute verwendet werden, welche die gängigen Kriterien eines Primärschlüssels erfüllen, wie z.b. Eindeutigkeit, Unveränderlichkeit oder niemals NULL. Dennoch empfiehlt sich bei der Verwendung von ORM die Verwendung expliziter Identifikationsattribute. Sie werden auch synthetic identifiers (dt.: künstliche Identifikatoren) genannt. Ihr Wert wird automatisch durch die Applikation oder die Datenbank generiert. Hibernate erlaubt die Anwendung verschiedener Generatoren, welche unterschiedliche Strategien anwenden. Für die Time Reporting Anwendung wurde der native- Generator verwendet. Dieser bedient sich in Verwendung mit der für die Applikation verwendeten Datenbank MySQL 5.0 der durch die Datenbank bereitgestellten auto increment-funktion. Die Angabe der Verwendung eines bestimmten Generators geschieht im XML-mapping-Dokument über das <generator> Element (siehe Listing 4.2 Zeile 14). Wie in Abbildung 4.7 dargestellt stehen die einzelnen Entitäten in unterschiedlichen Beziehungen zueinander. Ein Projekt kann z.b. 0..* Mitgliedschaften besitzen. Jede Mitgliedschaft hingegen gehört genau zu einem Projekt. Hibernate unterscheidet die vier folgenden Arten von Beziehungen zwischen Entitäten untereinander: one-to-one: Eine one-to-one Beziehung sagt aus, dass eine Entität 0 oder 1 Referenz auf eine andere Entität haben kann und umgekehrt. one-to-many: Ein Objekt der Entität A kann 0..* Referenzen auf Objekte der Entität B haben, wohingegen Objekte der Entität B nur 0 oder 1 Referenz auf 8 Hibernate unterscheidet in die Begriffe object identity (hier: identische Adresse im Speicher), object equality (hier: gleiche Werte) und database identity (hier: gleicher Primärschlüssel und in gleicher Tabelle). Das identifier attribute bestimmt die database identity einer Entität. 9 Die Identifikationsattribute eine persistenten Klasse und deren Verweis über die Eigenschaft name im XML-mapping-Dokument können optional weggelassen werden. In diesem Fall verwaltet Hibernate die Datenbankidentität intern. Das Ermitteln der Datenbankidentität eines Objektes geschieht dann über die Methode session.getidentifier(object).

50 4.2 Java Portlets: Spezifikation und Entwicklung 45 ein Objekt der Entität A haben können. Beispiel für die Entität A ist die Klasse Project, deren Objekte 0..* Referenzen auf Objekte der Klasse Membership haben können. many-to-one: Ein Objekt der Entität A kann 0 oder 1 Referenz auf ein Objekt der Entität B haben, wohingegen Objekte der Entität B 0..* Referenzen auf Objekte der Entität A haben können. Beispiel für die Entität A ist die Klasse Membership, deren Objekte 0 oder 1 Referenz auf ein Objekt der Klasse Project haben können. many-to-many: Objekte der Entität A können 0..* Referenzen auf Objekte der Entität B haben und umgekehrt. Ein Objekt der Klasse Membership kann z.b. 0..* Referenzen auf Role-Objekte haben und umgekehrt. Die aufgeführten Beziehungen werden als Metadaten innerhalb des XMLmapping-Dokumentes verwendet. So wird z.b. das <many-to-one> Element in Listing 4.2 (Zeile 17-19) verwendet, um die Beziehung der Property project auf die persistente Klasse Project zu definieren. Dabei wird das Attribut class verwendet, um auf die betroffene Klasse zu verweisen. Die Eigenschaften id und column haben dieselbe Verwendung wie bereits für das <id> Element beschrieben. Zusätzlich wird das Attribut not-null benutzt, welches verwendet werden kann, um eine Aussage darüber zu treffen, ob das zugehörige Feld in der Datenbank den Wert null annehmen darf oder nicht. Das <many-to-one> Element wird in der Datenbank über einen Fremdschlüssel realisiert. Dafür wird in der Tabelle MEMBERSHIP die Spalte PROJECT ID angelegt, welche den Primärschlüssel des zugehörigen Projektes bzw. des zugehörigen Datensatzes aus der Tabelle PROJECT beinhaltet. Die Eigenschaften user und profile der Klasse Membership werden auf die gleiche Weise in der Datenbank abgebildet. In Java besitzen alle Objekte eine eindeutige Identität über ihre Adresse im Speicher (die so genannte object identity). Die Instanzen einer Klasse werden als Referenzen übergeben, mit Ausnahme der primitiven Objekttypen, bei denen eine Wertübergabe durchgeführt wird. Hibernate führt im Gegensatz zur allgemeinen Java-Sichtweise eine zusätzliche Unterscheidung von Instanzen in Abhängigkeit der Datenbankidentität durch. Ein Objekt ist demnach vom Typ entity, wenn es seine eigene Datenbankidentität besitzt, d.h. einem Datensatz einer Tabelle entspricht und einen eindeutigen Primärschlüssel hat. Referenzen auf dieses Objekt werden in der Datenbank über einen Fremdschlüssel realisiert. Die Existenz eines Objektes vom Typ entity steht in keiner Abhängigkeit zu der einer anderen Entität. Dem gegenüber stehen Objekte vom Typ value. Sie besitzen keine eigene Datenbankidentität. Ihre Darstellung in der Datenbank entspricht dem Wert einer Tabellenspalte eines Datensatzes 10. Value-typische Objekte gehören immer zu einer Entität. Die Lebensdauer von Objekten dieses Typs ist daher an die der zugehörigen Entität gebunden. 10 mit Ausnahme so genannter Collections

51 4.2 Java Portlets: Spezifikation und Entwicklung 46 Die Klasse Membership besitzt Objekte vom Typ value. Die Attribute active, added und lastlog verweisen im Bezug auf Abbildung 4.7 auf keine Entitäten. Keines der betroffenen Objekte (weder die beiden Objekte vom Typ Date noch das Objekt vom Boolean) beinhaltet seine eigene Datenbankidentität. Sie werden daher in der Datenbank jeweils als einzelner Feldwert eines Datensatzes abgespeichert. Die Angaben zum Mapping dieser Attribute werden unter Verwendung des <property> Elementes getätigt. Dabei wird über die zugehörige Eigenschaft name der Name des Attributes aus der betroffenen Klasse angegeben. Zusätzlich können im <property> Element die Attribute column, für den gewünschten Spaltennamen, und type, für die explizite Angabe des gewünschten Datenbanktyps verwendet werden. Die Benutzung des <property> Elementes wird in Listing 4.2 in den Zeilen 29, 31 und 33 dargestellt. Neben den bisher aufgeführten, und im Zusammenhang mit ORM zur Veranschaulichung verwendeten Attributen beinhaltet die Klasse Membership zwei Eigenschaften vom Typ Set (siehe Listing 4.1 Zeile 12 und 13). Das Attribut roles einer Mitgliedschaft beinhaltet 0..* Referenzen auf Objekte der Klasse Role. Dies entspricht der Aussage, dass einem Projektmitglied mehrere Rollen zugewiesen werden können. Umgekehrt lässt sich anhand von Abbildung 4.7 ablesen, dass eine Rolle von mehreren Mitgliedern ausgeführt werden kann. Diese Beziehung wird von Hibernate als many-to-many bezeichnet. Jede der beiden Entitäten kann mehrere Objektreferenzen auf ihr gegenüber haben. Um diese Beziehung im XML-mapping-Dokument angeben zu können wird das <many-to-many> Element verwendet. Zusätzlich müssen Angaben zur Art der Collection (dt.: Sammlung) gemacht werden. Hibernate unterscheidet zwischen den vier Arten Set, Bag, List und Map. Ein Set beinhaltet eine ungeordnete (wohlmöglich aber sortierte 11 ) Menge von Objekten, die keine Duplikate enthält. Die Verwendung eines Set wird durch Angabe des <Set> Elementes bewirkt. Ein Bag unterscheidet sich von einem Set durch das Zulassen von Duplikaten. Hierfür wird das <bag> oder <idbag> Element verwendet. Um eine geordnete Menge, welche Duplikate zulässt, mit Hibernate in einer Datenbank abzubilden wird das <list> Element benutzt. Dabei wird über das <index> Element ein zusätzliches Feld angelegt, welches nur auf Seiten der Datenbank verwendet wird und dafür sorgt, dass die Elemente einer Liste in genau derselben Reihenfolge in einer Tabelle abgespeichert werden, wie sie im zugehörigen Listenobjekt abgelegt sind. 11 Hibernate besitzt eine strikte Trennung zwischen der Bedeutung der Begriffe sorted (dt.: sortiert) und ordered (dt.: geordnet) im Zusammenhang mit Collections. Eine Menge ist sortiert, wenn sie unter Verwendung eines Java Comparator sortiert wurde und sich im Speicherbereich der zugehörigen Anwendung befindet. Ein geordnete Menge hingegen wird auf Datenbankebene durch Anwendung des orderby SQL-Sprachelementes geordnet in der Datenbank abgebildet.

52 4.2 Java Portlets: Spezifikation und Entwicklung 47 Um die Elemente einer Menge nicht entsprechend ihrer Reihenfolge, sondern nach einem bestimmten Attribut (der Objekte einer Menge) in der Datenbank zu ordnen, wird das <map> Element verwendet. Dabei beruht der Index auf einem existierenden (d.h. nicht neu anzulegenden) Feld der Tabelle. Für das Abbilden der Property roles der Klasse Membership wurde das <Set> Element verwendet, da die Menge keine Duplikate beinhalten darf 12. Über das Attribut name wird im XML-mapping-Dokument auf die betroffene Eigenschaft der Klasse verwiesen. Zusätzlich wird das Attribut table verwendet, welches den Namen der Tabelle beinhaltet, die zusätzlich angelegt werden muss, um eine manyto-many Beziehung in der Datenbank darzustellen (siehe Listing 4.2 Zeile 35). Das <key> Element beschreibt durch die Eigenschaft column den Spaltennamen, in welchem die Primärschlüssel der Membership Objekte abgelegt werden sollen, um diese mit denen der Role Objekte zu verknüpfen (Zeile 36). Anschließend wird das bereits erwähnte <many-to-many> Element angewandt. Es beinhaltet die Attribute class und column zur Angabe des vollständigen Klassennamens der betroffenen Entität und zur Angabe des gewünschten Spaltennamens für die Primärschlüssel der zugehörigen Objekte (Zeile 37-39). Abbildung 4.8 zeigt einen beispielhaften Auszug aus der Tabelle MEMBERROLES, die als Ergebnis der angegebenen Metadaten in der Datenbank angelegt wird. Abbildung 4.8. Auszug aus der Tabelle MEMBERROLES Die zweite Property der Klasse Membership, deren zugehörige Metadaten unter Verwendung des <set> Elementes im XML-mapping-Dokument angegeben werden, ist das Feld workentries. Wie in Abbildung 4.7 gezeigt, können einer Mitgliedschaft 0..* Arbeitseinträge angehören, über die ein Mitglied seine durchgeführten Tätigkeiten dem System mitteilt. Umgekehrt besitzt jeder Arbeitseintrag eine Referenz auf ein Objekt der Entität Membership. Aus Sicht von Hibernate handelt es sich dabei um eine gerichtete one-to-many Beziehung, zur dessen Angabe das zugehörige <one-to-many> Element verwendet wird. Im Zusammenhang mit den beiden Begriffen sorted und ordered, lässt sich neben der unterschiedlichen Art der Beziehungen von roles und workentries ein weiterer Unterschied feststellen. Zur Abbildung beider Felder in der Daten- 12 Einem Mitglied kann nicht zweimal die gleiche Rolle zugewiesen werden

53 4.2 Java Portlets: Spezifikation und Entwicklung 48 bank verwendet die Time Reporting Anwendung als Art der Collection ein Set. Beide Mengen werden daher ungeordnet in der Datenbank abgebildet. Ohne die explizite Forderung nach einer Sortierung hat dies eine wahllose Reihenfolge der Mengenelemente nach jedem Abruf aus der Datenbank zur Folge. Da die Reihenfolge der einzelnen Role Objekte im Feld roles für die Anwendung keine Rolle spielt, wird bei der Implementierung der Klasse Membership der Konstruktor der Klasse HashSet verwendet, der keine feste Reihenfolge zur Laufzeit garantiert. Dem gegenüber steht das Feld workentries, welches eine sortierte Reihenfolge zur späteren Darstellung in der Benutzerschnittstelle benötigt. Hierfür wird der Konstruktor der Klasse TreeSet verwendet, der eine sortierte Reihenfolge der Elemente einer Menge garantiert 13 (siehe Listing 4.1 Zeile 12 und 13). Die Sortierung der Mengenelemente kann bei Initialisierung des Feldes durch Hibernate durchgeführt werden. Dafür wird bei Anwendung des <set> Elementes neben name das Attribut sort verwendet. Die Verwendung des <one-to-many> Elementes führt in der Tabelle WORKENTRY zu einer neuen Spalte, die anschließend als Fremdschlüssel den Primärschlüssel des zugehörigen Membership-Objektes beinhaltet. Über das <key> Element wird auf die betroffene Spalte der Tabelle WORKENTRY verwiesen. Das <one-to-many> Element beinhaltet das Attribut class, um durch Angabe des vollständigen Klassennamens auf die in Beziehung stehende Entität zu verweisen. Mit Hilfe des beschriebenen XML-mapping-Dokumentes und der Implementierung der Klasse erhält Hibernate alle Daten, die zur Generierung des relationalen Abbildes benötigt werden. Angelehnt an die aufgeführte Vorgehensweise zur Angabe der Metadaten wurde für jede in Abbildung 4.7 dargestellte Entität neben der Implementierung der Klasse ein entsprechendes XML-mapping-Dokument erstellt. Das Anbinden und Verwenden von Hibernate innerhalb der Time Reporting Anwendung wurde unter Verwendung der Technologie Spring Framework realisiert, welche die Integration von Hibernate ermöglicht. Die Handhabung wird im weiteren Verlauf dieses Dokumentes veranschaulicht Das DAO Pattern Im Zusammenhang mit Spring 14 wird in der Time Reporting Applikation das Data Access Object (DAO) Muster (engl.: Pattern) angewendet. Aufgabe des DAO Pattern ist das Kapseln der Zugriffe auf persistente Daten. Ein DAO verbirgt auf diese Weise den verwendeten Persistenzmechanismus vor der übergeordneten Applikationsschicht und schafft somit eine Unabhängigkeit zwischen beiden. Dabei bildet es die alleinige Schnittstelle zwischen der Anwendung und deren persistenten Daten. Hierdurch entsteht ein weiterer Vorteil. Die Verwendung des DAO Musters ermöglicht durch die entstandene Unabhängigkeit ein einfaches Austauschen des 13 Die Sortierung geschieht dabei einer natural order (dt.: natürlich Ordnung) folgend, unter Verwendung des Comparable Interfaces. Die Klasse Membership implementiert daher die Methode comparableto der Schnittstelle Comparable (Listing 4.1 Zeile 45 bis 48). Die Sortierung erfolgt über den Nachnamen des Mitgliedes. 14 Abkürzung für Spring Framework

54 4.2 Java Portlets: Spezifikation und Entwicklung 49 Persistenzmechanismus, da jedes DAO als Bindeglied zwischen Applikations- und Persistenzschicht die Implementierung der Zugriffsmethoden auf zugehörige persistente Objekte beinhaltet [SDN07]. Die Funktionsweise des DAO Pattern wird im Folgenden anhand der bereits in Kapitel aufgeführten Klasse Membership aufgezeigt und erläutert. Die Unabhängigkeit zwischen Applikationsschicht und Persistenzmechanismus wird über die Verwendung von Interfaces erreicht, die es ermöglichen den verwendeten Mechanismus für die Anwendung transparent erscheinen zu lassen. Ein Objekt der Applikatonsschicht 15 greift auf eine persistente Entität über das zugehörige DAO Interface zu. Die DAO Klasse wiederum, welche das Interface implementiert, verwendet ihren Persistenzmechanismus, um die Zugriffoperationen auf der gewünschten Entität auszuführen. In der Time Reporting Anwendung besitzt jede persistente Klasse ein DAO Interface sowie eine zugehörige DAO Klasse, welche unter Verwendung von Hibernate die Zugriffsmethoden auf die persistente Klasse implementiert. Der Klasse Membership gehören daher das MembershipDAO Interface sowie die Klasse MembershipDAOImpl an. Listing 4.3 zeigt einen Ausschnitt des MembershipDAO Interfaces, der die grundlegenden Zugriffsmethoden der Schnittstelle darstellt. Listing 4.3. Ausschnitt des MembershipDAO Interfaces 1 2 public interface MembershipDAO 3 { 4 / Add new membership / 5 void savemembership ( Membership membership ) ; 6 7 / Remove e x i s t i n g membership / 8 void deletemembership ( Membership membership ) ; 9 10 / Change e x i s t i n g membership / 11 void updatemembership ( Membership membership ) ; } Die Methodendeklarationen save*, delete* und update* finden sich in jedem DAO Interface der Time Reporting Anwendung. Sie ermöglichen das Persistieren, Löschen und Ändern eines Objektes der hier dargestellten Klasse Membership. Alle drei Methoden verlangen als Parameter ein Objekt vom Typ Membership. Listing 4.4 zeigt den zugehörigen Ausschnitt der Klasse MembershipDAOImpl, welche die deklarierten Methoden des Interfaces implementiert. 15 auch Business Objekt oder Geschäftsobjekt genannt

55 4.2 Java Portlets: Spezifikation und Entwicklung 50 Listing 4.4. Ausschnitt der Klasse MembershipDAO 1 2 public c l a s s MembershipDAOImpl extends HibernateDaoSupport implements 3 MembershipDAO 4 { 5 / Add new membership / 6 public void deletemembership ( Membership membership ){ 7 gethibernatetemplate ( ). d e l e t e ( membership ) ; 8 } 9 10 / Remove e x i s t i n g membership / 11 public void savemembership ( Membership membership ){ 12 gethibernatetemplate ( ). save ( membership ) ; 13 } / Change e x i s t i n g membership / 16 public void updatemembership ( Membership membership ){ 17 gethibernatetemplate ( ). update ( membership ) ; 18 } } Die DAO Klassen verwenden als Persistenzmechanismus die Technologie Hibernate. Der Zugriff erfolgt dabei über Spring. Das Spring Framework stellt für den Umgang mit ORM und persistenten Daten zwei Module bereit, das O/R Mapping Modul und das JDBC/DAO Modul. Diese Modul beinhalteten eine Vielzahl an Frameworks, die weniger eigene Lösungen von Spring darstellen, sondern vielmehr die Integration vorhandener Technologien erlauben. Die Klasse MembershipDAOImpl erbt von der Klasse HibernateDaoSupport, welche dem Hibernate ORM Framework aus dem O/R Mapping Modul von Spring entstammt. Sie bietet über die Methode gethibernatetemplate Zugriff auf ein HibernateTemplate Objekt, welches die Verwendung von Hibernate durch die Bereitstellung von Standardmethoden vereinfacht. Die Anbindung an Hibernate wird im Zuge der Erläuterung des Spring Frameworks genauer erklärt. Dem Leser sollte an dieser Stelle das DAO Prinzip und seine Handhabung verständlich sein. Der verwendete Persistenzmechanismus befindet sich in den Methoden der DAO Klasse und wird über Verwendung von Standardmethoden der Klasse HibernateTemplate realisiert (siehe Liste 4.4 Zeile 7, 12 und 17) Das Spring Framework und seine Anwendung Spring ist ein open-source Applikationsframework um Java Platform Standard Edition (J2SE)/Java Platform Enterprise Edition (J2EE) basierende Entwicklungen zu vereinfachen und gute Progammierpraktiken zu fördern [Seu04, Kapitel 3]. Die dabei angewandten Prinzipien entstammen [Joh03]. Der zugehörige Autor, Rod Johnson, gilt gleichzeitig auch als Entwickler der ersten Version des Frameworks. Hauptgrund für die Entwicklung von Spring waren die aufgetretenen Probleme im praktischen Umgang mit der Enterprise Java Bean (EJB) Spezifikation,

56 4.2 Java Portlets: Spezifikation und Entwicklung 51 welche vor allem durch die Verwendung eines monolithischen Containers, sowie mangelnder Anpassungs- und Erweiterungsfunktionalitäten dessen infrastruktureller Dienste entstanden. Die folgende Aussage entstammt [WB05, Kapitel 1.2, Abschnitt 2]. Sie beinhaltet die wesentlichen Bestandteile von Spring. Spring is a ligthweight inversion of control and aspect-oriented container framework Der Begriff lightweight (dt.: leichtgewichtig) verweist im Zusammenhang mit Spring und einem entsprechendem Vergleich mit konkurrierenden Container Frameworks sowohl auf eine geringe Größe (die Dateigröße der JAR-Datei, welche das komplette Framework beinhaltet beträgt gerade mal 2,5 MB) als auch auf den geringen und skalierbaren Aufwand, der für die Einrichtung und Verwendung des Frameworks benötigt wird. Inversion of Control (IoC) bezeichnet eine Technik zur Entkopplung der Abhängigkeiten von Applikationsobjekten untereinander. IoC findet seine Anwendung vor allem im Zusammenhang mit der Verwendung von Frameworks, welche in der Rolle eines koordinierenden Hauptprogramms den Ablauf der Applikation bestimmen. Dabei übernimmt ein übergeordneter Container die Kontrolle zur Verwaltung der Abhängigkeiten ihm untergeordneter Objekte. Die betroffenen Objekte geben hierzu, entgegen der traditionellen Programmierweise, die Verantwortung zur Schaffung notwendiger Referenzen auf kollaborierende Objekte an den Container ab. Diese Verfahrensweise wird auch als Dependency Injection (DI) bezeichnet, da der Container einem Objekt die benötigten Beziehungen injiziert. Des Weiteren bietet Spring einen ausgereiften Mechanismus zur Anwendung aspektorientierter Programmierung (engl.: aspect-oriented programming (AOP)), welche als eine Ergänzung bzw. Erweiterung der objektorierentierten Programmierung angesehen werden kann. AOP ermöglicht eine klare Trennung zwischen der Applikationslogik und den infrastrukturellen Diensten, wie z.b. Transaktion, Persistenz oder Sicherheit einer Anwendung, welche auch als Crosscutting Concerns (dt.: querschneidende Belange) bezeichnet werden. Dabei beschränkt sich die Aufgabe eines Geschäftsobjektes auf die Ausführung von Applikationslogik, indem die Verantwortung von Crosscutting Concerns an den Container abgegeben wird. Die Bedeutung des oben aufgeführten Begriffs Container meint im Zusammenhang mit Spring die Bereitstellung einer Umgebung, welche die Verwaltung von Objekten der Anwendung übernimmt. Der Container steuert dabei den Lebenszyklus eines Objektes und bietet darüber hinaus zusätzliche Konfigurationsmöglichkeiten. Er bildet den Kern des Spring Frameworks. Die Objekte eines Containers werden auch als Beans bezeichnet.

57 4.2 Java Portlets: Spezifikation und Entwicklung 52 Ein Framework ist keine inhaltlich abgeschlossene Anwendung, sondern repräsentiert ein Programmgerüst unter Bereitstellung von Mechanismen, welche den Entwickler bei der Konfiguration und Komposition komplexer Anwendung unterstützen. Das Zusammenführen von Objekten bzw. Programmteilen geschieht in Spring deklarativ durch entsprechende Angaben in XML. Erläuterung der einzelnen Module Der Begriff leichtgewichtig bezieht sich im Zusammenhang mit Spring auch auf die Unterteilung des Frameworks in einzelne Module, welche es dem Benutzer ermöglichen nur die für seine Anwendung relevanten Komponenten zu verwenden und unnötige, überschüssige Funktionalitäten außen vor zu lassen. Das Framework ist in sieben Module unterteilt, welche in Abbildung 4.9 dargestellt sind und im Folgenden kurz erläutert werden. Abbildung 4.9. Module des Spring Frameworks Das wichtigste Modul bildet der Core Container. Auf ihm basieren alle anderen Module. Der Container wird daher implizit bei Entwicklung einer Applikation unter Anwendung des Spring Frameworks benutzt. Der eigentliche Mehrwert liegt aus Sicht des Entwicklers in der Verwendung der übergeordneten Module. Sie bieten unterstützende Funktionalitäten in verschiedenen Bereichen an. Der Core Container beinhaltet die BeanFactory, das Herzstück einer Spring-basierten Anwendung. Sie stellt die bereits angesprochene IoC-Funktionalität bereit. Das Application Context Modul erweitert das Konzept der BeanFactory bzw. des Containers. Es bietet unterstützende Funktionalität hinsichtlich Application life cycle events, internationalization messages, enterprise services und validation

58 4.2 Java Portlets: Spezifikation und Entwicklung 53 an. Außerdem ermöglicht es die Anbindung von EJB sowie die Integration von Template Frameworks, wie z.b. VM oder FreeMarker. Das AOP Modul dient als Basis zur Entwicklung eigener Aspekte einer Anwendung. Aus Interoperabilitätsgründen mit anderen AOP Frameworks beruht dieses Modul auf dem durch die AOP Alliance definierten Application Programming Interface (API). Das AOP Modul bietet außerdem einen Einstieg in die Entwicklung eigener Metadaten (genannt metadata programming). Dies ermöglicht beispielsweise die Verwendung eigener Annotations. Die Hauptaufgabe des JDBC und DAO Moduls liegt in der Bereitstellung unterstützender Funktionalität zur Vereinfachung der Anbindung und Kommunikation mit verschiedenen Datenbanken. Hierbei kommt unter anderem das in Kapitel beschriebene DAO Pattern zum Einsatz. Die Verwendung dieses Moduls erleichtert dem Entwickler die Arbeit mit Datenbanken, nicht zuletzt durch Bereitstellung einer raffinierten Zwischenschicht, welche die durch eine Datenbank oftmals unzureichenden und ungenügenden Fehlermeldungen interpretiert und diese vor der Weiterleitung an die Applikation durch aussagekräftige Fehlermeldungen ersetzt. Das O/R Mapping Modul erlaubt die Integration von generischen ORM Lösungen, wie z.b. Hibernate. Dies ermöglicht dem Entwickler auf eine eigene Implementierung unter Verwendung von JDBC zu verzichten. Das Web Context und Utility Modul von Spring basiert auf dem darunterliegenden Application Context Modul. Es erweitert dessen Funktionalität hinsichtlich der Entwicklung von Webanwendungen. Das Web Modul beinhaltet vorgefertigte Templates zur Bearbeitung von Standardaufgaben im Webbereich. Die Anwendung des MVC Musters wird durch Bereitstellung des MVC Framework Moduls erleichtert. Dies geschieht vor allem durch Verwendung der IoC- Funktionalität des Core Containers. Verwendung des IoC-Containers am Beispiel der Entität Membership Die in Kapitel aufgeführte Entität Membership, sowie deren zugehörige DAO Klasse (siehe Kapitel ) sind Teil der Time Reporting Anwendung. Sie besteht wie jede klassische Java-Anwendung aus verschiedenen Klassen, deren Aufgabenbereiche sich von einander unterscheiden. Spring-basierte Anwendungen lassen sich inbesondere durch die Art und Weise der Konfiguration der Klassen und der Bekanntmachung untereinander von herkömmlichen Anwendungen unterscheiden. Eine typische Spring-Anwendung besitzt dafür (mindestens) eine XML-Datei, die auch als Konfigurationsdatei bezeichnet wird. Sie erlaubt die angesprochene deklarative Komposition der Komponenten einer Anwendung.

59 4.2 Java Portlets: Spezifikation und Entwicklung 54 Die Klasse MembershipDAOImpl beschreibt verschiedene Dienste, nämlich die Persistenzdienste der Klasse Membership, welche innerhalb des Verlaufs der Time Reporting Anwendung benötigt werden. Die Klasse soll daher dem IoC-Container von Spring vorgestellt werden, um im späteren Verlauf im Zusammenspiel mit anderen Diensten im Kontext der Anwendung genutzt werden zu können. Das Anmelden am Container geschieht unter Verwendung der Konfigurationsdatei. Listing 4.5 zeigt den zugehörigen Ausschnitt aus der XML-Datei, welcher die Deklaration der Klasse MembershipDAOImpl beschreibt. Listing 4.5. Ausschnitt der Konfigurationsdatei applicationcontext.xml der Time Reporting Anwendung <bean i d= membershipdao 5 c l a s s=... t i m e r e p o r t i n g. p e r s i s t e n c e. e n t i t i e s. MembershipDAOImpl > 6 <property name= s e s s i o n F a c t o r y > 7 <r e f l o c a l= s e s s i o n F a c t o r y /> 8 </ property> 9 </ bean> Die dargestellte Deklaration repräsentiert im Container eine Instanz der Klasse MembershipDAOImpl. Wie bereits in Listing 4.4 gezeigt, erbt die Klasse von HibernateDAOSupport, welche das Attribut sessionfactory besitzt. Die Referenz auf ein Objekt der Klasse SessionFactory wird im Verlauf der Anwendung von einem Objekt der Klasse HibernateDAOSupport benötigt, um für die Kommunikation mit persistierten Daten eine HibernateTemplate-Instanz zu erhalten. Die Deklaration einer Instanz in der Konfigurationsdatei erfolgt durch Verwendung des <bean> Elementes, wobei das Attribut id einen eindeutigen Namen der Instanz innerhalb des IoC-Containers beinhalten muss. Die Eigenschaft class verweist auf die zugehörige Klasse des zu erzeugenden Objektes. Neben ihrer Deklaration erlaubt die Konfigurationsdatei auch das Einrichten und Konfigurieren der Instanzen. Das <Property> Element ermöglicht dem Entwickler das Zuweisen von Referenzen oder Werten auf die Eigenschaften einer Instanz. Es bewirkt implizit den Anruf der zugehörigen Setter Methode des betroffenen Objektes durch den Container. Das Attribut name verweist dabei auf die betroffene Property. Wertübergaben erfolgen unter Verwendung des <value> Elementes, welches innerhalb des <Property> Elementes angegeben wird. Für eine Referenzübergabe verwendet Spring das <ref> Element. Hier wird über das Attribut local 16 auf das zugehörige Bean verwiesen. Das referenzierte 16 Neben local kann auch das Attribut bean verwendet werden. Die unterschiedliche Verwendung definiert sich durch die Entfernung der betroffenen Objekte. Befindet sich das referenzierte Objekt inner-

60 4.2 Java Portlets: Spezifikation und Entwicklung 55 Objekt muss dabei ebenfalls durch den IoC-Container verwaltet werden. Die in Listing 4.5 abgebildete Zuweisung entspricht einer Referenzübergabe. Dem Attribut sessionfactory wird hierbei eine Referenz auf ein lokales Bean übergeben, dessen eindeutiger Name innerhalb des Containers ebenfalls sessionfactory ist (Zeile 6-8). Ähnlich wie das Bean sessionfactory kann nun auch membershipdao innerhalb der Konfigurationsdatei verwendet werden und durch entsprechende Referenzen anderen Instanzen innerhalb des Containers bekannt gemacht werden. Auf diese Weise lässt sich unter Verwendung der Konfigurationsdatei ein Objektnetz einrichten, welches zur Laufzeit durch den Container verwaltet wird. Die hier aufgeführte Verwendung des IoC-Containers am Beispiel der Klasse MembershipDAOImpl zeigt nur einen kleinen Teil der durch Spring in diesem Zusammenhang bereitgestellten Funktionalität. Sie dient lediglich zur Veranschaulichung der angewandten Vorgehensweise bei der Erstellung des Time Reporting Portlets. Dem Beispiel der Erstellung des membershipdao Beans folgend wurde jeweils eine Instanz jeder DAO Klasse der übrigen Entitäten in der Konfigurationsdatei deklariert und ihre zugehörige Laufzeitverwaltung in den Verantwortungsbereich des IoC-Containers übergeben. Auch die von Spring bereitgestellten Klassen für das Session- und Transaktionsmanagment im Zusammenspiel mit Hibernate finden ihre Anwendung durch entsprechende Objekte innerhalb des Containers, wie z.b. das bereits angesprochene sessionfactory Bean. Verwendung des Spring Portlet MVC Frameworks Angelehnt an das im Zusammenhang mit Servlets genutzte Web MVC Framework beinhaltet Spring seit seiner Version 2.0 das Portlet MVC Framework. Beide Technologien unterstützen den Entwickler in der Erstellung webbasierter Anwendungen. Der Schwerpunkt ihrer Aufgabe liegt dabei in der Bereitstellung vorgefertigter Softwarekonstrukte, die es dem Entwickler ermöglichen die Kontrolle über den Workflow einer Anwendung möglichst einfach und flexibel zu halten. Sie gehören beide dem in Abbildung 4.9 dargestellten Web Context und Utility Modul an und werden ähnlich wie die aus dem O/R Mapping Modul stammenden Klassen zur Integration von Hibernate unter Verwendung des IoC-Containers benutzt. Das Portlet MVC Framework unterscheidet sich vom Web MVC Framework primär durch die im Gegensatz zu einem Servlet vorhandene Unterteilung eines Portlet Requests in zwei Phasen (siehe Kapitel Abschnitt Anfragebehandlung). Die im Bezug auf das MVC Muster bereitgestellten Controller Klassen halb der gleichen Konfigurationsdatei (einschließlich zugehöriger, inkludierter Dateien), so kann local verwendet werden. Die Verwendung der Eigenschaft bean verlangt lediglich die Existenz innerhalb des IoC-Containers.

61 4.2 Java Portlets: Spezifikation und Entwicklung 56 des Portlet MVC Frameworks, welche für die Bearbeitung eines Requests zuständig sind, implementieren diese Unterscheidung. So besitzt z.b. die im Zusammenhang mit der Time Reporting Anwendung über Vererbung am häufigsten verwendete Klasse AbstractController die beiden Methoden handleactionrequestinternal und handlerenderrequestinternal, wohingegen die aus dem Web MVC Framework stammende, vergleichbare Klasse AbstractController nur die Methode handlerequestinternal besitzt [Por07]. Zentrales Element des Portlet MVC 17 ist die Klasse DispatcherPortlet. Sie fungiert, gemäß der Portlet-Spezifikation, als Schnittstelle zwischen dem Portal bzw. Portlet-Container und einer an das Portal anzubindenden Anwendung. Das Portal delegiert daher jeden Request, der sich auf die Anwendung bezieht an das zugehörige DispatcherPortlet. Um den Anforderungen der Portlet-Spezifikation gerecht zu werden, beinhaltet die Klasse DispatcherPortlet alle in Kapitel aufgeführten Methoden, welche sie über die Basisklasse GenericPortlet erbt [Spr06]. Die Verwendung dieser Klasse ist im Zusammenhang mit der Time Reporting Anwendung das ausschlaggebende Merkmal, welches die Anwendung als ein Portlet kennzeichnet. Die Anwendung des Portlet MVC findet unter Verwendung des von Spring bereitgestellten IoC-Containers statt. Jedem Objekt der Klasse DispatcherPortlet gehört dafür eine Konfigurationsdatei an, welche vom Entwickler verwendet werden kann, um dem Container zugehörige Objekte bekannt zu machen, welche zur Laufzeit durch selbigen verwaltet werden sollen. Eine Controller Klasse wird im Kontext von Spring auch als Handler Klasse bezeichnet. Ihre Aufgabe liegt in der Abarbeitung der durch einen Request gestellten Forderungen. Im Folgenden wird der schematische Ablauf einer Anfrage und dessen Bearbeitung innerhalb des Portlet MVC geschildert, dabei werden die grundlegenden Elemente des Frameworks aufgeführt und erläutert. Erhält ein DispatcherPortlet einen Request, so beginnt zunächst das so genannte Handlermapping. Spring stellt dafür eine Reihe vorgefertigter Klassen bereit, welche mittels der Konfigurationsdatei unter Verwendung des IoC- Containers dem betroffenen DispatcherPortlet zur Verfügung gestellt werden können. Die Aufgabe des Handlermapping besteht in der Zuweisung einer geeigneten HandlerExecutionChain in Abhängigkeit des eingegangenen Requests. Eine HandlerExecutionChain beinhaltet ein oder mehrere Handler, sowie optional eine Reihe von Interceptors. Ein Interceptor kann vor Ausführung eines Handler (prehandle), danach (posthandle) oder nach Abschluss des kompletten Requests (aftercompletion) aufgerufen werden. Seine Aufgabe liegt in der Bearbeitung bestimmter (kleinerer) Aspekte innerhalb der Prozesskette einer Requestverarbeitung, wie z.b. dem automatischen Übertragen der Parameter eines action Requests auf den folgenden zugehörigen render Request. Nach der Zuweisung einer 17 Abkürzung für Portlet MVC Framework

62 4.2 Java Portlets: Spezifikation und Entwicklung 57 geeigneten HandlerExecutionChain übernimmt das DispatcherPortlet deren Ausführung. Das Ergebnis dieser Prozesskette bildet normalerweise die Rückgabe eines ModelAndView Objektes, welches unter Verwendung eines ViewResolvers zur Aktualisierung der Benutzeroberfläche des Portlets führt. Handler, Handlermapping, Interceptors und ViewResolver werden durch den IoC-Container verwaltet. Sie werden daher mittels der Konfigurationsdatei eingerichtet und konfiguriert. Die Time Reporting Anwendung verwendet das Portlet MVC zur Steuerung des Programmablaufs. Im Folgenden soll sie als Beispiel einer möglichen Anwendung des Portlet MVC aufgeführt werden. Für das Handlermapping verwendet die Time Reporting Anwendung zwei vorgefertigte Klassen von Spring: PortletModeParameterHandlerMapping und PortletModeHandlerMapping. Die Klasse PortletModeHandlerMapping ermöglicht ein Mapping des Requests auf einen zugehörigen Handler in Abhängigkeit des bereits in Kapitel aufgeführten Portlet Mode. Diese Zuweisungsart ist stark eingeschränkt, da sich pro Portlet Mode nur ein Handler zuordnen lässt. Andererseits bietet sie auch einen großen Vorteil, da das Zuweisungskriterium, nämlich der Modus eines Portlets, in jedem Request implizit enthalten ist und nicht unbedingt durch den Entwickler bei der Erzeugung eines Requests explizit angegeben werden muss. Die Klasse PortletModeHandlerMapping eignet sich daher besonders für das Mapping des ersten Aufrufs eines Portlets durch den Portlet-Container, welcher die Anwendung auffordert ihr erstes Portletfragment zur Erstellung der Portalseite zu liefern. Listing 4.6 zeigt den zugehörigen Ausschnitt aus der Konfigurationsdatei portletcontext.xml. Die Anwendung der Eigenschaft order wird im Zusammenhang mit der Verwendung weiterer HandlerMapping Klassen benutzt (Zeile 7). Sie legt die Reihenfolge fest, anhand derer das DispatcherPortlet das Handlermapping an zuständige Objekte weiterreicht, solange bis ein geeigneter Handler gefunden ist. Die Eigenschaft portletmodemap beinhaltet die Zuordnungstabelle, mittels derer das Mapping stattfindet (Zeile 9-15). Hier kann über das <entry> Element eine Zuordnungsregel angegeben werden. Dabei verweist die Property key auf den betroffenen Portlet Mode. Das innerhalb von <entry> liegende <ref> Element gibt an, welcher Handler im Falle des betroffenen Portlet Modus für die weitere Bearbeitung des Requests zuständig ist. Im konkreten Fall liegt hier eine Zuweisung an das Bean currentprojectscontroller vor, wenn der Portlet Modus VIEW vorliegt. Das betroffene Bean ist ebenfalls in Listing 4.6 aufgeführt (Zeile 20-25). Die Klasse CurrentProjectsController erbt von AbstractController, einer vorgefertigten Handler Klasse von Spring. Die Klasse CurrentProjectsController implementiert daher die Methode handlerenderrequestinternal, welche als Rückgabewert eine Objekt der Klasse ModelAndView hat. Diese Methode wird im Falle der Zuordnung des Requests an das Bean currentprojectscontroller durch das DispatcherPortlet aufgerufen.

63 4.2 Java Portlets: Spezifikation und Entwicklung 58 Listing 4.6. Ausschnitt der Konfigurationsdatei portletcontext.xml der Time Reporting Anwendung <bean i d= portletmodehandlermapping 5 c l a s s= 6 org. springframework. web. p o r t l e t. handler. PortletModeHandlerMapping > 7 <property name= order value= 20 /> <property name= portletmodemap > 10 <map> 11 <entry key= view > 12 <r e f bean= c u r r e n t P r o j e c t s C o n t r o l l e r /> 13 </ entry> 14 </map> 15 </ property> 16 </ bean> <bean i d= c u r r e n t P r o j e c t s C o n t r o l l e r 21 c l a s s=... t i m e r e p o r t i n g. mvc. c o n t r o l l e r. C u r r e n t P r o j e c t s C o n t r o l l e r > 22 <property name= p e r s i s t e n c e S e r v i c e > 23 <r e f bean= p e r s i s t e n c e S e r v i c e /> 24 </ property> 25 </ bean> Darüber hinaus beinhaltet die Klasse CurrentProjectsController die Eigenschaft persistenceservice. Dem Attribut des gleichnamigen Beans wird mittels der Konfigurationsdatei über das <property> Element das innerhalb des IoC- Containers befindliche Bean persistenceservice zugewiesen. Die Deklaration dieses Beans befindet sich zusammen mit der des in Kapitel beschriebenen Beans membershipdao in der Konfigurationsdatei applicationcontext.xml. Das Bean persistenceservice beinhaltet Referenzen auf je ein Objekt der zugehörigen DAO Klasse einer Entität und ermöglicht daher den Zugriff auf alle persistierten Daten. Neben dem Bean portletmodehandlermapping benutzt die Time Reporting Anwendung eine weitere Handlermapping Klasse. Sie findet ihre Verwendung in dem Bean portletmodeparameterhandlermapping, basierend auf der gleichnamigen Klasse. Die Zuweisung erfolgt hier zusätzlich zum Portlet Modus nach einem weiteren Attribut, welches innerhalb eines Requests als zusätzlicher Parameter explizit angegeben werden muss. Das Bean ist in Listing 4.7 abgebildet. Seine Konfiguration lehnt an der des Bean portletmodehandlermapping an. Der Wert der Eigenschaft order ist niedriger als der des vorangegangenen Handlermapping Beans. Dies bedeutet, dass das DispatcherPortlet zunächst anhand der Mapping- 18 Abschnitt: Verwendung des IoC-Containers am Beispiel der Entität Membership

64 4.2 Java Portlets: Spezifikation und Entwicklung 59 Regeln des portletmodeparameterhandlermapping Bean nach einem geeigneten Handler sucht. Sollte sich in dessen Zuordnungstabelle keiner finden, so wird der Reihenfolge von order folgend im nächst höheren Bean gesucht. Das portletmodeparameterhandlermapping Bean beinhaltet zu dem eine Reihe von Interceptors. Der in Zeile 9 angegebene parametermappinginterceptor übernimmt die Aufgabe des automatischen Übertragens der Parameter eines action Requests in den folgenden zugehörigen render Request und gewährleistet daher eine korrekte Zuordnung des Handler Beans im Hinblick auf die Zuordnung nach bestimmten Parametern eines Requests. Er wird ebenfalls in der Konfigurationsdatei deklariert und somit vom IoC-Container verwaltet (Zeile 30-31). Listing 4.7. Ausschnitt der Konfigurationsdatei portletcontext.xml der Time Reporting Anwendung <bean i d= portletmodeparameterhandlermapping 5 c l a s s=... web. p o r t l e t. handler. PortletModeParameterHandlerMapping > 6 <property name= order value= 10 /> 7 <property name= i n t e r c e p t o r s > 8 < l i s t> 9 <r e f bean= parametermappinginterceptor /> </ l i s t> 12 </ property> 13 <property name= portletmodeparametermap > 14 <map> 15 <entry key= view > 16 <map> 17 <entry key= c u r r e n t p r o j e c t s > 18 <r e f bean= c u r r e n t P r o j e c t s C o n t r o l l e r /> 19 </ entry> </map> 22 </ entry> </map> 25 </ property> 26 </ bean> <bean i d= parametermappinginterceptor 31 c l a s s=... web. p o r t l e t. handler. ParameterMappingInterceptor /> Die Zuordnungstabelle portletmodeparametermap benötigt die Angabe von zwei Zuweisungskriterien nach denen ein Handler ausgewählt werden kann. Zum einen wird dafür der Portlet Modus verwendet. Zum anderen benötigt die zweidimensionale Liste einen weiteren String-Wert als Entscheidungskriterium. Er wird

65 4.2 Java Portlets: Spezifikation und Entwicklung 60 später verwendet, um mit dem in einem Request enthaltenen Parameter, dessen Schlüsselwert action sein muss, verglichen zu werden. Das Ergebnis der Bearbeitung eines Requests durch einen zugewiesenen Handler ist wie bereits erwähnt ein ModelAndView Objekt. Dieses Rückgabeobjekt wird vom DispatcherPortlet für die weitere Verarbeitung eines Requests benötigt. Es beinhaltet einen Verweis auf die an den Portlet-Container zurückzuliefernde View, welche ein Portletfragment enthält, sowie ein Modell vom Typ Map, welches alle Objekte beinhaltet, die im weiteren Verlauf von der zugehörigen View verwendet werden. Das ModelAndView Objekt wird daher vom DispatcherPortlet benutzt, um eine korrekte Zuweisung auf die zu liefernde Ausgabe zu ermöglichen. Hierfür verwendet das DispatcherPortlet einen ViewResolver, welcher über die Konfigurationsdatei angelegt wird. Die Time Reporting Anwendung verwendet als ViewResolver ein Objekt der Klasse InternalResourceViewResolver, wie in Listing 4.8 abgebildet. Listing 4.8. Ausschnitt der Konfigurationsdatei portletcontext.xml der Time Reporting Anwendung <bean i d= viewresolver 5 c l a s s= 6 org. springframework. web. s e r v l e t. view. InternalResourceViewResolver > 7 <property name= viewclass 8 value= org. springframework. web. s e r v l e t. view. JstlView /> 9 <property name= p r e f i x value= /WEB INF/ j s p / /> 10 <property name= s u f f i x value=. j s p /> 11 </ bean> Das Bean viewresolver übernimmt das Mapping auf die zugehörige JSP. Hierfür können über das <Property> Element die Eigenschaften prefix und suffix angegeben werden. Das prefix Attribut verweist über einen Pfad auf das Verzeichnis innerhalb der WAR-Datei, in dem die betroffene JSP-Datei liegt. Das suffix Attribut definiert die Dateiendung. Der folgende Code zeigt die Erstellung eines ModelAndView Objektes innerhalb der Methode handlerenderrequestinternal eines Handlers der Time Reporting Anwendung. Der Konstruktor benötigt drei Attribute. Das erste ist viewname. Es repräsentiert den Dateinamen der gewünschten JSP ohne deren Dateiendung. Die beiden letzteren Attribute sind modelname und modelobject. Sie dienen der Übergabe des zuvor erstellten Modells und geben den Namen an, unter welchem in der JSP auf das Modell zugegriffen werden kann.

66 4.2 Java Portlets: Spezifikation und Entwicklung 61 Listing 4.9. Beispielhafte Erzeugung eines ModelAndView Objektes Map<String, Object> model = new HashMap<String, Object >(); 4 model. put ( example, H e l l o World ) ; ModelAndView modelandview = 7 new ModelAndView ( c u r r e n t p r o j e c t s, model, model ) ; 8... Das DispatcherPortlet reicht den Wert des Attributes viewname an das Bean viewresolver weiter. Dieses bildet daraus den kompletten Pfad der anzuzeigenden View über die Konkatenation von prefix viewname suffix, welche im konkreten Fall den Pfadnamen /WEB-INF/jsp/currentprojects.jsp ergibt. Das Portlet MVC bietet die Möglichkeit den kompletten Verlauf einer Request Bearbeitung abzudecken. Die Einrichtung, Konfiguration und Laufzeitverwaltung der zugehörigen Objekte wird dabei vollständig unter Verwendung des IoC-Containers abgedeckt Die Verwendung der Portlet Tag Library und des Model Objektes innerhalb einer JSP Die Präsentationsebene der Time Reporting Portletanwendung besteht aus einer Reihe von JSP-Dateien. Der Inhalt dieser Dateien unterliegt bestimmten portletspezifischen Restriktionen. So dürfen z.b. die HTML Elemente <base>, <body>, <iframe>, <frame>, <frameset>, <head>, <html> und <title> innerhalb der Ausgabe eines Portlets nicht enthalten sein. Andererseits stehen einem Portletfragment zusätzliche Elemente zur Verfügung, welche die Kommunikation und den Austausch von Daten zwischen der View und dem Portlet selbst ermöglichen. Die Portlet-Spezifikation beinhaltet zu diesem Zweck die Portlet Tag Library, welche von jedem Portal unterstützt werden muss. Sie erlaubt den Zugriff einer JSP auf portletspezifische Elemente, wie den RenderRequest oder RenderResponse. Die Verwendung der Portlet Tag Library verlangt in der betroffenen JSP eine Deklaration über das taglib Element wie folgt: <%@ taglib uri=" prefix="portlet" %> Das Attribut prefix erlaubt die Angabe eines eindeutigen Kürzels, mit welchem jeder Tag der importierten Bibliothek beginnen muss. Im Folgenden werden die vier wichtigsten Elemente aufgeführt, welche dem Entwickler anschließend zur Verfügung stehen [Pan06, Abschnitt Portlet Tag Library]. Über den Tag <portlet:defineobjects> findet die Deklaration der Variablen renderrequest, renderreponse und portletconfig statt, welche dem Entwickler anschließend innerhalb der JSP zur freien Verwendung bereitstehen.

67 4.2 Java Portlets: Spezifikation und Entwicklung 62 Das <portlet:actionurl> Element erzeugt einen URL, welcher auf das zugehörige Portlet der JSP verweist. Es bewirkt außerdem einen action Request, der zum Aufruf der Methode processaction führt. Dieser Tag beinhaltet zwei optionale Attribute. Zum einen kann über windowstate der gewünschte Fenstermodus angegeben werden. Zum anderen ermöglicht die Verwendung des Attributes portletmode das Wechseln des aktuellen Portlet Modus. Innerhalb des <portlet:actionurl> Elementes ist die Anwendung des <portlet:param> Tags erlaubt. Dieser ermöglicht die Übergabe von Parametern. Hierfür wird über das Attribut name der Schlüsselwert des Parameters angegeben, über den der Parameterwert innerhalb des Portlets abgerufen werden kann. Das Attribut value beinhaltet den Parameterwert. Der folgende Code zeigt eine beispielhafte Verwendung des <portlet:actionurl> Elementes. <portlet:actionurl windowstate="normal" portletmode="view"> <portlet:param name="viewname" value="currentprojects"> </portlet:actionurl> Die übergebenen Werte können innerhalb der Methode processaction des zugehörigen Portlets über das ActionRequest Objekt abgefragt werden, wie der folgende Quellcodeausschnitt zeigt. public void processaction( ActionRequest actionrequest, ActionResponse actionresponse) throws PortletException {... String viewname = (String) actionrequest.getparameter("viewname");... actionresponse.setportletmode( actionrequest.getportletmode()); actionresponse.setwindowstate( actionrequest.getwindowstate());... } Ähnlich verhält es sich mit dem <portlet:renderurl> Element. Es stellt die gleichen Attribute bereit wie <portlet:actionurl> und erlaubt ebenfalls die Verwendung des <portlet:param> Elementes. Allerdings führt dieser Tag zu einem render Request, welcher den Aufruf der Methode render zur Folge hat. Unter Anwendung des Portlet MVC von Spring steht dem Entwickler ein weiteres Objekt zur Verfügung, welches implizit innerhalb einer JSP enthalten ist. Das Model Objekt, welches über den Konstruktor der Klasse ModelAndView an das DispatcherPortlet übergeben wird, ermöglicht den Zugriff auf die Objekte der übergebenen Map. Der spätere Variablenname innerhalb der JSP wird dabei explizit an den Konstruktor übergeben. Unter Annahme der in Listing 4.9 angegebenen

68 4.2 Java Portlets: Spezifikation und Entwicklung 63 Deklaration kann auf das Model Objekt unter Verwendung der JSTL wie folgt innerhalb der zugehörigen JSP (in diesem Fall die Datei currentprojects.jsp) zugegriffen werden. <c:out value="${model.example}"/> Ergebnis des dargestellten JSTL Elementes ist die Ausgabe des, der Variable example zugeordneten String-Wertes Hello World Konfiguration des Portlet Deployment Descriptors Für das erfolgreiche Deployment einer Portletanwendung benötigt das zuständige Portal den Deployment Descriptor, welcher sich in Form der Datei portlet.xml innerhalb der WAR-Datei befindet. Ähnlich wie der Servlet Deployment Descriptor, welcher durch die Datei web.xml repräsentiert wird, finden sich in der Datei portlet.xml Informationen wie z.b. Initialisierungsparameter, zulässige Benutzerrollen oder unterstützte Ausgabeformate. Diese Daten werden vom Portal für eine korrekte Einrichtung der Portletanwendung benötigt. Listing 4.10 zeigt verschiedene Auszüge des Deployment Descriptors der Time Reporting Anwendung, deren Bedeutung im Folgenden erklärt wird. Listing Ausschnitt des Deployment Descriptors portlet.xml der Time Reporting Anwendung 1 2 <?xml version= 1. 0?> 3 <p o r t l e t app... > 4 <p o r t l e t> 5 <p o r t l e t name>infeurope Time Reporting System</ p o r t l e t name> 6 <p o r t l e t c l a s s> 7 org. springframework. web. p o r t l e t. D i s p a t c h e r P o r t l e t 8 </ p o r t l e t c l a s s> 9 <i n i t param> 10 <name>c o n textconfiglocation</name> 11 <value>/web INF/ c l a s s e s / p o r t l e t C o n t e x t. xml</ value> 12 </ i n i t param> <supported l o c a l e>en</ supported l o c a l e> 15 <supported l o c a l e>de</ supported l o c a l e> </ p o r t l e t> <user a t t r i b u t e> 20 <d e s c r i p t i o n>vorname</ d e s c r i p t i o n> 21 <name>u s e r. name. given</name> 22 </ user a t t r i b u t e> </ p o r t l e t app>

69 4.2 Java Portlets: Spezifikation und Entwicklung 64 Das Basiselement des Portlet Deployment Descriptors bildet der umschließende <portlet-app> Tag, innerhalb dessen für jedes Portlet einer Portalanwendung entsprechende Angaben über das Element <portlet> hinterlegt werden können. Das <portlet-name> Element ermöglicht die Zuweisung eines eindeutigen Namens innerhalb der Anwendung (Zeile 5). Die Referenz auf die zugehörige Portlet Klasse geschieht über den <portlet-class> Tag. In der Time Reporting Anwendung wird an dieser Stelle auf Grund der Verwendung des Portlet MVC auf die bereits aufgeführte Klasse DispatcherPortlet verwiesen (Zeile 6-8). Attributen der späteren Portletinstanz dieser Klasse können über das <init-param> Element im Deployment Descriptor Werte übergeben werden. So wird z.b. dem Attribut contextconfiglocation der Pfad der zu benutzenden Konfigurationsdatei zugewiesen (Zeile 9-12). Das <supported-locale> Element unterstützt den Internationalisierungsaspekt von Portalen. Über dieses Element erhält das Portal Auskunft darüber, welche Sprachen von einem Portlet unterstützt werden. Die Angaben der Sprachenkürzel folgen dem Standard des Requests for Comments (RFT) 1766 des W3-Konsortiums. Die Time Reporting Anwendung unterstützt daher die beiden Sprachformate de ( deutsch) und en ( englisch) (Zeile 14 und 15). Die Bereitstellung von Benutzerinformationen eines Portals an seine zugehörigen Portlets ist in der Portlet-Spezifikation festgelegt. Die genaue Angabe der benötigten Attribute eines Benutzers erfolgt im Deployment Descriptor. Die Anzahl der abrufbaren Eigenschaften ist portalspezifisch. Für die Angabe wird das <user-attribute> Element verwendet, wobei die Attributsnamen dem Standard der Platform for Privacy Preferences Specification (P3P) entsprechen, welche ebenfalls durch das W3-Konsortium definiert wurde. Listing 4.10 beinhaltet die Verwendung des <user-attribute> Elementes (Zeile 19-22). Das Portal wird dadurch aufgefordert den Vornamen des aktuellen Benutzers der Portletanwendung bereitzustellen.

70 4.3 Anwendung des Unified Process Anwendung des Unified Process Iterative und evolutionäre Vorgehensweisen in der Softwareentwicklung streben im Gegensatz zum klassischen Wasserfall -Entwicklungsprozess eine Aufteilung des Prozesses in einzelne kurze Entwicklungszyklen an. Sie fördern einen möglichst frühen Beginn der Implementierungs- und Testphase, z.b. über das so genannte Prototyping, mit dem Ziel frühzeitige Feedbackschleifen durchlaufen zu können, welche Aussagen hinsichtlich der Eignung des aktuellen Lösungsansatzes ermöglichen. Auf diese Weise sollen mögliche Fehlentwicklungen frühzeitig erkann und die dadurch entstehenden Kosten minimiert werden. Dieser Kontrollmechanismus erhöht daher die Planungssicherheit eines Projektes hinsichtlich Zeit und Kosten. Entgegen dem sequentiellen, statischen Ablauf der einzelnen Entwicklungsphasen im Wasserfall -Prozess, basieren iterative Vorgehensmodelle auf der parallelen Durchführung der einzelnen Phasen, d.h. die Implementierungsphase beginnt bereits vor Abschluss der vollständigen Anforderungserstellung so wie die Testphase vor Abschluss der Implementierung anfängt. In Abhängigkeit vom Projektstadium beinhaltet jeder Entwicklungsabschnitt eine unterschiedliche Verteilung der betriebenen Arbeitsaufwände in den einzelnen Entwicklungsdisziplinen. Der Unified Process (UP) gehört zu den bekanntesten Beispielen für iterative Vorgehensweisen. Sein Entwicklungsverlauf gliedert sich in kurze, durch feste Zeitfenster beschränkte Einheiten, welche als eigenes Mini-Projekt betrachtet werden können. Diese Einheiten werden als Iterationen bezeichnet. Jede Iteration beinhaltet, in ihrer Rolle als selbstständiges Projekt, alle Entwicklungsphasen eines klassischen Projektes. Die Eigenschaft iterativ bezieht sich daher auf die kontinuierliche Weiterentwicklung des Projektes durch das sequentielle Durchlaufen von einzelnen Iterationen. Diese Vorgehensweise wird deshalb auch als inkrementeller Entwicklungsprozess bezeichnet. Da die ständig zu durchlaufenden Feedbackschleifen eine regelmäßige Anpassung und Korrektur der Anforderungen, Spezifikationen und des Designs zur Folge haben, spricht man im Zusammenhang mit iterativen Prozessenverläufen auch von evolutionären Vorgehensmodellen [Lar05, Kapitel 2.2]. Das Ergebnis jeder Iteration innerhalb des UP kann als Untermenge des finalen Systems betrachtet werden. Mit fortschreitender Iteration nähert sich diese Untermenge dem Endprodukt. Dabei werden im gleichen Maße Teilmengen der Anforderungen erfüllt. Der größte Vorteil dieser Vorgehensweise ist die frühzeitige Verifizierung der durch die Entwicklergruppe verstandenen Anforderungen. Diese Überprüfung findet durch regelmäßige Rücksprache mit dem Endbenutzer statt. Dieser hat somit die Möglichkeit, in den weiteren Verlauf des Entwicklungsprozesses einzugreifen und das zu entwickelnde System nach seinen Wünschen zu beeinflussen. Die Spezifikation der Anforderungen ist eine der Schwachstellen des Wasserfall -Modells, da sie oftmals spekulative Anforderungen auf Grund mangelnder Kenntnisse über das zu lösende Problem fördert.

71 4.3 Anwendung des Unified Process 66 Die Einhaltung fester Zeitfenster für jede Iteration ist ein wichtiges Kriterium des UP. Einer Nichteinhaltung sollte daher durch Reduzierung der zugehörigen Anforderungen der betroffenen Iteration entgegengewirkt werden Zugehörige Entwicklungsphasen Die Unterteilung des UP in verschiedene zeitliche Abschnitte hängt im Gegensatz zum Wasserfall -Entwicklungsgprozess nicht mit der Durchführung bestimmter Tätigkeiten zusammen. Der UP ist in die vier folgenden Phasen gegliedert. Jede Phase setzt sich aus ein oder mehreren Iterationen zusammen. Inception: Diese Phase dient einer Überprüfung des (bis zu diesem Zeitpunkt potentiellen) Projektes hinsichtlich seiner Durchführbarkeit. Die Inception- Phase verschafft daher einen groben Projektüberblick und dient der Entwicklergruppe gleichzeitig dazu, einen ersten Eindruck über die Problemdomäne und die grundlegende Problematik, welche als Auslöser des Projektes gesehen werden kann, zu erhalten. Ergebnis dieser Phase im Falle einer positiven Machbarkeitsbewertung sind erste, grobe Abschätzungen hinsichtlich Zeit, Kosten und Aufwand, sowie die Festlegung grobgranularer Projektziele. Elaboration: In der Elaboration-Phase wird die grundlegende Architektur festgelegt. Dies geschieht durch die iterative Implementierung von einzelnen Use Cases (UC). Dabei werden die wesentlichen Anforderungen des Projektes identifiziert und festgelegt. Auf diese Weise kann eine weitere, genauere Abschätzung des Projektes vorgenommen werden. Die detaillierte und formale Beschreibung aller Anforderungen findet an dieser Stelle nicht statt, d.h. die Elaboration- Phase entspricht nicht der Requirements-Phase des Wasserfall -Modells. Vielmehr findet in dieser Phase bereits eine erste Implementierung der festgelegten Architektur sowie die Durchführung zugehöriger Tests statt. Construction: Während der Construction-Phase findet die weitere Implementierung der Anforderungen statt. Im Gegensatz zur Elaboration-Phase liegt der Schwerpunkt hier auf der Implementierung des zu erstellenden Systems. Dabei wird auch mit der Realisierung von Feinheiten begonnen. Ergebnis jeder der in dieser Phase befindlichen Iterationen ist ein bereits nutzbares System, welches sich mit jeder weiteren Iteration dem Endprodukt annähert. Transition: Die Transition-Phase dient der Fertigstellung des Produktes. Hier werden letzte Feinheiten implementiert. Der Schwerpunkt liegt auf der Vorbereitung zur Einrichtung des Systems in die Produktionsumgebung sowie auf der Durchführung von Tests.

72 4.3 Anwendung des Unified Process Zugehörige Entwicklungsdisziplinen Jede Tätigkeit innerhalb eines UP wird einer bestimmten Disziplin zugeordnet. Das Ergebnis einer Tätigkeit wird als Artefakt (engl.: artifact) bezeichnet. Eine Iteration beinhaltet in den meisten Fällen alle Disziplinen, wobei deren Gewichtung in Abhängigkeit vom Projektstand unterschiedlich ausfällt. In frühen Iterationen finden vor allem die Disziplinen Spezifikation der Anforderungen, Analyse und Architekturmodellierung ihre Anwendung, wohingegen spätere Iterationen durch Implementierung und die Durchführung von Tests dominiert werden. Abbildung 4.10 zeigt den klassischen Einsatz der einzelnen Disziplinen in den unterschiedlichen Phasen und Iterationen. Abbildung UP Disziplinen Das dargestellte Szenario demonstriert eine mögliche Verteilung. Es repräsentiert keine Vorschrift. Im Gegenteil, der UP beinhaltet nur wenige Vorgaben und Regeln, welche ihn kennzeichnen. Dazu gehören ein iterativer Entwicklungsprozess, sowie eine kontinuierliche Annäherung der einzelnen Iterationsergebnisse an das gewünschte finale Produkt. Jede Ausführung einer bestimmten Tätigkeit (mit Ausnahme des Programmierens), sowie deren zugehörige Artefakte sind optional und daher nicht zwingend notwendig. Das Aufstellen eines geeigneten Prozesses ist Aufgabe der jeweiligen Entwicklergruppe bzw. des zuständigen Projektmanagers. Auch der Grad an Formalität der einzelnen Artefakte unterliegt der Entscheidung der Entwicklergruppe und sollte an die Bedürfnisse des Projektes angepasst sein.

73 4.3 Anwendung des Unified Process UP vs. RUP Der UP kann als eine standardisierte Vorgehensweise betrachtet werden, obgleich er keiner formalen Spezifikation unterliegt. Seiner Entwicklung liegt [Jac99] zu Grunde. Einer der Hauptentwickler dieses Entwicklungsprozesses ist heute Philippe Kruchten, Professor an der University of British Columbia und gleichzeitig Director of Process Development des Unternehmens Rational, dessen Produktfamilie u.a. den Rational Unified Process (RUP) beinhaltet. Der RUP kann als eine konkrete Instanz des UP angesehen werden. Seine Weiterentwicklung unterliegt der Firma Rational, welche für die Anwendung des Entwicklungsmodells eine Reihe von unterstützenden Tools bereitstellt. In diesem Zusammenhang wird der RUP auch als Framework bezeichnet. Den Kern der zur Verfügung gestellten Software bildet der Rational Method Composer. Er beinhaltet die formale Beschreibung vorgefertigter Anwendungsmodelle des RUP, und erlaubt deren individuelle Anpassung zur Definition eigener Prozessabläufe. Dabei beruhen die mitgelieferten Prozessbibliotheken auf best practices und können als Grundgerüst für verschiedene Projektarten benutzt werden Anwendung des UP am Beispiel der Entwicklung des Alfresco Explorer Portlets Die Aufgabenstellung (siehe Kapitel 3) beinhaltet die Einrichtung des Dokument- Management-Systems von Alfresco, sowie dessen Anbindung an das Portal in Form eines Portlets. Hierfür wurde das Alfresco Explorer Portlet entwickelt, welches Benutzern des Portals einen lesenden Zugriff auf die Verzeichnisstruktur des DMS ermöglicht. Die Entwicklung unterliegt der Anwendung des UP. Im Folgenden sollen die einzelnen Phasen beschrieben werden, welche angelehnt an das UP-Modell durchlaufen wurden. Sowohl die Projektdauer von drei Wochen als auch die Größe des Entwicklerteams, welches aus einer einzigen Person bestand, weisen daraufhin, dass es sich aus Sicht des UP um ein kleines Projekt handelt. Der angewandte Entwicklungsprozess beinhaltet daher einen niedrigen Grad an Formalität, d.h. die Artefakte der einzelnen Tätigkeiten, wie z.b. die Erstellung von UC-Modellen, Domain Modellen oder Unified Modeling Language (UML)-Diagrammen, unterliegen keinen strengen formalen Anforderungen. Diese Anpassung des Prozesses beruht auf der Tatsache, dass innerhalb des UP alle zusätzlichen Artefakte (ausgenommen des herzustellenden Produktes) dem primären Zweck dienen innerhalb des Entwicklerteams klare Absprachen und das gemeinschaftliche Verständnis formal und strukturiert festzuhalten, um mögliche Missverständnisse z.b. hinsichtlich Zielsetzung oder Aufgabenverteilung zu vermeiden. Der UP kann daher in Abhängigkeit

74 4.3 Anwendung des Unified Process 69 der Projektumstände sowohl streng formal als auch informal gehalten werden, stets mit dem Ziel aus Sicht der Entwicklergruppe unnötige bzw. überschüssige Tätigkeiten zu vermeiden. Zum allgemeinen Verständnis sollen die grundlegenden Ziele des Projektes vor der Erläuterung der durchlaufenen Entwicklungsphasen kurz beschrieben werden. Das Projekt umfasst die Installation des Dokument-Management-Systems, sowie dessen Konfiguration und die Einrichtung von Benutzerprofilen, welche das Erstellen, Ändern und Löschen von Verzeichnissen und Dateien zu Testzwecken erlauben. Das DMS stellt eine eigene Weboberfläche zur Verfügung. Sie bietet das Arbeiten auf der bereitgestellten Verzeichnisstruktur an. Darüber hinaus soll der Zugriff auch über die Anwendung Windows Explorer von Windows ermöglicht werden. Hierfür wird das Common Internet File System (CIFS)-Protokoll verwendet, welches den Zugriff auf entfernte Dateisysteme erlaubt. Sowohl der Zugriff über die bereitgestellte Weboberfläche als auch der Zugang über den Windows Explorer sollen für jeden Mitarbeiter innerhalb des internen Netzwerks zur Verfügung stehen. Beiden Zugriffsarten soll das Lesen und Schreiben auf dem DMS gestattet sein. Darüber hinaus soll eine weitere Zugangsmöglichkeit geschaffen werden, die es erlaubt von außen, also durch Mitarbeiter, welche sich im Außendienst befinden, erreichbar zu sein und einen Zugriff auf das Dateisystem bereitstellt. Hierfür bietet sich die Verwendung des Portals an, da es eine gesicherte Schnittstelle nach außen bereitstellt und für jeden Mitarbeiter über einen herkömmlichen Browser erreichbar ist und somit keine spezielle Software benötigt. Dieser Zugang soll bestimmten Restriktionen unterliegen, welche u.a. nur das Herunterladen von Dateien erlauben, das Hochladen jedoch verbieten. Zu diesem Zweck soll ein Portlet entwickelt werden, welches dem Portalbenutzer die Funktionalität bereitstellt auf die Verzeichnisstruktur zuzugreifen, um zugehörigen Dateien abrufen zu können. Inception-Phase Die Dauer der Inception-Phase dieses Projektes betrug zwei Tage. Innerhalb dieser Phase wurde das zu verwendende Installationspaket Alfresco Community (Version 1.4) hinsichtlich der bereitgestellten Zugriffsmöglichkeiten untersucht. Darüber hinaus wurden die wesentlichen Projektziele festgelegt, wie z.b. der bereits aufgeführte Zugriff auf das DMS über drei verschiedene Zugangsarten. Die folgenden Leitfragen lagen der Durchführung der Inception-Phase zur Grunde. Mit ihrer Beantwortung galt diese Phase gleichzeitig als beendet. Welche Funktionalität soll durch das Dokument-Management-System abgedeckt werden? Auf welche Weise kann das System in die vorhandene IT-Infrastruktur eingegliedert werden? Sind die gestellten Anforderungen erfüllbar? Soll mit dem Projekt fortgefahren werden oder wird an dieser Stelle abgebrochen?

75 4.3 Anwendung des Unified Process 70 Die beiden letzten Fragen sind aus Sicht des UP unabdingbar für die Inception- Phase, deren primäres Ziel die Überführung eines potentiellen Projektes in ein durchführbares Projekt ist. Eine definitive Zusage gegenüber einem Auftraggeber hinsichtlich der Durchführbarkeit sollte daher stets erst nach Abschluss dieser Phase getätigt werden. Der Auftraggeber bzw. Endnutzer sollte außerdem an der Erarbeitung der zugehörigen Ergebnisse in möglichst hohem Maße beteiligt sein. Dies erleichtert das spätere Verständnis seinerseits über eventuelle, unerfüllbare Anforderungen und schafft eine solide Basis für eine mögliche Neuausrichtung des Projektes. Für die Beantwortung der beiden ersten Fragen wurden so genannte Requirement Workshops durchgeführt. Dies geschah über verschiedene Gespräche mit Mitarbeitern. Hierbei eignet sich besonders gut die Erstellung von UC-Modellen als mögliches Artefakt dieser Tätigkeit. Sie definieren die Art und Weise, wie der Benutzer mit dem zukünftigen System arbeitet, und bieten die Möglichkeit gemeinsame Absprachen bzw. das gemeinsame Verständnis über ausgearbeitete Anforderungen festzuhalten. Entgegen der Requirement-Phase des Wasserfall - Entwicklungsprozesses handelt es sich bei den hier aufgestellten UC-Modellen nur um grobe Beschreibungen, welche einer weiteren Verfeinerung unterzogen werden müssen. Außerdem beinhaltet die Inception-Phase lediglich die Auflistung der wichtigsten UCs. Neben der Durchführung der beschriebenen Requirement Workshops wurde zusätzlich die Funktionalität des anzubindenden DMS geprüft und bewertet, um mögliche Konzepte der Realisierung zu skizzieren und diese zu diskutieren. Elaboration-Phase In der Elaboration-Phase wurde u.a. mit der Implementierung des Alfresco Explorer Portlets begonnen. Die Dauer dieser Phase betrug sechs Tage, wobei eine Unterteilung in vier Iterationen stattfand. In der ersten Iterationen wurde das Dokument-Management-System installiert und verschiedene Konfigurationen sowie die Erstellung von Benutzerprofilen zu Testzwecken über die Weboberfläche durchgeführt. Die somit bereits fertig gestellte erste Zugangsmöglichkeit wurde mit verschiedenen Mitarbeitern getestet und diskutiert. In der zweiten Iteration wurde die Anbindung des DMS über den Windows Explorer unter Verwendung des CIFS-Protokolls eingerichtet, konfiguriert und getestet. Nach Fertigstellung der beiden ersten Zugangsarten konnte mit der Entwicklung des Portlets begonnen werden. Ziel der dritten Iteration war daher die Erstellung eines ersten Prototyps, welcher die Kommunikation mit dem DMS unter Anwendung der bereitgestellten Web Services veranschaulichen sollte. Gleichzeitig sollten auf diese Weise Erfahrungen im Umgang mit dem Dateisystem gesammelt werden, um mögliche Probleme zu erkennen und eventuelle Änderungen an der geplanten

76 4.3 Anwendung des Unified Process 71 Art der Implementierung vorzunehmen. In dieser Iteration wurde parallel mit der Verfeinerung der zugehörigen UP-Modelle begonnen. Die vierte Iteration baute auf dem im Vorherigen erstellten Prototyp auf. Die Aufgabenstellung bestand aus der Erweiterung des Prototyps mit dem Ziel, die Verzeichnisstruktur bereits graphisch darstellen zu können und dem Benutzer das Wechseln in andere Verzeichnisse zu ermöglichen. Auf diese Weise konnten frühzeitige Feedbackschleifen mit den Endbenutzern, nämlich den Mitarbeitern, eingeleitet werden, die es ermöglichen sollten, die verstandenen Anforderungen zu verifizieren und gegebenenfalls zu ändern. Mit Abschluss dieser Iteration war die grundlegende Architektur des Portlets fertig gestellt und ein erstes, wenngleich auch nur zu Veranschaulichungszwecken nutzbares System erstellt. Dieser Zustand kann als Kriterium zum Abschluss der Elaboration-Phase angesehen werden. Construction-Phase Die Construction-Phase wurde zur Verfeinerung und Erweiterung des bereits erstellten Portlets verwendet. Dafür wurde, trotz der kurzen Dauer von vier Tagen, die Anzahl der Iterationen erhöht, um im ständigen Austausch mit den Mitarbeitern die Ergebnisse durchgeführter Erweiterungen zu besprechen und ihre Korrektheit zu prüfen. Zuvor wurde anhand der skizzierten UP-Modelle die weitere Entwicklung in einzelne Teilaufgaben unterteilt, welche anschließend iterativ abgearbeitet wurden. Das Ergebnis jeder Iteration war somit ein nutzbares System, welches auf dem Endprodukt der vorherigen Iteration aufbaute und es um eine bestimmte Funktionalität erweiterte. Der Schwerpunkt der Construction-Phase lag daher auf der Implementierung sowie auf der Durchführung von Tests. Auf Grund der fortgeschrittenen Entwicklung, der ständigen Kontrolle durch Feedbackschleifen und der stetigen Abnahme schwerwiegender Änderungen bzw. Erweiterungen fanden die erstellten UP- Modelle ab diesem Zeitpunkt keine Verwendung mehr. In den Tätigkeitsbereichen Anforderungserstellung, Analyse und Architekturmodellierung wurden daher keine weiteren Arbeiten durchgeführt. Transition-Phase Mit Abschluss der Implementierung des Alfresco Explorer Portlets begann die Transition-Phase. Ihrer Dauer betrug einen Tag bestehend aus einer Iteration. Während dieser Phase fand die Überführung des Portlets aus der Testumgebung in die Produktionsumgebung statt. Damit wurde die dritte Zugriffsmöglichkeit auf das DMS fertig gestellt und ihre Anwendung für alle Mitarbeiter bereitgestellt. Graphische Darstellung des angewandten UP Der im Vorangegangenen beschriebene Entwicklungsprozess lässt sich wie in Abbildung 4.11 aufgeführt darstellen. Die Abbildung veranschaulicht das Verhältnis

77 4.3 Anwendung des Unified Process 72 der Anwendung einzelner Disziplinen innerhalb des Entwicklungsverlaufs, wobei nicht verwendete Disziplinen nicht aufgeführt sind. Die Entwicklungsdauer betrug insgesamt 13 Arbeitstage, unterteilt in 11 Iterationen. Abbildung Angepasster UP zur Entwicklung des Alfresco Explorer Portlets