In  nh ha al lt ts sv ve er rz ze ei ic ch hn ni is s  I

1.  Einleitung  7

1.1.  Motivation.  7

1.2.  Ziel der Arbeit.  7

1.3.  Kapitelübersicht.  8

2.  Die Applikation „handyEngine“  9

2.1.  Umfeld und Intention  9

2.2.  Funktionsumfang  11

2.2.1.  Nutzer - Interface  11

2.2.2.  Admin - Interface  14

3.  XML und Substandards  16

3.1.  Ziele und Begriffe  16

3.1.1.  Entwicklung  16

3.1.2.  Ziele von XML.  17

3.1.3.  wellformed XML.  18

3.1.4.  valid XML  19

3.1.5.  Namespaces  20

3.2.  Dokumenttypdefinition.  21

3.2.1.  DTD  21

3.2.2.  XML Schema  21

3.3.  Parser  23

3.3.1.  Begriffsdefinition  23

3.3.2.  SAX.  24

3.3.3.  DOM.  25

3.3.4.  Einbindung.  26

3.4.  XPath  28

3.5.  XSL.  30

3.5.1.  Transformations  30

3.5.2.  Formatting Objects  34

4.  Architektur von Webapplikationen.  36

4.1.  Evolution  36

4.2.  n-Tier Konzeption  41

4.2.1.  Einordnung  41

4.2.2.  Data- / Backend Tier  42

4.2.3.  Application Server Tier.  43

4.2.4.  Presentation Layer  45

4.3.  Model - View - Controller  48

5.  Implementierung der Applikation „handyEngine“  50

5.1.  Vorbemerkungen.  50

5.1.1.  Abgrenzung  50

5.1.2.  Runtime Environment  50

5.2.  Design.  52

5.2.1.  Model  52

5.2.2.  Controller.  53

5.2.3.  View  56

5.3.  Projektstatus.  60

Seite  2 von  73

6.  Ausblick.  62

6.1.  WebServices  62

6.1.1.  Herausforderung  62

6.1.2.  SOAP  64

6.1.3.  WSDL.  65

6.1.4.  UDDI  66

6.1.5.  Schlussfolgerung  66

6.2.  komponentenbasierte Frameworks  67

6.2.1.  J2EE  67

6.2.2.  NET  68

6.2.3.  SunONE  69

7.  Schlussbetrachtung.  70

Literaturverzeichnis   71

Anhang   72

Erkl  ärung  73

Seite  3 von  73

Ve  er rz ze ei ic ch hn ni is s d de er r A Ab bb bi il ld du un ng ge en n  

Abbildung  1: Komponentendiagramm EHB  

Abbildung  2: Screenshot handyEngine Startseite  

Abbildung  3: Screenshots handyEngine Funktionsseiten  

Abbildung  4: Sequenzdiagramm Modellreferenzierung  

Abbildung  5: Screenshot handyEngine-Admin Interface.  

Abbildung  6: Aufbau eines XML Dokuments  

Abbildung  7: SAX Parser-Events  

Abbildung  8: Aufbau eines DOM  

Abbildung  9: Syntax eines XPath-Ausdrucks  

Abbildung  10: XSLT Einsatzbeispiele.  

Abbildung  11: Beispiel einer XSLT - Transformation  

Abbildung  12: XSL Spezifikationen.  

Abbildung  13: Architektur eines XSL Prozessors.  

Abbildung  14: Ablauf eines XSL:FO Renderings  

Abbildung  15: Prinzip der CGI Programmierung  

Abbildung  16: fastCGI Einbindung  

Abbildung  17: Architektur der Servlet-Schnittstelle  

Abbildung  18: 3-tier Konzeption  

Abbildung  19: Die Rolle des Application Server.  

Abbildung  20: Komposition eines Presentation Layers  

Abbildung  21: Anforderungen an clientbasierte Technologien  

Abbildung  22: MVC - Desing Pattern.  

Abbildung  23: Anwendungsfalldiagramm handyEngine.  

Abbildung  24: Klassendiagramm Datenbeans.  

Abbildung  25: Klassendiagramm Controller  

Abbildung  26: Sequenzdiagramm Referenzierung  

Abbildung  27: verteilte Anwendung.  

Abbildung  28: Aufbau einer SOAP Message  

Abbildung  29: Einsatz von UDDI.  

Abbildung  30: Architektur des NET Frameworks  

Abbildung  31: Bestandteile des SunONE Frameworks  

Seite  4 von  

Ve er rz ze ei ic ch hn ni is s d de er r A Ab bk kü ür rz zu un ng ge en n V

ANSI American National Standards Institute API Application Programming Interface ASP Active Server Pages CGI Common Gateway Interface cHTML compact HTML CORBA Common Request Broker Architecture CSS Cascading Style Sheet DCOM Distributes Component Object Model DHTML Dynamic HTML DOM Document Object Model DSSSL Style Semantics and Specification Language DTD Document Type Definition EHB Elektronisches Handbuch EJB Enterprise JavaBeans GIF Graphical Interchange Format GML Generalized Markup Language GUI Graphical User Interface HTML Hypertext Markup Language HTTP Hypertext Transport Protocol IDL Interface Definition Language IE Internet Explorer IIOP Internet Inter ORB Protocol IIS Internet Information Server ISO International Organization for Standardisation IT Information Technology J2EE Java 2 Enterprise Edition J2SE Java 2 Standard Edition J2ME Java 2 Micro Edition JAXP Java API for XML Processing JDBC Java Database Connectivity JSP Java Server Pages JVM Java Virtual Maschine

Seite 5 von 73

KDE K Desktop Environment MVC Model - View - Controller NS Netscape OMG Open Management Group ORB Object Request Broker PERL Practical Extraction and Report Language PDF Portable Document Format PHP PHP: Hypertext Preprocessor RAD Rapid Application Development RPC Remote Procedure Call SAX Simple API for XML SVG Scalable Vector Graphics TCP / IP Transmission Control Protocol / Internet Protocol RFC Request For Comment RMI Remote Method Invocation SGML Standard Generalized Markup Language UML Unified Modeling Language URL Unified Ressource Locator W3C World Wide Web Consortium WML Wireless Markup Language XHTML Extensible Hypertext Markup Language XML Extensible Markup Language XSL Extensible Stylesheet Language XSLT Extensible Stylesheet Language Transformation XSL:FO Extensible Stylesheet Language Formatting Objects

Seite 6 von 73

1. . E Ei in nl le ei it tu un ng g 1

1. .1 1. . M Mo ot ti iv va at ti io on n 1

Am 15.11.2001 wurde der Mikroprozessor 30 Jahre alt ¹ und am 13.01.2001 das World Wide Web 10 Jahre ² . Betrachtet man rückblickend die exponentielle Entwicklung, die dieses Medium in der relativ kurzen Zeit sowohl quantitativ als auch qualitativ genommen hat, kann man eine Vorstellung davon entwickeln, welche Entwicklungssprünge wir in Zukunft erleben werden. Allein im Jahr 2001 wurden 195 RFC veröffentlicht ³ , die die Entwicklung von Webanwendungen direkt oder indirekt beeinflussen. Diese Situation ist freilich nicht ungewöhnlich, zumal im IT - Bereich. In ihrer Massivität stellt die Entwicklung jedoch eine neue Qualität dar, der mit adäquaten Methoden begegnet werden muss. Das der präferierte Ansatz zur Beherrschung der Situation selbst ein Standard ist, erscheint nur auf den ersten Blick seltsam: XML ist mit dem Anspruch entwickelt worden, als eine Art Metastandard zunächst die Syntax zu vereinheitlichen. Das dieses Ziel auf den ersten Blick eher bescheiden ausfällt, darf dessen enormen Nutzen nicht marginalisieren.

Trotz der Bemühung einer Vereinheitlichung ist vor allem im Onlinebereich eine stetige Zunahme der Komplexität von Anwendungen zu verzeichnen, zumal auch ein Metastandard wie XML implementiert und beherrscht werden muss. Dies ist vor allem der vielerorts angestrebten vollständig browserbasierten Bedienung von Unternehmensanwendungen zuzuschreiben.

1. .2 2. . Z Zi ie el l d de er r A Ar rb be ei it t 1

Dabei kommt wirkt sich positiv aus, dass alle eingesetzten Standards nicht im luftleeren Raum entwickelt wurden, sondern immer ein dediziertes Problem adressieren und damit quasi einen „best practice“ - Ansatz für ihren Einsatz mitliefern. Diesen an einem konkreten Beispiel zu verdeutlichen soll Ziel der vorliegenden Arbeit sein. Einzelne Technologien und Konzepte sollen gezielt

¹ http://www.heise.de/newsticker/data/ciw-15.11.01-001/default.shtml

² http://www.heise.de/newsticker/data/fr-13.01.01-001/default.shtml

³ http://www.ietf.org/iesg/1rfc_index.txt Seite 7 von 73

herausgegriffen werden um ihre Bedeutung innerhalb des „big picture“ darzustellen.

1. .3 3. . K Ka ap pi it te el lü üb be er rs si ic ch ht t 1

Da in der Darstellung immer wieder auf die Referenzapplikation „handyEngine“ zurückgegriffen werden wird, dient es der Verständlichkeit, eine kurze Einführung in diese Anwendung an den Anfang zu stellen. Kapitel 2 beschreibt deshalb das Userinterface für Administratoren und Nutzer.

Die in diesem Szenario verwendeten Technologien XML und Web Development werden in den beiden folgenden Kapiteln 3 und 4 fundiert dargestellt und erläutert. Der Schwerpunkt liegt dabei immer auf den Aspekten, die im Beispiel zum Tragen kommen. Die Metasprache XML wird dabei im Bottom - Up - Prinzip erläutert, d.h. zunächst werden elementare Regeln eingefügt um darauf aufbauend fortgeschrittenere Anwendungen wie XSL darzustellen. Der Themenkomplex Web Development im Kapitel 4 wird zunächst historisch betrachtet, da sich viele Gründe für die aktuellen Architekturprinzipien aus Erfahrungen in der Vergangenheit ableiten. Im Anschluss wird das MVC -Paradigma vorgestellt, welches heute als dominierendes Architekturprinzip gilt. Im Kapitel 5 wird auf Basis der zuvor eingeführten Technologien und Paradigmen das anfangs eingeführte Beispiel im Detail beschrieben und dabei insbesondere auf die Verbindung von Theorie und Praxis abgestellt.

Im letzten Kapitel werden aktuelle Entwicklungen und Frameworks vorgestellt, die die Art und Weise der Entwicklung von Applikationen im Umfeld des Internets erheblich verändern werden. Hier soll vor allem deutlich werden, dass die vorliegende Arbeit lediglich ein Schnappschuss des gegenwärtigen Stands der Technik in einem sich permanent weiterentwickelnden Umfeld ist.

2. . D Di ie e A Ap pp pl li ik ka at ti io on n „ „h ha an nd dy yE En ng gi in ne e“ “ 2

2. .1 1. . U Um mf fe el ld d u un nd d I In nt te en nt ti io on n 2

Das Mobilfunkunternehmen ePlus betreibt im Rahmen des Customer Relationship Managements eine Telefonhotline als 1st Level Support. Um die Kundenzufriedenheit auf einem hohen Niveau zu halten, ist es für die Hotline Agents essentiell schnell und umfassend zu allen Fragen der Kunden Auskunft erteilen zu können. Nicht nur die, zum Teil sehr komplexen, Vertragsarten und rechtlichen Rahmenbedingungen müssen jedem Agent bekannt sein, sondern auch aktuelle Informationen wie zum Beispiel Netzstörungen oder Aktionen des Kampagnenmanagements.

Neben der intensiven Schulung aller Call Center Mitarbeiter werden diese durch das Informationsportal „EHB“ bei Ihrer täglichen Arbeit unterstützt. Dieses bietet direkten Zugriff auf rund 8000 Seiten redaktionell bearbeiteter Texte und Grafiken. Zur Pflege dieses Pools unterhält ePlus ein etwa 20 Personen starkes Team technischer Redakteure, die, jeweils mit eigenem Kompetenzbereich, Fakten sammeln und aufbereiten.

Zur optimalen Unterstützung dieses Teams wurde ein leistungsfähiges Content Management System entwickelt, das durch die konsequente Trennung von Inhalt und Layout, die medienunabhängige Erstellung von so genannten „InfoObjekten“ in einem Repository erlaubt und Workflowfunktionen für deren Pflege bereitstellt.

Abbildung 1: Komponentendiagramm EHB

Seite 9 von 73

„Kanalredakteure“ nutzen die so verfügbaren Inhalte um damit beispielsweise Webseiten mit einheitlichem Layout zu publizieren. Einer der so versorgten Kanäle ist das, vor allem in den Call Centern genutzte, „elektronische Handbuch (EHB)“. Ein großer Teil der von den Call Centern bearbeiteten Kontakte lässt sich dem Themenkomplex Mobiltelefonauswahl und -benutzung zuordnen. Insbesondere Schwierigkeiten bei der Bedienung der Geräte nehmen einen wichtigen Platz ein und fordern die Mitarbeiter der Hotline besonders, da sich die Zahl der von ePlus vertriebenen Modelle auf inzwischen nahezu 100 summiert hat. Die redaktionelle Betreuung dieses Bereichs wurde bisher von 2 technischen Redakteuren übernommen, die über die spezifischen Kompetenzen verfügen. Die Publikation erfolgte im Rahmen des „EHB“. Da die Strukturierung der Inhalte - in diesem Fall vor allem Bedienungsanleitungen - für jedes Telefon ähnlich erfolgt, ergeben sich perpetuierte Arbeitsabläufe bei der Pflege von Ablagestrukturen im Repository sowie der Komposition von Webseiten. Eine weitergehende Unterstützung durch das System stellt also ein offensichtliches Rationalisierungspotenzial dar. Wird dieses genutzt, kann sich der Redakteur seiner eigentlichen Aufgabe widmen. Neben den Vorteilen, die eine gesonderte Berücksichtigung des Bereichs „Mobiltelefone“ für den Redakteur mit sich bringt, kann auch der Leser von einem angepassten Layout profitieren. Die bisherige Lösung im Rahmen des „EHB“ erlaubt zwar die Nutzung spezifischer Templates, kann jedoch lediglich eine eindimensionale Navigation in Form der hierarchischen Kategorisierung von Webseiten bieten da es sich hier um eine contentunabhängige Universallösung handelt. Insbesondere inhaltliche Faktoren, wie zum Beispiel technische Daten können für Orientierungsfunktionen nicht genutzt werden.

Motiviert durch diese, für alle Seiten unbefriedigende, Situation wurde eine Vision entwickelt, die zwei Ziele definiert:

− Masterstruktur: uniforme Inhalte sollen nur einmal strukturiert werden müssen − spezialisiertes Interface: contentbasierte Funktionalität generiert Mehrwert

Die Aufgabe umfasst also eine vollständig vertikal integrierte Lösung, die vom Zugriff auf das Repository über die Aufbereitung der Inhalte bis zur Bereitstellung erweiterter Suchfunktionen alle Aspekte einer webbasierten Applikation tangiert.

2. .2 2. . F Fu un nk kt ti io on ns su um mf fa an ng g 2

2.2.1. Nutzer - Interface

Da es in der täglichen Praxis des Call Centers meist um Fragen zu bereits verkauften Mobiltelefonen geht, steht der schnelle Zugriff auf ein bekanntes Modell im Vordergrund. Das Layout der Anwendung trägt dem Rechnung, indem sichergestellt ist, dass jedes Modell mit maximal 2 Nutzeraktionen erreichbar ist.

Abbildung 2: Screenshot handyEngine Startseite

Grundsätzlich gliedert sich das Interface dazu in 2 Bereiche, die als HTML Frames implementiert wurden. Der obere Frame erlaubt den Zugriff auf die Hauptfunktionen „Übersicht“, „Berater“ und „Vergleich“ sowie einen Schnellzugriff mittels Auswahl von Hersteller und Modellname (optional). Dieser Frame bleibt in jeder Situation unverändert, so dass dem Nutzer immer die Möglichkeit bleibt, zur Ausgangssituation zurückzukehren. Der untere Frame bietet Platz um die Ein- und Ausgaben der jeweiligen Funktion darzustellen. So

können hier beispielsweise Suchergebnisse in Form von Thumbnails oder die Bedienungsanleitungen eines selektierten Modells eingeblendet werden. Bei Bedarf ist dieser Frame vertikal scrollbar. Grundsätzlich kann durch Klick auf ein Thumbnail immer zur Detailseite eines Modells gesprungen werden, um technische Daten und Bedienungsanleitungen abzurufen. Da als unternehmensweiter Standard Netscape Navigator 4.7x vorgegeben ist, wurde das Layout für diesen Browser optimiert, dabei jedoch auch die Darstellung in alternativen Browsern berücksichtigt.

Abbildung 3: Screenshots handyEngine Funktionsseiten

Als Mimimalanforderung können die Unterstützung von HTML 3.2 sowie von CSS 1 genannte werden. Sofern verfügbar, werden Javascript- und Cookie -Unterstützung genutzt, um Angaben im „Handyberater“ persistent beim Nutzer zu hinterlegen und ihm so eine erneute Eingabe bei wiederholtem Aufruf der Seite zu ersparen.

Die Steuerung der Anwendung erfolgt vollständig über URL - Parameter. Das heißt, alle Zustände in den einzelnen Frames können mittels spezifischer URLs reproduziert werden. Dies gilt auch für die komplexen Suchabfragen im

„Handyberater“. Dieser Umstand ermöglicht es dem Nutzer auch, einzelne Zustände als Link in seine „Bookmark“ - Liste aufzunehmen. Im folgenden sind die Hauptfunktionen kurz umrissen:

− Übersicht

im unteren Frame werden alle als „im Shop verfügbar“ gekennzeichneten Handymodelle als Thumbnails aufgeführt. − Berater

im unteren Frame wird eine detaillierte Parameterauswahl angezeigt, die es ermöglicht, spezialisierte Selektionen in der Modelldatenbank vorzunehmen. Das Ergebnis der Suche wird im Stil der Übersicht dargestellt. − Vergleich

im unteren Frame werden die Parameter von zwei Modellen tabellarisch gegenübergestellt. Die Auswahl der Modelle erfolgt im Stil des Schnellzugriffs − Schnellzugriff

im oberen Frame ermöglichen zwei Drop - Down - Listen die Auswahl von Hersteller und Modell. Nach erfolgter Selektion des Herstellers wird die Modellliste mit passenden Einträgen gefüllt. Der Klick auf „auswählen“ führt bei selektiertem Hersteller auf eine „Thumbnail“ - Übersicht der Modelle des jeweiligen Herstellers und bei bereits gewähltem Modell direkt zur Detailseite dieses Modells. − Details

Wurde auf einem der beschriebenen Wege ein Modell eindeutig selektiert, wird dieses mit Abbildung und technischen Daten im unteren Frame präsentiert. Am rechten Rand ist eine 2 - stufige hierarchische Mikronavigation verfügbar, die Bedienungsanleitungen thematisch sortiert anbietet.

Zusätzlich sind zur optimalen Unterstützung der Bedienungsanleitungen Macromedia Flash - Animationen implementiert. Da diese jedoch vom System, abgesehen von der Einbindung in die HTML - Seiten, wie gewöhnliche Abbildungen behandelt werden, sollen sie ihr nicht weiter betrachtet werden. Sowohl Seiten mit statischem als auch solche mit dynamischen Inhalten sind das Ergebnis von XSLT Transformationen und somit leicht modifizierbar.

2.2.2. Admin - Interface

Wie im Kapitel 2.1 bereits ausgeführt, lässt sich die vorgestellte Anwendung konzeptionell zwischen Repository und Client PC anordnen. Sie macht dem Client die Inhalte des Repositorys zugänglich indem sie diese mithilfe von Templates in ein sinnvolles Layout einpasst und weitere Funktionen zur Navigation hinzufügt. Es ist offensichtlich, dass in dieser Situation viele Funktionen parametrisiert sein müssen, um den langfristigen Betrieb gewährleisten zu können. Zu diesem Zweck wurde eine leistungsfähige Administrationskomponente entwickelt, mit der in erster Linie das Erscheinungsbild den aktuellen Gegebenheiten angepasst werden kann.

Im Wesentlichen sind hier die verfügbaren Modelle sowie das spezifische Layout inklusive der Gestaltungselemente, wie zum Beispiel die verwendeten Grafiken, zu nennen. Zusätzlich besteht die Möglichkeit, die in der Suche angebotenen Modellmerkmale in Schlagwortlisten zu pflegen.

Abbildung 4: Sequenzdiagramm Modellreferenzierung

Damit ein Modell in der Anwendung berücksichtigt wird, muss es dem System bekannt gemacht werden. Hierzu wird ein „InfoObjekt“ aus dem Repository referenziert. Dabei werden der Name des Modells, der Hersteller sowie die SAP -Materialnummer als eindeutiger Schlüssel übernommen. Diese Stammdaten

werden durch Bewegungsdaten, etwa die aktuelle Verfügbarkeit in den Shops, ergänzt. Der Anwendung ist das jeweilige Modell nun inklusive aller technischen Daten (aus dem referenzierten InfoObjekt) bekannt. Gegebenenfalls vorhandene Bedienungsanleitungen können nun mittels der, ebenfalls im Administrationstool hinterlegten, „Masterstruktur“ gefunden werden.

Diese Struktur definiert allgemeingültig die, für alle Modelle gleich strukturierte, Ablage von „InfoObjekten“ für Bedienungsanleitungen. Dazu wird für jeden Navigationseintrag in der Mikromavigation der „Handydetailseite“ der Ablagepfad zum korrespondierenden „InfoObjekt“ im Repository angegeben.

Zusätzlich besteht die Möglichkeit, jeder Handydetailseite ein Template zuzuordnen. Diese werden ebenfalls, zusammen mit dem Templates für Systemseiten, als XSLT - Dokumente im Administrationstool gepflegt.

Abbildung 5: Screenshot handyEngine-Admin Interface

Da als Application Server für die Gesamtanwendung Lotus Domino vorgegeben wurde, konnte bei der Implementierung des Administrationstools auf die RAD -Funktionen dieser Plattform zurückgegriffen werden, was den

Entwicklungsaufwand erheblich reduzierte.