zum Systementwicklungsprojekt Erweiterung des J2EE-basierten Group

Document Sample
zum Systementwicklungsprojekt Erweiterung des J2EE-basierten Group Powered By Docstoc
					         Lehrstuhl Informatik IV Prof. M. Broy
          Technische Universität München




                Ausarbeitung
           zum Systementwicklungsprojekt
"Erweiterung des J2EE-basierten Group Knowledge
 Management Systems CROFT um konfigurierbare
   Homepages und Workspaces für Projekte und
                   Mitarbeiter"


                  von Igor Grosche

         Betreuer: Dipl.-Inf. Frank Marschall
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces




Inhaltsverzeichnis

Einleitung _________________________________________________________________ 3
Aufgabenstellung ___________________________________________________________ 3
Ausgangssituation __________________________________________________________ 3
Anforderungen _____________________________________________________________ 4
Realisierung _______________________________________________________________ 5
  Fachliches Modell__________________________________________________________ 6
  Datenstrukturen___________________________________________________________ 7
    Einfache Ansichtskomponenten ________________________________________________________ 8
    Listen____________________________________________________________________________ 8
    Ansichtskonfiguration _______________________________________________________________ 9
    Relationen _______________________________________________________________________ 10
    Klassenstruktur ___________________________________________________________________ 10
  Business-Logic-Schicht_____________________________________________________ 11
    ViewEJB ________________________________________________________________________ 11
    ViewManagerEJB _________________________________________________________________ 13
    DAO-Klassen ____________________________________________________________________ 15
  Persistence-Schicht________________________________________________________ 17
  Presentation-Schicht_______________________________________________________ 19
    "JavaServer Pages Model 2"-Architektur________________________________________________ 19
    Webbeans _______________________________________________________________________ 20
    Ansatz von der JSP-Tag Library Spezifikation ____________________________________________ 20
Neue Entitätstypen in die Ansichtskonfigurationen aufnehmen _____________________ 23
  Datenbank ______________________________________________________________ 23
  Business-Logik ___________________________________________________________ 23
    EJBs ___________________________________________________________________________ 23
    DAOs __________________________________________________________________________ 23
  JSPs ___________________________________________________________________ 24
Zusammenfassung _________________________________________________________ 25
Informationsquellen________________________________________________________ 26




Igor Grosche, 04.09.2001                                                                      2
            Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces



Einleitung
Am Lehrstuhl Prof. Broy entstand im Rahmen des Softwaretechnikpraktikums im
Sommersemester 2000 das Group Knowledge Management System CROFT zur Verwaltung
von Personen, Projekten, Dokumenten und Kontakten.

Die Anwendung wurde auf Basis der Java 2 Enterprise Edition (J2EE)1 realisiert, die ein
Framework zur komponentenbasierten Entwicklung von Serverapplikationen mit HTML-
Clients bietet. Hierbei kamen neuste Technologien wie Enterprise JavaBeans (EJBs)2,
JavaServer Pages (JSPs)3 und JDBC zum Einsatz. Im Rahmen dieses
Systementwicklungsprojektes wurde die Anwendung weiter ausgebaut und verbessert.



Aufgabenstellung
Das Ziel des Systementwicklungsprojektes war es, das bestehende System um
konfigurierbare, webbasierte Homepages und Workspaces für Projekte und Mitarbeiter zu
erweitern. Diese Seiten sollten jeweils Informationen enthalten, die für die Arbeit eines
Mitarbeiters oder eines Projektes relevant sind bzw. für ihre Darstellung nach außen zur
Verfügung stehen. Die Webseiten sollten dynamisch mit Hilfe von JSPs generiert werden,
wobei der Benutzer die dargestellten Inhalte zur Laufzeit mittels einer GUI konfigurieren
kann.

Im einzelnen wurden folgende Schritte für die Projektdurchführung vorgesehen:
• Einarbeitung in die J2EE und das CROFT-System
• Konzeption und Realisierung eines Mechanismus zur Verwaltung der Konfigurationen auf
   Basis von EJBs
• Konzeption und Realisierung einer geeigneten web-basierten Benutzerschnittstelle zur
   Konfiguration der Homepages/Workspaces (mit JSPs oder/und Applets)
• Erweiterung der bestehenden dynamischen Homepages und Workspaces um die
   Darstellung der konfigurierbaren Inhalte



Ausgangssituation
Die Ansichten in der ersten CROFT-Version konnten die Anforderungen an der
Konfigurierbarkeit und der flexiblen Gestaltung von für die Arbeit von Lehrstuhl-Mitarbeiter
oder Projektmitglieder benötigten Informationen nicht gerecht werden:
• die Ansichten konnten nur geringfügig umgestaltet werden
• es gab keine Möglichkeit, die Informationen (in Listen) zu strukturieren
• man konnte keine Bilder, Texte oder Links auf Ansichten unterbringen
• man konnte keine selbst definierten Passagen mit HTML-Code den Ansichten
    hinzufügen
• die Tabellen waren hart codiert, man konnte nicht die interessierenden Spalten
    auswählen oder die Sortierung festlegen
• es konnte nur jeweils eine interne und eine öffentliche Ansicht für eine Person bzw. ein
    Projekt angelegt werden


1
    [J2EE 2000]
2
    [EJB 1999]
3
    [JSP 1999]

Igor Grosche, 04.09.2001                                                                       3
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces


Ein weiteres Problem bestand darin, dass der Aufbau von Ansichten mit Hilfe JSPs ziemlich
kompliziert war. Man brauchte das Verständnis dieses Aufbaus, um irgendwelche
Änderungen vornehmen zu können. Um nur geringfügige Designanpassungen zu machen,
mußte man mit der JSP-Struktur der Ansichten vertraut sein.
Es mußte also eine sinnvolle Trennung des Inhalts von der reinen Web-Seiten-Gestaltung
(Design) vorgenommen werden. Dabei sollte eine Auslagerung der Behandlung von
Benutzereingaben aus den JSPs , die für die reine Darstellung verantwortlich sind, in die
"Controller"-JSPs oder -Servlets erreicht werden.

Es gab zwei Arten von Ansichten:
   • Interne Ansicht (Homepage)
   • Öffentliche Ansicht (Workspace)

Jede Ansicht hatte einen Header und drei vordefinierten Tabellen. Der Header enthielte
Namen, Titel und Foto der Person bzw. Namen, Kurzbeschreibung, Logo und Status des
Projektes. Diese Daten gehörten zu den Person- bzw. Projektdaten und konnten im Dialog
"Person ändern" bzw. "Projekt ändern" geändert werden.

Die Tabellen in den Ansichten spiegelten die fachlichen Beziehungen zwischen Entitäten im
System (Personen, Projekten, Dokumenten und Kontakten) wie Mitgliedschaft oder Besitz
wieder. Eine Personenansicht stellte eine Tabelle mit allen Projekten, wo die Person Mitglied
ist, eine Tabelle mit allen Dokumenten und eine Tabelle mit allen Kontakten, die der Person
gehören, zur Verfügung. Auf einer Projektansicht konnte man eine Tabelle aller
Projektmitglieder, eine Tabelle aller Dokumente und eine Tabelle aller Kontakte, die
Projektbesitz sind, ansehen.

Zusätzlich gab es auf internen Ansichten die Möglichkeit, Dokumente und Kontakte den
jeweiligen Tabellen hinzuzufügen: man konnte von Homepages und Workspaces anderer
Projekte oder Personen interessierende Dokumente oder Kontakte in die Sammelmappe
kopieren, und dann sie auf eigener internen Ansicht in die jeweiligen Tabellen übernehmen.
Auf der internen Projektansicht konnten auf diese Weise neue Projektmitglieder dem
jeweiligen Projekt hinzugefügt werden.



Anforderungen
Die funktionalen Anforderungen an die neuen Ansichten wurden hauptsächlich durch die
Aufgabenstellung definiert.

Die zusätzlichen, nicht-funktionalen Anforderungen waren:
   • die mit der verbesserten Konfigurierbarkeit der Ansichten entstandene
       Verkomplizierung der Struktur der Seiten sollte nicht zu den langen Ladezeiten führen
       (effizienter Datenbankzugriff und kompakte Datenstrukturen)
   • die im CROFT-System neu eingeführten Entitäten sollten leicht in die Ansichten
       integriert werden können
   • es sollten keine Veränderungen an den bestehenden Entitäten vorgenommen werden




Igor Grosche, 04.09.2001                                                                        4
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces



Realisierung
Als Ergebnis des Systementwicklungsprojektes wurde eine Komponente entwickelt, die
alleine für die Darstellung und die persistente Speicherung von Ansichtskonfigurationen im
CROFT-System verantwortlich und von Entitäten im System unabhängig ist.

Die Realisierung erfolgte auf drei Architekturebenen: Business-Logic-Schicht, Persistence-
Schicht und Presentation-Schicht (siehe Abbildung 1).




                                 Abbildung 1: Realisierung


Der Mechanismus zur Verwaltung von Ansichtskonfigurationen wurde in der Business-Logik
gekapselt (siehe EJB-Ebene in der Abbildung 1). Dafür wurden zwei EJBs entwickelt und
implementiert (ViewEJB und ViewManagerEJB). Sie gewährleisten u.a. die
Persistenzhaltung der Konfigurationsinformationen in einer Datenbank. Für den DB-Zugriff
verwenden sie Data Access Objects (DAOs). Die ViewEJB greift auf ein ViewDAO, um neue
Ansichtskonfigurationen anzulegen, nach bestehenden zu suchen, sie zu ändern und zu
laden. Die EntityBean verwendet dabei das ViewRelationDAO, um Informationen über
Relationen (z.B. Ansichtskonfiguration - ihr Besitzer, Ansichtskonfiguration - ihre
Komponenten usw.) aus der Datenbank zu gewinnen. Da in Ansichten auch Daten der
Homepage- und Workspace-Besitzer dargestellt werden sollen (Name, Bild oder Logo usw.),
kommuniziert die ViewEJB mit Person- und ProjectEJBs. Die ViewManagerEJB spielt die
Rolle eines Verwalters für Ansichtskonfigurationen und ihre Komponenten. Sie stützt sich auf
ListDAO und ViewEntityDAO, um Listen und Ansichtskomponenten (Bilder, Texte, Links) zu
verwalten. Relationen zwischen diesen und Ansichtskonfigurationen werden über
ViewRelationDAO administriert.

Die Realisierung auf dem Persistence-Schicht (DB-Ebene in der Abbildung 1) wurde durch
das Anlegen von Datenbanktabellen für Ansichtskonfiguration- und Listen-Informationen und
den Relationen zwischen denen in einer Oracle8i-Datenbank erledigt. Eine zusätzliche
Tabelle wurde für Ansichtskomponenten (Bilder, Links, Texte) angelegt.

Auf dem Presentation-Schicht (JSP-Ebene in der Abbildung 1) wurden JSPs für zusätzliche
Dialoge und die Darstellung von Listen, Tabellen, Homepages und Workspaces sowie die

Igor Grosche, 04.09.2001                                                                     5
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces


"Controller"-JSPs zur Bearbeitung von Benutzereingaben implementiert. Für die
Kommunikation zum Business-Logic-Schicht sind drei Web-Beans zuständig, die Modell-
Objekten zwischen den zwei Schichten austauschen. In Modell-Klassen sind die
verwendeten Datenstrukturen implementiert.



Fachliches Modell

Eine Ansichtskonfiguration (ViewConfiguration) ist für die Verwaltung und
Persistenzhaltung von Informationen bezüglich des Aussehen und der Gestaltung einer
Ansicht und ihrer Komponenten verantwortlich.

Fachliche Beziehungen zwischen Ansichtskonfigurationen, ihren Komponenten und anderen
Entitäten im CROFT-System sind in der Abbildung 2 graphisch dargestellt.




                               1                                          1
           Person                                                              Projekt
                                          *                    *
                                            View
                                         Configuration
                                              1        1
                 *                                                                *
          Userlist             1                           *           PlainViewComponent
     1       *             1
                                                                                  *
                                          Systemlist
                                    1                              1


                                   Abbildung 2: Fachliches Modell


Jede Ansichtskonfiguration ist zu einer Person oder einem Projekt zugeordnet. Es gibt zwei
Ansichtsarten, die sich im Allgemeinen nur in den Zugriffsbeschränkungen für Benutzer des
CROFT-Systems unterscheiden:
   • Homepage - die öffentliche Ansicht einer Person bzw. eines Projektes, die für alle
       Interessenten zugänglich ist.
   • Workspace - die private passwortgeschützte Ansicht einer Person bzw. eines
       Projektes, die nur für die entsprechende Person bzw. Mitglieder des jeweiligen
       Projektes zugänglich ist.

Für eine Person oder ein Projekt dürfen mehrere Homepage- bzw. Workspace-
Konfigurationen definiert werden.



Igor Grosche, 04.09.2001                                                                     6
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces


Eine Ansichtskonfiguration kann beliebig viele Bilder, Texte, Links (PlainViewComponents)
und Tabellen (Userlists) enthalten. In den Tabellen können sowohl PlainViewComponents
als auch andere Listen gruppiert werden.



Datenstrukturen

Eine Ansicht (z.B. Webseite) hat üblicherweise einen Titel, Attribute (für eine Webseite
werden sie im HTML <BODY>-Tag definiert, z.B. Text-, Hintergrund- oder Link-Farbe) und
eine Menge von Komponenten, die den eigentlichen Inhalt repräsentieren sollen
(beispielsweise Texte, Bilder, Links, Tabellen, Tabelleneinträge usw.).

Es wird dabei zwischen einfachen (PlainViewComponents) und zusammengesetzten
Komponenten (Userlists und Systemlists) unterschieden (siehe Abbildung 2):
• zu den einfachen Ansichtskomponenten (PlainViewComponents) zählen
   Komponenten, die keine anderen Komponenten beinhalten, also keine Container sind (im
   Sinne Java-AWT- bzw. Java-Swing-Terminologie). Das sind Bilder, einfache Texte,
   Links, Target-Texte (Texte, die von einer URL geladen werden können) sowie Einträge in
   Tabellen;
• die Listen stellen Container dar, die PlainViewComponents oder auch andere Listen
   beinhalten können.

Die Struktur von Komponententypen in Ansichtskonfigurationen ist in der Abbildung 3
graphisch dargestellt.



                                        ViewConfiguration -
                                           Komponenten



                Plain                                                      List
           ViewComponent
                  s


    Person                 ViewEntity                    Systemlist                   Userlist


    Project
                                           Image


  Document                                  Link


                                        Target-Text
   Contact

                                            Text


                 Abbildung 3: Komponententypen in Ansichtskonfigurationen

Igor Grosche, 04.09.2001                                                                    7
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces



Das Modell einer Ansichtskonfiguration-Komponente ist durch die
de.tum.in.croft.view.model.ViewComponentModel-Klasse implementiert. Die Klasse
enthält Felder und Zugriffsmethoden für einen Identifikator, einen Namen und eine
Hashtabelle für beliebigen Attribute. Falls Daten für eine Komponente nicht geladen werden
konnten, hat die Klasse ein String-Feld für die entsprechende Fehlermeldung.


Einfache Ansichtskomponenten

Jede Komponente einer Webseite (Bild, Text, Link, Tabelle, Tabelleneintrag) kann man als
PlainViewComponent interpretieren. Ein PlainViewComponent kann man entweder direkt
(z.B. Bild auf einer Webseite) oder als ein Teil einer zusammengesetzten Komponente (z.B.
Eintrag einer Tabelle) darstellen. Bilder, Texte, Target-Texte und Links sind sowohl für die
direkte Darstellung als auch für Einträge in Tabellen geeignet. Sie werden im Weiteren als
"ViewEntity"'s bezeichnet.

Die ViewEntities können von vier Inhaltstypen sein:
        • Bild (Image)
        • Text
        • Target-Text
        • Link

Die ViewEntities sind durch die de.tum.in.croft.view.model.ViewEntityModel-Klasse
implementiert und erweitert die de.tum.in.croft.view.model.ViewComponentModel-Klasse.

Für die ViewEntities sind folgende Attribute vorgesehen:
• Inhaltstyp
• Inhalt (für Bilder, Links und Target-Texte - eine URL, für einfache Texte - den Text selbst)

Entitäten im CROFT-System (Person, Projekt, Dokument, Kontakt) werden auch als
PlainViewComponents einer Homepage oder eines Workspaces interpretiert. Sie können nur
als Einträge in einer Tabelle dargestellt werden. Für die direkte Darstellung sind
entsprechende Ansichten zuständig (z.B. Dokumentenansicht, Kontaktansicht,
Projekthomepage usw.).

Bei der Darstellung in Tabellen werden nur die für den jeweiligen Tabelleneintrag relevanten
Informationen über die Entität aus einer Datenbank geholt (z.B. Titel, Typ und Status eines
Dokumentes) und an den Presentation-Schicht in einem PlainViewComponent
(ViewComponentModel-Klasse) verpackt übergeben. Da die Attribute in der
ViewComponentModel-Klasse in einer Hashtabelle organisiert sind, kann man z.B. für eine
Person ihren Vor- und Nachnamen als Attribute speichern. Die Information, zu welchem
Entitätstyp eine oder andere ViewComponentModel-Instanz gehört, wird dagegen im
umgebenden Listen-Objekt gehalten.


Listen

Eine Liste kann mehrere PlainViewComponents eines Entitätstyps beinhalten.

Bei den Listen unterscheidet man:
• Systemlisten, die direkt fachliche Zusammenhänge im System widerspiegeln (z.B.
    enthält die Systemliste "Projektmitglieder" alle Personen, die Mitglied in einem Projekt
    sind; wird eine Person aus dieser Liste gelöscht, so ist sie damit automatisch nicht mehr


Igor Grosche, 04.09.2001                                                                         8
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces


    Mitglied des Projektes; auf der Homepage der entsprechenden Person taucht das Projekt
    nicht mehr in der Systemliste "Eigene Projekte" auf) und
•   benutzerdefinierte Listen (Userlists), die keine fachlichen Zusammenhänge
    widerspiegeln, sondern sind lediglich eine Sammlung von Referenzen (z.B. eine
    Dokumenten-Liste, in der Dokumente anderer Personen oder Projekte liegen können;
    wird ein Dokument gelöscht, so verschwindet es lediglich aus dieser Liste, der jeweilige
    Besitzer merkt jedoch nichts davon).

Systemlisten sind fest mit den fachlichen Beziehungen im System verknüpft. Ihre
Komponenten kann man durch eine Abfrage bzgl. einer Beziehung (z.B. Mitglieder in einem
Projekt) ermitteln. Deshalb wurden Systemlisten fest definiert und können für jede Ansicht
eingesetzt werden. Im CROFT-System stehen vier Systemlisten zur Verfügung:
• "Projektmitglieder" - kann einer Projektansicht hinzugefügt werden und enthält alle
    Personen, die im Projekt mitarbeiten,
• "Eigene Projekte" - kann einer Personenansicht hinzugefügt werden und enthält alle
    Projekte, in denen die Person Mitglied ist,
• "Eigene Dokumente" - kann sowohl einer Projekt- als auch einer Personenansicht
    hinzugefügt werden und enthält alle Dokumente, die der jeweiligen Person bzw. dem
    jeweiligen Projekt gehören,
• "Eigene Kontakte" - kann sowohl einer Projekt- als auch einer Personenansicht
    hinzugefügt werden und enthält alle Kontakte, die der jeweiligen Person bzw. dem
    jeweiligen Projekt gehören.

Eine Liste kann auch als ein Eintrag in einer anderen Liste interpretiert werden. Demnach
können Listen andere Listen beinhalten. Es sind beliebige Schachtelungen zulässig.

Listen sind durch die ListModel-Klasse (de.tum.in.croft.view.model.ListModel) implementiert,
die von der ViewComponentModel-Klasse abgeleitet ist. Für die Listenkomponenten ist ein
ArrayList-Objekt vorgesehen. Eine Liste hat folgende Attribute:
• Typ der Liste (Systemliste oder benutzerdefinierte Liste)
• Entitätstyp der Komponenten
• Status der Liste bei der Darstellung (auf- oder zugeklappt)

Falls eine benutzerdefinierte Liste als eine Tabelle (z.B. HTML-Tabelle) dargestellt werden
soll, werden zusätzlich folgende Attributen gebraucht:
• Maximale Listenlänge,
• Spalten für die Tabelle,
• Name der Spalte, nach der sortiert werden soll.


Ansichtskonfiguration

Eine Ansichtskonfiguration stellt ähnlich wie eine Liste einen Container dar, der andere
PlainViewComponents und Listen enthält. Dementsprechend kann man die
Listenfunktionalität für Ansichtskonfigurationen übernehmen.

Die Datenstruktur für Ansichtskonfigurationen wird durch die ViewModel-Klasse
(de.tum.in.croft.view.model.ViewModel) implementiert, die, wie es schon oben angedeutet,
von der ListModel-Klasse abgeleitet ist. Die ViewModel-Klasse hat folgende Eigenschaften:
• Typ der Ansicht, zu der die Ansichtskonfiguration gehört (Homepage oder Workspace),
• Flag, der signalisiert, ob die Ansichtskonfiguration aktiviert ist.

Wie es schon oben erwähnt, kann für eine Person oder ein Projekt mehrere
Ansichtskonfigurationen definiert werden. Demnach kann eine Homepage oder ein
Workspace in verschiedenen Konfigurationen dargestellt werden. Um aber festzulegen, in

Igor Grosche, 04.09.2001                                                                      9
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces


welcher Konfiguration die jeweilige Ansicht für den Benutzer erscheinen soll, wird jeweils
eine der definierten Konfigurationen aktiviert.

Eine Ansicht enthält normalerweise Informationen, die den Besitzer der Homepage oder des
Workspaces betreffen. Im CROFT-System werden beispielsweise Name, Position und URL
für den Bild einer Person benötigt. Für ein Projekt sind das die URL für das Projekt-Logo, die
Kurzbeschreibung und der Status des Projektes. Für diesen Zweck hat die ViewModel-
Klasse eine Hashtabelle, in der diese Informationen abgelegt und abgefragt werden können.

Außerdem hat die ViewModel-Klasse folgende Attribute:
• Background-Farbe
• URL für ein Background-Bild
• Farbe für Links
• Farbe für aktive Links
• Farbe für schon besuchte Links
• Farbe des Standardtextes in der Ansicht


Relationen

Jede Ansichtskonfiguration steht in einer Relation (Beziehung) zu ihrem Besitzer (man sagt,
eine Ansichtskonfiguration gehört zu einer Person bzw. einem Projekt) bzw. zu ihren
Komponenten (eine Ansichtskonfiguration enthält eine Komponente). Genauso hat eine
Liste eine Relation zu ihren Komponenten (eine Liste enthält eine Komponente). Für die
Verwaltung von diesen drei Relationen wurde ein abstraktes Datenmodell verwendet, das
folgende Felder beinhaltet:
• Typ der Relation (Ansichtskonfiguration - ihr Besitzer, Ansichtskonfiguration - ihre
    Komponente oder Liste - ihre Komponente)
• Identifikator der ersten Komponente
• Identifikator der zweiten Komponente
• Typ der zweiten Komponente
• Eine Hashtabelle für Zusatzattribute, die für die jeweilige Relation relevanten
    Informationen erhalten (z.B. in der Relation "Ansichtskonfiguration - Besitzer der
    Ansichtskonfiguration" kann man den Typ der Ansicht und den Aktivitätsflag ablegen)

Das Modell ist durch die ViewRelationModel-Klasse
(de.tum.in.croft.view.model.ViewRelationModel) implementiert.


Klassenstruktur

In der Abbildung 4 ist die Vererbungshierarchie der Klassen für die oben beschriebenen
Datenstrukturen graphisch dargestellt.




Igor Grosche, 04.09.2001                                                                     10
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces




                                           Object




                 ViewComponentModel                   ViewRelationModel




  ViewEntityModel                         ListModel




                                          ViewModel

                 Abbildung 4: Vererbungshierarchie bei der Datenstrukturen



Business-Logic-Schicht

Wie es schon in der Einführung zum Kapitel erwähnt, wurden zwei EJBs zur Verwaltung von
Ansichtskonfigurationen entwickelt:
       • ViewEJB
       • ViewManagerEJB

Die erste EJB übernimmt die Verwaltung von Attributen und das Laden einer
Ansichtskonfiguration. Die zweite EJB verwaltet Komponenten und bietet zusätzliche
Dienste zur Verfügung, wie das Erstellen von Default-Ansichtskonfigurationen für neu
angelegte Projekte und Personen, das Aktivieren von Ansichtskonfigurationen usw.

Bei der Realisierung wurde auf weitere persistente Komponenten (EntityBeans) verzichtet,
die eigentlich für Listen und ViewEntities angebracht wären. Die Entscheidung wurde wegen
der Peformance-Anforderung getroffen. Die erhöhten Lade- und Initialisierungszeiten für
EntityBeans konnten das Laden von Ansichtskonfigurationen erheblich verlangsamen, was
für eine webbasierte GUI zur Benutzerunfreundlichkeit des Gesamtsystems führen konnte.
Deshalb wurden Persistence-Mechanismen für Listen und Ansichtskomponenten in den
DAO-Klassen (de.tum.in.croft.view.ejb.impl.ListDAO und
de.tum.in.croft.view.ejb.impl.ViewEntityDAO) untergebracht. Die Verwaltung von Relationen
einer Ansichtskonfiguration wurde ebenso mit Hilfe einer DAO-Klasse
(de.tum.in.croft.view.ejb.impl.ViewRelationDAO) realisiert. Wegen der erheblichen
Bedeutung der DAO-Klassen wurde ihnen einen Extra-Abschnitt gewidmet.


ViewEJB

Die ViewEJB ist eine EntityBean. Sie stellt eine persistente Komponente dar, die
Informationen über eine Ansichtskonfiguration (Ansichtsattributen) verwaltet und Clients zur
Verfügung stellt.


Igor Grosche, 04.09.2001                                                                       11
          Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces


Das Home-Interface (ViewHome) der ViewEJB stellt Methoden bereit, die das Kreieren von
neuen Ansichtskonfigurationen und das Überprüfen, ob eine Ansichtskonfiguration mit einem
bestimmten PrimaryKey oder eine aktivierte Ansichtskonfiguration für eine bestimmte Person
oder ein Projekt existiert, ermöglichen (siehe Tabelle 1). Die Remove-Funktionalität ist über
die von der EJBHome vererbte remove()-Methode ansprechbar.


      Methode             Rückgabewert      Exception                  Beschreibung
                                                            Legt eine neue
                                                            Ansichtskonfiguration mit
                                                            Attributen, die im ViewModel-
                                                            Argument übergeben werden, für
                                                            die Entität vom Typ ownerType
create(
                                         CreateException,   (zur Zeit sind die Ansichten für
 ViewModel model,
                             View                           Personen und Projekte
 long ownerId,                           RemoteException
                                                            vorgesehen) mit der Identifikation-
 int ownerType)
                                                            Nummer ownerId. Die Methode
                                                            liefert eine Remote-Referenz auf
                                                            das neu angelegte View-Objekt
                                                            zurück

                                                          Überprüft, ob eine
                                                          Ansichtskonfiguration mit dem
                                                          Primary Key viewPK existiert und
findByPrimaryKey(                        FinderException, liefert eine Remote-Referenz auf
                             View
    ViewPK viewPK)                       RemoteException dieses Objekt zurück. Falls es
                                                          keine Ansichtskonfiguration mit
                                                          dem Key existiert, wird eine
                                                          FinderException ausgelöst.
                                                          liefert ein View-Objekt der
                                                          aktivierten Ansichtkonfiguration
                                                          vom Typ viewType (entweder
                                                          Homepage oder Workspace) für
findActiveViewForOwner(
                                                          die Entität vom Typ ownerType
   long ownerId,                         FinderException,
                             View                         (Person oder Projekt) mit der
   int ownerType,                        RemoteException
                                                          Identifikation-Nummer ownerId.
   int viewType)
                                                          Falls es keine
                                                          Ansichtskonfiguration mit dem Key
                                                          existiert, wird eine
                                                          FinderException ausgelöst.

                                 Tabelle 1: ViewHome-Interface


Über das Remote-Interface der ViewEJB (de.tum.in.croft.view.ejb.View) läßt sich das Modell
einer Ansichtskonfiguration ändern. Dafür stehen die Methoden getModel( ) und
setModel(ViewModel model) zur Verfügung. Die Zusammenfassung aller Methoden der
View-Interface ist in der Tabelle 2 dargestellt.




Igor Grosche, 04.09.2001                                                                    12
          Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces


      Methode           Rückgabewert         Exception              Beschreibung
                                                         Liefert das Modell der
getModel()               ViewModel       RemoteException
                                                         Ansichtskonfiguration
setModel(                                                Setzt das Modell der
                              -          RemoteException
  ViewModel model)                                       Ansichtskonfiguration zu model
                                                         Liefert true, wenn die EJB-Instanz
                                                         zwischenzeitlich irgendwelchen
isModified()               Boolean       RemoteException
                                                         Änderungen unterlag


                                     Tabelle 2: View-Interface


Für die EntityBean wurde, genauso wie im ganzen CROFT-System, Bean Managed
Persistance eingesetzt. Beim Anlegen, Ändern, Löschen und Laden von
Ansichtskonfigurationen in bzw. aus einer Datenbank verwendet die ViewEJB das ViewDAO.


ViewManagerEJB

Die ViewManagerEJB ist eine zustandlose SessionBean. Sie stellt Methoden zur Verfügung,
die man in drei Gruppen unterteilen kann:
• Methoden für das Anlegen, Ändern, Löschen und Laden von Listen und
    Ansichtskomponenten (ViewEntities) einer Ansichtskonfiguration,
• Methoden für die Verwaltung von Listen- und Ansichtskonfiguration-Komponenten
    (Einfügen, Löschen, Ersetzen)
• Methoden für die Ansichtskonfigurationen-Verwaltung: Anlegen von Default-
    Konfigurationen für neue Projekte und Personen, Aktivieren von Ansichtskonfigurationen,
    Laden einer Liste aller angelegten Konfigurationen einer Person oder eines Projektes.

Alle Methoden der ViewManager-Interface sind in der Tabelle 3 aufgelistet.


      Methode           Rückgabewert         Exception               Beschreibung
                                                          Legt eine Liste mit den Attributen
createList(                              CreateException,
                            Long                          von list an und liefert Identifikator
      ListModel list)                    RemoteException
                                                          der Liste zurück
                                                          Löscht die Liste mit dem ID listId
removeList(                              RemoveException in der Datenbank sowie alle
                              -
         long listId)                    RemoteException Komponenten, die sie beinhaltet,
                                                          und ihre Beziehungen
updateList(                                               Updatet eine Liste zur list
                              -          RemoteException
      ListModel list)
                                                          Lädt die Liste mit dem ID listId
loadList(long listId)    ListModel       RemoteException und liefert das ListModel-Objekt
                                                          zurück
                                                          Legt eine ViewEntity mit den
createViewEntity(
                                         CreateException, Attributen von viewEntity an und
 ViewEntityModel            Long
                                         RemoteException liefert Identifikator der ViewEntity
         viewEntity)
                                                          zurück
removeViewEntity(                        RemoveException Löscht die ViewEntity mit dem ID
                              -
            long id)                     RemoteException id in der Datenbank
updateViewEntity(                                         Updatet eine ViewEntity zur
  ViewEntityModel             -          RemoteException viewEntity
         viewEntity)

Igor Grosche, 04.09.2001                                                                      13
           Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces


                                                          Lädt die ViewEntity mit dem ID id
loadViewEntity(             ViewEntity-
            long id)           Model      RemoteException und liefert das ViewEntityModel-
                                                          Objekt zurück
addViewComponent(                                         Fügt ein neues ViewComponent
long viewId,                                              component der
ViewComponentModel               -        RemoteException Ansichtskonfiguration mit ID
           component,                                     viewId auf die Position position
int position)                                             hinzu
addViewComponents(                                        Fügt Komponenten aus dem
       long viewId,                                       ArrayList components der
                                 -        RemoteException
      ArrayList                                           Ansichtskonfiguration mit ID
         components)                                      viewId hinzu
replaceAllViewComponents(                                 Ersetzt alle Komponenten der
      long viewId,                                        Ansichtskonfiguration mit ID
                                 -        RemoteException
      ArrayList                                           viewId durch Komponenten
          components)                                     components
addListComponent(                                         Fügt ein neues ViewComponent
 long listId,                    -        RemoteException component der Liste mit ID listId
ViewComponentModel                                        hinzu
           component)
addListComponents(                                        Fügt Komponenten aus dem
  long listId,                                            ArrayList components der Liste
                                 -        RemoteException
  ArrayList                                               mit ID listId hinzu
         components)
removeComponents(                                         Entfernt Komponenten
   int listType,                                          components vom Typ entityType
   long listId,                                           aus der Liste
                                 -        RemoteException
   int entityType,                                        (Ansichtskonfiguration) vom Typ
   ArrayList                                              listType und mit dem ID listId
         components)
                                                            Legt Default-
                                                            Ansichtskonfigurationen für alle
createDefaultViews()                      RemoteException
                                                            Personen und Projekte im System
                                                            an
                                                            Legt eine Default-
                                                            Ansichtskonfiguration vom Typ
                                                            viewType für den Besitzer vom
CreateDefaultViewForOwner                                   Typ ownerType und mit dem ID
(                                                           ownerId an und setzt ihren
    long ownerId,                                           Aktivitätsflag auf activity (falls die
    int ownerType,           ViewPK       RemoteException
                                                            Ansichtskonfiguration gleich
    int viewType,                                           aktiviert werden soll, wird die zur
    int activity)                                           Zeit aktivierte
                                                            Ansichtskonfiguration deaktiviert).
                                                            Liefert PrimaryKey der neu
                                                            angelegten Ansichtskonfiguration
getAllViewsForOwner(         ArrayList    RemoteException   Liefert ein ArrayList aller für den
     long ownerId,                                          Besitzer vom Typ ownerType und
     int ownerType)                                         mit dem ID ownerId angelegten
                                                            Ansichtskonfigurationen zurück
activateView(                    -        RemoteException   Aktiviert die Ansichtskonfiguration
     long viewId,                                           vom Typ viewType und mit dem
     long ownerId,                                          ID viewId für den Besitzer vom
     int ownerType,                                         Typ ownerType und mit dem ID
     int viewType)                                          ownerId. Die zu dem Zeitpunkt

Igor Grosche, 04.09.2001                                                                       14
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces


                                                          aktivierte Ansichtskonfiguration
                                                          vom gleichen Type und für den
                                                          gleichen Besitzer wird deaktiviert

                             Tabelle 3: ViewManager-Interface


Eine zustandlose SessionBean hat bessere Performance-Eigenschaften als eine EntityBean.
Die Übernahme von den oben aufgeführten Aufgaben in die ViewManagerEJB trug deshalb
der Benutzerfreundlichkeit des CROFT-Systems bei.

Genauso wie ViewEJB stützt sich die ViewManagerEJB in der Kommunikation mit der
Datenbank auf DAO-Klassen ab.


DAO-Klassen

DAOs sind Hilfsobjekte, die das Lesen und Schreiben von Daten der EJBs in die Datenbank
ermöglichen. Es wurden vier DAO-Klassen implementiert:
   • ListDAO
   • ViewDAO
   • ViewEntityDAO
   • ViewRelationDAO

Die DAO-Klassen (außer ViewRelationDAO) implementieren die abstrakte AbstractDAO-
Klasse (siehe Abbildung 5), die allgemeine Interface-Methoden wie create(), remove(),
update() und load() definiert und Methoden openConnection(), closeConnection(), getId(),
setId(long id), getModel(), setModel(ViewComponentModel model), dispose() und finalize()
zur Verfügung stellt.

Alle DAO-Klassen verwenden das DBProperties-Interface (de.tum.in.croft.util.DBProperties),
das Konstanten für die Datenbankzugriffe (Tabellen-, Spaltennamen usw.) bereitstellt (siehe
Abbildung 5). Die Kapselung aller datenbankspezifischer Konstanten in einer Interface hat
den Vorteil, daß bei der Änderungen von Datenbanktabellen evtl. nur dieser Interface
angepaßt werden muß. Das Interface enthält auch Konstanten für verschiedene
Wertebereiche (Ansichtstypen, Relationtypen, Aktivitätstypen usw.) und Methoden für String-
Konvertierungen ihrer Werte.

Die ListDAO-Klasse stellt Methoden für Anlegen, Ändern, Löschen und Laden von
Listeninformationen in bzw. aus der Datenbank zur Verfügung. Beim Aufruf der load()-
Methode mit Argumenten (Spaltennamen und Spaltenname, nach der sortiert werden soll)
werden mit den Listeninformationen gleich auch die Komponenten der Liste geladen und
vorsortiert. Es werden dabei nur die Daten für Komponenten geladen, die den im Argument
übergebenen Spalten entsprechen, also z.B. für eine Projektmitglieder-Liste werden beim
Aufruf von:

       load("SURNAME, FIRST_NAME, POSITION", "SURNAME");

alle Projektmitglieder sortiert nach Nachnamen geladen und in ViewComponentModels mit
den entsprechenden IDs und den Attributen "SURNAME", "FIRST_NAME" und "POSITION"
in der components-Hashtabelle abgelegt (vgl. Abschnitt "Datenstrukturen"). Für die
Wertebereiche (wie in dem Beispiel für "POSITION") werden gleich die String-Darstellungen
anstatt von IDs geladen (Join auf die entsprechende Range-Tabelle).




Igor Grosche, 04.09.2001                                                                   15
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces



                                   DBProperties




       ViewRelationDAO                                  AbstractDAO




                                       ListDAO                           ViewEntityDAO




                                      ViewDAO




       Interface                     Abstrakte Klasse                       Klasse



                    Abbildung 5: Vererbungshierarchie der DAO-Klassen

Die ViewDAO-Klasse stellt Methoden für Anlegen, Ändern, Löschen und Laden von
Ansichtskonfigurationen bereit. Die Ähnlichkeit der Struktur von Ansichtskonfigurationen der
Struktur von Listen wurde in dem Abschnitt "Datenstrukturen" schon erwähnt. Das Laden von
Komponenten aus der Datenbank konnte dementsprechend von der ListDAO übernommen
werden. Die ViewDAO wurde von der ListDAO abgeleitet und erbt die Methoden für das
Laden von Komponenten (siehe Abbildung 5).

Die ViewEntityDAO-Klasse bietet Methoden für Anlegen, Ändern, Löschen und Laden von
ViewEntities in bzw. aus der Datenbank.

Wie schon oben angedeutet, wurde die Behandlung von Relationen aus den Performance-
Gründen in die ViewRelationDAO-Klasse überlagert. Für Relationen ist eine Modell-Klasse
(de.tum.in.croft.view.model.ViewRelationModel) implementiert (siehe Abschnitt
"Datenstrukturen"), die alle zu einer Beziehung gehörenden Informationen kapselt.

Für Ansichtskonfigurationen sind folgende Relationentypen definiert:
• Ansichtskonfiguration - Komponente der Ansichtskonfiguration
    (DBProperties.RangeRelationType.VIEW_COMPONENT_REL)
• Liste - Komponente der Liste
    (DBProperties.RangeRelationType.LIST_COMPONENT_REL)
• Ansichtskonfiguration - Besitzer der Ansichtskonfiguration
    (DBProperties.RangeRelationType.VIEW_OWNER_REL)


Die Konstanten sind in der DBProperties-Klasse (de.tum.in.croft.util.DBProperties)
zusammengefaßt. Der Typ der Relation gibt gleichzeitig den Typ der ersten Komponente
(primary-Teil) in der Beziehung an. Der Typ der zweiten Komponente ist explizit im Attribut
"secondaryType" angegeben. Die IDs der Komponenten sind in "primaryId"- und
"secondaryId"-Attributen abgelegt. Eine Relation kann ein oder mehrere Attribute beinhalten.

Igor Grosche, 04.09.2001                                                                   16
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces


Beispielsweise braucht die Relation "Ansichtskonfiguration - Komponente der
Ansichtskonfiguration" mitzuspeichern, an welcher Position ist diejenige Komponente in der
Ansicht vorhanden. Die Art und die Kardinalität dieser Zusatzinformationen hängt von der
Relation ab. Um trotzdem im Relation-Modell abstrakt zu bleiben, wurde in der
ViewRelationModel-Klasse eine Hashtabelle eingesetzt, in der beliebig viele
Zusatzinformationen aller Art abgelegt werden können.

Die ViewRelationModel-Objekte müssen auf die Datenbanktabellen abgebildet werden. Die
Datenbanktabellen für Relationen unterscheiden sich nur in den Anzahl und der Art von
Zusatzattributen. Deshalb kann man eine der Vorgehensweisen anwenden:
• entweder für jede Relation eine eigene Datenbanktabelle anlegen oder
• eine einzige Tabelle für alle Relationsarten, wobei der Typ und Anzahl der
    Zusatzattribute verallgemeinert werden müssen.

In dieser Version wird die zweite Alternative eingesetzt. Es wird nur eine Datenbanktabelle
für alle Relationen verwendet ("VIEW_RELATION"), die drei Zusatzattributen vom Typ
Integer vorsieht ("ATTRIBUTE_1", "ATTRIBUTE_2" und "ATTRIBUTE_3"). Das Mapping von
relationenabhängigen Zusatzattributen einer Relationen auf diese relationenunabhängigen
Attribute erfolgt über Konstanten der DBProperties-Interface
(DBProperties.ViewOwnerRelTable, DBProperties.ViewComponentRelTable,
DBProperties.ListComponentRelTable). Z.B. ist die Beziehung zwischen einer
Ansichtskonfiguration und einer ihrer Komponenten im ViewRelationModel-Objekt "relation"
gekapselt, und will man die Position dieser Komponente in der Ansicht ermitteln, ruft man

       relation.getAttribute(DBProperties.ViewComponentRelTable.POSITION);

auf. Die Konstante POSITION entspricht der Spalte ATTRIBUTE_1 in der VIEW_RELATION
Tabelle.

Die ViewRelationDAO-Klasse stellt Methoden für Anlegen, Ändern, Löschen und Laden von
Relationsdaten nicht nur von einer Relation, sonder auch für ganze Collections von
Relationen. Beim Laden von Relationen kann man den Spaltenamen angeben, wonach die
Relationen sortiert werden sollen.




Persistence-Schicht

Die Realisierung auf dem Datenbankebene bestand aus dem Entwurf von
Datenbankstrukturen und ihre Umsetzung in die entsprechende Datenbanktabellen.

Die Übersicht aller für Ansichtskonfigurationen angelegten Tabellen ist in der Tabelle 4
dargestellt.

Für die ersten drei in der Tabelle 4 dargestellten Datenbanktabellen sind entsprechende
Sequenzen angelegt, die für die fortlaufende PrimaryKey-Generierung verantwortlich sind.
Außerdem wurden folgende Wertebereichtabellen angelegt:
    • RANGE_ENTITY_TYPE,
    • RANGE_VISIBILITY,
    • RANGE_LIST_TYPE,
    • RANGE_VIEW_ENTITY_TYPE,
    • RANGE_VIEW_COMPONENT_TYPE,
    • RANGE_RELATION_TYPE



Igor Grosche, 04.09.2001                                                                   17
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces



     Tabelle                Spalten                           Type
                    VIEW_ID                    NUMBER (PRIMARY KEY)
                    NAME                       VARCHAR2(50)
                    BGCOLOR                    VARCHAR2(50)
                    BACKGROUND                 VARCHAR2(1024)
     VIEWS
                    ALINK                      VARCHAR2(50)
                    LINK                       VARCHAR2(50)
                    VLINK                      VARCHAR2(50)
                    TEXTCOLOR                  VARCHAR2(50)
                    LIST_ID                    NUMBER (PRIMARY KEY)
                    NAME                       VARCHAR2(50)
                    LIST_TYPE                  NUMBER (REFERENCES
                                                            RANGE_LIST_TYPE (ID))
                    ENTITY_TYPE                NUMBER (REFERENCES
       LIST
                                                         RANGE_ENTITY_TYPE (ID))
                    STATE                      NUMBER
                    COLUMNS                    VARCHAR2(500)
                    LENGTH                     INTEGER
                    ORDER_BY                   VARCHAR2(20)
                    VIEW_ENTITY_ID             NUMBER (PRIMARY KEY)

                    NAME                       VARCHAR2(50)
  VIEW_ENTITY
                    VIEW_ENTITY_TYPE           NUMBER (REFERENCES
                                                    RANGE_VIEW_ENTITY_TYPE (ID))
                    CONTENT                    VARCHAR2(2048)
                    REL_ TYPE                  NUMBER (REFERENCES
                                                       RANGE_RELATION_TYPE (ID))
              PRIMARY_ID                       NUMBER
              SECONDARY_ID                     NUMBER
VIEW_RELATION
              SECONDARY_TYPE                   NUMBER
              ATTRIBUTE_1                      INTEGER
              ATTRIBUTE_2                      INTEGER
              ATTRIBUTE_3                      INTEGER

                 Tabelle 4: Datenbanktabellen für Ansichtskonfigurationen


Alle Tabellen-, Spaltennamen und Einträge in den Wertebereichtabellen sind in der
DBProperties-Interface (de.tum.in.croft.util.DBProperties) zusammengefaßt. Alle Änderungen
in der Datenbankstrukturen müssen dementsprechend im Interface nachgezogen werden.

Für die automatische Generierung und das Entfernen von den Datenbankstrukturen in bzw.
aus einer Oracle-Datenbank wurden SQL-Skripts entwickelt (createView.sql und
dropView.sql im Verzeichnis CROFT_ROOT/dev/sqlscripts/).

Um für alle im System vorhandenen Personen und Projekte Default-Ansichtskonfigurationen
automatisch anzulegen, wurde create_views.jsp und entsprechende Methoden in der
ViewManagerEJB implementiert.




Igor Grosche, 04.09.2001                                                                 18
            Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces


Presentation-Schicht

Die Realisierung auf der Präsentationsebene bezieht sich auf drei Webbeans, die die
Kommunikation mit Business-Logic-Objekten abwickeln sollen, und JavaServer Pages, die
für die eigentliche Darstellung verantwortlich sind. Es wurde dabei die sogenannte
"JavaServer Pages Model 2"-Architektur1 für die auf JSP basierten GUI-Komponenten
verwendet, die eine Trennung von der fachspezifischen Semantik von ihrer Präsentation
nach dem MVC (Model-View-Controller) Design Pattern vorsieht (siehe Abbildung 6). Bei der
Realisierung von Ansichten wurde JSP-Tag-Library Spezifikation2 angewendet, die einer
besseren Modularität der GUI-Gestaltung beigetragen hat.


"JavaServer Pages Model 2"-Architektur

Bei der Implementierung von GUI-Komponenten wurde eine Trennung der fachspizifischen
Semantik von ihrer Darstellung nach den Ansätzen der MVC Design Pattern vorgenommen
(siehe Abbildung 6). Die Behandlung von Benutzereingaben wurde in sog. Action-JSPs
verlagert. Diese JSPs nehmen die Client-Requests an, verarbeiten sie, führen evtl.
Änderungen an Modellen von Ansichtskonfigurationen, Listen oder ViewEntites (in der
Kommunikation mit Webbeans) und übergeben anschließend die Steuerung an View-JSPs,
die Ansichten und Dialoge unter Berücksichtigung der geänderten Modellen darstellen.

Informationen, die innerhalb eines Requests benötigt werden, können von einer JSP zu der
anderen als Attribut des pageContext-Objektes übergeben werden. Informationen, die über
ein Request hinaus gebraucht werden, können in dem session-Objekt abgelegt werden.
Letzter Mechanismus wird z.B. für die Speicherung der aktuellen Ansichtskonfiguration
verwendet. Das Laden einer Konfiguration nimmt erhebliche Zeit in Anspruch. Oft ist es der
Fall, daß, nach dem eine Ansicht geladen wurde, nur geringfügige Änderungen der Ansicht
vorgenommen werden, wie beispielsweise das Einfügen einer Entität in die Sammelmappe,
oder aufklappen einer Liste. Es ist danach nicht nötig, die ganze Ansichtskonfiguration aus
der Datenbank neu zu laden. Man kann sie einfach aus dem session-Objekt übernehmen.




                       Abbildung 6: "JavaServer Pages Model 2"-Architektur
1
    [Seshadri, Model 2 2000]
2
    [Geary 2000] und [Brown 2000]

Igor Grosche, 04.09.2001                                                                  19
            Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces




Webbeans

Für die Kommunikation mit den EJBs wurden drei Webbeans implementiert:
• de.tum.in.croft.view.web.ViewBean - stellt Methoden für Anlegen, Ändern, Löschen und
    Laden von Ansichtskonfigurationen, Einfügen, Positionieren und Entfernen von Ansichts-
    und List-Komponenten, Aktivieren von Ansichtskonfigurationen
• de.tum.in.croft.view.web.ListBean - stellt Methoden für Anlegen, Ändern, Löschen und
    Laden von Listen
• de.tum.in.croft.view.web.ViewEntityBean - stellt Methoden für Anlegen, Ändern, Löschen
    und Laden von Ansichtskomponenten (ViewEntities)

Die Webbeans verwenden die de.tum.in.croft.util.JNDIProperties-Interface, in der JNDI-
Namen von EJBs als Konstanten zusammengefaßt sind.


Ansatz von der JSP-Tag Library Spezifikation

Die JSP Spezifikation 1.11 erlaubt die Definition und die Verwendung von eigenen JSP-Tags.
Diese Tags können dann in eine Library zusammengefaßt und in die JSPs ähnlich wie Java-
Klassen importiert werden.

Für die flexible Gestaltung von Ansichtskonfigurationen wurden JSP-Templates verwendet,
die eine Kapselung des Webseiten-Layouts erlauben und ein modulares Design fördern.

Die Templates-Techniken basieren auf drei neu definierten JSP-Tags:
• <template:insert>
• <template:put>
• <template:get>

Die Templates wurden hauptsächlich für die Aufbau von Homepages und Workspaces
eingesetzt. Alle Ansichten sind nach einem Muster aufgebaut: oben links - ein Bild (Foto der
Person bzw. Logo des Projektes), rechts davon Name und Position der Person bzw. Name
des Projektes mit einer Kurzbeschreibung, darunter - Tabellen mit Entitäten und Listen. Für
diesen Aufbau kann man einen JSP-Template (vgl. view_template.jsp) definieren, der
hauptsächlich aus reinem HTML-Code besteht, und dem mit Hilfe von <template:get>-Tags
dynamische Inhalte eingefügt werden können (siehe Listing 1).

Um das Template verwenden zu können, schreibt man eine JSP (vgl.
person_homepage.jsp), die die Verwendung des Templates durch den <template:insert>-
Tag bekanntgibt und mit <template:put>-Tags die dynamischen Inhalte für den Template
vorgibt (siehe Listing 2). Es können sowohl einfache Strings (wie title im Listing 2) als auch
ganze JSPs (content.jsp oder person_header.jsp im Listing 2) übergeben werden. Beim
Attribut "direct" des <template:put>-Tags, das auf true gesetzt ist, wird der im content
übergebene Text ohne die Verarbeitung von der JSP-Engine in den Template übernommen.




1
    [JSP 1999]

Igor Grosche, 04.09.2001                                                                     20
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces




   <%@taglib uri="./taglibs/template.tld" prefix="template" %>

   <HTML><HEAD>
     <TITLE><template:get name='title' /></TITLE>
   </HEAD>
   <BODY>
   <TABLE width='100%'>
     <TR>
       <TD> <template:get name="header" /> </TD>
     </TR>
     <TR>
       <TD> <template:get name="content" /> </TD>
     </TR>
   </TABLE>
   </BODY>
   </HTML>


                                     Listing 1: Template



   <%@taglib uri="./taglibs/template.tld" prefix="template" %>

   <% String title = "Homepage" %>
   <template:insert template='view_template.jsp'>
          <template:put name='title' content='<%= title %>' direct='true' />
          <template:put name='header' content='person_header.jsp' />
          <template:put name='content' content='content.jsp' />
   </template:insert>



                           Listing 2: Verwendung eines Templates


Damit die JSP-Engine weiß, wie die Tags bearbeitet und ihre Argumente interpretiert werden
sollen, ist für jeden Tag eine Klasse implementiert, die javax.servlet.jsp.tagext.TagSupport-
Klasse erweitert. Solche Klassen für die drei oben vorgestellten Tags sind in dem Package
de.tum.in.croft.view.tag.template implementiert:
    • de.tum.in.croft.view.tag.template.GetTag
    • de.tum.in.croft.view.tag.template.InsertTag
    • de.tum.in.croft.view.tag.template.PutTag

Die de.tum.in.croft.view.tag.bean.PageParameter-Klasse ist eine JavaBean, die für die
Kapselung von Tag-Parametern verwendet wird.

Als letztes muss noch eine tld-Datei erstellt werden. Das ist eine XML-Datei, in der die
Zuordnung von Tags zu den TagSupport-Klassen fixiert wird und Tag-Attribute definiert
werden (siehe Listing 3).




Igor Grosche, 04.09.2001                                                                   21
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces


     <?xml version="1.0" encoding="ISO-8859-1" ?>
     <!DOCTYPE taglib PUBLIC
      "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN"
      "http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd">
     <taglib>
             <tlibversion>1.0</tlibversion>
             <jspversion>1.1</jspversion>
             <shortname>Simple Template System</shortname>
             <tag>
                     <name>insert</name>
                     <tagclass>de.tum.in.croft.view.tag.template.InsertTag</tagclass>
                     <bodycontent>JSP</bodycontent>
                     <attribute>
                             <name>template</name>
                             <required>true</required>
                             <rtexprvalue>true</rtexprvalue>
                     </attribute>
             </tag>
             <tag>
                     <name>put</name>
                     <tagclass>de.tum.in.croft.view.tag.template.PutTag</tagclass>
                     <bodycontent>JSP</bodycontent>
                     <attribute>
                             <name>name</name>
                             <required>true</required>
                             <rtexprvalue>true</rtexprvalue>
                     </attribute>

                      <attribute>
                              <name>content</name>
                              <required>true</required>
                              <rtexprvalue>true</rtexprvalue>
                      </attribute>

                      <attribute>
                              <name>direct</name>
                              <required>false</required>
                              <rtexprvalue>false</rtexprvalue>
                      </attribute>
            </tag>
            <tag>
                      <name>get</name>
                      <tagclass>de.tum.in.croft.view.tag.template.GetTag</tagclass>
                      <bodycontent>JSP</bodycontent>
                      <attribute>
                              <name>name</name>
                              <required>true</required>
                              <rtexprvalue>true</rtexprvalue>
                      </attribute>
             </tag>
     </taglib>


                                       Listing 3: tld-Datei



Igor Grosche, 04.09.2001                                                                22
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces



Neue Entitätstypen in die Ansichtskonfigurationen
aufnehmen
Um ein neues Entitätstyp in den Ansichtskonfigurationen verwenden zu können, müssen
geringfügige Anpassungen auf allen drei Ebenen vorgenommen werden:
• in der Datenbank,
• auf dem Business-Logik-Schicht und
• auf der Präsentationsebene


Datenbank

In der Datenbanktabelle "RANGE_ENTITY_TYPE" muss das neue Entitätstyp eingetragen
werden.


Business-Logik

Alle die das neue Entitätstyp betreffenden Datenbank-Informationen (Tabellen- und
Spaltennamen, Tabellennamen von Relationen, in denen das Entitätstyp steht usw.) sollen
ähnlich wie für die anderen Entitätstypen in der de.tum.in.croft.util.DBProperties-Interface
eingetragen werden.

Der JNDI-Name der zugehörigen EJB muss in die de.tum.in.croft.util.JNDIProperties
eingetragen werden.

EJBs

Falls für das neue Entitätstyp eigene Ansichtskonfigurationen angelegt werden sollen (wie für
Projekte und Personen) müssen die Methoden getOwnerModel(long ownerId, int ownerType)
in der ViewEJB und der ViewManagerEJB für das Laden von Modellen des neuen
Entitätstyps erweitert werden. Die Methoden für das Anlegen von Default-
Ansichtskonfigurationen in der ViewManagerEJB sollen auch für das neue Entitätstyp
angepaßt werden.

DAOs

Die Anpassungen betreffen nur ListDAO- und ViewDAO-Klassen.

Die ViewDAO-Klasse definiert Methoden, die Komponenten für die Default-Konfigurationen
einer Person, eines Projektes und eines Kompetenzzentrums liefern. Falls für das neue
Entitätstyp eigene Ansichtskonfigurationen angelegt werden sollen, muss für es eine
ähnliche Methode eingefügt werden.

Für die ListDAO-Klasse sind die meisten Anpassungen vorzunehmen. Komponenten von
sowohl Systemlisten als auch benutzerdefinierten Listen werden in dieser Version direkt aus
der Datenbank geladen, ohne den RelationManager zu verwenden. Für diese
Vorgehensweise wurde wegen der fehleranfälligen Implementierung des RelationManagers
und Performance-Problemen entschieden.

Die ListDAO-Klasse stellt für das Laden von Listenkomponenten eigene Methoden zur
Verfügung. In den Methoden
• getSystemlistComponents(int entityType, String columns, String orderBy) und

Igor Grosche, 04.09.2001                                                                       23
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces


•   getUserlistComponents(int entityType, Object[] idArray, String columns, String orderBy)

wird es je nach entityType-Parameter zu den spezielleren Methoden
• getPersonListComponents(Object[ ] idArray, String columns, String orderBy)
• getProjectListComponents(Object[ ] idArray, String columns, String orderBy)
• getDocumentListComponents(Object[ ] idArray, String columns, String orderBy)
• getContactListComponents(Object[ ] idArray, String columns, String orderBy) und

•   getPersonSystemlistComponents(String relTableName, String ownerTypeString,
    String columns, String orderBy)
•   getProjectSystemlistComponents(String relTableName, String ownerTypeString, String
    columns, String orderBy)
•   getDocumentSystemlistComponents(String columns, String orderBy)
•   getContactSystemlistComponents(String columns, String orderBy)

verzweigt. Diese Methoden führen einen Select auf entsprechende Datenbanktabellen,
fühlen ein ArrayList-Objekt mit ViewComponentModels und liefern es zurück.

Für ein neues Entitätstyp müssen ähnliche zwei Methoden
• getEntitättypListComponents(Object[ ] idArray, String columns, String orderBy) und
• getEntitätstypSystemlistComponents(....)

implementiert werden und entsprechende Fallunterscheidungen in die
getSystemlistComponents(...) und getUserlistComponents(....) eingebaut werden.


JSPs

Um die Darstellung von neuen Entitätstype in Tabellen von Ansichten zu ermöglichen,
müssen geringfügige Anpassungen in der de.tum.in.croft.util.web.JSPProperties-Klasse,
list.jsp und table_create.jsp vorgenommen werden, und eine JSP für die Repräsentation des
neuen Entitätstyps in Listen und Tabellen implementiert werden.

In der de.tum.in.croft.util.web.JSPProperties-Klasse sollen Konstanten für das neue
Entitätstyp ähnlich wie für bestehende Entitätenstypen definiert werden.

Die Anpassungen in der list.jsp betreffen nur Interaktionsbuttons, die für eine Liste erlaubt
sind. Beispielsweise ist für eine Personen-Systemliste ein "Aus Sammelmappe"-Button
vorhanden, für eine Projekte-Systemliste ist solcher Button dagegen nicht zulässig. Welche
Interaktionsbuttons für Listen des neuen Entitätstyps zulässig sind, muß entsprechend
eingestellt werden.

Um eine Tabelle für Elemente des neuen Entitätstyps anlegen zu können, muss in die
SelectBox "Typ der List-Elementen" eine Option-Feld für das Entitätstyp eingetragen werden.

Um Tabelleneinträge verschiedener Entitätstypen darstellen zu können, werden spezielle
JSPs verwendet:
• document_list_component.jsp
• contact_list_component.jsp
• person_list_component.jsp
• project_list_component.jsp
• viewentity_list_component.jsp

Es wird deshalb eine ähnliche JSP für das neue Entitätstyp benötigt.


Igor Grosche, 04.09.2001                                                                      24
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces



Zusammenfassung
Die Konzeption und Realisierung des Mechanismus für die Verwaltung von
Ansichtskonfigurationen hat sich als eine anspruchsvolle und umfassende Aufgabe
herausgestellt. Alleine die implementierten Java-Klassen bestehen aus über 7700 Lines of
Code. Die Unabhängigkeit von den bestehenden Entitäten konnte nur bedingt realisiert
werden, da auf den existierenden RelationManager verzichtet werden mußte. Ansonsten
erfüllt die realisierte Komponente alle an sie gestellten Anforderungen und bietet mehrere
komfortable Funktionen zur Verfügung.

Der Einsatz von neuen Konzepten bei der GUI-Komponenten vereinfachte und
modularisierte den GUI-Aufbau. Der Einsatz von Templates förderte die stärkere Trennung
zwischen Design- und Logik-Implementierungen. Das gesamte GUI-Implementierung beläuft
sich auf über 5300 Lines of Code.

Das CROFT-System gewann durch die neuen Ansichten an der Benutzerfreundlichkeit und
der Performance. Die Integration von neuen Entitätstypen kann ohne den spürbaren
Aufwand realisiert werden.




Igor Grosche, 04.09.2001                                                                     25
         Erweiterung des CROFT-Systems um konfigurierbare Homepages und Workspaces



Informationsquellen


[J2EE 2001]                         Java 2 Enterprise Edition. Sun Microsystems 2000.
                                    (http://java.sun.com/j2ee)

[EJB 1999]                          Enterprise JavaBeans Specification, Version 1.1.
                                    Sun Microsystems 1999.
                                    (http://java.sun.com/products/ejb)

[JSP 1999]                          JavaServer Pages Specification, Version 1.1;
                                    Sun Microsystems1999. (http://java.sun.com/products/jsp)

[Servlet 1999]                      Java Servlet Specification, Version 2.2.
                                    Sun Microsystems 1999.
                                    (http://java.sun.com/products/servlet)

[WrEntApp 1999]                     Writing Enterprise Application with Java 2 SDK,
                                    Enterprise Edition. Sun Microsystems 1999.

[DeEApp 1999]                       Designing Enterprise Application with Java 2 SDK,
                                    Enterprise Edition. Sun Microsystems 1999.

[Geary 2000]                        David Geary: JSP templates. JavaWorld 2000.
                                    (http://www.javaworld.com)

[Brown 2000]                        Simon Brown: Encapsulate reusable functionality in JSP
                                    tags. JavaWorld 2000. (http://www.javaworld.com)

[Seshadri, Forms 2000]              Govind Seshadri: Advanced form processing using JSP.
                                    JavaWorld 2000. (http://www.javaworld.com)
[Seshadri, Internationalize 2000]   Govind Seshadri: Internationalize JSP-based Websites.
                                    JavaWorld 2000. (http://www.javaworld.com)

[Seshadri, Model 2 2000]            Govind Seshadri: Understanding JavaServer Pages
                                    Model 2 architecture. JavaWorld 2000.
                                    (http://www.javaworld.com)

[McPherson 2000]                    Scott McPherson: JavaServer Pages: A Developer's
                                    Perspective. Sun Microsystems 2000.
                                    (http://developer.java.sun.com)




Igor Grosche, 04.09.2001                                                                 26