Flexibilität und Multichannel technische Herausforderungen an Multichannel Systeme

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Flexibilität und Multichannel technische Herausforderungen an Multichannel Systeme im Rahmen des Seminars Enterprise Architecture Management (EAM) Florian Baten Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Dipl. Wirt.-Inf. Christoph Lembeck Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Einführung Motivation Basistechnologien Trennung von Inhalt und Layout Kurzer Einblick in XML extensible Markup Language XML Parser Transformation von XML Dokumenten mit XSLT Multichannel-Systeme Was sind Multichannel-Systeme? Architektur von Multichannel-Systemen Tier Architektur Tier Architektur Beurteilung von Multichannel-Systemen Cocoon als Multichannel-Framework Was ist Cocoon? Architektur des Cocoon Frameworks Komponenten von Cocoon Beurteilung von Cocoon Zusammenfassung und Ausblick Anhang A: Durchführung einer Beispielinstallation Anhang B: Kommentierte Sitemap Anhang C: Beispiel für eine XSLT Transformation Literaturverzeichnis II

3 Kapitel 1: Einführung 1 Einführung 1.1 Motivation Mit der Entwicklung von EAI (Enterprise Application Integration) ist es gelungen, verschiedene bestehende Systeme in ein logisches Gesamtsystem zu integrieren. Eine Middleware steuert die Kommunikation zwischen den Systemen untereinander und stellt standardisierte Schnittstellen zur Außenwelt bereit. Die Aufbereitung der Informationen für die Anwender wird in der Regel von klassischen Web Applikationen im Rahmen eines Internet oder Intranet Portals vorgenommen. Da nach heutigem Stand für Web Anwendungen in der Regel 3-Tier Thin-Client Architekturen eingesetzt werden, ist bei einer Änderung der Informationsaufbereitung der Application-Tier betroffen, welcher Präsentationsschicht und Applikationsschicht beinhaltet. Besonders bei der Unterstützung von mobilen Endgeräten sind innerhalb der Präsentationsschicht viele Standards (z.b. chtml, ihtml, xhtml, WML) in teilweise unterschiedlichen Versionen zu berücksichtigen. So wird es durch neue Endgeräte nötig, die auf dem Applications-Tier laufenden Programmteile zu erweitern oder neue zu entwickeln. Neben Änderungen am Layout werden häufig auch unterschiedliche Anforderungen an Art und Umfang der Inhalte gestellt. Beim Web- Browsing werden bspw. viele Bilder und Animationen eingesetzt, die sich für das mobile Browsing nicht eignen, da hier im Allgemeinen mehr Wert auf komprimierte Inhalte gelegt wird. Die Lösung zu diesem Problem bieten Multichannel-Systeme, die mit Hilfe einer 4-Tier Architektur die Präsentationsschicht auf einem von der Applikationsschicht getrennten Tier auslagern. Erst im Presentation-Tier werden dann Inhalt und Layout bei der Antwortgenerierung zusammengeführt. Das Cocoon Framework stellt ein solches Multichannel-System dar. Es baut auf XML- Technologien wie z.b. XSLT auf, um die 4-Tier Architektur umsetzen zu können und somit die Trennung von Inhalt und Layout, bzw. Applikations- und Präsentationsschicht, zu erreichen. 3

4 Kapitel 2: Basistechnologien 2 Basistechnologien 2.1 Trennung von Inhalt und Layout In der klassischen Web Anwendung werden Inhalte statisch oder dynamisch als HTML Seiten auf Internet/Intranet-Portalen zur Verfügung gestellt. Bei dynamisch generierten Inhalten werden die Webseiten z.b. mit Hilfe von Java Server Pages (JSP), Java Servlets, Active Server Pages (ASP), PHP Code o.a. zur Laufzeit serverseitig erstellt. Der große Nachteil von Präsentationssprachen wie HTML ist die Vermischung von Layout und Inhalt. HTML ist zwar für den Menschen lesbar, doch eignet es sich nicht für den Datenaustausch zwischen Maschinen und nicht zur Präsentation von Inhalten, die für die Weiterverarbeitung bestimmt sind. Unter anderem für diesen Zweck wurde XML entwickelt. XML ist mittlerweile international etabliert und ermöglicht deshalb einen Datenaustausch auch über Unternehmensgrenzen hinaus. 2.2 Kurzer Einblick in XML extensible Markup Language Im Jahre 1996 wurde mit der Entwicklung von XML durch das World Wide Web Consortium (W3C) begonnen. Es hat sich unter anderem als universelles Datenaustauschformat im EAI Umfeld durchgesetzt. In diesem Bereich sind unterschiedlichste Systeme mit unterschiedlichen Datenformaten integriert. Mit XML als Datenaustauschformat muss nun nur noch festgelegt werden, wie Daten in XML überführt werden, bzw. von XML in ein anderes Format exportiert werden. Um dies zu erreichen ist es erforderlich, dass die XML-Dokumente wohlgeformt sind. Dabei handelt es sich um die allgemeine XML-Spezifikation, die eine grundlegende syntaktische Richtigkeit gewährleistet. Um eine weiterführende syntaktische und semantische Gültigkeit eines XML-Dokumentes sicherstellen zu können, wurde die Document Type Definition (DTD) entwickelt. DTDs sind Definitionen und dienen der Beschreibung von Dokumentklassen. DTDs sind selber keine wohlgeformten XML-Dateien, entsprechen also nicht der XML- Spezifikation. Sie haben den Nachteil, dass sie nur sehr allgemeine Datentypen unterstützen und aufgrund ihrer Syntax schwer zu lesen und zu verstehen sind. Da sie 4

5 Kapitel 2: Basistechnologien zudem keine Vererbung anbieten und keine Namensräume unterstützen, wurde im Mai 2001 vom W3C ein neuer Standard entwickelt, die XSD. [AB00 S.256f] Die XML Schema Definition (XSD) erlaubt die detaillierte Beschreibung von Datentypen und Attributen dadurch, dass die Datentypen der gängigen Programmiersprachen unterstützt werden. Mit XML Schema kann zum Beispiel festgelegt werden, ob ein Element nur Ganzzahl-, Wahrheits-, oder Fließkommawerte hat. Die genauere Beschreibung der Daten führt zu einem Mehraufwand bei der Schemaerstellung, der allerdings besonders dann gerechtfertigt wird, wenn das Schema für eine große Anzahl von Dokumenten verwendet wird. [W3C] 2.3 XML Parser Um XML-Dokumente zu verarbeiten, müssen diese von Programmen, so genannten Parsern, zunächst eingelesen werden. Nicht validierende Parser prüfen ein Dokument dabei lediglich auf Wohlgeformtheit, validierende Parser nutzen zudem eine DTD oder XSD, um die Gültigkeit eines Dokumentes sicherzustellen. [AB00 S.82, 256] Bei der Funktion von XML Parsern gibt es grundsätzlich zwei verschiedene Ansätze, baumorientierte und ereignisorientierte Parser. Document Object Model (DOM) ist eine Spezifikation zur Definition eines Application Programming Interface (API) für die Manipulation von XML-Dokumenten. Ein DOM- Parser liest immer ein komplettes XML-Dokument ein und erstellt daraus einen Objektbaum, bestehend aus Knoten und Blättern, der die Struktur des Dokumentes wiedergibt. [AB00 S.47,169] Bei der Entwicklung von Applikationen bietet DOM den Vorteil einer einfacheren Implementierung, da die gesamte Struktur eines Dokumentes gespeichert wird. Besonders die Navigation und Operationen zur Manipulation der Datei werden dadurch vereinfacht. Der Nachteil von DOM ist der zum Teil enorme Speicherbedarf bei größeren XML-Dokumenten. [LZ02 S.47] SAX (Simple API for XML) ist eine Spezifikation für ereignisgesteuerte Parser. Als eine Spontanentwicklung von vielen XML-Entwicklern und nicht offiziell vom W3C geschaffen, genießt SAX jedoch eine große Akzeptanz. Ein SAX-Parser erzeugt während der Abarbeitung einer XML-Datei verschiedene Arten von Ereignissen, die 5

6 Kapitel 2: Basistechnologien direkt verarbeitet werden können. Ein Ereignis entsteht, wenn z.b. ein Start- oder End- Tag erreicht wird. Aus dieser Funktionsweise resultiert bei größeren Dateien ein erheblicher Geschwindigkeitsvorteil gegenüber DOM, da nicht gewartet werden muss, bis das Dokument vollständig eingelesen ist. Da der Speicherverbrauch von SAX konstant ist, können sogar Dokumente beliebiger Größe verarbeitet werden. Nachteilig ist, dass die Programme, die einen SAX-Parser nutzen, die Navigation in einem Dokument übernehmen müssen und die Programmierung dadurch aufwändiger wird. Zudem gibt es Situationen, in denen nur DOM verwendet werden kann, z.b. wenn Dateien manipuliert werden sollen. Die meisten Parser sind JAXP (Java API for XML Processing) kompatibel, so dass sowohl DOM als auch SAX unterstützt wird. Dadurch können die Vorteile beider Varianten sinnvoll kombiniert werden. [LZ02 S.43-48] 2.4 Transformation von XML Dokumenten mit XSLT Das Format/Layout von XML-Dokumenten kann mit der Extensible Stylesheet Language (XSL) beschrieben werden. XSL-Transformations (XSLT) ist eine, in der XML-Spezifikation enthaltene, Transformationssprache und dient dazu, ein XML- Dokument von einem Format in ein anderes zu überführen oder für die Präsentation aufzubereiten (Rendern). Diese in XML entworfene Sprache soll es ermöglichen, aus beliebig strukturierten XML-Daten Output zu generieren, welcher der Webserver z.b. als (X)HTML-Seite anzeigt. Wie in Abb. 1 zu sehen, geschieht dies unter Verwendung eines XSL-Stylesheets. Im Anhang dieser Arbeit befindet sich ein einfaches Beispiel für eine solche Transformation. Abbildung 1: XSLT Transformation Mit XSL-FO (Formatting Objects), einem weiteren XML-Standard, ist es zudem möglich grafische Dateien in den Formaten SVG, TIFF, PS, PDF, etc. zu erstellen. 6

7 Kapitel 3: Multichannel-Systeme 3 Multichannel-Systeme 3.1 Was sind Multichannel-Systeme? In der Literatur werden zwei Arten von Multichannel-Systemen unterschieden. Bei den so genannten N:1-Multichannel-Systemen greifen verschiedene Frontanwendungen auf eine Kernanwendung zu, wie in Abb. 2 zu sehen ist. Ein Beispiel wäre, wenn der Kunde direkt über Internet auf das System zugreifen kann, oder indirekt über das Callcenter. Es ist denkbar, dass der Funktionsumfang für den Kunden über die Internetselbstbedienung nicht so umfangreich ist, wie über das Callcenter. Entscheidend ist, dass alle Kanäle immer die gleiche Kernanwendung im Back-Office nutzen und dabei grundsätzlich mit denselben Informationen versorgt werden. [Ke02 S.16] Abbildung 2: N:1 Multichannel Gibt es im Back-Office nicht nur eine Kernanwendung, sondern verschiedene Systeme auf mehreren Servern, wie in Abb. 3 dargestellt, so wird die Bezeichnung N:M- Multichannel verwendet. An dieser Stelle spielt das EAI-System eine große Rolle, welches in vielen Unternehmen bereits existiert, um die verschiedenen heterogenen Systeme miteinander zu kombinieren, denn bei einem N:M-Multichannel-System wird häufig die rechte Seite durch ein bestehendes EAI-System repräsentiert. Auf der anderen Seite, am Frontend des Multichannel-Systems, gibt es unterschiedliche Benutzergruppen. Nach denen muss das Multichannel-System differenzieren, da für jede Gruppe unterschiedliche Geschäftsfunktionalität bereitgestellt wird. Letzteres leistet das EAI-System, welches Workflows zur Verfügung stellt, Transaktionssicherheit für Frontanwendungen garantieren kann und bei Bedarf auch Rollbacks durchführt. 7

8 Kapitel 3: Multichannel-Systeme Abbildung 3: N:M Multichannel Langham und Ziegeler [LZ02] gehen bei Multichannel in erster Linie von Endgeräteunabhängigkeit aus. Das von ihnen beschriebene Szenario umfasst verschiedene Endgeräte, die auf eine Multichannel-fähige Middleware zugreifen, an die im Hintergrund unterschiedliche Backend-Systeme angeschlossen sind. Im weiteren Verlauf dieser Arbeit, deren Schwerpunkt nicht im EAI (Backend) Bereich liegen soll, wird diesem Ansatz gefolgt und damit der Schwerpunkt auf die Darstellung auf unterschiedlichen Endgeräten gelegt. 8

9 Kapitel 3: Multichannel-Systeme 3.2 Architektur von Multichannel-Systemen Nach dem im vorigen Kapitel definierten Schwerpunkt sollen Multichannel-Systeme abhängig vom Endgerät eines Benutzers auf Anfragen reagieren und nach Möglichkeit immer die gleichen Inhalte und Funktionen zur Verfügung stellen. Bei der Antwortgenerierung bedienen sich Multichannel-Systeme daher immer von den gleichen Inhalten, auch wenn diese dynamisch und endgeräteunabhängig generiert werden. Nur Layout und eventuell Logik, falls bestimmte Funktionen auf einem Endgerät nicht realisierbar sind, werden dementsprechend angepasst Tier Architektur Die heute sehr weit verbreiteten 3-Tier Architekturen (Abb. 4) zeichnen sich durch einen Application-Tier aus, in dem die Business-Logik implementiert ist. Die Präsentationsschicht kann auf Dienste der Applikationsschicht zugreifen, während die Applikationsschicht ihrerseits auf die Datenschicht zugreifen kann. Abbildung 4: 3-Tier Architektur Präsentationsschicht, Applikationsschicht und Datenzugriffsschicht können sich bspw. auf einem Web- oder Application-Server befinden. Da es sich bei Web-Anwendungen beim Client in der Regel um einen Thin-Client handelt, findet dort meist nur noch die Anzeige durch Rendering von z.b. HTML Seiten durch einen Internet Browser statt. Die Präsentationslogik befindet sich daher wie die Applikationslogik auf dem Application-Tier. Greifen nun verschiedenartige Clients auf den Server zu, gibt es zwei Möglichkeiten darauf zu reagieren. Einerseits kann man den kleinsten gemeinsamen Nenner aller Endgeräteeigenschaften herausfinden und eine Applikation so entwerfen, dass sie allen 9

10 Kapitel 3: Multichannel-Systeme Anforderungen gerecht wird. Das wird gemacht, wenn die Clients sich stark ähneln, wie z.b. bei verschiedenen HTML-Browsern. Dabei können kleine Unterschiede in Form von bedingten Anweisungen in der Implementierung berücksichtigt werden. Kommen mobile Endgeräte hinzu, werden die Kompromisse zu groß, so dass ein eigenes Modul (z.b. ein eigenes Servlet) implementiert werden muss. Dann leitet die Applikation in Abhängigkeit vom anfragenden Client, bzw. genauer, in Abhängigkeit vom User Agent 1 des Clients, die Anfrage an das passende Applikationsmodul weiter. Die Erweiterung, Änderung und Wartung solcher Applikationen durch die Berücksichtigung der verschiedenen neuen Fälle bzw. User Agents innerhalb der Präsentationsschicht wird im Laufe der Zeit immer aufwändiger. Die Ursache liegt darin, dass in dieser Architektur Inhalt und Layout, also Applikations- und Präsentationsschicht, logisch nicht voneinander getrennt werden. [Ar03 S.60f] Tier Architektur Die 4-Tier Architektur (Abb. 5) löst das Problem der Aufbereitung für unterschiedliche Endgeräte durch die klare, logische Trennung zwischen der Applikationsschicht und der Präsentationsschicht. Erst in der Präsentationsschicht werden dann die aus der Applikationsschicht eintreffenden (formatneutralen) Inhalte in ein passendes Ausgabeformat transformiert. Z.B. eine Transformation von XML in HTML mittels XSLT. Abbildung 5: 4-Tier Architektur 1 String, der den anfragenden Client genau identifiziert 10

11 Kapitel 3: Multichannel-Systeme Damit liegen die Daten weiterhin auf dem Datenbankserver und die Logik wird nach wie vor vom Application-Tier umgesetzt. Neu ist dabei, dass der Client nun nicht mehr mit dem Application-Tier kommuniziert, sondern mit dem Presentation-Tier, der die Aufgabe der grafischen Aufbereitung vom Application-Tier übernommen hat. [Ar03 S.60f] 3.3 Beurteilung von Multichannel-Systemen Nach Meinung Kellers ist es die Aufgabe von EAI-Technologien, bestehende DV- Systeme für Nachrichten aus dem Internet zugänglich zu machen. [Ke02 S.12] Außerdem empfiehlt Keller die Nutzung von XML, um eine Nachricht in mehreren unterschiedlichen Darstellungen anzeigen zu können. [Ke02 S.16-18] Multichannel-Systeme, die eine solche Technologie repräsentieren, tun genau das, indem sie die Frontend-Anbindung an ein EAI-System mittels einer 4-Tier Architektur effizient gestalten. Dann müssen dank der 4-Tier Architektur Änderungen bzw. Ergänzungen nur im Presentation-Tier vorgenommen werden, wenn z.b. neuen Endgeräten der Zugang zu dem bestehenden System ermöglicht werden soll. Dies ist möglich, da im Application- Tier, anders als in der 3-Tier Architektur, noch keine Layoutinformation zugefügt wurde. Multichannel-Systeme können somit eine ideale Ergänzung für EAI-Systeme sein, die eine flexible und vor allem zukunftsorientierte Frontend-Anbindung benötigen. 11

12 Kapitel 4: Cocoon als Multichannel-Framework 4 Cocoon als Multichannel-Framework 4.1 Was ist Cocoon? Cocoon ist ein leistungsfähiges Multichannel-Framework auf Basis von XML und ermöglicht die dynamische Generierung verschiedener Formate wie z.b. HTML, WML, PDF oder JPEG. Es wurde vom Italiener Stefano Mazzochi im Jahre 1999 entwickelt. Unter der Schirmherrschaft der Apache Software Foundation entstand bis 2001 die zweite Version des Open Source Projektes. Das in der Literatur auch als Publishing-Framework bezeichnete Cocoon stellt auf Java Servlets basierende Komponenten bereit und kann auf spezifikationskonformen Web Containern (Servlet Engine) auf Web- oder Application-Servern genutzt werden. Cocoon kann Inhalte, die im XML-Format vorliegen, in ein beliebiges Ausgabeformat transformieren und damit verschiedene Endgeräte bedienen. Überdies bietet das mächtige Framework die Möglichkeit, viele weitere Features im Bereich J2EE Applikationsentwicklung, im speziellen der XML-Verarbeitung zu nutzen. Das Cocoon Framework ist aktuell in der Version verfügbar. Eine Anleitung zur Installation und Konfiguration auf einem Apache Tomcat Web Container befindet sich im Anhang dieser Arbeit. 12

13 Kapitel 4: Cocoon als Multichannel-Framework 4.2 Architektur des Cocoon Frameworks Das Cocoon Framework basiert auf einer offenen, komponentenbasierten Architektur. Der Kern von Cocoon ermöglicht das Kompilieren, Laden und Ausführen von Programmen und enthält einige Basisklassen für die weiteren Komponenten, sowie für Caching, Logging, Threading, etc. Zu den weiteren Komponenten, die in den folgenden Abschnitten genauer erläutert werden, gehören Generatoren, Transformatoren, etc. Praktisch alle dieser Komponenten können durch andere ausgetauscht werden. Abbildung 6: Architektur des Cocoon Frameworks [AC] Mit Cocoon ausgelieferte Logicsheets ermöglichen den Aufbau eines einfachen Portals durch reine Konfiguration ohne, dass Programmierung nötig ist. Den äußeren Ring der Grafik bilden die spezifischen, selbst erstellten Komponenten um die das Framework nach Bedarf erweitert werden kann und die Inhalte, die präsentiert werden sollen. Cocoon has been designed to coexist and interoperate side-by-side with your existing J2EE solutions or to give them new functionality without requiring any change in the existing infrastructure. [AC] 13

14 Kapitel 4: Cocoon als Multichannel-Framework 4.3 Komponenten von Cocoon Die folgende Grafik (Abb. 7) zeigt am Beispiel eines HTML-Requests das Zusammenspiel der wichtigsten Komponenten von Cocoon. Dazu wird der Request eines Clients, in diesem Fall ein HTML-Browser von Cocoon verarbeitet. Die Sitemap wird von oben nach unten abgearbeitet, bis der Matcher einer Pipeline zutrifft. Dann wird die entsprechende Pipeline mit den darin beschriebenen Komponenten durchlaufen. Der Generator der Pipeline beginnt, indem aus einem XML-Dokument SAX-Ereignisse erzeugt werden. In dem XML-Dokument sind die für die angefragte Seite benötigten Inhalte hinterlegt. Die SAX-Ereignisse werden vom Transformer unter Zuhilfenahme eines Stylesheets von XML in XHTML umgewandelt, also mit Layoutinformationen versehen. Der Serializer wandelt die vom Transformer eintreffenden XML-konformen Ereignisse in das Ausgabeformat, in diesem Fall HTML, um und erstellt daraus eine zusammenhängende Datei, die an den Client übertragen wird. [LZ02 S.157f] Abbildung 7: eine einfache HTML Pipeline in Cocoon Die grundlegenden Eigenschaften der wichtigsten, von Cocoon verwendeten, Komponenten, sowie die Sitemap werden im Folgenden einzeln erläutert. Im Anhang befindet sich außerdem eine kommentierte Sitemap. Eine Pipeline beginnt immer mit einem Generator und wird durch einen Serializer abgeschlossen. Dazwischen können beliebig viele oder keine Transformatoren eingesetzt werden. Es kann innerhalb einer Pipeline auch mehrere Pfade geben und unterschiedliche Serializer können ein und dieselbe Pipeline beenden. 14

15 Kapitel 4: Cocoon als Multichannel-Framework Für den Fall dass Fehler auftreten, bietet Cocoon die Möglichkeit eines komfortablen Error-Handlings. Dazu können Fehler für ganze Pipelines oder auch nur für Teile davon abschnittweise abgefangen werden. Welche Pipeline einen Request beantwortet, wird mit einem Matcher entschieden. Sie sind der Schlüssel zu einer Pipeline und werden im Normalfall mit der URI, bzw. einem Teil davon verglichen. Es können aber auch andere Dinge, wie zum Beispiel die Systemzeit getestet werden. Sie sind mit einer If-Anweisung ohne Else-Zweig vergleichbar. Daher wird gerne am Ende in der Sitemap eine Pipeline mit einem Catch- All Matcher verwendet, um (durch die Hintertür) eine Art Else zu ermöglichen. Generatoren sind immer der Beginn einer Pipeline. Sie lesen ein Dokument ein und erzeugen daraus einen Strom aus SAX-Ereignissen, die dann entweder an einen Transformer oder an einen Serializer gesendet werden. Die Quelldokumente müssen nicht zwangsläufig im XML-Format vorliegen, denn es gibt Generatoren für viele Formate, wie z.b. HTML oder WML, die der Generator in einen XML-Datenstrom umwandelt. Cocoon nutzt Xerces 2, ein JAXP konformen Open Source XML-Parser von der Apache Software Foundation. Transformer konsumieren und produzieren SAX-Ereignisse. Diese optionale Komponente ermöglicht die Veränderung des XML-Datenstroms. So können nicht nur Elemente hinzugefügt und gelöscht werden, auch direkte Änderungen sind möglich. Bei der reinen Umwandlung von XML in andere Formate, wie HTML reicht ein einzelner Transformer in der Regel aus. Sind komplexere Transformationen nötig, z.b. bei der SQL Verarbeitung, werden oft mehrere Transformer in einer Pipeline hintereinander geschaltet. Einerseits liegt es daran, dass einige Transformationen auf die Ergebnisse einer anderen Transformation warten müssen, andererseits ist es sinnvoll, mehrere (kleinere) Transformationen vorzunehmen, da diese in anderen Pipelines wieder verwendet werden können. Ein Transformer reagiert in dem Fall nur auf die für ihn bestimmten Ereignisse und leitet alle anderen unbearbeitet weiter. Cocoon nutzt Xalan 3 als XSLT-Transformer ebenfalls ein JAXP konformes Programm. 2 ist der Name einer blauen Schmetterlingsart 3 ist der Name eines seltenen Musikinstruments 15

16 Kapitel 4: Cocoon als Multichannel-Framework Am Ende einer Pipeline verwandelt der Serializer den vom Generator oder Transformer kommenden XML-Datenstrom in ein Ausgabeformat, z.b. XHTML in HTML. In dem Fall gibt es für den Serializer wenig zu tun außer, einige XML-Tags zu verändern oder zu löschen. Wird jedoch PDF oder JPEG erzeugt, muss der Serializer mehr leisten. Jede Pipeline, die mit einem Generator begonnen wird, muss mit einem Serializer abgeschlossen werden, auch wenn ein XML-Dokument nicht verändert wurde. Sobald ein Serializer seine Arbeit aufnimmt, können keine weiteren Serializer mehr gestartet werden und auch die Sitemap wird nicht weiter abgearbeitet. Auf diese Weise wird sichergestellt, dass ein Client nicht versehentlich mehrere Antworten vom Server erhalten kann. [LZ02 S.87] Die Sitemap ist das Herzstück von Cocoon, ein XML-Dokument, in dem sämtliche Komponenten definiert werden und das Zusammenspiel dieser in den Pipelines beschrieben wird. Im Anhang befindet sich eine kommentierte Sitemap. Subsitemaps dienen der hierarchischen Kapselung und eignen sich gerade bei größeren Projekten, um nicht die Übersicht zu verlieren. Auch verschiedene Aufgabenbereiche können so einfach voneinander abgegrenzt werden. Die Referenzierung auf Subsitemaps funktioniert wie mapping anhand der URI. [LZ02 S.170f] Ein Selector wird innerhalb einer Pipeline eingesetzt, um boolesche Auswertungen durchzuführen. Das wichtigste Beispiel für einen Selector ist der Browser Selector, welcher in Abhängigkeit vom User Agent den Browsertyp und die Version ermittelt. Anhand dieser Information kann dann ein browserspezifisches Stylesheet für die Transformation ausgewählt und verwendet. Der Gegensatz zu einem Matcher, welcher mit einer if-anweisung vergleichbar ist, erlaubt ein Selector komplexere Auswertungen, vergleichbar mit einer CASE- Anweisung. Desweiteren dient die Unterscheidung der logischen Aufgabentrennung und einer besseren Übersicht. [LZ02 S.114f] Ein Reader fügt Daten ohne weitere Verarbeitungsschritte hinzu. Er ist dazu gedacht, Dateien, die sich bereits im gewünschten Ausgabeformat befinden, direkt an den Client zu senden, z.b. Grafik-, Multimedia- oder JavaScript-Dateien. Daher umgeht ein Reader das Pipeline-Prinzip, denn er stellt einen Generator und Serializer gleichzeitig. [LZ02 S.115] 16

17 Kapitel 4: Cocoon als Multichannel-Framework Actions erzeugen keine Ausgabe und nehmen nicht direkt an der XML-Verarbeitung teil. Sie sind für Hintergrundprozesse gedacht, wie die Cookie-Abfrage, Kommunikation mit einer Datenbank oder die Autorisierung eines Benutzers. Actions können auch den Fluss durch die Sitemap bestimmen. Eine nützliche Anwendung ist z.b. die Prüfung, ob eine angefragte Datei auf einem Server aktuell zur Verfügung steht, bevor mit der Verarbeitung begonnen wird. Mit Action-Sets können beliebig viele Actions miteinander kombiniert werden. [LZ02 S.115] Action-Sets werden wie alle anderen Komponenten zentral in der Sitemap definiert. Damit sind Fragmente leicht wieder verwendbar und die Wartbarkeit deutlich erhöht. [LZ02 S.163] Mit Extensible Server Pages (XSP) können Inhalte zur Laufzeit dynamisch erzeugt werden. Dies geschieht ähnlich wie bei JSP oder ASP. In früheren Versionen von Cocoon konnten dynamische Inhalte ausschließlich über XSPs generiert werden. Inzwischen gibt es mit Transformern und Actions eine Alternative zur dynamischen Generierung mit XSPs, da XSPs das Prinzip der Trennung von Inhalt und Logik verletzen. [LZ02 S.303f] Da Cocoon in der XSP-Verarbeitung außerdem kein Caching zulässt, werden XSPs hauptsächlich zum Prototyping im Rahmen der Entwicklung genutzt. [LZ02 S.309f] 4.4 Beurteilung von Cocoon Mazzocchi sieht die größte Stärke von Cocoon darin, Inhalte für verschiedene Endgeräte bereitzustellen. [Ma04] Auch Ford bestätigt, dass Cocoon eine sinnvolle Wahl darstellt, wenn der Bedarf nach endgeräteabhängigem Output besteht. Nach seiner Meinung wird diese Funktionalität in naher Zukunft für alle Web Applikationen notwendig sein. [Fo04 S.309] Allerdings bemängelt Ford die zum Teil unübersichtliche Dokumentation des Frameworks. Es kommt vor, dass in der Dokumentation bereits Features beschrieben werden, die zwar in den Entwicklungsreleases vorhanden sind, aber noch nicht in der offiziellen Version umgesetzt wurden. [Fo04 S.315] Beide Autoren sind der Meinung, dass die große Vielfalt, die Cocoon bietet, auch gleichzeitig eine der größten Schwächen des Frameworks ist. Die genutzten, offenen 17

18 Kapitel 4: Cocoon als Multichannel-Framework Standards, wie z.b. XSLT, sind teilweise sehr kompliziert und eine Werkzeugunterstützung ist nicht durchgehend vorhanden. [Fo04 S.309 / Ma04] Cocoon Entwickler Mazzocchi selbst empfiehlt die Nutzung von Cocoon auch nicht für alle Anwendungsszenarien ( Applications where Cocoon doesn't really stands out (yet!) are data-centric web applications ), jedoch besonders im Multichannel Bereich ( Cocoon was born as a web publishing framework and it really shines for multichannel operations ). [Ma04] Da das Cocoon Framework inklusive sämtlicher Komponenten von der Apache Software Foundation kostenlos erhältlich ist und auch für kommerzielle Zwecke eingesetzt werden darf, besteht ein besonders großes Interesse vieler Anwender das System einzusetzen und weiterzuentwickeln. 18

19 Kapitel 5: Zusammenfassung und Ausblick 5 Zusammenfassung und Ausblick Nach einer Vorstellung der zugrunde liegenden Basistechnologien wurden im dritten Kapitel die unterschiedlichen Ansätze von Multichannel-Systemen und ihre Einordnung in das EAI Umfeld diskutiert. Die Aufgabe dieser Systeme, Inhalte flexibel für verschiedene Endgeräte aufzubereiten, stellte sich dabei als zentral heraus. Gemäß diesem Schwerpunkt wurden die Vorteile einer 4-Tier Architektur gegenüber der weit verbreiteten 3-Tier Architektur herausgearbeitet. Die Vorstellung des Cocoon Frameworks als konkretes Multichannel-System, dessen Stärken besonders in dem gewählten Schwerpunkt liegen, rundete den bisherigen Teil der Arbeit im vierten Kapitel ab. Mit einer immer stärkeren Orientierung auf Inhalte und die flexible Client abhängige Darstellung dieser Inhalte werden MC Systeme einen höheren Stellenwert bekommen. Während heute für viele Anwendungsszenarien auch klassische Web Anwendungen gut geeignet sind, stellt sich die Frage, ob eine MC Architektur eingesetzt werden soll in Zukunft nicht mehr. Denn bereits heute wird der allgegenwärtige Zugriff auf Internet und Intranet Portale durch die unterschiedlichsten Endgeräte immer selbstverständlicher. Das always on Paradigma, welches auch in Mobilfunknetzen z.b. durch die Technologien GPRS und UMTS umgesetzt wird, verstärkt diese Entwicklung. Der Trend geht dahin, dass immer mehr Software in den Unternehmen im Einsatz ist und davon prozentual immer weniger selbst programmiert wird. Das heißt, dass sich die Aufgabenschwerpunkte von Mitarbeitern verschieben, und zwar von der Programmierung proprietärer Lösungen zur Integration fertiger Lösungen zu den Geschäftsprozessen, die das Unternehmen benötigt. [Ke02 S.12] In Zukunft soll die Arbeit mit Cocoon nicht komplizierter sein als die Programmierung einer gewöhnlichen Applikation. Das Framework soll dann den Rest der Arbeit übernehmen. [Ma04] 19

20 Anhang A: Durchführung einer Beispielinstallation Java wird benötigt und ist auf der Seite verfügbar. Ich habe Cocoon in der Version von verwendet. Die Installation läuft wie folgt ab: Zuerst wird die Datei entpackt und anschließend die Datei build.bat gestartet. Nun gibt es mehrere Möglichkeiten Cocoon zu starten. Im gleichen Verzeichnis wo die build.bat liegt ist auch eine cocoon.bat zu finden. Ruft man diese in einem Command-Fenster mit dem Parameter servlet auf, so wird Cocoon in dem Fenster gestartet. Über kann man Cocoon aufrufen. Etwas eleganter ist es, Cocoon über Apache Tomcat zu starten. Dazu muss Tomcat, zu finden unter installiert werden. Ich habe die Version verwendet. (jakarta-tomcat exe) Aufgerufen wird Tomcat über Unter \cocoon-2.7.1\build\ ist ein Ordner webapp. Diesen Ordner in cocoon umbenennen und in das webapps -Verzeichnis von Tomcat kopieren. Bei einigen Versionen gibt es auch eine cocoon.war Datei, die ins webapps -Verzeichnis kopiert werden muss. Der Aufruf erfolgt nun nicht mehr über den Port 8888 sondern über Tomcat

21 Anhang B: Kommentierte Sitemap sitemap.xmap <?xml version="1.0"?> //* Metaangaben wie der Namespace (xmlns) sind sehr wichtig und * sollten nach Möglichkeit nicht geändert werden! *// <map:sitemap xmlns:map=" //* Wie die hier beschriebenen Komponenten zusammenhängen, wird * weiter unten unter Pipelines ersichtlich. *// <!--======================Components===========================--> <map:components> //* Der File-Generator liest die XML-Datei ein und erzeugt * SAX-Events. Diese werden dann von folgenden Transformer * weiterverarbeitet *// <map:generators default="file"> <map:generator name="file" label="content" src="org.apache.cocoon.generation.filegenerator"/> </map:generators> //* Der Transformer nutzt ein XSL-Stylesheet um den XML-Datenstrom * vom Generator zu verändern. Z.B. in XHTML. *// <map:transformers default="xslt"> <map:transformer name="xslt" src="org.apache.cocoon.transformation.xalantransformer"> <use-request-parameters>false</use-request-parameters> </map:transformer> </map:transformers> //* Der Serializer Überträgt den Datenstrom vom Transformer zum * Client. Dabei wird der Datenstrom noch verändert *// <map:serializers default="html"> <map:serializer name="html" mime-type="text/html" src="org.apache.cocoon.serialization.htmlserializer"/> </map:serializers> //* Dies ist eine sehr abgespeckte Variante des * Browser-Selectors, es wird lediglich zwischen * Explorer und Mozilla unterschieden. *// <map:selectors default="browser"> <map:selector name="browser" factory="org.apache.cocoon.selection.browserselector"> <browser name="explorer" useragent="msie"/> <browser name="netscape" useragent="mozilla"/> </map:selector> </map:selectors> //* Hiermit wird die URL/URI abgefragt. *// <map:matchers default="uri"> <map:matcher name="uri" factory="org.apache.cocoon.matching.wildcardurimatcher"/> </map:matchers> </map:components> <!--======================Pipelines============================--> <map:pipelines> //* Hier beginnt die Pipeline*// <map:pipeline>

22 //* Die Pipeline wird über folgende URL aufgerufen: * *// <map:match pattern="helloworld"> //* Der Generator liest die Datei helloworld.xml *// <map:generate src="helloworld.xml"/> //* Dem Transformer wird das richtige Stylesheet übergeben *// <map:transform src="helloworld2html.xsl"/> //* Der Serializer bekommt die Information aus dem * XML-Datenstrom eine HTML-Datei zu erstellen. *// <map:serialize type="html"/> </map:match> </map:pipeline> </map:pipelines> </map:sitemap>

23 Anhang C: Beispiel für eine XSLT Transformation Die Datei helloworld.xml enthält nur den Inhalt, aber keinerlei Layoutinformation. <?xml version="1.0"?> <document> <text>hello World</text> </document> Umgekehrt ist es bei der Datei helloworld2html.xsl. Hier sind nur Layoutinformationen hinterlegt <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl=" <xsl:template match="document"> <html> <body> <h1><xsl:value-of select="text"/></h1> </body> </html> </xsl:template> </xsl:stylesheet> Der XSLT-Transformer erzeugt daraus die HTML-Datei helloworld.html. In dieser sind Inhalt und Layoutinformationen nun zusammengeführt. <html> <body> <h1>hello World</h1> </body> </html>

24 Literaturverzeichnis [LZ02] [Fo04] Matthew Langham, Carsten Ziegeler: Cocoon: Building XML Applications, 1st. ed., New Riders Publishing, Neal Ford: Art of Java Web Development, 1st. ed., Manning Publications, [AB00] Richard Anderson, Mark Birbeck, Michael Kay, u.a.: XML professionell, 1. Aufl., MITP Verlag, [Le04] [Ar03] [Ke02] Theodore W. Leung: Professional XML Development with Apache Tools: Xerces, Xalan, FOP, Cocoon, Axis, Xindice, Wrox Press, Wiley Publishing, André Aregger: MultichannelPortal Framework für e-banking Applikationen, Dissertation der wissenschaftlichen Fakultät der Universität Zürich, Wolfgang Keller: Enterprise Application Integration Erfahrungen aus der Praxis, 1. Aufl., dpunkt Verlag, [Ma02] Stefano Mazzocchi: Interview with Stefano Mazzochi, Abrufdatum: [W3C] [AC] World Wide Web Consortium. Abrufdatum: Apache Cocoon Webseite. Abrufdatum: