View
1
Download
0
Category
Preview:
Citation preview
Seminararbeit
Integration von Groupware- und J2EE-basierten Applikationen:
Konzeption eines generischen Vorgehensmodells zur Entwicklung
von JSP Custom Tags
Prof. Dr. Ludwig Nastansky
Sommersemester 2003
Betreuer:
Dipl.-Wirt. Inform. Ingo Erdmann
vorgelegt von:
Christian Eric Leutnant
Wirtschaftsinformatik
Matrikelnummer: 3689202
Gerhart-Hauptmann-Straße 2
33129 Delbrück-Boke
Inhalt
i
Inhaltsverzeichnis
1 Einleitung .......................................................................................................................1 1.1 Szenario..................................................................................................................1 1.2 Zielsetzung .............................................................................................................1 1.3 Aufbau der Arbeit ...................................................................................................2
2 Grundbegriffe und thematische Abgrenzung ...................................................................3 2.1 Vorgehensmodelle ..................................................................................................3 2.2 Groupware..............................................................................................................4
2.2.1 Computer Supported Cooperative Work und Groupware.................................4 2.2.2 Architektur von Groupwaresystemen...............................................................4
2.3 Java 2 Enterprise Edition ........................................................................................6 2.3.1 Technologie- und Architekturüberblick ...........................................................6 2.3.2 JavaServer Pages.............................................................................................8 2.3.3 Tag Libraries und Custom Tags.....................................................................10
2.4 Integration von Anwendungssystemen ..................................................................11 2.4.1 Definition des Integrationsbegriffs ................................................................11 2.4.2 Integrationstypen...........................................................................................12 2.4.3 Integrationsziele ............................................................................................13
3 Konzeption des Vorgehensmodells ...............................................................................15 3.1 Motivation und Abgrenzung des Integrationstyps..................................................15 3.2 Voraussetzungen...................................................................................................16 3.3 Das Vorgehensmodell ...........................................................................................16
3.3.1 Problembewusstsein schaffen........................................................................17 3.3.2 Technische Machbarkeit analysieren .............................................................17 3.3.3 Nutzwert von Custom Tags evaluieren ..........................................................18 3.3.4 Entwicklung der Tag Library.........................................................................19 3.3.5 Organisationsweites Publizieren der Tag Library...........................................19 3.3.6 Integration in Entwicklungsumgebung ..........................................................19
3.4 Beurteilung des Vorgehensmodells .......................................................................20 4 Anwendung des Vorgehensmodells ..............................................................................21
4.1 Systemumgebung..................................................................................................21 4.2 Anforderungsdefinition des Prototyps ...................................................................21 4.3 Erstellung eines Custom Tags anhand des Vorgehensmodells ...............................22
4.3.1 Problembewusstsein schaffen........................................................................22 4.3.2 Technische Realisierungsmöglichkeiten analysieren......................................22 4.3.3 Nutzwert von Custom Tags evaluieren ..........................................................23 4.3.4 Entwicklung der Tag Library.........................................................................23 4.3.5 Organisationsweites Publizieren der Tag Library...........................................24 4.3.6 Integration in Entwicklungsumgebung ..........................................................24
5 Zusammenfassung und Ausblick...................................................................................25 6 Literaturverzeichnis ......................................................................................................26
Inhalt
ii
Abbildungsverzeichnis
Abbildung 1: J2EE Container, Standard Services und Komponenten (aus Takagiwa et al. 2001) ..............................................................................................................................8
Abbildung 2: Das Vorgehensmodell in Phasen .....................................................................16
Abkürzungsverzeichnis
API Application Programming Interface
EJB Enterprise JavaBeans
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
IIOP Internet Inter-Orb Protocol
J2EE Java-2-Plattform Enterprise Edition
JSP JavaServer Pages
1 Einleitung
1
1 Einleitung
1.1 Szenario
Die heutige IT-Landschaft von Unternehmen ist in der Regel so gekennzeichnet, dass eine
Vielfalt heterogener Anwendungssysteme existiert, die den unterschiedlichsten
betriebswirtschaftlichen und technischen Ansprüchen und Anforderungen gerecht werden
müssen.1 Nicht zuletzt unter finanziellen Gesichtspunkten erscheint es jedoch zumeist
sinnvoll, Redundanzen sowohl in der Datenhaltung als auch in der Anwendungslogik
systemübergreifend zu vermeiden.2 Verschiedene Anwendungssysteme operieren in diesem
Idealzustand auf einem einheitlichen, gemeinsamen Datenbestand; Funktionalitäten, die
bereits in einem System realisiert wurden, können auch von anderen Systemen verwendet
werden. Dieser Ansatz wird allgemein unter dem Namen „Integration“ diskutiert und gilt als
zentraler Begriff in der Wirtschaftsinformatik.3
Im Groupware-Umfeld ist derzeit insbesondere die Möglichkeit der Integration mit
Anwendungen, die auf der Java 2 Plattform, Enterprise Edition (J2EE) basieren, ein
hochaktuelles Thema. Auf der einen Seite steht hierbei die Groupware mit ihrem
Haupteinsatzgebiet im kollaborativen Umfeld. Auf der anderen Seite existierten J2EE
Anwendungen, die auf so genannten J2EE Application Servern laufen bzw. ausgeführt
werden.
1.2 Zielsetzung
Eine Möglichkeit zur Integration von Groupware- und J2EE-basierten Applikationen ist die
Entwicklung und der Einsatz von Custom Tags bzw. Tag Libraries.
Ohne eine zielorientierte Anwendung eines Vorgehensmodells ist die heutige Entwicklung
von Software bei komplexeren Problemstellungen jedoch kaum noch zu bewältigen.4 Es stellt
sich daher die Frage, wie derartige Tag Libraries zu konzipieren bzw. zu entwickeln sind.
Einerseits soll der Entwicklungsprozess so effizient und effektiv wie möglich ablaufen,
andererseits muss das Endprodukt selbst jeglichen Anforderungen an die Qualität von
Software genüge tun.5
1 Vgl. Kaib 2002, S. 13 2 Vgl. Kaib 2002, S. 27 3 Vgl. Heilmann 1989, S. 46 ff. 4 Siehe dazu Ghezzi et al. 1991, S. 357 ff. 5 Zu Kriterien der Qualität von Software vgl. Ghezzi et al. 1991, S. 17 ff.
1 Einleitung
2
Das Ziel dieser Seminararbeit ist somit, ein Vorgehensmodell zu konzipieren, welches als
Leitfaden zur Entwicklung von Custom Tags innerhalb des Umfelds der Integration von
Groupware und J2EE dienen kann.
1.3 Aufbau der Arbeit
In Kapitel 2 finden zunächst eine Erläuterung der Begrifflichkeiten und eine thematische
Abgrenzung der Arbeit statt. Hierbei wird insbesondere auf die J2EE- sowie die Groupware-
Architektur eingegangen.
Darauf aufbauend wird in Kapitel 3 zunächst noch einmal die Motivation für ein
Vorgehensmodell zur Entwicklung von Custom Tags dargelegt. Im Anschluss daran erfolgt
die Konzeption dieses Modells. Nach einer kurzen Beurteilung wird das Modell in Kapitel 4
aufgegriffen und anhand eines praktischen Beispiels der Entwicklung einer Tag Library
verdeutlicht. Abschließend werden in Kapitel 5 eine Zusammenfassung sowie ein kurzer
Ausblick gegeben.
2 Grundbegriffe und thematische Abgrenzung
3
2 Grundbegriffe und thematische Abgrenzung
In diesem Kapitel werden die notwendigen Grundlagen, auf denen diese Arbeit aufbaut,
wiedergegeben. Zunächst erfolgt eine Einführung in Vorgehensmodelle. Im Anschluss daran
wird auf Groupware sowie J2EE eingegangen. Der letzte Abschnitt dieses Kapitels widmet
sich der Integration von Anwendungssystemen.
2.1 Vorgehensmodelle
Heutzutage gilt es als nahezu unmöglich, komplexe Software zu entwickeln, ohne ein
geeignetes Vorgehensmodell zur Softwareentwicklung anzuwenden.6 Laut der Gesellschaft
für Informatik ist ein Vorgehensmodell ein „Muster zur Beschreibung eines
Entwicklungsprozesses auf der Basis eines Entwicklungsschemas“7. „Vorgehensmodelle (life
cycle models) dienen [somit]8 zur Benennung und Ordnung von produktbezogenen
Aktivitäten bei der Softwareentwicklung“.9
In der wissenschaftlichen Literatur10 findet sich bereits eine breite Vielfalt an
Vorgehensmodellen wieder.11 Ohne im Detail einzelne Vorgehensmodelle vorzustellen, ist
festzustellen, dass sie alle den Prozess der Entwicklung von Software durch eine Folge von
Aktivitäten bzw. Phasen definieren, die nach einem vorgegebenen Ablaufplan stattfinden und
so als Leitfaden für ein systematisches Vorgehen dienen. Es ist jedoch ebenfalls festzustellen,
dass es aufgrund einer Vielzahl von Einflussfaktoren kein für alle Anwendungsgebiete
optimales Vorgehensmodell gibt.12 Aus diesem Grunde ist es nicht nur möglich sondern sogar
unumgänglich, bereits existierende Vorgehensmodelle für spezifische Anwendungsfälle zu
modifizieren oder gar neue, spezifische Vorgehensmodelle zu entwickeln, die für das
jeweilige Anwendungsszenario am geeignetsten erscheinen.
6 Vgl. Ghezzi et al. 1991, S. 360 7 Gesellschaft für Informatik, Arbeitskreis „Begriffe und Konzepte der Vorgehensmodellierung“ http://www.vorgehensmodelle.de/Giak/index.html (letzter Zugriff: 19.11.2003) 8 Zitat erweitert durch den Autor 9 Rechenberg / Pomberger 1997, S. 657 10 Die Begriffe Vorgehensmodell, Lebenszyklusmodell und Software-Prozessmodell werden dort synonym verwendet. 11 Siehe dazu beispielsweise Ghezzi et al. 1991, S. 358 ff. 12 Vgl. Frick / Marré 1995, S. 52
2 Grundbegriffe und thematische Abgrenzung
4
2.2 Groupware
Neben einer kurzen Darstellung des Forschungsgebiets Computer Supported Cooperative
Work wird in diesem Kapitel auf den Begriff Groupware und die Architektur von
Groupwaresystemen eingegangen.
2.2.1 Computer Supported Cooperative Work und Groupware
Computer Supported Cooperative Work, kurz CSCW, ist eine interdisziplinäre
Forschungsrichtung der Informatik, welche sich damit beschäftigt, wie durch den Einsatz der
Informations- und Kommunikationstechnologie die Arbeit von Personen in Gruppen bzw.
Teams unterstützt und damit gleichermaßen effizienter und effektiver gestalten kann.13
Während CSCW das wissenschaftliche Forschungsgebiet bezeichnet, steht der Begriff
Groupware für die Software, welche im Rahmen dieses Forschungsgebietes entstanden ist
bzw. auf dessen Ergebnissen beruht.14 In der Literatur wird Groupware häufig nach der Art
der Unterstützungsfunktion von Prozessen der Gruppenarbeit klassifiziert.15 Dabei wird
unterschieden zwischen Kommunikations-, Koordinations- und Kooperationsprozessen.
Kommunikation bezeichnet dabei den „Austausch von Informationsobjekten“16. Eine
Kommunikation im Umfeld der Informationstechnologie kann bereits durch das Senden und
Empfangen einer E-Mail stattfinden. Durch Koordination werden das Arbeiten in einem Team
organisiert und die Tätigkeiten der beteiligten Teammitglieder aufeinander abgestimmt.17
„Unter (..) Kooperation wird der Austausch von Informationen verschiedener Personen mit
einem gemeinsamen Ziel verstanden.“18 Im Gegensatz zur Kooperation ist bei der
Koordination ein gemeinsames Ziel nicht immer gegeben, es liegt jedoch häufig eine
organisatorische Zusammenarbeit bzw. ein gemeinsames Interesse vor.19 Im Folgenden
werden die Begriffe Groupware und Groupwaresystem synonym verwendet.
2.2.2 Architektur von Groupwaresystemen
Wie ein Abschnitt 2.2.1 bereits erläutert, handelt es sich bei Groupware um Software und
nicht wie bei dem Begriff CSCW um ein wissenschaftliches Forschungsgebiet. „Die
13 Vgl. Teufel et al. 1995, S. 14 ff. 14 Siehe Teufel et al. 1995, S. 21 sowie Riggert 2000, S. 224 15 Vgl. Teufel et al. 1995, S. 26 ff. 16 Vgl. Teufel et al. 1995, S. 26 17 Siehe Riggert 2000, S. 225 18 Vgl. Dierker / Sander 1999, S. 104 19 Vgl. Teufel et al. 1995, S. 26
2 Grundbegriffe und thematische Abgrenzung
5
Architektur von Groupwaresystemen wird [somit]20 wesentlich durch technische Kriterien
bestimmt.“21 Diese Kriterien bzw. Anforderungen an die Architektur sollen im Folgenden in
Anlehnung an Riggert (2000, S. 230 f.)näher erläutert werden.
Standards
In der IT-Landschaft heutiger Unternehmen existiert häufig eine Vielfalt heterogener
Anwendungssysteme.22 Um Groupwaresysteme in eine derartige IT-Infrastruktur einzuführen
ist es somit erforderlich, dass sie gängige Betriebssysteme und Kommunikationsprotokolle
unterstützen.23
Dokumentenmanagement
Groupwaresysteme basieren in aller Regel nicht auf relationalen Datenbanken, in welchen
jegliche Daten in Tabellenform abgelegt werden, sondern auf einem eigenen Datencontainer,
der allerdings ebenfalls als Datenbank bezeichnet wird. Das so genannte Informationsmodell
einer Groupware Architektur beschreibt, wie Daten in einem Groupware Architektur
gespeichert und bereitgestellt werden.24 Ein zentraler Begriff ist in diesem Zusammenhang
der so genannte „Object Store“. Bei einem Groupware Object Store handelt es sich um eine
verteilte Datenbank, auf die mehrere Benutzer zugreifen können.25 In solch einer Datenbank
werden letztendlich auch die Daten in Form von Dokumenten abgelegt.26 Benutzer können
sich derartige Dokumente anzeigen lassen, sie bearbeiten und auch löschen. Unterstützt
werden sie dabei durch Mechanismen zur Informationsorganisation und Informationssuche,
wie z. B. Volltextretrievalmechanismen.27
Sicherheitskonzepte
Groupware wird, wie bereits erwähnt, zur Unterstützung der Gruppenarbeit eingesetzt. Häufig
ist es jedoch so, dass nicht jedes Mitglied einer Gruppe auf jegliche Daten zugreifen darf.
Darüber hinaus ist mitunter erforderlich, dass eindeutig und zweifelsfrei nachgewiesen
werden kann, dass beispielsweise ein Dokument von einer bestimmten Person erstellt wurde.
Aus diesem Grunde gehören Sicherheitskonzepte, die den Zugriffsschutz oder den
20 Ergänzung des Verfassers 21 Siehe Riggert 2000, S. 230 22 Vgl. Kapitel 1.1 23 Vgl. Riggert 2000, S. 230 24 Vgl. Lotus Development 1995, S. 29 25 Vgl. Lotus Development 1995, S. 29 26 Näheres dazu in Lotus Development 1995 27 Vgl. Riggert 2000, S. 230
2 Grundbegriffe und thematische Abgrenzung
6
Identitätsnachweis durch Mechanismen wie Authentifizierung und Autorisierung steuern, als
wesentliches Element zu jeder Groupware.28
Nachrichtenaustausch
Zur Unterstützung der Kommunikations-, Koordinations- und Kooperationsprozesse ist es
notwendig, dass Groupware Mechanismen zum Nachrichtenaustausch bereitstellt. Riggert
(2000, S. 231) weißt darauf hin, dass Groupwaresysteme traditionell eine ausgefeilte
Nachrichtenaustauschtechnik mit Gateways zu vielen E-Mail-Systemen aufweisen.
Replikation
„Unter Replikation versteht man grundsätzlich das Konzept zum Abgleichen und
Synchronisieren der Inhalte verschiedener räumlich verteilter dynamischer „Kopien“ einer
Datenbank“.29 Das Konzept der Replikation nimmt dabei bewusst eine redundante
Datenhaltung in Kauf.30 Nur dadurch ist es möglich, verteilt an unterschiedlichen Orten, mit
ein und derselben Datenbank zu arbeiten, ohne an ein Kommunikationsnetzwerk
angeschlossen zu sein.
Anwendungsentwicklung
Ein Groupwaresystem soll eine Entwicklungsumgebung mit sich bringen, mit der es möglich
ist, umfangreiche und hochkomplexe Geschäftsanwendungen zu entwickeln. Andererseits soll
es aber auch die Möglichkeit geben, dass ein Endanwender einer Groupware relativ einfach
kleine Aufgaben zur Erstellung bzw. Bearbeitung einer konkreten Groupware Anwendung
selbst bewältigen kann.31
2.3 Java 2 Enterprise Edition
In diesem Kapitel wird zunächst ein Überblick über die J2EE Architektur gegeben. Im
Anschluss daran werden Servlets, JavaServer Pages sowie Tag Libraries detaillierter
betrachtet.
2.3.1 Technologie- und Architekturüberblick
„Die Java-2-Plattform Enterprise Edition (J2EE) definiert einen Standard zur
Implementation, Konfiguration, Verteilung und zum Einsatz von unternehmensweiten
28 Vgl. Dierker / Sander 1999, S. 154 ff 29 Dierker / Sander 1999, S. 129 30 Vgl. Riggert 2000, S. 231 31 Vgl. Riggert 2000, S. 231
2 Grundbegriffe und thematische Abgrenzung
7
Anwendungen (Enterprise Applications)“.32 Bei einer J2EE-Anwendung handelt es sich dabei
um eine Software, welche auf der Programmiersprache Java basiert und in der Regel auf
einem speziellen Server, dem J2EE-Server, auch Application Server genannt, ausgeführt
wird.33
Eine J2EE-Anwendung basiert dabei häufig auf der so genannten 3-Schichten-Architektur34,
wodurch die Anwendung logisch in eine Präsentationsebene, eine Anwendungsebene und
eine Datenhaltungsebene aufgetrennt wird.
Darüber hinaus basiert die J2EE-Archiktur auf Komponenten. Das J2EE Tutorial35 definiert
eine Komponente folgendermaßen: „A J2EE component is a self-contained functional
software unit that is assembled into a J2EE application with its related classes and files and
that communicates with other components.“ Es handelt sich bei Komponenten also um
eigenständige Softwaremodule die miteinander kommunizieren können.
J2EE Standard-konforme Anwendungen können generell aus vier verschiedenen
Anwendungskomponenten bestehen: einer auf der Programmiersprache Java basierenden
Client-Anwendung, welche auf einem Desktop-Rechner ausgeführt wird, einem Java Applet,
einer Web Komponente sowie einer Enterprise JavaBeans (EJB) Komponente.36 Im Rahmen
dieser Arbeit ist insbesondere die Web Komponente der J2EE Architektur hervorzuheben. Die
Web Komponente hat sowohl die Aufgabe, dem Benutzer die Daten zu Präsentieren, als auch
entsprechende Eingaben des Benutzers entgegenzunehmen.37 Dies geschieht insbesondere
durch die JavaServer Pages (JSP) Technologie, die in Abschnitt 2.3.2 näher beschrieben
wird.
Zu jeder Komponente existiert ein so genannter Container. Ein Container dient als
Laufzeitumgebung für eine spezielle J2EE Komponente. Darüber hinaus stellt ein Container
gewisse Dienste zur Verfügung, die beispielsweise die Kommunikation zwischen
unterschiedlichen Komponenten ermöglichen, wie es in Abbildung 1 schematisch dargestellt
wird. Dadurch kann sich der Entwickler im Allgemeinen stärker auf die eigentliche
Implementierung bzw. Umsetzung von Geschäftsprozessen konzentrieren, ohne sich auf
Hardware- bzw. Betriebssystemebene beispielsweise um Protokolle zur Kommunikation
kümmern zu müssen.
32 Vgl. Turau et al. 2001, S. 1 33 Vgl. Bien 2001, S. 65 f. 34 Vgl. Balzert 1999, S. 446 ff. 35 Zu finden unter http://java.sun.com/j2ee 36 Zur Vertiefung siehe J2EE Specification 37 Vgl. Turau et al. 2001, S. 19
2 Grundbegriffe und thematische Abgrenzung
8
Abbildung 1: J2EE Container, Standard Services und Komponenten (aus Takagiwa et al. 2001)
Wie eingangs bereits erwähnt, werden J2EE Applikationen auf Application Servern
ausgeführt. Innerhalb einer verteilten 3-Schichten-Architektur besetzt ein Application Server
die Anwendungs- bzw. Präsentationsschicht, d. h. er beinhaltet vor allem einen Web
Container und einen EJB Container. Dadurch führt er zum einen die Geschäftslogik im
Hintergrund aus, welche beispielsweise den Zugriff auf die Datenhaltungsebene steuern kann,
zum anderen stellt er über die Web Komponenten das Bindeglied zum Anwender dar.
Darüber hinaus unterstützt ein Application Server in Anlehnung an die J2EE Spezifikation
eine Reihe weiterer Protokolle und Sicherheitsmechanismen.
2.3.2 JavaServer Pages
In Abschnitt 2.3.1 wurde bereits angedeutet, dass die Web Komponente innerhalb der J2EE
Architektur die zentrale Rolle der Darstellung bzw. Präsentation von Daten gegenüber dem
Benutzer und der Entgegennahme seiner Eingaben übernimmt.38 Der Benutzer greift mittels
eines gängigen Webbrowsers auf die Anwendung zu. Auf der Seite des Application Servers
werden dabei die Web Komponenten angesprochen. Die J2EE Spezifikation definiert zwei
Arten von Web Komponenten, die Java Servlets und die JavaServer Pages (JSP).39
38 Im Kontext einer Webbrowser-basierten Anwendung wird zunehmend auf eigene Client Anwendungen, aber auch auf im Browser dargestellte Applets verzichtet, welche ebenfalls die Rolle des Benutzerinterfaces samt Darstellung und Annahme von Eingaben übernehmen könnten. 39 Vgl. Bodoff et al. 2002, Kapitel 9 (Anmerkung: Der Autor konnte nur auf eine elektronische Version dieses Buches zugreifen, die eine genaue Seitenangabe nicht zulässt. Dies gilt im Folgenden auch für alle weiteren Verweise auf diese Quelle innerhalb dieser Arbeit.)
2 Grundbegriffe und thematische Abgrenzung
9
Durch beide Technologien ist es möglich, Webseiten zu generieren, die im Gegensatz zu rein
statischen HTML-Seiten auch einen dynamischen Inhalt aufweisen können. Um die JSP
Technologie zu erklären, müssen jedoch zunächst Java Servlets beschrieben werden. Es sollen
im Folgenden jedoch keine Technologiedetails erklärt werden. Die Vermittlung der
grundlegenden Idee steht im Vordergrund.40
Java Servlets
Java Servlets (kurz Servlets) sind zunächst einmal Java Programme, die ein Java Interface
implementieren oder von einer speziellen Java Klasse erben.41 Die Laufzeitumgebung, welche
Java Programme zur Ausführung benötigen, wird durch eine so genannte Servlet Engine
bereitgestellt. Ein Browser stellt eine Anfrage an ein Servlet in Form eines HTTP Requests.
Das Servlet bearbeitet die Anfrage und antwort mit einem HTTP Response. Sowohl HTTP
Request als auch Response sind standardisierte Nachrichten, die durch das Hypertext Transfer
Protocol (HTTP) spezifiziert werden.42 Ein Webbrowser ist in der Lage, Daten in Form der
HyperText Markup Language43 (HTML)darzustellen. Ein Servlet als Java Klasse generiert
eine Ausgabe im HTML-Format durch den Aufruf von Funktionen, die durch eine
Standardausgabeklasse44 zur Verfügung gestellt werden.45 Als Parameter für diese Befehle
wird in diesem Fall Text im HTML-Format übergeben.
Der Vorteil eines Servlets ist, dass auf Anfrage eines Webbrowsers dynamischer Inhalt
generiert werden kann, da innerhalb des Java Codes beliebige Funktionen, beispielsweise zum
Auslesen von Informationen aus Datenbanken, aufgerufen werden können. Ein wesentlicher
Nachteil bei komplexen Webanwendungen allerdings ist, dass innerhalb eines Servlets eine
Vermischung von Anwendungslogik und Code zur Darstellung einer HMTL Seite stattfindet.
Da oft der statische Inhalt einer Webseite gegenüber dem dynamischen Anteil überwiegt,
stellt ein Servlet somit vielfach nicht die optimale Lösung dar.
JavaServer Pages (JSP)
Eine mögliche Alternative zu Servlets sind JavaServer Pages (JSP).46 JSPs bieten ebenfalls
die Möglichkeit, dynamischen Inhalt mit statischem Inhalt zu verbinden. Wie bei Servlets
40 Für einen detaillierten Überblick siehe beispielsweise Turau et al. 2001 41 Vgl. Bodoff et al. 2002, Kapitel 10 42 Vgl. http://www.w3.org/Protocols/rfc2616/rfc2616.html (Stand 07.11.2003) 43 Siehe http://www.w3.org/MarkUp/ (Stand 14.02.2004) 44 Zur Vertiefung siehe http://java.sun.com/j2se/1.4.2/docs/api/java/io/PrintWriter.html (Stand 07.11.2003) 45 Neben HTML kann ein Servlet auch andere Formate, so genannte Content Types generieren. 46 Streng genommen gelten JSPs nicht als eine Servlets ausschließende Alternative sondern werden in umfangreichen Webanwendungen parallel innerhalb einer Model View Controller Architektur eingesetzt (vgl. Brown et al. 2001, S. 197)
2 Grundbegriffe und thematische Abgrenzung
10
auch findet hierbei eine Vermischung von Code zur Darstellung mit Code der
Anwendungslogik statt. Da jedoch eine JSP prinzipiell auf einer HTML Seite basiert, wird der
Code zur Darstellung einer HTML Seite in den Vordergrund gerückt. An die meist wenigen
Stellen, wo dynamischer Inhalt notwendig ist, treten spezielle Anweisungen, die, vereinfacht
ausgedrückt, auf der Programmiersprache Java beruhen. Verständlicherweise könnte ein
Browser den Java Code so nicht nutzen bzw. sinnvoll darstellen. Aus diesem Grund wird eine
JSP zunächst in ein Servlet übersetzt. Dies geschieht mit Hilfe der so genannten JSP Engine.
Dabei werden auch die normalen HTML Tags wieder in eine Methode der
Standardausgabeklasse eingebettet. Das Servlet selbst wird dann durch die Servlet Engine
kompiliert, welches bei einer Anfrage durch einen Browser die entsprechende Antwort
erzeugen kann. Dann werden auch die ursprünglichen Java-Anweisungen innerhalb einer JSP
mit ausgeführt und der Inhalt kann so gegebenenfalls dynamisch generiert werden.
2.3.3 Tag Libraries und Custom Tags
Bei JavaServer Pages aber auch Servlets wurde stets angemerkt, dass bei beiden
Technologien eine Vermischung von Code für die Darstellung als auch Code der
Anwendungslogik, insbesondere bei der Generierung von dynamischen Inhalten, vorkommt.
Diese Vermischung gestaltet sich insbesondere als Problem bei umfangreichen, großen
Webanwendungen, wodurch Wartung und Pflege erschwert werden.
Eine mögliche Lösung dieses Problems sind die so genannten Tag Libraries.
Eine Tag Library fasst in der Regel mehrere eigenentwickelte Tags, so genannte Custom Tags
zusammen. Durch ein Custom Tag ist eine Kapselung von Anwendungslogik möglich.
Der wesentliche Kern eines Custom Tags bildet der so genannte Tag Handler. Der Tag
Handler ist eine JavaBean, d. h. vereinfacht gesagt eine Java Klasse, die eines von drei
speziellen Interfaces implementieren muss. In der Praxis wird jedoch meistens eine Klasse
erstellt, die von einer Klasse der Java API erbt, die ihrerseits bereits eines der Interfaces
implementiert. Wesentlich ist, dass jedem Custom Tag in einer Tag Library ein Tag Handler
bzw. eine Tag Handler Klasse entspricht. Durch beide Varianten wird jedoch sichergestellt,
dass die Tag Handler Klasse spezielle Methoden enthalten muss, die vom JSP Container bei
der Ausführung eines Tags innerhalb einer JSP-Seite aufgerufen werden können. In diesen
Methoden ist dann der eigentliche Programmcode eines Custom Tags enthalten, wie
beispielsweise Berechnungen oder Datenzugriffe.
Ein Tag Library Descriptor (TLD) ist eine XML-basierte Datei, die wichtige Informationen
für den JSP Container enthält. Neben allgemeinen Eigenschaften wie z. B. dem Namen der
Tag Library und Informationen zu benutzten Standards werden für jeden Tag spezielle
2 Grundbegriffe und thematische Abgrenzung
11
Eigenschaften angegeben. Unter anderem findet der JSP Container auf diese Weise zu jedem
Custom Tag den entsprechende Tag Handler. Für jeden Tag Handler werden darüber hinaus
Informationen über Parameter verwaltet.
Für jede Webanwendung existiert ein so genannter Deployment Descriptor. Dies ist ebenfalls
eine XML Datei, in welcher Konfigurationen für die Webanwendung vorgenommen werden
können. Damit der JSP Container weiß, wo er einen neuen Tag Library Descriptor und somit
auch die damit verbundenen Custom Tags findet, wird ihm über die XML Datei der Ort der
TLD-Datei mitgeteilt.
Nach der Erstellung einer Tag Library können die Custom Tags auf einer JSP Seite benutzt
werden. Mittels einer taglib-Direktive wird dem JSP Container mitgeteilt, welche Tag Library
auf der Seite verwendet wird, und mit welchem Präfix die einzelnen Custom Tags dieser Tag
Library aufgerufen werden können. Die Tag Library Technologie ersetzt also nicht die JSP
Technologie. Vielmehr wird die JSP Technologie um einen eleganten Mechanismus zur
Trennung von Layout und Code bereichert.
2.4 Integration von Anwendungssystemen
2.4.1 Definition des Integrationsbegriffs
„Allgemein bezeichnet das Wort Integration die ‚Wiederherstellung eines Ganzen’ durch das
Verbinden oder Vereinigen logisch zusammengehörender Teile und beschreibt sowohl das
Bemühen, bisher getrennte Vorgänge oder Strukturen zusammenzuführen, als auch das
Ergebnis dieser Tätigkeiten.“47
Im Umfeld einer heterogenen, oft historisch gewachsenen Systemlandschaft, erscheint dieser
allgemeingültige Ausdruck der Wiederherstellung eines Ganzen zunächst nicht ganz sinnvoll.
Von Wiederherstellung kann streng genommen auch nicht die Rede sein, da die Heterogenität
der IT-Infrastruktur üblicherweise nicht aus ursprünglich einer Anwendung resultiert.
Besser ist in diesem Zusammenhang hier wohl die Definition durch Mertens (2000, S. 10),
nach der Integration in der Wirtschaftsinformatik als Verknüpfung von Menschen, Aufgaben
und Technik zu verstehen ist.
Im Kontext dieser Arbeit ist insbesondere der Integrationsgedanke der Technik, bzw. genauer
die Integration von Anwendungssystemen relevant. Anwendungssysteme sind Hard- und
47 Kaib 2002, S. 10
2 Grundbegriffe und thematische Abgrenzung
12
Softwaresysteme zur Automatisierung informationsverarbeitender Aufgaben.48 Es gilt hier,
unterschiedliche Anwendungssysteme so miteinander zu koppeln, dass ein Zugriff eines
Anwendungssystems auf ein Anderes stattfinden kann.
Im Folgenden werden die Begriffe Anwendungssystem sowie Anwendung (englisch
Application) synonym verwendet.
2.4.2 Integrationstypen
In der wissenschaftlichen Literatur über Integration im Kontext der Integration
innerbetrieblicher Unternehmensanwendungen, der Enterprise Application Integration, wird
hauptsächlich zwischen fünf verschiedenen Ausprägungen bzw. fünf unterschiedlichen Typen
der Integration unterschieden.49
Daten-Integration
Zunächst ist hier die reine Daten-orientierte Integration zu nennen. Hierbei handelt es sich um
das Extrahieren bzw. Auslesen der Daten eines Anwendungssystems50 und das Einfügen bzw.
Updaten dieser Daten in einem anderen Anwendungssystem.51
API-Integration
Bei der Application Interface-orientierten Integration greift ein Anwendungssystem auf die
sogenannte API, das Application Programming Interface, eines anderen Systems zu.52 Eine
API ist eine Schnittstelle, die ein Anwendungssystem anbietet, damit externe Anwendungen
über diese Schnittstelle mit der entsprechenden Anwendung kommunizieren können.53 Über
API´s können somit Funktionen eines Anwendungssystems für andere Systeme zugänglich
gemacht werden. Eine API definiert einen Satz von Schnittstellen inklusive der jeweiligen
Syntax und Semantik. Durch die Syntax einer speziellen Schnittstellendefinition wird
festgelegt, wie der jeweilige Funktionsaufruf insbesondere mit evtl. erforderlichen Parametern
und Rückgabetypen gestellt werden muss. Die Semantik einer Schnittstellendefinition gibt
Auskunft darüber, welchem Zweck die Schnittstelle dient. Linthicum (2001, S. 53) beschreibt
API´s als wohldefinierten Mechanismus, der es Entwicklern erlaubt, Services aufzurufen und
ein Ergebnis zurückzukommen.
48 Vgl. Fischer 1999, S. 8 49 Vgl. Linthicum 2001, S. 27 50 häufig handelt es sich in diesem Falle um Datenbanksysteme 51 Vgl. Linthicum 2001, S. 33 ff. 52 Vgl. Linthicum 2001, S. 52 ff. 53 Vgl. Rechenberg / Pomberger 1997, S. 553
2 Grundbegriffe und thematische Abgrenzung
13
Methoden-Integration
Bei einer Methoden-orientierten Integration wird die Geschäftslogik, die innerhalb einer
Unternehmung in Form von Programmcode existiert, allen Anwendungen, die entsprechende
Funktionalitäten benötigen, zur Verfügung gestellt.54
Portal-Integration
Bei einer Portal-orientierten Integration werden Anwendungen integriert, indem
Informationen von verschiedenen Anwendungen oder gar die Anwendungen selbst innerhalb
derselben Benutzeroberflache dargestellt werden.55 Dieser Integrationsansatz findet
insbesondere im Kontext des World Wide Web und der Benutzung von Webbrowsern
Verwendung.
Prozess-Integration
Zuletzt ist die Prozess-orientierte Integration zu nennen. Diese Integrationsvariante hat zum
Ziel, mehrere, logisch aufeinander folgende Geschäftsprozesse56, die allerdings getrennt auf
verschiedenen Anwendungssystemen ablaufen, so miteinander zu koppeln, dass ein
automatisierter Übergang von einem Geschäftsprozess auf einem Anwendungssystem zum
nächsten Geschäftsprozess auf demselben oder einem anderen Anwendungssystem erfolgen
kann.57
2.4.3 Integrationsziele
„Generelles Sachziel der betrieblichen IV ist es, zur Erreichung der strategischen
Unternehmensziele beizutragen. (…) Die Integration betrieblicher Anwendungen ist in
diesem Zusammenhang ein Formalziel, welches die Art und Weise konkretisiert, durch die
das Sachziel erreicht werden soll.“58 Nach Fischer (1999, S. 88) ist das Ziel der Integration
letztendlich, durch ganzheitliche, ungehinderte und inhaltlich konsistente Informationsflüsse
die Effektivität und Effizienz der Unternehmung zu steigern.
Von dieser wissenschaftlichen Definition des Ziels der Integration abweichend lassen sich
konkrete Nutzeffekte und somit Ziele der Integration in Kosteneffekte, Zeiteffekte und
54 Vgl. Linthicum 2001, S. 75 ff. 55 Vgl. Linthicum 2001, S. 91 ff. 56 Eine Definition des Begriffs Geschäftsprozess findet sich in Gadatsch 2001, S. 29 f. 57 Vgl. Linthicum 2001, S. 105 ff. 58 Vgl. Kaib 2002, S. 23
2 Grundbegriffe und thematische Abgrenzung
14
Qualitätseffekte unterteilen.59 So ist es beispielsweise möglich, die Kosten für die Erstellung
von Software zu verringern, indem erprobte Softwarekomponenten wiederverwendet werden.
Neben einer Senkung der Kosten kann dies mitunter auch zu einer Verbesserung der Qualität
führen.60 Darüber hinaus lassen sich durch die Integration von Anwendungssystemen die
positiven Eigenschaften unterschiedlicher Technologien kombinieren, um so Nutzeffekte
unterschiedlicher Art generieren zu können.
59 Vgl. Kaib 2002, S. 25 ff. 60 Vgl. Kaib 2002, S. 30
3 Konzeption des Vorgehensmodells
15
3 Konzeption des Vorgehensmodells
In diesem Kapitel wird ein Vorgehensmodell vorgestellt, anhand dessen Custom Tags
entwickelt werden können, um Groupware- und J2EE-Anwendungen zu integrieren.
Zunächst wird noch einmal kurz auf die Motivation eines Vorgehensmodells für dieses
Szenario eingegangen, sowie der Integrationstyp für das in dieser Arbeit relevante Szenario
herausgestellt. Nach Erläuterung einiger Voraussetzungen, die ein Entwickler erfüllen muss,
wird danach das Vorgehensmodell dargestellt und abschließend kritisch beurteilt.
3.1 Motivation und Abgrenzung des Integrationstyps
In Kapitel 2 wurden die unterschiedlichen Architekturen von Groupware und J2EE
dargestellt. Jede Architektur bringt gewisse Stärken und Schwächen mit sich. Während
Groupware insbesondere Vorteile im kollaborativen Umfeld besitzt, ist die J2EE Architektur
für sehr große Datenvolumina ausgelegt und für eine transaktionsorientierte Abwicklung von
Geschäftsprozessen geeignet. Durch die Integration lässt sich ein Synergieeffekt erreichen,
dem positive Eigenschaften beider Architekturen zugrunde liegen.61
Diese Arbeit basiert auf einem Szenario, in welchem von einer J2EE-Anwendung aus mittels
Custom Tags auf eine Groupware-Anwendung zugegriffen wird. Der Zugriff auf die
Groupware-Anwendung findet über die API des Groupwaresystems statt. Das
Groupwaresystem basiert auf einer wie in Kapitel 2.2 dargestellten Technologie bzw.
Architektur. Eine Groupware-Anwendung gilt im Folgenden als eigenständige Lösung, die
auf dem Groupwaresystem läuft. Der Zugriff auf die Groupware-Anwendung geschieht über
die API des Groupwaresystems.
Der Integrationstyp, dem dieses Szenario zu Grunde liegt, ist somit eine API-orientierte
Integration. Die J2EE-Anwendung greift mittels der API des Groupwaresystems auf eine
Groupware-Anwendung zu. Die entsprechende Anwendungslogik wird über Custom Tags
gekapselt. Die Entwicklung von Custom Tags erfordert ein geeignetes Vorgehensmodell,
welches in diesem Kapitel vorgestellt wird.
61 Vgl. Abschnitt 2.4.3
3 Konzeption des Vorgehensmodells
16
3.2 Voraussetzungen
Bevor auf das eigentliche Vorgehensmodell eingegangen wird, sollen im Folgenden die
notwendigen Voraussetzungen erläutert werden, die ein Entwickler erfüllen sollte und die
somit zur erfolgreichen Durchführung notwendig sind.
J2EE-Kenntnisse
Kenntnisse über die J2EE-Architektur sowie die Programmiersprache Java sind unabdingbar.
Dies umfasst insbesondere die Programmiersprache selbst sowie die Servlet- und JSP-
Technologie. Darüber hinaus ist ein Grundwissen über Webtechnologien und –Standards im
Zusammenhang mit der J2EE-Architektur notwendig.
Groupware-Kenntnisse
Auch wenn die eigentliche Custom Tag Entwicklung sich auf die J2EE-Seite konzentriert, ist
es sinnvoll, wenn der Entwickler ein grundlegendes Wissen über die Architektur des
entsprechenden Groupwaresystems sowie über die zu integrierende spezifische Groupware-
Applikation erworben hat. So können Logik-Fehler und Verständnis-Probleme vermieden
werden.
API-Kenntnisse
Neben einem grundlegenden Wissen über die Groupware-Architektur ist ein Verständnis der
spezifischen API eines Groupwaresystems absolut notwendig, da bei der Entwicklung von
Custom Tags auf diese API zurück- und zugegriffen wird.
3.3 Das Vorgehensmodell
Das Vorgehensmodell gliedert sich in insgesamt 6 aufeinander folgende Phasen, wie in
Abbildung 2 dargestellt wird.
Abbildung 2: Das Vorgehensmodell in Phasen
3 Konzeption des Vorgehensmodells
17
In den Folgenden Abschnitten werden die einzelnen Phasen des Vorgehensmodells
dargestellt. In einigen Phasen wird dabei explizit die Architektur von Groupwaresystemen
berücksichtigt.
3.3.1 Problembewusstsein schaffen
Analog zu anderen Vorgehensmodellen, gilt es zunächst herauszustellen, was durch eine
Integration einer Groupware-Applikation in eine bzw. mit einer J2EE-Anwendung erreichen
werden soll.62 Es stellt sich darüber hinaus auch die Frage, was die Anwendungsdomäne einer
integrierten, gemeinsamen Anwendung ist und was mit der Anwendung bezweckt wird.
Soll durch die Integration beispielsweise erreicht werden, dass die bestehende Groupware-
Anwendung um die Mächtigkeit einer J2EE basierten Lösung im Bezug auf Skalierbarkeit
oder Transaktionsunterstützung erweitert wird, oder ist es das Ziel, das eine J2EE-
Anwendung lediglich die Groupware-Anwendung als Persistenzebene, d. h. als Object Store63
bzw. Datencontainer benutzt? Wenn sich auch die Entwicklung bzw. das Ergebnis der
Custom Tags nicht besonders unterscheiden wird, ist diese Überlegung dennoch wichtig.
Dient die Groupware bzw. die Groupware-Applikation nur noch als Datencontainer ohne jede
eigene Anwendungslogik, beispielsweise weil eine Groupware-Anwendung auf der J2EE-
Architektur neu entwickelt wurde, bleibt zu hinterfragen, ob nicht auch die Daten auf eine
relationales Datenbank portiert werden sollten. Wenn sich das Datenmodell einer Groupware-
Anwendung nicht oder nur schwer portieren ließe, so kann in dem Fall, dass die Groupware
als reiner Datencontainer benutzt wird, zumindest davon ausgegangen werden, dass keinerlei
Gefahr besteht, dass ein gleichzeitiger Zugriff auf die Daten durch die Groupware-
Applikation und die J2EE-Applikation stattfindet. Eine mögliche Transaktionsunterstützung
der J2EE-Applikation wird dadurch nicht unterlaufen.
3.3.2 Technische Machbarkeit analysieren
Nachdem die Anwendungsdomäne spezifiziert und das Problembewusstsein geschärft ist, gilt
es im nächsten Schritt, Möglichkeiten der technischen Realisierung zu erfassen. In einer
ersten Überlegung bzw. Analyse ist das Ziel, herauszufinden, ob bereits eine entsprechende
Lösung evtl. sogar in Form einer Tag Library existiert, welche für die eigenen Zwecke
hinreichend geeignet ist. Dies ist insbesondere unter dem Aspekt der Wiederverwendung des
Codes bei der Entwicklung von Tag Libraries bzw. einzelnen Custom Tags interessant und
wird daher in Abschnitt 3.3.5 noch einmal von einem anderen Blickwinkel aus betrachtet.
62 Vgl. Frick / Marré 1995, S. 43 ff. 63 Vgl. Kapitel 2.2.2
3 Konzeption des Vorgehensmodells
18
Wenn bisher keine geeignete Lösung existiert, gilt es in einem nächsten Schritt zu
analysieren, in wie weit die Groupware eine API mitsamt einer Dokumentation zur
Verfügung stellt und wie diese API zu nutzen ist. Nur wenn das Groupwaresystem von außen
„offen“ ist, ist eine Integration, wie sie in Kapitel 3.1 dargestellt wurde, überhaupt möglich.
Darüber hinaus muss festgestellt werden, über welche Kommunikationsprotokolle die API
anzusprechen ist und wie ein Nachrichtenaustausch mit anderen Systemen durch die
Architektur des Groupwaresystems unterstützt wird.
Neben der API ist es selbstverständlich wichtig, sich die spezifische Architektur eines
Groupwaresystems vor Augen zu führen. Wie in Kapitel 2.2.2 dargestellt, findet die
Datenhaltung bei der Groupware in einem so genannten Object Store statt. Der Zugriff auf die
Datenhaltungsebene eines Groupwaresystems erfolgt über die in dem Object Store
verwalteten Dokumente. Es reicht allerdings nicht, sich nur mit dem Datenmodell des
Groupwaresystems auseinander zusetzen. Vielmehr ist es ebenso notwendig, das spezifische
Datenmodell der Groupware-Anwendung, die das Ziel einer Integration darstellt, zu kennen.
Neben einem Verständnis über das Datenmodell des Groupwaresystems und der
entsprechenden Anwendung ist ebenso ein Bewusstsein über deren Sicherheitskonzepte und
Zugriffsmodelle unabdingbar. Es muss geklärt werden, wie sich ein externes System bei dem
Groupwaresystem und der Anwendung authentifizieren und autorisieren kann und wie diese
„Anmeldung“ programmiertechnisch am besten zu lösen ist.
3.3.3 Nutzwert von Custom Tags evaluieren
Als Vorteile von Tag Libraries bzw. Custom Tags gilt die Möglichkeit der Trennung von
Layout und Logik und die sich daraus ergebende Möglichkeit der Wiederverwendung des
entwickelten Codes für mehrere JSP-Seiten oder gar mehrere Anwendungen. Gerade deshalb
sollte allerdings hinterfragt werden, ob eine Tag Library bzw. ein einzelner Custom Tag zur
Lösung eines Integrationsszenarios von Groupware- und J2EE-Applikationen überhaupt
geeignet ist. Wenn das Ziel die Trennung von Layout und Logik ist, kann dies ggf. auch
mittels JavaBeans oder einer Enterprise JavaBeans erreicht werden. Eine Entwicklung einer
Tag Library und der damit verbundene Mehraufwand macht somit nur Sinn, wenn aufgrund
des Einsatzgebietes des Tags eine häufige Wiederverwendbarkeit gefordert ist.64 Darüber
hinaus gilt es auch die Nachteile eines Custom Tags zu berücksichtigen.65 So wirkt sich
beispielsweise eine Tag Library grundsätzlich erst einmal negativ auf die Performance einer
Webanwendung aus. Dies führt zwar in den meisten Fällen zu keiner messbaren bzw.
64 Vgl. Brown et al. 2001, S. 289 65 Vgl. Brown et al. 2001, S. 286 ff.
3 Konzeption des Vorgehensmodells
19
bemerkbaren Beeinträchtigung, jedoch sollte bei performance-kritischen Anwendungen diese
Auswirkung dennoch Berücksichtigung finden.
3.3.4 Entwicklung der Tag Library
Die eigentliche Entwicklung einer Tag Library umfasst mehrere Schritte.66 Für eine
ausführliche Darstellung der einzelnen Schritte wird auf die einschlägige Literatur
verwiesen.67
1. Erstellung einer Tag Handler Klasse
2. Erstellung eines Tag Library Descriptors
3. Anpassung des Deployment Descriptors
4. Benutzung der Custom Tags innerhalb der JSP-Seite
3.3.5 Organisationsweites Publizieren der Tag Library
Wie bereits mehrfach erwähnt, ist ein wesentlicher Vorteil von Tag Libraries die Trennung
von Layout und Anwendungslogik. Damit einhergehend ist es möglich, die Webanwendungs-
Entwicklung in unterschiedliche Rollen aufzuteilen. Auf der einen Seite gibt es den
Entwickler, welcher dafür zuständig ist, die Tag Library zu erstellen. Auf der anderen Seite
gibt es den Webdesigner, der vor allem für das grafische Design einzelner Webseiten der
Anwendung verantwortlich ist und die Tag Library des Entwicklers nutzt. Nun mag es bei
kleinen Anwendungen kein Problem derart geben, dass der Webdesigner nicht weiß, welche
Tag Libraries er auf seinen JSP-Seiten mit welchen Custom Tags nutzen kann. Für große,
komplexe Anwendungen, insbesondere aber auch anwendungsübergreifend, ist es jedoch
notwendig, dass ein organisationsweites Publizieren aller Tag Libraries stattfindet, so dass
alle Webdesigner, aber auch die Entwickler, wissen, welche Tag Libraries unternehmensweit
mit welchen Funktionalitäten existieren und wie dies Tag Libraries zu benutzen sind. Eine
Wiederverwendbarkeit kann nur möglich sein, wenn entsprechende Mitarbeiter darüber
informiert sind, welche einsatzbereiten Softwarekomponenten, in diesem Fall Tag Libraries,
in der Organisation existieren.
3.3.6 Integration in Entwicklungsumgebung
Webanwendungen werden heutzutage kaum noch mit einem einfachen Editor erstellt. Es
existieren integrierte Entwicklungsumgebungen, die sowohl einem Webdesigner als auch
66 Vgl. 2.3.3 67 Vgl. z. B. Brown et al. 2001, S. 270 ff.
3 Konzeption des Vorgehensmodells
20
einem Entwickler einen großen Teil der Arbeit, beispielsweise durch Codegeneratoren oder
aber auch die Möglichkeit des Debugging, abnehmen. Aufbauend auf der Idee des
organisationsweiten Publizierens ist es erstrebenswert, zu untersuchen, ob die Möglichkeit
besteht, neu entwickelte Tag Libraries in die eingesetzte Entwicklungsumgebung zu
integrieren. Webdesigner können so beispielsweise per „Drag and Drop“ oder zumindest über
Menübefehle bestehende Tag Libraries auf einfache Weise benutzen. Dies wäre sicherlich
nicht zuletzt unter dem Gesichtspunkt einer einfachen Wiederverwendbarkeit von Vorteil.
3.4 Beurteilung des Vorgehensmodells
Das vorgestellte Vorgehensmodell ist ein Leitfaden zur Entwicklung von Custom Tags, die
zur Integration von Groupware- in J2EE-Applikationen eingesetzt werden können. Wert
wurde insbesondere auf eine Beurteilung des Nutzens einer Tag Library gelegt. Dadurch wird
betont, dass es notwendig ist, die Entwicklung einer Tag Library grundlegend zu planen und
nicht sofort mit dem eigentlichen Programmieren zu beginnen. Ungenügende oder zu
spezielle Tag Libraries werden nicht oder nur selten wiederverwendet.
Das Vorgehensmodell wurde bewusst relativ technologie-neutral gehalten. So wird nur an
wenigen Stellen konkret eine Groupware-Applikation genannt. Dadurch ist es nicht nur
beschränkt auf ein Groupware-J2EE-Szenario, sondern in einem beliebigen J2EE-basierten
Szenario verwendbar. Wenn sich die spezifischen Charakteristiken und Merkmale einer
Groupware-Architektur auch von einer anderen Anwendung bzw. Architektur eines anderen
Systems unterscheiden, so findet letztendlich eine Integration auf Anwendungsebene statt und
an dieser Stelle unterscheidet sich eine Groupware-Applikation nur unwesentlich von einer
anderen Anwendung.
In diesem Vorgehensmodell werden die Aufgaben jeder einzelnen Phase klar dargestellt. Ein
Nachteil dieses Vorgehensmodells es jedoch, dass keinerlei konkret überprüfbare Kriterien
gegeben werden, an denen sich das Ergebnis jeder einzelnen Phase hätte messen können. So
ist es mit dem Modell beispielsweise nicht möglich, den Nutzwert einer Tag Library
rechnerisch exakt zu ermitteln und so eine Entscheidung für eine mögliche Entwicklung
treffen zu können. Ein derartiger Ansatz in diesem Vorgehensmodell wäre sicherlich von
Vorteil gewesen, hätte aber auch den Rahmen und die Größe dieser Arbeit weit überschritten.
4 Anwendung des Vorgehensmodells
21
4 Anwendung des Vorgehensmodells
In diesem Kapitel wird die Anwendung des Vorgehensmodells anhand einer prototypischen
Entwicklung eines Custom Tags näher erläutert. Dazu wird zunächst die gewählte
Systemumgebung beschrieben. Nach einer kurzen Spezifikation der Anforderungen an den zu
entwickelnden Prototyp erfolgt die Darstellung der Anwendung des Vorgehensmodells.
4.1 Systemumgebung
Im Folgenden soll kurz die Systemumgebung, wie sie für eine prototypische Anwendung des
Vorgehensmodells zur Verfügung stand, beschrieben werden.
Als Groupwaresystem dient ein Lotus Domino Server in der Version 6.0.3 der Firma IBM.68
Als J2EE Application Server dient ebenfalls ein Produkt der Firma IBM, der WebSphere
Application Server in der Version 5.0. Dieser ist sowohl als eigenständiges Produkt in
unterschiedlichen Varianten verfügbar, sowie als Testumgebung in der
Entwicklungsumgebung WebSphere Studio Application Developer integriert.69 Für die
prototypische Entwicklung werden die Entwicklungsumgebung und die integrierte
Testumgebung des J2EE Servers verwendet.
Die Entscheidung zur Auswahl der beiden Produkte begründet sich zum einen durch die
Marktführerschaft beider Systeme in ihren jeweiligen Einsatzgebieten sowie zum anderen
dadurch, dass beide Produkte technologisch ausgereift sind und den aktuellen Stand der
Technik repräsentieren.
Als zu integrierende Groupware-Anwendung wurde eine kleine Datenbank, welche auf dem
Domino Server läuft gewählt. Diese Datenbank basiert auf der Datenbankschablone mit dem
Namen „Discussion – Notes & Web (6)“ und dient als Diskussionsforum. Diese Schablone
wird zusammen mit dem Produkt Lotus Domino Server ausgeliefert.
Die Datenbank wurde geringfügig angepasst und in dieses Diskussionsforum sind bereits
einige Diskussionsbeiträge eingestellt worden.
4.2 Anforderungsdefinition des Prototyps
Die Datenbank auf dem Domino-Server stellt ein Diskussionsforum dar. Die einzelnen
Beiträge dieses Diskussionsforums sollen über eine J2EE-Anwendung mittels eines Custom
Tags auf einer JSP-Seite aufgelistet werden. Die Diskussionsbeiträge sollen stets in Ihrem
68 Informationen dazu unter http://www.lotus.com/ (Stand: 15.11.2003) 69 Informationen dazu unter http://www.ibm.com/websphere/ (Stand: 15.11.2003)
4 Anwendung des Vorgehensmodells
22
vollständigen Diskussionsthread angezeigt werden. Dabei soll zwischen drei Möglichkeiten
unterschieden werden:
� Alphabetisch sortiert nach dem Titel der Hauptdiskussionsthemen.
� Sortiert nach dem Datum der Erstellung der Hauptdiskussionsthemen. Der neueste
Diskussionsthread steht somit an oberster Stelle.
� Sortiert nach dem Datum der Erstellung aller Diskussionsbeiträge. Der
Diskussionsthread, welcher den neuesten Beitrag im ganzen Diskussionsforum
enthält, steht somit an oberster Stelle.
Aufgrund einer nur prototypischen Entwicklung wird auf eine detaillierte
Anforderungsspezifikation verzichtet.
4.3 Erstellung eines Custom Tags anhand des Vorgehensmodells
Im Folgenden werden die einzelnen Phasen des Vorgehensmodells bei der prototypischen
Entwicklung betrachtet.
4.3.1 Problembewusstsein schaffen
In dem Szenario wird der Einfachheit halber angenommen, dass keine gleichzeitigen Zugriffe
auf die Datenbank von unterschiedlichen Anwendungen stattfinden. Somit entfällt eine
Implementierung eines geeigneten Mechanismus zur Synchronisation parallel durchgeführter
Transaktionen. Ziel ist es lediglich, das Diskussionsforum auf J2EE-Seite zur Darstellung
abzubilden.
4.3.2 Technische Realisierungsmöglichkeiten analysieren
IBM stellt bereits zwei Tag Libraries zur Verfügung, die für die Kommunikation mit dem
Groupwaresystem Lotus Notes vorgesehen sind.70 Eine Tag Library, die „Domtags“ Tag
Library, enthält eine Vielzahl an „Collaboration Tags“ zum Zugriff auf die
unterschiedlichsten Objekte des Groupwaresystems. Die zweite Tag Library namens
„Domutil“ enthält nützliche Tags, mit denen beispielsweise if- oder while-Anweisungen
ausgeführt werden können und die für viele J2EE Web Container einsetzbar sind.
Auch wenn die Domtags Tag Library bereits Tags enthält, mittels denen Dokumente
unterschiedlich aufgelistet werden können, so ist es mit ihnen jedoch nicht möglich, auf das
70 Nähere Informationen finden sich in der Lotus Domino Designer 6 Hilfe, die mit dem Groupwaresystem ausgeliefert wird.
4 Anwendung des Vorgehensmodells
23
Diskussionsforum so zuzugreifen, dass der Diskussionsthread mit dem neuesten Beitrag an
obererster Stelle angezeigt wird. Aus diesem Grund scheidet eine Benutzung der vorhandenen
Tag Libraries aus.
Somit ist eine Eigenentwicklung einer Tag Library umzusetzen. Bereits die Existenz der
Domtags Tag Library lässt dabei darauf schließen, dass das Groupwaresystem Lotus Notes
eine Möglichkeit der Kommunikation mit anderen Anwendungen über ein API anbietet. Die
Kommunikation mit dem Domino Server findet über das Internet Inter-Orb Protocol71 (IIOP)
statt.72 IBM stellt dazu eine Java-Bibliothek zur Verfügung, die sich auf dem Application
Server befinden muss. Der Aufruf von Methoden der Groupware-API in der Tag Library wird
zunächst über diese Bibliothek abgewickelt. Diese Bibliothek kommuniziert ihrerseits mittels
IIOP mit dem Groupwaresystem und somit auch mit der Groupware-Anwendung.
Die API stellt ebenfalls entsprechende Methoden zur Authentifzierung und Autorisierung
einer J2EE-Anwendung gegenüber dem Domino Server zur Verfügung. Diese sind auf die
Mechanismen zur Zugriffskontrolle und zum Zugriffsschutz des Domino Servers abgestimmt.
4.3.3 Nutzwert von Custom Tags evaluieren
Nach der Analyse der technischen Realisierung, gilt es abzuschätzen, ob überhaupt eine
Entwicklung einer Tag Library mit Custom Tags sinnvoll ist. Der wesentliche Vorteil, der den
Mehraufwand der Erstellung einer Tag Library rechtfertigt, ist die Wiederverwendbarkeit der
einzelnen Custom Tags auf verschiedenen Seiten für verschiedene Anwendungen.
In Bezug auf die Anforderungsspezifikation aus Kapitel 4.2 macht hier eine Entwicklung von
Custom Tags durchaus Sinn. Ein möglicher Einsatz der zu erstellenden Tag Library
beschränkt sich nicht nur auf die Diskussions-Datenbank. Die Custom Tags können durchaus
auch innerhalb anderer J2EE Anwendungen zur Integration anderer Lotus Notes Datenbanken
verwendet werden, sofern die entsprechende Anzeige der Daten von Interesse ist.
Darüber hinaus ist die Anforderung einer Darstellung „Sortiert nach dem Datum der
Erstellung aller Diskussionsbeiträge“ überhaupt erst durch die Integration einer J2EE-
Applikation mit Lotus Notes / Domino lösbar, wodurch der Nutzen einer Integration – ob mit
oder ohne Tag Library – unbestreitbar ist.
4.3.4 Entwicklung der Tag Library
Auf die Darstellung der Entwicklung der Tag Library soll im Rahmen dieser Arbeit nicht
näher eingegangen werden, da das Vorgehen, wie auch in 3.3.4 dargestellt, keine großen
71 Siehe http://www.omg.org/technology/documents/formal/corba_iiop.htm (Stand: 10.11.2003) 72 Vgl. Lotus Domino Designer 6 Hilfe sowie Nielsen et al. 2001, S. 28
4 Anwendung des Vorgehensmodells
24
Besonderheiten für die Integration von J2EE- und Groupware-basierten Applikationen
aufweißt.
4.3.5 Organisationsweites Publizieren der Tag Library
Ein organisationsweites Publizieren der Tag Library ist aufgrund der nur prototypischen
Entwicklung zur Demonstration des Vorgehensmodells nicht durchführbar. Dies schließt
jedoch nicht aus, dass die Veröffentlichung eines „Benutzerhandbuchs“ zu einer Tag Library
nicht von Interesse ist und hierfür ggf. geeignete Werkzeuge und Richtlinien bereitgestellt
werden sollten.
4.3.6 Integration in Entwicklungsumgebung
Eine Tag Library wird mittels einer taglib-Direktive auf einer JSP Seite eingebettet.
Die Entwicklungsumgebung WebSphere Studio Application Developer bietet generell nach
Einbettung einer taglib-Direktive die menügestützte Verwendung einzelner Custom Tags an
und unterstützt die Eingabe der Parameter von Custom Tags.
Darüber hinaus erlaubt es der WebSphere Studio Application Developer eigene Plug-In´s zu
erstellen.73 Es ist vorstellbar, dass sich durch die Entwicklung und den Einsatz von Plug-In´s
selbstentwickelte Tag Libraries effizienter in der Entwicklungsumgebung nutzen lassen.
Eine weitergehende Evaluierung der Integration von selbst entwickelten Tag Libraries in eine
Entwicklungsumgebung hätte den Rahmen dieser Arbeit überschritten. Ein derartiger Schritt
mag allerdings in einem Szenario mit mehreren Entwicklern und mehreren Tag Libraries
durchaus sinnvoll sein. Eine Entwicklungsumgebung, welche Unterstützung bei der Nutzung
von Custom Tags beispielsweise über Menüeinträge und Hilfestellungen zur Benutzung gibt,
kann die Entwicklung komplexer Anwendungen nur positiv beeinflussen.
73 Siehe dazu die Hilfe des WebSphere Application Studio Developer, Abschnitt Plug-In-Entwicklungsumgebung
5 Zusammenfassung und Ausblick
25
5 Zusammenfassung und Ausblick
Das Ziel der Arbeit war die Konzeption eines generischen Vorgehensmodells zur
Entwicklung von JSP Custom Tags im Umfeld der Integration von Groupware- und J2EE-
basierten Applikationen. Ein derartiges Modell wurde im Rahmen dieser Arbeit vorgestellt
und prototypisch innerhalb einer Domino/WebSphere-Umgebung angewendet. Auch wenn
dabei nicht alle Schritte bzw. Phasen, wie sie in Abschnitt 3.3 dargestellt wurden, ausführlich
Verwendung finden konnten, lies sich doch eine Entwicklung anhand des Vorgehensmodells
durchführen. Kritisch wurde bereits angemerkt, dass bisher keine konkret überprüfbaren
Kriterien für das Ergebnis jeder einzelnen Phase des Vorgehensmodells existieren.
Insbesondere für die Evaluation des Nutzwertes einer Tag Library bzw. von Custom Tags
erscheint ein derartiges messbares und überprüfbares Kriterium jedoch äußerst interessant, da
in dieser Phase maßgeblich über die Entwicklung einer Tag Library entschieden wird.
Allein schon die Motivation und die damit verbundene Notwendigkeit eines
Vorgehensmodells lassen vermuten, dass in absehbarer Zeit die Integration von J2EE und
Groupware, insbesondere in einem Domino/WebSphere-Szenario, ein hochaktuelles Thema
sein wird. Webanwendungen auf Basis der J2EE-Architektur werden auch in Zukunft eine
wichtige Rolle spielen, da sich diese Plattform für komplexe Anwendungen bewährt hat, auch
wenn neue Technologien wie beispielsweise die .NET-Architektur von Microsoft74 als
Konkurrenz am Markt auftreten. Die Idee bestehende Anwendungen beispielsweise auf Basis
eines Groupwaresystems in diese webzentrierte Welt zu integrieren, ist daher wohl nur eine
logische Folge. Aktuell erscheinen insbesondere Portallösungen, die ähnliche und
weiterführende Ansätze zur Integration von Domino und WebSphere verfolgen.75 Custom
Tag Libraries sind somit nur ein Baustein in einer Welt von integrieren
Anwendungssystemen. Aus diesem Grunde erscheint es sinnvoll, das entwickelte
Vorgehensmodell um weitere Konzepte der J2EE-Entwicklung zu erweitern oder in ein
ganzheitliches Vorgehensmodell zur Integration von Groupware- und J2EE-basierten
Applikationen zu integrieren.
74 Siehe dazu http://www.microsoft.com/net/ (Stand: 29.11.2003) 75 Vgl. dazu Tulisalo et al. 2003
6 Literaturverzeichnis
26
6 Literaturverzeichnis
Balzert 1999 Balzert, Helmut: Lehrbuch Grundlagen der Informatik : Konzepte,
Notationen in UML, Java, C++, Algorithmik und Softwaretechnik.
Heidelberg : Spektrum Verlag, 1999
Bien 2001 Bien, Adam: Enterprise Java Frameworks : Das Zusammenspiel der
Java-Architekturen. München [u. a.] : Addison-Wesley, 2001
Bodoff et al. 2002 Bodoff Stephanie et. al.: The J2EE™ Tutorial. 1. Auflage, Boston :
Addison-Wesley, 2002
Brown et al. 2001 Brown, Simon et. al.: Professional JSP, 2nd Edition. Birmingham :
Wrox Press, 2001
Dierker / Sander 1999 Dierker, Markus; Sander, Martin: Lotus Notes 4.6 und Domino :
Integration von Groupware und Internet. Bonn : Addison-Wesley,
1999
Fischer 1999 Fischer, Joachim: Informationswirtschaft : Anwendungsmanagement.
München : Oldenbourg, 1999
Frick / Marré 1995 Frick, Andreas; Marré Roland: Der Software-Entwicklungsprozess –
Ganzheitliche Sicht : Grundlagen zu Entwicklungs-Prozeß-Modellen.
München : Hanser, 1995
Gadatsch 2001 Gadatsch, Andreas: Management von Geschäftsprozessen :
Methoden und Werkzeuge für die IT-Praxis: Eine Einführung für
Studenten und Praktiker. 1. Auflage, Braunschweig : Vieweg, 2001
Ghezzi et al. 1991 Ghezzi, Carlo; Jazayeri, Mehdi; Mandrioli, Dino: Fundamentals of
Software Engineering. Englewood Cliffs, New Jersey : Prentice-Hall,
1991
Heilmann 1989 Heilmann, Heidi: Integration: Ein zentraler Begriff der
Wirtschaftsinformatik im Wandel der Zeit. In: Theorie und Praxis der
Wirtschaftsinformatik (HMD), Nr. 150, 1989, Bd. 26, S. 46-58
J2EE Specification Java™ 2 Platform, Enterprise Edition (J2EE™) Specification,
Version 1.4, Proposed Final Draft 3, Santa Clara : Sun, 2003
http://java.sun.com/j2ee/
6 Literaturverzeichnis
27
Kaib 2002 Kaib, Michael: Enterprise Application Integration : Grundlagen,
Integrationsprodukte, Anwendungsbesipiele.1. Auflage,
Wiesbaden : Deutscher Universitäts-Verlag, 2002
Linthicum 2001 Linthicum, David S.: B2B Application Integration : e-Business-
Enable Your Enterprise. 2. Auflage, Boston : Addison-Wesley, 2001
Lotus Development
1995
Lotus Development o.V.: Groupware - Communication,
Collaboration, Coordination. Cambridge, Massachusetts : Lotus
Development Corporation (Hrsg.), 1995
Mertens 2000 Mertens, Peter: Integrierte Informationsverarbeitung 1 :
Administrations- und Dispositionssysteme in der Industrie.
12. Auflage, Wiesbaden : Gabler, 2000
Nielsen et al. 2001 Nielsen, Soren Peter et al.: Domino and WebSphere Together Second
Edition. 2. Auflage, New York : IBM, 2001
Rechenberg /
Pomberger 1997
Rechenberg, Peter; Pomberger, Gustav et al.: Informatik-Handbuch.
München : Carl Hanser Verlag, 1997
Riggert 2000 Riggert, Wolfgang: Betriebliche Informationskonzepte : Von
Hypertext zu Groupware. 2. Auflage, Braunschweig : Vieweg, 2000
Takagiwa et al. 2001 Takagiwa, Osamu et al.: Programming J2EE APIs with WebSphere
Advanced. 1. Auflage, San Jose : IBM, 2001
Teufel et al. 1995 Teufel, Stefanie et al.: Computerunterstützung für die Gruppenarbeit.
Bonn : Addison-Wesley, 1995
Tulisalo et al. 2003 Tulisalo et al.: Portalizing Domino Applications for WebSphere
Portal. 1. Auflage, New York : IBM, 2003
Turau et al. 2001 Turau, Volker; Saleck, Krister; Schmidt Marc: JavaServer Pages und
J2EE : unternehmensweite Web-basierte Anwendungen. 1. Auflage,
Heidelberg : dpunkt.verlag, 2001
Recommended