Dankwort

Für die Betreuung während des Diplomsemesters sowie für die Bestimmung des Diplomthemas bedanke ich mich bei Herrn Prof. Dr. J. Dunkel.

Außerdem möchte ich mich bei Herrn Christian Geveke für die freigestellte Zeit in der dvg Hannover Datenverarbeitungsgesellschaft mbH und seiner Unterstützung zur Erstellung dieser Arbeit bedanken. Herrn Martin Grube danke ich für die nützlichen Ratschläge im Bereich der Unified Modelling Language (UML).

Weiterhin bedanke ich mich bei allen Freunden und Bekannten die mich bei der Erstellung dieser Arbeit tatkräftig unterstützt haben.

i

Die vorliegende Diplomarbeit wurde in der Zeit vom 06.05. - 05.08.2002 bei der dvg Hannover Datenverarbeitungsgesellschaft mbH, Laatzener Str.5, 30539 Hannover unter der Anleitung von Herrn Prof. Dr. J. Dunkel (Erstprüfer) und Herrn C. Geveke (Zweitprüfer) angefertigt.

Erklärung

Ich versichere hiermit, dass ich die vorliegende Arbeit selbstständig verfasst und keine anderen Quellen und Hilfsmittel als die angegebenen genutzt habe.

Ort, Datum Stefan Tantow

ii

Inhaltsverzeichnis

Abstract   1

Einleitung   2

Voraussetzungen   2

Einsatzort   2

Projekt  „Himalaya“  3

Ausgangssituation   4

I  Projektbeschreibung  5

I.1  Allgemeine Ziele des Projekts  7

I.2  Eigenschaften der Dokumentengenerierung  8

I.3  Zusätzliche Anforderungen  9

I.4  Lösungsansatz  9

I.5  Technische Umgebung  11

II  Server-Komponente zur Dokumentenerzeugung  12

II.1  Anforderungsanalyse  13

II.1.1  Use Cases  13

II.2  Analyse/Design  21

II.2.1  Fachlicher Überblick des Klassenmodells  21

II.2.2  Paketstruktur des Klassenmodells  23

II.2.3  Detailbeschreibung des Klassenmodells  25

II.2.4  Konfigurations- und Ablagemöglichkeiten  30

II.3  Implementierung  36

II.3.1  DocServiceWrapper  36

II.3.2  WLSInfos  36

II.3.3  Dispatcher  37

II.3.4  Form  41

iii

II.3.5 InternalForm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

II.3.6 FormVar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

II.3.7 RawData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

II.3.8 ValueData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

II.3.9 Jobparameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

II.3.10 FormService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

II.3.11 FormDescription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

II.3.12 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

II.3.13 Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

II.3.14 EngineMetaData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

II.3.15 XSLEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

II.3.16 GenEngine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

III Client-Komponente zur Eingabe des Dokumenteninhalts 54

III.1 Anforderungsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

III.1.1 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

III.2 Analyse/Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

III.2.1 Erweiterung der Paketstruktur . . . . . . . . . . . . . . . . . . . . . . . . . 58

III.2.2 Überblick des erweiterten Klassenmodells . . . . . . . . . . . . . . . . . . . 59

III.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

III.3.1 GUIDocserviceMain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

III.3.2 GUIGenericBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

III.3.3 Deployment des Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

IV Ablauf der Dokumentengenerierung 68

V Abschließende Bewertung 73

Quellenverzeichnis 78

iv

1 Abstract

Abstract

Die vorliegende Arbeit beschreibt und analysiert die Implementierung eines Dienstes zur dynamischen Dokumentengenerierung in der Programmiersprache Java. Für die Realisierung des Dienstes wird die Extensible Markup Language(XML) und die Extensible Stylesheet Language(XSL) in Verbindung mit dem Formatting Objects Standard genutzt. Die Dokumentengenerierung erfolgt, indem XML-Daten in ein vorher generiertes XSL-Formular integriert werden. Es wird anschließend ein darstellbares Format erzeugt, um das Ergebnis präsentieren zu können. Die Formate können individuell vom Nutzer des Dienstes (meist ein bestehendes Anwendungssystem) eingestellt bzw. konfiguriert werden. Ein weiterer wichtiger Aspekt ist die Erstellung der XSL-Formulare. Daher wird in dieser Arbeit auch ein Formulardesigner vorgestellt, mit dessen Hilfe der Nutzer ohne Programmierkenntnisse individuelle Formulare jeder Art generieren kann. Dabei spielt das Verwaltungsmanagement der Formulare sowie die Verarbeitung dieser durch den Server auch eine wichtige Rolle. Im zweiten Teil der Arbeit wird eine Demonstrationsanwendung zur Nutzung des Dienstes vorgestellt bzw. implementiert. Diese kann dem Designer der Formulare als Testwerkzeug dienen, um anwendungsindividuell generierte Formulare, die mit Daten gefüllt werden, auf Korrektheit zu prüfen. Mit Hilfe des Acrobat Readers c kann das Ergebnis betrachtet und ausgedruckt werden.

2 Einleitung

Einleitung

Voraussetzungen

Für das Verständnis der Diplomarbeit werden folgende Grundkenntnisse vorsausgesetzt: Beschreibungs-/Programmiersprachen :

Extensible Markup Language(XML), Extensible Stylesheet Language(XSL), Formatting Objects, Java Applikationsserver :

Java 2 Enterprise Edition (J2EE), Implementierung von Enterprise Java Beans (EJB) OO-Design :

Begriffe im Bereich der Unified Modelling Language (UML) z.B. Klassendiagramme, Use-Cases oder Sequenzdiagramme

Einsatzort

Diese Diplomarbeit entstand während des zweiten Praxissemesters bei der dvg Hannover Datenverarbeitungsgesellschaft mbH.

Nach eigenen Angaben: „Die dvg ist mit über 1.700 Mitarbeitern und Umsatzerlösen in Höhe von 403,3 Mio. Euro in 2001 führender Informationstechnologie - Dienstleister der deutschen Sparkas-senorganisation. Das Unternehmen mit Firmensitz in Hannover unterhält eines der größten Rechenzentren Europas.“

Das Rechenzentrum der dvg ist eines der modernsten Europas, wobei alle Abhebungen an den über 63.000 angeschlossenen Sparkassen-Geldautomaten in 12 Ländern direkt über den zentralen Netzknoten des Rechenzentrums in Hannover laufen. Zu den Tätigkeitsschwerpunkten gehören

• Entwicklung und Integration von Anwendungssystemen,

• Hard- und Software-Beratung,

• IT-Services und

• Rechenzentrumsbetrieb.

3 Einleitung

Projekt „Himalaya“

Im Projekt „Himalaya“ entwickelt die dvg Hannover Softwarebausteine zur Unterstützung von Vertriebsprozessen der Finanzdienstleistungsbranche auf Basis einer netzzentrierten Frontendarchitektur.

Zu den Softwarebausteinen gehören acht flexibel kombinierbare Teilprozesse:

• Geschäftsportfolio,

• Vertriebsunterstützendes Aufgaben- und Terminsystem (VAS),

• Database-Marketing,

• Beratungsbausteine,

• Teilerneuerung Kundensystem,

• Giro,

• Einlagenmanagement und

• Zahlungsverkehr

Für jeden Teilprozess müssen Geschäftsdokumente erzeugt werden.

Ziel des Konzepts ist es, ein hohes Qualitätsniveau des Dienstleistungsangebots zu gewährleisten und zugleich durch höhere Produktivität eine Verbesserung der Kostensituation zu erreichen. Die oben genannten Geschäftsvorfälle werden grundsätzlich fallabschließend bearbeitet. Die Navigation durch die Subprozesse eines Geschäftsvorfalls wird dabei über die „Himalaya“-Anwendung gesteuert.

Zu dieser modernen Technologie gehört die Anwendung und Nutzung von Applikationsserver im Rahmen der 3-Tier Architektur. Diese Architektur dient zur Trennung von Präsentation auf den Clients und den fachlichen Anwendungen auf dem Applikationsserver. Die juristischen Daten werden auf Hostsystemen gehalten.

4 Einleitung

Ausgangssituation

Dieser Diplomarbeit liegt folgende Ausgangssituation zugrunde:

Die Implementierung eines Dokumentengenerierungsdienstes in der Programmiersprache C++ ist bereits vorhanden und befindet sich bereits in der Pilotierung. Es werden zwei Systeme zur Dokumentengenerierung verwendet. Für institutsindividuelle und dynamische Formulare wird das Officepaket Applixware c genutzt. Die Verarbeitung von statischen Formularen z.B. Kredit-

formulare des Sparkassenverlages erfolgt über ein zusätzliches Dokumentenverarbeitungssystem. Das Textverarbeitungssystem vom Officepaket Applixware c dient dabei zum Formulardesign der

dynamischen Formulare. Die Integration der Inhaltsdaten in die Formulare zur Laufzeit erfolgt über die Makrosprache von Applix. Dabei werden einem Makro die Inhaltsdaten übergeben, welches diese dann in das entsprechende Formular einfügt. Als Ergebnis wird von Applix eine Datei im Postscript-Format zurückgeliefert. Da zur Darstellung der Acrobat Reader c verwendet werden soll,

ist hierfür eine Konvertierung von Postscript(Applix) nach PDF erforderlich. Diese Konvertierung erfolgt über Ghostscript. Das generierte PDF Dokument wird über das Acrobat Reader c -Plug-In

des Browsers angezeigt. Zu dem existieren eine Menge von Konvertiermodulen um unterschiedliche Dateiformate zu erzeugen.

Diese Lösung hat folgende Nachteile:

Die gesamte Ansteuerung des Servers funktioniert über Corba. Corba ist eine programmiersprachen-und plattformunabhängige Architektur für verteilte Objekte. Kernstück dieser Architektur ist der „Object Request Broker“ (ORB), der als Vermittlungszentrale zwischen den Objekten dient. Wie die Praxis (auch in der dvg) gezeigt hat, ist der Einsatz einer auf Corba-basierten Lösung aufgrund der hohen Komplexität des Systems mit hohen Wartungs- bzw. Administrationsaufwand verbunden. Unter anderem erhöht sich dadurch auch die Fehleranfälligkeit. Des Weiteren ergeben sich bei der geplanten Portierung nach Java folgende Problemstellungen:

Aus verschiedenen Gründen (z.B. Performance oder hardwarenahe Funktionen) können existierende C++ Bibliotheken nicht nach Java portiert werden oder sie sind nicht als Java Bibliotheken verfügbar. Beispielsweise ist die Verarbeitung von großen Bytestreams von zu konvertierenden Daten in C++ erheblich performanter. Dadurch müssen manche Funktionalitäten weiterhin in der Program- miersprache C++ genutzt werden.

5 KAPITEL I. PROJEKTBESCHREIBUNG

Kapitel I

Projektbeschreibung

Die Dokumentengenerierung für institutsindividuelle bzw. dynamischen Formulare der dvg wird mit dem Officepaket Applixware c durchgeführt. Applixware c ist vergleichbar mit Microsoft Office c

und stellt keine Ideallösung dar. Außerdem handelt es sich um keinen offenen Standard und wurde ursprünglich auch nicht als Dokumentengenerierer konzipiert. Durch die Applix-Makrosprache zur Dokumentenaufbereitung entstehen besonders bei großen Dokumentenmengen wesentliche Per-formancenachteile. Hinzu kommt das Applixware c zum Formulardesign nicht besonders benutzer-freundlich ist.

Neben Applixware c werden auch andere Dokumentengenerierer und Formatkonvertierer verwendet. Gleichzeitig ist geplant, das weitere derartige Module zukünftig ohne größere Aufwände dem Dokumentendienst hinzugefügt werden. Für die Realisierung wurde hierfür ein generischer Ansatz basierend auf konfigurierbaren modularen „Engines“ (Funktionseinheiten) gewählt. „Engines“ werden zur Laufzeit aus Metainformationen einer Konfigurationsdatei erzeugt. Diese Metainformationen beinhalten unter anderem die Ein- und Ausgabeformate und mögliche Aufrufe von externen Kom-mandos. Zusätzlich wurde auch ein Mechanismus implementiert, um mehrstufige „Engine“-Aufrufe für die Konvertierung von einem Eingabeformat in ein Ausgabeformat zu ermöglichen.

Beispiel: Konvertierung von ASCII nach PDF

Ein einfacher Text soll in das PDF-Format konvertiert werden. Da es keinen direkten Konverter gibt, werden zwei Konvertierungsstufen durchgeführt:

1. ASCII nach Postscript

2. Postscript nach PDF

Für die Diplomarbeit wird jedoch nur eine „Engine“ verwendet, da die Zielstellung die Untersuchung eines Dokumentengenerierers auf Basis von XML und XSL:FO ist.

6 KAPITEL I. PROJEKTBESCHREIBUNG

Erklärung der Begriffe zur Diplomarbeit:

Inhalt (Content)

Der Begriff „Inhalt“ ist wie folgt definiert:

Von unterschiedlichen Geschäftsprozessen (Anwendungssysteme) werden Daten verschiedener Arten an den Dokumentengenerierungsdienst übermittelt. Zu diesen Daten gehören:

• ASCII-Zeichenketten (Strings)

• Bytestreams (z.B. Bilder)

• dynamische Tabellen mit unterschiedlicher Zeilenlänge

Die jeweiligen fachlichen Anwendungen übergeben dabei Felddaten in Form von Text für Platzhaltervariablen, dynamische Tabellen oder Bytestreams.

Formular

Der Begriff „Formular“ ist wie folgt definiert: Ein Formular wird im Dokumentengenerierungsprozess mit Inhalt gefüllt. Es kann folgende Komponenten enthalten:

• statischen Text (z.B. Tabellenüberschriften, Anreden),

• kundenspezifische Inhalte (Logos, Textbausteine)

• sowie Platzhalter (Variablen) für Text, Bilder oder Tabellen

Die Formulare liegen in unterschiedlichen proprietären Formaten als Datei vor. Die Metadaten dieser Formulare werden über Repositorys verwaltet.

Jobparameter

Unter Jobparametern versteht man spezielle Parameter für einen bestimmten Dokumentengenerierungsprozess. Diese steuern das zu erzeugende Dokument indem folgende Parameter übergeben werden können:

• das Zielformat des zu generierenden Dokuments. Im Rahmen der Diplomarbeit ist dieses Format PDF.

• bei institutsindividuellen Formularen ein Institutsname (z.B. von einer Organisation). Dieser muss auch zusätzlich in einem Formularrepository angegeben werden.

7 KAPITEL I. PROJEKTBESCHREIBUNG

Dokument

Das Dokument ist als ein generiertes Ergebnis vom dynamischen Dokumentendienst definiert. Es beinhaltet die vom jeweiligen Anwendungssystem übermittelten Felddaten an den dafür vorgesehenen Platzhaltern (Variablen) des Formulars (siehe Begriffserklärung Formular). Das generierte Dokument liegt je nach gewünschtem Zielformat unter Berücksichtigung der Jobparameter als Ergebnis vor. Mit diesem Dokument kann die Anwendung eine Weiterverarbeitung durchführen (z.B. Speicherung in eine Datenbank oder Anzeige über den Acrobat Reader c ).

I.1 Allgemeine Ziele des Projekts

• Das Hauptziel ist die Bereitstellung eines Dokumentenverarbeitungssystems das die Funktionalitäten der beiden existierenden Dokumentenverarbeitungssysteme für statische und dynamische Formulare in sich vereint und zusätzlich die Performance verbessert wird.

• Des Weiteren soll die Benutzerfreundlichkeit des Formulardesigners erhöht werden.

• Ein bestehendes Anwendungssystem wird um die Funktionalität einer Dokumentengenerierung erweitert. Daher werden Daten aus den Anwendungen über den Dokumentendienst und ein dazugehöriges Formular zu einem Dokument verarbeitet und an die Anwendung zurückgegeben. Das Formular besitzt bestimmte Platzhalter, welche über den Dienst mit den Anwendungsdaten ersetzt werden.

• In dieser Arbeit soll der Mischvorgang der Inhaltsdaten in die Formulare über XML in Verbindung mit XSL-Formatting Objects erfolgen. Der Ablauf der Integration ist dabei wie folgt beschrieben:

Die übermittelten Daten aus den Anwendungen werden in das XML-Format transferiert und mit einem entsprechenden XSL:FO-Stylesheet (Formular) in ein XSL:FO-Dokument mit den XML- Datentransformiert. Anschließend erfolgt eine Vermischung der XML- bzw. XSL:FO-Daten und Konvertierung in ein darstellbares Format (z.B. PDF).

• Das Ergebnis soll ein Dokument sein, welches über ein Renderingprozess (Datenvermischung) eines Formatting Objects Processor (FOP) durchgeführt wird. Die Anwendung kann anschließend das generierte Dokument anzeigen.

• Außerdem soll eine benutzerfreundliche Schnittstelle für den Entwickler des bestehenden Anwendungssystems realisiert werden, damit dieser die anfallenden Daten dem Dienst übermitteln kann.

• Ein weiteres Ziel ist die Implementierung eines Demo-Clients, um vorhandene Formulare auf Fehler zu prüfen. Dieses geschieht, indem dynamische Eingabemasken für die Formularfelder zu bearbeiten sind, um anschließend das Ergebnis zu betrachten. Aus diesem Grund soll als weiteres Ziel die Demoapplikation eine Vorschaufunktion mit anschließender Druckmöglichkeit beinhalten.

Diese Anwendung sollte demnach auch benutzerfreundlich und ergonomisch dargestellt sein, damit auch ein Nicht-Programmierer z.B. der Formulardesigner diese Applikation bedienen kann.

8 KAPITEL I. PROJEKTBESCHREIBUNG

• Als letztes Ziel soll es die Möglichkeit der Erzeugung von Formularen im XSL-Kontext geben. Jeder Bediener muss ein XSL-Formular ohne Programmierkenntnisse erstellen können. Ein denkbarer Formulardesigner ist XSLFast von jCatalog c , welcher auch in dieser Arbeit untersucht und eingesetzt wird.

Mit diesem Tool kann eine Layout erzeugt werden, welches unter anderem statischen Text und Platzhalter für Text bzw. Bilder beinhalten kann.

Nach der Formularerstellung muss das Layout dem eigentlichen Dienst publiziert werden. Zu diesen Informationen gehören unter anderem ein eindeutiger symbolischer Formularname sowie der vollständige Pfad und Dateiname.

I.2 Eigenschaften der Dokumentengenerierung

Bei der dynamischen Dokumentengenerierung wird ein Dokument mit bestimmten dynamischen und statischen Inhalt erzeugt und in einem vorgegebenen Format abgelegt. Für den Dokumentengenerierungsprozess relevante Steuerungsinformationen, wie zum Beispiel das Zielformat, werden in Jobparametern hinterlegt. Um ein solches Dokument zu generieren werden Inhaltsdaten von geschäftsbezogenen Daten aus Anwendungssystemen mit einem dazugehörigen Formular vermischt. Anschließend wird das Dokument in einem angegebenen Format zurückgegeben.

Vereinfacht könnte folgende Formel aufgestellt werden, wobei das Formular mit den Inhaltsdaten zu einem Dokument vermischt wird:

Dokument = Formular + Inhaltsdaten(Felddaten)

9 KAPITEL I. PROJEKTBESCHREIBUNG

I.3 Zusätzliche Anforderungen

• Der Dokumentendienst soll keine fachlichen Abhängigkeiten zu den Anwendungen besitzen. Damit ist ein allgemeiner Einsatz durch Wiederverwendbarkeit der Quellcodes auch in anderen Projekten möglich.

• Die eigentliche Anwendung (Das Anwendungssystem, welche den Dokumentendienst aufruft) soll in ihrer Funktionsweise nicht beeinträchtigt werden, wenn der Dokumentendienst nicht verfügbar ist.

• Die Formulare sollen vom Dokumentengenerierungsdienst angesprochen werden, wobei diese in einem Formularrepository gehalten werden sollen. In diesem Repository sind jedoch nur die Metadaten zum Formular enthalten. Es soll erreicht werden, dass das Repository eine zentrale Konfigurationsdatei im XML-Format ist, aber die eigentlichen Formulare in einem bestimmten Formularpfad auf dem jeweiligen Dokumentengenerierungsdienst-Server verwaltet werden.

• Da die Formulare meist nicht direkt von einem Entwickler bzw. Programmierer generiert werden, sollte es eine zentrale Administration der Formulare geben.

Es muss somit die Möglichkeit bestehen, dass ein Formulardesigner die entwickelten Formulare auf einem Server hinterlegen kann, so dass diese sofort zur Verarbeitung von einem Anwendungssystem (Client) genutzt werden können.

I.4 Lösungsansatz

Die Diplomarbeit untersucht zwei verschiedene Anwendungen:

Der erste Teil der Diplomarbeit behandelt den Softwareentwicklungsprozess eines dynamischen Dokumentendienstservers. Dabei erfolgt die Dokumentengenerierung über den Formatting Objects Pro-cessor (FOP) in Verbindung mit Xalan von Apache c .

In der Arbeit wird nur auf das Ausgabeformat PDF eingegangen, da der Acrobat Reader c sich inzwischen auf dem Markt durchgesetzt hat und auf jedem Standardrechner installiert ist. Die gesamte Dokumentengenerierung erfolgt in einem Geschäftsprozess (Server-Komponente).

Im zweiten Teil der Diplomarbeit wird ein Demo-Client als Testwerkzeug für den Entwickler bzw. Formulardesigners implementiert (Client-Komponente).

10 KAPITEL I. PROJEKTBESCHREIBUNG

Server-Komponente

Da für einen Dokumentendienstserver eine zentrale Administrationsumgebung, Skalierbarkeit sowie Portierbarkeit wichtige Voraussetzungen sind, wird für die Diplomarbeit eine Applikationsserver-Lösung basierend auf dem J2EE-Standard verwendet.

Ein Server für die Dokumentengenerierung bietet vor allem Vorteile bei der Verwaltung von Formularen. Bei einer Nutzung des Dienstes ohne Server (Clientlösung), müssten alle Formulare auf das lokale Dateisystem vom Client transferiert werden, wobei ständig auf die Aktualität der Formulare zu achten ist.

Des Weiteren würde die gesamte Rechenzeit der Dokumentengenerierung auf dem Client geschehen. Dieses kann zu Einbußen der Performance führen. Durch diesen Performancedefizit können auch die eigentlichen Anwendungen betroffen sein, indem während des Dienstaufrufs diese in ihrer Funktionsweise beeinträchtigt werden.

Außerdem wird der Server von der Client-Komponente über eine EJB-Schnittstelle (Session Bean) angesprochen, so dass dem Client eine bedienerfreundliche Schnittstelle für die Dokumentengenerierung zur Verfügung steht. (siehe Abbildung I.1)

Client-Komponente

Die Client-Komponente ist als grafische Benutzeroberfläche (GUI) konzipiert und soll die Verbindung zur Server-Komponente veranschaulichen (Schnittstelle zum Server).

Um eine zentrale Verteilung (Deployment) der Clientapplikation zu ermöglichen, wird Java Web Start (JWS) von Sun in Verbindung mit einem Webserver (Apache) genutzt. Die eigentliche Clientapplikation wird mit Java-Swing-Elementen realisiert.