Studienarbeit - swa.informatik.uni-hamburg.de · Diese Arbeit befasst sich mit dem Framework - JavaServer Faces. Hauptziel ist es, den Einsatz von JavaServer Faces für die Weiterentwicklung

Universität Hamburg

Fachbereich Informatik

Studienarbeit

im Arbeitsbereich Softwaretechnik

Thema: Entwicklung eines browserbasierten Client Front-Endfür das Equipment Management System, mitUnterstützung des Frameworks - JaverServer Faces

eingereicht von: Randolph Tendzegolskis ‹[email protected]›

eingereicht am: 27. März 2007

Betreuer: Herr Dr. Guido Gryczan

Inhaltsverzeichnis

Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vAbkürzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiAbbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

1 Einleitung 11.1 Ausgangslage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Einführung und Grundbegriffe 42.1 J2EE - Java2 Plattform Enterprise Edition . . . . . . . . . . . . . . . . . . . . . 42.2 Java Server Pages und Servlets . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Architekturen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1 Das MVC-Paradigma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.2 JSP-basierte Model 1-Architektur . . . . . . . . . . . . . . . . . . . . . . 142.3.3 JSP-basierte Model 2 Architektur . . . . . . . . . . . . . . . . . . . . . . 152.3.4 Die Umsetzung des MVC-Paradigma im Framework - JavaServer Faces 16

2.4 Laufzeitumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.1 Jakarta Tomcat Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.2 Der JBoss Applikationsserver . . . . . . . . . . . . . . . . . . . . . . . . 182.4.3 IBM WebSphere Applikationsserver (WAS) . . . . . . . . . . . . . . . . 192.4.4 Andere Applikationsserver . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Das Framework - JavaServer Faces 203.1 Konfigurationsdateien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.1 Der deployment Deskriptor (web.xml) . . . . . . . . . . . . . . . . . . 213.1.2 Die Anwendungskonfigurationsdatei (faces-config.xml) . . . . . . . . 23

3.2 Der Lebenszyklus der Anfrageverarbeitung . . . . . . . . . . . . . . . . . . . . 253.3 Das UI-Komponenten-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4 Das Rendering-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.5 Die JSF-Tag-Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.6 Managed Beans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.7 Konvertierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.8 Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.9 Eventhandling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

iii

INHALTSVERZEICHNIS

3.10 Das Navigations-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.11 Lokalisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4 Das Equipment Management System 434.1 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2 EMS - Szenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.2.1 Die zentralen Aufgaben des Equipment Management System . . . . . 444.2.2 Editiere-Geräte (Editing a device) . . . . . . . . . . . . . . . . . . . . . 464.2.3 Editiere-Raumpläne (Editing room maps) . . . . . . . . . . . . . . . . 464.2.4 Editiere-Mitarbeiter (Editing an employee) . . . . . . . . . . . . . . . . 464.2.5 Weitere Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3 Die Architektur des EMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.4 Das Employee-Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.4.1 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.4.2 Umsetzung und Realisierung . . . . . . . . . . . . . . . . . . . . . . . . 51

5 Zusammenfassung, Bewertung und Ausblick 56

A Anhang 58

B Literaturverzeichnis 59

C Ehrenwörtliche Erklärung 63

iv

Vorwort

An dieser Stelle möchte ich all jenen danken, die durch ihre fachliche und persönlicheUnterstützung zum Gelingen dieser Studienarbeit beigetragen haben.

Bedanken möchte ich mich auch bei dem EMS-Team. In zahlreichen Gesprächen undDiskussionen konnten viele Probleme gelöst und Fragen geklärt werden.

Meiner Freundin danke ich ganz besonders für ihr Verständnis und ihre Geduld, gera-de im letzten Abschnitt meiner Studienarbeit.

Besonderer Dank gebührt meinen Eltern, die durch ihre Unterstützung und Korrektur-lesen mir diese Studienarbeit ermöglicht haben.

Des weiteren bedanke ich mich bei Herrn Dr. Guido Gryczan für die Betreuung mei-ner Studienarbeit und den zahlreichen wissenschaftlichen Ratschläge, welche stets zurVerbesserung der Arbeit beigetragen haben.

v

Abkürzungsverzeichnis

API Application Programming InterfaceCGI Common Gateway InterfaceDNS Domain Name SystemEAI Enterprise Application IntegrationEIS Enterprise Information SystemEJB Enterprise Java BeanEMS Equipment Management SystemGUI Graphical User InterfaceHTTP Hypertext Transfer ProtocolJ2EE Java 2 Enterprise EditionJAAS Java Authentication and Authorization ServiceJCA J2EE Connector ArchitekturJDBC Java Database ConnectivityJMS Java Message ServiceJMX Java Management ExtensionsJNDI Java Naming and Directory InterfaceJSF JavaServer FacesJSP Java Server PagesJSR Java Spezification RequestJTA Java Transaction APILDAP Lightweight Directory Access ProtocolMVC Model-View-ControllerNIS Network Information ServicePDA Personal Digital AssistantRI ReferenzimlementierungRMI Remote Method InvocationSVG Scalable Vector GraphicsTCK Technology Compatibility ToolkitUI User interfaceURI Uniform Resource IdentifiernURL Uniform Resource LocatorWAR Java Archiv für Web-ApplikationenWML Website META LanguageXHTML Extensible Hypertext Markup Language

vi

INHALTSVERZEICHNIS

XML Extensible Markup Language

vii

Abbildungsverzeichnis

2.1 Drei-Schichten-Architektur (grob) . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Drei-Schichten-Architektur (fein) . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Model-View-Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Die Model 1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5 Die Model 2 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Der Lebenszyklus der Anfrageverarbeitung . . . . . . . . . . . . . . . . . . . . 263.2 Die UI-Komponenten der Referenzimplementierung . . . . . . . . . . . . . . 29

4.1 Die Benutzeroberfläche des EMS . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2 Basis-Struktur der Benutzer-Interface-Komponenten des EMS . . . . . . . . 474.3 Die „works on“ relationship von Tools und Materialen . . . . . . . . . . . . . 484.4 Der Anmelde-Mechanismus der Workbench (EMS) . . . . . . . . . . . . . . . 504.5 Der Employee (RT) ist bereit zur Bearbeitung. . . . . . . . . . . . . . . . . . . 524.6 Die emsEdit.jsp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

viii

1 Einleitung

Diese Studienarbeit ist im Rahmen des Projektes „Objektorientierte Softwareentwick-lung“ am Fachbereich Softwaretechnik der Universität Hamburg entstanden. Lernzieledieses 2 Semester dauernden Projektes waren neben der Einarbeitung in fundamentaleMethoden und Techniken der objektorientierten Konstruktion, auch die Einarbeitung,Erweiterung und das Refactoring einer schon bestehenden Anwendung wie das „Equip-ment Management System“.1

Das „Equipment Management System (EMS)“ ist ein Tool zur Organisation von Ge-räten, Mitarbeitern und Raummappen. Es dient als ein größeres Beispiel zur Erklärungder Konzepte des Handbuches „Object-Oriented Software Construction Handbook - De-veloping Application-Oriented Software with the Tools & Materials Approach“ von Prof.Dr.-Ing. Heinz Züllighoven et al.2

Entwickelt worden ist das „Equipment Management System (EMS)“ von der C1 WPSGmbH3 in Zusammenarbeit mit der Uni-Hamburg. In diesem Projekt wurde gezielt aufdie Zusammenarbeit zwischen Studenten und erfahrenen Entwicklern geachtet.

Diese Arbeit befasst sich mit dem Framework - JavaServer Faces. Hauptziel ist es, denEinsatz von JavaServer Faces für die Weiterentwicklung des „Equipment ManagementSystem“ zu prüfen. Es soll untersucht werden, inwieweit sich das Framework eignet,einen browserbasierten Client Front-End für das „Equipment Management System“ zuentwickeln. Hierbei wird es besonders auf die Integration des Frameworks - JavaServerFaces ankommen und seine Eignung, eine Trennung zwischen Geschäfts- und Präsenta-tionslogik zu finden.

1.1 Ausgangslage

Java hat sich in den letzten Jahren als eine führende Technologie für die Entwicklung vonWeb-Applikationen etabliert. Aber die immer komplexer werdenden Webanwendungenmachen es notwendig, im Sinne der Wartbarkeit, Wiederverwendbarkeit, Erweiterbar-keit, Konfigurierbarkeit und einfacher Entwicklungen sich grundsätzlich Gedanken überdie Struktur von Webanwendungen zu machen.

1(vgl. wps07b)2(vgl. Zül05)3C1 WPS Workplace Solutions Gesellschaft für DV-Beratung mbH

1

1.2. ZIEL

Die Wiederverwendung von Software wird dabei als ein erstrebenswertes Ziel und er-folgversprechendes Instrument bei der Entwicklung von Software angesehen. Genau die-sen Aspekt verfolgen die Frameworks. Ein Framework soll das Erstellen grösserer Web-Applikationen unter Einsatz von J2EE - Technologien vereinfachen.

Während die Entwurfsmuster sich auf eine reine Umsetzungsempfehlung beschrän-ken, gehen Frameworks noch einen Schritt weiter. Frameworks verfolgen in ihrem Grund-gedanken, neben der „einfachen“ Wiederverwendung von Code, noch vielmehr. Ihre Wie-derverwendung zielt auf ganze Designideen und sogar komplette Services ab.

Frameworks bestehen demnach „aus einer Menge von zusammenarbeitenden Klassen,die einen wiederverwendbaren Entwurf für eine bestimmte Klasse von Software darstel-len“.4 Frameworks stellen somit branchenspezifische oder -übergreifende Lösungen fürallgemein bekannte Probleme dar. Eine Reihe bekannter Frameworks sind Struts, Veloci-ty, Cocoon und JaverServer Faces.

Bereits im Mai 2001 wurde das Framework - JavaServer Faces (JSF) von Sun als JavaSpezification Request (JSR)127 dem Java Community Process hinzugefügt. Und schon imDezember 2003 konnte dann bereits die Referenzimplementierung von Sun herunterge-laden werden. Das im März 2004 erschienene Final Release umfasst Spezifikation, Refe-renzimplementierung und das Technology Compatibility Toolkit (TCK). Inzwischen liegtseit 11. Mai 2006 die momentan aktuellste Version der J2EE-Spezifikation vor, die Version5.0 (Java EE 5).5 Neben Sun waren auch noch an der Entwicklung der JSF Spezifikationbeteiligt die Apache Software Foundation, BEA Systems, Borland, Software Corporation,IBM, Oracle und Macromedia.

Im Hinblick auf die Entwicklung eines browserbasierten Client Front-End, wird unsdas WEB-Framework - JaverServer Faces eine Architektur liefern für Entwicklung vonClient-Server Anwendungen. Die Client-seitigen Zugriffe erfolgen dabei durch einen Web-browser.

Die ursprüngliche Architektur des EMS hatte eine Client-Server Struktur, welche diekomplette Geschäfts- und Präsentationslogik im Client vereinte. Diese Architektur galt esnun so zu überarbeiten und erweitern, das die neue Architektur des EMS eine im Sinne„Suns J2EE Spezifikation“ thin-client Architektur aufweist.

1.2 Ziel

Web-Browser sind auf dem Weg das universelle Front-End für viele WEB-Anwendungenzu werden. Motivation dieser Studienarbeit ist es zu untersuchen, inwieweit sich das Fra-mework - JaverServer Faces für die Entwicklung eines browserbasierten Client Front-End

4(vgl. Gam01)5(vgl. Mic07c)

2

KAPITEL 1. EINLEITUNG

eignet, für eine schon bestehende Anwendung wie das „Equipment Management Sys-tem“. Dabei dient das Framework - JaverServer Faces als Grundgerüst einer Model-View-Controller (MVC)-Architektur, im Sinne „Suns J2EE Spezifikation“.

Der sehr praxisnahe Bezug gibt mir die Chance, das Framework - JaverServer Facesdirekt im Einsatz zu testen. Die Integration des Frameworks - JaverServer Faces in dasbestehende „Equipment Management System“ gilt es zu meistern. Diese Arbeit wird an-hand des Beispiels Employee-Tool zeigen, wie eine mögliche Umsetzung und Realisie-rung aussieht.

1.3 Übersicht

In dieser Arbeit werden in Kapitel 2 zunächst grundlegende Begriffe erläutert, um einVerständnis für die Struktur und das Verhalten von Frameworks und deren Komponen-ten, zu erhalten. Dabei wird insbesondere auf die verschiedenen Architektur-Modellevon Suns „J2EE Spezifikation“ eingegangen, sowie die Einbettung der JSF-Applikationin einem Java Servlet Container, der die Laufzeitumgebung liefert.

In Kapitel 3 wird das Framework - JaverServer Faces selbst vorgestellt. Nach einer kur-zen Einführung werden alle relevanten Komponenten des Frameworks behandelt. Dazuzählen Themen wie die Konfigurationsdateien, der Lebenszyklus der Anfrageverarbei-tung, das UI-Komponenten-Modell, das Rendering-Modell, die Validierung, das Event-handling, das Navigations-Modell, die JSF-Tag-Bibliotheken, die Managed Beans und dieLokalisierung.

Das Kapitel 4 behandelt die Integration des Framework - JaverServer Faces in das„Equipment Management System“. Eine kurze Einführung in das „Equipment Manage-ment System“ soll das Verhalten mittels Szenarios beschreiben. Im Folgeabschnitt wirddann der Grundaufbau der Architektur veranschaulicht. Zuletzt soll dann herausgestelltwerden, wie die Umsetzung und Realisierung des Employee-Tool aussieht.

In Kapitel 5 wird diese Arbeit zusammengefasst und die gewonnenen Erfahrungen kri-tisch beurteilt. Im Ausblick werden die aufgetauchten Fragen, Grenzen und Wünsche zu-sammengefasst.

3

2 Einführung und Grundbegriffe

2.1 J2EE - Java2 Plattform Enterprise Edition

Die Java2 Plattform Enterprise Edition (J2EE) definiert einen Standard, um mit modula-ren Komponenten verteilte, mehrschichtige, skalierbare und plattformunabhängige un-ternehmensweite Anwendungen zu entwickeln. Dabei versteht sich J2EE nicht als Pro-dukt im eigentlichen Sinne, sondern spezifiziert lediglich einen allgemeinen Rahmen zurAnwendungsentwicklung in der Programmiersprache Java. Ziel ist es, einfach anpassbareund leicht zu administrierende Komponenten zu entwickeln, welche plattformübergrei-fend eingesetzt und an existierende Informationssysteme angekoppelt werden können.

Hierzu werden bestimmte Aspekte der Umgebung, in der die Applikation abgewickeltwird, als auch in der Umgebung, in der entwickelt wird, standardisiert. Dadurch wirddie Umgebung austauschbar, da man sie durch eine gleichwertige Komponente erset-zen kann. Klar definierte Schnittstellen zwischen den Komponenten und der Umgebungsollen dafür sorgen, dass Softwarekomponenten unterschiedlicher Hersteller interope-rabel sind und dass die verteilte Anwendung gut skalierbar ist. Dies kann natürlich nurfunktionieren, wenn sich die Entwickler an die ausgegebene Spezifikation halten.

Darüber hinaus bietet die J2EE-Spezifikation ein festgelegtes Rollenmodell, welchesdie einzelnen Rollen der Entwickler bei der Entwicklung von J2EE-Applikationen defi-niert. Dabei sollte die Rollenverteilung so gewählt werden, dass sich die Entwickler aufihre speziellen Kenntnisse im jeweiligen Fachgebiet konzentrieren können. Das ange-strebte Ziel ist somit, Überschneidungen im Domänenwissen zwischen den Rollen zuminimieren.1

J2EE ermöglicht die Realisierung unternehmensweiter Anwendungen durch eine 3-Schichten-Architektur. Ziel ist es die drei Aufgaben Präsentationslogik (engl. Presentation-Logic), Geschäftslogik (engl. Business-Logic) und Datenhaltung voneinander zu trennen.Die Abbildung 2.1 veranschaulicht die Aufteilung der 3-Schichten als „grob“ Darstel-lung.2

Im Gegensatz zu den Client-Server Architekturen aus den frühen 90igern, welche le-diglich „nur“ 2-Schichten (Client/Server) besaßen, führt die 3-Schichten-Architektur ei-

1(vgl. Tur01)2(vgl. Bor07)

4

KAPITEL 2. EINFÜHRUNG UND GRUNDBEGRIFFE

Abbildung 2.1: Drei-Schichten-Architektur (grob)

ne mittlere Schicht (engl. middle Tier) ein. Die mittlere Schicht wird oft auch als „Midd-leware“ bezeichnet. Charakteristisch für die 2-Schichten-Architekturen waren, dass diePräsentationslogik sowie die Geschäftslogik komplett im Client vereint wurden. DieseArt der Anordnung, wo sich die Applikationslogik hauptsächlich auf dem Client befin-det, wird auch „fat-client“ genannt3.

Die 3-Schichten-Architektur verlagert hingegen die Präsentationslogik und Geschäfts-logik in die mittlere Schicht. Damit liegt die Applikationslogik auf dem Server und nurdie Darstellungslogik auf dem Client. Diese Art der Anordnung wird in der Literatur auchals thin-client bezeichnet4.

Einer der gewonnenen Vorteile aus der Verlagerung der Präsentations- und Geschäfts-Logik ist, dass Änderungen an der Applikationslogik nur einmal vorgenommen werdenmüssen und damit allen Clients sofort zur Verfügung stehen. Hierbei erfolgt die Wartungund Skalierung zentral. Abbildung 2.2 zeigt die 3-Schichten als „fein“ Darstellung.5

Die clientseitigen Zugriffe auf eine J2EE-Anwendung können auf unterschiedliche Arthergestellt werden. Dazu zählen vor allem:

• Handelsüblichen Browser mit Einsatz von Technologien wie, JavaServer Page (JSP),HTML, XML oder Applets.

3(vgl. Zöl06)4(vgl. Zöl06)5(vgl. Bor07)

5

2.1. J2EE - JAVA2 PLATTFORM ENTERPRISE EDITION

Abbildung 2.2: Drei-Schichten-Architektur (fein)

• Java Applikations-Clients, laufend auf einem Rechner (Desktop).

• Portable Geräte (Devices), wie PDA´s (personal digital assistant) oder Handy´s.

Die EIS (Enterprise Information System) Schicht repräsentiert ein so genanntes Unter-nehmensinformationssystem zur geordneten Verwaltung von Wissen und Geschäftsda-ten. Typischerweise werden diese Datenbestände meist in einem relationalen DatenbankSystem gehalten.

Die Ankopplung solcher Informationssysteme ist Einsatzgebiet der Enterprise Appli-cation Integration (EAI) und geschieht mit einer J2EE „Connector-Architecture“ (JCA).Die J2EE Connector Architecture ist eine Software-Architektur, die eine Programmier-schnittstelle (API) zur Verfügung stellt, um die Integration von heterogenen Anwendun-gen in die J2EE-Plattform zu ermöglichen.6

Die mittlere Schicht (Middle Tier) ist stellvertretend für die Serverumgebung einerJ2EE Web Applikation und kann in diverse logische Segmente unterteilt werden. EineJava J2EE Web Applikationen besteht dabei entweder aus Servlets oder JSPs und benöti-gen zur Ausführung einen Container. Ein Container ist eine Serverapplikation, die dieseWeb Applikation verwaltet und ausführt. Diese Container liefern die Laufzeitumgebungfür die Komponenten.

6(vgl. Wik07c)

6


Das Konzept des Containers soll eine einheitliche Sicht auf die von tiefer liegendenSchichten angebotenen Diensten (services), zur Verfügung stellen. Die aktuelle Spezifi-kation erfordert die folgenden Container:

• einen Web-Container als Laufzeitumgebung für Servlets und Java Server Pages (JSP).

• einen EJB-Container als Laufzeitumgebung für Enterprise Java Beans (EJB).

• einen JCA-Container als Laufzeitumgebung für JCA Connectoren.7

Ein WEB-Container besteht meist aus einem Servlet oder ein JSP-generiertes Servletund ist stellvertretend für die serverseitige Präsentationslogik.

Der EJB-Container stellt eine Laufzeitumgebung für Enterprise JavaBeans (EJB) zurVerfügung, welche die Geschäftslogik einer Applikation in sich vereint. Der Containerkümmert sich sowohl um die Speicherung der Daten, als auch um deren Verfügbarkeitfür jeden autorisierten Client. Ein EJB-Container arbeitet als Vermittlungsschicht zwi-schen Client und Datenbank, daher spricht man auch von Middleware.

Der JCA-Container hält eine Laufzeitumgebung für die JCA Connectoren bereit undsoll wie vorher schon beschrieben, die Integration von heterogenen Anwendungen indie J2EE-Plattform ermöglichen.

Container sind normalerweise keine eigenständig lauffähige Software, sondern Teil ei-nes Applikation-Servers nach der J2EE-Spezifikation. Bekannte Applikation-Server sind:

• JBoss (Open Source)

• BEA WebLogic (kommerziell)

• IBM WebSphere (kommerziell)

Da J2EE den Anspruch erhebt, konsequent auf einem Komponentenmodell zu basie-ren und portable zu sein, können Komponenten somit unabhängig von der verwendetenJ2EE-Plattform die gleichen Dienste erwarten.

Sowohl der WEB-Container als auch der EJB-Container bieten Dienste an, die denKomponenten ständig zur Verfügung stehen müssen:

• Namens- und Verzeichnisdienste

7Dieser ist zwar nicht explizit definiert, faktisch jedoch muss jeder Application-Server-Hersteller diesenimplementieren. Denn im Enterprise Java Beans(EJB) sowie im Web-Container sind Restriktionen defi-niert, welche für die JCA-Laufzeitumgebung nicht gelten. Dabei handelt es sich beispielsweise um dasStarten von Threads oder das Lesen und Schreiben in Dateien etc.

7

2.1. J2EE - JAVA2 PLATTFORM ENTERPRISE EDITION

• Transaktionsdienst

• Konfigurationsdienst

• Kommunikationdienst zwischen J2EE-Komponenten

• Sicherheitsdienst (Security)

Darüberhinaus müssen die Hersteller der J2EE-Container folgende Implementierun-gen der J2EE-APIs zur Verfügung stellen:8

• JNDI

Das Java Naming und Directory Interface ermöglicht den Zugriff auf Namens- undVerzeichnisdienste durch Java-Programme. Beispielsweise über LDAP zu LDAP-Servern, JDBC Datenquellen, EJB Homes, JMS (Java Messaging Service) Connec-tions, Network Information Service (NIS) und Domain Name System (DNS).

• Servlet

Die Servlet API stellt Klassen und Interfaces zur Erstellung serverseitiger Web-App-likationen zur Verfügung. Im allgemeinen erlaubt das Java-Servlet-API die Erweite-rung von Servern, deren Protokoll auf Anfragen und Antworten basiert.

• EJB

Enterprise Java Beans sind Softwarekomponenten, die die Geschäftslogik einer Ap-plikation beinhalten und den Zugriff auf persistente Daten gestatten. Die Beanslaufen in einem EJB-Container ab.

• JSP

Java Server Pages sind Textdokumente, die zum einen aus statischem Text und zumanderen aus dynamischen Textelementen (JSP-Elementen) bestehen. Die JSP-Seitenwerden transparent vom Web-Container in ein Servlet umgewandelt. Auf die JSPTechnologie wird später noch genauer eingegangen. JSPs spielen beim Einsatz vonJavaServer Faces eine zentrale Rolle.

• JMX

Java Management Extensions ermöglicht es, die einzelnen J2EE-Komponenten undAnwendungen zu verwalten.

• JMS

Java Message Service ist eine API für die asynchrone Nachrichtenverarbeitung.

8Die Aufzählung enthält nur auszugsweise eine Beschreibung der wichtigsten APIs. Eine komplette Listeder Java Platform Enterprise Edition (Version 5.0) API Spezifikation finden Sie unter (Mic07b)

8


• JDBC

Die Java DataBase Connectivity API bewerkstelligt, das Java-Applikationen mittelsSQL auf eine relationale Datenbank zugreifen können.

• JTA

Die Java Transaction API definiert eine Schnittstelle, die es der Applikation erlaubt,die Transaktionsverwaltung zu steuern. Die JTA ist somit die Java-Schnittstelle zuden Transaktionsmonitoren und regelt den Zugriff von Applikationen auf gemein-sam genutzte Ressourcen wie Datenbanken oder Message-Systeme.

• JAAS

Der Java Authentication and Authorization Service ist eine Java-API, die es ermög-licht, Dienste zur Authentifikation und Zugriffsrechte in Java-Programmen bereit-zustellen.

• JCA

J2EE Connector Architecture ermöglicht die Integration non-Java Applikationen.Stichwort: Enterprise Application Integration (EAI).

• JAXP

Die Java API for XML Processing hilft dem Entwickler bei der Bearbeitung von XML-Dokumenten und enthält eine Reihe von Möglichkeiten zum Validieren und Par-sen.

• JSF

JavaServer Faces ermöglicht dem Entwickler, auf einfache Art und Weise die Ent-wicklung von Komponenten für Benutzerschnittstellen in Webseiten und derenNavigation, zu definieren.

• RMI-IIOP

RMI-IIOP ist die Abkürzung für Java Remote Method Invocation over the InternetInter-ORB-Protocol und ist der Mechanismus, der die Kommunikation zwischenJava-Objekten in verschiedenen virtuellen Maschinen ermöglicht. RMI-IIOP ist, imUnterschied zu RMI (Remote Method Invocation) von Java, mit der API java.rmizu CORBA kompatibel und ermöglicht so die Interaktion von CORBA (CommonObject Request Broker Architecture ) Objekten in eine J2EE-Applikation.

• JavaMail

Die JavaMail API bietet protokoll-unabhängige Unterstützung für Email-Sytemeund erlaubt den Zugriff auf Mail Services, wie z.B. SMTP (Simple Mail Transfer Pro-tocol ), POP3 (Post Office Protocol Version 3), IMAP (Internet Message Access Pro-tocol ) oder NNTP ( Network News Transfer Protocol).

9

2.2. JAVA SERVER PAGES UND SERVLETS

2.2 Java Server Pages und Servlets

Die Trennung von Präsentations-, Geschäfts- und Datenlogik gilt als ein erfolgverspre-chendes Instrument bei der Entwicklung von Web-Applikationen. Wie im vorigen Ab-schnitt schon bereits erwähnt, verwaltet ein WEB-Container meist ein Servlet oder einJSP-generiertes Servlet und ist stellvertretend für die serverseitige Präsentationslogik. ImHinblick auf die Entwicklung mit dem Framework JavaServer Faces (JSF) sollen nun diebeiden Basis-Technologien Servlets und Java Server Pages (JSP)9 vorgestellt werden.

Das Framework JSF ist dabei nicht ausschließlich an die Java Server Pages als Präsen-tationsschicht gebunden, mögliche Optionen sind Renderkits für mobile Endgeräte, diebeispielsweise WML oder XHTML Basic unterstützen. Dennoch lässt sich zunächst einTrend verfolgen, der sich auf HTML-Web-Applikationen auf Basis von JSP konzentrierenwird.10

Grundsätzlich lässt sich über beide Technologien (JSP und Servlets) sagen, dass sie dasgleiche Ziel verfolgen, es nur auf unterschiedliche Weise erreichen. Beide Technologiensind Server-Programme, die dynamische HTTP Web-Seiten generieren und diese zumClient, als Folge einer Anfrage, zurückschicken.

Servlets sind vergleichbar mit Applets, wobei ein Applet ein Java-Programm auf derClient-Seite (im Browser) und ein Servlet ein Programm auf der Server-Seite (im Server)ist. Damit unterscheiden sich die Servlets auch im wesentlichen von CGI-Programme11,die über die CGI-Schnittstelle mit dem Server kommunizieren. Servlets sind dagegeneigenständige Programme, die im Kontext des Webservers liegen. Die Instanzen einesServlets werden bei Bedarf von der Laufzeitumgebung (Web-Container) erzeugt und vonihm aus angesprochen. Der Web-Container seinerseits kommuniziert mit dem Webser-ver oder ist integraler Bestandteil eines Java-Webservers.

Die Servlets bestehen aus Java-Klassen, deren Instanzen innerhalb eines Java-Webser-vers Anfragen von Clients entgegen nehmen und beantworten. 12 Um auf Anfrage vonClients entsprechend reagieren zu können, müssen die Servlets immer die Schnittstel-le javax.servlet.Servlet oder eine davon abgeleitete javax.servlet.http.HttpServlet imple-mentieren. Servlets verfolgen einen prozeduralen Ansatz und erreichen die Webseiten-Generierung dadurch, dass sie die HTML-Anweisungen mit println() oder ähnlichem inden Ausgabestrom senden. Diese Art der Generierung ist nicht nur sehr fehlerträchtig,sondern läßt auch die gewünschte Trennung zwischen Geschäftslogik und Präsentation-logik missen.

9Die Java Server Pages Technologie dient als Referenzimplementierung für die Präsentationsschicht imFramework JSF.

10(vgl. Hai04, S.37)11Common Gateway Interface (CGI), ist eine schon länger bestehende Variante, Webseiten dynamisch

bzw. interaktiv zu machen. (vgl. Wik07a)12(vgl. Wik07e)

10


Die Java Server Pages (JSP) ist eine von Sun Microsystems entwickelte Technologie (Ar-chitektur), die die Generierung von serverseitigem dynamischen Inhalten erlaubt undkonzeptionell vergleichbar mit der ASP.NET Technologie von Microsoft ist. 13

Eine JSP Seite ist hierbei ein textbasiertes Dokument, welches sowohl statischen alsauch dynamischen Inhalt besitzen kann und für gewöhnlich die Erweiterung *.jsp trägt.Fragmente, also Teile einer JSP Seite, die in andere einfliessen, haben die Erweiterung*.jspf.

Der statische Inhalt einer JSP Seite kann aus einem Format wie HTML, SVG, WML oderXML gebildet werden und besteht aus all jenen Elementen, die von einem Webserverin die HTTP-Response (Antwort) ohne Veränderung übernommen werden (z.B. HTML-Tags).14 Der Dynamische Inhalt wird in der Regel in Form von eingebetteten Java-Codein die JSP-Seite eingebracht.

JSP-Seiten werden zur Laufzeit von einem speziellen JSP-Compiler in ein Servlet um-gewandelt, kompiliert und als Servlet ausgeführt. Die Umwandlung der Java Server Pagesin den Bytecode geschieht hierbei in 2 Phasen. In der ersten Phase wird der Java-Anteilan der JSP-Seite durch den JSP-Compiler in einen Java-Quellcode umgewandelt, der imweitestem Sinne einem Java-Servlet entspricht. In der zweiten Phase wird dann der Byte-code durch den Java-Compiler generiert, aus dem vorher entstandenen Java-Servlet. Die-se so erzeugten Java-Klassen können von einem Webserver mit entsprechender Servlet-Engine ausgeführt bzw. interpretiert werden.

JSP-Seiten werden vom Web-Server automatisch in Servlets übersetzt. Der Überset-zungsvorgang von JSP-Seiten in ein Servlet muss dann nur einmal getätigt werden, da-nach benutzt der Servlet-Container direkt die übersetzte Klasse.

Die Java Server Pages verfolgen im Grunde den komplementären Ansatz gegenüberden Servlets. Wo Servlets HTML-Anweisungen in ihren Java-Code integrieren, bauen dieJSPs hingegen Java-Codes mit in ihre HTML-Seiten ein. Faktisch erreichen beide Metho-den ihr Ziel, nur lässt die Lesbarkeit und Wartbarkeit, sowohl die der JSP Seiten als auchdie des Java-Codes, zu wünschen übrig.

Eine nahe liegende Schlußfolgerung wäre es daher, für die Web-Anwendungsentwick-lung die prozedural aufgebauten, in Java geschriebenen Servlets frei von HTML-Anweis-ungen (Präsentationslogik) zu lassen und die JSP-Dokumente frei von Java-Code (Ge-schäftslogik). Und genau dies wird durch eine strikte Trennung der beiden Technologienin spezielle exclusive Aufgabenbereiche erreicht.

Servlets werden oft im Rahmen der J2EE-Spezifikation nach dem Model-View-Con-troller-Pattern (MVC)15 in Form von JSP verwendet. Während sich die Servlets nur auf

13Ähnliche Ergebnisse können auch von den Skriptsprachen wie PHP oder Perl erzielt werden, diese sindaber keine Architekturen.

14(vgl. Wik07d)15MVC steht für das Model-View-Controller Paradigma und wurde schon bei der Programmierung mit

11

2.3. ARCHITEKTUREN

die Ablaufsteuerung und Controllerfunktionalität konzentrieren, werden die JSPs einzigals Präsentationsschicht eingesetzt.

Das MVC-Paradigma spielt eine entscheidende Rolle, um das Zusammenwirken derTechnologien Java Server Pages und Servlets und die Trennung von Präsentations-, Ge-schäfts- und Datenlogik zu verstehen. Es wird daher im nächsten Kapitel noch ausführ-lich betrachtet.

Damit die JSP-Seiten als Präsentationsschicht eingesetzt werden können, sollten in-haltlich keine Vermischungen mehr von Präsentationslogik und Geschäftslogik stattfin-den. Da aber dennoch die Möglichkeit bestehen soll dynamischen Inhalt einzubringen,wurde der eingebettete Java-Code ausgelagert. Dies wurde durch die Einführung spezi-eller JSP-Tags erreicht.

Bei den JSP-Tags handelt es sich um spezielle Tags in XML-Notation, die eine vorde-finierte Funktionalität liefern und in speziellen Tag-Bibliotheken (Tag-Library) gehaltenwerden. Tag-Bibliotheken sind ein integraler Bestandteil der JSP-Spezifikation.

Das Konzept der Tag-Bibliotheken ermöglicht somit die Auslagerung von Java-Codeaus den JSP Seiten. Dadurch ist es möglich, JSP-Seiten zu entwickeln, die nur noch wenigbis gar keinen Java-Code beinhalten.16

Damit kann sich der Web-Designer, der kein Java versteht, auf sein Anwendungsgebietkonzentrieren und unabhängig von dem Web-Entwickler arbeiten, der die dynamischenTeile einer Seite entwickelt. Das angestrebte Ziel, Überschneidungen im Domänenwis-sen zwischen den Rollen zu minimieren, könnte so erreicht werden.

2.3 Architekturen

Die Aufteilung der einzelnen Komponenten und deren Zuständigkeit, sowie die Wahl derzu benutzenden Komponenten-Technologien, ist ein wichtiger Aspekt bei der Entwick-lung von Web-Applikationen. In diesem Zusammenhang wurden auch die Architektur-muster entwickelt, die einen allgemeinen Lösungsrahmen anbieten. Dabei beschreibendie Architekturmuster nicht wie bei den Entwurfsmustern nur die Lösung eines konkre-ten Teilproblems, sondern vielmehr den strukturellen Grundaufbau des Softwaresystemsund die Verteilung der Zuständigkeiten. Sie lassen jedoch die Details des konkreten Ent-wurfs noch offen.

Das Model-View-Controller (MVC) Architekturmuster für Web-Anwendungen wurdeaus dem bekannten Model-View-Controller-Paradigma abgeleitet, das schon bei der Ent-wicklung von Benutzeroberflächen in Smalltalk angewandt wurde. Die Model 1- und Mo-

Smalltalk erfolgreich eingesetzt. Die J2EE-Community hat das MVC-Paradigma entsprechend ihren Ge-gebenheiten angepasst.

16(vgl. Wik07f)

12


del 2- Architektur sind eine für Webanwendungen spezialisierte Variante des Architektur-musters MVC und werden im diesem Kapitel noch genauer vorgestellt.

2.3.1 Das MVC-Paradigma

Das MVC-Paradigma teilt ein Softwaresystem in drei Zuständigkeiten auf: Datenmodell(engl. Model), Präsentation (engl. View) und Programmsteuerung (engl. Controller). Zieldieser Aufteilung soll ein flexibles Programmdesign sein, um mögliche spätere Änderun-gen und Erweiterungen einfach zu halten und die Wiederverwendbarkeit zu fördern. Zu-dem verschafft die Strukturierung eine Übersicht und Ordnung, welche die Komplexitätdes Softwaresystem reduziert.

Der Vorteil bei dieser Vorgehensweise ist, dass es zu einem späteren Zeitpunkt mög-lich ist, die vorhandenen Daten im Datenmodell neu zu visualisieren, in dem man ein-fach nur den View austauscht. Dabei braucht man sich keine Gedanken um die daten-verarbeitenden bzw. datenmanipulierenden Teile des Programms zu machen, da dieseja entkoppelt sind. Des weiteren wird die schon angesprochene Arbeitsteilung in spezifi-sche Arbeitsfelder (Page Autoren, Application Developer und Component Writer) unter-stützt. Die Abbildung 2.3 zeigt die Abhängigkeiten der drei Komponenten Model, Viewund Controller.

Abbildung 2.3: Model-View-Controller

13

2.3. ARCHITEKTUREN

• Datemmodell (Model)

Das Model enthält die darzustellenden Daten und repräsentiert den aktuellen Zu-stand. Das Model kennt weder die Präsentation noch die Steuerung und ist deshalbunabhängig von einer bestimmten Darstellung der Ausgabe oder einem bestimm-ten Verhalten der Eingabe. Von ihr abhängige Views werden registriert und bei Da-tenänderung benachrichtigt. Zu jedem Model kann es mehrere Views geben. DasModel wird in einfachen Applikationen mittels Java Beans umgesetzt. Bei komple-xeren Applikationen kommen dann meist die Enterprise Java Beans zum Einsatz.

• Präsentation (View)

Die View ist die Bildschirmrepräsentation einer Model-Komponente. Zur Visuali-sierung des Zustandes stellt ein View-Objekt Anfragen an das Model-Objekt. Hier-zu liest das View-Objekt die Daten aus dem Model-Objekt aus und stellt sie in ge-wünschter Form dar. Änderungen im Model-Objekt haben zufolge, dass die regis-trierten Views benachrichtigt werden, die sich wiederum durch ihre Funktion Up-date auf einen aktuellen Zustand bringen können. Die View ist nicht für die Inter-aktion mit dem Benutzer verantwortlich. Je nach Design leitet sie aber Benutzerak-tionen (bzw. Events) weiter an das Controller-Objekt.

• Programmsteuerung (Controller)

Der Controller bestimmt das Verhalten, wie auf die Benutzeraktionen reagiert wird.Der Controller steuert und verwaltet die Views, nimmt die Benutzeraktionen ent-gegen, wertet diese aus und agiert entsprechend. Der Controller ändert abhängigvom Benutzerverhalten das Model oder ruft andere Views auf. Jedem Controllerist dabei genau eine View zugeordnet und mehrere Controller einem Model. DerController besitzt die Intelligenz und steuert somit den Ablauf der Präsentation.

2.3.2 JSP-basierte Model 1-Architektur

Die Model 1 Architektur ist eine 2-Schichte Architektur, die häufig nur für einfach über-schaubare und kleine Web-Anwendungen verwendet wird. Die Model 1 Architektur trenntnicht die Zuständigkeiten nach dem MVC-Paradigma auf. In einem JSP-basierte Modellliegen die Zuständigkeiten hauptsächlich bei den JSP-Seiten und den Java Beans. DenAufbau einer JSP-basierte Model 1 Architektur zeigt Abbildung 2.4.

Bei dieser Art von Aufbau ist die JSP-Seite sowohl für die Darstellung (View), als auchfür die Programmsteuerung (Controller) zuständig. Die Java Bean kapselt den aktuellenZustand und enthält das Datenmodell (Model). Charakteristisch für diese Architekturwar, dass für nahezu jede angezeigte Seite eine eigene JSP-Seite notwendig war und dassdie Navigation zumeist fest (dezentralisiert) in der JSP-Seite eingebunden wurde.

14


Abbildung 2.4: Die Model 1 Architektur

Vorteil dieses Ansatzes ist die einfache und zumeist schnellere Implementierung. Esbietet sich an, diesen Ansatz nur bei einfachen und kleinen Projekten zu verwenden,wo sich der Aufwand einer Trennung nach dem MVC-Paradigma nicht lohnt. Denn dieNachteile liegen auf der Hand. Aufgrund des Vermischen von HTML- und Java-Code,lässt die Überschaubarkeit zu wünschen übrig. Dies würde sich bei einer aufgabenori-entierten Entwicklung von Page Autoren, Application Developer und Component Writernachhaltig bemerkbar machen. Zudem sind spätere mögliche Änderungen in der Na-vigation recht aufwendig, da die dezentralisierte Arbeitsweise verlangt, dass womöglichalle Verbindungen (Links) quer durch die JSP-Seiten geändert werden müssen. Diese Va-riante von Architektur ist außerdem schlecht erweiterbar und skalierbar.

2.3.3 JSP-basierte Model 2 Architektur

Die seiten-zentrierte Navigationsweise der Model 1-Architektur stößt bei größeren An-wendungen schnell an ihre Grenzen. Deshalb wurde die Model 2 Architektur auch um ei-ne Controller Servlet erweitert. Die Model 2 Architektur wächst somit zu einer 3-SchichtenArchitektur und setzt das MVC-Paradigma um. Dabei ist es leicht, die Architektur umweitere Schichten wie z.B EJBs zu erweitern. Die Abbildung 2.5 zeigt den Aufbau einerJSP-basierten Model 2 Architektur.

Innerhalb der Model 2 Architektur sind die JSPs nicht mehr für die Ablaufsteuerung(Controller) verantwortlich, sondern nur noch für die eigentliche Bildschirmrepräsen-tation (View) zuständig. Die Zuständigkeiten der Model-, View- und Controller-Kompo-nenten sind wie im Kapitel Das MVC-Paradigma schon beschrieben, dem MVC-Paradigma

15

2.3. ARCHITEKTUREN

Abbildung 2.5: Die Model 2 Architektur

entsprechend verteilt. Durch die zunehmende Komplexität wächst der anfangs größereArbeitsaufwand, wird aber durch die gewonnenen Vorteile wie Wiederverwendbarkeit,Erweiterbarkeit und Skalierbarkeit mehr als wieder wettgemacht.

2.3.4 Die Umsetzung des MVC-Paradigma im Framework -JavaServer Faces

Dem Framework - JavaServer Faces (JSF) liegt das MVC-Architekturmuster zugrunde.Das Framework JSF besitzt eine zentrale Navigation der Seiten, welches durch die Con-troller-Komponente dem sogenannten FacesServlet gesteuert wird. Das Verhalten wirdin einer zentralen Konfigurationsdatei faces-config.xml definiert, die noch später genau-er vorgestellt wird. Neben dem standardmäßigen Navigation-Handler gibt es die Mög-lichkeit, ihn gegen andere (fremd oder eigene) Varianten auszutauschen.

Die Model-Komponenten werden im Framework JSF durch Java Beans realisiert, die indiesem Zusammenhang auch Managed Beans genannt werden. Bekannt gemacht (defi-niert) werden die Managed Beans, wie auch schon das Verhalten der Navigation, in derKonfigurationsdatei faces-config.xml. Die Managed Beans repräsentieren den serversei-tigen Zustand einer UI-Komponente. An UI-Komponenten ausgelöste Benutzeraktionen(Actions) werden an die ihr registrierten Managed Beans weiter geleitet. Innerhalb derManaged Beans werden die Actions dann verarbeitet oder an weitere Instanzen dele-giert. Das Resultat einer Managed Beans wird als Rückgabewert dem Navigation-Handlerzurückgegeben, der dann den nächsten Navigationsfall (Seiten-Wahl) anhand dem be-schriebenen Verhalten in der faces-config.xml bestimmt.

16


Die View-Komponente wird durch sogenannte Renderer repräsentiert. Ein Renderereiner View-Komponente (UI-Komponente) definiert die Darstellung der Komponente inder jeweiligen Auszeichnungssprache wie z.B. HTML, XHTML, XML. Dabei werden meh-rere Renderer zu RenderKits zusammengefasst. Die UI-Komponente selbst definiert le-diglich nur die Funktionalität. Dadurch ist es möglich, dass ein und dieselbe UI-Kom-ponente unterschiedliche Renderer besitzen und damit auf unterschiedliche Arten derRepräsentation dargestellt werden können. Die Trennung der Funktionalität und der Re-präsentation einer UI-Komponente, fördern die schon oft angesprochene Rollenvertei-lung bei der Entwicklung dieser Komponenten. Die Referenzimplementierung von JSFbenutzt JSP mit dem Standard RenderKit HTML, dies ist aber wie schon erwähnt, nureine Art der Repräsentation.

2.4 Laufzeitumgebung

Die Laufzeitumgebung für Servlets bzw. JSP-generierte Servlets wird im Rahmen der Ent-wicklung von Java J2EE Web Applikationen durch das Konzept der Container realisiert.Das Konzept des Containers soll eine einheitliche Sicht auf die von tiefer liegenden Schich-ten angebotenen Diensten (services), zur Verfügung stellen. Container sind normaler-weise keine eigenständig lauffähige Software, sondern Teil eines Applikationsservers (engl.Application Server) nach der J2EE-Spezifikation.

Ein Anwendungsserver oder Applikationsserver ist im Allgemeinen ein Server, auf demAnwendungsprogramme (Applikationen) ausgeführt werden. Ein Applikationsserver stelltfür Anwendungsprogramme spezielle Dienste zur Verfügung, wie beispielsweise Trans-aktionen, Authentifizierung oder den Zugriff auf Verzeichnisdienste und Datenbankenüber definierte Schnittstellen.

Da Webbrowser besonders beliebte thin-clients für Applikationsserver darstellen, sinddie meisten Applikationsserver entweder Ergänzungen zu Webservern oder enthalteneinen Webserver (z. B. Tomcat in JBoss, WebSphere oder WebLogic). In den folgendenAbschnitten sollen die gängigsten Applikationsserver vorgestellt werden.

2.4.1 Jakarta Tomcat Server

Der Jakarta Tomcat Server ist die offizielle Server-Referenzimplementierung für die Servlet-und JSP-Spezifikation von Sun Microsystems. Er wurde von der Apache-Foundation17

innerhalb des Jakarta-Projektes18 entwickelt.

Der Tomcat Server besteht seit Version (4.x) aus zwei Hauptkomponenten Jasper (JSP-Compiler) und Catalina (Servlet Container). Mit Hilfe des JSP-Compilers Jasper können

17Informationen über die Apache-Foundation (vgl. Fou07c)18Informationen über das Jakarta-Projekt (vgl. Fou07b)

17

2.4. LAUFZEITUMGEBUNG

Java Server Pages in Servlets übersetzt und im Servlet Container Catalina zur Ausführunggebracht werden. Da Jasper eine eigenständige Komponente und als Servlet realisiert ist,besteht auch die Möglichkeit, ihn in anderen Servlet Container einzusetzen.

Der Catalina Servlet Container ist komplett in Java implementiert. Er deckt aktuell dieReferenz Implementierung der Servlet (2.3) und JSP (1.2) Spezifikatioen von Sun Micro-systems ab. Der Catalina Servlet Container ist der im Jakarta-Projekt für Tomcat entwi-ckelte Nachfolger von Apache JServ.

Tomcat bietet, wie fast alle Servlet Container einen eigenen, integrierten HTTP-Serveran, der es erlaubt, neben dynamischen Inhalten, statische Elemente zu übertragen.

Jakarta ist wie Apache ein Open Source Projekt und somit ist der Quellcode zu jeder Zeitfrei verfügbar. Da der Tomcat Container aber nicht als Web-Server, sondern als Contai-ner für Web-Applikationen konzipiert wurde, sind viele Aspekte eines modernen Web-Servers, wie z.B. sicherheitsrelevante Aspekte nicht ausreichend realisiert bzw. imple-mentiert. Um dennoch die dynamische Funktionalität des Tomcat Containers nutzen zukönnen, wird der Tomcat Container zusammen mit der bewährten Robustheit des ApachWeb-Servers in Kombination zusammen geschaltet.

2.4.2 Der JBoss Applikationsserver

JBoss ist der derzeit einer der populärsten Open-Source-Applikationsserver. Der JBossApplikationsserver ist die Implementierung eines Applikationsserver nach dem J2EE-Standard und Teil des JBoss Middleware-Frameworks. Die Arbeit daran wurde im Jahre2000 begonnen und erreichte im Juli 2004 mit der Zertifizierung nach der CompatibilityTest Suite für die J2EE 1.4 von Sun einen wichtigen Meilenstein. 19 JBoss war der erstezertifizierte Open-Source-Applikationsserver und ist somit eine echte Alternative gegen-über BEA Weblogic und IBM Websphere, der zudem kostenlos zu bekommen ist.

Im Rahmen dieses Projekts wird der JBoss Applikationsserver in Kombination mit Tom-cat verwendet. Die Leichtigkeit der Installation und das Customizing von Tomcat ist sehrgut dokumentiert und bietet eine runde Sache und gute Basis für JSP- bzw. Servlet-An-wendungen. Es werden zwar momentan nicht alle Aspekte eines vollständigen Applika-tionsservers gebraucht, aber gerade die Praxistauglichkeit und die gute Integration in dieEntwicklungsumgebung Eclipse haben mich dazu bewogen, den JBoss Applikationsser-ver als Ganzes20 zu verwenden.

19Der ursprüngliche Entwickler JBoss Inc. wurde im Jahr 2006 vom Linux Distributor RedHat übernom-men. (vgl. Hat07)

20Für viele Web-Anwendungen würde auch nur der Tomcat mit seiner Funktionalität reichen.

18


2.4.3 IBM WebSphere Applikationsserver (WAS)

Bei dem von IBM kommerziell vertriebenen WebSphere Applikationsserver (WAS) han-delt es sich wie bei JBoss um einem Server, der die J2EE Spezifikation von Sun vollständigerfüllt. Die Plattform unterstützt Webservices und die moderne J2EE-Architektur, soll ei-ne hervorragende Portabilität, ausgezeichnete Performance, höchste Skalierbarkeit undeine sehr gute Anschlussfähigkeit an andere Systeme garantieren. 21

An Programmierhilfen stellt WebSphere den Entwicklern ein Portfolio zur Verfügung,wie z.B. Transaktions-Management für die Sicherheitsroutinen, Clustering-Optionen zurOptimierung der Leistungsfähigkeit, Web-Entwicklungstools (WebSphere Studio Appli-cation Developer (WSAD)) und den allgemeinen umfangreichen Support von IBM. Ins-gesamt rühmt sich IBM eine All-In-One Lösung präsentieren zu können, die den Kundenauch im Hinblick der weiteren Entwicklung der Produktfamilie eine gewisse Sicherheitbietet, was bei den Open-Source-Projekten tendenziell nicht gegeben ist.

Dennoch, auch IBM hat sich im Laufe der Zeit im Segment der Open-Source-Projekteneinen Platz erkämpft und strebt weiter nach Marktanteilen. Im Oktober 2005 stellte IBMeine kostenlose Version seines WebSphere Application Sever auf Basis von Apache Gero-nimo unter dem Namen Websphere Application Server Community Edition vor. Mit demkostenlos erhältlichen System sollen vor allem kleine und mittlere Unternehmen günstigin die J2EE-Server-Welt einsteigen können.

2.4.4 Andere Applikationsserver

Neben den eben vorgestellten Applikationsserver (Open-Source bzw. kommerziell) sol-len aber auch noch andere bekannte Firmen genannt werden, die sich einen Namen aufdem Applikationsserver Markt gemacht haben. Ferner konnten sich im kommerziellenJ2EE Bereich Oracle mit dem Oracle Application Server, SUN iPlanet und BEA WebLogicpositionieren. Bestehenden Open-Source-Alternativen zu JBoss sind Geronimo22, Glass-fish23 und JOnAS. 24

21nach eigenen Angaben von IBM (vgl. IBM07)22Apache Geronimo wird unter Federführung der Apache Software Foundation (ASF) entwickelt. (vgl.

Fou07a)23SUNs Open Source Java EE 5 Application Server. (vgl. Mic07a)24Java Open Application Server. (vgl. Web07)

19

3 Das Framework - JavaServerFaces

Mit dem Framework - JavaServer Faces (JSF) hat Sun ein ereignisgesteuertes javabasier-tes Web-Framework auf Grundlage der Model 2 Architektur entwickelt. Dabei soll sichdie Entwicklung von Anwendungen für das Web vereinfachen. Mit dem Framework las-sen sich Benutzeroberflächen für Web-Anwendungen aus vorgefertigten Komponentenzusammenbauen, ähnlich wie Desktop-Applikationen mit dem GUI-Framework Swing.Das Hauptaugenmerk liegt also in erster Linie in einem User-Interface-Framework.

In den folgenden Abschnitten werden alle relevanten Themen behandelt, die sich mitder Zusammensetzung und der Funktionalität des Frameworks JSF beschäftigen. Dazuzählen Themen wie die Konfigurationsdateien, der Lebenszyklus der Anfrageverarbei-tung, das UI-Komponenten-Modell, das Rendering-Modell, die Validierung, das Event-handling, das Navigations-Modell, die JSF-Tag-Bibliotheken, die Managed Beans und dieLokalisierung.

3.1 Konfigurationsdateien

Beim Aufbau großer WEB-Applikationen spielen die Konfigurationsdateien eine wichtigeRolle, um das System bzw. einzelne Komponenten optimal zu konfigurieren und an diesystemspezifischen Gegebenheiten perfekt anzupassen.

Eine jede WEB-Applikation besteht immer aus einer Reihe von Konfigurationsdatei-en. Eine besondere Stellung innerhalb einer jeden WEB-Applikation hat die XML-Dateiweb.xml. Aufgabe dieser Konfigurationsdatei ist es, alle Einstellungen rund um das Fa-cesServlet zu ermöglichen. Diese zentrale Konfigurationsdatei sollte sich immer im WEB-INF-Verzeichnis einer WEB-Applikation befinden.

Eine weitere nicht weniger unwichtige Datei ist die faces-config.xml. In dieser Kon-figurationsdatei werden alle Parameter definiert, die für die JSF-Applikation notwendigsind. Vornehmlich werden hier alle Einstellungen vorgenommen, die sich mit dem Ver-arbeitungsprozess der ankommenden Requests an das FacesServlet beschäftigen. DieserVerarbeitungsprozess kann in Phasen unterteilt werden, wird deswegen auch „Der Le-benszyklus der Anfrageverarbeitung“1 genannt und soll später noch genauer beschrie-

1(vgl. Hai04)

20

KAPITEL 3. DAS FRAMEWORK - JAVASERVER FACES

ben werden. Es sollen nun folgend beide Konfigurationsdateien vorgestellt werden.

3.1.1 Der deployment Deskriptor (web.xml)

Bei einer JSF-Applikation muss immer innerhalb der Datei web.xml, das FacesServlet de-finiert werden. Dieses FacesServlet fungiert als zentraler Controller und nimmt alle An-fragen an die JSF-Applikation entgegen. Das folgende Code-Beispiel zeigt auszugsweiseden typischen Aufbau einer Datei web.xml.

<web-app>...

<servlet><servlet-name>Faces Servlet</servlet-name><servlet-class>javax.faces.webapp.FacesServlet</servlet-class><init-param>

<param-name>config</param-name><param-value>/WEB-INF/faces-config.xml</param-value>

</init-param><load-on-startup>0</load-on-startup>

</servlet>

<servlet-mapping><servlet-name>Faces Servlet</servlet-name><url-pattern>*.faces</url-pattern>

</servlet-mapping></web-app>

Im Folgenden sollen nun alle relevanten Elemente im einzelnen beschrieben werden.

<servlet>...</servlet>

Dieser Bereich definiert das FacesServlet, das in der Klasse javax.faces.webapp.FacesServletenthalten ist und folgende Elemente enthält:

<servlet-name>Faces Servlet</servlet-name><servlet-class>javax.faces.webapp.FacesServlet</servlet-class>

21

3.1. KONFIGURATIONSDATEIEN

Faces Servlet ist der Name des Servlets und javax.faces.webapp.FacesServlet ist der quali-fizierende Java Klassenname des JavaFaces Kontrollers.

<init-param><param-name>config</param-name><param-value>/WEB-INF/faces-config.xml</param-value>

</init-param>

Das Kontroller-Servlet kann mit diversen Initialisierungsparametern konfiguriert wer-den. In unserem Beispiel wird mittels dem Parameter config definiert, wo sich die zen-trale Konfigurationsdatei für unsere JSF-Applikation befindet. Der Eintrag verweist aufdas Verzeichnis /WEB-INF/ in der sich die Datei faces-config.xml befindet. Da die faces-config.xml von zentraler Bedeutung für unsere Anwendung ist, werde ich sie später nochgenauer vorstellen.

<load-on-startup>0</load-on-startup>

<load-on-startup> gibt an, dass das Controller-Servlet bereits beim Start des Containersgeladen werden soll.

<servlet-mapping><servlet-name>Faces Servlet</servlet-name><url-pattern>*.faces</url-pattern>

</servlet-mapping>

Die Konfiguration des <servlet-mapping> beschreibt, in welchen Fällen der FacesServletController eine Anfrage entgegen nimmt und eine Response generiert. Es gibt grundsätz-lich zwei verschiedene Möglichkeiten zu definieren, welche URLs vom Controller verar-beitet werden: Extension-Matching und Präfix-Matching:

Extension-Matching Das Extension-Matching leitet alle Anfragen, die mit einer be-stimmten Endung, wie im Beispiel zu sehen *.faces, an das FacesServlet weiter.Denkbar wäre auch ein Extension-Matching mit der Endung .jsp. Damit würdendann alle JSP-Seiten das FacesServlet erreichen. Folgendes Beispiel einer Anfrageeines WEB-Browsers veranschaulicht dies.

http://localhost:8080/EMS/login.jsp

Präfix-Matching Das Präfix-Matching leitet alle URLs, die nach dem Kontextpfad derApplikation mit einem bestimmten Wert anfangen, an den Controller weiter. DieKonfiguration des <servlet-mapping> würde dann wie folgt aussehen.

22


<servlet-mapping><servlet-name>Faces Servlet</servlet-name><url-pattern>/faces/*</url-pattern>

</servlet-mapping>

Die Anfrage vom WEB-Browser an den Controller würde dann so aussehen.

http://localhost:8080/EMS/faces/login

Grundsätzlich lässt sich festhalten, das die Art der Verwendung des Matching keinenEinfluss auf das Ergebnis hat, bzw. auf die Verarbeitung durch das FacesServlet.

3.1.2 Die Anwendungskonfigurationsdatei (faces-config.xml)

Die Datei faces-config.xml ist wie schon angesprochen, die zentrale Konfigurationsdateides FacesServlet-Controllers. Alle ankommenden Requests, ob per Extension-Matchingoder Präfix-Matching werden von dem FacesServlet-Controller gefiltert und an das Fa-cesServlet weitergegeben und verarbeitet. Der Typische Aufbau einer Datei faces-config.xml kann aus folgenden Elementen bestehen:2

• Application:

Hier können Einstellungen vorgenommen werden, die für die gesamte Web-Appli-kation gültig sind. Pro Web-Applikation gibt es immer nur eine Instanz, das heißt,dass die Applikation-Instanz als Singleton implementiert ist. Durch den modula-ren Aufbau können beinahe alle Klassen, die für die Steuerung nötig sind, durchBenutzer-definierte Klassen ausgetauscht werden.

• Factory:

Über das <Factory>-Element hat der Benutzer die Möglichkeit, die Standard-Factor-ies auszutauschen, um so die Erzeugung der Objekte zu beeinflussen. In den sel-tensten Fällen wird aber ein JSF Entwickler, die Default-Einstellungen ändern müs-sen. Der Vollständigkeit halber seien alle Factories erwähnt: application-factory,faces-context-factory, lifecycle-factory und render-kit-factory.

• Component

Selbstentwickelte benutzerdefinierte UI-Komponenten können über das <compo-nent>-Element der Web-Applikation zugänglich gemacht werden. Dabei werdendie UI-Komponenten durch das <component>-Element registriert und stehen fort-an der Applikation zur Verfügung.

2(vgl. Hai04)

23

3.1. KONFIGURATIONSDATEIEN

• Converter

Mit dem <converter>-Element hat der Web-Entwickler die Möglichkeit, die Stand-ard-Konverter um seine eigenen oder fremd entwickelten Konverter zu erweitern.Alle hier registrierten Konverter haben eine <converter-id>, über die sie eindeutigzu identifizieren sind.

• Managed-bean

Das <managed-bean>-Element dient zur Registratur aller Java Beans einer JSF-Applikation. Sobald eine Managed-Bean zum erstenmal über eine JSP-Seite ange-sprochen wird, wird automatisch dynamisch eine Instanz von ihr erzeugt. Bei derDefinition der Managed-Beans besteht auch die Möglichkeit, sie über ihre Proper-ties vorzuinitialisieren und anzugeben, in welchen Scope (Session, Request, Appli-cation oder none) sie abgelegt werden soll.

• Navigation-rule

Jedes <navigation-rule>-Element repräsentiert eine individuelle Entscheidungsre-gel, die bestimmt, welche Seite als nächstes angezeigt werden soll. Abhängige Fak-toren für den Navigations-Fall sind, für welche aktuelle Seite gilt der Navigation-Fall <from-view-id>, der Rückgabewert vom NavigationHandler <from-outcome>und die nächste zu rufende Seite <to-view-id>.

• Referenced-bean

Das Element <referenced-Bean> ist eine Referenz auf ein Java-Objekt, welches ei-ne konkrete Klasse, abstrakte Klasse oder ein Interface sein kann, das zur Laufzeitder Applikation unter dem Key <referenced-Bean-name> und Scope verfügbar seinsoll.

• Render-kit

Das <render-kit>-Element beschreibt die Auswahl des RenderKits und entschei-det damit über die Wahl der gewählten Bildschrimrepräsentation (HTML, XHTML,WML etc.) einer UI-Komponente. Innerhalb einer Applikation kann das Render-Kit über <render-kit-id> referenziert und benutzt werden. Der Zugriff erfolgt dannüber die Methoden der RenderKit-Factory Klasse.

• Lifecycle

Mir dem <lifecycle>-Element hat der Entwickler die Möglichkeit Veränderungen ander Standard-Anfrageverarbeitung vorzunehmen.

• Validator

24


Mit der Validierung hat der Entwickler ein wichtiges Feature, die Benutzereingabeauf mögliche „Eingabefehler“ vorab zu überprüfen. Wie auch schon bei dem <con-verter>-Element hat der Web-Entwickler mit dem <validator>-Element die Mög-lichkeit, die Standard-Validierer um eigen entwickelte Validatoren zu erweitern.

3.2 Der Lebenszyklus der Anfrageverarbeitung

Eine Anfrage an eine JSF-Applikation durchläuft mehrere Phasen der Verarbeitung. DieVerarbeitung der Anfrage durch diese verschiedenen Phasen wird Lebenszyklus der An-frageverarbeitung (engl. Request Processing Lifecyle) genannt3. Doch bevor die einzelnenPhasen vorgestellt werden sollen, soll kurz auf die verschiedenen Szenarien einer Anfrageeingegangen werden.

Bei einer Anfrage (engl. Request) an eine JSF-Applikation kann es grundsätzlich zu fol-genden unterschiedlichen Szenarien kommen:

1. Ein Non-Faces Request erzeugt eine Faces Response.

Ein Non-Faces Request ist eine Anfrage von einer Web-Seite, die von keiner JSF-Applikation erzeugt wurde. Ein Beispiel wäre ein Link von einer Web-Seite ohneJSF-Elementen (UI-Komponenten), hin zu einer Web-Seite mit JSF-Elementen.

2. Ein Faces Request erzeugt eine Faces Response.

Eine Faces Response ist eine Antwort einer JSF-Applikation, die erzeugt wurde, durchdie letzte Phase der Anfrageverarbeitung, die „Render Response“-Phase. Durchläuftdie Anfrageverarbeitung nicht die letzte Phase, so spricht man von einer Non-FacesResponse.

3. Ein Faces Request erzeugt eine Non-Faces Response.

Somit ist ein Faces Request eine Anfrage von einer Web-Seite, die vorher eine FacesResponse erhalten hat, die von einer JSF-Applikation erzeugt wurde.

Das Standard-Szenario einer JSF-Applikation sieht so aus, dass ein Faces Request alsAnfrage, durch eine Faces Response beantwortet wird. Wie schon angedeutet, durchläufteine Anfrage an eine JSF-Applikation verschiedene Phase, die nun im einzelnen genauerbeschrieben werden sollen. Die Abbildung 3.1 zeigt den Lebenszyklus der Anfrageverar-beitung.4

Der Lebenszyklus der Anfrageverarbeitung enthält folgende Phasen:

3(vgl. Hai04, S. 33ff.)4(vgl. Hai04, S. 43)

25

3.2. DER LEBENSZYKLUS DER ANFRAGEVERARBEITUNG

Abbildung 3.1: Der Lebenszyklus der Anfrageverarbeitung

1. Wiederherstellung des UI-Komponenten-Baumes (engl. Restore View)

In der ersten Phase wird die JSP-Seite nach UI-Komponenten durchsucht und diegefundenen UI-Komponenten in eine Baum-Struktur gebracht (wiederhergestellt).An den Komponenten registrierte Validierungs-Klassen, Event-Listener oder Kon-verter würden dementsprechend auch als Elemente im Baum auftauchen. Die Auf-teilung in eine Baum-Struktur hat den Vorteil, dass eine Applikation später sehr be-quem und einfach auf die einzelnen Elemente im Baum zugreifen kann, um sie ge-gebenenfalls zu verändern. Die erstellte fertige Baum-Struktur wird im Anschlussim FacesContext abgelegt und ist damit später für weitere Verarbeitungsschritte je-derzeit zugänglich.

2. Übernahme der Anfrage-Werte (engl. Apply Request Value)

Die einzelnen Komponenten, das heißt, die Elemente des in der ersten Phase er-stellten Komponenten-Baum (engl. Component Tree), beschaffen sich mittels ih-rer eigenen decode()-Methode die Werte aus den Anfrage-Parametern. Dabei kanndavon ausgegangen werden, das jede UI-Komponente eine decode()-Methode hat,weil jede UI-Komponente von der abstrakten Klasse UIComponent abgeleitet istund damit zwingend diese Methode implementieren muss. Treten bei der Über-nahme der Anfrage-Werte Fehler auf, kann die weitere Verarbeitung abgebrochenwerden, indem die Methode responseComplete()des FacesContext aufgerufen wird.Damit wird dann die komplette Fehlermeldung an den FacesContext übergebenund zur letzten Phase zur der Render Response-Phase gesprungen.

3. Verarbeitung der Validierung (engl. Process Validation)

26


Die Verarbeitung der Validierung betrifft alle UI-Komponenten, an dem ein Valida-tor registriert wurde. Dabei wird der Wert der Eingabe auf seine formale Richtigkeitüberprüft. Entspricht der Wert nicht mit dem im Validator spezifizierten geforder-ten Kriterien, so wird eine Fehlermeldung ausgelöst. Diese wird dann in den Faces-Context gespeichert und es wird zur letzten Phase gesprungen. Die Fehlermeldungkann in der aktuellen Seite angezeigt werden, um den Benutzer auf die von ihmgegebene „falsche“ Eingabe hinzuweisen.

4. Aktualisierung der Model-Objekte (engl. Update Model Values)

Die validierten Werte können nach ihrer Überprüfung an die entsprechenden Model-Objekte übertragen werden. Dabei findet unter Umständen ein Standard oder vomBenutzer explizit gewollte Konvertierung statt, die die in der Bildschirmpräsentati-on verwendeten Datentypen, auf die im Model verwendeten umwandelt.

5. Aufruf der Applikation (engl. Invoke Application)

In dieser Phase werden alle ActionEvents, die durch den Benutzer durch drückenauf Buttons oder Hyperlinks in der JSP-Seite ausgelöst wurden, verarbeitet. An Kom-ponenten ausgelöste ActionEvents werden von registrierten Model-Objekte verar-beitet. Der Rückgabewert der Model-Objekt-Methode wird an den NavigationHand-ler übergeben. Anhand des Navigation-Case der in der faces-config.xml beschrie-ben ist, kann die nächste Seite bestimmt werden, die „gerendert“ werden muss.

6. Rendern der Response (engl. Render Response)

Bei jeder UI-Komponente des Komponenten-Baums, der sich im FacesContext be-findet, wird encode()-Methode aufgerufen. Damit wird der Prozess des „Renderns“der einzelnen Komponenten angestoßen. Mögliche Fehlermeldungen, die sich imFacesContext befinden, werden auf der JSP-Seite mittels dem speziellen Tag<h:message/> angezeigt. Nach erfolgreicher Darstellung aller Komponenten wirdder Zustand des Komponenten-Baum gespeichert und steht fortan neuen FacesRequests zur Verfügung.

Ab der zweiten Phase werden die einzelnen Phasen immer von Event-Verarbeitungenunterbrochen. An dieser Stelle hat der Entwickler zwei Möglichkeiten. Erste Möglichkeit,falls notwendig, kann der Entwickler aus dem Verarbeitungsprozess komplett aussteigen,durch Aufruf der responeseComplete()-Methode des aktuellen FacesContext-Objetes. Da-mit wird dann ein Non-Faces Response erzeugt. Zweite Möglichkeit ist, den Verarbei-tungsprozess nur abzubrechen und direkt zur letzen Phase (Rendern Response) zu sprin-gen.

27

3.3. DAS UI-KOMPONENTEN-MODELL

3.3 Das UI-Komponenten-Modell

Das UI-Komponenten-Modell ist sehr flexibel, um Benutzeroberflächen für Web-Anwend-ungen mit JavaServer Faces zu entwickeln. Dabei gibt die JavaServer Faces-Spezifikationvor, wie die Architektur dieser Komponenten aussehen soll und liefert auch schon eingroßes Angebot an Basiskomponenten mit.

Eine UI-Komponente kann hierbei ein einfacher Button oder eine zusammengesetz-te Tabelle, die aus mehreren Einzelkomponenten bestehen kann, sein. UI-Komponentensind leicht konfigurierbare, durch Komposition erweiterbare und wieder verwendbareKomponenten, aus denen das Benutzer-Interface einer JSF-Applikation gebildet wird.Zugänglich werden die UI-Komponenten über sogenannte JSF Custom Tags innerhalbeiner JSP-Seite gemacht.

Grundsätzlich spezifizieren die UI-Komponenten-Klassen sämtliche UI-Komponenten-Funktionalitäten. Dazu gehören Funktionalitäten, wie die Werte aus dem Eingabeformu-lar auslesen(decoding), den Komponentenstatus erhalten, eine Referenz zu den Model-Objekten aufrechthalten, das Event-Handling steuern und das Rendern (Encoding).

An der Spitze der UI-Komponenten-Klassen und somit erweitert jede UI-Komponentediese Klasse, steht die Klasse javax.faces.component.UIComponent. Direkt davon abge-leitet ist die UIComponet-Base-Komponente. Diese Klasse vereinfacht die Entwicklungvon eigens entwickelten UI-Komponenten (engl. Custom User Interfaces Components)und implementiert auch schon eine Reihe der abstrakten Methoden von der Klasse ja-vax.faces.component.UIComponent. Die UIComponet-Base-Komponente definiert somitden Default-Status und das Verhalten einer UI-Komponente. Alle UI-Komponenten-Klas-sen sind von ihr abgeleitet.

Die Abbildung 3.2 zeigt die Vererbungsstruktur der verschiedenen UI-Komponentender Referenzimplementierung von Sun.5

Erwähnenswert sei noch die UIViewRoot-Komponente. Sie dient für jede erstellte Baum-Struktur (Wiederherstellung des UI-Komponenten-Baumes) als Einstiegselement undbefindet sich immer als „Top-Element“ in einer Baum-Struktur.

Festzuhalten bleibt, dass alle UI-Komponenten eins gemeinsam haben, sie definierenlediglich die Funktionalität einer UI-Komponente, lassen aber die Entscheidung ihrerRepräsentation noch offen. Das betrifft sowohl die Art der Darstellung einer UI-Kompo-nente (eine UI-Komponente wie UISelectMany kann z.B. in HTML durch mehrere Check-boxen oder durch ein Drop-Down-Menü dargestellt werden.), als auch die benutze Aus-zeichnungssprache (HTML, XHTML, WML etc.). Wie eine UI-Komponente dargestelltwird und in welcher Auszeichnungssprache, wird durch den benutzen Renderer ent-schieden.

5Die Erläuterung zu den einzelnen Komponenten würde den Rahmen dieser Arbeit sprengen, kann abervon dem interessierten Leser unter (vgl. Hai04, S. 49ff.) nachgelesen werden.

28


Abbildung 3.2: Die UI-Komponenten der Referenzimplementierung

3.4 Das Rendering-Modell

Das Rendering-Modell ist für die Darstellung einer UI-Komponente auf dem Bildschirmverantwortlich. Die Trennung von Funktionalität und Präsentation einer UI-Komponentehat nicht nur den Vorteil der getrennten Entwicklung (JSF-Rollenverteilung), sondernbringt damit auch eine hohe Flexibilität mit sich, die es möglich macht, jede UI-Kom-ponente in unterschiedlichen Arten der Darstellung und zugleich in unterschiedlichenAuszeichnungssprachen anzeigen zu lassen.

Durch die gewonnene Unabhängigkeit von Funktionalität und Präsentation ist es des-halb auch möglich, die Renderer untereinander auszutauschen, ohne an den UI-Kom-ponenten Veränderungen bzw. Anpassungen vornehmen zu müssen. Dies fördert die Er-weiterbarkeit und Wartbarkeit beträchtlich. Die Umsetzung einer UI-Komponente in ei-ne Bildschirmrepräsentation wird Rendering genannt und wird durch spezielle Render-Klassen durchgeführt.

Gleichartige Renderer werden in einem RenderKit zusammengefasst. Die JavaServerFaces Referenzimplementierung enthält bereits ein Standart-RenderKit, welches die UI-

29

3.5. DIE JSF-TAG-BIBLIOTHEKEN

Komponenten für ein HTML-Client darstellt.

3.5 Die JSF-Tag-Bibliotheken

Um die Funktionalität der Webapplikation zu verlagern, werden Tags definiert, welcheder Seitendesigner in seinem HTML Code einbaut. Damit wird die eigentliche Funk-tionalität nicht auf der Seite, sondern in eine externe Java-Klasse ausgelagert. Die vielbeschriebene JSF-Rollenaufteilung wird damit unter anderem erst möglich. Es bestehtbereits eine große Anzahl von vordefinierten Tags, die in Tag-Bibliotheken mit dem Fra-mework JSF ausgeliefert werden.

Die zwei JSF-Tag-Bibliotheken die mit der Referenzimplementierung von Sun aus-geliefert worden sind: jsf_core und html_basic. In der jsf_core Tag-Bibliothek befindensich Tags, die unabhängig von der jeweiligen Auszeichnungssprache (HTML, XHTML,XML etc.) benutzt werden können. Diese Tags ermöglichen Basisfunktionalitäten wie z.B.Event-Handling und Datenvalidierung. Die html_basic Tag-Bibliothek liefert all jene Tagszu Darstellung der Standart- HTML-Elemente, sowie die Tags, um die UI-Komponentenin einer JSP-Seite zu beschreiben.

Das folgende Code-Fragment zeigt auszugsweise den Aufbau und Umgang mit denTags.

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %><%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>

<html><body>

<f:view><h:form>

<h:outputText value="Username: "/>

<h:inputText id="username"value="#{loginBean.username}"/>

<h:outputText value="Passwort: "/>

<h:inputSecret id="password"value="#{loginBean.password}"/>

<br><br><h:commandButton value="Abschicken>>"

action="#{loginBean.getLoginResult}"actionListener="#{loginBean.login}" />

30


</h:form></f:view>

</body></html>

Damit die JSF-Tag-Bibliotheken benutzt werden können, müssen sie am Anfang einerJSP-Seite mittels einer JSP-Direktive eingebunden werden.

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %><%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>

Das uri-Attribut definiert die Lage der Tag-Bibliothek. Das prefix-Attribut stellt einenNamensraum dar.

<f:view><h:form>...</h:form>

</f:view>

Das <f:view>-Tag leitet den Bereich ein, in dem alle UI-Komponenten beschrieben wer-den. Nur innerhalb des <f:view>-Tag beschriebene UI-Komponenten-Tags, werden derApplikation zugänglich gemacht und sind über den FacesContext und damit über denUI-Komponenten-Baum erreichbar. Die UIForm-Komponente wird in HTML durch das<h:form>-Tag repräsentiert. Innerhalb des Tags können nun UIInput-Komponenten ste-hen.


• id

Das Attribut id identifiziert die Komponente eindeutig.

• value

Das Attribut value bindet den Wert der Komponente an die Property eines Model-Objekts.

Das inputText-Tag definiert eine UIInput-Komponente (Text-Eingabe-Feld) mit denAttributen id und value. Dabei wird durch das Attribut id die Komponente eindeutigidentifiziert. Es dürfen keine zwei Komponenten die gleiche ID haben. Wenn keine ID

31

3.6. MANAGED BEANS

angegeben wird, wird von der JSF-Implementierung eine automatisch vergeben. Durchdas value-Attribut wird der Wert der Komponente, über dem Mechanismus Value Bin-ding Expressions, an die Property eines Model-Objekts (Managed-Bean), gebunden. DerTeil loginBean steht für die referenzierte Managed-Bean und username für das Property.Der Datentyp vom Wert der Komponente und der des Managed-Bean-Property müssenübereinstimmen oder bei nicht Übereinstimmung entsprechend konvertiert werden.

<h:commandButton value="Abschicken>>"action="#{loginBean.getLoginResult}"actionListener="#{loginBean.login}" />

• value

Der Wert des Attributs value bestimmt die clientseitige Beschriftung des Buttons.

• action

Der Wert des Attributs action kann direkt ein String-Wert sein oder wie in unseremBeispiel eine Referenz (Value Binding Expressions) auf eine Managed-Bean (login-Bean) und die darin enthaltende Methode (getLoginResult), die einen String-Wertzurück liefert. Der String-Rückgabewert wird vom NavigationHandler benötigt, umanhand des Navigation-Case (beschrieben in faces-config.xml) die nächste Seite zubestimmen.

• actionListener

Der Wert des Attributs actionListener referenziert eine Methode, über dem Mecha-nismus Method Binding Expressions, die die ActionEvents verarbeiten kann. DieseMethoden enthalten die Funktionalität der UI-Komponenten oder delegieren dieVerarbeitung weiter an andere Instanzen.

Die UICommand-Komponente führt eine Aktion aus, wenn sie aktiviert wird. Das com-mandButton-Tag ist eine Möglichkeit der Darstellung zur Realisierung einer UICommand-Komponente, die Andere wäre die Darstellung als commandLink. Mit dem commandBut-ton-Tag wird in unserem Fall ein Button definiert, mit dem der Benutzer die Möglichkeithat, eine action auszulösen.

3.6 Managed Beans

Die Model-Objekte werden in JavaServer Faces durch Beans realisiert, genauer gesagtdurch Managed-Beans. Eine Managed-Bean besteht dabei aus einer Menge von Proper-ties und Methoden. Die Properties können sich entweder auf Werte von UI-Komponenten

32


oder direkt auf Instanzen dieser Komponenten beziehen. Die Methoden einer Managed-Bean können dabei verarbeitende Aufgaben übernehmen. Das können Aufgaben seinwie die Validierung, das Event Handling und die Vorbereitung der Navigation.

Bevor eine Managed-Bean referenziert werden kann, muss sie in der JSF-Konfigura-tionsdatei faces-config.xml bekannt gemacht werden. Der Aufbau folgt grundsätzlich fol-gendem Schema:

<managed-bean><description>

Die loginBean überprüft das Login.</description><managed-bean-name>loginBean</managed-bean-name><managed-bean-class>

de.itwps.ems.web.bean.EMSBeanLogin</managed-bean-class><managed-bean-scope>request</managed-bean-scope>

</managed-bean>

• <description>

Die <description> enthält eine Beschreibung über das Einsatzgebiet der Managed-Bean. (optional)

• <managed-bean-name>

Der <managed-bean-name> ist ein eindeutiger Identifikator und dient zur Refe-renzierung, innerhalb der JSP-Seiten, einer Managed-Bean.

• <managed-bean-class>

Die <managed-bean-class> gibt den vollständigen Klassenpfad zu der Implemen-tierung der Managed-Bean an.

• <managed-bean-scope>

Hier wird der Scope eingestellt, in der sich die Managed-Bean befinden soll. Zuläs-sige Parameter sind: „request“, „session“, „application“ oder „none“.

Nachdem die Managed-Bean bekannt gemacht worden ist, kann sie zum Managementvon UI-Komponenten eingesetzt werden. Zu klären bleibt: Wie wird die Bindung von UI-Komponenten bzw. deren Wert an Properties der Managed-Bean erreicht und wie wer-den die Methoden einer Managed-Bean über die UI-Komponenten-Tags referenziert.

33

3.6. MANAGED BEANS

Die Bindung von UI-Komponenten bzw. deren Wert an Properties der Managed-Bean,kann auf einer JSP-Seite auf zwei Arten hergestellt werden. Zum einen wird über das bin-dig-Attribut der Tags direkt eine Instanz einer Komponente in der Managed-Bean refe-renziert, zum anderem wird über das value-Attribut der Tags nur der Wert einer Kompo-nente referenziert.


Das Beispiel zeigt, wie der Wert der Komponente value, an die Property username derManaged-Bean loginBean gebunden wird. Man spricht in diesem Zusammenhang auchvom Value Binding Expressions. Alle Bindungen dieser Art haben die allgemeine Formvalue=“#{myBean.myProperty}. Hierbei muss aber entsprechend berücksichtigt werden,dass der Datentyp des Property mit dem Datentyp des Wertes der Komponente über-einstimmt. Bei instanzgebundenen Komponenten ist ein Property, vom Typ der Kom-ponente selbst. Die get()- und set()-Methoden des Property liefern also eine Instanz derKomponente zurück.

Das referenzieren einer Methode einer Managed-Bean über die UI-Komponenten-Tags,wird über den Mechanismus des Method Binding Expressions erreicht. Dabei werdennicht wie beim Value Binding Expressions Propertiers einer Managed-Bean gebunden,sondern ihre Methoden.


Wie schon erwähnt, können die Methoden einer Managed-Bean verschiedene Auf-gaben übernehmen, wie z.B. auch das Event Handling. Mit dem actionListener-Attributwird eine Methode referenziert, die die ActionEvents verarbeiten kann. Die Methode lo-gin der Managed-Bean loginBean wird also dementsprechend aufgerufen, nachdem derBenutzer den Button Abschicken» gedrückt hat. Die Methode soll die Verarbeitung desLogins bewerkstelligen oder zu mindestens an Instanzen delegieren, die die Verarbei-tung übernehmen. Die referenzierte Methode, die ActionEvents verarbeiten kann, hättein unserem Beispiel folgendes aussehen.

public void login(ActionEvent event) {

[...]checkUserAndPassword( getUsername(), getPassword() )[...]

}

34


3.7 Konvertierung

Die Werte, die eine UI-Komponente anzeigen und sofern es sich um eine Input-Kom-ponente handelt, aufnehmen kann, können verknüpft werden über dem MechanismusValue Binding Expressions, mit den Properties der Model-Objekte (Managed-Bean). Da-bei wird unterschieden zwischen dem Datentyp der Property, der benutzt wird, um denWert intern in dem Model-Objekt zu speichern und dem Datentyp, wie der Wert nach au-ßen hin (Bildschirmrepräsentation) repräsentiert wird. Wenn die beiden Datentypen sichunterscheiden, dann müssen die Datentypen entsprechend in beide Richtungen konver-tiert werden.

Um diese Konvertierung zu ermöglichen, können sogenannte Konverter (engl. Con-verter) an den UI-Komponenten registriert werden. Dabei stellt die JSF Implementierungschon eine Reihe von Konvertern, die automatisch eine Konvertierung vornehmen undsomit dem Entwickler eine menge Arbeit im Hintergrund abnehmen. Aber nicht immerreichen die angebotenen Konverter aus und deshalb besteht die Möglichkeit, sie um ei-gene Entwickelte zu erweitern.

Mit dem Interface javax.faces.convert.Converter liefert die JSF-Implementierung eineeinfache Möglichkeit, Konverter zu erzeugen. Alle Konverter müssen dieses Interface im-plementieren. Das Interface definiert die zwei Methoden getAsObject() und getAsString()die von dem Entwickler nur implementiert werden müssen:

• getAsObject()

Diese Methode wandelt den Datentyp, der in der Bildschirmrepräsentation be-nutzt wird, in den Datentyp des Model-Objekt um. Ein Beispiel wäre die Umwand-lung eines Datums. In HTML werden die Werte als String-Werte dargestellt. Die in-terne Repräsentation eines Datums könnte aber auch durch die Klasse java.util.Daterealisiert worden sein. Die Methode getAsObject() wandelt somit den String-Wertder Bildschirmrepräsentation in den Datentyp des Property java.util.Date um.

• getAsString()

Die Methode getAsString() wandelt im Unterschied dazu die Properties eines Model-Objekts in einen String-Wert um. Das heißt für unser Beispiel, das der Datentypjava.util.Date zu einem String-Wert umgewandelt wird. Bei eigenen entwickeltenKonvertern ist die Implementation dieser Methode meist die einfachere.

Nachdem ein eigener Konverter erzeugt wurde, muss er noch bekannt gemacht wer-den für die JSF-Applikation. Dies geschieht in der schon bekannten Konfigurations-Dateifaces-config.xml. Fortan steht der Konverter innerhalb einer JSP-Seite mit dem JSF-CoreTag <f:converter> zur Verfügung und kann an entsprechende UI-Komponenten registriertwerden.

35

3.8. VALIDIERUNG

3.8 Validierung

Bevor die Model-Beans aktualisiert werden können und damit nicht irrtümlich falscheWerte übernommen werden, wurde die Phase der Validierung in den Lebenszyklus derAnfrageverarbeitung aufgenommen. In dieser Phase werden alle Validierungen für UI-Input-Komponenten verarbeitet. Das Framework JSF stellt schon von Haus aus eine Rei-he von Standard-Validierungs-Klassen und Tags bereit. Dabei handelt es sich um Vali-dierungsfälle, wie z.B. ob die Länge einer Eingabe den Anforderungen entspricht oderob überhaupt eine Eingabe vom Benutzer getätigt worden ist. Die Länge einer Eingabez.B. spielt bei der Vergabe von Passwörtern eine entscheidende Rolle und darf aus si-cherheitsrelevanten Gründen nicht zu kurz sein. Das folgende Beispiel zeigt den ebenangesprochenen Validierungsfall.

<h:inputText id="password"value="#{loginBean.password}"required="true">

<f:validateLength minimum="8"/>

Der Benutzer wird aufgefordert ein Passwort einzugeben, das mindestens aus acht Zei-chen besteht. In diesem Beispiel wird eine Standard-Validierungs-Klasse validateLengthbenutzt. Das minimum-Attribut definiert, was die minimale Länge des Eingabe-Stingshaben darf. Durch das required-Attribut des inputText-Tags kann entschieden werden,ob die „Leere“-Eingabe auch eine gültige ist. In unserem Fall bestehen wir auf eine Ein-gabe durch den Benutzer (required=“true“). Demzufolge darf das Eingabefeld nicht leersein.

Wenn Standard-Validierungs-Klassen nicht mehr das gewünschte Funktionsspektrumabdecken, können auch eigene Validierungs-Klassen geschrieben werden. Die Referen-zierung einer eigenen Validierungs-Klasse würde dann wie folgt aussehen.

<h:inputText id="password"value="#{loginBean.password}"required="true">

<f:validator validatorId="PasswordValidator"/>

Mit dem Ausdruck <f:validator validatorId=“PasswordValidator“/> wird der Password-Validator an die UI-Komponente gebunden. Bekannt gemacht werden die eigenen Vali-datoren in der schon vielmals beschriebenen JSF-Konfigurations-Datei faces-config.xml.

<validator><description>Ueberprueft die Laenge des Passwortes</description>

36


<validator-id>PasswordValidator</validator-id><validator-class>

de.itwps.ems.web.validator.PasswordValidator</validator-class>

</validator>

Genau wie bei der Registrierung der eigenen Konverter, werden auch die Validatoreninnerhalb der JSF-Konfigurations-Datei bekannt gemacht. Die dem entsprechende Klas-se PasswordValidator sieht dann wie folgt aus.

public class PasswordValidator implements Validator {

public void validate( FacesContext context,UIComponent component,Object value)throws ValidatorException {

String stringValue = (String) value;int laengeDerEingabe = stringValue.length();

if ( laengeDerEingabe < 8 ) {

FacesMessage message = new FacesMessage("Die von ihnen gewählten länge des Passwortes ist zu kurz...");

throw new ValidatorException(message);}else {

//ok}

}}

Eigene Validierungs-Klassen müssen nur das Interface Validator mit der Methode va-lidate implementieren. Die Variable value vom Typ Object liefert uns die Eingabe desPasswortes. Dieser Datentyp Object wird zunächst in einem String-Wert umgewandeltund dessen Länge wird bestimmt. Anhand des Entscheidungsfalls wird die eigentlicheÜberprüfung, ob das Passwort mindestens aus acht Zeichen besteht, entschieden. Wenndas Passwort aus acht oder mehr Zeichen besteht, ist die Eingabe korrekt und es mussnichts weiter passieren. Ist die Eingabe-Länge des Passwortes kleiner als acht Zeichen,

37

3.9. EVENTHANDLING

wird eine Fehler-Message (FacesMessage) erzeugt, die dann durch eine ValidatorExcep-tion weitergereicht wird. Diese message kann dem Benutzer auf der JSP-Seite angezeigtwerden, der dann dementsprechend reagieren kann.

3.9 Eventhandling

Benutzer können grundsätzlich Aktionen (Events) an UI-Komponenten auslösen, die inirgendeiner Form verarbeitet werden müssen. Damit eine Applikation über diese Eventsinformiert werden kann, werden sogenannte Listener an die UI-Komponenten registriert.Es gibt in JavaServer Faces zwei Arten von Events, die ausgelöst werden können: ActionE-vents und ValueChangeEvents. Beide Events sind von der Klasse FacesEvent abgeleitet.Es existiert aber noch eine andere Klasse neben FacesEvent, die Klasse PhaseEvents. DerLebenszyklus der Anfrageverarbeitung besteht aus einzelnen Phasen, die immer wiederdurch Event-Verarbeitung unterbrochen werden. Die PhaseEvents werden genau nachAbarbeitung einer Phase ausgelöst bzw. versendet. Ein Entwickler, der sich diese Pha-seEvents zu nutze machen will, kann dies durch die Implementierung des PhaseListenersund dessen Registrierung in der JSF-Konfigurations-Datei faces-config.xml erreichen.

Die angesprochenen ActionEvents werden von zwei UI-Komponenten-Tags des HTMLRenderKit der Referenzimplementierung unterstützt: commandLink und commandBut-ton. Beide Komponenten sind vom Typ UICommand. Die ValueChangeEvents könnenvon allen UIInput-Komponenten ausgelöst werden. Dies ist möglich, weil alle UIInput-Komponenten und davon abgeleitete Klassen, das Interface EditableValueHolder imple-mentieren müssen. ValueChangeEvents werden immer dann ausgelöst, wenn sich derWert einer UIInput-Komponenten durch den Benutzer geändert hat. Die Registrierunginnerhalb einer JSP-Seite geschieht durch das schon bekannte Attribut actionListener,welches innerhalb der Komponenten-Tags benutzt wird.

actionListener="#{myBean.myMethod}"

Es gibt zwei Varianten, Events in einer JSF-Applikation zu verarbeiten. Die erste Va-riante registriert eigene Listener-Klassen an den UI-Komponenten. Die zweite Varian-te bindet eine UI-Komponente per Method Binding Expressions an eine Methode einerManaged-Bean, die die Verarbeitung übernimmt.

Eine referenzierte Methode müsste z.B. um das ActionEvent per Method Binding Ex-pressions verarbeiten zu können, die Form besitzen:

public void methodenName{ActionEvent event}{

//Event-Verarbeitung}

38


Die Implementierung des Interfaces ActionListener und der einzigen Methode action-Performd einer eigenen entwickelten Listener-Klasse, würde wie folgt aussehen:

public class myActionListener implements ActionListener{

public void actionPerformed(ActionEvent event)throws AbortProcessingException{

//Event-Verarbeitung}

}

3.10 Das Navigations-Modell

Die Navigation, das heißt die Auswahl der anzuzeigenden Seiten innerhalb einer JSF-Applikation, wird standardmäßig durch den NavigationHandler geregelt. Abhängig istdie Navigation dabei von mehreren Faktoren.

Angestoßen wird die Navigation letztendlich vom Benutzer, durch Auslösen eines Ac-tionEvents auf einer JSP-Seite. Nehmen wir an, der Benutzer drückt einen Button undbeendet dadurch die Eingabe eines Formulares. Das Formular könnte eine Eingabe vomBenutzer verlangt haben, wie z.B. den Benutzernamen und das Passwort.


Durch das Drücken des Buttons Abschicken» wird die Methode login der Managed-Bean loginBean benachrichtigt über das ActionEvent. Diese Methode kann dementspre-chend auf die action reagieren und das „Login“ verarbeiten. Entscheidend nach der Ver-arbeitung ist das Resultat der Überprüfung des Logins. Die Überprüfung kann dabei gül-tig („erfolgreich“) oder ungültig („misserfolg“) sein. Das Resultat der Überprüfung derMethode login wird als String-Wert („erfolgreich“ oder „misserfolg“) in dem Property lo-ginResult der loginBean gespeichert.

public void login(ActionEvent event) {

if ( checkUserAndPassword( getUsername(), getPassword() ){

setLoginResult("erfolgreich"); \\Login ok

39

3.10. DAS NAVIGATIONS-MODELL

}else{

setLoginResult("misserfolg"); \\Login falsch}

}

Über das action-Attribut des commandButton-Tag wird nach der Verarbeitung desEvents der String-Rückgabewert dem NavigationHandler übergeben. Der NavigationHand-ler hat jetzt alles was er braucht. Anhand der aktuellen Seite, dem String-Rückgabewertund den Navigations-Regeln (beschrieben in der JSF-Konfigurationsdatei faces-config.xml)kann der NavigationHandler die nächste anzuzeigende Seite bestimmen.

<navigation-rule><description>

Was soll nach der Anmeldung passieren? (erfolgreich/misserfolg)</description><from-view-id>/login.jsp</from-view-id>

<navigation-case><description>

Anmeldung erfolgreich, weiter mit der Seite willkommen.jsp</description><from-outcome>erfolgreich</from-outcome><to-view-id>/willkommen.jsp</to-view-id>

</navigation-case>

<navigation-case><description>

Anmeldung fehlgeschlagen, weiter mit der Seite loginFalsch.jsp</description><from-outcome>misserfolg</from-outcome><to-view-id>/loginFalsch.jsp</to-view-id>

</navigation-case></navigation-rule>

• <navigation-rule>

Das <navigation-rule>-Element definiert die Regel für ein Navigations-Fall. Inner-halb der faces-config.xml können beliebig viele Navigations-Fälle definiert werden.

• <from-view-id>

40


Dieses Element kennzeichnet, auf welche Seite sich diese Navigations-Regel be-zieht. In unserem Fall ist es die login.jsp-Seite. Wenn das Element nicht angegebenist, so gelten die Navigations-Regeln global für die gesamte Applikation.

• <navigation-case>

Die <navigation-case>-Elemente sind die einzelnen Navigationsfälle, die unterschie-den werden sollen. Entscheidend für ein Navigations-Fall ist der Rückgabewert desNaigationHandler. Ist dieser String-Wert gleich dem der unter dem <from-outcome>-Element beschriebenen, dann wird dieser Navigations-Fall angewandt. Die dannzu bestimmende Seite für diesen Navigations-Fall, wird mit dem <to-view-id>-Ele-ment angezeigt.

Die Navigation würde, angewandt auf unser Beispiel, auf einen String-Rückgabewertvon „erfolgreich“ mit dem Aufruf der nächsten Seite willkommen.jsp reagieren.

3.11 Lokalisierung

Die Lokalisierung befasst sich mit der Anpassung einer Applikation an die verschiedenenSprachen oder Kulturen. Dabei sollte die Lokalisierung schon im Vorfeld der Entwicklungbedacht werden, weil fest kodierte Sprachelemente in einer Applikation, später meist nurmit enormen Aufwand wieder geändert werden können. Ein Großteil der Lokalisierungbeschäftigt sich mit der Übersetzung der Ausgabe einer Applikation in die gewünschteSprache. Das Framework JSF unterstützt die Lokalisierung und setzt sie mit sogenanntenResourceBundles um.

Beim den ResourceBundles handelt es sich um zentrale Text-Dateien, die nach demkey=Value-Schema aufgebaut sind. Der Aufbau der Dateibezeichnung folgt dem Schemaresources_xx.properties. Für die Variable xx stehen dann die verschiedenen Abkürzungenfür die verschiedenen Sprachen, wie deutsch (de), englisch (en) usw. und für resourcesder Name des Bundles.

# resources_de.propertiesuserNameField=BenutzernamepasswordField=PasswortloginButton=Login[...]

Jedem Schlüssel-Wort ist genau ein String der jeweiligen Sprache zugeordnet, der beiVerwendung in der Bildschirmrepräsentation erscheint. Die Referenzierung des Resour-ceBundles in der JSP-Seite geschieht über das <f:load-Bundle>-Tag. Das Tag lädt die pas-senden Ressourcen für die aktuell eingestellte Sprache Automatisch.

41

3.11. LOKALISIERUNG

FacesContext.getCurrentInstance().getViewRoot().setLocale(Local.GERMAN)

Die Sprach-Einstellungen können natürlich auch entsprechend geändert werden. Die-se Anweisung würde die Sprach-Einstellungen auf deutsch setzen.

<f:loadBundle basename="de.pixxi.resources" var="messages"

Das Laden des ResourceBundle geschieht über das basename-Attribut und beziehtsich auf die Dateien resources des ResourceBundles, die sich im Verzeichnis de.pixxi desKlassenpfads befinden müssen. Das var-Attribut definiert einen Namensraum innerhalbder JSP-Seite, mit dem dann der Zugriff möglich ist.

<h:outputText value="#{messages.userNameField}"/>

Der Ausdruck #{messages.userNameField} referenziert über den Mechanismus ValueBinding Expression den String-Wert, der unter dem Schlüssel-Wort userNameField zu fin-den ist. Im unseren Beispiel würde die UI-Komponente outputText eine Beschriftung mitdem String „Benutzername“ bekommen.

42

4 Das Equipment ManagementSystem

Das „Equipment Management System (EMS)“ ist ein Tool zur Organisation von Gerä-ten, Mitarbeitern und Raumplänen (Räumen). Mögliches gedachtes Einsatzgebiet wardie Verteilung und Verwaltung der Ressourcen unseres Uni-Fachbereiches. Das Tool solldie vorhandenen Ressourcen durch Organisation der Mitarbeiter effektiv einsetzten. DasEMS stellt hierbei nicht den Anspruch eines real eingesetzten Systems. Es dient vielmehrals ein größeres Beispiel zur Erklärung der Konzepte des Handbuches „Object-OrientedSoftware Construction Handbook - Developing Application-Oriented Software with theTools & Materials Approach“1.

Entwickelt worden ist das „Equipment Management System (EMS)“ von der C1 WPSGmbH2 in Zusammenarbeit mit der Uni Hamburg. In diesem Projekt wurde gezielt aufdie Zusammenarbeit zwischen Studenten und erfahrenden Entwicklern geachtet.

4.1 Einführung

Dieser Teil der Studienarbeit ist im Rahmen des Projektes „Objektorientierte Softwa-reentwicklung“ am Fachbereich Softwaretechnik der Universität Hamburg entstanden.Lernziele dieses 2 Semester dauernden Projektes waren neben der Einarbeitung in fun-damentale Methoden und Techniken der objektorientierten Konstruktion, auch die Ein-arbeitung, Erweiterung und das Refactoring einer schon bestehenden Anwendung, wiedas „Equipment Management System“.

Der Schwerpunkt meiner Person an diesem Projekt war, die Möglichkeit einzuschät-zen, inwieweit sich die Client-Server Architektur des EMS eignet, die Steuerung auchüber andere Benutzeroberfächen bzw. Präsentationsarten abzuwickeln. Bisher war diesnur möglich mittels der GUI-Swing Benutzeroberfläche. Damit war die komplette Ge-schäfts- und Präsentationslogik im Client vereint.

Im Rahmen dieser Studienarbeit wurde deshalb von mir ein browserbasierter Cliententwickelt. Im Hinblick auf die Entwicklung des Clients, wird uns das WEB-Framework -

1(vgl. Zül05)2C1 WPS Workplace Solutions Gesellschaft für DV-Beratung mbH

43

4.2. EMS - SZENARIEN

JaverServer Faces die Architektur liefern. Die Client-seitigen Zugriffe erfolgen dann durcheinen Webbrowser.

Im Folgenden soll nun das EMS vorgestellt werden. Hierbei wird besonders auf dieverschiedenen Szenarien des EMS eingegangen. Sie sollen ein Gefühl für die Funktions-weise und das Verhalten des EMS vermitteln. Es folgt dann eine Beschreibung der Ar-chitektur des EMS. Zu berücksichtigen ist, das im Rahmen dieser Studienarbeit es mirnicht möglich war, alle Aspekte des Systems komplett zu beschreiben. Viele Beschrei-bungen werden sich vielmehr nur auf die Teile stützen, die von mir bearbeitet wordensind. Abgeschlossen wird dieses Kapitel, am Beispiel des employee editor-Tool, das zeigt,wie meine Realisierung und Umsetzung eines Tools des EMS aussieht.

4.2 EMS - Szenarien

Die Szenarien beschreiben die Aufgaben, Eigenschaften und das Verhalten des Equip-ment Management System. Dabei soll kurz auf die Funktionen der einzelnen Kompo-nenten eingegangen werden, sowie eine kurze Erklärung zu den einzelnen Tools.

4.2.1 Die zentralen Aufgaben des Equipment ManagementSystem

Bevor ein Benutzer das Equipment Management System benutzen kann, wird er gebe-ten, seinen Benutzernamen und Passwort einzugeben. Bei erfolgreichen Login kann der„equipment Manager“ (Benutzer) das System nutzen. Er hat nun die Möglichkeit, dieGeräte (Rechner), Mitarbeiter und Räume zu Verwalten bzw. zu organisieren.

Dem Benutzer präsentiert sich eine Benutzeroberfläche (Workbench), die in verschie-dene Segmente unterteilt ist. Die unterschiedlichen Segmente sind der Local Desktop,die Registry, die Toolbox, der Shredder und verschiedene Buttons zur Steuerung. Zu demkommt noch eine Menü-Leiste, die viele Aktionen bietet wie z.B. das Ändern des Benut-zers oder die des Schrifttyps. Die Abbildung 4.1 zeigt eine Ansicht auf die Benutzerober-fläche des EMS.

• Local Desktop

Auf der linken Seite der Benutzeroberfläche, innerhalb des Local Desktop (materialbox) werden alle „lokalen“ Materialien angezeigt. Das sind jene Materialien, diesich mit den verschiedenen Tools der Toolbox bearbeiten lassen.

44

KAPITEL 4. DAS EQUIPMENT MANAGEMENT SYSTEM

Abbildung 4.1: Die Benutzeroberfläche des EMS

• Registry

Auf der rechten Seite befindet sich die remote material box, genannt Registry. DieRegistry zeigt dem Benutzer alle Materialien an, die sich in der Registratur befin-den. Die Registratur speichert die Materialen auf der Server-Seite und abstrahiertvon diesem Prozeß. Die Umsetzung der Speicherung der Materialien bleibt demClient verborgen. Dies kann sowohl als Flat-File als auch in einer Datenbank mitJDO-Anbindung geschehen.

Um ein Material bearbeiten zu können, muss der Benutzer dieses Material zuerstaus der Registry „auschecken“ in den lokalen Bereich (Local Desktop). Änderun-gen am Material bleiben solange lokal, bis das Material wieder in die Registry „ein-gecheckt“ worden ist. Wenn ein Material „ausgecheckt“ wird, verbleibt an seinerStelle eine „MissingCard“ in der Registry, das anderen Benutzern anzeigt, das die-ses Material gerade bearbeitet wird.

• Toolbox

In der Toolbox werden alle Tools angezeigt, mit denen der Benutzer die Materia-len bearbeiten kann. Dem Benutzer stehen folgende Tools zur Verfügung: Kopier-Materialen (copying materials), Editiere-Geräte (Editing a device), Editiere-Raum-pläne (Editing room maps), Erzeuge-Raumpläne (RoomMap Designer), Editiere-Mitarbeiter (Editing an employee) und Erzeuge-Werte (Value Definer).

45

4.2. EMS - SZENARIEN

• Shredder

Mit dem Shredder ist es möglich, nicht mehr brauchbare Materialien zu löschen.Wird ein Material aus dem lokalen Bereich heraus gelöscht und wurde noch nie„eingecheckt“, können die lokalen Änderungen verworfen werden. Wird hingegenein Material aus dem Registry-Bereich gelöscht, wird es komplett gelöscht.

Das erzeugen von neuen Materialien und ändern dieser, ist eine der zentralen Aufga-ben, die die EMS-Tools unterstützten. Auf die Funktionsweise der Tools soll im folgendennoch genauer eingegangen werden.

4.2.2 Editiere-Geräte (Editing a device)

Der Benutzer kann ein Material vom Typ device zur Bearbeitung öffnen, durch Dop-pelklick auf dessen Symbol oder durch ziehen des Symbols auf das entsprechende Tool inder Tool-Box. Die Tools sind selber in der Lage zu entscheiden, ob sie das entsprechendeMaterial bearbeiten können. Das device editor-Tool kann z.B. nur Materialien vom Typdevices verarbeiten. Mit diesem Tool besteht die Möglichkeit devices zu editieren und zuerzeugen. Wird ein neues device erzeugt, wird auch sichergestellt, dass es einen eindeu-tigen Namen erhält. Die devices definieren Attribute bzw. Eigenschaften (Werte einer Ei-genschaft) wie z.B. einen Device-Status (in Plannung, bestellt, im Bestand), eine Device-Klasse (Low End, Inermediate, High End), ein Datum der Inbetriebnahme(01.06.06), einDatum des letzten Upgrades (01.12.06) und eine Beschreibung (Description).

4.2.3 Editiere-Raumpläne (Editing room maps)

Der Benutzer hat mit dem room map designer-Tool die Möglichkeit room maps anzule-gen und zu ändern. Über die Option „Edit Room Map Properties“ kann der Benutzer Ein-fluss nehmen auf die Größe sowie auf den Namen der room map. Innerhalb einer roommap können nun neue Räume (rooms) mit der Option New Room angelegt werden. DieRäume können dann entsprechend mit Geräten (devices) und Mitarbeitern (Members)belegt werden.

4.2.4 Editiere-Mitarbeiter (Editing an employee)

Ein Mitarbeiter wird über das employee editor-Tool geöffnet. Wie die vorherigen Toolsauch, dient dieses Tool der Erzeugung und Änderung. Das employee editor-Tool kannnur von Materialen vom Typ employee verarbeiten. Das Tool definiert Eigenschaften ei-nes Mitarbeiters wie Vorname, Nachname, Anschrift, E-mail, Telefonnummer, Tag derEinstellung und Position (Manager, Team Member). Nach Beendigung der Änderungen

46


kann der Benutzer durch drücken des save-Button die Angaben abspeichern. Ist der an-gelegte Mitarbeiter noch nicht vorhanden, wird er dem Local Desktop hinzugefügt.

4.2.5 Weitere Tools

Es gibt noch eine Reihe weiterer Tools, die im Rahmen dieser Arbeit nicht weiter be-schrieben werden können, aber der Vollständigkeit halber, noch kurz erwähnt werdensollen. Zu dem zählen die Tools: Copying materials vervielfältigt ein ausgewähltes Mate-rial, Value Definer erstellt eindeutige Werte für die Gerätebezeichnungen, Device Organi-zer können die Geräte auf die verschiedenen Räume verteilt werden.

4.3 Die Architektur des EMS

Hauptkomponente und zentrale Anlaufstelle des EMS ist das Workbench-Tool. Sie bein-haltet den Local Desktop (MaterialBox), die Registry (RemoteMaterialBox), die ToolBoxund den Shredder. Innerhalb der ToolBox befinden sich alle angemeldeten und regis-trierten Tools.

Abbildung 4.2: Basis-Struktur der Benutzer-Interface-Komponenten des EMS

47

4.3. DIE ARCHITEKTUR DES EMS

Die Abbildung 4.2 zeigt die Basis-Struktur der Benutzer Interface Komponenten desEquipment Management System, nachdem das System abgemeldet und initialisiert wor-den ist.3 Zu beachten ist, dass die Abbildung keine Materialien enthält. Die Pfeile inner-halb der Abbildung zeigen eine contains relationships. Die meisten Elemente in dieserAbbildung sind Tools, folglich wurden die Tools nach ihrer korrespondierenden Klassebenannt. Die RegistryServices-Komponente beschreibt die sechs verschiedenen services,die von der RemoteMaterialBox genutzt werden: RegistryService, RegistryServiceFile, Re-gistryServiceJDO, RegistryServiceListener, RegistryServiceProxy and RegistryServiceSer-ver. Diese service-Architektur hat den Vorteil, dass die Speicherung der Materialien aufder Server-Seite unabhängig und verborgen vom Client durchgeführt werden können.Somit kann die Art der Speicherung (Flat-file bzw. JDO) flexibel ausgetauscht werden,ohne am Client große Änderungen vornehmen zu müssen.

Die Abbildung 4.3 zeigt die Abhängigkeiten von Tools und Materialen.4 Sie lässt be-wusst die service-Architektur außen vor. Die Pfeile beschreiben eine „works on“ relation-ship.

Abbildung 4.3: Die „works on“ relationship von Tools und Materialen

3(vgl. wps07a)4(vgl. wps07a)

48


4.4 Das Employee-Tool

Dieser Abschnitt beschreibt die Umsetzung und Realisierung des Employee-Tool. Bevordas Employee-Tool benutzt werden kann, muss ein Systemzustand geschaffen werden,indem das EMS arbeitsfähig ist. Arbeitsfähig ist das EMS und damit bereit für die Be-nutzeraktionen, wenn alle Initialisierungen abgeschlossen sind und die Workbench aufMethodenaufrufe reagieren kann. Um diesen Systemzustand zu schaffen, muss sich derBenutzer vorerst einmal anmelden.

4.4.1 Ausgangssituation

Diese Ausgangssituation stellt sich wie folgt dar. Ein Benutzer meldet sich mit seinem Be-nutzernamen und Passwort an. Es folgen jetzt eine Reihe von Verarbeitungsschritten, diedas EMS in einen Zustand versetzen soll, mit dem es möglich ist, über die Workbench.jsp-Seite (View) das EMS als Benutzeroberfläche zu steuern. Hierzu werden, wie auch schonin den vorangegangenen Abschnitten ausführlich beschrieben, alle UI-Komponentender Workbench.jsp-Seite mit den entsprechenden WorkbenchBean-Methoden (Model)assoziert.

Da die Workbench des EMS-Clients die komplette Funktionalität des Systems schonenthält, soll das Ziel sein, diese auch weiterhin zu nutzen. Hierzu werden alle Action-Methoden-Aufrufe innerhalb der WorkbenchBean weitergereicht, an die „echte“ Work-bench. Die Verarbeitung der Funktionalität wird demnach nicht im Model (Workbench-Bean) abgearbeitet, sondern über ein EMSController-Objekt an die Workbench des EMSweitergereicht. Die Methoden der Workbench des EMS müssen hierfür natürlich dement-sprechend angepasst werden.

Die Abbildung 4.4 zeigt den Verlauf der Anmeldung eines Benutzers, bis hin zu demPunkt, an dem die Workbench des EMS einsatzbereit ist, um Methoden-Aufrufe vom derWorkbenchBean bzw. des EMSControllers entgegen nehmen zu können.

1. Der HTML-Client sendet ein Request an die Login.jsp. Auf dieser Seite kann derBenutzer seinen Benutzernamen und das Passwort eintragen.

2. Durch das bestätigen des Login-Button wird die Eingabe abgeschlossen und vonder Action-Methode public void login(ActionEvent event) der LoginBean verarbei-tet. Ist die Verifizierung fehlgeschlagen (false), so wird der Benutzer darauf hinge-wiesen und muss die Eingabe nochmal vornehmen.

3. Der Benutzer wurde erfolgreich verifiziert. Die EMSAdmin-Klasse ist die zentra-le Verwaltung für den Anmelde-Mechanismus. Sie ist als static implementiert undkann somit von allen Klassen aufgerufen werden.

49

4.4. DAS EMPLOYEE-TOOL

Abbildung 4.4: Der Anmelde-Mechanismus der Workbench (EMS)

4. Wenn ein Benutzer sich erfolgreich angemeldet hat, wird ein neuer WebUser ange-legt, der alle Attribute des Benutzers aufnimmt.

5. Jeder WebUser bekommt ein Conntroller-Objekt, das später als Vermittler zwischender WorkbenchBean und der Workbench des EMS fungieren soll. Hierzu verwalteter die Referenz der Workbench des EMS.

6. Der EMSController startet den EMSClient in einem eigenem Thread. Dieser EM-SClient startet unabhängig seine Initialisierung und stellt die Verbindung mit demEMSServer her.

7. Im verlauf der Initialisierung des EMSClient ist die Workbench soweit fortgeschrit-ten, dass sie sich bei der zentralen EMSAdmin registrieren kann.

8. Die EMSAdmin übergibt die Referenz der Workbench an das entsprechende EMS-

50


Controller-Objekt. Dieses verwaltet fortan diese Referenz, um spätere Methoden-Aufrufe von der WorkbenchBean weiter leiten zu können.

9. Nachdem der EMS-Client seine Initialisierung abgeschlossen und das EMSCon-troller-Objekt seine Referenz bekommen hat, wird der String-Wert („erfolg“) anden NavigationHandler weitergegeben. Der NavigationHandler bestimmt anhanddes Navigation-Case, beschrieben in der JSF-Konfigurations-Datei (faces-config.xml),die nächste aufzurufende Seite.

10. Der Navigationsfall verweist bei einem erfolgreichen „Login“ auf die Workbench.jsp-Seite.

11. Durch den Aufruf der Workbench.jsp wird im diesem Kontext die WorkbenchBe-an initialisiert. Diese erfragt bei der zentralen EMSAdmin, welches EMSController-Objekt für sie zuständig ist.

12. Fortan kann die Verarbeitung der Action-Methoden an das EMSController-Objektweiter gereicht werden.

13. Das EMSController-Objekt leitet dann wiederum die Verarbeitung an die Metho-den der Workbench weiter, die dann letztendlich die eigentliche Funktionalität ent-halten.

4.4.2 Umsetzung und Realisierung

Nachdem wir die Ausgangslage geschaffen haben, kann der Benutzer das EMS über dieUI-Komponenten der Workbench.jsp-Seite „steuern“. In diesem Abschnitt wird die Um-setzung und Realisierung des Employee-Tool beschrieben. Ausgegangen wird von folgen-der Situation: Ein Employee (initialen RT) wurde aus der Registry (remote material box)„ausgecheckt“ und befindet sich im Local Desktop (material box). Die Abbildung 4.5 zeigtdie Ausgangslage.

Die Bearbeitung des Employee wird gestartet, durch das Drücken des „CommandLink-Edit“.

<h:commandLink id="Edit"action="edit"actionListener="#{editBean.edit}">

<h:outputText value="Edit" /><f:param id="editThingDescriptionDV"

name="thingDescriptionDV"value="#{localObj.thingDescriptionDV}" />

</h:commandLink>

51


Abbildung 4.5: Der Employee (RT) ist bereit zur Bearbeitung.

Der „CommandLink-Edit“ ist verbunden mit der Action-Methode edit innerhalb dereditBean.

public void edit(ActionEvent event){

UIParameter component = (UIParameter)event.getComponent().findComponent("editThingDescriptionDV");

ThingDescriptionDV thingDescriptionDV = (ThingDescriptionDV)component.getValue();

employee = emsController.getEmployeeForEdit(thingDescriptionDV);

this.setEditBean(employee);}

Damit wir das Material Employee überhaupt bearbeiten können, müssen wir zunächsteinmal das Material aus der MaterialBox (Lokal) auslesen. Ziel ist es, die „EditBean“ mitden Attributen eines Employee zu füllen. Die EditBean definiert genau die Attribute, dieein Employee besitzen kann. Die EditBean ist somit das Model-Objekt für die emsEdit.jsp-Seite, die die View-Komponente darstellt.

52


UIParameter component = (UIParameter)event.getComponent().findComponent("editThingDescriptionDV");

Als erstes wird die Komponente identifiziert, über die der Benutzer das Event ausgelösthat, mittels des Parameters „editThingDescriptionDV“. Die UI-Komponente ist über dasTag <f:param id=“editThingDescriptionDV“ identifizierbar.

ThingDescriptionDV thingDescriptionDV = (ThingDescriptionDV)component.getValue();

Der Aufruf component.getValue() bezieht sich demnach auf den Wert der Komponen-te, der unter dem Tag <f:param value angegeben ist. Das value-Attribut verweist auf dieLokalen-Objekte und dessen Attribut .thingDescriptionDV.

employee = emsController.getEmployeeForEdit(thingDescriptionDV);

Jedes Material (Employee) hat eine Beschreibung vom Typ ThingDescriptionDV. Mitdieser ThingDescriptionDV ist es uns möglich, den Employee aus der MaterialBox derWorkbench auszulesen.

this.setEditBean(employee);

Der übergebene „employee“ wird mittels der Methode this.setEditBean(employee) demModel-Objekt EditBean zugewiesen. Nachdem das Model-Objekt mit den Attributen desEmployee initialisiert worden ist, kann die JSP-Seite emsEdit.jsp zur Bearbeitung aufge-rufen werden. Die Abbildung 4.6 zeigt die emsEdit.jsp-Seite.

Der Benutzer hat nun die Möglichkeit den Employee zu bearbeiten. Dabei wird dieEingabe, wie z.B. die des „HiringDate“ wie im Beispiel zu sehen, schon auf seine „Rich-tigkeit“ überprüft. Das Beispiel zeigt die Eingabe eines Monats (13), der nicht von dem„MonthValidator“ akzeptiert worden ist. Die entsprechende Fehlermeldung wird in der„Error Messages Box“ ausgegeben.

53


Abbildung 4.6: Die emsEdit.jsp

public class MonthValidator implements Validator {

public void validate( FacesContext context,UIComponent component,Object value)throws ValidatorException {

int intValue = (Integer) value;

if ( (intValue < 1) | (intValue > 12) ) {FacesMessage message = new FacesMessage("Die Benutzereingabe des" +

"von Ihnen gewählten Monats ist falsch! Bitte beachten Sie, " +"dass der von Ihnen gewählte Wert im Intervall von 1 - 12 " +"bleibt und das ganze Datum im Format dd.mm.yyyy " +"gehalten wird."

);throw new ValidatorException(message);

}else {

//ok

54


}}

}

Nachdem der Benutzer seine Eingaben vervollständigt hat, kann er die Änderungen„verwerfen“ oder „speichern“. Durch drücken des save-Button werden die aktuellen Pro-perties von der View in den Employee gespeichert und der Employee wird danach wiederin die lokale Registry „eingecheckt“.

In diesem Beispiel wurde die Umsetzung und Realisierung eines Tools des EMS aus-zugsweise verdeutlicht. Im Rahmen dieser Studienarbeit war es leider nicht möglich,alle beteiligten Komponenten (Klassen und Methoden) komplett aufzuzeigen. Beteilig-te Komponenten, wie z.B. die Konfigurationsdateien oder Validatoren, wurden aber zu-mindest schon in vorangegangenen Abschnitten erläutert. Es bleibt festzuhalten, dass esmöglich ist, mit dem HTML-Client das EMS zu steuern.

55

5 Zusammenfassung, Bewertungund Ausblick

In dieser Studienarbeit wurde erfolgreich das JavaServer Faces - Framework für die Ent-wicklung eines browserbasierten Client Front-End für das Equipment Management Sys-tem erprobt. Dabei stellte sich heraus, dass das User-Interface Framework - JavaSer-ver Faces das Erstellen von Web-Anwendungen mit Java vereinfacht. Es ist möglich, dasJSF-Framework so zu erweitern, dass ein HTML-Client auf der Präsentationsebene dasEquipment Management System bedient. Dies ist unter anderem der Verdienst des JSF-Frameworks, dass durch seine klaren Strukturen nicht zu komplex und somit leicht er-lernbar ist. Die robuste und vielfältig konfigurierbare Softwarearchitektur nimmt dabeidem Entwickler viel Arbeit ab. Die Trennung von Model, View und Controller ermöglichtein rollenbasiertes Entwickeln einer Web-Anwendung. Die individuellen Fähigkeiten derEntwickler können so optimal im jeweiligen Fachgebiet (Page Autoren, Application De-veloper und Component Writer) eingesetzt werden. Der zumeist höhere Einarbeitungs-aufwand in die Strukturen und das Verhalten, macht sich aber nach Meinung des Autorsdurch kürzere Entwicklungszeiten meist schnell bezahlt.

In dieser Studienarbeit wurden in Kapitel 2 viele relevante Punkte angesprochen, diesich mit dem Aufbau von Web-Architekturen beschäftigten. Es wurden ausführlich dieJ2EE-Sichten-Architektur und das MVC-Paradigma beschrieben. Des weiteren wurde aufdie beteiligten Technologien Java Server Pages, Servlet und Applikationsserver eingegan-gen. Das Kapitel 3 stellte das JSF-Framework selber ausführlich vor. Dabei ging es um diesehr vielfältigen Konfigurations-Möglichkeiten einer JSF-Anwendung. Es wurde nebender Implementierung des Fachkonzepts, auch die vielen Gestaltungsmöglichkeiten ei-ner Benutzeroberfläche vorgestellt. Die Umsetzung und Realisierung des Employee-Toolwurde von mir im Kapitel 4 aufgezeigt. Die Realisierung konnte dabei im Rahmen dieserStudienarbeit leider nicht alle gewünschten Aspekte aufzeigen und umsetzen.

Die Implementierung des Web-Clients kann in einer weiterführenden Betrachtung sofortgesetzt werden, so das auch die anderen Tools noch weiter umgesetzt werden kön-nen. Zu wünschen wäre auch die Umsetzung des Konzepts, die auch die parallele Ver-arbeitung mehrerer Clients zulässt und damit das Projekt zu einer „richtigen“ Client-Server Architektur wachsen lässt. Dies war mir leider aus strukturbedingten Vorgabendes Equipment Management System nicht möglich. Des weiteren wäre wünschenswert,das Design der Benutzeroberfläche des HTML-Clients mit Hilfe von „Style Sheets“ noch

56

KAPITEL 5. ZUSAMMENFASSUNG, BEWERTUNG UND AUSBLICK

weiter zu verfeinern oder es mit anderen Auszeichnungssprachen wie z.B. WML zu im-plementieren.

57

A Anhang

Sämtlicher im Rahmen dieser Studienarbeit entstandener Quellcode ist auf der beige-legten CD vorhanden. Der Quellcode für das EMS wurde der Workbench der Eclipse-Programmierumgebung entnommen.

• EMS-Projekt

Das EMS-Projekt befindet sich im Verzeichnis: workspace/XEMSweb/source/de/it-wps/ems

• Web-Komponenten

Die Web-Komponenten (EMSAdmin, EMSController, WEBUser) befindet sich imVerzeichnis: workspace/XEMSweb/source/de/itwps/ems/web

• Beans

Die Beans befindet sich im Verzeichnis: workspace/XEMSweb/source/de/itwps/ems/web/bean

• Converter

Die Converter befindet sich im Verzeichnis: workspace/XEMSweb/source/de/itwps/ems/web/converter

• Validator

Die Validatoren befindet sich im Verzeichnis: workspace/XEMSweb/source/de/itwps/ems/web/validator

• Die JSP-Seiten

Die JSP-Seiten befindet sich im Verzeichnis: workspace/XEMSweb/WebRoot

• faces-config.xml + web.xml

Diese Dateien befinden sich im Verzeichnis: workspace/XEMSweb/WebRoot/WEB-INF

Zusätzlich wurde das Deployment des Projekts als WAR-Datei beigelegt. Ausgeführtwurde es mit dem JBoss Applikationsserver. Das Deployment befindet sich auf der CDim Verzeichnis: deploy/XEMSweb.war

58

B Literaturverzeichnis

[Ber01] BERGSTEN, Hans: JaverServer Pages: Deutsche Übersetzung von Jörg Staude-meyer. O´Reilly, 2001

[Ber04] BERGSTEN, Hans: JavaServer Faces: Building Web-based User Interfaces.O´Reilly, 2004

[Bor07] BORLAND: 3-Schichten-Architektur. Website. 2007. – http://info.borland.com/techpubs/jbuilder/jbuilder2005/j2eeapps/j2ee_programming.html

[Bos04] BOSCH, Andy: Java Server Faces: Das Standard-Framework zum Aufbau web-basierter Anwendungen. Addison-Wesley, 2004

[Fou07a] FOUNDATION, Apache S.: Apache Geronimo. Website. 2007. – http://geronimo.apache.org/

[Fou07b] FOUNDATION, Apache S.: The Jakarta Project. Website. 2007. – http://jakarta.apache.org/

[Fou07c] FOUNDATION, Apache S.: Support the Apache Software Foundation. Website.2007. – http://www.apache.org/

[Gam01] GAMMA, R. Helm ; R. Johnaon; J. Vlissides; E.: Entwurfsmuster: Elementewiederverwertbarer objektorientierter Software, Deutsche Übersetzung von D.Riehle. New York : Addison-Wesley, 2001

[Hai04] HAIGES, Sven: Die Welt der Gesichter: Einführung in JavaServer Faces Teil1:Grundlagen. 2004

[Hal04] HALL, Larry Brown; M.: Core Servlets and Java Server Pages. Sun Microsystems,2004

[Hat07] HAT, Red: JBoss. Website. 2007. – http://labs.jboss.com/portal/

[IBM07] IBM: WebSphere. Website. 2007. – http://www-306.ibm.com/software/de/websphere/application/app-transaction.html

[Man05] MANN, Kito D.: JavaServer Faces in action. Greenwich : Manning PublicationsCo., 2005

59

B LITERATURVERZEICHNIS

[Mic07a] MICROSYSTEMS, Sun: GlassFish Community. Website. 2007. – http://java.sun.com/javaee/community/glassfish/

[Mic07b] MICROSYSTEMS, Sun: J2EE API Java Platform, Enterprise Edition, v 5.0. Website.2007. – http://java.sun.com/javaee/5/docs/api/

[Mic07c] MICROSYSTEMS, Sun: J2EE Enterprise Edition, v 5.0. Website. 2007. – http://java.sun.com/developer/technicalArticles/J2EE/intro_ee5/

[Mic07d] MICROSYSTEMS, Sun: MVC-Architektur. Website. 2007. – http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/app-arch/app-arch2.html

[Tur01] TURAU, M. Schmidt; K. Saleck; V.: Java Server Pages und J2EE : Unternehmswei-te Web-basierte Anwendungen. 2001

[Ull06] ULLENBOOM, Christian: Java ist auch eine Insel, Programmieren für die Java2-Plattform in der Version 5. Galileo Computing, 2006

[Web07] WEB, Konsortium O.: Java Open Application Server. Website. 2007. – http://wiki.jonas.objectweb.org/xwiki/bin/view/Main/WebHome

[Wik07a] WIKIPEDIA: Common Gateway Interface (CGI). Website. 2007. – http://de.wikipedia.org/wiki/Common_Gateway_Interface

[Wik07b] WIKIPEDIA: J2EE Begriffklärung. Website. 2007. – http://de.wikipedia.org/wiki/J2EE

[Wik07c] WIKIPEDIA: J2EE Connector Architecture (JCA). Website. 2007. – http://de.wikipedia.org/wiki/J2EE_Connector_Architecture

[Wik07d] WIKIPEDIA: Java Server Pages (JSP). Website. 2007. – http://de.wikipedia.org/wiki/JavaServer_Pages

[Wik07e] WIKIPEDIA: Servlet. Website. 2007. – http://de.wikipedia.org/wiki/Servlet

[Wik07f] WIKIPEDIA: Tag-Libraries. Website. 2007. – http://de.wikipedia.org/wiki/Tag-Library

[wps07a] C1 WPS: Architektur: Equipment Management System (EMS). Website. 2007.– http://www.c1-wps.de/contell/cms/c1web/c1wps/site/loesungen/oochb/ems/overview.html

[wps07b] C1 WPS: Übersicht: Equipment Management System (EMS). Website. 2007.– http://www.c1-wps.de/contell/cms/c1web/c1wps/site/loesungen/oochb/ems/index.html

60

B LITERATURVERZEICHNIS

[Zül05] ZÜLLIGHOVEN, Heinz: Object-Oriented Construction Handbook - DevelopingApplication-Oriented Software with the Tools and Materials Approach. dpunktVerlag, 2005

[Zöl06] ZÖLLER, Bernhard: Thin Client vs. FatClient: Teil 1. Website. 2006.– http://www.contentmanager.de/magazin/artikel_1220_thin_client_fat_client_vergleich_vorteile.html

61

C Ehrenwörtliche Erklärung

Ich versichere, die von mir vorgelegte Studienarbeit selbständig verfasst zu haben. DieÜbernahme wörtlicher Zitate aus der Literatur sowie die Verwendung der Gedanken an-derer Autoren, wurden von mir an den entsprechenden Stellen innerhalb der Arbeit ge-kennzeichnet. Alle Quellen und Hilfsmittel, die ich für die Arbeit benutzt habe, sind vonmir kenntlich gemacht worden.

Hamburg, 27. März 2007

Ort, Datum Unterschrift

63

Documents

Studienarbeit - swa.informatik.uni-hamburg.de · Diese Arbeit befasst sich mit dem Framework - JavaServer Faces. Hauptziel ist es, den Einsatz von JavaServer Faces für die Weiterentwicklung