1. FOM Hochschule für Oekonomie & Management
Studienzentrum Essen
Master-Thesis
zur Erlangung des Grades eines
Master of Arts (M.A.)
über das Thema
Konzeption eines IDML Servers
von
Peyman Pouryekta
Erstgutachter Professor Dr.-Ing. Torsten Finke
Matrikelnummer 198124
Abgabedatum 2013-04-15

2. 2
Inhaltsverzeichnis
1 Einleitung........................................................................................................................................... 4
1.1 Sachliche Motivation................................................................................................................ 4
1.2 Ziele.......................................................................................................................................... 4
1.3 Leserkreis................................................................................................................................. 4
1.4 Typografische Konventionen.................................................................................................... 5
1.5 Literaturdiskussion................................................................................................................... 5
2 Grundlagen......................................................................................................................................... 6
2.1 Softwarearchitektur.................................................................................................................. 6
2.1.1 Definition........................................................................................................................ 6
2.1.2 Architekturmuster........................................................................................................... 8
2.1.3 Entwurfsmuster............................................................................................................. 10
2.2 Webservice............................................................................................................................. 12
2.2.1 Definition...................................................................................................................... 12
2.2.2 SOAP............................................................................................................................ 12
2.2.3 REST............................................................................................................................ 13
2.3 Grails...................................................................................................................................... 14
2.3.1 Einordnung................................................................................................................... 14
2.3.2 Groovy.......................................................................................................................... 15
2.3.3 Spring........................................................................................................................... 20
2.3.4 Konzepte....................................................................................................................... 21
2.3.5 Applikation................................................................................................................... 21
2.4 IDML...................................................................................................................................... 30
2.4.1 InDesign........................................................................................................................ 30
2.4.2 Dateiformat................................................................................................................... 32
2.4.3 IDMLlib........................................................................................................................ 35
3 Umsetzung....................................................................................................................................... 37
3.1 Konzept.................................................................................................................................. 37
3.1.1 Anforderungen.............................................................................................................. 37
3.1.2 Systemarchitektur......................................................................................................... 37
3.1.3 Webservice.................................................................................................................... 39
3.1.4 Process-Engine............................................................................................................. 41
3.2 Praktische Umsetzung............................................................................................................ 42
3.2.1 Systemanforderungen................................................................................................... 42
3.2.2 Prototyp........................................................................................................................ 42
3.2.3 Szenarien...................................................................................................................... 53
4 Schlussbetrachtung.......................................................................................................................... 61

3. 3
4.1 Ergebnisse.............................................................................................................................. 61
4.2 Bewertung.............................................................................................................................. 62
4.3 Blick in die Zukunft .............................................................................................................. 63
Abbildungsverzeichnis........................................................................................................................ 65
Abkürzungsverzeichnis....................................................................................................................... 66
Literaturverzeichnis............................................................................................................................ 68
Stichwortverzeichnis........................................................................................................................... 71

4. 4
1 Einleitung
Diese Thesis beschäftigt sich mit der Fragestellung, wie ein IDML-Server aufgebaut sein und ob die-
ser Vorteile bringen kann. Es wird ein Konzept erstellt, auf dessen Basis ein IDML-Server entwickelt
werden kann. Durch unterschiedliche Szenarien, die mit Hilfe des IDML-Servers abgebildet werden,
können die Vorzüge eines solchen Servers aufgezeigt werden.
Es folgen die sachliche Motivation, die Ziele und die Literaturdiskussion dieser Arbeit.
1.1 Sachliche Motivation
In der Druck- und Medienindustrie wird zur Erstellung von Medienprodukten häufig das Programm
Adobe InDesign (im weiteren Verlauf InDesign) verwendet. InDesign ist proprietär und das Dateifor-
mat kann somit nur von InDesign verwendet werden. Ab der CS4 Version von InDesign hat das Unter-
nehmen Adobe ein neues Dateiformat eingeführt das sich InDesign Markup Language (IDML) nennt.
Dieses Format ist einmal für die Versionskompatibilität zwischen den InDesign Versionen ab CS4
verantwortlich und zum anderen für die externe Verarbeitung von InDesign-Dokumenten. Dadurch das
IDML offengelegt wurde, können neue Möglichkeiten im Bereich von Automatisierungen außerhalb
von InDesign entwickelt werden. IDML ist jedoch ein komplexes Dateiformat und der Umgang damit
erfordert tiefes Wissen über InDesign und IDML. Um diese Komplexität beherrschbar zu machen,
sind Systeme notwendig, die von IDML-Spezialisten entwickelt werden und den Umgang mit IDML
zu verweinfachen. Oft kommt es in der Druck- und Medienindustrie vor, dass Kosten durch wieder-
kehrende Prozesse entstehen. Häufig können solche Prozesse individuell durch IDML automatisiert
werden. Ein weiterer Aspekt ist, dass einfache Aufgaben oft abhängig von InDesign sind, wodurch
zusätzlicher Arbeitsaufwand sowie Lizenzkosten entstehen können. Durch den Einsatz von IDML
kann in bestimmten Bereichen eine von InDesign unabhängige und in andere Systeme integrierbare
Lösung geboten werden.
1.2 Ziele
Diese Arbeit zeigt ein Konzept auf, mit dem der Umgang von IDML-Dateien gestaltet werden kann.
Der IDML-Server fungiert dabei als ein Werkzeug, welches man für die IDML-Verarbeitung verwen-
den kann. In dieser Arbeit steht der IDML-Server im Fokus. Darüber hinaus soll der produktive Ein-
satz eines solchen Servers dargestellt werden. Dazu werden aus der Druck- und Medienindustrie unter-
schiedliche Szenarien betrachtet, die den produktiven Einsatz eines IDML-Servers bestätigen sollen.
1.3 Leserkreis
Die Arbeit ist hauptsächlich an Personen aus der Informationstechnik gerichtet, die sich mit IDML
beschäftigen und dessen Einsatzmöglichkeiten betrachten wollen. Ein grundsolides Vorwissen über

5. 5
Softwareentwicklung im Bereich Java und über Desktop-Publishing mit InDesign wird vorausgesetzt.
Ein Vorwissen über die Themen aus dem Grundlagenkapitel ist von Vorteil. Tieferes Wissen kann und
soll über die Referenzen aus dem Literaturverzeichnis herangezogen werden.
1.4 Typografische Konventionen
In dieser Arbeit wird auf die typografischen Konventionen Wert gelegt, um dem Leser das komplexe
Thema bestmöglich zu erläutern. Folgende Konventionen werden eingehalten:
Fließtext: Die Schriftart für den Fließtext ist eine Times in der Größe 12 pt.
Code: Groovy, HTML, XML, IDML, Grails-Kommandos, URLs, Parameter und alle Elemente,
die darin verwendet werden, werden in der Schriftart Courier New mit 11 pt ausgezeichnet.
Dateinamen: Datei-, Ordnernamen und Pfade werden in der Schriftart Times mit dem Stil Italic
ausgezeichnet.
Diagramm: Die Typografie in den Diagrammen wird in Arial mit 11 pt und 8 pt ausgezeichnet.
1.5 Literaturdiskussion
Der Kern dieser Thesis beschäftigt sich mit der Orchestrierung der Themen aus dem Grundlagenkapi-
tel zu einer Komposition - dem Konzept. Dabei wird bei den Grundlagenthemen auf ihre Kernkonzep-
te eingegangen, um ein Basisverständnis zu vermitteln.
Die wichtigsten Literaturangaben dieser Arbeit beziehen sich auf den Bereich der Frameworks. Da das
Grails- und das Spring-Framework eine zentrale Rolle in dieser Konzeption spielen, wurde hier auf
den Verweis der Primärliteratur besonderer Wert gelegt. Rod Johnson (Spring-Framework), Graeme
Rocher (Grails-Framework) und Guillaume Laforge (Groovy) sind dabei die Köpfe der jeweiligen
Technologien. Zum Thema IDML ist kaum Literatur vorhanden, deshalb wird hauptsächlich mit der
IDML-Spezifikation gearbeitet. Diese behandelt jedoch nicht ausreichend den Einsatz von IDML,
weshalb Vorwissen über InDesign und eine eigenständige Motivation zur Erarbeitung von Kenntnissen
im Bereich IDML vorausgesetzt wird.

6. 6
2 Grundlagen
Dieses Kapitel beschäftigt sich mit den grundlegenden Themen, die für das Verständnis der Arbeit re-
levant sind. Als Erstes wird der Begriff Softwarearchitektur beleuchtet. Hier wird vor allem erläutert,
was eine Softwarearchitektur ist, welche Ziele sie verfolgt und wie diese umgesetzt werden kann.
Im Kapitel 2.2 wird erläutert, was unter einem Webservice zu verstehen ist. Dabei werden die Techno-
logien Simple Object Access Protocol (SOAP) und Representational State Transfer (REST) betrachtet
sowie ihre Funktionsweise erläutert.
Das Kapitel 2.3 beschäftigt sich mit dem Grails-Framework. Hier werden die Konzepte des Frame-
works erläutert. Auch die eingesetzte Sprache Groovy wird hier betrachtet und grundsätzlich gezeigt,
wie eine Grails-Applikation aufgebaut ist.
Anschließend wird im Kapitel 2.4 auf die IDML eingegangen. Zunächst wird erklärt, was überhaupt
InDesign ist. Danach wird das Dateiformat IDML betrachtet und sein Aufbau beschrieben. Danach
wird auf die Möglichkeit eingegangen, wie dieses Format verarbeitet werden kann.
In allen Grundlagenkapitel werden nur die wesentlichen Aspekte angesprochen. Genauere Informatio-
nen können anhand des Literaturverzeichnisses herangezogen werden.
2.1 Softwarearchitektur
In diesem Abschnitt wird der Begriff Softwarearchitektur erläutert. Es beginnt mit der Definition des
Begriffes. Dann wird auf dieArchitekturmuster und Entwurfsmuster eingegangen. Diese sind abstrakte
Beschreibungen einer Lösung für häufig vorkommende Probleme. Dabei betrachtenArchitekturmuster
zum einen das gesamte System, während Entwurfsmuster auf sehr spezielle Probleme ausgerichtet
sind.
2.1.1 Definition
Softwarearchitektur befasst sich mit der Gestaltung und der Struktur eines Softwaresystems. Es exis-
tiert eine Vielzahl an Definitionen.
Philippe Kruchten erläutert den Begriff auf diese Weise:
Software architecture deals with abstraction, with decomposition and composition,
with style and esthetics. [Kruchten1995, S.1]
Der Fokus von Kruchten liegt dabei auf Abstraktion, Zerlegung, Zusammensetzung, Ästhetik und Stil
der Softwarearchitektur.
Das Carnegie Mellon Software Engineering Institute (SEI) stellt auf seiner Webseite mehr als 100
Definitionen zur Verfügung [vgl. Carnegie2012]. Anhand dieser Sammlung kann grundsätzlich gesagt
werden, dass Softwarearchitektur sich mit folgenden Aspekten beschäftigt:

7. 7
Struktur: Eine Softwarearchitektur beschreibt die Komponenten eines Softwaresystems. Es geht
hierbei nicht nur um den Aufbau, sondern auch um das Zusammenspiel, die Beziehungen und die
Eigenschaften der Komponenten. Somit ist die Softwarearchitektur nicht nur der Bauplan, sondern
auch der Ablaufplan des Softwaresystems. [vgl. Starke2009, S.16] Eines ihrer der Hauptziele ist
es, die Komplexität eines Softwaresystems mit Hilfe einer Struktur beherrschbar zu machen.
Beschreibung einer Lösung: Eine Softwarearchitektur wird in Form von Plänen realisiert. Sie
beschreibt eine Lösung und besteht aus abstrakten Komponenten. Diese Pläne führen durch die
konkrete Implementierung zur Realisierung eines Systems. [vgl. Starke2009, S.16]
Entwurfsentscheidungen: Eine Softwarearchitektur basiert auf Entwurfsentscheidungen. Hier-
bei spielt sowohl die Wahl der Technologie, als auch die Wahl des Aufbaus von Komponenten eine
wichtige Rolle. [vgl. Starke2009, S.17] An dieser Stelle können Entwurfsmuster (design patterns)
ansetzen, um eine Lösung für bekannte Entwurfsprobleme zu bieten.
Übergang von der Analyse zur Realisierung: Eine Softwarearchitektur ist das Bindeglied zwi-
schen der Analyse und der konkreten Implementierung des Softwaresystems. [vgl. Starke2009,
S.17] Generell wird Software entwickelt, um ein bestehendes oder zukünftiges Problem zu lö-
sen. Dieses Problem wird im Rahmen der Analyse erfasst. Die Softwarearchitektur beschreibt die
Funktionsweise und den Aufbau des Systems, welches das Problem löst. Sie dient bei der Soft-
wareentwicklung als Vorgehensmodel.
Sichten: Eine Softwarearchitektur wird in unterschiedlichen Sichten dargestellt. Philippe Kruch-
ten unterscheidet dabei die fünf folgenden Sichten:
• logical view
• process view
• development view
• physical view
• scenario
Durch die Sicht auf die Architektur aus einem bestimmten Blickwinkel kann die Architektur ge-
nauer betrachtet und gestaltet werden, da andere Bereiche so ausgeblendet werden. Eine genaue
Erläuterung der Sichten ist zu finden unter: [Kruchten1995, S.1f].
Verständlichkeit: Eine Softwarearchitektur schafft Ordnung und ermöglicht einen Überblick über
das System. Um die Komplexität eines Systems verständlich zu machen, werden die Anforderun-
gen in Strukturen überführt und dokumentiert. Die Dokumentation ist hierbei ein wichtiger Punkt.

8. 8
Denn nur so können alle Beteiligten ein Verständnis über die einzelnen Komponenten und deren
Zusammenspiel bekommen. [vgl. Starke2009, S.18]
Flexibilität: Eine Softwarearchitektur sorgt dafür, dass das Softwaresystem weiterentwickelt wer-
den kann. Die Software muss einen Aufbau gewährleisten, der es ermöglicht, das System flexibel
zu erweitern. [vgl. Starke2009, S.19] Das bedeutet auch, dass in der Praxis generell keine perfekte
Softwarearchitekturen entstehen, da diese häufig nicht flexibel hinsichtlich ihrer Weiterentwick-
lung sind. [vgl. Wolff2009]
Abstraktion: Eine Softwarearchitektur beschreibt ein abstraktes System. Dabei werden Informa-
tionen bewusst weggelassen, um die Verständlichkeit des Systems zu erhöhen. Die wesentlichen
Kerneigenschaften der Software werden in einer Softwarearchitektur dargestellt. [vgl. Starke2009,
S.19]
Qualität: Eine durchdachte Softwarearchitektur kann die Qualität der Software erhöhen. Die Qua-
lität besteht aus mehreren Kriterien, wie zum Beispiel Performance, Verständlichkeit, Flexibilität
etc. [vgl. Starke2009, S.19]
Um diese Aspekte auch realisieren zu können, wird häufig auf bestehende Methoden wie beispielswei-
se Architekturmuster zurückgegriffen.
2.1.2 Architekturmuster
Architekturmuster unterstützen bei der Entwicklung eines Softwaresystems, da sie dieses aus einer
abstrakten und ganzheitlichen Sicht beschreiben. Im Folgenden wird das Schichtenmuster und das
Model View Controller (MVC) Muster erläutert. Diese sind für die spätere Umsetzung relevant:
Schichtenmuster: Das Schichtenmuster hat die Aufgabe, Struktur zu schaffen. Das Softwaresys-
tem wird dabei in unterschiedliche Schichten unterteilt (layering). Jede Schicht hat eine Aufgabe
und bietet der darüber liegenden Schicht eine definierte Anzahl an Diensten an. Der Aufbau eines
solchen Systems wird häufig mit einer Zwiebel verglichen. Jede Schicht kapselt ihre internen De-
tails und verbirgt die darunter liegenden Schichten. Die Nutzung der Dienste einer Schicht erfolgt
generell über die darüber liegende Schicht. Eine Mehrfachnutzung von Diensten durch andere
Schichten ist zu vermeiden, da die Abhängigkeiten der Schichten dadurch erhöht werden. [vgl.
Starke2009, S.149f]
Eine mögliche Aufteilung der Schichten für ein Softwaresystem wäre die Unterteilung in: Daten-,
Domänen-, Anwendungs- und Präsentationsschicht.

9. 9
Folgende Vor- und Nachteile ergeben sich durch den Einsatz eines Schichtenmusters:
Vorteile
• Unabhängigkeit der Schichten in der Erstellung und im Betrieb
• Implementierung einer Schicht kann aufgrund ihrer Unabhängigkeit ausgetauscht werden
• Minimierung der Abhängigkeiten zwischen Komponenten des Systems
• Leicht zu verstehendes Strukturkonzept
[vgl. Starke2009, S.150]
Nachteile
• Beeinträchtigung der Performance, da eine Anfrage unter Umständen durch mehrere Schich-
ten durchgereicht werden muss
• Erweiterungen eines Systems beinhaltet oft Änderungen in alle Schichten
[vgl. Starke2009, S.150f]
MVC: Das MVC Muster ist ein Quasi-Standard bei objektorientierten Anwendungen. Es dient
der Strukturierung von Softwaresystemen und beinhaltet die Einteilung in drei Einheiten: Model
(Datenmodell), View (Präsentation) und Controller (Programmsteuerung). Ziel des MVC Musters
ist es, eine bessere Wartbarkeit und Flexibilität der Software zu erreichen. [vgl. Starke2009, S.246]
Abbildung 1 zeigt den Ablauf des MVC Musters. Dabei stellen die durchgezogenen Pfeile direkte
und die gestrichelten indirekte Assoziationen dar.
• Das Model stellt den Programmteil dar, der die bearbeiteten Daten verwaltet.
• Die View stellt einen Zustand der Anwendung dar. Sie ist verantwortlich für die Anzeige der
Daten.
• Der Controller ist für die Steuerung verantwortlich. Er interpretiert die Operationen, die über
die View kommen und bestimmt den Folgezustand der Anwendung.
[vgl. Starke2009, S.247]
Abb. 1 MVC Ablauf [vgl. Starke2008, S.247]
Model
View Controller
Statusabfrage Statusänderung
Neuer Status
View anzeigen
Benutzer Eingabe

10. 10
Diese beiden Architekturmuster werden häufig verwendet, um die ganzheitliche Sicht eines Systems
zu organisieren. Oft tauchen während der Implementierungsphase jedoch auch Probleme auf, die nicht
mit Architekturmustern abgedeckt werden können. Hier setzen Entwurfsmuster an.
2.1.3 Entwurfsmuster
Ein Entwurfsmuster (design pattern) ist die abstrakte Beschreibung einer Lösung für ein häufig vor-
kommendes Problem. Allgemein betrachtet besitzt ein Muster vier Elemente:
Mustername: Der Mustername ist die aussagekräftige Benennung des Entwurfsproblems und der
Lösung mit ein oder zwei Worten. Sie erweitert das Entwurfsvokabular und sorgt für einen einfa-
chen Umgang bei der Dokumentation und der Kommunikation mit anderen. [vgl. Gamma2011,
S.3]
Problemabschnitt: Der Problemabschnitt beschreibt, wann das Entwurfsmuster anzuwenden ist,
welches Problem es löst und in welchem Kontext es sich befindet. Es beschreibt spezifische Ent-
wurfsprobleme und Bedingungen, die erfüllt sein müssen. [vgl. Gamma2011, S.3]
Lösungsabschnitt: Der Lösungsabschnitt beschreibt die Elemente des Entwurfs und deren Be-
ziehungen, Zuständigkeiten und Interaktionen. Die dargestellte Lösung ist als eine Schablone zu
sehen, die in unterschiedlichen Situationen Anwendung finden kann. [vgl. Gamma2011, S.4]
Konsequenzabschnitt: Der Konsequenzabschnitt beschreibt die Vor- und Nachteile des Ent-
wurfs. Diese sind relevant für die Beurteilung des Entwurfs gegenüber anderen Alternativen. [vgl.
Gamma2011, S.4]
Es gibt unterschiedliche Arten von Entwurfsmustern. Erich Gamma klassifiziert sie nach drei Aufga-
benbereichen:
Erzeugung: Die Erzeugungsmuster sind dafür zuständig, Objekte zu erzeugen. Sie kapseln den
Prozess der Erzeugung und vereinfachen den Umgang damit. Der Einsatz von Erzeugungsmustern
gewährleistet die Kontrolle über den Erzeugungsprozess, da in einem Muster entschieden wird,
was, wer, wann und wie erzeugt wird. [vgl. Gamma2011, S.101]
Struktur: Die Strukturmuster sind dafür zuständig, den Aufbau von Objekten und deren Bezie-
hungen untereinander zu vereinfachen. Der Einsatz von Strukturmuster kann die Komplexität ei-
ner Software minimieren. [vgl. Gamma2011, S.169]
Verhalten: Die Verhaltensmuster schaffen einen einheitlichen Umgang in der Kommunikation

11. 11
zwischen den Objekten. Der Einsatz von Verhaltensmustern kann die Flexibilität der Software im
Bereich der Kommunikation zwischen Objekten erhöhen. [vgl. Gamma2011, S.271]
Entwurfsmuster werden häufig in Frameworks verwendet. Für die spätere Umsetzung werden hier
einige kurz dargestellt:
Singleton: Das Singleton Entwurfsmuster gehört zu den Erzeugungsmustern und ist objektbasie-
rend. Der Zweck des Musters ist die Erzeugung genau eines Exemplars einer Klasse mit einem
globalen Zugriff darauf. Um dies zu gewährleisten, wird die Zuständigkeit der Verwaltung des
Exemplars in die Klasse gelegt. Die Klasse selber kann somit entscheiden, ob ein neues Objekt
erzeugt werden muss, oder nicht. [vgl. Gamma2011, S.157f]
Builder: Das Builder Entwurfsmuster gehört zu den Erzeugungsmustern und ist objektbasierend.
Der Zweck des Musters ist die Vereinfachung der Erzeugung von komplexen Objekten. Es trennt
die Erzeugung des Objektes von seiner Representation. Somit kann derselbe Erzeugungsprozess
unterschiedliche Representationen hervorbringen. [vgl. Gamma2011, S.119f]
Command: Das Command Entwurfsmuster ist ein Verhaltensmuster und ist objektbasierend. Der
Zweck des Musters ist die Vereinfachung bei Ausführung mehrerer komplexer Aktionen. Dabei
wird eine Anfrage in ein Command gekapselt. Durch das Ausführen eines Commands werden
mehrere Aktionen ausgeführt, die von außen nicht ersichtlich sind. Entwurfsmuster werden auch
häufig miteinander kombiniert. Zum Erzeugen von Commands kann zum Beispiel das Builder
Entwurfsmuster verwendet werden. [vgl. Freeman2004, S.206]
State: Das State Entwurfsmuster gehört zu den Verhaltensmustern und ist objektbasierend. Der
Zweck des Musters ist es Objekten die Möglichkeit zu geben, ihren Zustand zu definieren und auf
diesen aufmerksam zu machen. Eine Kombination mit dem Command-Entwurfsmuster könnte
so aussehen, dass sich bei der Beendigung der Ausführung eines Commands der Zustand eines
Objekts ändert und darauf aufmerksam macht, dass diese Ausführung beendet wurde. [vgl. Free-
man2004, S.410]
Diese Entwurfsmuster lösen spezielle Probleme und bringen oft mehr Organisation und Struktur in
eine Software.
Ein weiterer wichtiger Aspekt von Softwaresystemen ist die Bedienung. Oftmals wird die Bedienung
des Systems über eine Benutzeroberfläche realisiert. Ist das System jedoch auf die Kommunikation
mit anderen Maschinen ausgerichtet, so kann die Kommunikation über einen Webservice stattfinden.

12. 12
2.2 Webservice
Der folgende Abschnitt beginnt mit der Definition des Begriffs Webservice. Danach werden wie zuvor
erwähnt die Technologien SOAP und REST beschrieben und ihre Funktionsweise voneinander abge-
grenzt.
2.2.1 Definition
In der Literatur und in verschiedenen Fachzeitschriften existiert eine Vielzahl von Definitionen des
Begriffs Webservice. Das Standardisierungsgremium World Wide Web Consortium (W3C) bietet fol-
gende Definition an:
A Web service is a software system designed to support interoperable machine-to-
machine interaction over a network. It has an interface described in a machine-pro-
cessable format (specifically WSDL). Other systems interact with the Web service in a
manner prescribed by its description using SOAP messages, typically conveyed using
HTTP with an XML serialization in conjunction with other Web-related standards.
[Booth2004]
Dabei fällt auf, dass das W3C in dieser Definition weitere Technologien aufführt, wie zum Beispiel:
Web Service Description Language (WSDL), SOAP, Hypertext Transfer Protocol (HTTP) und Exten-
sible Markup Language (XML).
Der Begriff Webservice wird im weiteren Verlauf ohne die genannten Abhängigkeiten verstanden und
kann unter gegebenen Umständen andere Formate und Technologien implementieren. Die Kernauf-
gabe von Webservices, sind die Maschine zu Maschine Interaktion über ein Netzwerk und über einem
plattformunabhängigen Kommunikationsformat.
2.2.2 SOAP
Ursprünglich wurde SOAP von UserLand, DevelopMentor, IBM und Microsoft entwickelt. In der Ver-
sion 1.1 wurde SOAP als Kommunikationsprotokoll betrachtet. Aktuell liegt SOAP in der Version 1.2
vor, in der es mehr die Funktion eines Messaging-Framework übernimmt. [vgl. Frotscher2007, S. 28]
Um strukturierte Daten versenden zu können, ist eine Transportmöglichkeit notwendig. Bei einem
Webservice erfolgt dies in den häufigsten Fällen über HTTP. Dabei stellt sich die Frage, wie diese
Daten vorliegen. SOAP bietet hier eine XML basierte Lösung.
Relevant für diese Kommunikation ist die SOAP-Nachricht und das WSDL:
SOAP-Nachricht: Eine SOAP-Nachricht basiert auf XML und besteht aus einem Envelope. In
diesem wird der Namesraum der Nachricht definiert:

13. 13
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope">
<env:Header> </env:Header>
<env:Body> </env:Body>
</env:Envelope>
In dem Envelope befindet sich ein optionaler Header und ein zwingend erforderlicher Body.
Der Header enthält mehrere Headerblöcke, die Angaben zu Routing, Auslieferung, Authentifizie-
rung, Autorisierung und Transaktionskontexte beinhalten können. Der Body beinhaltet die eigent-
liche Nachricht, die ausgeliefert und verarbeitet werden soll. [vgl. Snell2002, S.15f]
Abb. 2 SOAP-Nachricht
WSDL: WSDL ist eine XML-Spezifikation. Es handelt sich um eine Sprache, die es ermöglicht,
einen Webservice standardisiert zu beschreiben. Die Beschreibung enthält alle notwendigen In-
formationen, um den Webservice anwenden zu können. Darin enthalten sind alle Operationen
der zu versendenden Nachrichten und Datentypen. Außerdem kann WSDL definieren, wie dieser
Webservice aufzurufen und unter welcher Adresse er zu erreichen ist. Werden diese Vorgaben ein-
gehalten, kann über Code-Generierung die Interaktion mit dem Webservice automatisiert werden.
WSDL ist wie auch SOAP plattformunabhängig. [Frotscher2007, S.44]
2.2.3 REST
REST ist generell keine festgelegte Norm. In der Literatur und in Fachzeitschriften weichen die Mei-
nungen voneinander ab.
Die Grundidee ist, dass über ein Uniform Resource Identifier (URI) eine serverseitige Aktion ausge-
führt werden kann, die genau ein Ergebnis liefert. Das erfolgt bei REST in den häufigsten Fällen über
HTTP. [vgl. Fielding2000]
Im Folgenden wird dargestellt, welche HTTP Standardmethoden REST im Webanwedungskontext
hauptsächlich verwendet:
Envelope
Header
Body

14. 14
GET: Beim Aufruf einer GET-Methode wird vom Server eine Ressource gefordert. Dabei kann
eine GET-Anfrage beliebig oft abgesendet werden. Die Methode kann ähnlich betrachtet werden
wie die Read-Methode bei Datenbankoperationen. [vgl. Bayer2002]
POST: Beim Aufruf einer POST-Methode wird vom Server eine Änderung einer Ressource gefor-
dert. Dabei können Prozesse oder Datenbankfelder verändert werden. Die Methode kann ähnlich
betrachtet werden, wie die Update-Methode bei Datenbankoperationen. [vgl. Bayer2002]
PUT: Beim Aufruf einer PUT-Methode wird vom Server eine Änderung einer Ressource gefordert
oder eine neue erzeugt. Die Methode kann ähnlich betrachtet werden, wie die Kombination aus
Create- und Update-Methode bei Datenbankoperationen. [vgl. Bayer2002]
DELETE: Beim Aufruf einer DELETE-Methode wird vom Server die Entfernung einer Ressour-
ce gefordert. Die Methode kann ähnlich betrachtet werden, wie die Delete-Methode bei Daten-
bankoperationen. [vgl. Bayer2002]
2.3 Grails
Dieser Abschnitt stellt die wesentlichen Aspekte des Grails-Framework dar. Es beginnt mit der Ein-
ordnung des Frameworks in der Java-Welt. Darauf folgt die Betrachtung der Sprache Groovy, die ein
wesentlicher Bestandteil des Frameworks ist. Außerdem wird auf das Spring-Framework eingegangen
sowie die Konzepte des Grails-Frameworks. Im letzten Abschnitt wird der Aufbau einer Grails-Appli-
kation betrachtet.
2.3.1 Einordnung
Das Grails-Framework baut auf bestehenden Standards auf, die sich in der Industrie durchgesetzt ha-
ben. Spring und Hibernate sind dabei die wesentlichen Frameworks die Grails verwendet. Abbildung
3 veranschaulicht die Beziehungen:
Abb. 3 Grails Einordnung [vgl. Rocher2009, S.3]
Java Virtual Machine
Java
Groovy
JDK
Java EE Spring Hibernate SiteMash
Grails

15. 15
SiteMesh ist dabei ein Layout Framework mit dem es möglich ist, Seitendekorationen in der View auf
einfachem Weg zu gestalten.
Das Hibernate-Framework ist ein Persistenz-Framework und behandelt Object Relational Mapping
(ORM) mit dem es möglich ist, Plain Old Java Objects (POJOs) in relationalen Datenbanken zu spei-
chern. Im Folgenden wird auf die Sprache Groovy und auf das Spring-Framework eingegangen, wel-
ches die Kerntechnologien des Grails-Frameworks sind. [vgl. Rocher2009, S.2f]
2.3.2 Groovy
Groovy ist eine dynamische Programmiersprache, die in der Java Virtual Machine (JVM) läuft. Es
liegt mit der Sprache Java auf einer Ebene und bedient sich auch ihrer. Groovy kann somit als eine
Erweiterung von Java angesehen werden.
Abb. 4 Groovy/Java Plattform [vgl. Grandeur2009, S.11]
James Strachan, der die Grundidee für Groovy hatte, wurde bei der Entwicklung von Groovy von den
Eigenschaften der Sprachen Python, Ruby und Smalltalk inspiriert. [vgl. König2007, S.3f] Es folgen
die wesentlichen Besonderheiten von Groovy gegenüber Java:
Dynamisch: Groovy ist eine dynamisch typisierte Sprache. Das bedeutet, anders als bei Java,
welche statisch typisiert ist, kann zur Laufzeit der geschriebene Groovy Code manipuliert werden.
Dadurch ist die Sprache flexibler für den Entwickler. Das zeichnet sich vor allem darin aus, dass
die Entwicklung mit einer dynamischen Sprache oft schneller ist, da die Syntax der Sprache kür-
zer gehalten und aussagekräftiger ist. Dem gegenüber steht die langsamere Geschwindigkeit bei
der Ausführung. Dadurch, das während der Laufzeit der Code verändert werden kann, und somit
neu kompiliert werden muss, können bei der Geschwindigkeit Einbußen entstehen. [vgl. Gran-
deur2009, S.12]
Import: Das Groovy Development Kit (GDK) erweitert das Java Development Kit (JDK) mit
zusätzlichen Methoden und der funktionalen Erweiterung durch Closures. Dabei werden automa-
tisch folgende Importierungen eingebunden:
Plattform (Linux, Windows...)
Java Virtual Machine
JavaGroovy

16. 16
• groovy.lang.*;
• groovy.util.*;
• java.lang.*;
• java.util.*;
• java.net.*;
• java.io.*;
• java.Math.BigInteger;
• java.Math.BigDecimal;
[Davis2008, S.42]
Zusätzlich wird eine Anzahl an Methoden verkürzt. Beispielsweise wird System.out.print in
Groovy mit print aufgerufen. [vgl. Grandeur2009, S.13]
Closure: Eines der wichtigsten Konzepte in Groovy ist das Konzept der Closure. Sie stammen aus
dem Bereich der funktionalen Programmierung und sorgen für mehr Flexibilität. Es sind Code-
blöcke, die referenziert und als Argument oder Rückgabewert in anderen Funktionen verwendet
werden können. [vgl. König2007, S.130f]
Die Syntax eines Closure ist wie folgt definiert [vgl. Groovy2012]:
{ [closureArguments->] statements }
Dabei ist closureArguments-> eine optionale, kommagetrennte Liste von Argumenten. Wenn
nur ein Argument verwendet wird, wird automatisch auf das Argument mit dem Schlüsselwort it
referenziert. [vgl. Grandeur2009, S.19]
def sayIt = { println "Hallo $it"}
sayIt "Welt!"
//Ausgabe: "Hallo Welt!"
def sayValue = {value -> println "Hallo $value"}
sayValue "Welt!"
//Ausgabe: "Hallo Welt!"
Semikolon: In Groovy ist der Einsatz von Semikolons vollkommen optional. Nur beim mehr-
fachen Aufruf in einer Zeile sind Semikolons notwendig. [Davis2008, S.42]

17. 17
print 'Hallo'
print 'Welt!'
//Ausgabe: Hallo Welt!
print 'Hallo'; print 'Welt!';
//Ausgabe: Hallo Welt!
Datentypen: In Groovy müssen keine Datentypen definiert werden. Stattdessen wird das Schlüs-
selwort def verwendet. Dabei stellt Groovy zur Laufzeit fest, um welchen Datentyp es sich han-
delt. [vgl. Grandeur2009, S.13f]
def word = 'Hallo Welt!'
print word.class
//Ausgabe: java.lang.String
def append(word){
'Hallo ' + word
}
append('Welt!')
//Input: String, Ausgabe: Hallo Wellt!
Integer i = 20
append(i)
//Input Integer, Ausgabe: Hallo 20
GString: Groovy hat eine eigene erweiterte Implementierung des Strings genannt Groovy-String
(GString). GString erlaubt dem Entwickler die Einbindung in einen String mit den Auszeichnun-
gen $ und {}. [vgl. Grandeur2009, S.14f]
def word = "Welt!"
def gstring= "Hallo ${word}"
println word.class
//Ausgabe: class java.lang.String
println gstring
//Ausgabe: Hallo Welt!

18. 18
println gstring.class
//Ausgabe: class org.codehaus.groovy.runtime.GStringImpl
Collections: In Groovy gibt es drei Arten von Collections: List, Map und Range. List und Map
sind von der funktionsweise genauso wie in Java verwendbar, nur die Darstellung ist eine andere.
Ranges hingegen sind sehr speziell und bei dynamischen Sprachen einmalig. [vgl. Grandeur2009,
S.16]
def list =['a', 'b', 'c', 'd', 'e']
def map = [0:'a', 1:'b', 2:'c']
def range= 1..10
println list.get(0)
//Ausgabe: a
println map.get(1)
//Ausgabe: b
println range
//Ausgabe [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
Return: In Groovy ist das return Statement am Ende einer Methode optional. Groovy gibt au-
tomatisch die letzte Zeile zurück. [vgl. Grandeur2009, S.17]
def method(){
"Hallo Welt!"
}
print method()
//Ausgabe: Hallo Welt!
NULL-Check: In Groovy können Objekte durch ein ? auf NULL geprüft werden. Dadurch kön-
nen NullPointerExceptions vermieden werden. [vgl. Grandeur2009, S.17]
def string = "Hallo Welt!"
println string.size()
//Ausgabe: 12

19. 19
def empty = null
println empty.size()
//Ausgabe: java.lang.NullPointerException: Cannot invoke method size()
on null object
println empty?.size()
//Ausgabe: null
Scripting: Ein weiterer wesetlicher Unterschied zu Java ist, dass Groovy skriptfähig ist. Ist Groo-
vy auf einem Betriebsystem installiert, so können ohne weiteres Skripte erstellt und ausgeführt
werden. Es ist nicht zwingend notwendig wie in Java Klassen zu erstellen. Ein einfaches Skript
(test.groovy) könnte wie folgt aussehen:
#!/usr/bin/env groovy
println "Hallo Welt!"
XML: Groovy bietet eine einfache Möglichkeit über Groovy-Path (GPath) mit XML umzugehen.
<?xml version="1.0" encoding="UTF-8"?>
<customers>
<corporate>
<customer name="Bill Gates" company="Microsoft"/>
<customer name="Steve Jobs" company="Apple"/>
<customer name="Jonathan Schwartz" company="Sun"/>
</corporate>
</customers>
Um diese XML nun einlesen zu können wird der XmlSlurper verwendet:
def customers = new XmlSlurper().parse(new File("test.xml"))
customers.corporate.customer.each{
println "${it.@name} works for ${it.@company}"
}
/*Ausgabe:
Bill Gates works for Microsoft
Steve Jobs works for Apple

20. 20
Jonathan Schwartz works for Sun
*/
2.3.3 Spring
Spring ist ein Open-Source-Framework. Es liefert zur Entwicklung einer Anwendung Fertigbausteine,
um die Entwicklung zu vereinfachen. Dabei ist Spring leichtgewichtig und flexibel, da es keine Vor-
gaben hinsichtlich der Architektur macht. Es liefert eine Menge an Libraries, die eingebunden werden
können, aber nicht zwingend erforderlich sind. Außerdem hat es den Anspruch, den Anwendungscode
unabhängig gestalten zu können, sodass es wiederverwendbar ist und auch ohne das Spring-Frame-
work eingesetzt werden kann. [vgl. Oltmanns2007, S.]
Das Spring-Framework ist in mehrere Module aufgeteilt. Vollständigkeitshalber werden im folgenden
Diagramm diese aufgeführt:
Abb. 5 Spring Modules [vgl. SpringDocu2012]
Der Core-Container ist das wichtigste Modul im Framework, da es sich mit den Kernkonzepten befasst.
Inversion of Control (IoC) und Dependency Injection (DI) sind dabei die fundamentalsten Konzepte.
IoC: IoC ist abstakt zu betrachten und befasst sich mit dem Lebenszyklus von Objekten. Das Hol-
lywood Principle verdeutlich dieses Konzept: "Don´t call us, we´ll call you". [vgl. Johnson2004,
S.128f], [vgl. Johnson2005, S.8f], [vgl. Freeman2004, S.296f]
Spring Framework Runtime
Data Access/Integration
AOP
Web (MVC/Remoting)
Aspects Intrumentation
Core Container
Test
Beans Core Context
Expression
Language
Web
Portlet
Servlet
Struts
JDBS ORM
OXM JMS
Transactions

21. 21
DI: DI ist eine Spezialisierung von IoC und wird auf zwei Wegen eingesetzt: Die erste Möglich-
keit ist Setter-Injection. Dabei wird über eine Setter-Methode ein Objekt injiziert. Die zweite Mög-
lichkeit ist die Constructor-Injection. Hierbei wird über den Konstruktor ein Objekt injiziert. Bei
beiden Möglichkeiten wir die Konfiguration der Klassen entweder über Annotationen oder über
eine externe XML-Datei konfiguriert.
2.3.4 Konzepte
Das Grails-Framework hat zum Ziel, die Java Enterprise Web Entwicklung zu vereinfachen und auf
die nächste Ebene der Abstraktion zu heben. Es bietet Möglichkeiten die andere Frameworks seit Jah-
ren bieten aber bislang nicht in der Java-Welt auf einfachem Wege verfügbar waren. Der Anspruch an
die Flexibilität ist dabei ein wesentlicher Punkt, den das Grails-Framework bietet. Das Framework ori-
entiert sich dabei an Frameworks wie Ruby on Rails, Django und TurboGears und bringt die Vorteile
dieser Frameworks in die Java Welt. [vgl. Rocher2009, S.1]
Die wesentlich Konzepte, die das Grails Framework verfolgt, sind Convention over Configuration
(CoC) und Don´t Repeat Yourself (DRY):
CoC: Bei CoC geht es um die Vereinfachung der Konfiguration einer Software. Dabei einigt man
sich auf Konventionen, wie beispielsweise gleichartige Benennungen, die dann dafür sorgen, dass
Konfigurationen wegfallen können. Ein Beispiel dafür ist die Benennung von Datenbanktabellen
und das Mapping dieser auf eine Klasse. Durch den Einsatz von CoC kann erheblich an Konfigu-
ration eingespart werden, was durch das einheitliche Vorgehen die Verständlichkeit des Systems
erhöht und die Fehleranfälligkeit reduziert.
DRY: Bei DRY geht es um die Vermeidung von Redundanzen. Ein Problem bei der Softwareent-
wicklung ist, dass der Entwickler in einer ständigen Wartungsphase ist. Sobald sich Anforderun-
gen verändern, müssen diese aufgenommen und im Code angepasst werden. Bei einem redun-
danten Code ist dies sehr aufwändig, da dieser an mehreren Stellen anpasst werden muss. Dies
ist folglich zeit- und kostenintensiv. Durch das DRY-Prinzip wird dieses Problem minimiert. [vgl.
Hunt2003, S.25f]
2.3.5 Applikation
Eine Grails-Applikation ist auf einfachem Weg zu erstellen. Ist Grails auf dem Betriebssystem instal-
liert, so gibt es eine Menge an vordefinierten Kommandos, welche bei der Entwicklung hilfreich sind.
Der Aufbau der Kommandos sieht dabei wie folgt aus:
grails [command name]

22. 22
Um eine Grails-Applikation zu erstellen wird das Kommando grails create-app verwendet.
Dieses Kommando fordert einen Namen für die Applikation. Nach Eingabe des Namens werden alle
notwendigen Dateien erstellt.
Der Aufbau einer Grails-Applikation sieht dabei wie folgt aus:
Abb. 6 Grails Applikation
Die application.properties Datei hält Properties, die angepasst werden können. In dieser Datei sind
beispielsweise die Versionsnummer und auch der Name der Applikation definiert.
In dem grails-app Ordner findet die Hauptentwicklung der Applikation statt. Hier sind Ordner zu fin-
den, die unterschiedliche Bereiche abdecken:
config: Alle relevanten Konfigurationsdateien für die Applikation sind in diesem Konfigurations-
ordner enthalten.
Die BootStrap.groovy Datei ermöglicht vor dem Start der Applikation oder nach dem Herunterfah-
ren der Applikation zusätzlichen Code auszuführen. So kann diese beispielsweise dazu verwendet
werden, einen Defaultbenutzer anzulegen, der beim Start der Applikation erzeugt wird.
Die BuildConfig.groovy Datei ist zuständig für das Buildmanagement der Applikation. Hier kön-
nen beispielsweise Maven-Repositories und Grails-Plugins eingebunden werden.
Die Config.groovy ist für die Konfiguration der Applikation gedacht. Hier werden Log4J, Enco-
ding und weitere Konfigurationsmöglichkeiten geboten.
Die DataSource.groovy behandelt die Konfiguration der Datenquelle. Wird in der Applikation
mit einer Datenbank gearbeitet, so besteht hier die Möglichkeit für unterschiedliche Umgebungen
(Entwicklungsumgebung, Testumgebung, Produktionsumgebung) eigene Datenbanken zu konfi-
gurieren.
Der hibernate und spring Ordner ist optional nutzbar. Gibt es beispielsweise Java-Klassen in dem

23. 23
src Ordner, die als Bean in der Grails-Applikation verwendet werden sollen, so kann diese hier
eingebunden werden. Die Spring-Konfiguration kann dann als XML oder in Groovy definiert wer-
den.
Die UrlMappings.groovy definiert ein einheitliches Uniform Resource Locator (URL) Verhalten
der Applikation.
domain: In dem domain Ordner werden die Domain-Klassen abgelegt. Die Erzeugung kann über
das Kommando grails create-domain-class erfolgen. Wird eine Domain-Klasse erzeugt,
sind Objekte dieser Klasse immer direkt auch Objekte, welche in der Datenbank abgelegt werden
können. Zu der Domain-Klasse Person gibt es beispielsweise direkt auch eine Datenbank-Tabelle
dazu.
Domain-Klassen können außerdem constraints besitzen. Das sind Angaben zu Attributen der
Klasse, die bei der Erzeugung eines Objekts validiert werden. [vgl. Rocher2009, S.45f]
class Person {
String firstname
String lastname
int age
String emailadress
static constraints{
firstname(blank: false)
lastname(blank: false)
age(min: 1)
emailadress(email: true)
}
}
Der Validator blank: false sorgt dafür, dass die Werte firstname und lastname nicht leer
sein dürfen. min:1 dagegen prüft, ob der Wert age mindestens bei 1 liegt. Der Validator email:
true überprüft, ob der Wert emailadress eine valide Email-Adresse ist.
Grails bietet im Bereich der Domainklassen ein Grails Object Relational Mapping (GORM). Dies
erleichtert den Umgang mit den Objekten und stellt gleichzeitig Create, Read, Update, Delete
(CRUD) Funktionalität zur Verfügung.
Um ein Objekt aus der Datenbank auszulesen wird die get() Methode verwendet.
def person = Person.get(id)

24. 24
Dabei fällt auf, dass die Klasse Person keine get() Methode definiert. Alle Domain-Klassen
bekommen zur Laufzeit diese Methoden hinzugefügt. Grails ermöglicht dies mit Groovy über Me-
taprogramming. [vgl. Rocher2009, S.249f] Um mehrere Personen als Liste zurück zu bekommen
kann die getAll() Methode verwendet werden:
def persons = Person.getAll(1,2,3)
Die list() Methode bietet zusätzliche Funktionen wie beispielsweise die Sortierungsfunktion:
def persons = Person.list(sort:'age', order:'desc')
Um ein Objekt in der Datenbank zu speichern oder zu aktualisieren, wird die save() Methode
verwendet:
def newPerson = new Person(params)
newPerson.save()
def person = Person.get(id)
person.save()
Dabei stellt im Hintergrund Hibernate automatisch fest, ob es ein Structured Query Language
(SQL) INSERT oder ein UPDATE verwenden muss. [vgl. Rocher2009, S.251]
Zum Löschen eines Objektes wird die delete() Methode angewandt:
person.delete()
Zum Suchen eines bestimmten Objekts aus der Datenbank bietet GORM die Dynamic-Finders.
[vgl. Rocher2009, S.255f] Diese setzen sich aus den Klasseneigenschaften und Schlüsselwörtern
zusammen:
Person.findByFirstnameAndLastname("John","Doe")
service: In dem service Ordner werden Service-Klassen abgelegt. Erzeugen kann man diese über
das Kommando grails create-service. Service-Klassen sind in Grails standardmäßig Sin-
geltons. Sie können über das Autowiring-Konzept von Spring automatisch über DI in einem Ser-
vice oder einem Controller injiziert werden. [vgl. Rocher2009, S.289f]

25. 25
class PersonController{
def personService
...
}
Eine Service-Klasse arbeitet im Normalfall mit den Domain-Klassen und repräsentiert die Busi-
nesslogik der Anwendung. Die Operationen in der Service-Klasse können Datenbankänderungen
behandeln. Somit müssen die Service-Klassen transaktional sein. Jede bietet die Möglichkeit die
Transaktionalität zu setzen. [vgl. Rocher2009, S.295f]
class PersonService{
boolean transactional = true
...
}
Transaktionalität wird beschrieben durchAtomicity, Consistency, Isolation und Durability (ACID):
• Atomicity bedeutet, dass jede atomare Operation in der Transaktion entweder ganz oder gar
nicht ausgeführt wird.
• Consistency bedeutet, dass nach der Ausführung einer Transaktion die Datenbank konsistent
sein muss - vorausgesetzt sie war auch vorher konsistent.
• Isolation bedeutet, es wird verhindert, dass mehrere parallel laufende Operationen sich gegen-
seitig behindern.
• Durability bedeutet, dass nach einer Transaktion gewährleistet wird, dass die Daten dauerhaft
in der Datenbank abgespeichert werden.
[vgl. Rocher2009, S.295f]
Service-Klassen können unterschiedliche scopes aufweisen. Bei Bedarf kann diese Eigenschaft
angepasst werden. [vgl. Rocher2009, S.297f]
class PersonService{
boolean transactional = true
static scope = 'request'
}
Das Schlüsselwort request bedeutet hier, dass für jede Anfrage ein Service erzeugt wird.

26. 26
controller: In dem controller Ordner werden Controller-Klassen abgelegt. Erzeugen kann man
diese mit dem Kommando grails create-controller. Controller-Klassen behandeln die
eingehenden Anfragen. Sie entscheiden wie die Anfrage verarbeitet wird und liefern ein Ergebnis
an den Anfragenden. [vgl. Rocher2009, S.65f]
class PersonController{
def index = {}
}
Ein Controller kann mehrere Closures beinhalten. Jeder Closure ist eine eigene Action und kann
über die URL angesteuert werden (/person/index). Der Name des Clousures (hier: index)
wird automatisch für die View verwendet (CoC). Somit wird vorausgesetzt, dass eine View mit
dem Dateinamen index.gsp existiert. Um eine individuelle View zu rendern, gibt es die Möglich-
keit diese explizit zu setzen. [vgl. Rocher2009, S.76f]
class PersonController{
def show = {
render(view:myview, model[person: Person.get(id)])
}
}
Die View muss hier myview.gsp lauten und das Objekt, welches an die Person übergeben wird,
lautet person.
Controller-Klassen bieten außerdem noch Aspect-Oriented-Programming (AOP) in Form von In-
terceptors. Somit kann vor oder nach einem Closure zusätzlicher Code ausgeführt werden. [vgl.
Rocher2009, S.90f]
def beforeInterceptor = {
log.trace("Executing action $actionName with params $params")
}
def afterInterceptor = {model->
log.trace("Executed action $actionName result model: $model")
}
Controller-Klassen können als Rückgabe an die View direkt auch XML oder JavaScript Object
Notation (JSON) zurückgeben. Dies wird im Zusammenhang mit Asynchronous JavaScript and

27. 27
XML (AJAX) oder beispielsweise direkt als Webservice verwendet. Die einfachste Möglichkeit,
die Grails hier bietet, sind die grails.converters.*.
import grails.converters.XML
def person = Person.get(id)
render person as XML
import grails.converters.JSON
def person = Person.get(id)
render person as JSON
Eine weitere Funktion die Grails bietet ist das Scaffolding. Scaffolding hilft unerfahrenen Ent-
wicklern beim Start mit dem Grails-Framework. Außerdem wird es oft im Bereich des Prototyping
eingesetzt, um eine erste Version zu erstellen. Scaffolding kann in Grails dynamisch und statisch
verwendet werden. Das dynamische Scaffolding von einer CRUD-Anwendung erzeugt während
der Laufzeit die Controller Logik und die Views. Um das Scaffolding zu aktivieren, wird das At-
tribut scaffold mit der jeweiligen Domainklasse gesetzt. [vgl. Rocher2009, S.19f]
class PersonController{
def scaffold = Person
}
Beim statischen Scaffolding werden einmalig der Controller und die dazugehörigen Views gene-
riert. Mit dem Kommando grails generate-controller wird der Controller erzeugt. Mit
dem Kommando grails generate-views werden die dazugehörigen Views erzeugt. Möchte
man beides mit einem Kommando generieren lassen, kann das Kommando grails generate-
all verwendet werden. [vgl. Rocher2009, S.27f]
views: In dem views Ordner werden die Groovy Server Pages (GSP) abgelegt. Sie sind an die Java
Server Pages (JSP) angelehnt, haben jedoch Vorteile, die durch die Sprache Groovy mitgebracht
werden, wie beispielsweise Dynamic Dispatching und die Expression Language (EL). [vgl. Ro-
cher2009, S.107f]
In dem views Ordner liegen normalerweise weitere Unterordner, welche die gleiche Benennung
haben, wie die jeweilige Domain-Klasse. In diesen Ordnern liegen dann die GSP-Dateien.
Grails arbeitet mit SiteMesh. Das Grundlayout liegt unter views/layouts/main.gsp. In der jeweili-
gen GSP wird das Layout dann über ein meta Tag eingebunden:

28. 28
<html>
<head>
<meta name="layout" content="main"/>
</head>
...
</html>
Um der View Funktionalität zu verleihen und eine Trennung von Inhalt und Funktion zu erlangen,
werden Tags eingesetzt. Alle diese GSP-Tags haben ein g: vorangestellt. Grails verwendet drei
unterschiedliche Arten von Tags:
Built-in Tags sind vordefinierte Tags, die das Framework Grails bietet. Sie werden beispielsweise
als logische oder iterative Funktionalitätsmöglichkeit in der View eingesetzt. [vgl. Rocher2009,
S.111f]
<g:if test="${firstname == 'John'}">
Hallo ${firstname}
</g:if>
<g:each in="${persons}">
<p>Firstname: ${it.firstname}</p>
<p>Lastname: ${it.lastname}</p>
</g:each>
Dynamic Tags sind Tags, welche unterschiedliche Darstellungen annehmen können. Einerseits
können sie wie die Built-in Tags in XML Form dargestellt werden [vgl. Rocher2009, S.116f]:
<a href="<g:createLink action="list" />">
dynamic link
</a>
Andererseits gibt es die Möglichkeit, die gleiche Funktionalität durch einen Methoden-Aufruf zu
realisieren:
<a href="${createLink(action:'list')}">
dynamic link
</a>

29. 29
Diese zweite Darstellungsmöglichkeit wird als sauberer empfunden, da die XML Tags nicht mehr-
fach ineinander verschachtelt sind.
Custom Tags sind dynamic Tags. Sie können individuell vom Entwickler programmiert werden,
um spezielle Aufgaben zu bewältigen. Sie werden in dem taglib Ordner positioniert.
taglib: Individuelle Tag-Libraries können mit dem Kommando grails create-tag-lib ge-
neriert werden. Ein einfaches Tag kann wie folgt aussehen:
class PersonTagLib{
def personname = {attrs, body ->
attrs.in?.each{
body(it)
}
}
}
Das zugehörige Tag in der View sieht wie folgt aus:
<g:personname in="${persons}">
Hallo ${it.firstname}
</g:personname>
Im lib Ordner können weiter Libraries platziert werden, die dann von der Applikation in Anspruch
genommen werden können.
Im scripts Ordner können zusätzliche Skripte hinterlegt werden. Diese können dann über das grails
Kommando ausgeführt werden.
Der src Ordner beinhaltet einen java und einen groovy Ordner. In diesen Ordnern können jeweils
Java und Groovy Code eingebunden werden. Gibt es beispielsweise bereits Businesslogik, die in Java
implementiert wurde, können die Java-Klassen hier in dem java Ordner platziert und somit von der
Grails-Applikation genutzt werden.
In dem test Ordner werden Integrationstests und Unittests platziert. Hier kann die Funktionalität der
Applikation ausgiebig getestet werden.
Der web-app Ordner beinhaltet den WEB-INF Ordner mit den Spring und SiteMesh Konfigurations-

30. 30
dateien. Darüber hinaus sind Cascading Style Sheets (CSS), Bild und JavaScript (JS) Ordner verfüg-
bar, in denen die jeweiligen benötigten Dateien positioniert werden können.
Eine Grails Applikation ist sofort nach der Erstellung ausführbar. Mit dem Kommando grails run-
app kann der integrierte Tomcat gestartet werden. Um ein Web Application Archive (WAR) zu erstel-
len kann das Kommando grails war verwendet werden.
2.4 IDML
Dieser Abschnitt beginnt mit der Erläuterung von dem Programm InDesign. Der wesentliche Aufbau,
die Ziele und die Ideen des IDML-Formats werden anschließend beschrieben. Im letzten Abschnitt
wird eine Möglichkeit dargestellt, IDML-Dateien zu verarbeiten.
2.4.1 InDesign
InDesign ist ein Desktop-Publishing (DTP) Programm. DTP Programme ermöglichen es alle Tätigkei-
ten, die vor dem Druck einer Publikation erfolgen müssen, an einem Desktop-Computer zu erledigen.
Zu diesen Tätigkeiten gehören: Text-, Bild- und Grafikbearbeitung sowie das Zusammenstellen dieser
zu einem Layout. [vgl. Kipphan2000, S.28]
Adobe bietet im DTP-Bereich eine Sammlung an Programmen an. Diese Sammlung wird Adobe Crea-
tive Suite (CS) genannt. InDesign ist dabei ein Teil der CS und verfolgt das Hauptziel, die Typografie
und das Layout für Print, aber auch für digitale Publikationen zu erstellen.
InDesign bietet dabei sehr viele Funktionen. Das gängige Vorgehen kann in die Bereiche Dokumen-
tenerstellung, Elementplatzierung und Dokumentenausgabe eingeteilt werden [vgl. Pouryekta2011,
S.16f]:
Dokumenterstellung: Bei der Dokumenterstellung werden die grundlegenden Werte gesetzt, die
das Dokument aufweisen soll. Die relevantesten Werte sind:
• Die Seitenanzahl legt fest, wie viele Seiten das Dokument haben soll. Dieser Wert kann dyna-
misch später bei der Bearbeitung verändert werden.
• Die Doppelseiten-Funktion entscheidet, ob das Dokument doppelseitig erzeugt werden soll.
Dies ist beispielsweise bei Büchern oder Broschüren relevant.
• Die Seitengröße kann individuell in unterschiedlichen Einheiten festgelegt werden.
• Die Ausrichtung der Seite entscheidet, ob das Dokument als Hoch- oder Querformat angelegt
wird.
• Spalten können eine Struktur in dem Dokument erzeugen. Die Anzahl der Spalten und der
jeweilige Steg1
kann angegeben werden.
1 Als Steg wird der Abstand zwischen den Spalten bezeichnet.

31. 31
• Die Ränder können in unterschiedlichen Einheiten definiert werden.
• Die Beschnittzugabe ist bei Dokumenten relevant, die später in den Druck kommen. Hier kön-
nen Beschnittzugaben definiert werden, um Blitzer2
zu vermeiden.
Elementplatzierung: Ist das Dokument erstellt, können auf diesem unterschiedliche Arten von
Elementen platziert werden:
• Text-Elemente werden für die Textdarstellung verwendet. Hier können umfangreiche typo-
grafische Auszeichnungen vorgenommen werden und Stile auf Absatz- oder Zeichenebene
zugewiesen werden.
• Rechteck-Elemente können als grafische Darstellung definiert werden. Diese können bei-
spielsweise Farb-, Bild- oder Videoinhalte aufweisen.
• Polygon-Elemente können individuelle Formen annehmen und wie Rechteck-Elemente Inhal-
te aufweisen.
• Oval-Elemente sind für kreisförmige Darstellungen ausgelegt. Auch diese können wiederum
Inhalte aufweisen.
• Linien-Elemente können Kurven darstellen.
• Formfelder und Knöpfe können zur Erzeugung von Formularen verwendet werden.
• Gruppen fassen alle möglichen Elemente zusammen.
Dokumentenausgabe: Je nach InDesign Version gibt es unterschiedliche Ausgabemöglichkeiten.
Die grundlegenden Ausgabemöglichkeiten sind:
• InDesign Document Format (INDD) ist das proprietäre Dateiformat, welches von InDesign
genutzt wird. Dieses Dateiformat ist nicht abwärtskompatibel.
• Adobe Portable Document Format (PDF) lässt sich mit umfangreichen Einstellungsmöglich-
keiten in InDesign definieren, um bestmögliche Druck-, Web- oder interaktive PDF-Doku-
mente zu erstellen.
• Electronic Publication (EPUB) ist ein offener Standard für electronic books (eBook), welches
im mobilen Bereich eingesetzt wird.
• InDesign Markup Language (IDML) ist zum einen das Dateiformat, mit dem die Versions-
kompabilität von InDesign gewährleistet wird und zum anderen ein offenes Dateiformat, wel-
ches anders als bei INDD die Möglichkeit bietet, es lesen und somit durch Drittsysteme ver-
arbeiten zu können.
2 Blitzer sind weiße Zwischenräume, die an den Rändern eines Dokumentes auftauchen, wenn keine Beschnitt
zugabe definiert wurde.

32. 32
2.4.2 Dateiformat
Das Dateiformat IDML wurde mit der InDesign Version CS4 eingeführt und repräsentiert ein In-
Design-Dokument als XML. Es ist ein Konstruktionsplan für InDesign-Dokumente. Wird eine IDML-
Datei in InDesign geöffnet erzeugt InDesign aus dem IDML ein INDD.
Außerdem löst IDML das InDesign Interchange Format (INX) ab und sorgt für die Versionskompatibi-
lität ab CS4. Ein wesentlicher Unterschied zu INX besteht darin, dass INX zwar auch XML basierend
ist, aber es nur maschinenlesbar und somit hauptsächlich nur für den internen Gebrauch in InDesign
verwendet wird. Die IDML-Spezifikationen hingegen sind öffentlich. Das Format kann somit verstan-
den werden. Mit IDML ist man dadurch nicht mehr an InDesign gebunden und kann IDML-Dateien
extern lesen und schreiben. [vgl. Adobe2012, S.12f]
Einige Bereiche in denen IDML eingesetzt werden kann sind [vgl. Adobe2012, S.15]:
• Generierung von IDML-Dokumenten oder Dokumententeilen aus einer Datenquelle.
• Programmatische Wiederverwendung von IDML-Elementen.
• Transformierung über Extensible Stylesheet Language Transformation (XSLT).
• Auffinden von Inhalten über XML Path Language (XPath) oder XML Query Language (XQuery).
• Validierungs- und Vergleichsmöglichkeit von Inhalten über unterschiedliche Versionen von Doku-
menten.
Die Ziele, die IDML nach der Spezifikation verfolgt, sind folgende [vgl. Adobe2012, S.15f]:
Vollständigkeit: Alle Elemente, die in InDesign erzeugt werden können, sollen in IDML darge-
stellt werden. Dabei ist darauf hinzuweisen, dass es rein um die Darstellung einer INDD als IDML
geht. IDML liefert keine Funktionen, die in InDesign verfügbar sind.
Lesbarkeit: IDML hat den Anspruch menschenlesbar und verständlich zu sein. Jemand der den
grundlegenden Umgang mit InDesign kennt, soll sich im IDML-Dokument zurecht finden können.
Verarbeitung: IDML-Dokumente sollen durch externe Applikationen gelesen und geschrieben
werden können.
Robustheit: Das IDML-Format soll robust sein. Das bedeutet Fehler in einem IDML-Dokument
sollten keine schwerwiegenden Auswirkungen haben. Das Regular Language Description for
XML New Generation (RNG) Schema definiert den Aufbau einer IDML und bietet somit Validie-
rungsmöglichkeiten, um grobe Fehler in IDML zu vermeiden.

33. 33
Rückwärtskompatibilität: Die Rückwärtskompatibilität zu einer Vorgängerversion soll durch
IDML gewähleistet werden.
Performanz: Die Performanz von INX-Dateien soll durch IDML übersteigern.
Verbesserungen gegenüber INX: IDML soll eine Verbesserung gegenüber INX sein. Es ist zum
einen ein offenes Format und beinhaltet keine unklaren Elemente wie bei INX. Zum anderen ver-
wendet es ein Schema zur Validierung und hat keine Prozessanweisungen mehr in Textbereichen.
Das IDML-Format ist ein Containerformat. Es beinhaltet mehrere XML-Dateien, welche das In-
Design-Dokument beschreiben. Dieses Containerformat ist ein Universal Container Format (UCF).
Es ist grundlegend ein ZIP-Archiv mit speziellen Bedingungen, die beispielsweise Kompression und
Encoding betreffen. [vgl. Adobe2012, S.394f]
Der Aufbau des IDML Formats sieht wie folgt aus:
Abb. 7 IDML Container Aufbau [Adobe2012, S.20]

34. 34
Multipurpose Internet Mail Extensions Type (MIMETYPE): Diese Datei beschreib den Datei-
typ. Bei IDML sieht der Inhalt wie folgt aus [vgl. Adobe2012, S.399f]:
application/vnd.adobe.indesign-idml-package
designmap.xml: Diese XML ist das Rückgrad der IDML-Datei. Alle weiteren Dateien in der
IDML werden von ihr referenziert. Außerdem sind die Reihenfolge und Beziehungen, die in dieser
XML aufgeführt sind wesentlich. [vgl. Adobe2012, S.44f]
MasterSpreads: MasterSpreads sind Vorlagen für einen Druckbogen. Hier kann der Druckbogen
(Spread) vordefiniert werden. Die MasterSpreads liegen in dem MasterSpread Ordner. Die Mas-
terspread.xml Dateien definieren den MasterSpread und können Elemente (PageItem) beinhalten,
die auf der MasterSpread positioniert werden. [vgl. Adobe2012, S.87] Die Benennung der IDML-
Komponenten folgt einem festen Schema, welche in den Spezifikationen zu finden ist. [vgl. Ado-
be2012, S.23f]
Resources: Dieser Ordner beinhaltet vier XML-Dateien, die Vorgaben und Einstellungen des In-
Design Dokumentes repräsentieren [vgl. Adobe2012, S.21]:
• Die Graphic.xml definiert beispielsweise Farben (Color), Rahmenstile (StrokeStyle) und Ver-
läufe (Gradients), die in dem InDesign-Dokument definiert wurden. Auf diese Definitionen
kann referenziert werden. [vgl. Adobe2012, S.263f]
• Die Fonts.xml definiert Defaultschriften und alle Schriften, die in dem InDesign-Dokument
verwendet werden. [vgl. Adobe2012, S.259f]
• Die Styles.xml definiert alle Stile, die in dem InDesign-Dokument definiert werden. Dazu
zählen: paragraph, character, object, cell, table und table of contens styles. [vgl. Adobe2012,
S.345f]
• Die Preferences.xml definiert Grundeinstellungen und Darstellungsmöglichkeiten des Doku-
mentes in InDesign. Es hat keine Auswirkungen auf das Dokument selbst. [vgl. Adobe2012,
S.281f]
Spreads: Spreads sind Druckbögen. Der Spread Ordner hält alle Spreads, die in dem InDesign-
Dokument definiert werden als Spread.xml Datei. Ein Spread kann mehrere Seiten (Page) bein-
halten. Auf einem Spread können PageItems platziert werden. [vgl. Adobe2012, S.87f] Die Be-
nennung der IDML Komponenten folgt einem festen Schema, welches in den Spezifikationen zu
finden ist. [vgl. Adobe2012, S.23f]
Stories: Stories definieren den Textinhalt eines Dokumentes. Der Stories Ordner hält alle Stories,

35. 35
die in dem InDesign Dokument definiert werden als Story.xml. Diese Stories beinhalten den Text,
die zugehörigen Stile und eine Referenz auf den zugehörigen Textrahmen (TextFrame). [vgl. Ado-
be2012, S.163f] Die Benennung der IDML-Komponenten folgt einem festen Schema, welches in
den Spezifikationen zu finden ist. [vgl. Adobe2012, S.23f]
XML: Der XML-Ordner beinhaltet drei weitere XML-Dateien, die für speziellere Aufgaben ver-
wendet werden [vgl. Adobe2012, S.22f]:
• Die BackingStory.xml definiert Inhalte, die noch keinem PageItem zugeordnet wurden.
• Die Tags.xml definiert alle Tags, die in InDesign mit der Tagfunktion erstellt wurden.
• Die Mapping.xml definiert die Beziehungen zwischen Tag und Styles.
META-INF: Dieser Ordner hält einmal die container.xml Datei. Diese ist notwendig für den UCF
Standard und referenziert auf die designmap.xml. Zum anderen metadata.xml welche beispiels-
weise Extensible Metadata Platform (XMP) und Resource Description Framework (RDF) Inhalte
definieren. [vgl. Adobe2012, S.401f]
2.4.3 IDMLlib
Die IDMLlib ist eine Java Library, die es ermöglicht IDML-Dokumente zu lesen und zu schrei-
ben. Ein weiteres Ziel der Library ist es, die Komplexität des IDML-Formates zu reduzieren und
eine Schnittstelle zu bieten, mit der es möglich ist IDML-Dokumente zu verarbeiten. IDMLlib kann
IDML-Dokumente und InDesign Snippets (IDMS) verarbeiten. Des Weiteren bietet die IDMLlib [vgl.
IDMLlib2013]:
• Ein Java Objektmodell
• Automatische Typ Konvertierung von XML nach Java
• Spezielle Klasse für die IDML-Elemente
• Lazy loading Mechanismus
• Polyglot Programming3
(Groovy, JRuby, Scala etc.)
• Vollen Zugriff auf die IDML-Elemente
• Kapselung der XML und somit keine notwendige XML Erfahrung
Die IDMLlib läuft auf den Betriebssystemen Windows, Linux und Mac OS. Vorausgesetzt wird das
JDK 5. Außerdem ist die IDMLlib unabhängig von InDesign. Somit lassen sich Workflows konzipie-
ren, die Automatisierungsaufgaben außerhalb von InDesign ersetzen und diese flexibler und perfor-
manter umsetzen können.
3 Polyglot bedeutet mehrsprachig. In diesem Zusammenhang ist der Zugriff von anderen Sprachen auf die
IDMLlib gemeint.

36. 36
Einige Einsatzmöglichkeiten werden auf der IDMLlib Webseite genannt [vgl. IDMLlib2013]:
• Individuelle Validierung von Dokumenten.
• Vorbereiten von InDesign-Dokumenten für InDesign.
• Publizieren von Inhalten, die aus InDesign-Dokumenten ausgelesen werden.
• Qualitätssicherung durch Validierung und Vergleichen von Dokumenten.
• Übersetzungsworkflows für mehrsprachige Dokumente.
• Einbinden von InDesign-Dokumenten in Drittsysteme.

37. 37
3 Umsetzung
Dieses Kapitel beschäftigt sich mit der Umsetzung des IDML-Servers. Nachdem in Kapitel 2 die
Grundlagen betrachtet wurde, wird zunächst auf das Konzept des IDML-Servers eingegangen. Im
Kapitel 3.2 erfolgt darauf die praktische Umsetzung, welche die Realisierung des Konzepts bestätigen
soll. Sowohl das Konzept, als auch die praktische Umsetzung bauen auf den vorherigen Grundlagen-
kapitel auf.
3.1 Konzept
Das Konzept beginnt mit den Anforderungen an den IDML-Server. Hier wird festgelegt, welche As-
pekte für das System relevant sind. Darauf folgt die Systemarchitektur, welche maßgeblich durch die
eingesetzten Frameworks definiert wird. Ferner werden Entwurfsentscheidungen hier festgelegt und
beschrieben. Im Anschluss darauf wird der Webservice definiert, der beim IDML-Server zum Einsatz
kommt. Im letzten Abschnitt werden die Funktionsweise und der Aufbau der Process-Engine definiert.
Diese Punkte zusammen dienen als Basis für die praktische Umsetzung.
3.1.1 Anforderungen
Das Konzept eines Systems, welches IDML-Dokumente verarbeiten kann, hat folgende Anforderun-
gen:
Verarbeitung: Das System soll in der Lage sein, IDML-Dateien verarbeiten zu können.
Vereinfachung: Das System soll den Umgang mit IDML vereinfachen. Da das IDML-Format
sehr komplex aufgebaut ist, soll das System diese Komplexität kapseln und über leicht verständli-
che Funktionen verfügbar machen.
Einbindung: Das System soll in bestehende Workflows integriert werden sowie Prozesse verein-
fachen und automatisieren können.
Erweiterbarkeit: Das System soll erweiterbar sein, um zukünftigen Anforderungen gerecht wer-
den zu können.
3.1.2 Systemarchitektur
Die Systemarchitektur ergibt sich in erster Linie aus den Anforderungen. Eines der Ziele des Systems
ist die Einbindung in bestehende Workflows. Da im Druck- und Medien-Bereich Workflowsysteme oft
als zentrales Serversystem vorliegen, wird hier das Konzept eines IDML-Servers gewählt. Folgende
Vor- und Nachteile ergeben sich bei dem Einsatz eines Servers:

38. 38
Vorteile
• Ein Server ist generell ein zentrales System und kann in Workflows integriert werden. In einem
Workflow können so Probleme schneller erkannt werden, da es eine klare Aufgabenverteilung gibt
und so deutlich wird, welcher Server für welche Aufgaben verantwortlich ist.
• Die Datensicherung ist bei einem zentralen Server einfacher zu handhaben, da die Daten an einem
Ort einheitlich gesichert werden können.
• Server können in bestehende Workflows über Schnittstellen eingebunden werden.
• Eine Cloudversion eines Servers ist möglich.
Nachteile
• Initialkosten eines Serversystems sind oft höher als bei Desktopsystemen, da die technische Kom-
plexität höher liegt.
• Single Point of Failure
Der Server ist ein System zur Verarbeitung von IDML-Dateien und wird in drei Bereiche unterteilt:
Eingabe, Verarbeitung und Ausgabe (EVA-Prinzip). Der Ein- und Ausgabe Bereich wird dabei über
den Komponente Webservice realisiert. Der Verarbeitungsbereich wird über die Komponente Process-
Engine realisiert.
Abb. 8 IDML-Server
Anfragen an den Server über den Webservice erfolgen über HTTP (üblicherweise wird HTTP/Port 80
für Webservices gewählt, da Firewalls den Port 80 normalerweise nicht blockieren. Es kann jedoch
auch ein anderer Port definiert werden.). Die Anfragen sind in Form von Parametern oder Dateien zu
definieren. Der Webservice nimmt die Anfrage entgegen und leitet diese weiter an die Process-Engine.
Die Process-Engine ist für die Ausführung von vordefinierten Abläufen zuständig. Diese führt die
nötigen Funktionen aus und liefert ein Ergebnis. Das Ergebnis wird wieder zurück an den Webservice
geleitet, der die Daten als Antwort in Form von XML (üblicherweise wird XML verwendet. Es können
jedoch auch andere Formate verwendet werden, wie zum Beispiel JSON.) an den Anfragenden wieder
zurück sendet.
IDML-Server
Webservice Process-Engine
IDML, Parameter
IDML, XML

39. 39
Der Server ist nach dem MVC-Muster und dem Schichtenmuster aufgebaut. Dabei ist das Model im
Bereich der Process-Engine anzuordnen. Dieser ist zuständig für die Verarbeitung der Daten. Die View
und der Controller sind im Bereich des Webservices einzuordnen. Die View ist hier die Darstellung der
Ergebnisse in Form von XML. Der Controller nimmt die Anfrage entgegen und ist dafür zuständig, die
Daten in der View darzustellen.
Das Schichtenmuster wird in mehreren Bereichen angewendet. Einmal ist der Server im Kontext eines
Workflows zu betrachten. Dabei ist der IDML-Server eine Komponente des Workflows (eine Schicht)
mit einer klaren Aufgabenstellung. Der IDML-Server hat das Ziel, die Komplexität des IDML-Forma-
tes zu kapseln. Deswegen wird der IDML-Server weiter in die Komponenten (Schichten) Webservice
und Process-Engine unterteilt. Auch diese Komponenten haben wieder eine klare Aufgabenstellung.
Zuletzt ist der IDML-Server aus Entwicklersicht zu betrachten, in dem Programmteile in Schichten
unterteilt werden, um wieder Aufgabenbereiche klar zu definieren.
Die konkrete Implementierung des Systems basiert auf Industriestandards, die sich im Laufe der Zeit
bewiesen haben. Das gewählte Framework für die Implementierung ist das Grails-Framework. Die
darunterliegenden Technologien, wie beispielsweise Spring-Framework, Groovy, Java und IDMLlib,
gewährleisten, dass die Anforderungen an das System erfüllt werden. Java und das Spring-Framework
liefern dabei eine sehr große Anzahl an erprobten Libraries, die in unterschiedlichsten Bereichen der
Softwareentwicklung eingesetzt werden können. Außerdem bietet Java Plattformunabhängigkeit so-
wie sichere und robuste Funktionen auf die das Grails-Framework und damit der IDML-Server auf-
baut. Die Sprache Groovy bringt durch ihre Eigenschaften, der dynamischen Typisierung und der
Skriptfähigkeit der Sprache starke Vorteile in den Bereichen der Flexibilität eines Systems. Des Weite-
ren liefert der Einsatz des Grails-Frameworks vor allem Vorteile in den Bereichen Prototyping und der
Erweiterbarkeit eines Systems durch Grails-Plugins. Diese können zu einer Grails-Web-Applikation
entwickelt und installiert werden. Außerdem bietet das Grails-Framework die Möglichkeit, Java-Klas-
sen und Libraries in das System einzubinden. Im Fall des IDML-Servers wird dies mit dem Einsatz
der IDMLlib in Anspruch genommen. Die IDMLlib ist im Kontext des IDML-Servers dafür zuständig,
die Komplexität des IDML Formats zu kapseln und Zugang und Verarbeitung von IDML-Dateien zu
gewähren.
3.1.3 Webservice
Der Webservice des IDML-Servers muss die Anforderungen wie Vereinfachung, Einbindung und Er-
weiterbarkeit erfüllen.
In erster Linie sollte der Webservice selbsterklärend und einfach zu bedienen sein. Hier ist die Wahl
auf eine XML basierende REST-Schnittstelle gefallen, statt auf eine SOAP-Schnittstelle, da REST
über das Grails-Framework auf einfachem Weg zu implementieren ist. SOAP hingegen ist bei der
Implementierung des Webservices oftmals komplexer umzusetzen als REST. Die Wahl XML zu ver-
wenden beruht auch darauf, dass die meisten Webservice-Schnittstellen XML basierend sind und das
Einbinden der Schnittstelle auch für Dritte möglichst einfach gestaltet werden soll. Alternative zu

40. 40
XML wäre hier JSON. JSON hat im Vergleich zu XML eine einfachere Syntax. Diese ist kürzer und
minimalistischer ausgelegt. Für eine Weiterentwicklung des IDML-Servers kann eine JSON/REST
Schnittstelle auch über das Grails-Framework auf einfachem Weg implementiert werden.
Die Einbindung des IDML-Servers in bestehende Workflows erfolgt durch die REST-Schnittstelle. Die
Bedienung der REST-Schnittstelle ist im Vergleich zu SOAP einfacher umzusetzten. Der Hauptgrund
dafür ist, das REST keine festgelegte Norm ist und somit flexibler gestaltet werden kann. Außerdem
entfällt im Vergleich zu SOAP ein XML-Overhead, da REST beispielsweise kein WSDL benötigt.
Die Erweiterbarkeit der REST-Schnittstelle wird über eine Parameter-Liste gewährleistet. Diese be-
steht aus einer Anzahl fest definierter Parameter, die für eine spezielle Anfrage notwendig sind und
einer flexiblen Anzahl an Parametern, die individuell je nach Anforderung definiert werden können.
Der Webservice behandelt drei Arten von Anfragen:
Upload: Die Uploadanfrage ist zuständig für den Upload von Dateien, wobei der Webservice eine
Erfolgs- oder Fehlermeldung als Ergebnis zurückgibt.
Aktion: Eine Aktionsanfrage beinhaltet keine Binärdaten. Hier wird über die Anfrage mit spe-
ziellen Parametern eine bestimmte Aktion ausgeführt, die eine Erfolgs- oder Fehlermeldung als
Ergebnis zurückgibt.
Download: Eine Downloadanfrage liefert Binärdaten. Bei einem Fehler wird eine Fehlermeldung
als Ergebnis geliefert.
Da der Server von mehreren Akteuren bedient wird, soll das Konzept einer Session im IDML-Server
implementiert. Diese garantiert, dass ein Akteur in seinem eigenen Kontext arbeitet und keine Daten
anderer Akteuere manipuliert. Ein möglicher Ablauf könnte wie folgt aussehen:
1. Erzeugung einer Session und eines Universally Unique Identifier (UUID). Diese ID muss bei allen
weiteren Aktionen immer mitgegeben werden.
2. Upload von Dateien
3. Anstoß eines Verarbeitungsprozess
4. Download der Ergebnisse des Verarbeitungsprozess
5. Beendigung der Session
Abb. 9 Workflow Ablauf
Session
Erzeugung
Verarbeitung
Session
Beendigung
Datei
Upload
Datei
Download

41. 41
3.1.4 Process-Engine
Um zu verstehen, wie die Process-Engine aufgebaut ist, wird anhand des Ablaufs (Abb.9) jeder Schritt
beschrieben:
Session Erzeugung: Bei der Session-Erzeugung über den Webservice wird als erstes in der Pro-
cess-Engine eine UUID erzeugt. Diese UUID wird benötigt, um einen Sessionordner zu erzeugen,
in dem die Session dann für den weiteren Ablauf behandelt wird. In diesem Sessionordner werden
drei weitere Ordner erzeugt. Der erste ist ein Inputordner, welcher für die eingehenden Dateien
zuständig ist. Der zweite ist ein Outputordner, in dem die Ergebnisdateien der Verarbeitung plat-
ziert werden. Der dritte Ordner ist ein Temporaryordner, in dem Dateien platziert werden können,
die beispielsweise im Verarbeitungsprozess abgelegt werden müssen. Das Ergebnis der Session-
Erzeugung ist im günstigsten Fall eine Erfolgsmeldung. Dabei wird eine XML zurückgesendet,
welche die UUID enthält.
Datei Upload: Ist die Session erzeugt, können Dateien hochgeladen werden. Zwingend notwendig
ist dabei das Angeben der UUID. Anhand der UUID kann entschieden werden, in welchem Sessio-
nordner die Datei abgelegt wird. Alle hochgeladenen Dateien landen immer in dem Inputordner.
Das Ergebnis eines erfolgreichen Uploads ist wiederum eine XML, welche die UUID enthält.
Verarbeitung: Bei der Verarbeitung stellt sich die Frage, wie die Daten genau verarbeitet werden
sollen. Um dieses Problem möglichst flexibel zu gestalten, wird ein Workflowordner in dem Sys-
tem definiert. In diesem Ordner können weitere Ordner platziert werden. Diese Ordner repräsentie-
ren einen Workflow. In dem Ordner können individuelle Groovy-Skripte abgelegt werden und alle
nötigen Dateien, die für diesen Workflow benötigt werden. Die Gruppierung der Groovy-Skripte
in Workflows hat den Sinn, das System überschaulich und strukturiert verwalten zu können. Der
Workflow und das jeweilige Groovy-Skript kann über den Webservice anhand von definierten
Paramterern angesteuert und somit ausgeführt werden. Die Ausführung selber erfolgt dann in dem
Sessionordner, wobei die Dateien aus dem Inputordner für die Ausführung verwendet werden und
das Binär Ergebnis der Verarbeitung in dem Outputordner platziert wird. Das Groovy-Skript kann
dabei auf alle Libraries zugreifen, die im System verfügbar sind und somit jede Art von Dateien
verarbeiten. Es ist somit also nicht nur beschränkt auf IDML-Dateien, sondern kann beispielswei-
se auch XML verarbeiten. Das Ergebnis der Webservice-Anfrage ist wiederrum XML und besitzt
eine Anzahl an fest definierten Werten, die das System mitliefert, sowie einen frei gestaltbaren
Bereich, der in dem ausgeführten Groovy-Skript gesetzt werden kann.
Datei Download: Ist die Verarbeitung abgeschlossen und wurden dabei Binärdaten erzeugt, findet
man diese in dem Outputordner. Um nun Zugang auf die Dateien zu ermöglichen, kann der Out-
putordner heruntergeladen werden. Dabei wird der ganze Outputordner in ein ZIP-Format gepackt

42. 42
und über den Webservice zur Verfügung gestellt.
Session Beendigung: Nachdem alle Prozesse abgearbeitet wurden muss die Session nun auch
beendet werden. Dies kann über den Webservice angestoßen werden. Die Process-Engine löscht
durch den Anstoß über den Webservice den Sessionordner und alle enthalteten Informationen.
Sollte die Session nicht über den Webservice beendet werden existiert zusätzlich ein Task, der
zeitgesteuert über die bestehenden Sessionordner iteriert und kontrolliert, ob der Sessionordner
eine festgelegte Zeit überschritten hat. Ist dies der Fall, wird der Sessionordner gelöscht. Dadurch
können Sessions beendet werden, die beispielsweise versehentlich vergessen wurden beendet zu
werden.
3.2 Praktische Umsetzung
Um das Konzept (Kapitel 3.1) zu bestätigen und produktive Einsatzszenarien durchspielen zu können,
wird ein Prototyp entwickelt. Dieser hat keinen Anspruch auf Vollständigkeit und kann Fehler beinhal-
ten. Zunächst wird auf die Systemanforderungen eingegangen, die notwendig sind für den Prototypen.
Im nächsten Schritt wird detailliert die Funktionsweise des Prototyps beschrieben. Zum Schluss sind
die produktiven Einsatzszenarien relevant, die über die Groovy-Skripts implementiert werden.
3.2.1 Systemanforderungen
Die Systemanforderungen liegen zunächst im technischen Bereich. Als Betriebsystem sind Windows,
Linux oder Mac OS X zu empfehlen. Der Prototyp wird auf einem Mac OS X 10.7.5 entwickelt und
getestet. Auf dem jeweiligen Betriebsystem muss eine Java 6 Version installiert sein. Außerdem ist für
den Prototyp ein Tomcat notwendig. Zu empfehlen ist der Tomcat 6.0.32. Der zugewiesene Speicher
sollte mit 512 Megabyte generell ausreichen. Je nach Last und Größe der zu verarbeitenden Daten
kann der Wert variieren und sollte angepasst werden. Die verwendete Grails Version liegt bei 2.1.0 und
die IDMLlib Version bei 1.1.5. Die IDML-Daten, die in das System einfließen, sollten von InDesign
CS4 erzeugt worden sein und der Document Object Model (DOM) Version 6.0 entsprechen.
Weitere wesentliche Anforderungen ergeben sich durch die auszuführenden Groovy-Skripte, die nicht
direkt Teil des Servers sind, sondern individuell je nach Einsatzgebiet gestaltet werden können. Hier
ist vor allem das Verständnis für die Sprache Groovy und das IDML-Format notwendig, um diese
Groovy-Skripte erstellen zu können.
3.2.2 Prototyp
Der Prototyp orientiert sich an dem Konzept des IDML-Servers. Die Architektur des Prototyps beruht
somit auf der vorgegebenen Grails Architektur.
Der IDML-Server kann über das Kommando grails run-app gestartet werden. Ist die Applikation
gestartet kann sie unter http://localhost:8080/IDML-Server betrachtet werden. Dabei wird

43. 43
im Browser die Standard Index Seite dargestellt:
Abb. 10 IDML-Server Index Seite
Diese zeigt den Status der Applikation, die installierten Plugins und die Controller, die das System zur
Verfügung stellt. Bei genauer Betrachtung erkennt man in den Plugins auch den Tomcat Server, der mit
dem Kommando grails run-app gestartet wird.
Um den IDML-Server detailliert zu durchleuchten, werden alle Prozesse des Workflow Diagramms
(Abb.9) wiederum durchlaufen:
Session Erzeugung: Die Session-Erzeugung wird über den ProcessController angestoßen.
Klickt man über die Index Seite auf den ProcessController wird dabei die URL http://lo-
calhost:8080/IDML-Server/process/index aufgerufen. Der URL Teil process deutet
auf den Controller hin, der hier angesprochen wird. Der URL Teil index deutet auf die Action hin,
die ausgeführt werden soll. Dieses Verhalten der Controller ist einheitlich gelöst und vereinfacht
den Umgang mit dem System. Dieser URLAufbau ist standardmäßig von dem Grails-Framework
vorgegeben kann aber bei Bedarf unter config/UrlMappings.groovy angepasst werden:

44. 44
static mappings = {
ʺ/$controller/$action?/$id?"{
constraints {
// apply constraints here
}
}
"/"(view:"/index")
"500"(view:'/error')
}
Die Action in dem ProcessController sieht dabei wie folgt aus:
def index() {}
Diese Action ist sehr einfach gehalten. Was hier passiert ist, der Einsatz von CoC. Über die Be-
nennung der Action wird automatisch auf die zugehörige gleichnamige GSP-Seite verwiesen und
diese als Antwort auf die Anfrage zurückgegeben:
Abb. 11 IDML-Server Process Index Seite
Die GSP-Seiten dienen lediglich zur optischen Darstellung für den Entwickler oder Benutzer, der
den Webservice manuell testen möchte. Ein späterer produktiver Einsatz erfolg direkt über die
URLs.
Um eine Session zu erzeugen, kann die zugehörige URL http://localhost:8080/IDML-
Server/process/createSession aufgerufen werden. Diese spricht folgende Action im
ProcessController an:

45. 45
def createSession(){
def result = processService.createSession()
render result as XML
}
Hier wird die Funktion createSession() des ProcessServices angesprochen. Der Service
wird getrennt vom Controller in einer eigenen Schicht untergebracht, um eine klare Aufgabenver-
teilung zu haben. Die Serviceklassen sind im MVC-Muster im Bereich des Model anzuordnen.
Die createSession() Methode des ProcessServices sieht wie folgt aus:
def createSession() {
def id = UUID.randomUUID()
fileStructureService.createSessionStructure(id)
def result = [:]
result.put("type", "success")
result.put("id", id.toString())
return result
}
Hier wird dafür gesorgt, dass die Session ID und alle notwendigen Strukturen erzeugt werden.
Als erstes wird eine zufällige UUID generiert. Anhand dieser UUID wird über den FileStruc-
tureService die Funktion createSessionStructure(id)aufgerufen. Diese ist dafür ver-
antwortlich die lokale Ordnerstruktur zu erzeugen, in der später dann die Verarbeitung stattfindet:
def createSessionStructure(id) {
new File(getInPath(id)).mkdirs()
new File(getOutPath(id)).mkdirs()
new File(getTmpPath(id)).mkdirs()
}
Das Erzeugen der Pfade wird in weitere Funktionen ausgelagert. Hier wird nur die Funktion ge-
tInPath() betrachtet, da alle anderen sehr ähnliche Funktionsweisen aufweisen. Diese Funktion
baut den Inputordner Pfad anhand konfigurierter Eigenschaften, die in der config.properties ge-
setzt werden, auf. Um auf diese Eigenschaften zugreifen zu können, bietet das Grails-Framework
das Interface GrailsApplication. Über diese kann dann direkt auf die config.properties und
die darin konfigurierten Werte zugegriffen werden (grailsApplication.config...):

46. 46
def getInPath(id) {
getWorkPath() + id + File.separator + grailsApplication.config.idml.
server.local.work.in.folder.name + File.separator
}
In der config.properties ist somit folgender Name für den Inputordner definiert:
idml.server.local.work.in.folder.name=in
Die config.properties Datei ist dabei eine extern verwaltete Konfigurationsdatei. Diese liegt nor-
malerweise außerhalb der Applikation. Der Grund für die externe Verwaltung ist, dass sich bei
Updates oder Bugfixes eines Systems oft die Konfiguration gar nicht ändert. Anstatt jedes Mal
erneut die Applikation zu konfigurieren, kann so nur die Applikation ausgetauscht und die Konfi-
guration beibehalten werden. Die config.properties muss eingebunden werden, damit das System
auch Zugriff auf die Daten hat. Dies erfolgt über die JVM option -Didmlserver.config.loca-
tion=/path/to/config.properties. Wie diese JVM option benannt ist, wird in der config/
config.groovy definiert:
grails.config.locations = []
if(System.properties["idmlserver.config.location"]) {
grails.config.locations << "file:" + System.properties["idmlserver.
config.location"]
}
Sind die Pfade und alle notwendigen Ordner erzeugt, wird in der createSession() Funktion
ein Ergebnis erstellt. Dieses Ergebnis ist vom Typ Map und beinhaltet einen type und die UUID.
Die Wahl, das Ergebnis als eine Map zu realisieren, hat den Grund, dass eine Map dynamisch er-
weiterbar ist und der Zugriff auf die Werte sehr einfach über Schlüsselwörter erfolgen kann. Einer
dieser Schlüsselwörter ist type. Dieser ist dafür zuständig zu unterscheiden, ob das Ergebnis ein
erfolgreiches oder ein fehlgeschlagenes Ergebnis ist.
Ist das Ergebnis erzeugt, wird es zurück an den Controller gegeben, der nichts anderes macht als
diese Map als XML zu rendern (render result as XML).
Das XML Ergebnis was zurückgegeben wird sieht wie folgt aus:
<map>
<entry key="type">success</entry>
<entry key="id">764c7d8e-c276-4ef2-be2f-45b00fda0868</entry>
</map>

47. 47
Das Wichtigste an diesem Ergebnis ist die ID. Diese muss während des ganzen Prozesses mitge-
liefert werden. Sie sorgt für die eindeutige Identifizierung der Session.
Datei Upload: Nachdem die Session erzeugt wurde, kann nun eine Datei in das System hochge-
laden werden. Dies erfolgt über den UploadController. Der UploadController enthält die
Funktion upload(). Diese kann über die URL http://localhost:8080/IDML-Server/
upload/upload angesteuert werden. Dabei werden die Parameter id und file für einen erfolg-
reichen Upload benötigt:
def upload() {
def id = params.id
def result = [:]
if (id) {
result = uploadService.uploadFile(id, request.getFile("file"))
} else {
def errormessage = "error: ID does not exists!"
result.put("type", "error")
result.put("errormessage", errormessage)
}
render result as XML
}
Sind diese Parameter verfügbar, wird die Datei über den UploadService mit der Funktion
uploadFile(id, file) in das System hochgeladen:
def uploadFile(id, file) {
def targetDirPath = fileStructureService.getInPath(id)
def targetPath = targetDirPath + File.separator + file.originalFile
name
def uploadedFile = new File(targetPath)
file.transferTo(uploadedFile)
def result = [:]
result.put("type", "success")
result.put("id", id.toString())
return result
}
Dabei wird als erstes der Pfad zum Inputordner der jeweiligen Session zusammengebaut, an

48. 48
dem die Datei platziert werden soll. Dies geschieht wiederum in einer speziellen Service-Klasse
(FileStructureService) die diese Art von Aufgabenstellung übernimmt. Anschließend wird
die Datei hochgeladen und ein Ergebnis vom Typ Map erzeugt, der wiederum die UUID und einen
type enthält. Wird im UploadController keine UUID als Parameter übergeben, wird sofort
ein Ergebnis mit einer Fehlermeldung erzeugt. In beiden Fällen wird die Map vom Controller in
XML gewandelt und zurückgegeben. Die XML sieht bei einem erfolgreichen Upload wie folgt
aus:
<map>
<entry key="type">success</entry>
<entry key="id">764c7d8e-c276-4ef2-be2f-45b00fda0868</entry>
</map>
Verarbeitung: Ist der Upload der Daten abgeschlossen, kann nun mit dem Verarbeitungsprozess
begonnen werden. Zum Anstoßen einer Verarbeitung wird der ProcessController verwendet.
Dieser enthält die Action execute():
def execute() {
def result = processService.executeScript(params?.script, params?.
workflow, params?.id, params)
render result as XML
}
Die Action greift auf den ProcessService zu und führt die executeScript() Funktion aus.
Das Ergebnis wird als XML wieder zurückgegeben. Die executeScript() Funktion erwartet
mindestens drei Parameter. Der erste Parameter ist der Skript-Parameter. Dieser identifiziert das
Groovy-Skript, das ausgeführt werden soll. Auch hier wird wieder CoC angewendet, um mög-
lichst einheitlich und einfach die Verarbeitung anzustoßen. Der zweite Parameter ist der Work-
flow-Parameter. Dieser definiert den Workflow, der angestoßen wird. Die Groovy-Skripte sind in
mehrere Workflows gruppiert. Dadurch können dieselben Skripte in unterschiedlichen Workflows
verwendet werden. Die Gruppierung der Skripte in Workflows dient vor allem der Strukturierung
der Skripte. Der dritte Parameter ist der UUID Parameter. Hier wird die UUID der Session erwar-
tet. Durch diese UUID kann die Session identifiziert werden. In dem Kontext der Session wird
dann das Skript ausgeführt. Als letztes erwartet die Funktion das ganze Parameter-Objekt. Dieses
Parameter-Objekt enthält alle Parameter, die übergeben wurden. Dies bietet die Möglichkeit, wei-
tere individuelle Parameter mitzugeben, die unter Umständen in dem Skript benötigt werden.
Die programmatische Ausführung sieht wie folgt aus:

49. 49
def executeScript(script, workflow, id, Map<String, String> params) {
def result = [:]
def binding = handleParams(params, id)
String[] roots = getRoots()
GroovyScriptEngine gse = new GroovyScriptEngine(roots);
def scriptPath = fileStructureService.getScriptPath(workflow, script)
def scriptFile = new File(scriptPath)
if (scriptFile.exists()) {
result = gse.run(scriptPath, binding);
result.put("type", "success")
} else {
def errormessage = "error: script does not exists!"
result.put("type", "error")
result.put("errormessage", errormessage)
log.error(scriptFile.getAbsolutePath() + ", " + errormessage)
}
result.put("workflow", workflow)
result.put("script", script)
result.put("id", id.toString())
return result
}
Zunächst werden durch die Funktion handleParams() alle Parameter und Werte, die übergeben
werden in ein Binding platziert:
def handleParams(Map<String, String> params, id) {
Binding binding = new Binding();
params.keySet().each {key ->
binding.setVariable(key, params.get(key));
}
binding.setVariable("inPath", fileStructureService.getInPath(id))
binding.setVariable("outPath", fileStructureService.getOutPath(id))
return binding
}
Durch das Binding hat das auszuführende Skript später Zugriff auf die jeweiligen Parameter und
kann somit alle nötigen Informationen verwerten. Außerdem werden der Inputordner Pfad und der
Outputordner Pfad für die nötigen Zugriffe in das Binding gesetzt. Ist das Binding gesetzt, gibt

50. 50
es zusätzlich noch die Möglichkeit Zugriff auf weitere Ressourcen zu nehmen. Über die getRo-
ots() Funktion können weitere Klassenpfade (Classpath) in die Ausführung mit eingebunden
werden. Diese Klassenpfade können URLs oder lokale Pfade sein, die über die config.properties
Datei gesetzt werden können.
String[] getRoots() {
def commaRoots = grailsApplication.config.idml.server.groovy.script.
engine.roots
def roots = commaRoots.split(",")
return roots
}
Als nächstes wird das GroovyScriptEngine Objekt mit den optionalen Klassenpfaden erzeugt.
Dieses Objekt ist für die Ausführung des Skripts verantwortlich. Welches Skript ausgeführt wer-
den soll, wird über den workflow und den script Parameter entschieden. Der FileStructure-
Service sorgt dafür, dass der richtige Pfad des Skripts erzeugt wird. Ist das Skript verfügbar, wird
das Groovy-Skript mit den jeweiligen Bindings ausgeführt. Das Ergebnis der Skriptausführung
muss eine Map sein. Diese Map kann in den Skripten dann mit den Ergebniswerten befüllt werden,
die für das jeweilige Szenario relevant sind. Somit hat der Entwickler des Skripts eigenständig
die Möglichkeit zu entscheiden, was als Ergebnis angezeigt werden soll. Zu dieser Map wird zu-
sätzlich ein success type hinzugefügt. Ist das Skript jedoch nicht verfügbar, wird eine Fehler-
meldung und der zugehörige error type dem Ergebnis hinzugefügt. Zum Schluss werden die
drei erforderlichen Parameter script, workflow und id unabhängig von Erfolg oder Fehlschlag
des Skriptes dem Ergebnis hinzugefügt. Ein Ergebnis in XML-Darstellung könnte dann wie folgt
aussehen:
<map>
<entry key="type">success</entry>
<entry key="workflow">export</entry>
<entry key="script">ExtractText</entry>
<entry key="id">764c7d8e-c276-4ef2-be2f-45b00fda0868</entry>
</map>
Datei Download: Nachdem der Verarbeitungsprozess durchlaufen wurde, können die Ergebnisse
als XML an den Anfragenden zurückgegeben worden sein. Aber es können auch Binärdaten er-
zeugt worden sein. Um Zugang zu diesen Binärdaten zu erhalten, gibt es die Möglichkeit über den
DownloadController den Outputordner herunterzuladen. Dieser Vorgang kann im Download-
Controller über die Action download() angestoßen werden:

51. 51
def download() {
def id = params.id
def resultFile = downloadService.getZippedOutFolder(id)
response.setContentType("application/zip")
response.setHeader("Content-disposition", "attachment;filename=${resu
ltFile.getName()}")
response.outputStream << resultFile.newInputStream()
}
Um den Outputordner herunterzuladen wird die UUID benötigt. Mit dieser kann der Download-
Service über die getZippedOutFolder() Funktion den als ZIP verpackten Outputordner be-
reitstellen:
def File getZippedOutFolder(id) {
def outFolder = new File(fileStructureService.getOutPath(id))
File outZipFile = new File(fileStructureService.getTmpPath(id) +
File.separator + outFolder.getName() + ".zip")
new AntBuilder().zip(destfile: outZipFile.getAbsolutePath(), basedir:
outFolder.getAbsolutePath())
return outZipFile
}
Über den FileStructureService werden die benötigten Output- und Temporaryordner Pfade
bereitgestellt. Anschließend wird mit dem AntBuilder dann der Outputordner gepackt und in
dem Temporaryordner abgelegt. Die Entscheidung den Outputordner zu packen, resultiert aus dem
Grund, dass unter Umständen die binären Ergebnisse sehr groß werden können. Um die Daten
möglichst performant bereitzustellen, wurde hier der ganze Ordner gepackt. Eine spätere Optimie-
rung dieser Funktion kann in einer zweiten Version des Servers erfolgen.
Die getZippedOutFolder() Funktion gibt somit den gepackten Outputordner zurück. Der Re-
sponse wird dann mit einem Header, ContentType und der gepackten Datei befüllt und an den
Anfragenden gesendet. So werden die Binärdaten aus dem Outputordner bereitgestellt und können
weiter verarbeitet werden.
Session Beendigung: Nach dem der Vorgang abgeschlossen ist, sollte die Session beendet wer-
den, um keine Dateileichen auf dem System zu haben. Dies kann über zwei Möglichkeiten erfol-
gen. Die erste und manuelle Möglichkeit erfolgt über den ProcessController. Dieser enthält
folgende Action:

52. 52
def closeSession() {
def id = params?.id
def result = processService.closeSession(id)
render result as XML
}
Notwendig für den Prozess ist die UUID. Diese wird entgegengenommen und an die closeSes-
sion() Funktion des ProcessServices übergeben.
def closeSession(id) {
fileStructureService.deleteSessionFolder(id)
def result = [:]
result.put("type", "success")
result.put("id", id.toString())
return result
}
Diese Funktion arbeitet ähnlich wie die createSession(). Sie unterscheiden sich lediglich dar-
in, dass sie die Sessionstruktur nicht erzeugt, sondern den Sessionornder mit der jeweiligen UUID
löscht. Das Löschen übernimmt der FileStructureService mit der Funktion deleteSes-
sionFolder():
def deleteSessionFolder(String id) {
def folder = new File(getWorkPath() + id)
FileUtils.deleteDirectory(folder)
}
Die zweite Möglichkeit die Session zu beenden, ist über den automatischen Task. Der Task ist in
der config/spring/resources.xml definiert:
<task:scheduler id="singleTaskScheduler" pool-size="1"/>
<task:scheduled-tasks>
<task:scheduled ref="cleanUpWorkDirService" method="run"
cron="${idml.server.tasks.cleanup.workdir.cronexpression}"/>
</task:scheduled-tasks>
Dieser greift zeitgesteuert auf die Funktion run() des CleanUpWorkDirServices zu. Die Zeit-
steuerung wird in der config.properties Datei über eine Cron Expression geregelt. Die run()

53. 53
Funktion sieht wie folgt aus:
def run() {
log.info("start cleanUpWorkDirTask")
new File(fileStructureService.getWorkPath()).eachFile {File
uuidFolder ->
if (uuidFolder.isDirectory()) {
def now = new Date()
long limit = grailsApplication.config.idml.server.tasks.
cleanup.workdir.time.limit as long
def folderDateWithLimit = new Date(uuidFolder.lastModi
fied() + limit)
if (now.after(folderDateWithLimit)) {
log.info("delete folder: " + uuidFolder.getAbsolute
Path())
fileStructureService.deleteSessionFolder(uuidFolder)
}
}
}
log.info("end cleanUpWorkDirTask")
}
Der Task betrachtet den Workordner in dem alle Sessionordner liegen. Alle Sessionordner werden
durchlaufen, um das Datum der letzten Änderung eines Ordners mit dem aktuellen Datum, plus
einem konfigurierbarem Werte, zu vergleichen. Wird dieser Wert übertroffen, wird der Session-
ordner als zu alt angesehen und direkt gelöscht. Sessions, die beispielsweise versehentlich nicht
beendet wurden, können somit automatisch nach einem festen konfigurierten Zeitlimit gelöscht
werden. Dies gewährleistet, dass eine Session eine maximale Lebensdauer hat.
3.2.3 Szenarien
In diesem Abschnitt werden die Szenarien beschrieben und dargestellt, welche Vorzüge diese haben
können. Sie werden über Groovy-Skripte realisiert und sind für den Verarbeitungsprozess verantwort-
lich. Die Groovy-Skripte gehören nicht direkt zum IDML-Server, können aber nach individuellen An-
forderungen entwickelt und in diesen eingebunden werden. Die Skripte sind auf vorgegebene IDML-
Dateien ausgerichtet. Diese sind speziell vorbereitet, um die ausgewählten Szenarien darstellen zu
können. Es werden sechs Skripte betrachtet, die jeweils ein Szenario darstellen: