Integration von Groupware- und J2EE-basierten ...gcc.uni-paderborn.de/www/wi/wi2/wi2_lit.nsf/0... · Integration von Groupware- und J2EE-basierten Applikationen: Konzeption eines

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


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


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


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


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


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


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.)


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)


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


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


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


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


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


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


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


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


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.


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.


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


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)


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.


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


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


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/


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

Documents

Integration von Groupware- und J2EE-basierten ...gcc.uni-paderborn.de/www/wi/wi2/wi2_lit.nsf/0... · Integration von Groupware- und J2EE-basierten Applikationen: Konzeption eines