Konzeption und Implementation einer multi-tier Anwendung mit J2EE

Transkript

1 Departement für Informatik Universität Fribourg Konzeption und Implementation einer multi-tier Anwendung mit J2EE Masterarbeit Dominic Brügger Juni 2005 Eingereicht bei: Prof. Jacques Pasquier-Rocha Betreut durch: Dr. Patrik Fuhrer

2 Zusammenfassung Im Rahmen der Vorlesung Advanced Software Engineering im Wintersemester 2003/04 wurde ein Studentenprojekt mit dem Namen Mini-Cybercoach eingeführt. Mini-Cybercoach ist eine multi-tier Anwendung für die Verwaltung von Trainingsdaten verschiedener Sportarten. Das Projekt beschränkte sich auf die Realisierung der Geschäftslogik mit Enterprise JavaBeans. Die vorliegende Masterarbeit besteht im Wesentlichen darin, das vorhandene Projekt zu vervollständigen und auszubauen. Auf der Seite des Presentation-Tiers konzentriert sich die Arbeit sich vor allem auf die Konzeption und Implementation einer fortgeschrittenen Webanwendung. Der Business-Tier wird mit Transaktionen und Sicherheit erweitert. Daneben wird die bestehenden Geschäftslogik mit weiteren Anwendungsfällen ausgebaut. Das Projekt baut auf verschiedenen Frameworks und Werkzeugen auf. Für den Business- Tier wird weiterhin Enterprise JavaBeans eingesetzt, zusammen mit anderen J2EE-APIs. Als Grundlage für den Presentation-Tier wird Struts verwendet. Struts ist ein Framework für die Entwicklung von Webanwendungen, das auf den J2EE-Technologien Servlet und JSP aufbaut. Daneben kommen Open-Source-Werkzeuge wie XDoclet, Ant und Cactus zum Einsatz um den Entwicklungsprozess zu automatisieren. Ein wesentlicher Punkt bei Frameworks wie J2EE und Struts ist die Möglichkeit, die zur Verfügung gestellten Dienste auf deklarative Weise konfigurieren zu können. Dadurch wird ein hohes Mass an Flexibilität erreicht, indem Eigenschaften verändert werden können, ohne dass dafür der Code der Anwendung verändert werden muss. Für das Cybercoach-Projekt wird versucht, die verwendeten Dienste durchgehend deklarativ anzupassen. Ein Hauptaugenmerk der Arbeit liegt auf den Konzepten des Software Engineering. Eine wichtige Rolle spielt insbesondere die Softwarequalität. Kriterien wie Robustheit, Wiederverwendbarkeit, Erweiterbarkeit und Wartbarkeit werden unter anderem durch die Anwendung von Design Patterns erfüllt. Sowohl für den Business-Tier, als auch für den Presentation-Tier werden verschiedene Core J2EE Patterns angewendet. Ein Grund für die Wahl von Struts als Grundlage für die Webanwendung ist, dass das Framework bereits mehrere Presentation- Tier-Patterns umsetzt. Die verwendeten Patterns werden in der vorliegenden Arbeit genau beschrieben. Es wird versucht, aktuelle Praktiken des Software Engineering anzuwenden. Dazu gehören zum Beispiel die Realisierung des Projekts mit einem agilen Entwicklungsprozesses, das automatisierte Testen der Anwendung und die Verwendung von UML für die Dokumentation.

3 Inhaltsverzeichnis 1. Einleitung Aufgabenstellung Übersicht Cybercoach Aufbau des Dokumentes Konventionen Grundlagen Multi-Tier Architekturen J2EE Komponentenmodell J2EE APIs Enterprise JavaBeans Servlet JavaServer Pages Vorteile von J2EE Struts Übersicht Model-View-Controller Konzeption Anwendungsfälle Benutzer hinzufügen Benutzer anmelden Benutzer abmelden Benutzerangaben ändern Benutzer löschen Athletisches Profil ändern Aktivität hinzufügen Aktivität anzeigen Fremde Aktivität anzeigen Benutzerrechte verwalten Eingaben validieren Objektmodell Person Login Role Address Phone Profile

4 Inhaltsverzeichnis Activity Discipline Schlussbemerkung Entwicklungsprozess Aufteilung des Projekts Implementation Business-Tier Verwendung von Enterprise JavaBeans Session-Beans Entity-Beans Container-Managed Persistence Container-Managed Relationships Transaktionen Sicherheit Business-Tier-Patterns Business Delegate Session Façade Service Locator Transfer Object Entwicklungszyklus Build-Prozess Codegenerierung Tests Mögliche Erweiterungen Implementation Presentation-Tier Verwendung von Servlet, JSP und Struts Struts Architektur Struts Konfiguration Internationalisierung Validation der Benutzereingaben Sicherheit Presentation-Tier-Patterns Front Controller und Application Controller Context Object View Helper Composite View Service To Worker Parsing der XML-Datei Mögliche Erweiterungen Benutzerhandbuch Navigation Seitenaufbau Szenarien

5 Inhaltsverzeichnis User-Szenario Coach-Szenario Administrator-Szenario Fazit Ergebnis Verbesserungsmöglichkeiten A. Abkürzungsverzeichnis 72 B. Beispiel Entity-Bean (ProfileEntityBean) 73 C. Beispiele J2EE- und Struts-Konfiguration 75 C.1. web.xml C.2. struts-config.xml C.3. validation.xml C.4. tiles-defs.xml D. XML-Datei für Aktivitäten 79 D.1. DTD D.2. Beispiel E. Verwendete Software 80 E.1. Applikationsserver und Datenbank E.1.1. JBoss E.1.2. MySQL E.2. Entwicklung E.2.1. Eclipse E.2.2. Ant E.2.3. XDoclet E.2.4. JUnit/Cactus E.2.5. DBUnit E.3. Dokumentation E.3.1. L A TEX E.3.2. BibTeX E.3.3. TeXShop E.3.4. Bibdesk E.3.5. Microsoft Visio F. Verwendete Hardware 85 G. Installation und Konfiguration 86 G.1. Installation JBoss G.2. Installation MySQL G.3. Installation MySQL Connector/J G.4. Datenbank für Cybercoach anlegen

6 Inhaltsverzeichnis G.5. Deploy von Cybercoach G.6. Beispieldaten installieren G.7. Cybercoach ausführen H. CD 89 6

7 Abbildungsverzeichnis 1.1. Schema der Cybercoach-Architektur Polar Running Coach: Resultatanzeige Polar Running Coach: Fortschrittsanzeige Tier-Modell, aus [ACM03] J2EE-Server und Container, aus [BGH + 04] Model-View-Controller, aus [Hus02] Use-Case-Diagramm Das Objektmodell Tiers im Cybercoach-Projekt Required Attribut, aus [MH01] Business Delegate Klassendiagramm [ACM03] Netzwerkbelastung, aus [MH01] Session Façade Klassendiagramm [ACM03] Session Façade Sequenzdiagramm Service Locator Klassendiagramm [ACM03] Transfer Object Klassendiagramm [ACM03] Transfer Object Sequenzdiagramm Lebenszyklus eines Cactus-Tests [Cac05] Struts Übersicht, aus [Hus02] Front Controller und Application Controller Klassendiagramm [ACM03] Context Object Klassendiagramm [ACM03] Context Object Sequenzdiagramm View Helper Klassendiagramm [ACM03] Composite View Klassendiagramm [ACM03] Service To Worker Klassendiagramm [ACM03] Service To Worker Sequenzdiagramm Navigationsbaum der Cybercoach-Webanwendung Seitenaufbau in der Cybercoach-Webanwendung Cybercoach: Benutzerregistration mit Fehlermeldungen Cybercoach: Hauptseite Cybercoach: Aktivitätendetails Cybercoach: Aktivitätenanzeige Cybercoach: Aktivitätenanzeige für Coaches Cybercoach: Benutzerrechte verwalten

8 Abbildungsverzeichnis E.1. JMX-Console für JBoss E.2. Eclipse E.3. Ant-Plugin für Eclipse E.4. Testresultate von JUnit/Cactus als HTML-Bericht

9 1. Einleitung 1.1. Aufgabenstellung Im Rahmen der Vorlesung Advanced Software Engineering im Wintersemester 2003/04 wurde ein Studentenprojekt mit dem Namen Mini-Cybercoach eingeführt. Die Aufgabe war, eine multi-tier Anwendung zur Verwaltung von Trainingsdaten verschiedener Sportarten zu entwickeln. Das Projekt wurde mit der Java 2 Plattform, Enterprise Edition (J2EE), insbesondere Enterprise JavaBeans (EJB) realisiert. Die Architektur besteht aus einem Benutzerinterface (Web- oder Clientanwendung), der Geschäftslogik und einer Datenbankschicht. Das Studentenprojekt ist für eine einsemestrige Vorlesung ausgelegt und beschränkt sich auf eine partielle Implementation der Geschäftslogik mit EJB und einem einfachen Testclient. Die vorliegende Masterarbeit besteht im Wesentlichen darin, das vorhandene Projekt zu vervollständigen und zu verbessern. In der ersten Phase der Arbeit werden verschiedene Vorschläge für die Erweiterung der bestehenden Basis erarbeitet. Verschiedene Möglichkeiten stehen zur Verfügung, zum Beispiel die Entwicklung eines Benutzerinfterfaces für mobile Geräte (PDA oder Mobiltelefon), Konzeption eines fortgeschrittenen Webinterface oder einer Rich-Client Swing-Benutzeroberfläche, neue Möglichkeiten der Datenvisualisierung oder die Erweiterung der Geschäftslogik durch Sicherheit und Transaktionen. Am Ende dieser ersten Phase werden die Erweiterungen und Verbesserungen festgelegt und der Umfang des Projekts genau definiert. Der praktische Teil der Arbeit besteht in der Realisierung der vorgeschlagenen Erweiterungen, also der Entwicklung des vervollständigten Cybercoach-Projekts. Das Hauptaugenmerk liegt dabei auf den Konzepten des Software Engineering. Eine wichtige Rolle spielt die Softwarequalität, das heisst die Beachtung der Kriterien Robustheit, Wiederverwendbarkeit, Erweiterbarkeit und Wartbarkeit [Mey97]. Es wird ausserdem mit aktuellen Praktiken des Software Engineering gearbeitet. Dazu gehört unter anderem die Verwendung eines agilen Entwicklungsprozesses [Coc01] mit automatisierten Tests, die Verwendung von UML und die Anwendung von Design Patterns. Eine Vorgabe für das Projekt ist, dass weitgehend Open-Source-Software für Datenbank, Applikationsserver, IDE usw. eingesetzt wird. Das Cybercoach-System soll ausserdem auf verschiedenen Plattformen (Windows, Linux, Mac OS X) betrieben werden können Übersicht Cybercoach Die Idee von Cybercoach geht zurück auf ein Projekt an der Hochschule für Technik und Architektur Freiburg [BB02] in Zusammenarbeit mit der Firma Tecost. Cybercoach ist ein System, welches einem Sportler hilft, sein Training möglichst effizient zu gestalten. Das System sammelt zu diesem Zweck verschiedene Daten des Sportlers und seinen Aktivitäten und wertet diese aus. Zu den Grundfunktionen von Cybercoach gehören: Erstellen und Verwalten eines Benutzerkontos. 9

10 1. Einleitung Aktualisieren des athletischen Profils (Gewicht, Ruhe-Herzfrequenz usw.). Hinzufügen, visualisieren und analysieren von Trainingseinheiten. Erstellen von Trainingsstatistiken. Sammeln von Daten während des Trainings (z.b. mit einem Herzfrequenz-Messer). Neben den aufgezählten Grundfunktionen bieten sich etliche Möglichkeiten an, mit welchen Cybercoach zu einem späteren Zeitpunkt erweitert werden könnte. Verschiedene Dienstleistungen könnten das Cybercoach-System auch kommerziell interessant machen. Eine Möglichkeit ist zum Beipiel das Erstellen eines personalisierten Trainingsplan, optimiert auf das aktuelle athletische Profil des Benutzers. Dieser Trainingsplan kann entweder von einem professionellen Coach oder einem intelligenten System erzeugt werden. Eine ähnliche Idee ist das Anbieten einer personalisierten Ernährungsberatung, basierend auf den gesammelten Daten des Benutzers. Wiederum kann dies von einem professionellen Diätberater oder einem intelligenten System erfolgen. Eine weitere Möglichkeit ist die Integration eines Onlineshops in das System. Auch hier können die gesammelten Benutzerdaten genutzt werden, Zum Beispiel um personalisierte Werbung zu erzeugen. Cybercoach ist als eine verteilte Anwendung konzipiert. Auf der Client-Seite dient einerseits ein Webbrowser oder ein Rich-Client als Benutzerinterface für die Verwaltung des Benutzerkontos und die Visualisierung der Trainingsdaten. Andererseits kommt ein mobiles Gerät zum Einsatz, welches direkt während des Trainings Daten über die laufende Aktivität sammelt. Als grundlegende Daten für eine Trainingsaktivität werden unter anderem die Koordinaten und die Herzfrequenz in bestimmten Zeitabständen gemessen. Als Beispielkonfiguration werden die Koordinaten von einem GPS-Empfänger und die Herzfrequenz von einer Polar-Armbanduhr gemessen. Die gesammelten Daten werden anschliessend von einem Mobiltelefon oder einem PDA synchronisiert und an den Server gesendet. Es ist auch vorstellbar, alle benötigten Komponenten in einem integrierten Gerät zu vereiningen. Abbildung 1.1 zeigt das Schema dieser Architektur. Als Datenformat für die Übertragung der Trainingsdaten vom mobilen Gerät zum Server ist XML vorgesehen. Auf der Server-Seite befindet sich ein Applikationsserver und eine Datenbank. Der Applikationsserver enthält die Geschäftslogik und die Datenbank ist zuständig für die persistente Speicherung der Daten. Polar, ein bekannter Hersteller von Herzfrequenz-Messgeräten, bietet unter dem Namen Polar Running Coach [Pol05] bereits ein System für die Verwaltung von Trainingsdaten an. Die Abbildungen 1.2 und 1.3 zeigen Ausschnitte dieses Systems und dienen als Inspiration für das Cybercoach-Projekt. Polar Running Coach wertet Trainingsdaten grafisch als Kurven und Balkendiagramme aus und erstellt verschiedene Statistiken über die getätigten Aktivitäten. Ein Unterschied zwischen Polar Running Coach und Cybercoach liegt in der Art, wie die Trainingsdaten übermittelt werden. Bei Cybercoach werden diese Daten in Form einer XML-Datei an den Server gesendet. Die Grundidee dabei ist, dass die Übermittlung der Daten automatisch von einem mobilen Gerät an den Server vorgenommen werden könnte. Die vorliegende Masterarbeit umfasst nicht den ganzen Bereich des Cybercoach-Systems. Sie beschränkt sich auf die Konzeption und Implementation eines Systems für die grundlegenden 10

11 1. Einleitung Server PDA Mobiltelephon Web Herzfrequenz- messer PC Datenbank Client-Seite Server-Seite Abbildung 1.1.: Schema der Cybercoach-Architektur Funktionen der Benutzerverwaltung, der Verwaltung von Trainingseinheiten und der Erzeugung von Trainingsstatistiken. Durch eine saubere Software-Architektur ist Cybercoach jedoch so ausgelegt, dass Erweiterungen einfach vorgenommen werden können. Von den in Abschnitt 1.1 vorgeschlagenen Erweiterungsmöglichkeiten des ursprünglichen Mini-Cybercoach-Projektes konzentriert sich diese Arbeit auf die Konzeption eines fortgeschrittenen Webinterfaces, sowie die Erweiterung der Geschäftslogik durch Sicherheit und Transaktionen. Als Grundlage für das Webinterface soll Struts dienen, ein Framework für die Entwicklung von Java-basierten Webanwendungen. Wie in Abbildung 1.1 angedeutet, wird auf die Realisierung einer Anwendung für mobile Geräte, welche direkt während einer Trainingsaktivität Messdaten aufzeichnet und anschliessend als XML-Datei an den Server sendet, im vorliegenden Projekt nicht eingegangen. Stattdessen werden die Trainingsdaten in Form einer XML-Datei direkt via Webinterface auf den Server geladen Aufbau des Dokumentes Kapitel 2 dieses Dokumentes befasst sich mit den Grundlagen von multi-tier Anwendungen, der J2EE-Plattform und des Struts-Frameworks. In Kapitel 3 wird die Konzeption des Cybercoach Projektes vorgestellt, wobei vor allem der Entwicklungsprozess, die Anwendungsfälle und das Objektmodell erläutert werden. Die beiden darauf folgenden Kapitel behandeln die Implementation von Cybercoach, aufgeteilt in die Implementation des Business-Tier im Kapitel 4 und die Implementation des Presentation-Tier im Kapitel 5. Beide Kapitel haben den gleich Aufbau. Es wird zunächst beschrieben, wie die verschiedenen Technologien eingesetzt werden. Anschliessend werden die verwendeten Patterns erläutert und am Schluss einige Erweiterungsmöglichkeiten vorgeschlagen. Kapitel 6 enthält das Benutzerhandbuch für die 11

12 1. Einleitung Abbildung 1.2.: Polar Running Coach: Resultatanzeige Abbildung 1.3.: Polar Running Coach: Fortschrittsanzeige 12

13 1. Einleitung Cybercoach-Webanwendung. Im Kapitel 7 werden schliesslich einige Schlussfolgerungen aus der Arbeit gezogen und die verschiedenen Verbesserungsmöglichkeiten zusammengefasst Konventionen Im vorliegenden Dokument werden folgende Konventionen verwendet: Kapitel sind in Abschnitte und eventuell Unterabschnitte aufgeteilt. Abbildungen werden kapitelweise nummeriert. Programmcode und URLs werden durch eine Typewriter Schrift kennzeichnet. Schlüsselwörter und Namen von Technologien werden kursiv geschrieben, wenn sie das erste mal vorkommen. Abkürzungen werden beim ersten Vorkommen ausgeschrieben und im Abkürzungsverzeichnis in Anhang A aufgeführt. Für Klassen- und Sequenziagramme wird der UML-Standard verwendet, wie er zum Beispiel in [Fow03] beschrieben wird. Klassendiagramme und Grafiken, die aus englischer Literatur entnommen wurden, werden in englischer Sprache abgebildet. 13

14 2. Grundlagen 2.1. Multi-Tier Architekturen Komplexe Softwaresysteme werden häufig in mehrere Schichten aufgeteilt. Diese Aufteilung hat einige wichtige Vorteile. Ein Entwickler kann eine einzelne Schicht sehr genau verstehen, ohne die restlichen Schichten kennen zu müssen. Durch die Aufteilung werden aber auch Abhängigkeiten der verschiedenen Softwareteile aufgebrochen. Eine einzelne Schicht kann dadurch zum Beispiel einfacher durch eine alternative Implementation ersetzt werden. Ein klassisches Modell für mehrschichtige Softwaresysteme ist die 3-Tier-Architektur. Dieses Modell teilt eine Software in drei Schichten ein: Präsentation Geschäftslogik Daten Die Präsentationsschicht behandelt die Interaktion zwischen dem Benutzer und der Software. Heutzutage ist dies in den meisten Fällen ein Rich-Client oder ein Webinterface. Beispiele von Rich-Clients sind Swing- oder Windows-Anwendungen. Die Hauptaufgaben der Präsentationsschicht sind die Darstellung von Informationen für den Benutzer und die Interpretation von Benutzerereignissen als Aktionen der Geschäftslogik. Die Geschäftslogik wird oft auch Anwendungslogik genannt und enthält die Implementation der eigentlichen Dienste, welche die Anwendung leistet. Dies sind beispielsweise Berechnungen welche auf Benutzereingaben und gespeicherten Daten basieren. Die Datenschicht übernimmt die Aufgabe der Datenspeicherung und Datenbereitstellung. Häufig wird hier ein Datenbankserver eingesetzt. Der Zugriff auf Daten kann aber auch durch Legacy-Systeme oder externe Anwendungen erfolgen. Im Zusammenhang mit J2EE werden häufig erweiterte Modelle mit mehr als drei Schichten verwendet. Abblidung 2.1 zeigt das 5-Tier-Modell, wie es in [ACM03] beschrieben wird. Der Client-Tier repräsentiert hier alle Geräte oder Clients, die auf das System zugreifen. Dies können zu Beispiel Webbrowser, Rich-Clients oder mobile Geräte sein. Der Presentation-Tier kapselt die gesamte Präsentationslogik. Die Präsentationslogik beinhaltet unter anderem das Session-Management, das Empfangen von Client-Anfragen, sowie das Erzeugen und Ausliefern von Antworten auf die Anfragen. In J2EE sind zum Beispiel Servlets und JavaServer Pages (siehe Abschnitte und 2.2.5) im Presentation-Tier angesiedelt. Der Business-Tier stellt Dienste zur Verfügung, die von Anwendungs-Clients benötigt werden. Diese Schicht besteht aus den Geschäftsdaten und der Geschäftslogik. Der Business-Tier ist gekoppelt mit dem Integration-Tier, welcher für die Kommunikation mit externen Ressourcen und Systemen zuständig ist. In J2EE verwenden zum Beispiel die Geschäftsobjekte JDBC (siehe Abschnitt 2.2.2) für den Zugriff auf eine relationale Datenbank. Der Resource-Tier 14

15 2. Grundlagen Client-Tier Browsers, Applets, Application clients User interaction, UI presentation, devices Presentation-Tier JSP, Servlets, Struts Session management, content creation, format, delivery Business-Tier EJBs and other Business components Business logic, transactions, data, services Integration-Tier JDBC, JMS, Connectors Resource adapters Resource-Tier Databases, external systems, Legacy systems Resources, data, external services Abbildung 2.1.: 5-Tier-Modell, aus [ACM03] enthält alle Daten und externen Ressourcen. Er wird zum Beispiel durch Datenbanksysteme, Mainframes oder Legacy-Systeme gebildet. In der Literatur herrscht eine gewisse Unklarheit über die Verwendung der Begriffe Tier und Layer. In einigen Werken [Fow02] wird Tier für die physische und Layer für die logische Aufteilung eines Systems verwendet. Andere Werke, besonders Literatur aus dem Java-Bereich [ACM03], machen diese Unterscheidung nicht. Im vorliegenden Bericht findet diese Unterscheidung ebenfalls nicht statt J2EE Java 2 Platform, Enterprise Edition [J2E05, JF99, BGH + 04] oder kurz J2EE ist die Spezifikation einer Plattform für die Entwicklung von verteilten multi-tier Anwendungen mit Java. J2EE etabliert offene Standards für verschiedene Technologien, die in verteilten Systemen verwendet werden. Zu den wichtigsten Diensten gehören Datenbankzugriff, Transaktionen, Persistenz, Naming und Message-Oriented Middleware Komponentenmodell J2EE-Anwendungen basieren auf einem Komponentenmodell. Eine Komponente ist eine Softwareeinheit, die speziell auf Wiederverwendbarkeit und Komposition mit anderen Komponenten ausgerichtet ist. Dies wird durch klar spezifizierte Schnittstellen erreicht. Die J2EE- Spezifikation definiert folgende Softwarekomponenten: Anwendungsclients und Applets sind Komponenten die auf dem Client ausgeführt werden. Servlets und JavaServer Pages (JSP) sind Web-Komponenten, die auf dem Server ausgeführt werden. 15

16 2. Grundlagen Enterprise JavaBeans (EJB) sind Geschäftskomponenten, die auf dem Server ausgeführt werden. J2EE-Komponenten erfordern einen Container als Laufzeitumgebung. Damit eine Komponente ausgeführt werden kann, muss sie zu einem J2EE-Modul assembliert werden und in einen Container geladen werden. Das Assemblieren einer oder mehreren Komponenten zu einem Modul beinhaltet auch das Konfigurieren der Container-Einstellungen für jede Komponente. Die Konfiguration geschieht mittels mehrerer XML-Dateien, sogenannten Deployment-Deskriptoren. Mit diesen Einstellungen werden verschiedene Dienste angepasst, die vom Container zur Verfügung gestellt werden. Zu diesen Diensten gehören unter anderem Transaktionen, Sicherheit, Naming und Persistenz. Abbildung 2.2.: J2EE-Server und Container, aus [BGH + 04] Abbildung 2.2 illustriert das Verhältnis zwischen J2EE-Server, Container und Komponenten. Auf der Client-Seite repräsentiert der Browser einen Container für Java-Applets. Neben der Ausführung von Applets ist er ebenfalls zuständig für die Darstellung der von den Servlets oder JSP generierten HTML-seiten. Anwendungsclients werden in einem Application- Client-Container ausgeführt. Die Server-Seite wird durch den J2EE-Server gebildet, der im Allgemeinen auch Applikationsserver genannt wird. Der J2EE-Server enthält zwei Container: einen Web- und einen EJB-Container. Der Web-Container verwaltet die Ausführung von Web-Komponenten, also Servlets und JavaServer Pages. Der EJB-Container verwaltet die Ausführung der Geschäftskomponenten. Betrachtet man Abbildung 2.2 unter dem Aspekt des 5-Tier-Modells aus Abschnitt 2.1, so repräsentiert die linke Seite den Client-Tier. Der Presentation-Tier wird durch die Servlets und JSP-Seiten gebildet. Der Business-Tier wird durch die Enterprise-Beans realisiert. Der EJB- Container übernimmt die Aufgabe des Integration-Tiers. Schliesslich stellt die Datenbank auf der rechten Seite den Ressource-Tier dar. 16

17 2. Grundlagen Es gibt zahlreiche Implementierungen von J2EE-Server. Für das Cybercoach-Projekt wird der JBoss Application Server [JBo05] verwendet. JBoss ist ein Open-Source-Projekt. Weitere Beispiele von Open-Source-Applikationsservern sind JOnAS [JOn05] und Apache Geronimo [Ger05]. IBM WebSphere [IBM05] und BEA WebLogic [BEA05] sind Beispiele kommerzieller Produkte J2EE APIs J2EE ist als eine Menge von Application Programming Interfaces (APIs) organisiert. Jede API bietet dem Entwickler eine Schnittstelle für eine bestimmte Technologie. Das Cybercoach- Projekt basiert vor allem auf den Technologien Enterprise JavaBeans, Servlets und JavaServer Pages. Auf diese wird in den Abschnitten bis genauer eingegangen. Daneben beinhaltet J2EE eine vielzahl weiterer APIs. Die wichtigsten werden nun kurz beschrieben: Java Database Connectivity (JDBC) ist eine API für den Zugriff auf relationale Datenbanken. Java Naming and Directory Interface (JNDI) ist eine Schnittstelle mit der eine Anwendung auf Namens- und Verzeichnisdienste zugreifen kann. Über JNDI wird insbesondere der Zugriff auf J2EE-Komponenten sichergestellt. Java Transaction API (JTA) erlaubt einer Anwendung die Steuerung der Transaktionsverwaltung. Java Message Service (JMS) ist eine API für die asynchrone Verarbeitung von Nachrichten. Java Authentication and Authorization Service (JAAS) ist eine API für die Authentifizierung und Autorisierung von Benutzern oder Gruppen von Benutzern. Java API for XML Processing (JAXP) ist eine API für die Verarbeitung von XML- Dateien. JAXP unterstützt die Standards SAX und DOM, um XML-Dateien als eine Folge von Events einzulesen beziehungsweise sie in einer Baumstruktur abzubilden Enterprise JavaBeans Enterprise JavaBeans [MH01, RBS04] oder kurz EJB ist ein standardisiertes, server-seitiges Komponentenmodell für die Entwicklung von verteilten Geschäftsanwendungen. Die aktuelle Spezifikation EJB 2.1 kennt drei verschiedene Typen von Enterprise-Beans: Entity-Beans modellieren die Geschäftsdaten der Anwendung. Dies können zum Beispiel Personen, Dinge oder Orte sein. Entity-Beans repräsentieren Daten, die in einem Speichermedium, etwa einer relationalen Datenbank, vorhanden sind. In der Regel wird die Persistenz vom EJB-Container automatisch verwaltet (Container-Managed Persistence). Es ist jedoch auch Möglich, dass ein Entity-Bean die Persitenz selber verwaltet (Bean- Managed Persistence). 17

18 2. Grundlagen Session-Beans bilden die Prozesse und Tasks der Anwendung ab. Sie stellt den Clients Dienste zur Verfügung, die einen Geschäftsprozess repräsentieren. Es wird zwischen Statefull- und Stateless-Session-Beans unterschieden. Bei Statefull-Session-Beans kann im Gegensatz zu Statless-Session-Beans der Zustand der Komponente über mehrere Aufrufe des selben Clients hinweg behalten werden. Message-Driven-Beans verarbeiten asynchrone Nachrichten. Die Nachrichten werden typischerweise durch die Java Message Service API (JMS) versendet. Sie können von beliebigen J2EE-Komponenten aus gesendet werden (Entity-Beans, Session-Beans, Web- Komponenten oder Anwendungs-Clients). Message-Driven-Beans sind seit EJB 2.0 Bestandteil der Spezifikation. Um ein Entity- oder Session-Bean zu implementieren, müssen neben der Bean-Klasse ein Komponenten- und ein Home-Interface definiert werden. Das Komponenten-Interface definiert die Geschäftsmethoden eines Enterprise-Beans. Zum Beispiel könnte das Komponenten- Interface eines Session-Beans, welches ein Bankkonto verwaltet, eine Methode für Gutschriften und eine Methode für Belastungen definieren. Das Home-Interface definiert die Lebenszyklus- Methoden eines Enterprise-Beans. Mit diesen Methoden könnenn unter anderem neue Instanzen des Beans kreiert oder bestehende Instanzen entfernt weren. Das Home-Interface eines Entity-Beans kann auch Finder-Methoden definieren. Finder-Methoden lokalisieren Instanzen von Entity-Beans anhand ihres Primärschlüssels oder anderen Kriterien. Clients können lokal oder entfernt auf Enterprise-Beans zugreifen. Beim lokalen Zugriff befinden sich Client und Bean in der selben Java Virtual Machine (JVM). Beim entfernten Zugriff befinden sie sich in verschiedenen JVMs oder sogar auf verschiedenen physischen Rechnern. Für einen lokalen Zugriff muss ein Entity- oder Session-Bean ein Local-Interface und ein Local-Home-Interface als Komponenten- beziehungsweise Home-Interface zur Verfügung stellen. Für den entfernten Zugriff muss es ein Remote-Interface und ein Remote-Home-Interface zur Verfügung stellen. Ein EJB-Container ist Teil eines Applikationsservers und bildet die Laufzeitumgebung für Enterprise-Beans. Er stellt die Infrastruktur zur Verfügung, welche für multi-tier Geschäftsanwendungen nötig ist. Zu dieser Infrastruktur gehören Dienste wie Transaktionsverwaltung, Persistenz, Sicherheit, Nebenläufigkeit und Ressourcenverwaltung. Der Entwickler wird somit von der Programmierung dieser Funktionalitäten befreit und kann sich vollständig der Geschäftslogik widmen. Für die Konfiguration der oben genannten Dienste werden Deployment-Deskriptoren verwendet. Durch das Konzept der Deployment-Deskriptoren werden Eigenschaften einer Komponente nicht hart codiert, sondern deklarativ festgesetzt. Dadurch wird eine hohes Mass an Flexibilität erreicht, indem Eigenschaften verändert werden können, ohne dass dafür der Code der Komponente verändert werden muss. Dadurch kann jede Komponente bei ihrer Verwendung den aktuellen Erfordernissen (zum Beispiel erhöhte Sicherheit) angepasst werden. Kapitel 4 beschreibt wie der Business-Tier des Cybercoach-Projekts mit Hilfe von EJB umgesetzt wird. Einige der hier erklärten Begriffe, wie zum Beispiel Container-Managed Persistence, werden in diesem Kapitel noch einmal aufgegriffen und anhand des Cybercoach-Projektes noch einmal genauer erläutert. 18

19 2. Grundlagen Servlet Die Servlet-Spezifikation definiert ein server-seitiges Komponentenmodell, das von Webserver- Herstellern implementiert werden kann. Servlets basieren auf dem Request-Response Programmiermodell. Obwohl sie verschiedene Arten von Requests unterstützen, werden sie vor allem verwendet, um HTTP-Requests für Webseiten zu verarbeiten. Servlets sind ein mächtiges Werkzeug, um dynamisch textbasierte Inhalte wie HTML oder XML zu erzeugen. Servlets werden oft als Java-Pendant zum Common Gateway Interface (CGI ) betrachtet JavaServer Pages JavaServer Pages oder kurz JSP ist eine Erweiterung des Servlet Komponentenmodells. Eine JSP-Seite ist ein Textdokument, das sowohl statische Inhalte wie HTML oder XML enthält, als auch und JSP-Elemente, welche dynamische Inhalte erzeugen. JSP-Seiten werden vom Web-Container on-the fly in Servlets übersetzt und kompiliert. Sie können anschliessend wie normale Servlets ausgeführt werden. JSP vereinfacht dadurch das Erstellen von dynamischen erzeugten Webinhalten. Zusätzlich zu den vordefinierten JSP-Elementen gibt es die Möglichkeit, benutzerdefinierte Sprach-Elemente (Custom-Tags) zu definieren. Dazu muss eine eigene Tag-Bibliothek (Tag- Library) deklariert werden. Tag-Libraries werden durch XML-Dateien definiert, die jedem Custom-Tag eine server-seitige Java-Klassen assoziieren, welche die Logik der Tags implementiert Vorteile von J2EE J2EE bietet wichtige Vorteile für die Entwicklung von verteilten Geschäftsanwendungen. Die Plattform stellt Dienste zur Verfügung, deren Implementation durch langjährigen Einsatz in laufenden Systemen erprobt und getestet wurde. Dies vermindert technische Risiken und senkt Kosten. Als Spezifikation ermöglicht J2EE die Entwicklung von Softwarekomponenten, die portabel sind. J2EE-Anwendungen lassen sich mit einem vernünftigen Aufwand auf einen anderen Applikationsserver portieren, sofern dieser die J2EE-Spezifikation implementiert. Ein weiterer wichtiger Vorteil ist, dass J2EE die Entwicklungszeit von verteilten Anwendungen verkürzt, da wichtige Dienste wie Transaktionen, Sicherheit usw. nicht selber implementiert werden müssen. Stattdessen werden diese Dienste vom Applikationsserver zur Verfügung gestellt und können durch die Deployment-Deskriptoren deklarativ konfiguriert werden. Man muss sich allerdings auch im Klaren sein, dass J2EE sehr umfassend ist und viele verschiedene Technologien beinhaltet. Die Zeiteinsparung durch den Einsatz von J2EE setzt somit gute Kenntnisse der zahlreichen APIs und Spezifikationen voraus Struts Übersicht Struts [Str05, Hus02] ist ein quelloffenes Framework für die Entwicklung von Java-basierten Webanwendungen. Der Kern von Struts ist eine Kontrollschicht, welche auf standartisierte 19

20 2. Grundlagen Technologien wie Servlets, JSP, JavaBeans und XML aufbaut. Die Architektur von Struts- Webanwendungen basiert auf dem klassischen Model-View-Controller-Pattern (siehe Abschnitt 2.3.2). Struts verfügt über eine eigene Controller-Komponente und integriert andere Technologien, um Model und View zu bilden. Für das Model interagiert Struts mit Datenzugriffs- Technologien, wie JDBC, EJB und anderen. Für die View-Komponenten arbeitet Struts zum Beispiel mit JSP. Struts stellt Mechanismen zur Verfügung, welche eine professionelle Webanwendung benötig, um erfolgreich ihren Dienst zu erweisen. Das Framework hilft dem Entwickler, eine Webanwendung zu realisieren, die erweiterbar ist und auf bewährten Patterns basiert. So werden viele der Presentation-Tier-Patterns aus [ACM03] von Struts realisiert. Kapitel 5 beschreibt die Details die Implementation der Cybercoach-Webanwendung mit Struts. Insbesondere wird in Abschnitt 5.2 gezeigt, welche Presentation-Tier-Patterns durch das Struts-Framework implementiert werden Model-View-Controller Das Model-View-Controller-Pattern [KP88] oder kurz MVC-Pattern teilt eine Anwendung in die Einheiten Datenmodell, Präsentation und Steuerung ein. Als eindeutige Bezeichnung dieser Einheiten werden die Begriffe Model, View und Controller verwendet, die zusammengesetzt dem Pattern seinen Namen geben. Abblidung 2.3 zeigt das MVC-Pattern, wie es meistens dargestellt wird: ein Dreieck bestehend aus den drei verbundenen Einheiten. Model State query Change notification State change Method invocations Events View View selection User actions Controller Abbildung 2.3.: Model-View-Controller, aus [Hus02] Das Model besteht aus dem internen Zustand des Systems, welcher sowohl das Objektmodell als auch die Aktionen, die den Zustand verändern, umfasst. In diesem Sinne ist die Geschäfts- 20

21 2. Grundlagen logik ebenfalls Teil des Models. Sowohl das Objektmodell, als auch die Geschäftslogik einer verteilten Anwendung werden durch den Business-Tier implementiert und sind nicht Teil des Presentation-Tiers. Die Architektur von Struts sieht deshalb vor, dass der Zugriff auf die die Model-Daten über den Business-Tier erfolgt und innerhalb des Presentation-Tier in Hilfsklassen gekapselt wird. Eine View ist verantwortlich für die Darstellung des Zustands. Sie stellt eine mögliche Abbildung des Models dar. Ein Datenmodell kann mehrere Views haben, zum Beispiel können tabellarische Daten als Tabelle, als Kuchendiagramm oder als Balkendiagramm dargestellt werden. In Struts werden View Komponenten in der Regel als JSP-Seiten realisiert. Um die Informationen des Models in den Seiten darstellen zu können, stellt Struts eigene Tag-Libraries zur Verfügung. Der Controller ist die Komponente, welche die Interaktionen des Anwenders verarbeitet. Er nimmt Benutzereingaben entgegen und bildet diese auf die entsprechende Funktion des Models ab. Die Kontrolle wird danschliessend an die zuständige View weitergeleitet. Der Controller hat sowohl Zugriff auf das Model, als auch auf die Views. 21

22 3. Konzeption 3.1. Anwendungsfälle In diesem Abschnitt werden die funktionalen Anforderungen des Cybercoach-Systems anhand von Anwendungsfällen (Use-Cases) erfasst. Anwendungsfälle beschreiben die typischen Interaktionen zwischen den Benutzern des Systems und dem System selbst. Es gibt kein standardisiertes Format, um Anwendungsfälle festzuhalten. Im vorliegenden Bericht wird ein gebräuchlicher Stil verwendet, der Fowler in [Fow03] beschreibt. Ein Anwendungsfall besteht dabei aus einer Menge zusammengehörender Szenarien. Ausgegangen wird vom Erfolgsszenario, welches den normalen Ablauf des Anwendungsfalls beschreibt. Die anderen Szenarien beschreiben Variationen oder Fehlerfälle und werden als Erweiterungen bezeichnet. Erfolgsszenario und Erweiterungen werden als eine numerierte Liste von Schritten niedergeschrieben. Jeder Anwendungsfall hat einen Hauptakteur, welcher vom System einen Dienst ersucht. Als Akteur wird in Anwendungsfällen eine Rolle bezeichnet, welche ein Benutzer in Bezug auf das System einnimmt. Das Cybercoach-System kennt drei verschiedene Akteure: Benutzer, Coach und Administrator. Benutzer hinzufügen System Benutzer anmelden «include» Fremde Aktivität anzeigrn Benutzer abmelden «include» Coach Benutzer löschen Benutzerangaben ändern «include» «include» Eingaben validieren Benutzer Athletisches Profil ändern «include» Benutzerrechte verwalten Aktivität hinzufügen Aktivität anzeigen Administrator Abbildung 3.1.: Use-Case-Diagramm Abbildung 3.1 zeigt das Use-Case-Diagramm im UML-Format. Das Diagramm enthält keine Details der einzelnen Anwendungsfälle. Vielmehr ist es als eine Art grafisches Inhaltsverzeichnis für die Menge der beschriebenen Anwendungsfälle zu verstehen. Die Details der Anwen- 22

23 3. Konzeption dungsfälle werden in den folgenden Abschnitten beschrieben. Jeder Abschnitt beschreibt jeweils ein Anwendungsfall mit den möglichen Szenarien im oben genannten Format Benutzer hinzufügen Hauptakteur: Benutzer. Erfolgsszenario: 1. Benutzer gibt Benutzerdaten (Name, Adresse, usw.), Benutzernamen und Passwort ein. 2. System validiert die Eingaben (Anwendungsfall ). 3. System überprüft, ob der Benutzername vergeben ist. 4. System speichert die Daten und zeigt die Hauptübersicht an. Erweiterungen: 3a. Der Benutzername ist bereits vergeben: 1. System fordert Benutzer auf, einen anderen Benutzernamen einzugeben. 2. Benutzer gibt neuen Benutzernamen ein oder bricht Registration ab Benutzer anmelden Hauptakteur: Benutzer. Erfolgsszenario: 1. Benutzer gibt Benutzernamen und Passwort ein. 2. System überprüft Benutzernamen und Passwort. 3. System meldet den Benutzer an. 4. System zeigt die Hauptübersicht an. Erweiterungen: 2a. Benutzername existiert nicht oder Passwort ist nicht korrekt: 1. System fordert Benutzer auf, Benutzerangaben erneut einzugeben. 2. Benutzer korrigiert die Angaben oder bricht Benutzeranmeldung ab. Bemerkungen: 1. Ein Benutzer kann erst erfolgreich angemeldet werden, nachdem er sich registriert hat. 23

24 3. Konzeption Benutzer abmelden Hauptakteur: Benutzer. Erfolgsszenario: 1. Benutzer wählt Logout. 2. System meldet den Benutzer ab Benutzerangaben ändern Hauptakteur: Benutzer. Erfolgsszenario: 1. System bereitet eine Eingabemaske mit den existierenden Benutzerangaben vor. 2. Benutzer nimmt die gewünschten Änderungen vor. 3. System validiert die Eingaben (Anwendungsfall ). 4. System speichert die geänderten Daten ab. 5. System zeigt die Hauptübersicht an Benutzer löschen Hauptakteur: Benutzer. Erfolgsszenario: 1. Benutzer wählt Benutzer löschen. 2. System löscht den Benutzer, das athletische Profil und alle Aktivitäten des Benutzers Athletisches Profil ändern Hauptakteur: Benutzer. Erfolgsszenario: 1. Benutzer gibt athletische Daten (Gewicht, Gesundheitszustand, usw.) ein. 2. System validiert die Eingaben (Anwendungsfall ). 3. System schliesst das bisherige Profil ab und kreiert ein neues. 4. System speichert die geänderten Daten im neuen Profil ab. Erweiterungen: 1a. Benutzer hat bereits ein athletisches Profil: 1. System füllt die Eingabefelder mit den existierenden Werten. 24

25 3. Konzeption Aktivität hinzufügen Hauptakteur: Benutzer. Erfolgsszenario: 1. Benutzer wählt in einem Dialog die XML-Datei mit den Aktivitätsdaten aus. 2. System parst die XML-Datei und speichert die Daten als Aktivität. 3. System zeigt Zusammenfassung der hinzugefügten Daten an. Erweiterungen: 2a. XML-Datei ist ungültig: 1. System erzeugt eine Fehlermeldung. 2b. Benutzer hat kein Profil mit entsprechender Gültikeitperiode: 1. System erzeugt eine Fehlermeldung Aktivität anzeigen Hauptakteur: Benutzer. Erfolgsszenario: 1. Benutzer gibt Anfangs- und Enddatum, sowie gesuchte Disziplin ein. 2. System validiert die Eingaben (Anwendungsfall ). 3. System zeigt Liste aller entsprechenden Aktivitäten an. 4. Benutzer wählt eine Aktivität aus. 5. System zeigt detailierte Informationen zur ausgewählten Aktivität an. Erweiterungen: 2a. Anfangs- und/oder Enddatum wurde nicht eingegeben: 1. System füllt die Eingabefelder mit Standardwerten Fremde Aktivität anzeigen Hauptakteur: Coach. Erfolgsszenario: 1. Coach gibt Anfangs- und Enddatum, gesuchte Disziplin und gewünschten Benutzer ein. 2. System validiert die Eingaben (Anwendungsfall ). 3. System zeigt Liste aller entsprechenden Aktivitäten mit zugehörigen Benutzernamen an. 25

26 3. Konzeption 4. Coach wählt eine Aktivität aus. 5. System zeigt detailierte Informationen zur ausgewählten Aktivität an. Erweiterungen: 2a. Anfangs- und/oder Enddatum wurde nicht eingegeben: 1. System füllt die Eingabefelder mit Standardwerten Benutzerrechte verwalten Hauptakteur: Administrator. Erfolgsszenario: 1. System zeigt Liste aller Benutzer mit zugehörigen Rechten für Coach und Administrator an. 2. Administrator ändert Coach- oder Administratorrechte für einen Benutzer. 3. System zeigt aktualisierte Liste an Eingaben validieren Hauptakteur: Benutzer oder Coach. Erfolgsszenario: 1. System überprüft die Eingaben (Format, Werte usw.). Erweiterungen: 1a. Eine oder mehrere Eingaben sind nicht gültig oder fehlen: 1. System listet die ungültigen Eingaben auf. 2. Benutzer oder Coach korrigiert die ungültigen Eingaben oder bricht ab Objektmodell Ein Objektmodell beschreibt die Geschäftsobjekte und die Beziehungen zwischen Geschäftsobjekten einer Anwendung. Abbildung 3.2 stellt das Objektmodell von Cybercoach als UML- Klassendiagramm dar. Die Attribute der Klassen bezeichnen jeweils Objekteigenschaften, die persistent gespeichert werden Person Jeder Benutzer, Coach oder Administrator des Cybercoach-Systems wird als Person-Objekt repräsentiert. Person enthält die Daten Vorname, Nachname, -Adresse, Geburtsdatum, Geschlecht und Sprache. 26

27 3. Konzeption Login -userid : String -password : String 1 * Role -id : Integer -rolename : String -rolegroup : String 1 Person -userid : String -firstname : String -lastname : String -phone : String - String -dateofbirth : Date -gender : char -language : String +getage() : int Profile 1 * -id : Integer -validfrom : Date -validto : Date -weight : float -heigth : int -restingheartrate : int -injury : boolean 1 * +getbmi() : float Activity -id : String -datetime : Date -duration : int -distance : int -minaltitude : int -maxaltitude : int -avgheartrate : int -maxheartrate : int -calories : int -points : String +getcaloriescalculated() : int * 1 Address -id : Integer -street : String -zip : int -city : String -country : String * Phone -id : Integer -number : String -type : Byte 1 Discipline -id : Integer -name : String -description : String -energyconsumption : float Abbildung 3.2.: Das Objektmodell Login Das Login-Objekt enthält die Zugangsdaten einer Person zum System, also den Benutzernamen und das Passwort. Zwischen dem Person und Login besteht eine bidirektionale 1:1-Beziehung, das heisst beide Objekte besitzen eine Referenz zueinander Role Das Role-Objekt repräsentiert die Benutzerrolle einer Person. Benutzerrollen werden für das Sicherheitsmodell verwendet (siehe Abschnitte und 5.1.5) stellen abstrakte Namen für die Zugriffsberechtigungen auf bestimmte Mengen von Ressourcen dar. Der Name der Rolle wird im Role-Objekt durch die Eigenschaft rolename definiert. Cybercoach kennt zur Zeit drei Verschiedene Rollen: 27

28 3. Konzeption User Coach Administrator Die Eigenschaft rolegroup wird zur Zeit nicht verwendet. Zwischen Login und Role besteht eine unidirektionale 1:n-Beziehung. Ein Login-Objekt kann mehrere Role-Objekte referenzieren. Umgekehrt ist ein Role-Objekt genau einem Login-Objekt zugewiesen, besitzt jedoch keine Referenz zu diesem Address Jedem Person-Objekt ist ein Address-Objekt assoziiert, welches die Adressdaten enthält. Zwischen Person und Address besteht eine eine 1:1-Beziehung. Diese Beziehung ist unidirektional, das heisst, Person hat eine Referenz zu Address, aber nicht umgekehrt. Eine bidirektionale Beziehung wäre möglich, ist aber nicht unbedingt nötig. Aus Gründen der Einfachheit besitzt jede Person nur eine Adresse. Das Objektmodell könnte auch so erweitert werden, dass mehrere Adressen möglich sind, zum Beispiel eine Postadresse und eine Rechnungsadresse Phone Phone-Objekte bestehen aus einer Nummer und einem Typ. Mit der Typenbezeichnung werden beispielsweise Privat-, Geschäfts-, Mobil- oder Faxnummern unterschieden. Sind mit der Zeit neue Nummerntypen erforderlich, so können diese laufend hinzugefügt werden. Einem Person- Objekt können mehrere Phone-Objekte assoziiert werden, jedoch kann jedes Phone-Objekt nur zu einem Person-Objekt gehören. Es besteht also eine 1:n-Beziehung. Auch hier ist die Navigierbarkeit unidirektional Profile Ein wichtiges Geschäftsobjekt ist Profile. Es repräsentiert das athletische Profil eines Benutzers und enthält sein Gewicht, seine Grösse, seine Ruhe-Herzfrequenz, sowie Angaben über Verletzungen. Die Beziehung zwischen Person und Profile ist bidirektional, das heisst beide Objekte besitzen eine Referenz zueinander. Während jedes Profil genau zu einer Person gehört, kann eine Person mehrere, zeitlich aufeinanderfolgende Profile besitzen. Die Eigenschaften validfrom und validto des Profile-Objektes definieren das Zeitintervall, in welchem es gültig ist. Werden die Daten des athletischen Profils geändert, sorgt die Geschäftslogik dafür, dass das bisherige Profil abgeschlossen wird. Dies geschieht durch das Setzen der validto-eigenschaft des alten Profils auf den aktuellen Zeitstempel. Gleichzeitig wird ein neues Profil angelegt, welches den selben Zeitstempel als Wert für die validfrom-eigenschaft erhält. Die veränderten Daten werden anschliessend im neuen Profil abgespeichert. Somit gehen geänderte Werte nicht verloren und es entsteht eine History der Profildaten. Dies erlaubt es zum Beispiel, die Gewichtsentwicklung eines Benutzers über eine bestimmte Zeitperiode darzustellen oder auszuwerten. 28

29 3. Konzeption Activity Activity-Objekte repräsentieren Trainingsaktivitäten. Zwischen Profile und Activity besteht eine bidirektionale 1:n-Beziehung. Ein Profil kann mehrere Aktivitäten haben, aber jede Aktivität ist genau einem Profil zugeordnet. Activity enthält als Trainingsdaten unter anderem die Dauer, die zurückgelegte Distanz, die durchschnittliche Herzfrequenz, die maximale Herzfrequenz und die verbrauchten Kalorien. Die Eigenschaft points ist eine Zeichenkette, welche alle Messpunkte der Trainingsaktivität in einer bestimmten Syntax enthält. Mit datetime werden Datum und Zeit des Beginns der Aktivität angegeben. Beim Hinzufügen einer Aktivität sorgt die Geschäftslogik dafür, dass die Aktivität dem Profil mit dem entsprechenden Zeitintervall zugeordnet wird. Eine Aktivität ist genau dann dem richtigen Profil zugewiesen, wenn die beiden Bedingungen Activity.dateTime Profile.validFrom und Activity.dateTime < Profile.validTo erfüllt sind. Findet die Geschäftslogik kein Profil, welches die erste Bedingung erfüllt, kann der Vorgang nicht durchgeführt werden. Wird ein Profil gefunden mit Activity.dateTime Profile.validFrom, dessen validto Eigenschaft nicht definiert (null) ist, so wird dieses Profil als das Aktuelle betrachtet und die Aktivität wird diesem Profil zugewiesen. Bei der Zuweisung einer Aktivität zu einem Profil wird somit nicht die Zeitspanne der Aktivität betrachtet, sondern nur deren Startzeit. Dadurch wird garantiert, dass jede Aktivität nicht mehr als einem Profil zugeordnet werden kann Discipline Jedem Activity-Objekt ist genau ein Discipline-Objekt zugeordnet. Discipline repräsentiert eine Sportdisziplin. Mögliche Disziplinen sind zum Beispiel Laufen, Walking, Inline- Skating, Ski, Langlauf oder Schwimmen. Eine interessante Eigenschaft von Discipline ist energyconsumption. Sie gibt den Energieverbrauch der Disziplin pro Kilogramm Körpergewicht pro Stunde an. Die Geschäftsmethode getcaloriescalculated() von Activity verwendet diesen Wert, um den Kalorienverbrauch der Aktivität zu berechnen. Für die Berechnung werden zusätzlich duration und weight des zugehörigen Profils verwendet Schlussbemerkung Es gibt verschiedene Alternativen für das vorgestellte Objektmodell. Eine Idee wäre zum Beispiel, Aktivitäten nicht Profilen zu zuordnen, sondern Personen. Der Vorteil dieses Modells wäre, dass das beim Hinzufügen einer Aktivität nicht das Profil gesucht werden muss, welches dem Datum und der Zeit der Aktivität entspricht. Hingegen wäre es weniger geeignet für Operationen auf Aktivitäten, welche das zugehörige athletische Profil einbeziehen. Beispielsweise wäre die Implementation der Geschäftsmethode getcaloriescalculated() mit diesem Modell schwieriger Entwicklungsprozess Bei Software-Entwicklungsprozessen unterscheidet man heute grundsätzlich zwischen dem traditionellen Wasserfallmodell und iterativen Prozessen [Fow03]. Der Hauptunterschied zwischen den beiden Prozessen besteht darin, wie ein Software-Projekt in kleinere Einheiten aufgespaltet wird. Um eine Software zu entwickeln, müssen mehrere Aktivitäten durchgeführt werden: 29

30 3. Konzeption Analyse, Design, Programmierung, Tests und Auslieferung. Mittels dieser Aktivitäten wird das Projekt in mehrere Phasen unterteilt. Beim Wasserfallmodell wird ein Projekt auf der Grundlage dieser Aktivitäten aufgespaltet. Jede Phase hat wohldefinierte Start- und Endpunkte mit eindeutig definierten Ergebnissen und wird genau einmal durchlaufen. Demgegenüber stehen iterative Prozesse, welche ein Projekt anhand von Funktionalitäten aufteilen. Ein Projekt wird zum Beispiel in vier Iterationen aufgeteilt, welche jeweils einen Viertel der gesamten Funktionalität repräsentiert, wobei der ganze Software-Lebenszyklus durchlaufen wird: Analyse, Design, Programmierung und Tests. Das Problem beim traditionellen Wasserfallmodell ist, dass es schwierig ist, während des Projekts die Spezifikationen anzupassen. Ein Projekt entspricht deshalb bei seiner Fertigstellung unter umständen nicht mehr den Bedürfnissen des Kunden. Ein weiterer Nachteil des Wasserfallmodells besteht darin, dass es während des Projekts schwierig ist, zu sagen, ob der Zeitplan eingehalten werden kann. Heutzutage werden deshalb iterative Prozesse bevorzugt. Unter den iterativen Prozessen kann man unterscheiden zwischen eher formellen Modellen, wie zum Beispiel der Unified Process [Kru04] und agilen Prozessen [Coc01], wie zum Beispiel Extreme Programming [Bec99]. Der Unified Process ist ein anpassbares und erweiterbares Grundgerüst eines Entwicklungsprozesses. Der Prozess ist in vier Phasen aufgeteilt: Inception, Elaboration, Construction und Transition. Jede Projektphase hat spezielle Ziele und wird mit einem Meilenstein abgeschlossen. Projektphasen werden weiter durch Iterationen unterteilt. In jeder Iteration werden ausgewählte Anwendungsfälle (Use-Cases) analysiert, entworfen, implementiert und getestet. Ein wichtiger Aspekt des Unified Process ist die Modellierung mit UML. Agilen Prozesse sind leichtgewichtige Software-Entwicklungsprozesse mit dem Ziel, die Softwareentwicklung durch weniger Prozessbürokratie und stärkere Berücksichtigung menschlicher Aspekte effizienter zu gestalten. Agile Prozesse versuchen, die Entwurfsphase auf ein Mindestmass zu reduzieren und statt dessen so früh wie möglich zu ausführbarer Software zu gelangen, welche anschliessend in regelmässigen und kurzen Abständen vorgelegt wird. Es wird in sehr kurzen Iterationen von einem Monat oder weniger gearbeitet. Ein wichtiger Aspekt agiler Prozesse ist die Kommunikation. Dies spiegelt sich einerseits darin nieder, dass der Kunde während der Entstehung aktiv am Projekt beteiligt ist. Andererseits ist auch die Kommunikation zwischen den Entwicklern von grosser Bedeutung. Zum Beispiel wird in Extreme Programming grundsätzlich nur zu zweit Programmiert (Pair Programming [Bec99, Pai05]). Die Softwarequalität wird in agilen Prozesse unter anderem durch rigorose Unit-Tests sichergestellt. Das Cybercoach-Projekt wird in einem iterativen Prozess entwickelt. Mehrere zusammengehörige Anwendungsfälle oder Funktionalitäten werden jeweils in einer Iteration analysiert, entworfen, implementiert und getestet. Neue Funktionalitäten werden jeweils direkt in das bestehende Projekt integriert und getestet. Obwohl der Umfang der Software zu Beginn des Projekts definiert wird (siehe Abschnitt 1.2), wird die Anzahl und der genaue Inhalt der Funktionalitäten im Laufe des Projekts ständig angepasst. Grundlage für Entscheidungen bezüglich Inhalt von Funktionalitäten sind jeweils der aktuellen Zeitplan und Erfahrungen aus den vorhergehenden Iterationen. Für das Cybercoach-Projekt wird keiner der genannten Entwicklungsprozesse vollständig umgesetzt. Es werden jedoch Prinzipien angewendet, die in Extreme Programming und anderen agilen Prozessen sehr verbreitet sind. Ein Beispiel sind automatische Unit-Tests. Es wird nicht 30

31 3. Konzeption jede Klasse getestet, wie dies Extreme Programming verlangen würde, jedoch werden alle vom Business-Tier zur Verfügung gestellten Dienste rigoros getestet. Ein weiteres Prinzip, das in Cybercoach versucht wird umzusetzen, ist kontinuierlichen Integration [Fow05, Bec99]. Kontinuierliche Integration ist ein Prinzip von Extreme Programming mit dem Ziel, programmierten Code in kurzen aufeinanderfolgenden Zeitabständen immer wieder zu integrieren und zu testen. Der Kern dieses Prinzips ist ein vollständig automatisierter Build-Prozess, der jederzeit ausgeführt werden kann. Automatische Builds des gesamten Projekts können so mehrere Male pro Tag durchgeführt werden. Der Bulid-Prozess sollte dabei auch die Ausführung der automatischen Tests beinhalten. Abschnitt beschreibt, wie Tests und kontinuierliche Integration im Cybercoach-Projekt konkret umgesetzt werden Aufteilung des Projekts Die Aufteilung des Cybercoach-Projekts ist durch die multi-tier Architektur gegeben. Abbildung 3.3 zeigt anhand des 5-Tier-Modells, welche Schichten für das Cybercoach-System implementiert werden müssen. Der Client-Tier besteht in unserem Fall aus den Webbrowsern, die auf das System zugreifen. Der Integration-Tier wird durch den Applikationsserver realisiert, der die APIs für den Zugriff auf die Datenbank implementiert. Der Resource-Tier wird durch die relationale Datenbank gebildet. Diese drei Schichten werden somit bereits durch existierende Produkte realisiert. Client-Tier Browsers, Applets, Application clients Presentation-Tier JSP, Servlets, Struts Cybercoach-Projekt Business-Tier EJBs and other Business components Integration-Tier JDBC, JMS, Connectors Resource-Tier Databases, external systems, Legacy systems Abbildung 3.3.: Tiers im Cybercoach-Projekt Es bleit somit die Implementation des Business-Tiers und des Presentation-Tiers übrig. Kapitel 4 beschreibt die Implementation des Business-Tiers und Kapitel 5 die des Presentation- Tiers. 31

32 4. Implementation Business-Tier 4.1. Verwendung von Enterprise JavaBeans Die Geschäftslogik des Cybercoach-Projektes wird mit Enterprise JavaBeans implementiert. Wie in Abschnitt beschrieben, gibt es drei verschiedene Arten von Enterprise-Beans. Für Cybercoach werden zwei Arten verwendet: Session-Beans und Entity-Beans. Message-Driven- Beans werden nicht verwendet Session-Beans Session-Beans modellieren die Geschäftsprozesse der Anwendung. Jeder von einem Session- Bean zur Verfügung gestellten Dienst repräsentiert einen Anwendungsfall. Das bedeutet, dass jeder in Abschnitt 3.1 beschriebene Anwendungsfall durch eine oder mehrere Methoden eines Session-Beans abgebildet wird. Die Dienste für mehrere zusammengehörige Anwendungsfälle können jeweils in einem Session-Bean zusammengefasst werden. Das Cybercoach-Projekt besitzt zwei Session Beans: PersonManagerSessionBean ActivityManagerSessionBean PersonManagerSessionBean enthält Methoden für die Verwaltung von Personen und deren athletischen Profile. Dazu gehörern insbesondere das Hinzufügen, Verändern und Löschen von Personen. Daneben besitzt das Bean auch Methoden, die es erlauben, das aktuell gültige athletische Profil einer Person zu erhalten und zu verändern. ActivityManagerSessionBean enthält Methoden für die Verwaltung von Aktivitäten. Dazu gehörern vor allem das Hinzufügen, Verändern und Löschen von Aktivitäten. PersonManagerSessionBean und ActivityManagerSessionBean sind als Stateless-Session- Beans implementiert und besitzen daher keinen Zustand zwischen Methodenaufrufen. Jeder Methodenaufruf ist unabhängig und verrichtet seinen Dienst ohne auf Instanzvariablen zuzugreifen. Stateless-Session-Beans bedeuten vor allem einen Vorteil bezüglich Performanz. Im Gegensatz zu Stateful-Session-Beans können sie vom EJB-Container durch Instance swapping [MH01] äusserst effizient verwaltet werden Entity-Beans In der Regel greifen Session-Beans auf ein oder mehrere Entity-Beans zu. Entity-Beans modellieren die Geschäftsdaten der Anwendung. Jedes Geschäftsobjekt des Objektmodells in Abbildung 3.2 wird genau durch ein Entity-Bean abgebildet. Cybercoach besitzt somit acht Entity- Beans: PersonEntityBean 32

33 4. Implementation Business-Tier LoginEntityBean RoleEntityBean AddressBean PhoneEntityBean ProfileEntityBean ActivityEntityBean DisciplineEntityBean Entity-Beans repräsentieren Daten in einer Datenbank. Wird ein neues Entity-Bean kreiert, so muss ein neuer Datensatz in die Datenbank eingefügt und mit dem Bean assoziiert werden. Ändert sich der Zustand des Beans, so müssen die Änderungen mit den Daten in der Datenbank synchronisiert werden. Der Prozess der Koordination zwischen der Datenbank und den Daten, welche eine Bean-Instanz repräsentieren, wird Persistenz genannt. Jedes Entity-Bean besitzt einen Primärschlüssel, also ein Objekt, welches das Bean eindeutig identifiziert. Ein Primärschlüssel kann ein beliebiger serialisierbarer Typ sein, zum Beispiel String, Integer, Double oder eine selbst definierte Klasse. Ein Primärschlüssel wird in der Bean-Klasse als ein gewöhnliches Persistenzfeld definiert, welches im Deployment-Deskriptor als Primärschlüssel deklariert wird. Cybercoach verwendet XDoclet, um den Deployment- Deskriptor automatisch zu erzeugen (siehe Abschnitt 4.3.2). Mit XDoclet wird ein Primärschlüssel mit dem definiert (siehe Beispiel in Anhang B, Zeile 17). Im Cybercoach-Projekt besitzen die Beans LoginEntityBean und PersonEntityBean den Primärschlüssel userid vom Typ String. Der Wert von userid ist der vom Benutzer gewählte Benutzernamen. Alle anderen Entity-Beans haben einen automatisch generierten Primärschlüssel von Typ Integer. Automatisch generierte Primärschlüssel werden direkt von der Datenbank erzeugt. Die automatische Generierung eines Primärschlüssels wird durch die Anwendung des auto-increment = "true" auf die Get-Methode des Primärschlüsselfeldes aktiviert (siehe Beispiel, Zeilen 61 und 62). Mit weiteren Tags kann konfiguriert werden, wie der Primärschlüssel generiert werden soll (siehe Beispiel, Zeilen 22-29). Diese Tags sind abhängig von JBoss und werden von anderen Applikationsservern nicht unterstützt. Dies hat eine gewisse Einschränkung der Portabilität zur Folge, ist aber unumgänglich, da EJB 2.1 die automatische Generierung von Primärschlüsseln nicht unterstützt Container-Managed Persistence Die Entity-Beans des Cybercoach-Projekts werden mit Container-Managed Persistence (CMP) betrieben. Die Persistenz wird dabei automatisch von EJB-Container verwaltet. Entity-Beans mit CMP werden in EJB 2.X als abstrakte Klassen definiert. Die konkreten Bean-Klassen werden vom Container automatisch erzeugt. Jedes Persistenzfeld eines Entity-Beans besitzt abstrakte Get- und Set-Methoden und wird im Deployment-Deskriptor als CMP-Feld deklariert. Mit XDoclet wird ein CMP-Feld durch das definiert, welches direkt auf die Get-Methode des entsprechenden Persistenzfeldes angewendet wird (siehe Beispiel in Anhang B, Zeile 60). 33

34 4. Implementation Business-Tier Container-Managed Relationships Wie in Abschnitt 3.2 definiert wird, besteht ein Objektmodell nicht nur aus Geschäftsobjekten, sondern auch aus den Beziehungen zwischen den Geschäftsobjekten. Seit EJB 2.0 können Beziehungen zwischen Entity-Beans mit Container-Managed Relationships (CMR) modelliert werden. Es wird dabei zwischen den folgenden Typen von Beziehungen unterschieden: One-to-one relationships bezeichnen 1:1-Beziehungen. One-to-many relationships bezeichnen 1:n-Beziehungen. Many-to-one relationships bezeichnen n:1-beziehungen. Many-to-many relationships bezeichnen n:n-beziehungen. Bei allen vier Fällen kann ausserdem zwischen bidirektionalen und unidirektionalen Beziehungen unterschieden werden. Für den bidirektionalen Fall sind One-to-many- und Many-toone-Beziehungen identisch. Somit sind sieben verschiedene Typen von Beziehungen möglich. Wie in Abschnitt 3.2 erläutert wird, existieren im Cybercoach-Projekt One-to-one, One-tomany und Many-to-one Beziehungen, aber keine Many-to-many Beziehungen. Einige der Beziehungen sind bidirektional, andere nur unidirektional. Beziehungen werden in der Bean-Klasse wie CMP-Felder durch abstrakte Get- und Set- Methoden definiert. Ist die Multiplizität zum referenzierten Bean one, so ist der Rückgabetyp der Get-Methode und der Typ des Parameters der Set-Methode das Local- oder Remote- Interface des referenzierten Entity-Beans. Ist die Multiplizität zum referenzierten Bean many, so ist der Typ java.util.collection. Bei einer unidirektionalen Beziehung werden Get- und Set-Methoden nur beim Entity-Bean definiert, welches die Referenz zum anderen Bean hat. Das wird auf die Get-Methode eines Relationship-Feldes angewendet und definiert das Feld als CMR-Feld. Bei jeder Beziehung benötigt genau eines der beiden Entity-Beans einen Fremdschlüssel. Der Fremdschlüssel wird mit dem angegeben (siehe Beispiel in Anhang B, Zeilen ). Bei One-to-manyund Many-to-one-Beziehungen muss das Tag auf die Get-Methode des Beans mit der Multiplizität one angewandt werden Transaktionen Ein wichtiger Dienst von Enterprise JavaBeans ist das deklarative Transaktionsmanagement. Ohne diesen Dienst müssten Transaktionen von Hand kontrolliert werden, indem explizite Transaktionsgrenzen gesetzt werden. Das Setzten von expliziten Transaktionsgrenzen ist für den Entwickler oft eine schwierige Aufgabe. Es erfordert ausserdem, dass Transaktions-Code direkt in die Geschäftslogik geschrieben wird, was die Klarheit und Flexibilität des gesammten Codes verringert. Mit deklarativem Transaktionsmanagement können Transaktionen durch das Setzten von Transaktionsattributen im Deployment-Deskriptor definiert werden. Transaktionsattribute bestimmen den Gültikeitsbereich einer Transaktion. Sie können auf ein ganzes Enterprise-Bean oder auf einzelne Methoden angewendet werden. Im ersten Fall gilt für jede Methode des Beans das definierte Attribut. 34

35 4. Implementation Business-Tier Im Cybercoach-Projekt haben alle Methoden der Enterprise-Beans das Transaktionsattribut Required. Die Attribute werden mit dem definiert, das jeweils auf die ganze Bean-Klasse angewendet wird (siehe Beispiel in Anhang B, Zeilen 20 und 21). Client (EJB or App) EJB Thread of execution Client s transactional context EJB s transactional context Client (EJB or App) EJB no transactional context Abbildung 4.1.: Required Attribut, aus [MH01] Das Required Attribut bedeutet, dass die Methode des Enterprise-Beans im Gültikeitsbereich einer Transaktion aufgerufen werden muss. Falls der Client des Beans bereits Teil einer Transaktion ist, so wird das Bean automatisch in den Gültigkeitsbereich dieser Transaktion aufgenommen. Falls der Client des Beans jedoch nicht Teil einer Transaktion ist, so startet das Bean eine eigene neue Transaktion. Der Gültikeitsbereich der neuen Transaktion endet, sobald die aufgerufene Methode fertig ausgeführt ist. Abbildung 4.1 illustriert dieses Verhalten. Weitere Informationen über die verschiedenen Transaktionsattribute liefert zum Beispiel [MH01] Sicherheit Im Cybercoach-Projekt wird deklarative Sicherheit angewendet, um Ressourcen im Business- Tier zu schützen. Die zu schützenden Ressourcen sind die Methoden der Enterprise-Beans, welche von Webkomponenten oder anderen Enterprise-Beans aufgerufen werden. Wie bei den Webkomponenten basiert das Sicherheitsmodell von Enterprise JavaBeans auf Rollen (siehe Abschnitt 5.1.5). Eine Rolle ist ein abstrakter Name für die Zugriffsberechtigung auf eine bestimmte Menge von Ressourcen einer Anwendung. Das EJB-Sicherheitsmodell spezifiziert nur die Autorisierung eines Benutzers. Als Autorisierung bezeichnet man die Überprüfung der Zugriffsberechtigung auf geschützte Ressourcen. Die Authentifizierung, also die Überprüfung der Identität einer Person oder Entität, ist hingegen im EJB-Sicherheitsmodell nicht spezifiziert. In Cybercoach wird die Identität eines Clients durch die Webanwendung auf der Ebene des Presentation-Tiers überprüft. Enterprise-Beans werden automatisch mit der in der Webanwendung authentifizierten Identität aufgerufen. In Abschnitt wird beschrieben, wie ein Client auf der Ebene des Presentation-Tiers authentifiziert wird. Die Autorisierung basiert im EJB-Sicherheitsmodell auf Method-Permissions. Die Method- Permissions werden im Deployment-Deskriptor definiert und bestimmen, welche Rollen Zugriff auf welche Methoden haben. Sie können entweder auf ein ganzes Enterprise-Bean oder auf einzelne Methoden angewendet werden. Im ersten Fall gilt für jede Methode des Beans die definierte Method-Permission. 35

36 4. Implementation Business-Tier In Cybercoach werden die Methoden der beiden Session-Beans durch Method-Permissions geschützt. Die Permissions werden mit dem definiert, das jeweils direkt auf die entsprechende Methode angewendet wird. Zum Beispiel haben alle Rollen (User, Coach und Administrator) Zugriffsrecht auf die Methode getcurrentprofile() des PersonManagerSessionBeans, denn jeder Benutzer des Systems benötigt Zugang zu seinem athletischen Profil. Hingegen hat nur die Rolle Administrator Zugriff auf die Methode addrole(), mit der einer Person mehr Rechte vergeben werden kann Business-Tier-Patterns Im Cybercoach-Projekt werden vier Business-Tier-Patterns aus [ACM03] angewendet. Die vier Patterns arbeiten eng zusammen. Sie werden in den folgenden Abschnitten einzeln beschrieben Business Delegate Das Business Delegate Pattern [ACM03] verbirgt die Komplexität der Kommunikation mit der Service-Schnittstelle vor dem Client. Die Service-Schnittstelle wird in der Regel durch Session Façades gebildet, welche als Session-Beans implementiert sind (siehe Abschnitt 4.2.2). Greift ein Client direkt auf die Service-Schnittstelle zu, können Probleme entstehen. Ändert sich zum Beispiel der Code der Service-Schnittstelle, muss der Client-Code unter Umständen ebenfalls verändert werden. Dies erschwert die Wartbarkeit und schränkt die Flexibilität des Systems ein. Der direkte Zugriff auf die Service-Schnittstelle erfordert ausserdem, dass der Client Code für die Interaktion mit Naming-Diensten (zum Beispiel JNDI), für die Behandlung von Netzwerkfehlern und eventuell auch für Caching benötigt. Der Code wird dadurch komplex und schwer wartbar. Das Business Delegate kapselt den Zugriff auf die Service-Schnittstelle und verbergt dessen Implementationsdetails, insbesondre den Zugriffsmechanismus. Der Client wird durch die Verwendung eines Business Delegate transparent bezüglich Naming- und Lookup-Diensten, beispielsweise JNDI. Das Business Delegate ist zuständig für die Behandlung von Service-Level-Exceptions, zum Beispiel java.rmi.remoteexceptions. Anstelle der Service-Level-Exceptions wirft das Business Delegate Application-Level-Exceptions, welche für den Client einfacher zu behandeln sind. Das Business Delegate ist ein geeigneter Ort, um Resultate und Referenzen zu Geschäftskomponenten zu cachen. Caching kann hier zu einer erheblichen Verbesserung der Performanz beitragen, da Zugriffe über das Netzwerk erspart werden. In unserem Fall wird auf Caching in den Business Delegates verzichtet. Das Klassendiagramm in Abbildung 4.2 zeigt die allgemeine Struktur des Business Delegate Patterns, wie es in Cybercoach verwendet wird. BusinessDelegates greifen in der Regel auf SessionFacades (siehe Abschnitt 4.2.2) zu, welche die Service-Schnittstelle bilden. Typischerweise besteht zwischen BusinessDelegate und SessionFacade eine 1:1-Beziehung. Das Pattern verwendet ausserdem einen ServiceLocator (siehe Abschnitt 4.2.3), um die Session Façades zu lokalisieren. 36

37 4. Implementation Business-Tier Client accesses «POJO» BusinessDelegate remotely accesses «Session Bean» SessionFacade 1 1..* 1 1 * 1 uses «Singleton» ServiceLocator looks up Abbildung 4.2.: Business Delegate Klassendiagramm [ACM03] Obwohl Business Delegates direkt von der Präsentationslogik oder von Clients verwendet werden, wird das Pattern als Business-Tier-Pattern und nicht als Presentation-Tier-Pattern kategorisiert. Business Delegates bilden eine logische Erweiterung des Business-Tiers. Das Cybercoach-Projekt besitzt zwei Business Delegates: PersonManagerDelegate kapselt den Zugriff auf PersonManagerSessionBean ActivityManagerDelegate kapselt den Zugriff auf ActivityManagerSessionBean Session Façade Das Session Façade Pattern [ACM03] bietet eine Lösung für zwei Probleme eines multi-tier Systems: die Kontrolle über den Zugriff der Remote-Clients auf die Geschäftskomponenten und die Minimierung der Netzwerkbelastung. Typischerweise werden server-seitige Geschäftskomponenten als Entity-Beans realisiert. Erlaubt man einem Client, auf diese Komponenten direkt zuzugreifen, kann dies zu mehreren Problemen führen: Eine feste Kopplung zwischen Client und Geschäftskomponente impliziert eine direkte Abhängikeit zwischen diesen. Ändert sich die Schnittstelle der Geschäftskomponente, so müssen Anpassungen an den Clients vorgenommen werden. Ein direkter Zugriff erfordert vom Client, dass er über Geschäftslogik verfügt, um die Interaktion mit den verschiedenen Geschäftskomponenten zu koordinieren. Dies untergräbt das multi-tier Modell, wo die Geschäftslogik durch den Business-Tier repräsentiert wird. Existieren verschiedene Typen von Clients, führt ein direkter Zugriff auf die Geschäftskomponenten dazu, dass die Logik für die Interaktion mit den Komponenten auf jedem Client existiert. Duplizierter Code auf verschiedenen Clients erschwert die Wartbarkeit des Systems. 37

38 4. Implementation Business-Tier Client using only business components Client using Session Façades EJB Server Abbildung 4.3.: Netzwerkbelastung, aus [MH01] Der zweite Punkt, mit welchem sich Session Façade auseinandersetzt, ist die Minimierung der Netzwerkbelastung. Häufig haben Geschäftskomponenten eine feine Granularität. Greifen Clients direkt auf die Komponenten zu, verursacht dies eine Vielzahl von wiederholten Aufrufen über das Netzwerk. Dadurch wird das Netzwerk stark belastet, was unweigerlich zu einer schlechten Performanz führt. Abbildung 4.3 veranschaulicht diese Situation. Eine Session Façade kapselt die Geschäftskomponenten und bildet eine Service-Schnittstelle, die dem Client Dienste für ein oder mehrere Anwendungsfälle zur Verfügung stellt. Die Session Façades enthalten somit die Geschäftslogik des Systems. Clients greifen auf eine Session Façade zu, anstatt direkt auf die Geschäftskomponenten zuzugreifen. Im Gegensatz zu den Geschäftskomponenten haben die Session Façades eine grobe Granularität. Eine Session Façade wird als Session-Bean implementiert, welches mit allen beteiligten Geschäftskomponenten interagiert. Die Geschäftskomponenten sind häufig Entity-Beans, es können jedoch auch andere Session-Beans sein. Abbildung 4.4 zeigt die allgemeine Struktur des Session Façade Patterns. Client remotely accesses «Session Bean» SessionFacade accesses «Entity Bean» BusinessComponent 1..* 1..* 1..* 1..* Abbildung 4.4.: Session Façade Klassendiagramm [ACM03] Cybercoach besitzt zwei Session Façades, welche jeweils die Dienste für mehrere verwandte Anwendungsfälle implementieren: 38

39 4. Implementation Business-Tier PersonManagerSessionBean stellt Dienste für die Verwaltung von Personen und ihren athletischen Profilen zur Verfügung ActivityManagerSessionBean stellt Dienste für die Verwaltung von Aktivitäten zur Verfügung Abblidung 4.5 zeigt das Sequenzdiagramm des Session Façade Patterns am Beispiel des PersonManagerSessionBean. Beim Aufruf getcurrentprofile() sieht man, dass die Session Façade die Interaktion mit zwei Entity-Beans kapselt. Zuerst wird getcurrentprofile() des gewünschten PersonEntityBeans aufgerufen. Anschliessend wird auf dem retournierten ProfileEntityBean die Methode getdata() aufgerufen, welche ein Transfer Object (siehe Abschnitt 4.2.4) mit den Profil-Daten retourniert. Dieses Objekt wird schliesslich an den Client gesendet. Client PersonManagerSessionBean PersonEntityBean ProfileEntityBean updateperson() setdata() getcurrentprofile() getcurrentprofile() currentprofile getdata() Abbildung 4.5.: Session Façade Sequenzdiagramm Service Locator Ein Client muss die Komponenten und Dienste des Business-Tier lokalisieren können. Wenn zum Beispiel ein Business Delegate im Presentation-Tier auf eine Session Façade zugreifen will, muss es zuerst das Home-Objekt der Session Façade lokalisieren, um dann durch Aufruf der create() Methode eine Instanz der Session Façade zu erhalten. 39

40 4. Implementation Business-Tier Business-Tier-Komponenten wie Enterprise-Beans und Integration-Tier-Komponenten wie JDBC-Datenquellen werden in J2EE-Anwendungen typischerweise durch Naming- und Directorydienste lokalisiert. Clients verwenden JNDI (Java Naming and Directory Interface), um ein InitialContext-Objekt zu erhalten, welches die Bindungen der Komponenten-Namen zu den Objekten enthält. Wird der Lookup-Mechanismus mit JNDI direkt in den Clients implementiert, entstehen Probleme bezüglich der Komplexität, der Duplizierung von Code und der Hersteller-Abhängigkeit. Die Verwendung von JNDI erhöht die Komplexität des Codes durch die wiederholten Verwendung des InitialContext-Objektes, Lookup-Operationen, Class-Casting und die Behandlung von Exceptions. Der Anwendungs-Client sollte von dieser Komplexität isoliert werden. Wird JNDI ausserdem in verschiedenen Clients angewendet, entsteht duplizierter Code. Das dritte Problem ist die Abhängigkeit von Herstellern. Das InitialContext-Objekt ist eine herstellerspezifische Implementation. Eine direkte Verwendung dieses Objektes in den Anwendungs- Clients fürt deshalb zu schwer portierbarem Code. Das Service Locator Pattern [ACM03] löst die beschriebenen Probleme, indem es die Lokalisierung der Komponenten und Dienste in einem eigenen Objekt kapselt. Dadurch werden die Implementationsdetails des Lookup-Mechanismus vor dem Anwendungs-Client verborgen. Üblicherweise wird ein einziger Service Locator für die ganze Anwendung verwendet. creates Client 1..* uses 1 «Singleton» ServiceLocator 1 uses 1 InitialContext 1 1 maintains looks up Cache resolves Target * 1 caches Abbildung 4.6.: Service Locator Klassendiagramm [ACM03] Abbildung 4.6 zeigt die Struktur des Service Locator Patterns. ServiceLocator wird typischerweise als Singleton [GHJV95] implementiert. Durch einen Cache kann die Performanz des ServiceLocators optimiert werden. Der Cache hält Referenzen zu den Targets, die bereits lokalisiert wurden. Die Targets sind zum Beispiel Enterpriese-Beans oder JDBC-Datenquellen. 40

41 4. Implementation Business-Tier Die Klasse cybercoach.util.servicelocator implementiert den Service Locator für das Cybercoach-Projekt. Sie enthält folgende Methoden für die Lokalisierung von Komponenten und Diensten: getremotehome() gibt das Remote-Home-Objekt eines Enterprise-Beans zurück. Als Parameter wird der JNDI-Name des Beans übergeben. getlocalhome() gibt das Local-Home-Objekt eines Enterprise-Beans zurück. Als Parameter wird der JNDI-Name des Beans übergeben. getdatasource() gibt eine JDBC-Datenquelle zurück. Als Parameter wird der JNDI- Name der Datenquelle übergeben Transfer Object Das Transfer Object Pattern [ACM03] bietet eine Lösung für den Transport mehrerer Datenelemente zwischen verschiedenen Schichten der Anwendung. In J2EE-Anwendungen werden server-seitige Geschäftskomponenten in der Regel als Entity-Beans implementiert. Diese stellen feinkörnige Get- und Set-Methoden für die einzelnen Elemente der Komponente zur Verfügung. Ein Client muss daher mehrere Methodenaufrufe ausführen, um alle benötigten Daten zu erhalten. Dies führt zu Performanz-Problemen, da grundsätzlich davon ausgegangen werden muss, dass die Schichten über mehrere Maschinen verteilt sind. Die Vielzahl von Aufrufen zwischen physisch getrennten Maschinen bedeutet einen Netzwerk-Overhead. Aber auch wenn Client und EJB-Container in der selben JVM oder auf der selben physischen Maschine ausgeführt werden, ist die Vielzahl von Aufrufen auf verteilten Objekten ineffizient. Um mehrere Datenelemente über die Anwendungsschichten zu transportieren, sollte daher ein Transfer Object verwendet werden. Anstatt mehrere Datenelemente individuell zu senden oder zu empfangen, werden die Datenelemente durch ein Transfer Object in einer einzigen Datenstruktur übermittelt. creates/uses Client accesses «Enterprise JavaBean» Component creates/uses «Serializable POJO» TransferObject 1..* 1..* +getdata() : TransferObject +setdata() : void Abbildung 4.7.: Transfer Object Klassendiagramm [ACM03] Abbildung 4.7 zeigt die Struktur des Transfer Object Patterns. Ein TransferObject ist ein serialisierbares POJO, das von einer Component kreiert und an den Client gesendet wird. Umgekehrt kann ein Client eigene TransferObjects instanziieren, um Datenelemente an die Component zu senden. 41

42 4. Implementation Business-Tier Cybercoach besitzt mehrere Transfer Objects, um die Datenelemente der Entity Beans abzubilden. Für Methoden von Session-Beans, welche mehr als ein Parameter haben, wurden ebenfalls ein Transfer Objects eingeführt. Als Konvention haben die Klassennamen aller Transfer Objects das Postfix TO. In Cybercoach werden ausserdem zwei Strategien des Transfer Objects Pattern angewendet, welche in [ACM03] beschrieben werden: Bei der Updatable Transfer Objects Strategie werden Daten nicht nur von der Komponente zum Client transportiert, sondern neue Daten können auch vom Client zur Komponente übermittelt werden. Das Transfer Object muss dafür mutabel sein. Die Methode getdata() der Komponente kreiert ein neues Transfer Object, welches alle Werte der Komponente enthält. Die Methode setdata() akzeptiert ein Transfer Object, welches neue oder geänderte Daten enthält. Die Methode setzt alle Attribute der Komponente auf die entsprechenden Werte des Transfer Objects. Bei der Multiple Transfer Objects Strategie kann eine Komponente mehrere Transfer Objects von unterschiedlicher Granularität produzieren. Diese Strategie wird zum Beispiel beim ActivityEntityBean verwendet. Dessen Methode getdata() retourniert das Transfer Object ActivityTO, welches alle Daten der Aktivität enthält. Hingegen retourniert die Methode getbasicdata() das Transfer Object ActivityBasicTO, welches nur die wichtigsten Daten der Aktivität enthält. Dieses wird aus Performanzgründen bei Suchabfragen verwendet. Die Abbildung 4.8 zeigt das Sequenzdiagramm eines Transfer Objects am Beispiel von PersonTO. Der Client ist typischerweise ein Session-Bean Entwicklungszyklus Build-Prozess Der Build-Prozess des Cybercoach-Projekts ist vollständig automatisiert. Als Build-Werkzeug wird Ant [Ant05, HL02] verwendet. Ant wird durch die Build-Datei build.xml gesteuert. In dieser Datei werden die für einen Build notwendigen Schritte in Form von sogenannten Targets definiert. Targets sind vergleichbar mit Funktionen in Programmiersprachen und enthalten Aufrufe von Ant-Tasks. Ein Task ist ein untrennbarer Arbeitsschritt. In der Build-Datei werden ebenfalls die Abhängigkeiten zwischen den Targets definiert. Beim Aufrufen eines Targets löst Ant diese Abhängigkeiten auf und arbeitet die Targets entsprechend ab. Ein vollständiger Build-Prozess des Cybercoach-Projekts durchläuft folgende Targets: ejbdoclet: Codegenerierung mit XDoclet. compile: Kompilieren des Quellcodes. ejb.jar, war und ear: Packaging der JAR-, WAR- und EAR-Archive. deploy: Deploy der Anwendung auf den Applikationsserver. test: Automatische Tests der Anwendung. 42

43 4. Implementation Business-Tier Client PersonEntityBean getdata() create PersonTO serialize and send getfirstname() getlastname() Abbildung 4.8.: Transfer Object Sequenzdiagramm Durch die Automatisierung des Build-Prozesses und durch die Integration der Tests in den Build-Prozess (siehe Abschnitt 4.3.3) wird das Prinzip der kontinuierlichen Integration [Fow05, Bec99] verwirklicht. Wie in Abschnitt 3.3 beschrieben, ist kontinuierliche Integration ein strenges Prinzip von Extreme Programming. Ziel ist, programmierten Code in kurzen aufeinanderfolgenden Zeitabständen immer wieder zu integrieren und zu testen. Tests sollten dabei zu jeder Zeit mit einem einzigen Befehl automatisch ausgeführt werden können Codegenerierung Die Implementation von Enterprise-Beans ist mit recht hohem Aufwand verbunden. Neben der Bean-Klasse müssen Komponenten- und Home-Interfaces definiert werden und Konfigurationen im Deployment-Deskriptor vorgenommen werden. Um diesen Arbeitsaufwand zu verringern, bietet der Codegenerator XDoclet [XDo05, WR03] hilfreiche Dienste. XDoclet arbeitet als eine Art Präprozessor, welcher XDoclet-Tags in den Java-Quelldateien auswertet und aus diesen weitere Dateien erzeugt. In unserem Fall werden auf diese Weise das Komponenten-Interface, das Home-Interface und der Deployment- Deskriptor erzeugt. XDoclet-Tags werden analog zu Javadoc-Tags in Doc-Kommentaren direkt im Quellcode definiert. Einige Tags wirken auf die ganze Klasse, zum andere dagegen nur auf Methoden, zum Manche Tags können optional Argumente enthalten, die als Schlüssel-Wert-Paare angegeben werden. Sämtliche Informatio- 43

44 4. Implementation Business-Tier nen, die für das Erzeugen des Standard-Deployment-Deskriptors und des JBoss-Deployment- Deskriptors notwendig sind, werden mittels diesen Tags angegeben. Zudem wird mit dem angegeben, welche Methoden im Komponenten-Interface veröffentlicht werden sollen (siehe Beispiel in Anhang B). Der Generierungsprozess wird vollständig in den Build-Prozess integriert, indem XDoclet durch das Build-Werkzeug Ant gestartet wird. Das XDoclet-Paket bietet dafür eine Reihe neuer Ant-Tasks. Für das Cybercoach-Projekt wird der Task ejbdoclet verwendet, welcher in der Lage ist, die Deployment-Deskriptoren und Interfaces zu generieren. In der kommenden Spezifikation EJB 3.0 [Ort04] wird die Entwicklung von Enterprise- Beans stark vereinfacht. Es wird nicht mehr notwendig sein, Komponenten-Interfaces, Home- Interfaces und Deployment-Deskriptoren zu definieren. Alle benötigten Metainformationen werden stattdessen in Form von Annotations in der Bean-Klasse definiert. Durch die neue Spezifikation würde der Einsatz von XDoclet im Cybercoach-Projekt überflüssig Tests Der Business-Tier von Cybercoach wurde mit automatischen Tests getestet. Da Session Façades den Zugriff auf Entity-Beans kapseln und die Geschäftslogik implementieren, bilden sie den globalen Zugriffspunkt auf den Business-Tier. Sie sind somit der ideale Ort, um das allgemeine Funktionieren der Anwendung zu testen. Für jede Session Façade wurde deshalb eine Testklasse implementiert, welche die Geschäftsmethoden testet. Für durchgehende Softwaretests im Sinne von Extreme Programming [Bec99] müsste jede einzelne Klasse durch Unit-Tests getestet werden. Beim Cybercoach-Projekt wurde auf dies verzichtet. Die Tests der Session Façades bilden jedoch ein akzeptabler Kompromiss. Das Testen von Enterprise-Beans ist mit einigen Schwierigkeiten verbunden. Cybercoach verwendet Container-Managed Persistence (CMP), so dass der Container zuständig für die Persistenz ist. Entity-Beans mit CMP werden in der EJB 2.X Spezifikation als abstrakte Klassen definiert. Jedes Persistenz-Feld besitzt abstrakte Get- und Set-Methoden. Die konkreten Klassen der Entity-Beans werden vom Container automatisch erzeugt und sind lokal nicht verfügbar. Entity-Beans können daher nicht lokal getestet werden, sondern müssen in einem Container ausgeführt werden, um getestet werden zu können. Für das Testen von Enterprise-Beans bieten sich somit zwei Möglichkeiten an: entweder die Tests werden auf dem Client ausgeführt und greifen auf die Enterprise-Beans im Container zu oder die Tests werden direkt auf dem Server ausgeführt. Client-seitige Tests haben einige Nachteile: Enterprise-Beans, welche nur ein lokales Interface besitzen, können nicht entfernt aufgerufen werden und somit nicht client-seitig getestet werden. Oft werden Enterprise-Beans von server-seitigem Code, zum Beispiel von einer Webanwendung, aufgerufen. In diesem Fall werden die Tests in einer anderen Umgebung ausgeführt, als der Produktionscode, was zu unterschiedlichem Verhalten führen kann. Für das Cybercoach-Projekt werden deshalb server-seitige Tests, so genannte In-Container- Tests, verwendet. Das quelloffene Framework Cactus [Cac05] bietet eine komfortable Möglichkeit, um server-seitige Unit-Tests zu erstellen. Cactus ist eine Erweiterung des Testframeworks JUnit [JUn05]. 44

45 4. Implementation Business-Tier TestCase Redirector Proxy TestCase Client side Server side Server side classes Abbildung 4.9.: Lebenszyklus eines Cactus-Tests [Cac05] Abblidung 4.9 zeigt den Lebenszyklus eines Cactus-Tests. Auf der Client-Seite ist die Cactus- Logik in den TestCase-Klassen implementiert. Im Moment stellt Cactus drei verschiedene TestCase-Klassen zur Verfügung: ServletTestCase, JspTestCase und FilterTestCase. Alle Klassen sind von der JUnit Klasse TestCase abgeleitet. Wie bei JUnit kann jede dieser Klassen mehrere Tests enthalten. Auf der Server-Seite ist die Cactus-Logik im Redirector Proxy implementiert. Der Redirector Proxy agiert als Proxy auf der Server-Seite der TestCase-Klasse. Dies bedeutet, dass die TestCase-Klasse zweimal instaziiert wird: einmal auf der Client-Seite durch den JUnit- Test-Runner und einmal auf der Server-Seite durch den Redirector Proxy. Die Instanz auf der Client-Seite baut eine HTTP-Verbindung zum Redirector Proxy auf. Der Proxy führt dann die Tests der server-seitigen TestCase-Klasse aus. Anschliessend werden die Testresultate zurück an den Client gesendet, wo sie vom Test-Runner angezeigt werden. Im Moment stellt Cactus noch keine spezielle TestCase Klasse für Enterprise JavaBeans zur Verfügung. Deshalb sind im Cybercoach-Projekt die Testklassen für die Session Façades von ServletTestCase abgeleitet. Eine Vorraussetzung um Enterprise-Beans testen zu können, ist ein bekannter Zustand der Datenbank. Das quelloffene Framework DBUnit [DBU05, Glo04] bietet eine elegante Lösung, um die Datenbank zu kontollieren und zwischen den Tests in einen definierten Zustand zu setzten. DBUnit löscht vor jedem Test die entsprechenden Datenbanktabellen und importiert anschliessend Testdaten, welche in XML-Dateien definiert werden. Die Tests sind im Cybercoach-Projekt vollständig in den Build-Prozess integriert. Cactus bietet dafür eine Integration mit dem Build-Werkzeug Ant. Das Ant-Target cactifywar erweitert ein bestehendes Web-Application-Archive (WAR) mit den nötigen Elementen, um die Cactus-Tests ausführen zu können. Dies beinhaltet die Cactus-Bibliotheken und die Definition der Redirector Proxies im Deployment-Deskriptor. Zusätzlich wurde ein eigenes Ant-Target geschrieben, welches das mit den Tests erweiterte J2EE-Modul auf den Applikationsserver lädt und anschliessend die Tests ausführt. Die Testresultate werden in der Kommandozeile von Ant angezeigt. 45

46 4. Implementation Business-Tier 4.4. Mögliche Erweiterungen Als mögliche Erweiterungen für den Business-Tier werden folgende Punkte vorgeschlagen: Der funktionelle Umfang von Cybercoach kann erweitert werden. In Abschnitt 1.2 wird der Umfang von Cybercoach auf die Konzeption und Implementation eines Systems für die grundlegenden Funktionen der Benutzerverwaltung, der Verwaltung von Trainingseinheiten und der Erzeugung von Trainingsstatistiken beschränkt. Es werden jedoch auch einige Zusatzfunktionen erwähnt, mit welchen Cybercoach erweitert werden könnte. Der funktionelle Umfang des Business-Tier könnte mit diesen Zusatzfunktionen erweitert werden. Eine dieser Zusatzfunktionen ist das Erstellen von personalisierten Trainingsplänen. Dazu müsste der Business-Tier Dienste zur Verfügung stellen, die es einem Coach erlauben, anderen Benutzer bestimmte Trainigsaufgaben zu stellen. Diese Zusatzfunktion würde eine Erweiterung des bestehenden Objektmodells und der implementierten Anwendungsfälle voraussetzten. Anstatt von einem Coach könnten Trainingspläne auch von einem intelligenten System automatisch erzeugt werden. Dieses intelligente System wäre Bestandteil des Business-Tier. Um ein möglichst vollständiges Beispiel einer J2EE-Anwendung zu erhalten, kann der Business-Tier mit weiteren Technologien erweitert werden. Dazu gehören insbesondere Message-Driven-Beans und Webservices. Message-Driven-Beans verarbeiten asynchrone Nachrichten und erlauben zum Beispiel die Integration mit Legacy-Systemen. Webservices unterstützen die direkte Interaktion mit anderen Anwendungen durch den Austausch XML-basierter Nachrichten über das Internet. Ein Webservice könnte zum Beispiel eingesetzt werden, um die Bezahlung per Kreditkarte zu implementieren. Cybercoach kann durch rigorose Unit-Tests erweitert werden. Im bestehenden Projekt werden die Session-Beans server-seitig getestet. Die server-seitigen Tests könnten auf die Entity-Beans erweitert werden. Auch Business Delegates, Transfer Objekte und Hilfsklassen wie der Service Locator könnten getestet werden. Dabei müssten verschiedene Strategien in Erwägung gezogen werden, zum Beispiel könnten einige der Klassen auch lokal getestet werden. Neben den Unit-Tests könnten zusätzlich Performanz-Tests durchgeführt werden. Dadurch liessen sich Engpässe im Business-Tier erkennen und das System könnte für erhöhtes Zugriffsaufkommen optimiert werden. 46

47 5. Implementation Presentation-Tier 5.1. Verwendung von Servlet, JSP und Struts Struts [Str05, Hus02] ist ein Framework für die Entwicklung von Webanwendungen, welches auf den J2EE-Technologien Servlet und JSP aufbaut. Einer der Hauptgründe für die Verwendung von Struts als Grundlage für die Cybercoach-Webanwendung ist die Tatsache, dass das Framework mehrere Presentation-Tier-Patterns aus [ACM03] anwendet Struts Architektur Struts verwendet eine Model-View-Controller-Architektur (siehe Abschnitt 2.3.2). Das Struts ActionServlet kontrolliert den Navigationsfluss. Die Struts Action-Klassen werden verwendet, um auf die Dienste des Business-Tier zuzugreifen. Erhält das ActionServlet einen Request vom Container, so bestimmt es anhand der URI, beziehungsweise des Pfades, welche Subklasse von Action zuständig ist, um den Request zu bearbeiten. Die entsprechende Action greift dann auf den Business-Tier zu, um Informationen aus der Datenbank oder anderen Ressourcen zu erhalten. JSP JSP Form Initial Page (HTML/JSP) ActionServlet Action struts-config.xml Abbildung 5.1.: Struts Übersicht, aus [Hus02] Für die Bearbeitung eines Requests muss die Action-Klasse die Eingaben des Benutzers kennen. Das ActionServlet bündelt die Benutzereingaben in einem JavaBean und übergibt dies der Action. JavaBeans für Eingaben werden in Struts als Subklassen von ActionForms implementiert. Jeder HTTP-Request muss mit einer HTTP-Response beantwortet werden. In der Regel generiert eine Struts Action die Response nicht selber, sondern leitet zu einer JSP-Seite weiter. Die ActionForward Klasse wird verwendet, um den Pfad zu einer bestimmten Seite unter einem logischen Namen abzuspeichern. Ist eine Action fertig ausgeführt, so gibt sie die passende 47

48 5. Implementation Presentation-Tier ActionForward zurück. Das ActionServlet verwendet den darin gespeicherten Pfad um die entsprechende Seite aufzurufen und die Response zu erstellen. Alle Details, die für die Ausführung einer Action-Klasse notwendig sind, werden in einem ActionMapping-Objekt gebündelt. Jedes ActionMapping bezieht sich auf einen spezifischen Uniform Resource Identifier (URI). Wird dieser URI vom Client angefordert, ermittelt ActionServlet das ActionMapping Objekt. Dieses Objekt bestimmt, welche Actions, ActionForms und ActionForwards für die Ausführung des Requests zu verwenden sind. Abbildung 5.1 beschreibt, wie die Struts Komponenten zusammenarbeiten. Die Details der ActionMappingss, ActionForms und ActionForwards werden in der Konfigurationsdatei struts-config.xml deklariert. Siehe dazu Abschnitt Für die Entwicklung einer spezifischen Webanwendung mit dem Struts-Framework sind im Wesentlichen folgende Arbeitsschritte notwendig: Implementation der JSP-Seiten. Die Seiten können HTML-Formulare für die Benutzereingabe enthalten. Implementation der Action-Subklassen. Implementation der ActionForm-Subklassen. Struts Konfiguration. Die Cybercoach-Webanwendung enthält mehrere JSP-Seiten für die Eingabe und Darstellung von Daten. Die Präsentationslogik ist durchgehend mit Struts Custom-Tags implementiert. Die Seiten enthalten keinen eingebetteten Java-Code, sogenannten Scriplet-Code. Dadurch wird die Trennung zwischen den Views und der Kontroll-, Zugriffs- und Formatierungslogik garantiert. In Cybercoach werden alle Actions von der Basisklasse BaseAction abgeleitet, welche selber implementiert wurde. BaseAction ist eine Erweiterung der Struts Action-Klasse und enthält häufig verwendete Methoden. Diese können von den Subklassen verwendet werden, was das Duplizieren von Code verhindert. Für jede Operation die der Benutzer durchführen kann, existiert eine eigene Action-Klasse. Einige Beispiele sind das Hinzufügen, Bearbeiten und Löschen eines Benutzers oder die Anzeige von Aktivitäten. Für jedes HTML-Formular in Cybercoach existiert eine Subklasse von ActionForm. Zum Beispiel existiert ein ActionForm für die Angaben einer Benutzerregistration oder für die Suchkriterien der Aktivitätenanzeige. ActionForms enthalten jeweils eine Get- und Setmethode für jedes Feld des Formulars Struts Konfiguration Die Struts-Konfigurationsdatei struts-config.xml wird verwendet, um wichtige Komponenten des Frameworks zu laden. Die Gesamtheit dieser Objekte definiert die Struts Konfiguration. Zusammen mit dem Struts ActionServlet bildet die Struts Konfiguration die Kontroll-Schicht der Anwendung. Die Struts-Konfigurationsdatei ist ein XML-Dokument. Jedes XML-Element der Datei entspricht einem Java-Objekt. Für jedes Element in der Konfigurationsdatei kreiert der Struts- Controller das entsprechenden Java-Objekt bei der Initialisierung der Anwendung. Die Konfigurationsdatei für Cybercoach enthält im Wesentlichen drei Arten von Elementen: eine Menge 48

49 5. Implementation Presentation-Tier von form-bean Elementen, eine Menge von globalen forward Elementen und eine Menge von action Elementen. Das Element form-bean beschreibt eine ActionForm-Subklasse, die von einem action Element referenziert werden kann. Das Element forward beschreibt ein ActionForward-Objekt, das in der Anwendung als Rückgabewert für die Action-Objekte zur Verfügung steht. Das Element action beschreibt ein ActionMapping-Objekt. Ein ActionMapping enthält die URI, welche verwendet wird, um die entsprechende Action aufzurufen. Die URI ist ein logischer Identifikator oder Pfad für die Action. Neben der URI enthält ein ActionMapping andere wichtige Eigenschaften, wie zum Beispiel eine Referenz zur ActionForm-Subklasse, die von der Action verwendet wird. Einen Ausschnitt der Struts-Konfigurationsdatei des Cybercoach-Projekts ist in Anhang C.2 enthalten Internationalisierung Internationalisierung ist der Prozess der Konzeption einer Anwendung, so dass sie an verschiedene Sprachen und Regionen angepasst werden kann, ohne dass Veränderungen am Code notwendig sind [Hus02]. Der englische Begriff internationalization wir häufig als i18n abgekürzt, da zwischen dem ersten i und dem letzten n des Wortes genau 18 Buchstaben stehen. Struts ist von Grund auf internationalisiert. Das Framework baut dabei auf die von Java Internationalization [J2S05] zur Verfügung gestellten Klassen und Pakete auf. Sprachabhängige Texte und Meldungen werden dabei in separaten Dateien, sogenannten Resource-Bundles definiert. Diese Dateien enthalten eine Liste mit Schlüssel-Werte-Paaren, wobei bei jeder Wert einem sprachabhängigen Text entspricht. Mittels spezifischen Custom-Tags der Struts Tag- Library können diese Texte in HTML-Seiten dargestellt werden. Dabei wird automatisch das Resource-Bundle für die aktuell definierte Sprache verwendet. Für die Cybercoach-Webanwendung werden folgende Resource Bundles zur Verfügung gestellt: MessageResources.properties enthält alle englischen Texte. MessageResources de.properties enthält alle deutschen Texte. MessageResources fr.properties enthält alle französischen Texte. Eine neue Sprache kann einfach hinzugefügt werden, indem ein Ressource Bundle erstellt wird, welches die übersetzten Texte enthält. Zusätzlich muss die Webanwendung so erweitert werden, dass man die neue Sprache auswählen kann Validation der Benutzereingaben Benutzereingaben werden in der Regel nicht im Business-Tier validiert [Hus02]. Business-Tier- Methoden erwarten korrekte und sinnvolle Daten und überprüfen diese in den meisten Fällen nicht auf Fehler. Natürlich ist der Business-Tier zuständig, um Daten zu überprüfen, die im Kontext mit Geschäftsobjekten stehen. Zum Beispiel ist er für die Überprüfung zuständig, 49

50 5. Implementation Presentation-Tier ob ein Benutzername mit einem gegebenen Passwort übereinstimmt. In solchen Fällen kann eine Business-Tier-Methode eine Exception werfen. Der Business-Tier ist aber nicht zuständig, einen Dialog mit dem Benutzer zu führen, um eine fehlerhafte Eingabe zu korrigieren. Auf der anderen Seite ist eine rein client-seitige Validation nicht sicher. Zwar ist es durchaus sinnvoll, Eingaben auf der Client-Seite zum Beispiel mit JavaScript zu überprüfen. Dadurch wird eine wiederholte Übertragung der Daten zum Server verhindert. Eine Überprüfung auf dem Client kann jedoch umgangen oder ausgeschalten werden und ist deshalb allein nicht genügend. Benutzereingaben werden deshalb in der Regel im Presentation-Tier validiert. Eine Webanwendung benötigt folgende Validations-Funktionen: Erfordern, dass ein Feld einen Wert enthält (nicht leer ist). Erfordern, dass ein gegebener Wert einem bestimmten Muster entspricht oder in einem bestimmten Bereich liegt. Überprüfen eines ganzen HTML-Formulars und Rückgabe einer Fehlerliste. Vergleichen zweier Felder. Rückgabe des ursprünglichen Wertes für die Korrektur. Anzeige von sprachabhängigen Fehlermeldungen. Um diese Funktionen anzubieten, hat das Struts-Framework den Jakarta Commons Validator [Com05] integriert. Damit die Eingaben eines HTML-Formulares mit dem Commons Validator überprüft werden, muss das entsprechende ActionForm von der Klasse ValidatorForm abgeleitet werden. Für jedes Formularfeld können ein oder mehrere Validations-Regeln angegeben werden. Die Regeln werden auf deklarative Weise in einer XML-Datei definiert. Commons Validator enthält bereits eine Menge vordefinierter Regeln, zum Beispiel für die Überprüfung von Typen, Wertebereichen oder Mustern mittels regulären Ausdrücken. Es besteht auch die Möglichkeit weitere Regeln selber zu definieren. Die HTML-Formulare in Cyberocoach werden ausschliesslich vom Commons-Validator überprüft. Alle Regeln für die Formulare werden in der Datei validation.xml definiert. Anhang C.3 enthält einen Ausschnitt dieser Datei. Auf den Zeilen kann man zum Beispiel sehen, wie die Validation des Geburtsdatums konfiguriert wird Sicherheit Sicherheit ist ist ein grundlegender Teil einer verteilten Anwendung. Es ist nötig, den Zugriff bestimmter Ressourcen der Anwendung auf autorisierte Benutzer einzuschränken. Als Autorisierung bezeichnet man die Überprüfung der Zugriffsberechtigung auf geschützte Ressourcen. Die Autorisierung erfolgt nach einer erfolgreichen Authentifizierung. Authentifizierung bezeichnet den Vorgang, die Identität einer Person oder einer Entität zu überprüfen. Dies kann zum Beispiel durch eine Passwortabfrage oder durch Überprüfung von biometrischen Daten erfolgen. 50

51 5. Implementation Presentation-Tier Die Sicherheit der Cybercoach-Webanwendung wird durch die deklarative Sicherheit der J2EE-Plattform gewährleistet. Deklarative Sicherheit oder declarative Security [BGH + 04] beschreibt die Sicherheits-Struktur einer Anwendung in einem Deployment-Deskriptor und nicht im Programmcode. Die J2EE-Spezifikation definiert ein rollenbasiertes Sicherheitsmodell, sowohl für Webkomponenten als auch für Enterprise-Beans. Eine Rolle ist ein abstrakter Name für die Zugriffsberechtigung auf eine bestimmte Menge von Ressourcen einer Anwendung. In Cybercoach existieren drei verschiedene Rollen: User ist der normale Benutzer. Er darf alle Grundfunktionen des Cybercoach-Systems ausführen. Coach hat mehr Rechte als der User. Er darf zum Beispiel die Daten anderer Benutzer einsehen. Administrator hat am meisten Rechte. Er darf zum Beispiel die Rechte anderer Benutzer ändern. Registriert sich eine Person im Cybercoach-System, hat sie standardgemäss die Rolle User. Ein Administrator hat dann die Möglichkeit, ihr die Coach- oder sogar die Administrator-Rolle zuzuteilen. Die Authentifizierung in der Cybercoach-Webanwendung erfolgt über die sogenannte Formbased Authentication. Wenn ein nicht-authentifizierter Client eine beschützte Ressource anfordert, wird er auf eine Login-Seite umgeleitet. Nach der Eingabe von Benutzernamen und Passwort überprüft der Server die Angaben. Ist der Login erfolgreich, leitet der Server den Client auf die angeforderte Ressource weiter. Ansonsten wird er auf eine Fehler-Seite weitergeleitet. Die Login- und Fehler-Seite können im web.xml Deployment-Deskriptor konfiguriert werden. Die Details des Authentifizierung-Mechanismus werden von der J2EE-Spezifikation nicht definiert und sind abhängig vom verwendeten Applikationsserver. JBoss erlaubt die Anpassung des Authentifizierung-Mechanismus durch die Konfiguration von Login-Modulen. Der konkrete Mechanismus wird definiert, indem ein Login-Modul konfiguriert wird, welches der Sicherheits- Domain entspricht, die für die J2EE-Komponenten verwendet wird. Das Login-Modul wird in der Konfigurationsdatei login-config.xml von JBoss definiert. Da in Cybercoach die Benutzernamen, Passwörter und Rollen in einer relationalen Datenbank vorhanden sind, wird das JDBC-basierte Modul DatabaseServerLoginModule verwendet. Ist ein Client authentifiziert, muss er für den Zugriff auf eine Ressource autorisiert werden. In J2EE-Webanwendungen bestimmen Security-Constraints, welche Rollen für den Zugriff auf eine bestimmte Menge von Web-Ressourcen autorisiert sind. Die Security-Constraints werden im web.xml Deployment-Deskriptor definiert. Anhang C.1 enthält einen Ausschnitt dieser Datei. Zum Beispiel sieht man auf den Zeilen 33-52, dass Clients mit der Rollen User, Coach oder Administrator Zugriff auf die Anzeige von Aktivitäten haben. Auf den Zeilen sieht man, dass nur Clients mit den Rolle Administrator Zugriff auf die Administrationsseite für die Änderung von Benutzerrechten haben. Es gibt auch ungeschütze Ressourcen, dass heisst Ressourcen, auf die alle Clients Zugriff haben. Zum Beispiel sind die Login-Seite und die Seite für die Benutzerregistrierung nicht geschützt. 51

52 5. Implementation Presentation-Tier 5.2. Presentation-Tier-Patterns Wie bereits erwähnt, wird Struts vor allem deshalb als Grundlage für die Implementation des Presentation-Tiers verwendet, weil das Framework mehrere der Presentation-Tier-Patterns aus [ACM03] anwendet. Die folgenden Abschnitte beschreiben, wie Struts die verwendeten Patterns umsetzt und wie diese in das Cybercoach-Projekt integriert werden Front Controller und Application Controller Eine Webanwendung benötigt einen zentralen Zugriffspunkt. Ohne zentralen Zugriffspunkt wird gemeinsamer Code für verschiedene Requests an mehreren Orten vervielfacht, zum Beispiel in verschiedenen JSP-Seiten. Wenn die Kontroll-Logik mit View-Logik vermischt wird, ist die Anwendung nicht modular und die Wartbarkeit des Systems nicht gewährleistet. Das Front Controller Pattern [ACM03] zentralisiert die Kontroll-Logik, welche ansonsten in verschiedenen Views vervielfacht wird. Für JSP-Views zum Beispiel, vermindert der Front Contoller die Versuchung, grosse Mengen Java-Code direkt in die JSP-Seiten einzubetten. Ein Front Controller bildet den zentralen Zugriffspunkt einer Webanwendung und verarbeitet alle eingehenden Requests. Ein Front Controller verwendet typischerweise einen Application Controller, um die Requests zu verarbeiten. Das Application Controller Pattern [ACM03] zentralisiert die Verwaltung der Actions und Views: Action-Management bezeichnet die Lokalisierung und Weiterleitung zu den spezifischen Actions. Eine Action führt die eigentliche Arbeit der Operation aus, welche einem eingehenden Request entspricht. View-Management bezeichnet die Lokalisierung und Weiterleitung zu der entsprechenden View. Das Klassendiagramm in Abbildung 5.2 zeigt die Struktur der beiden Patterns Front Controller und Application Controller. FrontController bildet den zentralen Zugriffspunkt für den Request des Client. Die Verarbeitung des Requests wird an den ApplicationController delegiert, welcher einen Mapper verwendet, um den Request zu einem Target aufzulösen. Targets sind Ressourcen wie Views oder Commands. Map enthält die Referenzen zu den Targets. Die beiden Patterns Front Controller und Application Controller werden vom Struts Framework angewendet. Die Stereotypen im Klassendiagramm geben die Struts-Klassen an, welche die entsprechenden Pattern-Klassen implementieren. Die ActionServlet-Klasse ist ein Front Controller. Sie delegiert die Verarbeitung der Requests dem RequestProcessor, welcher den Application Controller repräsentiert. Commands werden in Struts als Action-Klassen und Views als JSP-Seiten implementiert. Die Struts-Klasse ModuleConfig und die Konfigurationsdatei struts-config.xml realisieren einen Mapper für das Action-Management. Um Requests zu den entsprechenden Commands aufzulösen, verwendet der Mapper ActionConfig als Map. Für das View-Management übernimmt die Struts-Klasse ActionMapping die Rolle des Mappers. ActionMapping retourniert eine Referenz zur entsprechenden View. Die Referenz wird 52

53 5. Implementation Presentation-Tier Client sends request «ActionServlet» FrontController delegates «RequestProcessor» ApplicationController invokes Target provides resolves Mapper uses «JSP» View «Action» Command Map Abbildung 5.2.: Front Controller und Application Controller Klassendiagramm [ACM03] realisiert durch die Klasse ActionForward, welche dem RequestProcessor erlaubt, zur zugehörigen View weiterzuleiten. Wie für viele Struts-Anwendungen können ActionServlet und RequestProcessor für das Cybercoach-Projekt ohne Anpassungen übernommen werden. Anwendungsspezifisch sind nur die Views und Commands. Die Umsetzung der Front Controller und Application Controller Patterns in einer Struts-Anwendung läuft für den Entwickler somit auf die Implementation der Action-Klassen und JSP-Seiten hinaus Context Object Das Context Object Pattern [ACM03] bietet eine Lösung, um Komponenten der Anwendung von protokoll-spezifische Systeminformationen zu entkoppeln. Ein Context Object kapselt Systemdaten und erlaubt so den verschiedenen Komponenten der Anwendung unabhängig von einem spezifischen Protokoll auf die Daten zuzugreifen. Zum Beispiel existiert für jedes Feld eines HTML-Formulares ein HTTP-Request-Parameter. Ein Context Object speichert diese Daten unabhängig vom HTTP-Protokoll und vereinfacht die Konversion und Validation der Daten. Andere Teile der Anwendung können auf eine einfache Weise auf diese Daten zugreifen, ohne Kenntnisse über das HTTP-Protokoll haben zu müssen. Jede Veränderung im Protokoll wird vom Context Object behandelt, so dass die anderen Teile der Anwendung nicht angepasst werden müssen. Das Klassendiagramm in Abbildung 5.3 zeigt die allgemeine Struktur des Context Object Patterns. Client verwendet ContextFactory, um in Verwendung eines ProtocolInterface ein ContextObject zu kreieren. ContextObject schirmt die verschiedenen Komponenten der Anwendung von den Implementationsdetails des ProtocolInterface ab. Die Stereotypen im Klassendiagramm geben die Struts-Klassen an, die die entsprechenden Pattern-Klassen implementieren. Das Context Object entspricht in Struts dem ActionForm. 53

54 5. Implementation Presentation-Tier uses Client uses «RequestProcessor» ContextFactory creates «ActionForm» ContextObject uses «HTTPServletRequest» ProtocolInterface Abbildung 5.3.: Context Object Klassendiagramm [ACM03] Übermittelt ein Client ein ausgefülltes HTML-Formular mit dem HTTP-Protokoll an die Webanwendung, so kreiert der Struts RequestProcessor ein neues ActionForm und transferiert die Formulardaten vom protokoll-abhängigen HttpServletRequest-Objekt in das protokollunabhängige ActionForm. Die Daten können dann von den anderen Teilen der Anwendung, zum Beispiel den Action Klassen, unabhängig vom HTTP-Protokoll verwendet werden. Struts wendet für ActionForms die Request Context Validation Strategie [ACM03] an. Die Validation von Daten im Presentation-Tier erfolgt bei dieser Strategie in Koordination mit den Context Objects beziehungsweise den ActionForms. Um in Struts die eingehenden Felder eines Formulars zu validieren, wird die Methode validate() der entsprechenden ActionForm-Klasse überschrieben. In dieser Methode wird der spezifische Code für die Validation der Felder implementiert. Sie wird vom RequestProcessor aufgerufen, nachdem die Formulardaten ins ActionForm-Objekt transferiert wurden, aber bevor die Methode execute() der entsprechenden Action-Klasse ausgeführt wird. Somit wird sichergestellt, das eingehende Request-Daten validiert werden, bevor sie von anderen Teilen der Anwendung verwendet werden. Mit dem Commons Validator bietet Struts die Möglichkeit, Validationsregeln deklarativ zu definieren (siehe Abschnitt 5.1.4). Das Sequenzdiagramm in Abbildung 5.4 beschreibt eine Anwendung des Context Object Patterns im Cybercoach-Projekt anhand des Anwendungsfalles Benutzer hinzufügen. In diesem Diagramm repräsentiert AddUserForm das Context Object und HttpServletRequest das Protokoll-Interface View Helper Bei der Implementation von Views, zum Beispiel in Form von JSP-Seiten, besteht häufig die Tendenz, dass Kontrolllogik, Zugriffslogik und Formatierungslogik mit der View vermischt werden. Dies führt zu Problemen mit der Wierderverwendbarkeit, Wartbarkeit und Modularität der Anwendung. 54

55 5. Implementation Presentation-Tier Client ActionServlet RequestProcessor send request delegate create create AddUserForm get data set data validate() CreateUserAction get data HttpServletRequest createperson() PersonManagerDelegate Abbildung 5.4.: Context Object Sequenzdiagramm 55

56 5. Implementation Presentation-Tier Das View Helper Pattern [ACM03] beschreibt, wie Views von der Programmlogik getrennt werden können. Eine View delegiert dabei die Kontrolllogik, Zugriffslogik und Formatierungslogik an seine Helper-Klassen, welche in der Regel als JavaBeans oder als Custom-Tags (siehe Abschnitt 2.2.5) implementiert werden. Die Hauptaufgabe der Helper-Klassen ist die Formatierung und Anpassung des Models für eine bestimmte View. «RequestProcessor» ApplicationController «JSP» Helper dispatches View uses adapts PresentationModel 1 0..* JavaBean CustomTag Abbildung 5.5.: View Helper Klassendiagramm [ACM03] Das Klassendiagramm in Abbildung 5.5 beschreibt die allgemeine Struktur des View Helper Patterns. Typischerweise löst ApplicationController einen eingehenden Request in eine bestimmte View auf. Eine View repräsentiert Information und zeigt sie dem Benutzer an. Helper kapselt die Formatierung und den Zugriff auf die Daten des PresentationModels. PresentationModel enthält die Rohdaten, welche von den Diensten des Business-Tier abgerufen werden, um eine View zu generieren. Struts wendet zwei verschiedene Strategien des View Helper Pattern an, die in [ACM03] beschrieben werden: Bei der JavaBean Helper Strategie werden Helper als JavaBeans implementiert. Struts stellt die Tag-Library struts-bean zur Verfügung, mit welcher Daten aus JavaBeans mittels Custom-Tags angezeigt werden können. Im Cybercoach-Projekt wird diese Strategie zum Beispiel für die Anzeige von Aktivitäten verwendet. Das ShowActivityAction- Objekt ruft die Daten einer Aktivität vom Business-Tier ab und formatiert sie anschliessend. Zu den nötigen Formatierungen gehört etwa die Konversion der Distanz von Meter in Kilometer. ShowActivityAction instanziiert ein ActivityDetails Objekt und füllt es mit den formatierten Daten. ActivityDetails ist ein JavaBean, welches alle Daten einer Aktivität in Form von Strings enthält, die bereit für die Anzeige sind. Die formatierten Daten von ActivityDetails werden schliesslich von der JSP-Seite showactivity.jsp durch die Custom-Tags der struts-bean Tag-Library angezeigt. Bei der Custom Helper Strategie werden Helper als Custom-Tags implementiert. Struts stellt verschiedene Tag-Libraries zur Verfügung, welche Programmlogik als Custom-Tags kapseln. Zum Beispiel wird in Cybercoach die Tag-Library struts-logic oft verwendet. Die Custom-Tags dieser Bibliothek kapseln Kontrolllogik wie etwa die konditionelle Ge- 56

57 5. Implementation Presentation-Tier nerierung von Anzeigetext, die Abarbeitung von Objektkollektionen für Generierung von sich wiederholendem Anzeigetext oder Kontrollfluss. Eine Anwendung des View Helper Pattern im Cybercoach-Projekt ist im Service To Worker Sequenzdiagramm in Abbildung 5.8 sichtbar. ActivityDetailsBean repräsentiert in diesem Diagramm ein JavaBean Helper. Die View showactivity.jsp greift auf dieses Bean zu und zeigt die enthaltene Information dar Composite View Häufig besitzen mehrere Views einer Webanwendung gemeinsame Inhalte und haben das selbe Layout. Durch die Vermischung von Inhalt und Layout wird die Pflege und Erweiterbarkeit der Views erschwert. Das Composite View Pattern [ACM03] bietet eine Lösung, um eine View aus modularen Komponenten zu kombinieren, wobei Inhalt und Layout der View unabhängig verwaltet werden. Eine Composite View ist aus mehreren atomaren Subviews zusammengesetzt. Jede Subview kann dynamisch in die gesamte View geladen werden. Das Layout der Seite wird durch eine Vorlage definiert und unabhängig vom Inhalt verwaltet. Client dispatches «interface» View 1..* manages 1 ViewManager 1..* contains 1 1..* SimpleView CompositeView Template defines layout Abbildung 5.6.: Composite View Klassendiagramm [ACM03] Das Klassendiagramm in Abbildung 5.6 beschreibt die allgemeine Struktur des Composite View Patterns. SimpleView repräsentiert eine atomare Portion der gesamtem Anzeige und wird auch als Subview bezeichnet. CompositeView ist aus mehreren Views zusammengesetzt. Jeder dieser Views kann entweder eine SimpleView oder selber wieder eine CompositeView sein. Template ist eine Vorlage die das Layout definiert. ViewManager verwendet ein Template, um ein Layout umzusetzen. Dabei werden die entsprechenden Inhalte in das Layout eingefügt. Struts verwendet das Framework Tiles [Mal02, Str05], um Subviews zu Composite Views zusammenzusetzen. Die Subviews werden als JSP-Seiten realisiert, die jeweils einen Teil der gesamten Anzeige enthalten und in verschiedenen Views wiederverwendet werden können. Im Cybercoach-Projekt definiert die Template-Seite layout.jsp das Layout der gesamten Webanwendung. Mit Custom-Tags der struts-tiles Tag-Library werden in der Layout-Seite 57

58 5. Implementation Presentation-Tier verschiedene Regionen definiert, in welche die Subviews dynamisch geladen werden können. Die Konfigurationsdatei tiles-defs.xml definiert für jede Composite View, welche Subview in welche Region geladen werden soll. Anhang C.4 enthält einen Ausschnitt dieser Datei Service To Worker Das Service To Worker Pattern [ACM03] beschreibt, wie die Verarbeitung von Requests durchgeführt wird und wie die Geschäftsdienste aufgerufen werden, bevor die Kontrolle an die Views weitergeleitet wird. Service To Worker zentralisiert die Kontrolllogik und Verarbeitung von Requests. Model-Daten werden dadurch vom Business-Tier abgerufen, bevor die Kontrolle an die View weitergeleitet wird. Die View generiert anschliessend eine dynamische Antwort basierend auf den Model-Daten. Service To Worker ist aus mehreren anderen Presentation-Tier-Patterns zusammengesetzt und beschreibt die Interaktion zwischen diesen Patterns. Zu den verwendeten Patterns gehören Front Controller, Application Controller und View Helper. «Action» Command accesses BusinessService invokes provides Client sends request «ActionServlet» FrontController delegates «RequestProcessor» ApplicationController PresentationModel dispatches adapts «JSP» View uses ViewHelper 0..* Abbildung 5.7.: Service To Worker Klassendiagramm [ACM03] Das Klassendiagramm in Abbildung 5.7 beschreibt die allgemeine Struktur des Service To Worker Patterns. Die Stereotypen geben die Struts-Klassen an, welche die entsprechenden Pattern-Klassen implementieren. Das ActionServlet repräsentiert den FrontController und erhält einen Request vom Client. Der Request wird an ApplicationController delegiert, welcher in Struts durch den RequestController implementiert wird und den eingehenden Request zum entsprechenden Command auflöst. Commands werden in Struts als Action-Klassen implementiert, die über BusinessServices Daten des PresentationModel abrufen. Zu diesem Zeitpunkt identifiziert ApplicationController die entsprechende View und leitet die Kontrol- 58

59 5. Implementation Presentation-Tier le an sie weiter. Die View ist als JSP-Seite implementiert und verwendet ViewHelper, um die Daten des PresentationModel für die Anzeige anzupassen. Das Sequenzdiagramm in Abbildung 5.8 beschreibt eine Anwendung des Service To Worker Patterns im Cybercoach-Projekt anhand des Anwendungsfalles Aktivität anzeigen. In diesem Diagramm repräsentiert ShowActivityAction einen Command, der auf Geschäftsdienste des ActivityManagerDelegate zugreift. Die View showactivity.jsp verwendet den JavaBean Helper ActivityDetailsBean, um die Daten der Aktivität anzuzeigen Parsing der XML-Datei Die Daten von Trainingsaktivitäten werden im Cybercoach-System in Form von XML-Dateien an den Server gesendet. Ein spezieller Dialog in der Webanwendung erlaubt es, eine XML- Datei auszuwählen und hochzuladen. Die entsprechende Aktivität wird dadurch hinzugefügt. In einer erweiterten Form von Cybercoach könnte diese Datei auch direkt von einem mobilen Gerät an den Server gesendet werden, anstatt die Datei über die Webanwendung hochzuladen. Die XML-Datei hat eine einfache Struktur und enthält im Wesentlichen das Datum, die Startzeit, die Disziplin, die berechnete Anzahl verbrauchter Kalorien und eine Liste mit Messpunkten. Ein Messpunkt besteht jeweils aus den x-, y-, und z-koordinaten, der Herzfrequenz und der Zeit relativ zur Startzeit. Anhang D.1 beschreibt die Struktur der XML-Datei anhand ihrer Document Type Definition (DTD) und Anhang D.2 enthält ein einfaches Beispiel. Nach dem Hochladen der XML-Datei wird diese durch die Klasse ActivityXmlParser geparst. ActivityXmlParser ist ein SAX-Parser. SAX [BGH + 04] heisst Simple API for XML und ist ein ereignis-gesteuerter Mechanismus, um auf die Daten einer XML-Datei zuzugreifen. Ein SAX-Parser wird implementiert, indem Callback-Methoden zur Verfügung gestellt werden, welche jeweils aufgerufen werden, wenn der Parser Elemente oder Attribute liest. Die ActivityXmlParser Klasse baut intern eine Liste mit den geparsten Messpunkten auf. Diese Liste wird anschliessend abgearbeitet, wobei folgende Werte berechnet werden: Dauer der Aktivität Zurückgelegte Distanz Minimale Höhe über Meer Maximale Höhe über Meer Durchschnittliche Herzfrequenz Maximale Herzfrequenz Die gesammelten Informationen der Aktivität werden in einem ActivityTO Objekt gespeichert. ActivityTO enthält auch die Liste der Messpunkte in Form einer Zeichenkette. Das kreierte Transfer Object wird nach dem Parsing einer Business-Tier-Methode übergeben, welche eine neue Aktivität mit den entsprechenden Werten in das System einfügt. 59

60 5. Implementation Presentation-Tier Client ActionServlet RequestProcessor send request delegate create showactivity.jsp ShowActivityAction populate forward to ActivityDetailsBean getactivity() get data ActivityManagerDelegate Abbildung 5.8.: Service To Worker Sequenzdiagramm 60

61 5. Implementation Presentation-Tier 5.4. Mögliche Erweiterungen Als mögliche Erweiterungen für den Presentation-Tier werden folgende Punkte vorgeschlagen: Als Erweiterung zum bestehenden Webinterface kann zusätzlich ein Rich-Client als Benutzerinterface realisiert werden. Dieser Rich-Client würde über die Remote-Interfaces der Session-Beans auf den Business-Tier zugreifen. Für die Implementation der grafischen Benutzeroberfläche könnte beispielsweise Java Swing [J2S05] zum Einsatz kommen. Gegenüber dem dem Webinterface hat ein Rich-Client bessere Möglichkeiten für die Benutzerinteraktion. Eine vorstellbare Strategie wäre, dass als Interface für Coachund Administratoren-Dienste ein Rich-Client realisiert wird und für Benutzer-Dienste lediglich das Webinterface angeboten wird. Vorteil dieser Strategie wäre, dass der Benutzer einen niedrigen Installationsaufwand hat, da der Zugang zum Webinterface über einen Webbrowser erfolgt und somit kein zusätzliches Programm notwendig ist. Für die Cybercoach-Webanwendung wird Form-based Authentication verwendet, um einen Client zu authentifizieren. Da dies ist bei einem Rich-Client nicht möglich ist, müsste für die Authentifizierung die J2EE-API JAAS verwendet werden. Die Cybercoach-Webanwendung kann durch eine grafische Aufbereitung der Trainingsdaten erweitert werden. Bisher werden diese Daten in rein textueller Form präsentiert, etwa als Listen oder Tabellen. Die Trainingsdaten könnten zusätzlich in Form von Diagrammen dargestellt werden. Für die Implementation dieser grafischen Aufbereitung gibt es verschiedene Ansätze. Zum Beispiel könnten die Diagramme mit der Java 2D API [J2S05] erstellt werden und als JPEG-Bild im Webinterface dargestellt werden. Ein interessanter Ansatz für die Aufbereitung einer einzelnen Aktivität wäre, die XML-Datei der Aktivität mit XSL in eine SVG-Grafik zu transformieren. Auf diese Weise könnte zum Beispiel die Höhenkurve für die Aktivität generiert werden. Die Transformation könnte mit der J2EE-API JAXP [J2E05] realisiert werden. Der Presentation-Tier kann durch automatische Tests für die JSP-Seiten und Struts- Klassen erweitert werden. Bei der vorliegenden Ausführung von Cybercoach wird auf automatische Tests im Presentation-Tier verzichtet. Die JSP-Seiten könnten mit dem Cactus Framework [Cac05] getestet werden. Da Cactus bereits für die Tests der Enterprise- Beans eingesetzt wird, wäre der Aufwand für die Konfiguration gering. Auch für den Test von Strutsanwendungen gibt es bereits existierende Werkzeuge, die verwendet werden könnten. 61

62 6. Benutzerhandbuch Die Cybercoach-Webanwendung hat einen klaren und intuitiven Aufbau. Das vorliegende Kapitel beschreibt die Struktur des Interfaces und gibt eine Einführung in die Bedienung. Cybercoach kann unter der URL [Cyb05] getestet werden. Tabelle G.1 in Anhang G.6 enthält einige Benutzernamen und Passwörter, die für den Test verwendet werden können Navigation Abbildung 6.1 zeigt den Navigationsbaum der Cybercoach-Webanwendung. Die weissen Rechtecke stellen öffentliche Webseiten dar, die für jeden Besucher zugänglich sind. Die grünen Rechtecke repräsentieren Seiten, die für alle registrierten Benutzer zugänglich sind. Die gelben Rechtecke stellen die Seiten dar, auf welche nur Coaches Zugriff haben. Das orange Rechteck ist die Seite für die Verwaltung der Benutzerrechte, auf welche nur Administratoren zugreifen können. User registration (Step 1) Welcome page User registration (Step 2) Login Login-Error Edit user information Main page Manage user rights Edit athletic profile Add activity Show activities Show all activities Activity details Activity details Activity details Abbildung 6.1.: Navigationsbaum der Cybercoach-Webanwendung 6.2. Seitenaufbau Die Seiten der Cybercoach-Webanwendung sind alle nach dem gleichen Schema aufgebaut. Abbildung 6.2 zeigt diesen Aufbau. Am oberen Rand befindet sich die Kopfzeile (1) mit dem Titel 62

63 6. Benutzerhandbuch Abbildung 6.2.: Seitenaufbau in der Cybercoach-Webanwendung der Webanwendung. Am unteren Rand ist die Fusszeile (2), welche Coypright-Informationen enthält. Der linke Rand bildet eine Menüspalte, die in verschiedene Abschnitte aufgeteilt ist. Der Abschnitt Home (3) enthält allgemeine Menüpunkte, zum Beispiel Logout. Der Abschnitt User account (4) enthält alle Menüpunkte für die Verwaltung des Benutzerkontos, zum Beispiel die Bearbeitung der Benutzerangaben. Menüpunkte für die die Verwaltung von Aktivitäten sind im Abschnitt Activities (5) untergebracht. Der Abschnitt Coach (6) ist nur für Benutzer mit Coach-Rechten sichtbar und enthält einen Menüpunkt für die Anzeige von fremden Aktivitäten. Der letzte Abschnitt ist Administrator (7), welcher nur für Administratoren sichtbar ist und einen Menüpunkt für die Bearbeitung von Benutzerrechten enthält. Der grösste Teil einer Cybercoach-Seite wird für die Anzeige von Inhalten (8) verwendet Szenarien In diesem Abschnitt wir für jede Benutzerrolle in Cybercoach ein Szenario dargestellt. Eine Rolle bestimmt, welche Rechte ein Benutzer des Systems hat. Cybercoach kennt drei verschiedene Rollen: User, Coach und Administrator. Ein Benutzer, der sich noch nicht im System registriert hat, ist keiner der drei Rollen zugeordnet. Die Menge der unregistrierten Benutzer kann somit als eine vierte Benutzerkategorie betrachtet werden. 63

64 6. Benutzerhandbuch Abbildung 6.3.: Cybercoach: Benutzerregistration mit Fehlermeldungen 64

65 6. Benutzerhandbuch User-Szenario Bevor eine Person das Cybercoach-System benutzen kann, muss sie sich im System registrieren. Dazu wird in einem Webbrowser die Internetadresse von Cybercoach [Cyb05] eingegeben. Es erscheint eine Willkommens-Seite mit verschiedenen Menüpunkten. Durch die Wahl des Menüpunktes Register now! wird eine Eingabemaske angezeigt, in der die Personalien eingegeben werden können. Dies ist der erste Schritt der Benutzerregistration. Durch das Drücken von Continue werden die eingegebenen Daten validiert. Sind Fehler vorhanden, zum Beispiel ein leeres Feld oder eine ungültige Formatierung, so werden diese auf der selben Seite in einer roten Box angezeigt (siehe Abbildung 6.3). Die zuvor eingegebenen Werte bleiben erhalten, so dass sie vom Benutzer korrigiert werden können. Nachdem alle Fehler korrigiert worden sind, gelangt man durch erneutes Drücken von Continue zum zweiten Schritt der Registration. Hier werden in einer Eingabemaske der gewünschte Benutzername und zweimal ein Passwort eingegeben. Durch Drücken von Submit werden die Eingaben validiert. Ist der gewünschte Benutzername noch nicht vergeben und stimmen die beiden Passwörter überein, so ist die Registration erfolgreich abgeschlossen und die Willkommens- Seite wird erneut angezeigt. Der registrierte Benutzer kann jetzt auf der Willkommens-Seite den Menüpunkt Login wählen. Er wird aufgefordert, Benutzernamen und Passwort einzugeben. Sind die Angaben korrekt, so wird er auf die Hauptseite des Systems weitergeleitet (siehe Abbildung 6.4). Diese enthält das User-Menü, sowie eine Übersicht der persönlichen Informationen und der Aktivitäten im vergangenen Monat. Abbildung 6.4.: Cybercoach: Hauptseite 65

66 6. Benutzerhandbuch Abbildung 6.5.: Cybercoach: Aktivitätendetails Abbildung 6.6.: Cybercoach: Aktivitätenanzeige 66

67 6. Benutzerhandbuch Abbildung 6.7.: Cybercoach: Aktivitätenanzeige für Coaches Als erstes sollte der neue Benutzer ein athletisches Profil anlegen. Dazu wählt er den Menüpunkt Edit athletic profile. Es erscheint eine Eingabemaske, in welche der Athlet Gewicht, Grösse, Ruhe-Herzfrequenz und Gesundheitszustand eingeben kann. Nachdem das athletisches Profil anlegt worden ist, sind alle Voraussetzungen erfüllt, um Aktivitäten hinzuzufügen. Durch die Wahl des Menüpunktes Add activity wird eine Eingabemaske angezeigt, mit welcher der Benutzer eine Aktivitäten-Datei auszuwählen kann. Durch Drücken von Submit wird die Datei auf den Server geladen, wo sie ausgewertet wird. Anschliessend wird eine Seite angezeigt, die alle berechneten Details der Aktivität aufgelistet (siehe Abbildung 6.5). Um Aktivitäten zu einem späteren Zeitpunkt wieder aufzurufen, wählt der Benutzer den Menüpunkt Show activities. Es erscheint eine Liste mit allen Aktivitäten der letzten Woche. In einer Eingabemaske können das Suchintervall und die gewünschte Disziplin angegeben werden, um die Suche zu präzisieren (siehe Abbildung 6.6). Durch Drücken des Symbols i in der Liste kann der Benutzer die Details einer bestimmten Aktivität einsehen (siehe Abbildung 6.5). Im weiteren hat der Benutzer die Möglichkeit, seine Benutzerangaben zu ändern. Dies geschieht durch den Menüpunkt Edit user information. Schliesslich kann durch den Menüpunkt Delete user account das Benutzerkonto gelöscht werden. 67

68 6. Benutzerhandbuch Abbildung 6.8.: Cybercoach: Benutzerrechte verwalten Coach-Szenario Im Gegensatz zu einem gewöhnlichen Benutzer hat ein Coach das Recht, die Aktivitäten anderer Benutzer einzusehen. Ein Coach kann sich wie ein normaler Benutzer beim System anmelden, indem er auf der Willkommens-Seite den Menüpunkt Login wählt. Bei der Authentifizierung wird automatisch erkannt, dass der Benutzer ein Coach ist und im Menü wird ein zusätzlicher Abschnitt mit dem Titel Coach eingeblendet. Um die Aktivitäten anderer Benutzer anzuzeigen, wählt der Coach den Menüpunkt Show all activities. Analog zu Show activities für gewöhnliche Benutzer erscheint eine Liste mit Aktivitäten der letzten Woche. Die Liste enthält jedoch die Aktivitäten aller Benutzer. Für jede Aktivität wird der Name des entsprechenden Benutzers in einer zusätlichen Spalte angegeben (siehe Abbildung 6.7). Die Eingabemaske für die Suchkriterien enthält zusätzlich ein Auswahlfeld mit allen registrierten Benutzern. Dies erlaubt es, nach den Aktivitäten eines bestimmten Benutzers zu suchen. Durch Drücken des Symbols i in der Liste kann der Coach die Details einer bestimmten Aktivität einsehen (siehe Abbildung 6.5) Administrator-Szenario Ein Administrator kann sich wie ein gewöhnlicher Benutzer beim System anmelden, indem er auf der Willkommens-Seite den Menüpunkt Login wählt. Bei der Authentifizierung wird automatisch erkannt, dass der Benutzer ein Administrator ist und im Menü wird ein zusätzlicher Abschnitt mit dem Titel Administrator eingeblendet. 68

69 6. Benutzerhandbuch Um Benutzerrechte zu verändern, wählt der Administrator den Menüpunkt Manage user rights. Es erscheint eine Liste mit allen registrierten Benutzern des Systems (siehe Abbildung 6.8). In den Spalten Coach und Administrator wird angezeigt, ob ein Benutzer der entsprechenden Rolle angehört oder nicht. Ein Häkchen bedeutet, dass er der Rolle angehört und ein Kreuzchen, dass er ihr nicht angehört. Durch Drücken auf ein Kreuzchen wird dem Benutzer das Recht für die entsprechende Rolle zugeteilt und es erscheint ein Häkchen an seiner Stelle. Durch Drücken auf ein Häkchen wird das Recht wieder aufgehoben. 69

70 7. Fazit 7.1. Ergebnis Die vorliegenden Masterarbeit beschreibt die Konzeption und Implementation einer multiertier Anwendung mit J2EE anhand des Beispiels von Cybercoach. Das Hauptaugenmerk der Arbeit liegt dabei auf der Softwarequalität und dem Einsatz aktueller Praktiken des Software Engineering. Cybercoach baut auf verschiedenen Frameworks und Werkzeugen auf. Die folgende Liste gibt einen Überblick über die wichtigsten Technologien, die für die Realisierung des Projekts verwendet werden: EJB wird auf der Seite des Business-Tiers verwendet, um die Gechäftslogik zu implementieren. Struts bildet zusammen mit Servlet und JSP die Basis der Webanwendung auf der Seite des Presentation-Tiers. Cactus, JUnit und DBUnit werden für die automatisierten Test verwendet. XDoclet wird verwendet, um die Komponenten-Interfaces, die Home-Interfaces und den Deployment-Deskriptor für die Enterprise-Beans automatisch zu generieren. Ant wird als Build-Werkzeug verwendet. Die verschiedenen Kriterien der Softwarequalität wie Robustheit, Wiederverwendbarkeit, Erweiterbarkeit und Wartbarkeit werden unter anderem durch die Anwendung von Design Patterns erfüllt. Sowohl für den Business-Tier, als auch für den Presentation-Tier werden verschiedene Core J2EE Patterns [ACM03] angewendet. Das Struts-Framework setzt seinerseits bereits mehrere Presentation-Tier-Patterns um. Die verwendeten Patterns werden in der vorliegenden Arbeit genau beschrieben. Die Korrektheit der implementierten Geschäftsdienste wird im Cybercoach-Projekt mit automatisierten Tests überprüft. Die Verwendung des Cactus-Frameworks erlaubte es, diese Tests direkt auf dem Applikationsserver auszuführen. Indem der Build-Prozess durch Ant weitgehend automatisiert wird und die Tests integrierter Bestandteil des Build-Prozesses sind, wird ausserdem das Prinzip der kontinuierlichen Integration umgesetzt. J2EE, Struts und andere Frameworks bieten die Möglichkeit, die Konfiguration der zur Verfügung gestellten Dienste auf deklarative Weise vorzunehmen, zum Beispiel in Form von XML-Dateien. Dadurch wird ein hohes Mass an Flexibilität erreicht, indem Eigenschaften verändert werden können, ohne dass dafür der Code der Anwendung verändert werden muss. Für das Cybercoach-Projekt werden die verwendeten Dienste aus diesem Grund durchgehend deklarativ angepasst. 70

71 7. Fazit Auf der Seite des Business-Tiers stellt der EJB-Container folgende Dienste zur Verfügung, deren Konfiguration für das Cybercoach-Projekt deklarativ vorgenommen werden: Container-Managed Persistence Container-Managed Relationships Deklaratives Transaktionsmanagement Deklarative Sicherheit Auf der Seite des Presentation-Tiers wird die Konfiguration folgender Dienste deklarativ vorgenommen: Action-Mappings (Struts) Layout-Management (Tiles) Validierung der Benutzereingaben (Commons Validator) Deklarative Sicherheit Der Einsatz von Frameworks wie J2EE und Struts garantiert, dass die Anwendung auf einer erprobten und durchdachten Basis aufbaut. Zusätzlich kann der Entwicklungsaufwand beträchtlich verringert werden, da wichtige Dienste von den Frameworks zur Verfügung gestellt werden und nicht selber implementiert werden müssen. Der Aufwand, der zum Erlernen der Einzelheiten eines Frameworks notwendig ist, sollte jedoch nicht unterschätzt werden. J2EE und Struts beinhalten eine grosse Menge an Klassen, APIs und Konfigurationen, die der Entwickler kennen muss, um seine Anwendung zu realisieren. Bei EJB kommt hinzu, dass für jede Komponente eine Bean-Klasse, ein Komponenten- Interface und ein Home-Interface implementiert, sowie mehrere Konfiguration im Deployment- Deskriptor vorgenommen werden müssen. Die Vielzahl an Klassen, Interfaces und Konfigurationen ist arbeitsaufwändig und wird von vielen Entwicklern als komplex und unübersichtlich betrachtet. Durch Werkzeuge wie XDoclet kann zwar der Arbeitsaufwand reduziert werden, die Komplexität bleibt jedoch erhalten und wird durch die Einführung einer weiteren Technologie eher noch erhöht. Die Situation soll mit der kommenden Spezifikation EJB 3.0 verbessert werden, indem die Entwicklung der Enterprise-Beans stark vereinfacht wird Verbesserungsmöglichkeiten Für das Cybercoach-Projekt gibt es verschiedene Erweiterungsmöglichkeiten. Auf der Seite des Business-Tier werden in Abschnitt 4.4 der Ausbau des funktionellen Umfangs, die Verwendung weiterer Technologien und die Vervollständigung der automatischen Tests vorgeschlagen. Insbesondere durch die Verwendung weiterer Technologien wie Message-Driven-Beans und Webservices könnte Cybercoach als Beispiel einer J2EE-Anwendung vervollständigt werden. Auf der Seite des Presentation-Tier werden in Abschnitt 5.4 die Realisierung eines Rich- Clients, die Aufbereitung der Trainingsdaten, sowie die Einführung von automatischen Tests als Erweiterungsmöglichkeiten vorgeschlagen. Ein Rich-Client wäre vor allem deshalb interessant, weil durch ihn neben der Webanwendung eine zweite Art von Client existieren würde, die auf den Business-Tier zugreift. 71

72 A. Abkürzungsverzeichnis Abkürzung CGI CMP CMR DTD EAR EJB HTML HTTP IDE J2EE J2SE JAAS JAR JAXP JDBC JNDI JSP JVM MVC POJO SAX SVG UML URI URL WAR XML Beschreibung Common Gateway Interface Container-Managed Persistence Container-Managed Relationships Document Type Definition Enterprise Application Archive Enterprise JavaBeans Hypertext Markup Language Hypertext Transfer Protocol Integrated Development Environment Java 2 Platform, Enterprise Edition Java 2 Platform, Standard Edition Java Authentication and Authorization Service Java Archive Java API for XML Processing Java Database Connectivity Java Naming and Directory Interface Java ServerPages Java Virtual Machine Model View Controller Plain Old Java Object Simple API for XML Scalable Vector Graphics Unified Modeling Language Uniform Resource Identifier Uniform Resource Locator Web Application Archive Extensible Markup Language 72

73 B. Beispiel Entity-Bean (ProfileEntityBean) 1 package cybercoach.ejb. profile ; /** 6 * Entity bean for persisting an athletic profile of a person. 7 * 8 Dominic Bruegger * 11 bean 12 * name = " Profile " 13 * view -type = " local " 14 * type = " CMP " 15 * cmp - version = "2.x" 16 * local -jndi -name = "ejb / cybercoach / Profile " 17 * primkey - field = "id" 18 permission 19 * unchecked = " true " 20 transaction 21 * type = " Required " 22 unknown - pk 23 * class =" java.lang. Integer " 24 * column -name=" id" 25 * jdbc -type=" INTEGER " 26 * sql -type=" INT (11)" 27 * auto - increment=" true " 28 - command 29 * name=" mysql -get - generated -keys " 30 home 31 * local - class = " cybercoach.ejb. profile. ProfileHomeLocal " 32 * local - extends = " javax.ejb. EJBLocalHome " 33 interface 34 * local - class = " cybercoach.ejb. profile. ProfileLocal " 35 * local - extends = " javax.ejb. EJBLocalObject " 36 */ 37 public abstract class ProfileEntityBean extends EntityBeanAdapter { /** 40 * A container invokes this method before the instance s state is inserted into 41 * the database. 42 * 43 - method 44 */ 45 public Object ejbcreate () throws CreateException { 46 return null ; 47 } /** 50 * A container invokes this method after the instance s state has been inserted 51 * into the database. 52 */ 53 public void ejbpostcreate () throws CreateException { 54 } /** 57 * Returns the primary key. 58 * 59 interface - method 60 persistence 61 persistence 62 * auto - increment = "true " 63 */ 64 public abstract Integer getid (); /** 67 * Sets the primary key. 68 */ 69 public abstract void setid ( Integer id ); /** 72 * Returns the date the profile is valid from. 73 * 74 interface - method 75 persistence 76 */ 73

74 B. Beispiel Entity-Bean (ProfileEntityBean) 77 public abstract Date getvalidfrom (); /** 80 * Sets the date the profile is valid from. 81 * 82 interface - method 83 */ 84 public abstract void setvalidfrom ( Date validfrom ); /** 87 * Returns the date the profile is valid to. 88 * 89 interface - method 90 persistence 91 */ 92 public abstract Date getvalidto (); /** 95 * Sets the date the profile is valid to. 96 * 97 interface - method 98 */ 99 public abstract void setvalidto ( Date validto ); /** 104 * Returns the related person. 105 * 106 interface - method 107 relation 108 * name = "Person - Profile " 109 * role -name = "Profile -has -a- Person " 110 * cascade - delete = "yes " 111 relation 112 * related -pk - field = " userid " 113 * fk - column = " userid " 114 */ 115 public abstract PersonLocal getperson (); /** 118 * Sets the related person. 119 * 120 interface - method 121 */ 122 public abstract void setperson ( PersonLocal person ); /** 125 * Returns all activities associated to this profile. 126 * 127 interface - method 128 relation 129 * name = "Profile - Activity " 130 * role -name = "Profile -has -many - Activities " 131 */ 132 public abstract Collection getactivities (); /** 135 * Sets the activities associated to this profile. 136 * 137 interface - method 138 */ 139 public abstract void setactivities ( Collection activities ); } 74

75 C. Beispiele J2EE- und Struts-Konfiguration C.1. web.xml 1 <! DOCTYPE web -app PUBLIC 2 " -// Sun Microsystems, Inc.// DTD Web Application 2.3// EN" 3 "http :// java.sun.com /dtd /web - app_2_3.dtd "> 4 5 <!-- ====================================================================== --> 6 <!-- Web deployment descriptor for the Cybercoach project --> 7 <!-- ====================================================================== --> 8 <web - app > 9 10 <!-- ======== Struts action servlet configuration ===================== --> 11 <servlet > 12 <servlet -name >action </ servlet -name > 13 <servlet -class >org. apache. struts. action. ActionServlet </ servlet -class > 14 <init - param > 15 <param -name >config </ param -name > 16 <param -value >/WEB -INF /struts - config.xml </ param -value > 17 </init - param > 18 <load -on -startup >1</ load -on -startup > 19 </ servlet > <!-- ======== Struts action servlet mapping =========================== --> 22 <servlet - mapping > 23 <servlet -name >action </ servlet -name > 24 <url - pattern >*. do </ url - pattern > 25 </ servlet - mapping > <!-- ======== The welcome file list =================================== --> 28 <welcome -file - list > 29 <welcome -file >index.jsp </ welcome -file > 30 </ welcome -file - list > <!-- ======== Security Restrictions =================================== --> 33 <security - constraint > 34 <web -resource - collection > 35 <web - resource - name >Main control page </ web - resource -name > 36 <url -pattern >/ main.do </url -pattern > 37 </web -resource - collection > 38 <web -resource - collection > 39 <web - resource - name >Logout action </ web - resource -name > 40 <url -pattern >/ logout.do </url -pattern > 41 </web -resource - collection > <web -resource - collection > 44 <web - resource - name >Show activities page </ web - resource -name > 45 <url -pattern >/ showactivities.do </url -pattern > 46 </web -resource - collection > 47 <auth - constraint > 48 <role -name >User </ role -name > 49 <role -name > Coach </ role -name > 50 <role -name >Administrator </ role -name > 51 </auth - constraint > 52 </security - constraint > 53 <security - constraint > 54 <web -resource - collection > 55 <web - resource - name >Show activities coach page </ web - resource -name > 56 <url -pattern >/ showactivitiescoach.do </url -pattern > 57 </web -resource - collection > 58 <auth - constraint > 59 <role -name > Coach </ role -name > 60 <role -name >Administrator </ role -name > 61 </auth - constraint > 62 </security - constraint > 63 <security - constraint > 64 <web -resource - collection > 65 <web - resource - name >Manage user rights page </ web - resource -name > 66 <url -pattern >/ managerights.do </url -pattern > 67 </web -resource - collection > 68 <auth - constraint > 69 <role -name >Administrator </ role -name > 70 </auth - constraint > 71 </security - constraint > 72 75

76 C. Beispiele J2EE- und Struts-Konfiguration 73 <!-- ======== Definition of the authentication process ================ --> 74 <login - config > 75 <auth -method >FORM </ auth -method > 76 <form - login - config > 77 <form -login -page >/ login.do </ form -login -page > 78 <form -error -page >/ loginerror.do </ form -error -page > 79 </form - login - config > 80 </ login - config > <!-- ======== Definitions of the roles ================================ --> 83 <security -role > 84 <description >User role </ description > 85 <role -name >User </ role -name > 86 </ security -role > 87 <security -role > 88 <description >Coach role </ description > 89 <role -name > Coach </ role -name > 90 </ security -role > 91 <security -role > 92 <description >Administrator role </ description > 93 <role -name >Administrator </ role -name > 94 </ security -role > <!-- ======== Tag library descriptors ================================= --> 97 <taglib > 98 <taglib -uri >/ tags /struts -bean </ taglib -uri > 99 <taglib -location >/WEB -INF /lib /struts -bean.tld </ taglib -location > 100 </ taglib > </web -app > C.2. struts-config.xml 1 <? xml version ="1.0" encoding=" UTF -8"?> 2 <! DOCTYPE struts - config PUBLIC 3 " -// Apache Software Foundation // DTD Struts Configuration 1.2// EN" 4 "http :// jakarta. apache.org / struts /dtds /struts - config_1_2.dtd "> 5 6 <!-- ====================================================================== --> 7 <!-- Struts configuration file for the Cybercoach project --> 8 <!-- ====================================================================== --> 9 <struts - config > <!-- ======== Form bean definitions =================================== --> 12 <form - beans > 13 <form - bean 14 name =" adduserform " 15 type =" cybercoach. webapp. forms. AddUserForm "/> 16 <form - bean 17 name =" edituserform " 18 type =" cybercoach. webapp. forms. EditUserForm "/> </form - beans > <!-- ======== Global forward definitions ============================== --> 23 <global - forwards > 24 < forward 25 name =" welcome " 26 path ="/ welcome.do "/> 27 < forward 28 name =" main " 29 path ="/ main.do "/> 30 < forward 31 name =" error " 32 path ="/ error.do "/> 33 </ global - forwards > <!-- ======== Action mapping definitions ============================== --> 36 <action - mappings > 37 < action 38 path ="/ welcome " 39 type =" org. apache. struts. actions. ForwardAction " 40 parameter =" welcome.page "/> 41 < action 42 path ="/ locale " 43 type =" cybercoach. webapp. actions. LocaleAction " 44 parameter =" welcome " /> 45 < action 46 path ="/ login " 47 type =" org. apache. struts. actions. ForwardAction " 48 parameter =" login.page "/> 49 < action 50 path ="/ loginerror " 51 type =" org. apache. struts. actions. ForwardAction " 76

77 C. Beispiele J2EE- und Struts-Konfiguration 52 parameter =" login. error.page "/> < action 55 path ="/ adduser " 56 type =" org. apache. struts. actions. ForwardAction " 57 parameter =" add.user.1. page "/> 58 < action 59 path ="/ createuser " 60 type =" cybercoach. webapp. actions. CreateUserAction " 61 name =" adduserform " 62 scope =" request " 63 validate =" false "> 64 < forward 65 name =" input1 " 66 path =" add.user.1. page "/> 67 < forward 68 name =" input2 " 69 path =" add.user.2. page "/> 70 </ action > </ action - mappings > </ struts - config > C.3. validation.xml 1 <? xml version ="1.0" encoding=" UTF -8"?> 2 <! DOCTYPE form - validation PUBLIC 3 " -// Apache Software Foundation // DTD Commons Validator Rules Configuration 1.1.3// EN" 4 "http :// jakarta. apache.org / commons /dtds / validator_1_1_3.dtd "> 5 6 <!-- ====================================================================== --> 7 <!-- Validation rules for the Cybercoach project --> 8 <!-- ====================================================================== --> 9 <form - validation > 10 <formset > 11 <form name =" adduserform "> 12 <field 13 property =" firstname " 14 page ="1" 15 depends =" required "> 16 <arg0 key =" user. firstname "/> 17 </ field > 18 <field 19 property =" lastname " 20 page ="1" 21 depends =" required "> 22 <arg0 key =" user. lastname "/> 23 </ field > 24 <field 25 property =" street " 26 page ="1" 27 depends =" required "> 28 <arg0 key =" user. street "/> 29 </ field > 30 <field 31 property =" zip " 32 page ="1" 33 depends=" required, mask "> 34 <arg0 key =" user.zip "/> 35 <var > 36 <var -name >mask </ var -name > 37 <var - value >^\ d {4,5}$</ var - value > 38 </var > 39 </ field > 40 <field 41 property =" city " 42 page ="1" 43 depends =" required "> 44 <arg0 key =" user.city "/> 45 </ field > 46 <field 47 property =" phonehome " 48 page ="1" 49 depends=" required, mask "> 50 <arg0 key =" user. phonehome "/> 51 <var > 52 <var -name >mask </ var -name > 53 <var - value >^((\+{1,2}\ d {2}\ s?\d {1,2}) (\ d {2,3})) 54 \s?\/?\ s?\d {3}\ s?\ d {2}\ s?\d{2}$ </ var - value > 55 </var > 56 </ field > <field 77

78 C. Beispiele J2EE- und Struts-Konfiguration 59 property =" " 60 page ="1" 61 depends=" required, "> 62 <arg0 key =" user. "/> 63 </ field > 64 <field 65 property =" dateofbirth " 66 page ="1" 67 depends=" required, date "> 68 <arg0 key =" user. dateofbirth "/> 69 <var > 70 <var -name >datepattern </ var - name > 71 <var - value >dd.mm.yyyy </ var - value > 72 </var > 73 </ field > </form > <form name =" showactivitiesform "> 78 <field 79 property =" datefrom " 80 depends =" date "> 81 <arg0 key =" showactivities. datefrom "/> 82 <var > 83 <var -name >datepattern </ var - name > 84 <var - value >dd.mm.yyyy </ var - value > 85 </var > 86 </ field > 87 <field 88 property =" dateto " 89 depends =" date "> 90 <arg0 key =" showactivities. dateto "/> 91 <var > 92 <var -name >datepattern </ var - name > 93 <var - value >dd.mm.yyyy </ var - value > 94 </var > 95 </ field > 96 </form > 97 </ formset > 98 </form - validation > C.4. tiles-defs.xml 1 <? xml version ="1.0" encoding=" UTF -8"?> 2 <! DOCTYPE tiles - definitions PUBLIC 3 " -// Apache Software Foundation // DTD Tiles Configuration // EN" 4 "http :// jakarta. apache.org / struts /dtds /tiles - config.dtd "> 5 6 <!-- ====================================================================== --> 7 <!-- Tiles definitions for the Cybercoach project --> 8 <!-- ====================================================================== --> 9 <tiles - definitions > 10 < definition name =" base. layout " path ="/ layout.jsp "> 11 <put name=" header " value ="/ header.jsp "/> 12 <put name=" menu " value ="/ menu.jsp "/> 13 <put name =" content " value ="${ content }"/ > 14 <put name=" footer " value ="/ footer.jsp "/> 15 </ definition > 16 < definition name =" welcome.page " extends =" base. layout "> 17 <put name=" content " value ="/ welcome.jsp "/> 18 </ definition > 19 < definition name =" login.page " extends =" base. layout "> 20 <put name=" content " value ="/ login.jsp "/> 21 </ definition > 22 < definition name =" login. error.page " extends =" base. layout "> 23 <put name=" content " value ="/ loginerror.jsp "/> 24 </ definition > 25 < definition name =" main.page " extends =" base. layout "> 26 <put name=" content " value ="/ main.jsp "/> 27 </ definition > 28 < definition name =" error.page " extends =" base. layout "> 29 <put name=" content " value ="/ error.jsp "/> 30 </ definition > 31 < definition name =" add.user.1. page " extends =" base. layout "> 32 <put name=" content " value ="/ adduser1.jsp "/> 33 </ definition > 34 < definition name =" add.user.2. page " extends =" base. layout "> 35 <put name=" content " value ="/ adduser2.jsp "/> 36 </ definition > </tiles - definitions > 78

79 D. XML-Datei für Aktivitäten D.1. DTD 1 <?xml version ="1.0" encoding="utf -8"? > 2 3 <!-- ====================================================================== --> 4 <!-- DTD for the Cybercoach Activity XML File, Version > 5 <!-- ====================================================================== --> 6 7 <!-- Activity root element --> 8 <! ELEMENT activity (datetime, calories, discipline, point *)> 9 10 <!-- Measuring point --> 11 <! ELEMENT point (x, y, z, t, hr)> <!-- Start of activity ( date and time ) --> 14 <! ELEMENT datetime (# PCDATA )> <!-- Calories expended --> 17 <! ELEMENT calories (# PCDATA )> <!-- Discipline name --> 20 <! ELEMENT discipline (# PCDATA )> <!-- X- Coordinate --> 23 <! ELEMENT x (# PCDATA )> <!-- Y- Coordinate --> 26 <! ELEMENT y (# PCDATA )> <!-- Z- Coordinate --> 29 <! ELEMENT z (# PCDATA )> <!-- Time --> 32 <! ELEMENT t (# PCDATA )> <!-- Heart rate --> 35 <! ELEMENT hr (# PCDATA )> D.2. Beispiel 1 <?xml version ="1.0" encoding="utf -8"? > 2 <activity > 3 <datetime > :31:19 </ datetime > 4 <calories >6</ calories > 5 <discipline >Running </ discipline > 6 <point > 7 <x> </x> 8 <y> </y> 9 <z >540 </z> 10 <t >0 </t > 11 <hr >144</ hr> 12 </ point > 13 <point > 14 <x> </x> 15 <y> </y> 16 <z >540 </z> 17 <t >5 </t > 18 <hr >167</ hr> 19 </ point > 20 <point > 21 <x> </x> 22 <y> </y> 23 <z >540 </z> 24 <t >10 </t> 25 <hr >146</ hr> 26 </ point > </ activity > 79

80 E. Verwendete Software E.1. Applikationsserver und Datenbank E.1.1. JBoss Als Applikationsserver wird JBoss 4.0 [JBo05] verwendet. JBoss 4.0 ist ein zertitizierter J2EE 1.4 Open-Source Applikationsserver und implementiert die EJB 2.1 Spezifikation. JBoss basiert auf einem modularen Mikrokernel-Design. Dienste können je nach Einsatzbedarf hinzugefügt oder entfernt werden. Abbildung E.1.: JMX-Console für JBoss Abbildung E.1 zeigt die Webanwendung JMX-Console, welche mit JBoss mitgeliefert wird und verschiedene Funktionen für die Verwaltung des Applikationsservers zur Verfügung stellt. E.1.2. MySQL Für die persistente Speicherung von Daten wird MySQL 4.1 [MyS05] verwendet. MySQL ist eine relationale Open-Source Datenbank, die den SQL-Standard implementiert. Für die Verwendung von MySQL als persistenter Datenspeicher muss in der JBoss Konfiguration eine JDBC-Datenquelle angelegt werden, welche den MySQL-Treiber referenziert (siehe 80

81 E. Verwendete Software Anhang G.5). Mit der Kombination von JBoss und MySQL wurden im Allgemeinen gute Erfahrungen gemacht. Keine grösseren Probleme sind aufgetaucht. Ein Vorteil ist, dass JBoss Datenbanktabellen für Entitäten automatisch erzeugen kann und die automatische Generierung von Primärschlüsseln durch MySQL unterstützt. Im Cyberchoach Projekt werden verschachtelte Select-Ausdrücke verwendet, welche MySQL seit der Version 4.1 unterstützt. E.2. Entwicklung E.2.1. Eclipse Das Cybercoach-Projekt wurde mit Eclipse 3.0 [Ecl05] implementiert. Eclipse ist eine Open- Source Entwicklungsumgebung (IDE) für Java und andere Sprachen. Abbildung E.2 zeigt die Eclipse IDE unter Mac OS X. Abbildung E.2.: Eclipse 3.0 Eine Stärke von Eclipse ist die Erweiterbarkeit durch dessen Plugin-System. Für die Entwicklung von Cybercoach wurden die bereits mit Eclipse gelieferten Plugins für Ant und JUnit verwendet. JBoss bietet das frei erhältliche Plugin JBoss-IDE an, mit welchem der JBoss Applikationsserver und XDoclet gesteuert werden können. Auf den Gebrauch dieses Plugins wurde jedoch bei der entwicklung des Projektes verzichtet, da die Integration von JBoss und XDoclet durch die Ant Build-Datei erfolgt. 81

82 E. Verwendete Software E.2.2. Ant Ant [Ant05] ist ein in Java geschriebenes Werkzeug zum automatisierten Erzeugen von Programmen. Damit erfüllt es einen ähnlichen Zweck wie das auf Unix Systemen weit verbreitete Programm Make. Ant ist ein Open-Source Programm und wird von der Apache Software Foundation entwickelt. Gesteuert wir Ant durch eine XML-Datei, die sogenannte Build-Datei. In dieser Datei werden die Abhängigkeiten der Einzelnen Aufgaben (Targets) definiert, die für das Erzeugen des Programms notwendig sind. Abbildung E.3.: Ant-Plugin für Eclipse Abbildung E.3 zeigt das Ant-Plugin für Eclipse, mit welchem Targets direkt in Entwicklungsumgebung ausgeführt werden können. E.2.3. XDoclet XDoclet [XDo05] ist eine quelloffenes Werkzeug für die Generierung von Code. XDoclet liest Java Quelldateien ein und wertet die darin enthaltenen Metainformationen aus. Die Metainformationen werden in Form von JavaDoc-Tags direkt im Quellcode angegeben. Beispiele von möglichen Zielformaten sind XML-Dateien und Java Quelldateien. 82

83 E. Verwendete Software XDoclet wird mit Ant in den Build-Prozess integriert. Es existieren verschiedene Ant-Tasks, mit welchen XDoclet konfiguriert und gesteuert wird. Für das Cybercoach-Projekt wurde XDoclet verwendet, um die Remote-, Local- und Homeinterfaces, sowie die Deployment-Deskriptors für Enterprise JavaBeans zu generieren. Es besteht auch die Möglichkeit Konfigurationsdateien für Struts automatisch zu erzeugen. Jedoch können nicht alle notwendigen Informationen als JavaDoc-Tags in den Struts Klassen definiert werden und es müssen ergänzende Konfigurationsdateien, sogenannte Merge-Files, erstellt werden. Der Entwicklungsaufwand wird dadurch mit XDoclet kaum verringert und die Konfiguration von Struts wird unübersichtlich. Aus diesem Grund wurde für das Projekt auf die automatische Generierung der Struts-Konfigurationsdateien durch XDoclet verzichtet. E.2.4. JUnit/Cactus JUnit [JUn05] ist ein Framework zum Testen von Java-Programmen. Es ist besonders geeignet für automatisierte Tests einzelner Klassen (Units). Cactus [Cac05] ist ein Test-Framework, welches auf JUnit aufbaut und für das server-seitige Testen verwendet wird. Für das Cybercoach- Projekt wurden server-seitige Tests für die Enterprise JavaBeans geschrieben. Eclipse bietet eine integrierte Unterstützung für JUnit. Die Entwicklungsumgebung lässt einzelne Testklassen direkt ausführen und wertet das Resultat grafisch aus. Abbildung E.4.: Testresultate von JUnit/Cactus als HTML-Bericht JUnit wird durch Ant auch in den Build-Prozess integriert. Dies erlaubt es, mit einem einzigen Ant Befehl das Projekt zu kompilieren, auf den Applikationsserver zu laden und die Tests auszuführen. Diese Möglichkeit erwies sich während der Entwicklungsphase als sehr mächtig und motivierte, sauber und umfangreich zu testen. Aus den Testresultaten von JUnit beziehungsweise Cactus lassen sich auch Berichte im HTML-Format generieren. Abbildung E.4 zeigt einen Bericht mit Testresultaten des Cybercoach-Projekts. 83