WHOIS 2 als komponentenbasiertes, mandantenfähiges

Universität Siegen
Fachbereich Elektrotechnik und Informatik
Fachgruppe Praktische Informatik
WHOIS 2 als
komponentenbasiertes, mandantenfähiges FachbereichsInformationssystem
Tobias Schmidt
Matr.Nr.: 613251
Inhaltsverzeichnis
1Problemstellung........................................................................................................................................1
2Grundlagen .............................................................................................................................................. 1
2.1J2EE..................................................................................................................................................1
2.2JBoss.................................................................................................................................................3
2.3Rechteverwaltung............................................................................................................................. 3
2.3.1Allgemeines.............................................................................................................................. 3
2.3.2diskretionäre Zugriffskontrollen............................................................................................... 4
2.3.2.1Allgemein..........................................................................................................................4
2.3.2.2Subjekte und Objekte........................................................................................................ 4
2.3.2.3Realisierungsmöglichkeit..................................................................................................5
2.3.3rollenbasierte Zugriffskontrollen.............................................................................................. 5
2.3.4attributbasierte Zugriffskontrollen............................................................................................5
3Problemfelder...........................................................................................................................................6
3.1Datenbank.........................................................................................................................................6
3.2Login-Vorgang................................................................................................................................. 7
3.3interdisziplinäre Studiengänge......................................................................................................... 8
3.4Look and Feel................................................................................................................................... 9
4Lösungsmöglichkeiten............................................................................................................................. 9
4.1Ist-Stand von WHOIS2.....................................................................................................................9
4.2Alternative1.................................................................................................................................... 10
4.2.1Rechtevergabe bei WHOIS 1..................................................................................................11
4.2.2Sicherheitsmodell von J2EE .................................................................................................. 12
4.2.2.1deklarative Schutzvereinbarungen.................................................................................. 12
4.2.2.2programmatische Sicherheit............................................................................................12
4.2.2.3JAAS............................................................................................................................... 12
4.2.2.4Web-Security.................................................................................................................. 13
4.2.2.5Festlegung der Rollen..................................................................................................... 14
4.2.2.6Rechtevergabe an Rollen................................................................................................ 15
4.2.2.7Security-Model von WHOIS2.........................................................................................15
4.2.3Rechteverwaltung für WHOIS2..............................................................................................15
4.2.3.1XACML.......................................................................................................................... 16
4.2.3.2JAAS............................................................................................................................... 19
4.2.4Datenbank .............................................................................................................................. 21
4.2.4.1Gebrauch einer zentralen Datenbank............................................................................. 21
4.2.4.2Gebrauch mehrerer separater Datenbanken.................................................................... 22
4.2.5Login-Seiten............................................................................................................................24
4.2.5.1Zentrale Login-Seite........................................................................................................24
4.2.5.2seperate Login-Seiten......................................................................................................24
4.2.6interdisziplinäre Studiengänge ...............................................................................................25
4.2.7Architekturdarstellung............................................................................................................ 26
4.3Alternative 2................................................................................................................................... 27
4.3.1Datenbanken........................................................................................................................... 27
4.3.2Login-Seiten............................................................................................................................27
4.3.3Look-and-Feel.........................................................................................................................28
4.3.4interdisziplinäre Studiengänge................................................................................................28
4.3.5Architekturdarstellung............................................................................................................ 29
5RealisierungsBeispiel............................................................................................................................. 29
5.1Allgemein....................................................................................................................................... 30
5.2Modifikationen am Quellcode........................................................................................................30
5.2.1JNDI-Namen der Beans.......................................................................................................... 30
5.2.2SQL-Queries........................................................................................................................... 31
5.3Modifikationen an den Konfigurationsdateien für das Deployen...................................................31
5.4JBoss Konfigurationsdateien.......................................................................................................... 33
5.5Tool zum automatischen Deployen für WHOIS2.......................................................................... 33
5.6DatenImporte.................................................................................................................................. 35
5.6.1generelle Anforderungen........................................................................................................ 35
5.6.2Sicherheitsanforderungen....................................................................................................... 35
5.6.3Aktualisierung.........................................................................................................................35
5.6.4Auswahl der Daten................................................................................................................. 36
5.6.5Importieren von Lehrveranstaltungen.....................................................................................36
5.6.6Importieren von Belegungen...................................................................................................37
5.6.7Rechte..................................................................................................................................... 38
5.7KomponentenFreischaltung............................................................................................................38
5.8aufgetrene Probleme....................................................................................................................... 39
6Fazit........................................................................................................................................................39
Anhang A: DatenbankSchema WHOIS2.................................................................................................42
Anhang B: Installation des DeployTool...................................................................................................43
1
1Problemstellung
Gegenwärtig wird WHOIS2 als Fachbereichsinformationssystem nur im Fachbereich 12 als Service für
die Studenten angeboten, die damit ihren weiteren Studienverlauf planen können, in dem sie eine
komplette Übersicht über angebotene LehrVeranstaltungen bekommen und diese belegen können.
Mitarbeiter können ihre LehrVeranstaltungen ins System eingeben und ständig aktualisieren. Die
einzelnen Studiengänge lassen sich vollständig modellieren durch Angabe von Studiengangabschnitten,
dazugehörige Pflicht -und Wahlfächer und die damit verbundenen Studienleistungen.
Weitere geplante Funktionen sind unter anderem eine Raumbelegungsplanung und eine
Prüfungsamtkomponente. Geplant ist das System auch für andere Fachbereiche zugänglich zu machen.
Es soll dabei möglich sein
dass ein anderer Fachbereich auch nur einen Teil der gesamten
Funktionalitäten von WHOIS2 benutzen kann. Jedes einzelne System sollte dabei weitgehend autark
sein. Die Anpassung und die Installation des Systems für einen anderen Fachbereich(eventuell auch an
einer anderen Universität) sollte dabei von einem Administrator ohne Kenntnisse des Programm-Codes
über eine Web-Oberfläche vorgenommen werden können.
Für die Lösung dieses Problems bieten sich prinzipiell mehrere Möglichkeiten an. Wichtigster Punkt ist
dabei dass die einzelnen Systeme weitgehend autark bleiben sollen.
2Grundlagen
Zum besseren Verständniss der Problematik wird im folgenden nur ein kurzer Überblick über die
verwendeten Technologien die bei WHOIS2 zum Einsatz kommen gegeben.
2.1J2EE
WHOIS2 wurde mit der Java2 Enterprise Edition als WebApplikation entwickelt, und läuft auf dem
Open-Source WebServer JBoss.
2
Die Java2 Enterprise Edition ist eine Spezifikation verschiedener Technologien die auf der Java2
Standard Edition basieren.Der Einsatz von J2EE ermöglicht es serverseitige, komponentenorientierte,
transaktionale, plattformunabhängige und skalierbare Applikationen zu entwickeln[Arms05].
Die komponentenorientierte Entwicklung wird durch den Einsatz von EnterpriseJavaBeans möglich.
Diese stellen jeweils eine bestimmte Funkion zur Verfügung und bieten die Möglichkeit eines
entfernten Zugriffs. Es gibt drei Arten von EJBs die auch in WHOIS2 benutzt worden sind:
1)Session Beans
Diese Art von Beans bieten dem Client einen Zugriff auf die Geschäftsfunktionen der Applikation.
SessionBeans können stateless und stateful sein. Stateful SessionBeans haben einen persistenten Status
und stellen immer nur einem ganz bestimmten Client Dienste zur Verfügung, während eine stateless
Session Bean von mehreren Clients parallel benutzt werden kann[Arms05].
2)Entity Beans
Entity Beans repräsentieren Daten in einer Datenbank und stellen die Methoden zum Zugriff auf die
Daten bereit. Für jede einzelne Reihe in einer Tabelle einer relationalen Datenbank gibt es eine
EntityBean. Die Zugriffe auf die Datenbank können selbst implementiert werden, oder aber man
benutzt die von J2EE angebotene ContainerManagedPersistence(CMP), welche den Zugriff auf die
Daten steuert[Arms05].
3)Message-Driven Beans
Message-Driven Beans ermöglichen eine asynchrone Nachrichtenverarbeitung. Sie können nicht direkt
aufgerufen werden, sondern werden durch eingehende Nachrichten aktiviert. Diese Art von Beans wird
in WHOIS2 für das Senden von EMails benutzt.
Für WHOIS2 ist insbesondere auch die Mehrbenutzerfähigkeit von J2EE und Enterprise Java Beans
von entscheidender Bedeutung. Diese ist durch die client-server orientierte Architektur auf jeden Fall
gegeben. Jeder der Zugang zu einem Client, wie z.B. einem einfachen Web-Browser besitzt, hat auch
Zugang zu dem mit J2EE entwickelten System.
3
2.2JBoss
JBoss ist ein J2EE-konformer ApplikationsServer, d.h. er stellt alle Dienste zur Verfügung die die
J2EE-Spezifikation für Web-Applikationen vorschreibt.
Damit eine Applikation über den ApplikationsServer erreicht werden kann, reicht es aus, die
entsprechenden Beans zusammen mit verschiedenen Konfigurationsdateien, zusammengefasst in einem
Enterprise Aplication Archive(.EAR) in das „deploy“ Verzeichniss des JBoss zu kopieren. Das Archiv
besteht dabei wiederum aus einem Web Archive(.war) welches Servlets und JavaServerPages enthält,
und einem normalem Java Archiv(.jar) in welchem die BeanKlassen und sonstige Klassen
zusammgefasst sind.
Abbildung 1J2EE Application Packaging
Sobald das Archiv in das deploy-Verzeichniss kopiert wird, wird es vom JBoss deployt und ist
anschließend verfügbar. Nimmt man Veränderungen an den Klassen vor, erstellt ein neues Archiv, und
kopiert es erneut in das deploy-Verzeichniss, so wird dies von JBoss erkannt und das Package wird
redeployt.
2.3Rechteverwaltung
2.3.1Allgemeines
4
In mandantenfähiger Software, also Software die von vielen unterschiedlichen Benutzern verwendet
werden kann, müssen geeignete Zugriffskontrollen realisiert werden, und darauf geachtet werden,
welcher Nutze welche Funktionen aufrufen, und auf welche Dokumente er zugreifen darf.
Zugriffskontrollen sind immer dann notwendig wenn gewisse Bedrohungen wie der Verlust der
Vertraulichkeit, oder der Integrität auftreten können. Im Falle von WHOIS2 soll z.B. nicht jeder
Benutzer sehen können wer welche Vorlesungen besucht, oder gar persönliche Daten eines Studenten
betrachten können. Bei WHOIS2 kommt außerdem hinzu dass einzelne Benutzer abhängig davon
welche Komponenten der Fachbereich einsetzt nur bestimmte Funktionen aufrufen können.
Zu Beginn muss durch eine Login-Prozedur überprüft werden wer das System benutzen will und
welche Rechte dieser Nutzer hat. Ein Administrator sollte die Menge der zugelassenen Benutzer
verwalten und einzelnen Nutzern oder Gruppen von Nutzern bestimmte Rechte erteilen und entziehen
können.
Zugriffskontrollen können prinzipiell in verschiedenen Softwareschichten realisiert werden, also
innerhalb der Applikation, im Datenverwaltungssystem oder im Dateisystem. WHOIS stellt als WebApplikation allerdings bestimmte Funktionen zur Verfügung, weshalb hier nicht nur Rechte auf
irgendwelche Dokumente vergeben werden müssen.
2.3.2diskretionäre Zugriffskontrollen
2.3.2.1Allgemein
Die am meisten auftretenden Zugriffskontrollmechanismen sind diskretionäre Zugriffskontrollen.
Hierbei bedeutet diskretionär dass es dem Besitzer eines Objekts, einer Datei oder eines sonstigen
Datengranulats überlassen wird zu bestimmen welche Benutzer in welcher Weise auf diese Objekte
zugreifen dürfen. Zum Verständniss diskretionärer Zugriffskontrollen sind einige Grundbegriffe
notwendig.
2.3.2.2Subjekte und Objekte
Subjekte sind Inhaber von Rechten. Sie sind eine aktive Instanz in deren Namen Zugriffe durchgeführt
5
werden und deren Zugriffe kontrolliert werden müssen. Subjekte können Benutzer oder
Benutzergruppen, aber auch Programme sein.
Objekte , oder auch Schutzeinheiten, sind passive Instanzen die zu schützende Daten enthalten.Was
genau Schutzeinheiten sind hängt vom Programm ab in dem Zugriffskontrollen realisiert werden sollen.
2.3.2.3Realisierungsmöglichkeit
Die einfachste Form diskretionäre Zugriffskontrollen zu realisieren besteht darin eine sogenannte
Zugriffsmatrix zu erstellen. Hier wird genau aufgelistet welche Subjekte auf welche Objekte zugreifen
dürfen. Bei jedem Zugriff auf eine Schutzeinheit muss diese Matrix ausgewertet werden. Die Matrix
wird normalerweise nur spaltenweise bei den jeweiligen Objekten gespeichert, wodurch jedes Objekt
eine sogenannte Zugriffskontrollliste(Access Controll List, ACL) besitzt. Es kann auch noch zwischen
versch. Modi unterschieden werden. In einem Dateisystem bieten sich z.B. die Modi lesen,schreiben,
ausführen/navigieren über Verzeichnisse an. Dann müssen in der Zugriffsmatrix auch die einzelnen
erlaubten Zugriffsmodi gespeichert werden.
2.3.3rollenbasierte Zugriffskontrollen
Bei rollenabsierten Zugriffskontrollen wird eine Rolle als Mittler zw. Subjekten(also den Nutzern des
Systems) und den Berechtigungen eingefügt. Der Vorteil ist dass Rollendefinitionen über die Zeit
relativ unveränderlich sind, die Benutzermenge sich aber ständig ändert[Prie05]. Rollendefinitionen
und Zuweisung von Subjekten zu Rollen können unabhängig voneinander verändert werden.
2.3.4attributbasierte Zugriffskontrollen
Ein neuerer Ansatz Zugriffskontrollen speziell in Web-Applikationen zu realisieren besteht darin
Berechtigungen abhängig vom Wert bestimmter Attribute zu erteilen. Zugriffsrechte müssen hierbei
nicht statisch definiert werden , sondern werden dynamisch aufgrund bestimmter Attribute oder
Eigenschaften erteilt[Prie05]. Als ideales Einsatzgebiet erweisen sich hier Web-Applikationen bei
denen die Identität des Nutzers nicht im Vordergrund steht und welche von vielen Personen benutzt
werden kann, so dass die Speicherung der Rechte für jede Person zu komplex wäre.
6
3Problemfelder
Im folgenden soll aufgezeigt werden welche Probleme bei der Umstellung von WHOIS2 auf ein für
einzelne Fachbereiche konfigurierbares System auftreten. Generelle Lösungsmöglichkeiten werden
angesprochen und in Kapitel 4 näher erläutert.
3.1Datenbank
Da WHOIS2 bisher nur für den FB12 entwickelt wurde, stellte sich niemals die Frage ob es sinnvoll ist
die Verwendung von mehreren Datenbanken innerhalb einer Applikation zu unterstützen. Soll das
System aber für mehrere Fachbereiche freigeschaltet werden, kann es durchaus sinnvoll sein für jeden
Fachbereich eine eigene Datenbank zu erstellen, um auf Datenhaltungsebene die Autarkie der
Fachbereiche abzubilden.
Die geforderte Autarkie der einzelnen Systeme spricht auf jeden Fall dafür für jeden Fachbereich eine
eigene Datenbank zu benutzen. Alle Daten eines Fachbereichs würden somit separat verwaltet werden
und es gebe keine Vermischungen mit den Daten anderer Fachbereiche. Auch bezüglich der
Perfomance erscheint es vorteilhaft mehrere Datenbanken zu benutzen, als eine einzige Datenbank die
in einem späterem Stadium des Systems vielleicht einmal die Daten von mehr als 20 Fachbereichen
verwalten muss. Alle Anfragen müssten von dieser einen Datenbank verwaltet werden. Die Umstellung
von WHOIS2 auf die Möglichkeit mehrere Datenbanken zu benutzen ist allerdings mit erheblichem
Programmieraufwand verbunden. Bleibt die Applikationslogik für alle Fachbereiche die gleiche, müßte
die Datenbank dynamisch gewählt werden können, abhängig vom jeweiligen Benutzer. Würde für
jeden Fachbereich eine eigene Applikation erstellt werden, müßte man bei der Installation der
Applikation jeweils die richtige Datenbank einsetzen. Der Zugriff auf die Daten könnte in diesem Fall
wie bisher erfolgen.
Bei der Verwendung mehrerer Datenbanken tritt allerdings ein Problem hinsichtlich interdisziplinärer
Studiengänge auf. Vor allem durch diese Studiengänge kommt es zu Überschneidungen zwischen den
Fachbereichen. Fachbereiche sind daher doch nicht so autark wie es auf den ersten Blick erscheinen
könnte. Werden in den einzelnen Datenbanken immer nur die Vorlesungen des eigenen Fachbereiches
gespeichert, so müßte es auf jeden Fall Joints über mehrere Datenbanken geben, wenn auch Studenten
7
interdisziplinärer Studiengänge eine komplette Übersicht über ihr Studium angezeigt bekommen
sollen.Prinzipiell kann auch jeder Student einer Universität Vorlesungen besuchen die nicht von seinem
eigenem Fachbereich angeboten werden.
Denkbar wäre auch eine gemeinsame Datenhaltung für Daten die für verschiedene Fachbereiche gelten
können, wie z.B. Lehrveranstaltungen die für mehrere Studiengänge angeboten werden., und separate
Datenbanken für fachbereichsspezifische Daten.
3.2Login-Vorgang
Wenn man fordert dass die einzelnen Systeme für die Fachbereiche autark sein sollen, spricht alles
dafür auch jeweils eine eigene Login-Seite für einen Fachbereich zu benutzen. Alle Studenten des
Fachbereiches können sich nur hier einloggen, und dann die vom Fachbereich eingesetzten
Funktionalitäten benutzen. Wenn man jedoch auch hier wieder die interdisziplinären Studiengänge
berücksichtigt, so gibt es doch gewisse Probleme die auftreten können. Zum einen stellt sich die Frage
ob ein Student eines interdisziplinären Studienganges nur das System des Fachbereiches nutzen darf, in
dem er offiziell eingeschrieben ist. Dies würde bedeuten dass z.B. ein Wirtschaftsinformatiker
WHOIS2 nicht benutzen kann, wenn der FB5 das System gar nicht einsetzt.
Würde der FB12 WHOIS2 aber einsetzen, u.a. für die Belegungsverwaltung mit deren Hilfe
Raumkapazitäten geplant werden könnten, wäre es auch für Wirtschaftsinformatiker sinnvoll, und für
den FB12 wichtig um einen kompletten Überblick über Belegungen zu haben, diese Funktionalität
benutzen zu können. Dann müßten sich Wirtschaftsinformatiker auch im WHOIS2 des FB 12 einloggen
können, dürften aber dort z.B. nicht die Prüfungsamtkomponente benutzen da sie offiziell im FB5
eingeschrieben sind, und sich dort für Prüfungen anmelden müssen.
Am einfachsten wäre es zu sagen, dass Wirtschaftsinformatiker dann das System eben nicht benutzen
könnten, sondern erst wenn auch der FB5 das System einsetzt. Aber dann wäre auch der Nutzen einiger
Komponenten stark eingeschränkt. Nicht nur der Nutzen der Belegungsverwaltungskomponente wäre
gemindert, auch eine Komponente zur Evaluation von Lehrveranstaltungen würde nicht alle
Vorlesungsteilnehmer erreichen.
8
Für Studenten interdisziplinärer Studiengänge sollte es demnach sinnvollerweise doch möglich sein
eventuell auch die Funktionen anderer Fachbereiche zu benutzen. Bei jeweils separaten Login-Seiten
könnte sich ein Wirtschaftsinformatiker also auch in das System des FB12 einloggen. Ein
Wirtschaftsinformatiker hört aber auch Vorlesungen des FB6(Mathematik). Würde der FB6 das System
einsetzen und mit der Belegungsverwaltungskomponente alle Hörer einer Vorlesungen erreichen
wollen, müßten sich Wirtschaftsinformatiker auch hier einloggen können. Sollte dann irgendwann
einmal auch der FB5 das System einsetzen entsteht wieder ein neues Problem. Soll der
Wirtschaftsinformatikstudent nun alle Funktionen über das FB5-System erreichen können, was
benutzerfreundlicher
wäre,
müßten
eventuelle
Rechte
der
Studenten
in
den
anderen
Fachbereichssystemen neu gesetzt werden.
3.3interdisziplinäre Studiengänge
Aufgrund interdisziplinärer Studiengänge wie z.B. der Wirtschaftsinformatik oder der Mechatronik,
lassen sich Fachbereichsinformationssysteme nicht so autark realisieren wie es auf den ersten Blick
erscheinen mag. In erster Linie verursachen interdisziplinäre Studiengänge einige Probleme bei der
Belegungsverwaltung. Völlige Autarkie der einzelnen Systeme an einer Uni würde bedeuten dass nur
die Lehrveranstaltungen innerhalb des Fachbereiches zur Verfügung stehen würden, wass für einige
Studiengänge nicht ausreichend ist. Die Studenten eines solchen Studienganges könnten keinen
Komplettüberblick über für sie relevante Lehrveranstaltungen bekommen.
Bezüglich der Integrität von Datenbanken würde die Verwendung separater Datenbanken für jeden
Fachbereich ein falsches Bild der Realität wiedergeben, da in der DB des FB5 für die
Wirtschaftsinformatiker nur Vorlesungen aus dem FB5 gespeichert würden. Beim Gebrauch separater
Datenbanken müßte daher ein Teil der Daten von anderen Datenbanken importiert werden können.
Eine andere Frage die bereits angesprochen wurde, ist, in welchem System sich ein Student einloggen
soll. Kann er sich nur in dem System des Fachbereiches einloggen in dem er offiziell eingeschrieben ist,
oder muss er um alle Funktionalitäten benutzen zu können sich auch in anderen Fachbereichssystemen
einloggen können?
9
3.4Look and Feel
Die einzelnen Systemen sollten idealerweise auch visuell voneinander unterscheidbar sein. Hier könnte
es schon reichen das Logo des Fachbereiches anzupassen mit dazugehörigem Text. Eine
Personalisierung der Oberfläche für jeden Benutzer wie es bei WHOIS1 möglich war ist für die
einfache Unterscheidung der Systeme nicht unbedingt erforderlich.
4Lösungsmöglichkeiten
Prinzipiell muss man sich bei der Lösungssuche erst einmal überlegen, ob man nur eine einzige
deployte Applikation benutzen möchte, oder aber für jeden Fachbereich jeweils eine eigene Applikation
deployt. Ausgehend hiervon lassen sich dann Lösungen für oben formulierte Problemfelder finden
Um im folgenden Realisierungsmöglichkeiten für die erweiterte Mandantenfähigkeit von WHOIS2
aufzuzeigen ist es zunächst einmal sinnvoll das jetzige System bezüglich der oben angesprochenen
kritischen Punkte zu betrachten.
4.1Ist-Stand von WHOIS2
Beim jetztigen Stand von WHOIS2 ist nur die Belegungskomponente realisiert worden, und die
Probleme die bei der erweiterten Mandantenfähigkeit auftreten können wurden noch nicht
berücksichtigt. Hauptaugenmerk war eine funktionierende Belegungskomponente. Dabei funktioniert
die Komponente praktisch für alle Fachbereiche und alle Studiengänge. In der Datenbank ist eine
zentrale Tabelle der Fachbereich, über welche
zu Studiengängen, zu Studienleistungen und zu
Lehrveranstaltungen navigiert werden kann. Alles wird in einer Datenbank gespeichert wodurch es zu
keinen Redundanzen kommen kann. Das System ähnelt eher einem Hochschulinformationssystem.
Der Student wählt seinen Studiengang und hat Zugriff auf die entsprechenden Lehrveranstaltungen die
in der Datenbank mit einer Referenz auf seinen Studiengang gespeichert sind. Generell kann sich jeder
10
Student der Uni Siegen mit seinem Uni-Account vom HRZ in das System einloggen und Belegungen
vornehmen. Für die Authentifizerung wird der LDAP-Server des HRZ genutzt.
Probleme mit interdisziplinären Studiengängen treten nicht auf, da alles in einer Datenbank gespeichert
ist und über den Studiengang auf alle relevanten Vorlesungen und sonstige Daten zugegriffen werden
kann.
Studiengänge mit dazugehörigen Pflicht- und Wahlfächern und Studiengangsabschnitten können von
berechtigten Personen(dies wären zur Zeit alle Personen mit Administratorrechten) individuell
modelliert werden. Es wäre ohne weiteres möglich auch Studiengänge des FB5 oder FB6 zu
modellieren.
Die Erstellung von verschiedenen Konfigurationen für einzelne Fachbereiche ist mit dem jetzigen
Stand ohne weiteres nicht möglich, da bei der Entwicklung des Systems die Ausrichtung auf einzelne
Fachbereiche
nicht
berücksichtigt
wurde.
WHOIS2
ähnelt
zur
Zeit
eher
einem
Hochschulinformationssystem, da praktisch alle Studiengänge modelliert werden können und sich alle
Studenten ins System einloggen können. Es gibt aber im Prinzip keine Autarkie der einzelnen
Fachbereiche, und es wäre außerdem nicht ohne weiteres möglich WHOIS2 für jeden Fachbereich
einzeln zu konfigurieren(d.h. vor allem die Freischaltung einzelner Komponenten).
Im Hinblick auf die bereits oben diskutierten Problemfelder gibt es im Prinzip zwei sinnvolle
Alternativen mit denen die erweiterte Mandantenfähigkeit realisiert werden kann.
4.2Alternative1
Es wird nur eine einzige Applikation deployt, die die Fachlogik für alle Systeme enthält. Dies würde
bedeuten dass alle Nutzer auf die gleiche Fachlogik und damit die gleichen EnterpriseBeans zugreifen.
Um dennoch eine gewisse Autarkie der Fachbereiche zu ermöglichen, um damit die komponentenweise
Freischaltung des Systems für einzelne Fachbereiche zu realisieren, wäre hier insbesondere der Einbau
einer komplexen Rechteverwaltung notwendig. Hier bietet sich ein kurzer Rückblick auf den Aufbau
der Rechteverwaltung bei WHOIS1 an.
11
4.2.1Rechtevergabe bei WHOIS 1
Bei WHOIS 1 wurden sogenannte „allgemeine Rechte“ und „spezielle Rechte“ definiert, über die die
Mandantenfähigkeit realisiert wurde. Unter Mandantenfähigkeit wurde hier aber nicht verstanden das
System auch für andere Fachbereiche zu konfigurieren und benutzbar zu machen.
Allgemeine Rechte waren hier Rechte bestimmte Funktionen des Systems zu benutzen, wie z.B. das
Recht eines Professors bzw. Mitarbeiters eines Fachbereiches einen Fragebogen für eigene Vorlesungen
zu erstellen.
Spezielle Rechte sind immer dokumentbezogen,und geben einem Studenten oder auch Mitarbeiter das
Recht an einem Dokument zu arbeiten. Dies kann z.B. ein Fragebogen sein um Lehrveranstaltungen zu
evaluieren, und ein Student kann hier das Recht bekommen den Fragebogen eines Professors einmal
auszufüllen.
Um die Rechtevergabe zu steuern lassen sich Benutzer in Gruppen zusammenfassen, welcher dann ein
spezielles Recht vergeben werden kann. Die Gruppen können von einem Professor/Mitarbeiter gebildet
werden, oder können auch anhand bestimmter Attribute automatisch erstellt werden, z.B. alle Hörer
einer bestimmten Vorlesung.
Folgendes Modell veranschaulicht die Rechtevergabe bei WHOIS 1
Abbildung 2 WHOIS1 Rechteverwaltung
12
4.2.2Sicherheitsmodell von J2EE
J2EE bietet Mechanismen für die deklarative und programmatische Sicherheit von Web-Applikationen.
Diese Standard-Mechanismen werden bei WHOIS2 ebenfalls benutzt.
Deklarative Sicherheit bedeutet dass Zugriffskontrollen nicht direkt im Programm-Code erstellt
werden, sondern in Konfigurationsdateien spezifiziert werden.
Programmatisch bedeutet demnach dass Zugriffskontrollen innerhalb des ProgrammCodes realisiert
werden.
4.2.2.1deklarative Schutzvereinbarungen
Die deklarativen Schutzvereinbarungen werden in den XML-DeploymentDeskriptoren getroffen.J2EE
benutzt hier den Java Authentication and Authorization Service(JAAS) von SUN, welches Funktionen
zur Authentifizierung(Identifikation der Benutzer) und Autorisierung(Zugriffssicherheit) anbietet.
JAAS wird ebenso von JBOSS unterstützt.
4.2.2.2programmatische Sicherheit
Hier erfolgt die Steuerung des Zugriffs im Programcode der Anwendung. Die Klasse
HttpServletRequest stellt dafür die beiden Methoden java.security.Principal getUserPrincipal() und
boolean isUserInRole(String roleName) zur Verfügung. Hiermit ist die benutzerspezifische
Überprüfung von Zugriffsrechten möglich[Korn05].
4.2.2.3JAAS
Der Java Authentication and Authorization Service(JAAS] von Java ist eine API die die Identifikation
von Benutzern und Systemen einerseits, sowie die Vergabe von Zugriffsrechten andererseits unterstützt
[Korn05]. Bezüglich der Rechtevergabe arbeitet JAAS deklarativ.In einer Anwendung muss kein Code
zur Überprüfung von Rechten geschrieben werden. Die Rechtevergabe erfolgt deklarativ in
sogenannten Policy-Dateien, in denen die Rechte spezifiziert werden und zur Laufzeit durch einen
Security-Manager überprüft werden[Korn05]. WebContainer und Container für EJB's die konform zur
13
J2EE-Spezifikation arbeiten, müssen JAAS unterstützen[Korn05]. Bei JBOSS ist dies der Fall.
Zu unterscheiden ist WebSecurity, die den Zugriff auf bestimmte Seiten kontrolliert, und den
SecurityMassnahmen die sich auf bestimmte Funktionen des Systems beziehen
4.2.2.4Web-Security
Zur Vergabe von Zugriffsrechten muss zunächst einmal der Benutzer identifiziert werden, der auf eine
geschützte Ressource Zugriff erhalten möchte.
Die Konfiguration der Web-Security erfolgt im Deployment-Deskriptor der Web-Applikation
(web.xml). Folgende Übersicht zeigt den Aufbau des Deployment Deskriptors.
Abbildung 3 Auszug aus dem Web Application Deployment Deskriptor
Zunächst einmal müssen die Web-Ressourcen die geschützt werden sollen auch dem Container bekannt
gemacht werden. Dies geschieht durch die Angabe von URL-Patterns. Ausserdem muss festgelegt
werden wie sich der zugreifende Benutzer oder das zugreifende System ausweisen muss.Hierzu sind
folgende Möglichkeiten vorgesehen:HTTP Basic Authentication, HTTP Digest Authentication, Form
Based Authentication und HTTPS Client Authentication auf Basis von Zertifikaten[Korn05]. Detailiert
kann das Zugriffsverfahren im Element login-config beschrieben und konfiguriert werden. In WHOIS2
ist dies folgendermaßen konfiguriert:
14
<login-config>
<auth-method>FORM</auth-method>
<realm-name>whois_security</realm-name>
<form-login-config>
<form-login-page>/secure/login.jsp</form-login-page>
<form-error-page>/Error.jsp</form-error-page>
</form-login-config>
</login-config>
Die Abfrage von Benutzerinformationen ist formbasiert und erfolgt auf der JSP login.jsp. Bei
fehlgeschlagenem Login wird automatisch zu Seite Error.jsp weitergeleitet.
Als realm-name ist hier whois_security eingetragen. Dies bezieht sich auf die in der Datei loginconfig.xml des JBOSS Containers definierten Sicherheitspolice. Nach dieser Grundkonfiguration, die
die Authentisierung des Benutzers kontrolliert, muss festgelegt werden wer auf die geschützen WebRessourcen Zugriff haben soll. Eine Realisierungsmöglichkeit ist hier die deklarative Sicherheit.
Hierbei muss der Quellcode nicht verändert werden, jegliche Kontrollfunktionen werden im
Deployment-Deskriptor festgelegt. Es kann für jede Web-Ressource-Collection festgelegt werden,
welche Rollen das Recht haben auf diese Ressource zuzugreifen.Diese Festlegung ist bei WHOIS2 in
der Struts Konfigurationdatei struts-config.xml realisiert. Jeder Funktionsaufruf wird weitergegeben an
eine Struts-Action Klasse, welche die zugewiesene Rolle überprüft.
<action
>
path="/StudentBearbeitenSGWaehlenAction"
type="de.whois.univerwaltung.struts.action.StudentBearbeitenSGWaehlenAction"
name="StudentBearbeitenSGWaehlen"
scope="session"
roles="Admin"
unknown="false"
validate="false"
4.2.2.5Festlegung der Rollen
Die Rollen werden ebenfalls im Deployment-Deskriptor der Web-Applikation(web.xml) festgelegt,
bzw. im Deployment-Deskriptor der EJBs. Die Deklaration erfolgt durch das security-role Tag:
<security-role>
<description>...</description>
<role-name>...</role-name>
</security-role>
15
4.2.2.6Rechtevergabe an Rollen
Bei der deklarativen Sicherheit ist die Rechtevergabe an Rollen auch die einzige Möglichkeit
Funktionszugriffe zu beschränken. Rechte für einzelne Benutzerkennungen können nicht vergeben
werden[Korn05].Die Vergabe von Rechten kann immer nur mit vordefinierten Rollen verknüpft
werden. Da bei der erweiterten Mandantenfähigkeit für WHOIS2 Rechte variabel zur Laufzeit vergeben
werden sollen, ist die deklarative Sicherheit nicht ausreichend.
4.2.2.7Security-Model von WHOIS2
WHOIS2 nutzt hauptsächlich das von J2EE und JBOSS vorgegebene deklarative SicherheitsModel.
Damit ist es möglich den Zugang zu einzelnen URLs zu verwalten, in dem jeweils für verschiedene
URLs definiert wird welche „Rollen“ auf sie zugreifen dürfen. Diese Rollen werden zunächst einmal
nur als logische Rollen definiert und später zur Deploy-Zeit erst mit richtigen Rollen verbunden.
Genauer gesagt werden „SecurityConstraint“ Elemente in der Datei „Web.xml“ definiert in denen
genauer spezifiziert wird welche Rollen auf welche URLs zugreifen dürfen. Will ein Nutzer nun auf
diese URL zugreifen und besitzt noch keine Rolle, so wird er auf die Login-Seite umgeleitet, und kann
bei erfolgreichem Login Zugang zu den geschützten Seiten erhalten.
Auch WHOIS1 wurde nicht mit dem Gedanken einer Fachbereichskonfigurierung entwickelt, besitzt
aber ein relativ umfangreiches Rechtevergabesystem, das für die neuen Bedürfnisse bei WHOIS1 zum
Teil wiederverwendet werden könnte. Als Technologie setzt WHOIS1 dabei auf XACML, welches ein
XML-Schema vorgibt wie eine adäquate Rechteverwaltung verwirklicht werden kann.
4.2.3Rechteverwaltung für WHOIS2
Wie bereits erwähnt erfordert die erweiterte Mandantenfähigkeit bei WHOIS2 eine umfangreichere
Rechtevergabe, die durch die von J2EE und dem JBOSS-Server angebotene deklarative Sicherheit
16
nicht realisiert werden kann. Hierfür bieten sich in erster Linie zwei Möglichkeiten an. Der Gebrauch
von XACML, welches bereits bei WHOIS1 schon benutzt wurde, oder die erweiterten
Sicherheitsfunktionen von JAAS.
4.2.3.1XACML
Die eXtensible Access Control Markup Language (XACML) ist eine Sprache zur Realisierung von
Zugriffskontrollen. Sie definiert eine Syntax in XML mit deren Hilfe Zugriffskontrollen organisiert
werden können. Hierzu werden policies erstellt welche Zugriffsrechte festlegen, die später abgefragt
werden können. Für Java gibt es von SUN eine eigene API mit deren Hilfe eine Zugriffskontrolle
mittels XACML realisiert werden kann[Sun05]. Schlüsselbegriffe innerhalb der XACML sind die
Begriffe „Action“ und „Ressource“.Innerhalb einer Applikation ist das normale Vorgehen eines Users
eine bestimmte Aktion auf einer bestimmten Ressource auszuüben. Eine Ressource kann dabei eine
Datei, ein spezieller Dienst oder eine Systemkomponente sein[Mose05].
Es wird ein Request ausgeführt welcher an ein Dateisystem oder eben auch an einen Web-Server
weitergeleitet wird. Dieser wird hier Policy Enforcement Point(PEP) genannt.Der PEP kann den
Request weiter modifizieren und schickt ihn anschließend an einen Policy Decision Point(PDP),
welcher für den Request die passende policy sucht und bestimmt ob der Zugang erlaubt oder verwehrt
werden soll. Diese Antwort wird zurückgeschickt an den PEP welcher endgültig entscheidet wie mit
der Anfrage verfahren werden soll. PEP und PDP können dabei innerhalb einer Applikation oder auch
verteilt auf mehreren Servern liegen.
Ein Request besteht dabei aus den folgenden vier Attributen anhand dessen entschieden wird was mit
der Anfrage geschieht: Subject, Resource, Action und Environment(optional).
Subject beschreibt den Client der den Request initiiert hat, und auf eine bestimmte Resource mit einer
bestimmten Aktion(read,write) zugreifen möchte. Bei dem Zugriff auf bestimmte Web-Pages macht nur
die read-Aktion Sinn.
Ein weiterer wichtiger Begriff innerhalb der XACML ist der des Targets. Ein Target ist eine Menge
von Bedingungen für das Subject, die Ressource und die Action die erfüllt sein müssen damit eine
bestimmte policy eine Antwort auf ein Request geben kann.
17
Beispiel für ein Request, eine Policy und ein Response:
The Request:
<Request>
<Subject>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
DataType="urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name">
<AttributeValue>[email protected]</AttributeValue>
</Attribute>
<Attribute AttributeId="group"
DataType="http://www.w3.org/2001/XMLSchema#string"
Issuer="[email protected]">
<AttributeValue>developers</AttributeValue>
</Attribute>
</Subject>
<Resource>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#anyURI">
<AttributeValue>http://server.example.com/code/docs/developer-guide.html</AttributeValue>
</Attribute>
</Resource>
<Action>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
DataType="http://www.w3.org/2001/XMLSchema#string">
<AttributeValue>read</AttributeValue>
</Attribute>
</Action>
</Request>
The Policy:
<Policy PolicyId="ExamplePolicy"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:permit-overrides">
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<Resource>
<ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">
18
<AttributeValue
DataType ="http://www.w3.org/2001/XMLSchema#anyURI">
http://server.example.com/code/docs/developer- guide.html</AttributeValue>
<ResourceAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#anyURI"
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"/>
</ResourceMatch>
</Resource>
</Resources>
<Actions>
<AnyAction/>
</Actions>
</Target>
<Rule RuleId="ReadRule" Effect="Permit">
<Target>
<Subjects>
<AnySubject/>
</Subjects>
<Resources>
<AnyResource/>
</Resources>
<Actions>
<Action>
<ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
<ActionAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string"
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"/>
</ActionMatch>
</Action>
</Actions>
</Target>
<Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">
<SubjectAttributeDesignator DataType="http://www.w3.org/2001/XMLSchema#string"
AttributeId="group"/>
</Apply>
<AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">developers</AttributeValue>
</Condition>
</Rule>
</Policy>
19
The Response:
<Response>
<Result>
<Decision>Permit</Decision>
<Status>
<StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
</Status>
</Result>
</Response>
WHOIS1 benutzte ebefalls XACML zur Realisierung von Zugriffskontrollstrukturen. Hierbei wurde für
jede Systemkomponente eine eigene Policy geschrieben in der die benötigten Informationen über die
Rechtevergabe enthalten waren. Zur Speicherung der policies wurde hier eine Xindice Datenbank
benutzt. Xindice ist speziell für die Speicherung von XML-Daten entwickelt worden, wäre also für die
Speicherung der in XML geschriebenen policies von Vorteil.
4.2.3.2JAAS
Auch mit JAAS lassen sich die benötigten Kontrollstrukturen realisieren. [Moor05] beschreibt dabei
einen Weg wie sich mit JAAS auch komplexere Authorisierungsvorgänge realisieren lassen. Hierbei
spielen folgende Objekte eine Rolle[Moor05].
User:Eine Entität in der realen Welt, kann ein Mensch oder ein anderer Computer sein.
Subject: der User wie er von der Web-Applikation gesehen wird. Hierfür existiert eine eigene Klasse
„SUBJECT“.
Principal: Eine View des Subjects; wird durch die Klasse Principal realisiert.
Ressource:ein Objekt innerhalb eines Systems, kann eine Datei oder auch eine Web-Page sein.
20
Permission:Die Klasse Permission besteht aus den Attributen Ressource,Action und Name, und
können einem Principal erteilt werden.
Um mit JAAS eine Rechteverwaltung bei Web-Applikationen zu ermöglichen, müßte die Klasse
Permission erweitert werden, da sie standardmäßig keine URLs interpretiert. Eine Action müßte bei
einer Anfrage nicht mit angegeben werden da diese immer „read“ ist[Moor05].
Eine policy von JAAS hat den folgenden Aufbau
grant Principal * * {
permission com.xor.auth.perm.URLPermission \
"/struts-example/logoff.do";
};
grant Principal com.tagish.auth.TypedPrincipal "user" {
permission com.xor.auth.perm.URLPermission \
"/struts-example/editRegistration.do";
};
grant Principal com.tagish.auth.TypedPrincipal "admin" {
permission com.xor.auth.perm.URLPermission \
"/struts-example/editRegistration.do";
permission com.xor.auth.perm.URLPermission \
"/struts-example/adminMenu.do";
};
Diese Datei-orientierte Erstellung einer policy kann auch mit Hilfe von relationalen Datenbanktabellen
realisiert werden[Moor].
JAAS kann sehr sinnvoll in Verbindung mit dem Struts Application Framework eingesetzt werden
[Moor]. In einer Model-View-Controller Architektur, welche bei WHOIS2 ebenfalls durch den Einsatz
von Struts realisert wird, wird die Zugriffskontrolle im Controller realisiert. Bei Struts ist dies jeweils
das ActionServlet. Eine Zugriffsüberprüfung könnte dabei den folgenden Aufbau haben:
Permission p = new FilePermission("/Belegungen","read");
SecurityManager s = System.getSecurityManager();
21
if ( s != null) s.checkPermission(p);
Moor schlägt vor sowohl ein zentrales Servlet zu benutzen welches überprüft ob eine bestimmte URL
von dem User aufgerufen werden darf, als auch ein JSP Tag oder eine Methode die überprüft welcher
Inhalt auf einer WebSeite gesehen werden darf[Moor05]. Somit wäre es auch möglich Benutzern
unterschiedlicher Fachbereiche nur die für sie benutzbaren Menüpunkte, durch welche die Funktionen
einzelner Komponenten erreichbar sind, anzuzeigen.
Die eigentliche Sicherheitsüberprüfung sollte von einer eigenen Business-Klasse übernommen werden
[Moor05].
Die große Schwierigkeit bei einer Rechteverwaltung für WHOIS2 besteht darin, dass nicht nur der
Zugriff
einzelner Rollen oder Benutzer geregelt werden muss, sondern gleichzeitig auch immer
beachtet werden muss welches FachbereichsSystem gerade benutzt wird.
4.2.4Datenbank
Die Frage ist ob jeder Fachbereich eine eigene Datenbank erhalten sollte, oder ob alle Fachbereich auf
eine gemeinsame Datenbank zugreifen.Man könnte meinen eine gemeinsame Datenbank für alle
Fachbereiche wäre sinnvoller aufgrund der Tatsache das Lehrveranstaltungen auch für andere
Fachbereiche angeboten werden.
Hier würden aber wieder erhöhte Anforderungen an die
Rechteverwaltung gestellt um die Systeme autark zu realisieren.
4.2.4.1Gebrauch einer zentralen Datenbank
Bei Gebrauch nur einer zentralen Datenbank kann das DatenbankSchema prinzipiell beibehalten
werden. Es muss allerdings darauf geachtet werden dass es aus Benutzersicht zu keinerlei
Überschneidungen kommen kann. Daten aus einem Fachbereich dürfen auch nur in dessen System
benutzt werden, und es muss v.a. darauf geachtet werden, dass Mitarbeiter aus einem bestimmten
Fachbereich keine Lehrveranstaltungen eines anderen Fachbereiches verändern darf. Dies müßte hier
mit einer adäquaten Rechteverwaltung gelöst werden. Innerhalb der Datenbank müßte erkennbar sein
welchem Fachbereich die Daten gehören, dies kann durch ein zusätzliches Tabellenfeld das das Kuerzel
des Fachbereiches enthält erfolgen.
22
4.2.4.2Gebrauch mehrerer separater Datenbanken
Die Idee für jeden Fachbereich eine eigene Datenbank einzurichten erscheint unter dem Gesichtspunkt
der
Autarkie
sinnvoll,
birgt
jedoch
einige
programmiertechnische
und
organisatorische
Schwierigkeiten.
Wird für jeden Fachbereich eine eigenständig laufende Applikation deployt, kann dieses System an die
Datenbank des Fachbereiches angepasst werden, ohne größere Änderungen am ProgrammCode
vornehmen zu müssen.
Bei Verwendung nur einer einzigen deployten Applikation auf die alle Benutzer zugreifen , müßte die
z.Zt. verwendete ContainerManagedPersistence durch BeanManagedPersistence ersetzt werden, da die
Datenbank nun variabel angepasst werden muss. Um eine bessere Organisation des Datenbankzugriffes
zu erhalten, sollte in diesem Fall mit einem DataAccessObject(DAO) gearbeitet werden, welches die
ProgrammierDetails des Datenbankzugriffes kapselt[Deep01]. Ein DAO würde auch später eventuell
einmal auftretende Anpassungen an den Datenbankzugriff erleichtern.
Das von Sun entworfene DAO Pattern wird in folgendem Klassendiagramm verdeutlicht.
Abbildung 4 Klassendiagramm für DAO Muster
Erklärung der einzelnen Klassen:
BusinessObject: stellt hier den DatenClient dar, und ist das Objekt welches Zugriff auf die
Datenquelle fordert. Es kann sowohl eine SessionBean als auch eine EntityBean oder ein anderes JavaObjekt sein.
DataAccessObject: abstrahiert die Implementierung des Zugriffes auf die Datenbank welche vom
BusinessObject ausgeht. Auch Methoden zum Laden und Speichern/Aktualisieren von Datenbeständen
23
werden vom DAO übernommen.
DataSource: repräsentiert die Datenquellenimplementierung. Dies muss nicht unbedingt ein RDBMS
sein, sondern kann auch ein XML-Repository oder LDAP-Repository sein.
ValueObject: Dieses Objekt dient als Datenträger, und kann dazu verwendet werden angefragte Daten
an den Client zurückzugeben, bzw. Daten vom Client an die Datenbank zu schicken um diese zu
aktualisieren.
Beim Zugriff auf eine Datenbank muss bekannt sein zu welchem Fachbereich der jeweilige Nutzer
gehört. Hierzu muss für jeden Nutzer der sich in das System eines Fachbereiches einloggt eine eigene
Session erstellt werden.
Kompliziert wird diese Lösung wenn man die interdisziplinären Studiengänge betrachtet. Möchte ein
Wirtschaftsinformatiker einen Überblick über alle Vorlesungen die er in einem Semester belegen kann
haben, so muss bei beizubehaltender Autarkie unter Umständen auf mehrere Datenbanken zugegriffen
werden, oder die Daten müssen mehrfach in allen relevanten Datenbanken gespeichert werden.
Eine Möglichkeit dies Problem zu lösen, wäre eine Angabe bei der Anlage einer Studienleistung von
welchem Fachbereich hierzu eine Lehrveranstaltung angeboten wird. Bei der Auflistung der
Lehrveranstaltungen könnte dann in der entsprechenden Datenbank nach einer Lehrveranstaltung
gesucht werden. Hierbei müsste es universitätsweit eindeutige Primärschlüssel für die Speicherung von
Lehrveranstaltungen geben, damit die entsprechende Veranstaltung gefunden werden kann. Dies gilt
unter der Annahme das zu der gesuchten Lehrveranstaltung auch eine entsprechende Studienleistung in
dem jeweiligen Fachbereich angelegt wurde, so dass man über die Studienleistung, die einen bekannten
Primärschlüssel haben muss, zu den dafür angebotenen Lehrveranstaltungen gelangt.
Außerdem sollte die Lehrveranstaltung die von einem anderen Fachbereich angeboten wird
entsprechend gekennzeichnet sein, also vorzugsweise mit dem Kürzel des Fachbereiches.
Änderungen an einer Lehrveranstaltung eines anderen Fachbereiches dürfen nicht erlaubt sein, was bei
einem Versuch mit einer Fehlermeldung angezeigt werden sollte.
Ein Zugriff auf die Daten anderer Fachbereiche wird auch bei den Belegungen von Studenten für
24
Lehrveranstaltungen notwendig. Belegt ein Student eine Lehrveranstaltung eines anderen Fachbereiches
so muss entweder ein Verweis in der Tabelle Belegungen auf die Veranstaltung in der Datenbank des
anderen Fachbereiches erstellt werden, oder aber die Belegung muss in dem Fachbereich gespeichert
werden welcher die Veranstaltung anbietet. Sollen keine Daten redundant gespeichet werden kommt es
somit zu Verweisen zwischen Daten verschiedener Fachbereichsdatenbanken. Ein Fremdschlüssel in
einer Tabelle Belegungen auf eine Lehrveranstaltung die in einer anderen Datenbank gespeichert ist, ist
aber nicht möglich. Natürlich könnte trotzdem der Primärschlüssel der Lehrveranstaltung gespeichert
werden, dies wäre dann aber nicht gleichzeitig ein Fremdschlüssel der auf Daten in einer anderen
Tabelle verweist.
4.2.5Login-Seiten
4.2.5.1Zentrale Login-Seite
Eine zentrale Login-Seite(für die Fachbereiche innerhalb einer Universität) wäre programmiertechnisch
und auch bezüglich der Benutzerfreundlichkeit vorteilhaft. Alle Nutzer würden mit Angaben zu ihrem
Studiengang in der Datenbank gespeichert. Beim Login müsste ein Nutzer dann zw. seinen
angegebenen Studiengängen wählen, um die entsprechenden Funktionen die für seinen Studiengang
existieren benutzen zu können.
Ein administratives Problem was dabei auftaucht, ist die der tatsächlich benutzbaren Funktionen. Wie
bereits erwähnt ist es sinnvoll das ein Wirtschaftsinformatiker die Belegungskomponente des FB12
nutzen kann, auch wenn der FB5 das System gar nicht benutzt. Bei einer zentralen Login-Seite müßte
in einer gemeinsamen Datenbank im Prinzip für jeden Studiengang gespeichert sein zu welchem
Fachbereichssystem der Nutzer Zugang hat. Solange der FB5 keine Belegungsverwaltung einsetzt
sollten Wirtschaftsinformatiker eventuell Zugang zur Belegungsverwaltung des FB12 erhalten, aber
nicht auf eine eventuell vorhande Prüfungsamtkomponente des FB12. Eine zentrale Login-Seite bei
dennoch starker Autarkie der einzelnen Systeme erscheint zwar durchaus realisierbar, erschwert aber
die Programmierung des Login-Vorganges.
4.2.5.2seperate Login-Seiten
25
Jeweils eine separate Login-Seite für jeden Fachbereich an einer Universität bei nur einer einzigen
deployten Applikation verursacht einige programmiertechnische Hürden. Es ist nicht ohne weiteres
möglich mit J2EE und dem von WHOIS2 z.Zt benutzten JBOSS-Container, mehrere Login-Seiten für
eine deployte Web-Applikation zu erstellen. Jede Web-Applikation läuft innerhalb eines bestimmten
Contexts, welcher in einer Konfigurationsdatei für den JBoss angegeben wird. Ausgehend von einer
„context-root URL“ kann eine Login-Seite angegeben werden,die vom JBoss automatisch aufgerufen
wird wenn ein noch nicht authentifizierter Benutzer eine geschützte Web-Seite aufruft.
Um mehrere Login-Seiten benutzen zu können und weiterhin die Funktionen des JBoss benutzen zu
können die den Authentifizierungsvorgang realisieren, müßte WHOIS2 mehrfach deployt werden,
jeweils mit einer anderen StartSeite, worauf im nächsten Kapitel(Alternative 2) näher eingegangen
wird.
Um die Systeme visuell untescheiden zu können ist es unabdingbar verschiedene Login-Pages zu
erstellen und auch die restliche graphische Oberfläche an einen eigenen Stil anzupassen.
4.2.6interdisziplinäre Studiengänge
Bei einer einzigen deployten Applikation für alle Fachbereiche würde sich bei interdisziplinären
Studiengängen insbesondere das Problem ergeben bei welchem Fachbereich sich ein Student einloggen
sollte. Würden alle Fachbereiche einer Universität das System benutzen könnte man festsetzen dass
sich jeder Student nur in dem Fachbereich einloggen kann, in dem er offiziell eingeschrieben ist. Damit
der Student auch dann ein vollständiges Bild seiner Studiensituation bekommen kann, wäre der
Fachbereich dafür verantwortlich die Studiengänge entsprechend zu modellieren und eventuell
Lehrveranstaltungen aus anderen Fachereichen in die eigene Datenbank zu importieren, falls mehrere
Datenbanken benutzt würden. Wird nur eine Datenbank benutzt, auf die alle Fachbereiche zugreifen
können, so müßte vereinbart werden, dass jeder Fachbereich nur seine eigenen Studiengänge modelliert
damit es dort zu keinerlei Überschneidungen kommen kann. Insbesondere würden benötigte
Studienleistungen von dem Fachbereich selber erstellt und in der Datenbank hinterlegt.
Komplizierter wird der Sachverhalt wenn man bedenkt dass nicht alle Fachbereiche das System
benutzen würden. Wird das System z.B. nur vom FB 12 eingesetzt, und beschließt man dass sich z.B.
Wirtschaftsinformatiker dort nicht einloggen könnten, so würde der FB 12 ein falsches Bild von den
26
Belegungen ihrer Lehrveranstaltung bekommen,da ein großer Teil der potentiellen Teilnehmer von
Lehrveranstaltungen keine Belegungen vornehmen kann. Also wäre es besser jedem Fachbereich selbst
zu überlassen wer sich einloggen darf, und welche Studiengänge modelliert werden sollen. Dies alles
würde aber zu Komplikationen führen wenn nur eine zentrale Datenbank benutzt werden würde, die
Fachbereiche aber autark bleiben sollen. Entweder müßten dann Abstriche bei der Autarkie gemacht
werden, was allerdings zu einem System führen würde, dass mehr einem Hochschulinformationssystem
gleicht, oder man verwendet doch mehrere Datenbanken. Studenten könnte es dann erlaubt sein sich in
mehreren Systemen einzuloggen, und den Fachbereichen bleibt selbst überlassen welchen Studenten sie
ihre Dienste zur Verfügung stellen wollen.
4.2.7Architekturdarstellung
Abbildung 5eine Applikation - mehrere Datenbanken
27
4.3Alternative 2
Die zweite Alternative wäre es die Applikation mehrmals in den Web-Server(hier also den JBoss) zu
deployen,angepasst an den jeweiligen Fachbereich. Dies würde es erleichtern die geforderte Autarkie
der einzelnen Fachbereiche zu beachten, und insbesondere den Gebrauch mehrerer Datenbanken. Im
folgenden wird hierbei erneut näher auf die oben genannten Problemfelder eingegangen. Viele der
Probleme die hierbei auftreten, treten auch bei Alternative 1 auf, und wurden dort teilweise schon näher
erläutert.
4.3.1Datenbanken
Besitzt jeder Fachbereich seine eigene Applikationsinstanz auf dem Web-Server, und damit eine eigene
FachLogik für das System jedes Fachbereiches, so bietet es sich hier an für jeden Fachbereich auch eine
eigene Datenbank zu benutzen. Der Gebrauch einer einzigen Datenbank ist aus den gleichen Gründen
wie bei der ersten Alternative unter dem Gesichtspunkt der Autarkie nicht sinnvoll. Der Zugriff auf die
Datenbank bräuchte bei einer separaten Applikation nicht über ein DataAccessObject erfolgen, der
Zugriff auf die Datenbank würde erheblich erleicht werden, da eben immer nur auf eine Datenbank
zugegriffen werden muss. Wie ebenfalls bereits erwähnt, erfordert der Gebrauch jeweils separater
Datenbanken einen eventuellen Datenimport aus anderen Fachbereichen. Auf diese Problematik wird
unter dem Punkt „interdisziplinäre Studiengänge“ eingegangen.
4.3.2Login-Seiten
Bezüglich des Login-Vorganges ist es bei mehreren deployten Applikationen einfach, und unter dem
Gesichtspunkt der Autarkie sinnvoll, jeweils eigene Login-Seiten zu erstellen über die sich die Nutzer
einloggen können. Es müßte dann noch entschieden werden ob der Fachbereich seine Nutzer auf der
eigenen Datenbank verwalten möchte und somit selbst entscheiden könnte wer generellen Zugang zum
System hat, oder ob das selbe Login wie für den Zugang zum Studenten-Account des
Hochschulrechenzentrums genutzt werden soll. Beides wäre auf jeden Fall möglich, da für jeden
Fachbereich das System entsprechend modifiziert werden kann.
28
4.3.3Look-and-Feel
Bei mehreren deployten Applikation würde auch die Möglichkeit bestehen die einzelnen Systeme
optisch an die Fachbereiche anzupassen. Logos und andere Grafiken der Fachbereiche könnten in
einem speziellen Ordner gespeichert werden der mit der Applikation zusammen in den Web-Server
deployt wird. StyleSheets mit Formatierungsangaben können ebenfalls zusammen mit den
JavaServerPages in einer separaten StyleSheet-Datei gespeichert werden, und an die Fachbereiche
angepasst werden.
4.3.4interdisziplinäre Studiengänge
Eine bereits kurz angesprochene Lösung für die Problematik interdisziplinärer Studiengänge ist es ,
jedem Fachbereich selbst zu überlassen welche Studiengänge er modelliert. Der FB12 könnte also, um
mit seinem Belegungssystem alle Studenten zu erreichen, den Studiengang Wirtschaftsinformatik selbst
modellieren und diesen Studenten einen Zugang einrichten. Bei Verwendung separater Datenbanken
führt dies zu keinerlei Problemen. Wirtschaftsinformatiker müssten sich dann damit zufrieden geben,
dass sie nur einen Überblick über die Lehrveranstaltungen des FB12 bekommen. Irgendwann könnte
der FB5 WHOIS2 und die Belegungskomponente doch noch benutzen, und würde dann natürlich
ebenfalls den Studiengang Wirtschaftsinformatik modellieren. Der FB12 müßte dann selbst entscheiden
ob er seinen Service für Wirtschaftsinformatiker weiterhin anbieten möchte oder nicht.
Der FB5 hätte in dieser Situation das Problem nicht alle Daten über relevante Lehrveranstaltungen zu
den selbst erstellen Studienleistungen für Wirtschaftsinformatiker gespeichert zu haben, und wäre auf
einen Datenimport von Lehrveranstaltungen angewiesen.
Der FB12 hätte nun das Problem, nicht alle Studenten die Belegungen für ihre Lehrveranstaltungen
vorgenommen haben, in ihrer Datenbank gespeichert zu haben, und wäre ebenfalls auf einen
Datenimport angewiesen.
Es würden also bei dieser Alternative(mehrere Applikation und mehrere Datenbanken, Autarkie der
Fachbereiche),
zwei
Arten
von
Datenimporten
notwendig.
Zum
einen
der
Import
von
Lehrveranstaltungsdaten und alle damit zusammenhängen Einträge in der Datenbank wie
29
Mitarbeiter,Fachgruppe und Fachbereich, und zum anderen der Import von StudentenDaten und
Belegungen für Lehrveranstaltungen. Wie man dies genauer realisieren könnte wird in Kapitel 5 in der
Beschreibung eines DatenImport-Tools für Fachbereichsinformationssysteme beschrieben.
Ein Problem was weiterhin bei interdisziplinären Studiengängen bestehen würde, wäre die
Rechteverwaltung auch für einzelne Studiengänge im System. Wirtschaftinformatiker sollten zwar
eventuell die Belegungsverwaltungskomponente des FB12 benutzen können, aber nicht deren eventuell
vorhandene Prüfungsamtkomponente. Hier könnte es aber ausreichend sein lediglich eine zusätzliche
Rolle wie „GastStudent“ o.ä. einzurichten, welche dann nur Zugriff auf die Belegungsverwaltung hat.
Andere Möglichkeit wäre hier eine attributbasierte Zugriffskontrolle, wobei das Attribut Studiengang
im Prinzip alle Rechte vorgeben könnte. Ein Nutzer der Wirtschaftsinformatik studiert, hätte dann nur
Zugriff auf die Belegungsverwaltung.
4.3.5Architekturdarstellung
Abbildung 6mehrere Applikationen
5RealisierungsBeispiel
Folgendes
Kapitel
soll
näher
beschreiben
wie
die
erweiterten
Anforderungen
an
ein
30
Fachbereichsinformationssystem konkret realisiert werden können. Dabei stellt dieses Beispiel nur eine
von mehreren Möglichkeiten dar, und erhebt keinen Anspruch auf eine optimale Lösung des Problems.
5.1Allgemein
In diesem Beispiel wurde sich dafür entschieden jeweils eine eigene Applikation für jeden Fachbereich
zu erstellen welche die Daten jeweils in einer eigenen Datenbank abspeichern. Über eine eigene LoginSeite ist das System des Fachbereiches erreichbar. Die Schwierigkeit dieser Lösung bestand
insbesondere in der Administration der einzelnen Fachbereichssysteme. Da eben nicht nur eine einzige
Applikation vorliegt, und jedes System im Prinzip neu installiert werden muss, reicht es nicht aus
Änderungen an Zugriffsrechten vorzunehmen. Es ist vielmehr ein AdministrationsTool zu entwickeln
dass den Quellcode von WHOIS2 aus einem „BasisOrdner“ lädt, die Konfigurationsdateien zum
Deployen erstellt, das Programm schließlich kompiliert und direkt in den DeployOrdner des JBoss
kopiert.
5.2Modifikationen am Quellcode
Um eine WHOIS2-Applikation für einen bestimmten Fachbereich zu installieren sind einige
Änderungen am Quellcode notwendig.
5.2.1JNDI-Namen der Beans
EnterpriseBeans werden in verteilten Systemen über ihren JNDI-Namen angesprochen. Daher müssen
die Beans jedes Fachbereiches jeweils einen unterschiedlichen Namen besitzen.
Das HomeInterface einer Bean über das die einzelnen Funktionen angesprochen werden können wird
bei WHOIS2 mit xDoclet erstellt, welches verschiedene ANT-Tasks anbietet mit deren Hilfe die
Erstellung aller benötigten Klassen für ein J2EE Projekt automatisiert werden kann. Es wird eine ANTBuild Datei „xdoclet-build.xml“ erstellt welche die benötigten Informationen enthält. In dieser Datei
31
wird der JNDI-Name an den Fachbereich angepasst, indem ein Property „jndi-Prefix“ erzeugt wird,
welches z.B. das Kürzel des Fachbereiches(FB05,FB06...) enthalten kann. jndi-Prefix ist eine selbst
erzeugte Property, der Name könnte auch anders gewählt werden. In den selbst erstellten Bean Klassen
muss dann noch das xDoclet-Tag „jndi-name“ und „local-jndi-name“ angespasst werden und mit dem
Wert des Property jndi-Prefix aus der xdoclet-build.xml ergänzt werden. Dies sieht z.B. bei der
BelegungsVerwaltungSessionBean folgendermaßen aus:
jndi-name="${jndi-prefix}BelegungverwaltungFassade"
local-jndi-name = "${jndi-prefix}BelegungsverwaltungsFassade"
5.2.2SQL-Queries
An einigen Stellen im Code wurden zur Perfomance Verbesserung eigene SQL-Queries geschrieben,
und
die
Verbindung
zur
Datenbank
selbst
hergestellt
ohne
Verwendung
der
ContainerManagedPersistence. Da jeder Fachbereich eine eigene Datenbank besitzt muss der Pfad zur
Datenbank bei jeder neuen Installation angepasst werden. Um nicht jedesmal den Pfad direkt im Code
neu anzupassen wird der Pfad aus einer Property-Datei ausgelesen.Diese heisst bei WHOIS2
„configuration.xml“, und wird beim Deployen direkt im Wurzelverzeichniss gespeichert.
5.3Modifikationen an den Konfigurationsdateien für das Deployen
Um eine J2EE-Applikation im JBoss zu installieren sind einige Konfigurationsdateien erforderlich die
dem JBoss u.a. Informationen über verwendete EnterpriseBeans und über die zu verwendende
Datenbank. Diese werden im folgenden aufgelistet:
application.xml
Informationen zur Erstellung der .EAR Datei, also der eigentlichen Applikation. Eintrag des ContextRoot unter dem die Web-Applikation zu erreichen ist. <context-root>/whoisfbx</context-root>
32
jboss.xml
Eintrag aller EJBs und deren JNDI-Namen. Wird automatisch von XDoclet erstellt. Damit XDoclet die
Änderungen der JNDI-Namen hier auch einträgt wird die Datei bei Ausführung des DeployTool vorher
gelöscht.
jbosscmp-jdbc.xml
Diese Datei wird benötigt damit JBoss die Container-managed EntityBeans auch am richtigen Ort
speichert und wiederfindet. Dazu muss hier anfangs die DataSource angegeben werden. Die Datei wird
ebenfalls von XDoclet erstellt, es muss hier aber lediglich der Name der DataSource angegeben
werden, wass im DeployTool erfolgt.
web.xml
Hier muss der benutzte Security-Realm verwendet werden, der in login-config.xml näher spezifiziert
wird. Im Security-Realm wird angegeben wie Benutzer authentifizert werden sollen.
login-config.xml
Hier werden die Security-Realms des JBoss-Servers angegeben. Z.b. kann angegeben werden dass
Benutzer über einen LDAP-Server oder aber über die WHOIS-Datenbank authentifizert werden
sollen.Es besteht hier die Möglichkeit für jeden Fachbereich eine eigene Security-Realm anzugeben.
Die login-config.xml befindet sich allerdings im JBoss Ordner „server/default/conf“. Damit
Änderungen wirksam werden muss der JBoss neu gestartet werden.
DataSourcexyz-ds.xml
Da für jeden Fachbereich eine eigene Datenbank erstellt werden soll, muss diese dem JBoss bekannt
gemacht werden. Dies geschieht durch eine XML-Konfigurationsdatei mit dem Suffix „-ds“. Zwei
Einträge müssen hier angepasst werden
<jndi-name>fbxyz</jndi-name>
<connection-url>jdbc:mysql://localhost:3306//fbxyz</connection-url>
Über den JNDI-Namen ist die Datenbank die in der connection-url angegeben wird, später erreichbar.
Diese Datei muss ins deploy Verzeichniss des JBoss kopiert werden.
33
5.4JBoss Konfigurationsdateien
Wird dieselbe Applikation mehrmals in den JBoss deployt mit obigen Modifikationen, so muss
sichergestellt werden dass bei der Ausführung einer Applikation nur die Klassen benutzt werden die
sich im jeweiligen Archiv der Applikation befinden. Dazu muss JBoss dahingehend modifiziert
werden, dass beim Laden von Klassen nur in diesem Archiv nachgeschaut wird. JBoss 4.0.l benutzt
standardmäßig einen einheitlichen ClassLoader für alle deployten Applikationen und lädt alle Klassen
in einen gemeinsamen Pool[JBoss05]. Dies kann bei WHOIS2 zu Problemen führen.
Zudem ist in der J2EE 1.4 Spezifikation eindeutig vorgeschrieben dass ein „ScopedClass Loading“
benutzt wird, welches die Klassen eines Deployments von den Klassen anderer Deployments isoliert.
Die genaue Vorgehensweise der Umstellung wird im beigefügten Dokument zur Installation des
„DeployTool“ näher beschrieben.
5.5Tool zum automatischen Deployen für WHOIS2
Soll für jeden Fachbereich jeweils eine eigene Applikation erstellt werden mit eigener Datenbank und
Login-Seite, und sollen die einzelnen Fachbereichssysteme über eine Web-Oberfläche einfach zu
erstellen sein, so ist es notwendig ein Tool zu erstellen, dass ausgehend vom Namen des Fachbereiches
die Konfigurationsdateien und den Quellcode anpasst, das Projekt neu kompiliert und in den deployOrdner des JBoss kopiert. Zur Untersuchung der Machbarkeit eines solchen Tools wurde das im
folgenden erläuterte „DeployTool erstellt“, was allerdings für einen professionellen Einsatz noch
erweitert und modifiziert werden müßte. Im Vordergrund stand aber die generelle Möglichkeit mit
solch einem Programm das Problem der Konfigurierung von WHOIS2 für verschiedene Fachbereiche
zu lösen. Das Tool besteht im Prinzip aus drei EnterpriseBeans die die benötigten Funktionalitäten
realisieren.
ConfigurationBean
Diese Bean modifiziert die Konfigurationsdateien für das Deployen, die xDoclet-build.xml zum
Erstellen der Home- und RemoteInterfaces mit Hilfe von XDoclet, und die Ant-BuildDatei packagingbuild.xml die das Enterprise Archive(.ear Datei) der Applikation erstellt welches deployt werden kann.
34
Die verschiedenen Konfigurationsdateien werden mit Hilfe des XML BearbeitungsTools „JDom“
modifiziert.
InstallBean
Diese Bean kann dazu benutzt werden die fertige Applikation in den JBoss zu deployen, und dient
außerdem dazu die Datenbank für den Fachbereich zu erstellen.
PackagingBean
Diese Bean löscht bereits erstellte ältere Konfigurationsdateien, startet anschließend XDoclet um die
Home und RemoteInterfaces zu erstellen, kompiliert die komplette Applikation und erstellt mit Hilfe
der packaging-build.xml das EnterpriseArchive der Applikation für den JBoss.
Folgende Abbildung soll die Nutzung des DeployTool noch einmal verdeutlichen:
Abbildung 7DeployTool
35
5.6DatenImporte
Wie bereits in den vorherigen Kapiteln teilweise erwähnt ist es bei geforderter möglichst völliger
Autarkie der Fachbereiche teilweise notwendig Daten über Lehrveranstaltungen und Studenten aus den
Datenbanken anderer Fachbereiche zu importieren.
5.6.1generelle Anforderungen
Eine Datenimportfunktion sollte es Administratoren und Mitarbeitern ermöglichen Daten über
benötigte Lehrveranstaltungen und Belegungen von Studenten über ein Benutzermenü zu importieren.
Diese Daten sollten im eigenen Fachbereichsinformationssystem deutlich erkennbar sein.
5.6.2Sicherheitsanforderungen
Ist ein Importieren von Daten notwendig so muss sichergestellt werden dass diese Daten nicht weiter
verändert werden können. Dies gilt nicht nur für die Daten auf der Datenbank des Fachbereiches von
welchem die Daten importiert werden, sondern auch für die eigene Datenbank. Das Verändern von
Daten die an andere Fachbereiche exportiert werden, kann dadurch ausgeschlossen werden, dass andere
Fachbereiche lediglich nur-lesende Rechte auf die Daten bekommen. Bei importierten Daten muss ein
weiteres Feld in den jeweiligen Tabellen eingefügt werden um diese von eigenen erstellten Daten
unterscheiden zu können. Möchte ein Benutzer Änderungen an diesen Daten vornehmen, muss
überprüft werden ob dies zulässig ist, und im nicht zulässigen Fall eine Fehlermeldung ausgegeben
werden. Somit kann sichergestellt werden dass die importierten Daten mit den OriginalDaten des
anderen Fachbereiches übereinstimmen. Natürlich muss hier noch beachtet werden dass eine
regelmäßige Aktualisierung der Daten stattfindet.
5.6.3Aktualisierung
Importierte Daten müssen in regelmäßigen Abständen aktualisiert werden. Es sollte auch möglich sein
Daten auf Wunsch sofort zu aktualisieren. Dies ist z.B. notwendig wenn neue Studienleistungen erzeugt
36
werden und nun dazugehörige Lehrveranstaltungen aus anderen Fachbereichen importiert werden
sollen.
5.6.4Auswahl der Daten
Um einen komfortablen und korrekten DatenImport zu ermöglichen, sollten die Daten die importiert
werden können in TabellenForm aufgelistet werden. Eine einzelne Auswahl von bestimmten Daten
sollte dabei möglich sein.
5.6.5Importieren von Lehrveranstaltungen
Wird eine Lehrveranstaltung zu einer Studienleistung nicht vom eigenen Fachbereich angeboten, so
muss diese aus anderen Fachbereichen importiert werden. Hierbei reicht es allerdings nicht aus einfach
nur die Daten der Lehrveranstaltung zu kopieren und in der eigenen Datenbank zu speichern, wie im
Datenbank-Modell von WHOIS2 deutlich wird.
Um Lehrveranstaltungen zu importieren muss die dazugehörige Studienleistung bereits in der eigenen
Datenbank erstellt worden sein. Anschließend wird nach dazu passenden Lehrveranstaltungen gesucht.
Hier
ist
es
denkbar
aus
einer
Komplett-Übersicht
aller
Lehrveranstaltungen
aller
FachbereichsDatenbanken auf die lesende Rechte vorliegen die entsprechende Veranstaltung
auszuwählen, als auch eine Filter-Funktion zu benutzen die mit Hilfe des Namens oder Kuerzel der
Studienleistung die entsprechende Lehrveranstaltung sucht.
Ist die passende Lehrveranstaltung gefunden so muss nicht nur diese Lehrveranstaltung kopiert
werden , sondern, sofern noch nicht vorhanden, auch die Daten über den Dozenten, der Lehreinheit, der
Fachgruppe und des Fachbereiches.
Beim jetzigen Stand von WHOIS2 besteht zudem das Problem dass Lehrveranstaltungen nicht ohne
Angabe eines Studienganges und Studiengangabschnittes erstellt werden können. Das bedeutet dass
jeder Fachbereich der Daten exportiert die Lehrveranstaltung bereits für einen selbst betreuten
Studiengang erstellt haben muss. Falls die Lehrveranstaltung aber ausschließlich für andere
Fachbereiche angeboten wird müssen entweder die Studiengänge für die die Lehrveranstaltung relevant
ist, in die eigene Datenbank aufgenommen werden, oder es muss eine Art „Dummy Studiengang“
37
erstellt werden, der nur dazu dient Lehrveranstaltungen für andere Fachbereiche aufzunehmen.
Wird gefordert dass die Datenbank die Situation in der Realität korrekt wiedergeben soll, muss
eigentlich gefordert werden dass jeder relevante Studiengang auch in der eigenen Datenbank
gespeichert wird. Oft weiss der Dozent aber nicht für welche Studiengänge die Lehrveranstaltung
eventuell relevant sein könnte, und beim Anlegen einer Veranstaltung auch gleichzeitig alle
notwendigen Studiengänge mit aufzunehmen, verkompliziert das ganze Szenario.
WHOIS2 sollte also dahingehend angepasst werden dass Lehrveranstaltungen auch ohne Angabe eines
Studiengangabschnittes erstellt werden können. Allerdings sollte die Studienleistung in beiden
Datenbanken vorhanden sein. Beim Anlegen einer neuen Lehrveranstaltung reicht es aus die
dazugehörige Studienleistung anzugeben.
5.6.6Importieren von Belegungen
Der zweite notwendige Import ist der Import von Belegungen für Lehrveranstaltungen, wobei die
Studenten die die Belegung vorgenommen haben aus anderen Fachbereichen kommen. Dies ist
notwendig um einen vollständigen Überblick über alle Belegungen einer Lehrveranstaltung zu
bekommen.
Um dies zu erreichen würde es ausreichen einfach alle Belegungen und Studenten mit ihren
AdressDaten zu kopieren, so dass sie über den E-Mail Verteiler erreichbar sind. Denkbar wäre aber
auch eine Funktion die Statistiken darüber erstellt aus welchen Fachbereichen die Hörer von
bestimmten Vorlesungen kommen. Dies erfordert dann eine gleichzeitige Speicherung des
Studienganges und des Studiengangabschnittes des Studenten.
Theoretisch können Studenten aller Fachbereiche eine bestimmte Lehrveranstaltung wählen. Dann
müßten alle Datenbanken untersucht werden und die Studenten die eine Lehrveranstaltung aus dem
Fachbereich belegt haben kopiert werden. Man sollte Datenbanken anderer Fachbereiche aber auch
gezielt durchsuchen können, und von dort aus die Belegungen und Studenten
zu ausgewählten
Lehrveranstaltungen wählen können.
In der Praxis könnte dies so aussehen, dass z.B. der zuständige Dozent des FB12 für die Vorlesung
38
“BetriebsSysteme 1“, alle Belegungen der Vorlesung aus allen anderen Fachbereichen importieren
möchte. Damit dies ohne Probleme möglich ist, sollten universitätsweite einheitliche Fremdschlüssel
verwendet werden. Dem Import von Belegungen aus anderen Fachbereichsdatenbanken geht immer ein
Export von Lehrveranstaltungen des anderen Fachbereiches vorraus. Somit ist hier sichergestellt dass
verwendete Bezeichnungen bzw. Kuerzel in allen Datenbanken gleich sind. Importiert ein anderer
Fachbereich die Lehrveranstaltungen eines Fachbereiches, so könnte man dies auch auf der Datenbank
vermerken. So wüßte man genau in welchem Fachbereich Studenten eine Belegung auf diese
Lehrveranstaltung vornehmen könnten, und muss nicht alle Datenbanken nach Belegungen
durchsuchen.
5.6.7Rechte
Beim Datenimport stellt sich die Frage, wer überhaupt einen Datenimport veranlassen darf.
Der Administrator sollte die Möglichkeit besitzen Daten von Lehrveranstaltungen gezielt zu
aktualisieren und Intervalle bestimmen zu können in denen ein automatischer Abgleich erfolgt.
Beim Import von Belegungen und damit auch Studenten sollte jeder Mitarbeiter der eine
Lehrveranstaltung erstellt hat, dafür verantwortlich sein einen Datenimport durchzuführen. Ein
ständiger Abgleich ist bei einigen Lehrveranstaltungen eventuell gar nicht notwendig, bzw. meist nur
am Anfang des Semester sinnvoll. Der Server sollte hier nicht unnötig belastet werden.
5.7KomponentenFreischaltung
WHOIS soll komponentenorientiert weiterentwickelt werden, und die einzelnen Komponenten die
bestimmte Funktionen innerhalb eines Themenbereiches anbieten, sollen für die Fachbereiche einzeln
freigeschaltet werden können, ohne den Quellcode in großem Maße zu verändern.
Der komplette Source-Code von WHOIS muss bei dieser Lösung in einem Basis-Ordner vorliegen.
Bei der Installation eines Systems muss dann beachtet werden dass eventuell nicht alle Komponenten
für den Fachbereich zur Verfügung stehen sollen. Zu diesem Zweck könnten die Berechtigungen in
einer Property-Datei gespeichert und ausgelesen werden. Das Auslesen der Datei innerhalb der
39
JavaServerPage die das Hauptmenü erstellt ist ohne Probleme möglich da jeglicher JavaCode hier
eingebunden werden kann. Somit könnte man auf eine komplizierte Rechteverwaltung verzichten, die
bei mehreren deployten Applikationen sowieso wenig Sinn macht und die ganze Problematik
verkompliziert. Werden die Berechtigungen in einer Property-Datei gespeichert so kann diese später
ohne Probleme ergänzt werden.
Um nicht jedesmal alle Komponenten installieren zu müssen, bietet sich auch die Möglichkeit an nur
bestimmte Komponenten in das Applikationsarchiv zu kopieren.
5.8aufgetrene Probleme
Generelles Problem war dass zu ähnlichen Szenarien wie sie bei WHOIS2 vorlagen im Prinzip keine
Informationen im Internet oder in der Literatur vorzufinden waren. Die Besonderheit liegt bei WHOIS2
darin, dass die Fachbereichsinformationssysteme weitgehend autark sein sollen, dies aber aufgrund von
interdisziplinären Studiengängen nicht einfach möglich ist. Es werden auch Lehrveranstaltungen
anderer Fachbereiche benötigt die kopiert werden müssen. Zudem wurde die Anforderung von
unterschiedlichen Login-Seiten und unterschiedlicher Datenbanken gestellt. Die vorgestellte Lösung
erscheint auf den ersten Blick sicherlich recht kompliziert, aber unter den gegebenen Bedingungen ist
keine einfache Lösung möglich. Würde man z.B. auf separate Datenbanken und Login-Seiten
verzichten dann würde das System eher einem HochschulinformationsSystem gleichen. Bedenkt man
aber dass WHOIS komponentenorientiert weiterentwickelt werden soll, und der Einsatz bestimmter
Komponenten im Fachbereich oft der Zustimmung vom Dekanat bedarf, ist es nicht ohne weiteres
möglich ein HochschulinformationsSystem einzusetzen. Weiter muss man bedenken dass z.B. aufgrund
der Komplexität der Vorgänge in einem Prüfungsamt, oft auch der Quellcode und verschiedene
Funktionen innerhalb einer Komponente an den Fachbereich angepasst werden muss[Kelt04]. Mit der
Lösung des mehrfachen Deployens wäre dies ohne weiteres möglich.
6Fazit
40
Durch
die
gestellten
Anforderungen(weitgehende
Autarkie,
eigene
Login-Seiten,
separate
Datenbanken), ist es bei Verwendung von J2EE und des JBoss Servers, die einfachste Lösung das
entwickelte Fachbereichsinformationssystem WHOIS2 für jeden Fachbereich der dies einsetzen möchte
im Server neu zu deployen, im Prinzip also neu zu installieren.
Nachteile dieser Lösung sind die erschwerte Wartbarkeit, da bei Änderungen am Quellcode mehr als
eine Applikation neu erstellt werden muss. Diese Vorgänge lassen sich aber soweit automatisieren dass
der Mehraufwand kaum noch ins Gewicht fällt. Vorteil ist das für jeden Fachbereich leicht eine
bestimmte Konfiguration des Programmes erstellt werden kann. Denkbar wäre auch ein Fall in dem es
mehrere Versionen des Programms gibt, und nicht jeder Fachbereich bereit ist jeweils die neueste
Version zu erwerben. Dies müßte dementsprechend verwaltet werden. Auch Sonderwünsche, für die
Änderungen am Programmcode notwendig sind, könnten mit dieser Methode relativ einfach erfüllt
werden.
41
Anhang A Datenbank-Schema WHOIS2
42
43
Anhang B Installation des DeployTool mit Eclipse und JBoss
1.)
Auschecken des Programmes aus dem CVS:
RepositoryPath: /home/pi/whois/cvshome/
ModuleName: DeployTool
Auschecken des angepassten WHOIS2
RepositoryPath: /home/pi/whois/cvshome/
ModuleName: whois2Mandanten
2.)
unter Project->Properties: BuildPath anpassen:
J2EE 1.4Libraries(JBOSS_IDE)
JRE System Library
Web Services 1.0 Libraries(JBOSS_IDE)
alle Libraries im Ordner UsedLib
hinzufügen
im Reiter Source: ejbsrc und src muss im buildpath sein; DefaultOutputFolder = bin
3.)
in xdoclet-build.xml
Properties eclipse.home und xdoclet.basedir anpassen.
4.)
.project Datei überprüfen: sollte folgendermaßen aussehen:
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>DeployTool</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
<buildCommand>
<name>org.eclipse.jdt.core.javabuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>org.eclipse.jdt.core.javanature</nature>
</natures>
</projectDescription>
5.)
im Ordner src, in der Bean de.deploytool.sb.ConfigurationBean und
de.deploytool.sb.PackagingBean die statische Variable WHOIS_HOME anpassen, muss auf
whois2 ProjektOrdner zeigen.
44
6.)
XDoclet ausführen, anschließend die Datei web.xml aus dem help-Ordner ins Verzeichniss
src/Web-INF kopieren und alte überschreiben. Beim Ausführen von XDoclet wird die
funktionierende web.xml jedesmal überschrieben. Dann ist das Programm aber nicht lauffähig.
darauf achten dass Eclipse die Klassendateien automatisch erstellt, ansonsten selber
erstellen(BuildALL);
7.)
Packaging ausführen
8.)
benötigte Libraries unter DeployTool/JBOSS_Lib/lib in JBoss-Library Ordner kopieren
9.)
DeployTool.ear ins JBoss-Deploy Verzeichniss kopieren
Das Programm ist schließlich über http://localhost:JBOSS-Port/AdminWhois2erreichbar. Um sich
einzuloggen Benutzername „Admin“ und Passwort „Admin“ eingeben.
Da das Tool lediglich die Machbarkeit der Realisierung der vorgestellten Alternative 2 demonstriert,
wird lediglich die Angabe der Url unter der die neue Applikation erreichbar sein soll
benötigt.Anschließend wird das .ear Archiv von WHOIS2 erstellt und im jeweiligen Eclipse Ordner
hinterlegt. Um eine lauffähige Applikation zu erhalten, muss eine MySQL Datenbank erstellt worden
sein, mit dem Namen der auch als URL angegeben wurde.
Die FachbereichLogos und später eventuell auch andere JPEG oder GIF Bilder, sollten alle in einem
extra erstellten Ordner für den jeweiligen Fachbereich liegen. Prinzipiell könnten die Bilder auch stets
in den selben Ordner kopiert werden. Sollte aber später einmal ein neues Packaging der Applikationen
erforderlich sein, so liegen alle notwendigen Bilder bereits in den Ordnern.
Für einen professionellen Einsatz müßte das Tool weiterentwickelt werden. So sollte man z.B.
Informationen über die installierten Applikationen, eventuell mit einer Versionsnummer, in einer
Datenbank speichern.
45
Literatur
[Arms05
]Eric
Armstrong
et
al.:
The
J2EE
1.4
Tutorial.
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html, Abruf am 2005-05-01
[Deep01] Alur,Deepak et al.: Core J2EE Patterns. 1.Auflage ,Pearson Education, 2001.
[JBoss05] JBoss: http://docs.jboss.org/jbossas/whatsnew40/html_single/ Abruf am 2005-08-27
[Kelt04]Kelter, Udo: Fachbereichsinformationssysteme, in Skript zur Vorlesung Softwaretechnik 1,
Universität Siegen,2004
[Korn05] Korn, Wolfgang: Der Einsatz von JAAS in Web-Applikationen
http://www.javamagazin.de/itr/online_artikel/psecom,id,314,nodeid,11.html, 2003-03, Abruf am 200504-26
[Moor05] Moore, Dan: Using JAAS for Authorization and Authentication
http://www.mooreds.com/jaas.html, Abruf am 2005-05-25
[Mose05] Moses, Tim: eXtensible Access Control Markup Language(XACML) Version 2.0,
http://docs.oasis-open.org/xacml/access_control-xacml-2_0-core-spec-cd-04.pdf Abruf am 2005-05-09
[Prie05]Priebe, T., Dobmeier, W., Muschall, B., Pernul, G.: ABAC - Ein Referenzmodell für
attributbasierte Zugriffskontrolle. Proc. 2. Jahrestagung Fachbereich Sicherheit der Gesellschaft für
Informatik, Regensburg, April 2005.
[Sun05]Sun Microsystems: Sun's XACML Implementation, Programmer's Guide for Version 1.2. .
http://sunxacml.sourceforge.net/guide.html, Abruf am 2005-05-18
[Will05]Williams,
Jeff: Access
Control
(aka Authorization)
in
Your
J2EE Application.
http://www.owasp.org/columns/jwilliams/jwilliams3.html,2003-11-03, Abruf am 2005-04-29
46
[WOLF05] Wolf, Andreas: Access Control Management für Enterprise Java Beans
www.lineas.de/gi-bs/vortraege/awolf201101.pdf, Abruf am 2005-06-12