Konzeption eines IDML Servers
Upcoming SlideShare
Loading in...5
×
 

Konzeption eines IDML Servers

on

  • 1,812 views

 

Statistics

Views

Total Views
1,812
Views on SlideShare
1,341
Embed Views
471

Actions

Likes
0
Downloads
12
Comments
0

9 Embeds 471

http://www.fhcon.de 268
http://pouryekta.com 114
http://pouryekta.wordpress.com 49
http://webbeta.fhcon.de 17
http://fhcon.de 15
https://pouryekta.wordpress.com 3
http://next.fhcon.de 2
http://kallisto.fhcon.de 2
http://webcache.googleusercontent.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Konzeption eines IDML Servers Konzeption eines IDML Servers Document Transcript

  • FOM Hochschule für Oekonomie & ManagementStudienzentrum EssenMaster-Thesiszur Erlangung des Grades einesMaster of Arts (M.A.)über das ThemaKonzeption eines IDML ServersvonPeyman PouryektaErstgutachter Professor Dr.-Ing. Torsten FinkeMatrikelnummer 198124Abgabedatum 2013-04-15
  • 2Inhaltsverzeichnis1 Einleitung........................................................................................................................................... 41.1 Sachliche Motivation................................................................................................................ 41.2 Ziele.......................................................................................................................................... 41.3 Leserkreis................................................................................................................................. 41.4 Typografische Konventionen.................................................................................................... 51.5 Literaturdiskussion................................................................................................................... 52 Grundlagen......................................................................................................................................... 62.1 Softwarearchitektur.................................................................................................................. 62.1.1 Definition........................................................................................................................ 62.1.2 Architekturmuster........................................................................................................... 82.1.3 Entwurfsmuster............................................................................................................. 102.2 Webservice............................................................................................................................. 122.2.1 Definition...................................................................................................................... 122.2.2 SOAP............................................................................................................................ 122.2.3 REST............................................................................................................................ 132.3 Grails...................................................................................................................................... 142.3.1 Einordnung................................................................................................................... 142.3.2 Groovy.......................................................................................................................... 152.3.3 Spring........................................................................................................................... 202.3.4 Konzepte....................................................................................................................... 212.3.5 Applikation................................................................................................................... 212.4 IDML...................................................................................................................................... 302.4.1 InDesign........................................................................................................................ 302.4.2 Dateiformat................................................................................................................... 322.4.3 IDMLlib........................................................................................................................ 353 Umsetzung....................................................................................................................................... 373.1 Konzept.................................................................................................................................. 373.1.1 Anforderungen.............................................................................................................. 373.1.2 Systemarchitektur......................................................................................................... 373.1.3 Webservice.................................................................................................................... 393.1.4 Process-Engine............................................................................................................. 413.2 Praktische Umsetzung............................................................................................................ 423.2.1 Systemanforderungen................................................................................................... 423.2.2 Prototyp........................................................................................................................ 423.2.3 Szenarien...................................................................................................................... 534 Schlussbetrachtung.......................................................................................................................... 61
  • 34.1 Ergebnisse.............................................................................................................................. 614.2 Bewertung.............................................................................................................................. 624.3 Blick in die Zukunft .............................................................................................................. 63Abbildungsverzeichnis........................................................................................................................ 65Abkürzungsverzeichnis....................................................................................................................... 66Literaturverzeichnis............................................................................................................................ 68Stichwortverzeichnis........................................................................................................................... 71
  • 41 EinleitungDiese 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 entwickeltwerden 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 MotivationIn der Druck- und Medienindustrie wird zur Erstellung von Medienprodukten häufig das ProgrammAdobe 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 CS4verantwortlich und zum anderen für die externe Verarbeitung von InDesign-Dokumenten. Dadurch dasIDML offengelegt wurde, können neue Möglichkeiten im Bereich von Automatisierungen außerhalbvon InDesign entwickelt werden. IDML ist jedoch ein komplexes Dateiformat und der Umgang damiterfordert 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 IDMLzu 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 automatisiertwerden. Ein weiterer Aspekt ist, dass einfache Aufgaben oft abhängig von InDesign sind, wodurchzusätzlicher Arbeitsaufwand sowie Lizenzkosten entstehen können. Durch den Einsatz von IDMLkann in bestimmten Bereichen eine von InDesign unabhängige und in andere Systeme integrierbareLösung geboten werden.1.2 ZieleDiese 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 LeserkreisDie Arbeit ist hauptsächlich an Personen aus der Informationstechnik gerichtet, die sich mit IDMLbeschäftigen und dessen Einsatzmöglichkeiten betrachten wollen. Ein grundsolides Vorwissen über
  • 5Softwareentwicklung 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 undsoll über die Referenzen aus dem Literaturverzeichnis herangezogen werden.1.4 Typografische KonventionenIn dieser Arbeit wird auf die typografischen Konventionen Wert gelegt, um dem Leser das komplexeThema 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 Italicausgezeichnet.Diagramm: Die Typografie in den Diagrammen wird in Arial mit 11 pt und 8 pt ausgezeichnet.1.5 LiteraturdiskussionDer 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 dasGrails- und das Spring-Framework eine zentrale Rolle in dieser Konzeption spielen, wurde hier aufden Verweis der Primärliteratur besonderer Wert gelegt. Rod Johnson (Spring-Framework), GraemeRocher (Grails-Framework) und Guillaume Laforge (Groovy) sind dabei die Köpfe der jeweiligenTechnologien. Zum Thema IDML ist kaum Literatur vorhanden, deshalb wird hauptsächlich mit derIDML-Spezifikation gearbeitet. Diese behandelt jedoch nicht ausreichend den Einsatz von IDML,weshalb Vorwissen über InDesign und eine eigenständige Motivation zur Erarbeitung von Kenntnissenim Bereich IDML vorausgesetzt wird.
  • 62 GrundlagenDieses 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) betrachtetsowie 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 überhauptInDesign ist. Danach wird das Dateiformat IDML betrachtet und sein Aufbau beschrieben. Danachwird 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 SoftwarearchitekturIn diesem Abschnitt wird der Begriff Softwarearchitektur erläutert. Es beginnt mit der Definition desBegriffes. Dann wird auf dieArchitekturmuster und Entwurfsmuster eingegangen. Diese sind abstrakteBeschreibungen einer Lösung für häufig vorkommende Probleme. Dabei betrachtenArchitekturmusterzum einen das gesamte System, während Entwurfsmuster auf sehr spezielle Probleme ausgerichtetsind.2.1.1 DefinitionSoftwarearchitektur 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 Stilder Softwarearchitektur.Das Carnegie Mellon Software Engineering Institute (SEI) stellt auf seiner Webseite mehr als 100Definitionen zur Verfügung [vgl. Carnegie2012]. Anhand dieser Sammlung kann grundsätzlich gesagtwerden, dass Softwarearchitektur sich mit folgenden Aspekten beschäftigt:
  • 7Struktur: Eine Softwarearchitektur beschreibt die Komponenten eines Softwaresystems. Es gehthierbei nicht nur um den Aufbau, sondern auch um das Zusammenspiel, die Beziehungen und dieEigenschaften der Komponenten. Somit ist die Softwarearchitektur nicht nur der Bauplan, sondernauch der Ablaufplan des Softwaresystems. [vgl. Starke2009, S.16] Eines ihrer der Hauptziele istes, 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. Siebeschreibt eine Lösung und besteht aus abstrakten Komponenten. Diese Pläne führen durch diekonkrete 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 einewichtige 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 dieFunktionsweise 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• scenarioDurch 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 genaueErläuterung der Sichten ist zu finden unter: [Kruchten1995, S.1f].Verständlichkeit: Eine Softwarearchitektur schafft Ordnung und ermöglicht einen Überblick überdas 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.
  • 8Denn nur so können alle Beteiligten ein Verständnis über die einzelnen Komponenten und derenZusammenspiel 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 flexibelzu erweitern. [vgl. Starke2009, S.19] Das bedeutet auch, dass in der Praxis generell keine perfekteSoftwarearchitekturen 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 wesentlichenKerneigenschaften 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ätetc. [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 ArchitekturmusterArchitekturmuster unterstützen bei der Entwicklung eines Softwaresystems, da sie dieses aus einerabstrakten und ganzheitlichen Sicht beschreiben. Im Folgenden wird das Schichtenmuster und dasModel 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 Aufgabeund bietet der darüber liegenden Schicht eine definierte Anzahl an Diensten an. Der Aufbau einessolchen 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 erfolgtgenerell über die darüber liegende Schicht. Eine Mehrfachnutzung von Diensten durch andereSchichten 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.
  • 9Folgende 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 dientder Strukturierung von Softwaresystemen und beinhaltet die Einteilung in drei Einheiten: Model(Datenmodell), View (Präsentation) und Controller (Programmsteuerung). Ziel des MVC Mustersist 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 direkteund 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 derDaten.• Der Controller ist für die Steuerung verantwortlich. Er interpretiert die Operationen, die überdie View kommen und bestimmt den Folgezustand der Anwendung.[vgl. Starke2009, S.247]Abb. 1 MVC Ablauf [vgl. Starke2008, S.247]ModelView ControllerStatusabfrage StatusänderungNeuer StatusView anzeigenBenutzer Eingabe
  • 10Diese beiden Architekturmuster werden häufig verwendet, um die ganzheitliche Sicht eines Systemszu organisieren. Oft tauchen während der Implementierungsphase jedoch auch Probleme auf, die nichtmit Architekturmustern abgedeckt werden können. Hier setzen Entwurfsmuster an.2.1.3 EntwurfsmusterEin 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 derLö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 zusehen, 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 denProzess der Erzeugung und vereinfachen den Umgang damit. Der Einsatz von Erzeugungsmusterngewä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
  • 11zwischen den Objekten. Der Einsatz von Verhaltensmustern kann die Flexibilität der Software imBereich der Kommunikation zwischen Objekten erhöhen. [vgl. Gamma2011, S.271]Entwurfsmuster werden häufig in Frameworks verwendet. Für die spätere Umsetzung werden hiereinige 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 einemglobalen Zugriff darauf. Um dies zu gewährleisten, wird die Zuständigkeit der Verwaltung desExemplars in die Klasse gelegt. Die Klasse selber kann somit entscheiden, ob ein neues Objekterzeugt 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 trenntdie Erzeugung des Objektes von seiner Representation. Somit kann derselbe Erzeugungsprozessunterschiedliche Representationen hervorbringen. [vgl. Gamma2011, S.119f]Command: Das Command Entwurfsmuster ist ein Verhaltensmuster und ist objektbasierend. DerZweck des Musters ist die Vereinfachung bei Ausführung mehrerer komplexer Aktionen. Dabeiwird eine Anfrage in ein Command gekapselt. Durch das Ausführen eines Commands werdenmehrere Aktionen ausgeführt, die von außen nicht ersichtlich sind. Entwurfsmuster werden auchhäufig miteinander kombiniert. Zum Erzeugen von Commands kann zum Beispiel das BuilderEntwurfsmuster verwendet werden. [vgl. Freeman2004, S.206]State: Das State Entwurfsmuster gehört zu den Verhaltensmustern und ist objektbasierend. DerZweck des Musters ist es Objekten die Möglichkeit zu geben, ihren Zustand zu definieren und aufdiesen aufmerksam zu machen. Eine Kombination mit dem Command-Entwurfsmuster könnteso aussehen, dass sich bei der Beendigung der Ausführung eines Commands der Zustand einesObjekts ä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 ineine Software.Ein weiterer wichtiger Aspekt von Softwaresystemen ist die Bedienung. Oftmals wird die Bedienungdes Systems über eine Benutzeroberfläche realisiert. Ist das System jedoch auf die Kommunikationmit anderen Maschinen ausgerichtet, so kann die Kommunikation über einen Webservice stattfinden.
  • 122.2 WebserviceDer folgende Abschnitt beginnt mit der Definition des Begriffs Webservice. Danach werden wie zuvorerwähnt die Technologien SOAP und REST beschrieben und ihre Funktionsweise voneinander abge-grenzt.2.2.1 DefinitionIn der Literatur und in verschiedenen Fachzeitschriften existiert eine Vielzahl von Definitionen desBegriffs 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 amanner prescribed by its description using SOAP messages, typically conveyed usingHTTP 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 undkann 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 einemplattformunabhängigen Kommunikationsformat.2.2.2 SOAPUrsprü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.2vor, 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 einemWebservice erfolgt dies in den häufigsten Fällen über HTTP. Dabei stellt sich die Frage, wie dieseDaten 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. Indiesem wird der Namesraum der Nachricht definiert:
  • 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-NachrichtWSDL: 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 Operationender zu versendenden Nachrichten und Datentypen. Außerdem kann WSDL definieren, wie dieserWebservice 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 RESTREST 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 überHTTP. [vgl. Fielding2000]Im Folgenden wird dargestellt, welche HTTP Standardmethoden REST im Webanwedungskontexthauptsächlich verwendet:EnvelopeHeaderBody
  • 14GET: Beim Aufruf einer GET-Methode wird vom Server eine Ressource gefordert. Dabei kanneine GET-Anfrage beliebig oft abgesendet werden. Die Methode kann ähnlich betrachtet werdenwie 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 ähnlichbetrachtet werden, wie die Update-Methode bei Datenbankoperationen. [vgl. Bayer2002]PUT: Beim Aufruf einer PUT-Methode wird vom Server eine Änderung einer Ressource gefordertoder eine neue erzeugt. Die Methode kann ähnlich betrachtet werden, wie die Kombination ausCreate- 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 GrailsDieser 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 einwesentlicher Bestandteil des Frameworks ist. Außerdem wird auf das Spring-Framework eingegangensowie die Konzepte des Grails-Frameworks. Im letzten Abschnitt wird der Aufbau einer Grails-Appli-kation betrachtet.2.3.1 EinordnungDas 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. Abbildung3 veranschaulicht die Beziehungen:Abb. 3 Grails Einordnung [vgl. Rocher2009, S.3]Java Virtual MachineJavaGroovyJDKJava EE Spring Hibernate SiteMashGrails
  • 15SiteMesh ist dabei ein Layout Framework mit dem es möglich ist, Seitendekorationen in der View aufeinfachem 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 GroovyGroovy ist eine dynamische Programmiersprache, die in der Java Virtual Machine (JVM) läuft. Esliegt mit der Sprache Java auf einer Ebene und bedient sich auch ihrer. Groovy kann somit als eineErweiterung 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 denEigenschaften der Sprachen Python, Ruby und Smalltalk inspiriert. [vgl. König2007, S.3f] Es folgendie 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, dassdie 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 beider Ausführung. Dadurch, das während der Laufzeit der Code verändert werden kann, und somitneu 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) mitzusätzlichen Methoden und der funktionalen Erweiterung durch Closures. Dabei werden automa-tisch folgende Importierungen eingebunden:Plattform (Linux, Windows...)Java Virtual MachineJavaGroovy
  • 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 inGroovy mit print aufgerufen. [vgl. Grandeur2009, S.13]Closure: Eines der wichtigsten Konzepte in Groovy ist das Konzept der Closure. Sie stammen ausdem 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 verwendetwerden 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. Wennnur ein Argument verwendet wird, wird automatisch auf das Argument mit dem Schlüsselwort itreferenziert. [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]
  • 17print Halloprint 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.Stringdef append(word){Hallo + word}append(Welt!)//Input: String, Ausgabe: Hallo Wellt!Integer i = 20append(i)//Input Integer, Ausgabe: Hallo 20GString: 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.Stringprintln gstring//Ausgabe: Hallo Welt!
  • 18println gstring.class//Ausgabe: class org.codehaus.groovy.runtime.GStringImplCollections: In Groovy gibt es drei Arten von Collections: List, Map und Range. List und Mapsind 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..10println list.get(0)//Ausgabe: aprintln map.get(1)//Ausgabe: bprintln 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
  • 19def empty = nullprintln empty.size()//Ausgabe: java.lang.NullPointerException: Cannot invoke method size()on null objectprintln empty?.size()//Ausgabe: nullScripting: 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ührtwerden. Es ist nicht zwingend notwendig wie in Java Klassen zu erstellen. Ein einfaches Skript(test.groovy) könnte wie folgt aussehen:#!/usr/bin/env groovyprintln "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 MicrosoftSteve Jobs works for Apple
  • 20Jonathan Schwartz works for Sun*/2.3.3 SpringSpring 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 werdenkönnen, aber nicht zwingend erforderlich sind. Außerdem hat es den Anspruch, den Anwendungscodeunabhä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 folgendenDiagramm 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 RuntimeData Access/IntegrationAOPWeb (MVC/Remoting)Aspects IntrumentationCore ContainerTestBeans Core ContextExpressionLanguageWebPortletServletStrutsJDBS ORMOXM JMSTransactions
  • 21DI: 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. Beibeiden Möglichkeiten wir die Konfiguration der Klassen entweder über Annotationen oder übereine externe XML-Datei konfiguriert.2.3.4 KonzepteDas Grails-Framework hat zum Ziel, die Java Enterprise Web Entwicklung zu vereinfachen und aufdie 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 andie 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 Vorteiledieser 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 mansich auf Konventionen, wie beispielsweise gleichartige Benennungen, die dann dafür sorgen, dassKonfigurationen wegfallen können. Ein Beispiel dafür ist die Benennung von Datenbanktabellenund 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 Systemserhö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. Diesist folglich zeit- und kostenintensiv. Durch das DRY-Prinzip wird dieses Problem minimiert. [vgl.Hunt2003, S.25f]2.3.5 ApplikationEine 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]
  • 22Um 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 allenotwendigen Dateien erstellt.Der Aufbau einer Grails-Applikation sieht dabei wie folgt aus:Abb. 6 Grails ApplikationDie application.properties Datei hält Properties, die angepasst werden können. In dieser Datei sindbeispielsweise 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 verwendetwerden, 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 Applikationmit 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
  • 23src Ordner, die als Bean in der Grails-Applikation verwendet werden sollen, so kann diese hiereingebunden werden. Die Spring-Konfiguration kann dann als XML oder in Groovy definiert wer-den.Die UrlMappings.groovy definiert ein einheitliches Uniform Resource Locator (URL) Verhaltender Applikation.domain: In dem domain Ordner werden die Domain-Klassen abgelegt. Die Erzeugung kann überdas Kommando grails create-domain-class erfolgen. Wird eine Domain-Klasse erzeugt,sind Objekte dieser Klasse immer direkt auch Objekte, welche in der Datenbank abgelegt werdenkönnen. Zu der Domain-Klasse Person gibt es beispielsweise direkt auch eine Datenbank-Tabelledazu.Domain-Klassen können außerdem constraints besitzen. Das sind Angaben zu Attributen derKlasse, 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 leersein 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). Dieserleichtert 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)
  • 24Dabei fällt auf, dass die Klasse Person keine get() Methode definiert. Alle Domain-Klassenbekommen 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 bekommenkann 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() Methodeverwendet: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örternzusammen:Person.findByFirstnameAndLastname("John","Doe")service: In dem service Ordner werden Service-Klassen abgelegt. Erzeugen kann man diese überdas 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]
  • 25class 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änderungenbehandeln. Somit müssen die Service-Klassen transaktional sein. Jede bietet die Möglichkeit dieTransaktionalitä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 garnicht ausgeführt wird.• Consistency bedeutet, dass nach der Ausführung einer Transaktion die Datenbank konsistentsein 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 dauerhaftin der Datenbank abgespeichert werden.[vgl. Rocher2009, S.295f]Service-Klassen können unterschiedliche scopes aufweisen. Bei Bedarf kann diese Eigenschaftangepasst 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.
  • 26controller: In dem controller Ordner werden Controller-Klassen abgelegt. Erzeugen kann mandiese mit dem Kommando grails create-controller. Controller-Klassen behandeln dieeingehenden Anfragen. Sie entscheiden wie die Anfrage verarbeitet wird und liefern ein Ergebnisan 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 mitdem 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 ObjectNotation (JSON) zurückgeben. Dies wird im Zusammenhang mit Asynchronous JavaScript and
  • 27XML (AJAX) oder beispielsweise direkt als Webservice verwendet. Die einfachste Möglichkeit,die Grails hier bietet, sind die grails.converters.*.import grails.converters.XMLdef person = Person.get(id)render person as XMLimport grails.converters.JSONdef person = Person.get(id)render person as JSONEine 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 Prototypingeingesetzt, um eine erste Version zu erstellen. Scaffolding kann in Grails dynamisch und statischverwendet werden. Das dynamische Scaffolding von einer CRUD-Anwendung erzeugt währendder 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. Mitdem Kommando grails generate-views werden die dazugehörigen Views erzeugt. Möchteman 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 JavaServer Pages (JSP) angelehnt, haben jedoch Vorteile, die durch die Sprache Groovy mitgebrachtwerden, 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 Benennunghaben, 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<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 dreiunterschiedliche Arten von Tags:Built-in Tags sind vordefinierte Tags, die das Framework Grails bietet. Sie werden beispielsweiseals 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. Einerseitskö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 zurealisieren:<a href="${createLink(action:list)}"> dynamic link</a>
  • 29Diese 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 Anspruchgenommen werden können.Im scripts Ordner können zusätzliche Skripte hinterlegt werden. Diese können dann über das grailsKommando ausgeführt werden.Der src Ordner beinhaltet einen java und einen groovy Ordner. In diesen Ordnern können jeweilsJava und Groovy Code eingebunden werden. Gibt es beispielsweise bereits Businesslogik, die in Javaimplementiert wurde, können die Java-Klassen hier in dem java Ordner platziert und somit von derGrails-Applikation genutzt werden.In dem test Ordner werden Integrationstests und Unittests platziert. Hier kann die Funktionalität derApplikation ausgiebig getestet werden.Der web-app Ordner beinhaltet den WEB-INF Ordner mit den Spring und SiteMesh Konfigurations-
  • 30dateien. 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 IDMLDieser 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 Abschnittwird eine Möglichkeit dargestellt, IDML-Dateien zu verarbeiten.2.4.1 InDesignInDesign 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 dieserzu 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 Typografieund 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, diedas 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 angelegtwird.• Spalten können eine Struktur in dem Dokument erzeugen. Die Anzahl der Spalten und derjeweilige Steg1kann angegeben werden.1 Als Steg wird der Abstand zwischen den Spalten bezeichnet.
  • 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 Blitzer2zu vermeiden.Elementplatzierung: Ist das Dokument erstellt, können auf diesem unterschiedliche Arten vonElementen platziert werden:• Text-Elemente werden für die Textdarstellung verwendet. Hier können umfangreiche typo-grafische Auszeichnungen vorgenommen werden und Stile auf Absatz- oder Zeichenebenezugewiesen 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 wiederumInhalte 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 InDesigngenutzt 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), welchesim 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.
  • 322.4.2 DateiformatDas 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 basierendist, aber es nur maschinenlesbar und somit hauptsächlich nur für den internen Gebrauch in InDesignverwendet 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-Dateienextern 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 IDMLgeht. IDML liefert keine Funktionen, die in InDesign verfügbar sind.Lesbarkeit: IDML hat den Anspruch menschenlesbar und verständlich zu sein. Jemand der dengrundlegenden Umgang mit InDesign kennt, soll sich im IDML-Dokument zurecht finden können.Verarbeitung: IDML-Dokumente sollen durch externe Applikationen gelesen und geschriebenwerden können.Robustheit: Das IDML-Format soll robust sein. Das bedeutet Fehler in einem IDML-Dokumentsollten keine schwerwiegenden Auswirkungen haben. Das Regular Language Description forXML New Generation (RNG) Schema definiert den Aufbau einer IDML und bietet somit Validie-rungsmöglichkeiten, um grobe Fehler in IDML zu vermeiden.
  • 33Rückwärtskompatibilität: Die Rückwärtskompatibilität zu einer Vorgängerversion soll durchIDML 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 zumeinen 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 undEncoding betreffen. [vgl. Adobe2012, S.394f]Der Aufbau des IDML Formats sieht wie folgt aus:Abb. 7 IDML Container Aufbau [Adobe2012, S.20]
  • 34Multipurpose 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-packagedesignmap.xml: Diese XML ist das Rückgrad der IDML-Datei. Alle weiteren Dateien in derIDML werden von ihr referenziert. Außerdem sind die Reihenfolge und Beziehungen, die in dieserXML 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 Definitionenkann referenziert werden. [vgl. Adobe2012, S.263f]• Die Fonts.xml definiert Defaultschriften und alle Schriften, die in dem InDesign-Dokumentverwendet werden. [vgl. Adobe2012, S.259f]• Die Styles.xml definiert alle Stile, die in dem InDesign-Dokument definiert werden. Dazuzä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 zufinden ist. [vgl. Adobe2012, S.23f]Stories: Stories definieren den Textinhalt eines Dokumentes. Der Stories Ordner hält alle Stories,
  • 35die 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 inden 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 UCFStandard und referenziert auf die designmap.xml. Zum anderen metadata.xml welche beispiels-weise Extensible Metadata Platform (XMP) und Resource Description Framework (RDF) Inhaltedefinieren. [vgl. Adobe2012, S.401f]2.4.3 IDMLlibDie 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 undeine Schnittstelle zu bieten, mit der es möglich ist IDML-Dokumente zu verarbeiten. IDMLlib kannIDML-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 ErfahrungDie IDMLlib läuft auf den Betriebssystemen Windows, Linux und Mac OS. Vorausgesetzt wird dasJDK 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.
  • 36Einige 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.
  • 373 UmsetzungDieses Kapitel beschäftigt sich mit der Umsetzung des IDML-Servers. Nachdem in Kapitel 2 dieGrundlagen betrachtet wurde, wird zunächst auf das Konzept des IDML-Servers eingegangen. ImKapitel 3.2 erfolgt darauf die praktische Umsetzung, welche die Realisierung des Konzepts bestätigensoll. Sowohl das Konzept, als auch die praktische Umsetzung bauen auf den vorherigen Grundlagen-kapitel auf.3.1 KonzeptDas 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 dieeingesetzten Frameworks definiert wird. Ferner werden Entwurfsentscheidungen hier festgelegt undbeschrieben. Im Anschluss darauf wird der Webservice definiert, der beim IDML-Server zum Einsatzkommt. 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 AnforderungenDas 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-Formatsehr 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 SystemarchitekturDie Systemarchitektur ergibt sich in erster Linie aus den Anforderungen. Eines der Ziele des Systemsist die Einbindung in bestehende Workflows. Da im Druck- und Medien-Bereich Workflowsysteme oftals zentrales Serversystem vorliegen, wird hier das Konzept eines IDML-Servers gewählt. FolgendeVor- und Nachteile ergeben sich bei dem Einsatz eines Servers:
  • 38Vorteile• Ein Server ist generell ein zentrales System und kann in Workflows integriert werden. In einemWorkflow können so Probleme schneller erkannt werden, da es eine klare Aufgabenverteilung gibtund 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 einemOrt 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 FailureDer 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 überden Komponente Webservice realisiert. Der Verarbeitungsbereich wird über die Komponente Process-Engine realisiert.Abb. 8 IDML-ServerAnfragen an den Server über den Webservice erfolgen über HTTP (üblicherweise wird HTTP/Port 80für Webservices gewählt, da Firewalls den Port 80 normalerweise nicht blockieren. Es kann jedochauch ein anderer Port definiert werden.). Die Anfragen sind in Form von Parametern oder Dateien zudefinieren. 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 dienötigen Funktionen aus und liefert ein Ergebnis. Das Ergebnis wird wieder zurück an den Webservicegeleitet, der die Daten als Antwort in Form von XML (üblicherweise wird XML verwendet. Es könnenjedoch auch andere Formate verwendet werden, wie zum Beispiel JSON.) an den Anfragenden wiederzurück sendet.IDML-ServerWebservice Process-EngineIDML, ParameterIDML, XML
  • 39Der Server ist nach dem MVC-Muster und dem Schichtenmuster aufgebaut. Dabei ist das Model imBereich der Process-Engine anzuordnen. Dieser ist zuständig für die Verarbeitung der Daten. Die Viewund der Controller sind im Bereich des Webservices einzuordnen. Die View ist hier die Darstellung derErgebnisse in Form von XML. Der Controller nimmt die Anfrage entgegen und ist dafür zuständig, dieDaten in der View darzustellen.Das Schichtenmuster wird in mehreren Bereichen angewendet. Einmal ist der Server im Kontext einesWorkflows 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) Webserviceund Process-Engine unterteilt. Auch diese Komponenten haben wieder eine klare Aufgabenstellung.Zuletzt ist der IDML-Server aus Entwicklersicht zu betrachten, in dem Programmteile in Schichtenunterteilt werden, um wieder Aufgabenbereiche klar zu definieren.Die konkrete Implementierung des Systems basiert auf Industriestandards, die sich im Laufe der Zeitbewiesen haben. Das gewählte Framework für die Implementierung ist das Grails-Framework. Diedarunterliegenden Technologien, wie beispielsweise Spring-Framework, Groovy, Java und IDMLlib,gewährleisten, dass die Anforderungen an das System erfüllt werden. Java und das Spring-Frameworkliefern dabei eine sehr große Anzahl an erprobten Libraries, die in unterschiedlichsten Bereichen derSoftwareentwicklung 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 derSkriptfä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 derErweiterbarkeit eines Systems durch Grails-Plugins. Diese können zu einer Grails-Web-Applikationentwickelt 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 Einsatzder 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 zugewähren.3.1.3 WebserviceDer 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 Wahlauf 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 derImplementierung 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 dasEinbinden der Schnittstelle auch für Dritte möglichst einfach gestaltet werden soll. Alternative zu
  • 40XML wäre hier JSON. JSON hat im Vergleich zu XML eine einfachere Syntax. Diese ist kürzer undminimalistischer ausgelegt. Für eine Weiterentwicklung des IDML-Servers kann eine JSON/RESTSchnittstelle auch über das Grails-Framework auf einfachem Weg implementiert werden.Die Einbindung des IDML-Servers in bestehende Workflows erfolgt durch die REST-Schnittstelle. DieBedienung der REST-Schnittstelle ist im Vergleich zu SOAP einfacher umzusetzten. Der Hauptgrunddafür ist, das REST keine festgelegte Norm ist und somit flexibler gestaltet werden kann. Außerdementfä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 undeiner 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 eineErfolgs- 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 alsErgebnis zurückgibt.Download: Eine Downloadanfrage liefert Binärdaten. Bei einem Fehler wird eine Fehlermeldungals Ergebnis geliefert.Da der Server von mehreren Akteuren bedient wird, soll das Konzept einer Session im IDML-Serverimplementiert. Diese garantiert, dass ein Akteur in seinem eigenen Kontext arbeitet und keine Datenanderer 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 allenweiteren Aktionen immer mitgegeben werden.2. Upload von Dateien3. Anstoß eines Verarbeitungsprozess4. Download der Ergebnisse des Verarbeitungsprozess5. Beendigung der SessionAbb. 9 Workflow AblaufSessionErzeugungVerarbeitungSessionBeendigungDateiUploadDateiDownload
  • 413.1.4 Process-EngineUm zu verstehen, wie die Process-Engine aufgebaut ist, wird anhand des Ablaufs (Abb.9) jeder Schrittbeschrieben: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 werdendrei weitere Ordner erzeugt. Der erste ist ein Inputordner, welcher für die eingehenden Dateienzustä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 notwendigist 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 werdensollen. 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 allenötigen Dateien, die für diesen Workflow benötigt werden. Die Gruppierung der Groovy-Skriptein Workflows hat den Sinn, das System überschaulich und strukturiert verwalten zu können. DerWorkflow und das jeweilige Groovy-Skript kann über den Webservice anhand von definiertenParamterern angesteuert und somit ausgeführt werden. Die Ausführung selber erfolgt dann in demSessionordner, wobei die Dateien aus dem Inputordner für die Ausführung verwendet werden unddas Binär Ergebnis der Verarbeitung in dem Outputordner platziert wird. Das Groovy-Skript kanndabei auf alle Libraries zugreifen, die im System verfügbar sind und somit jede Art von Dateienverarbeiten. 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 besitzteine Anzahl an fest definierten Werten, die das System mitliefert, sowie einen frei gestaltbarenBereich, der in dem ausgeführten Groovy-Skript gesetzt werden kann.Datei Download: Ist die Verarbeitung abgeschlossen und wurden dabei Binärdaten erzeugt, findetman 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
  • 42und über den Webservice zur Verfügung gestellt.Session Beendigung: Nachdem alle Prozesse abgearbeitet wurden muss die Session nun auchbeendet werden. Dies kann über den Webservice angestoßen werden. Die Process-Engine löschtdurch 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, derzeitgesteuert über die bestehenden Sessionordner iteriert und kontrolliert, ob der Sessionordnereine festgelegte Zeit überschritten hat. Ist dies der Fall, wird der Sessionordner gelöscht. Dadurchkönnen Sessions beendet werden, die beispielsweise versehentlich vergessen wurden beendet zuwerden.3.2 Praktische UmsetzungUm 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 sinddie produktiven Einsatzszenarien relevant, die über die Groovy-Skripts implementiert werden.3.2.1 SystemanforderungenDie 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 undgetestet. Auf dem jeweiligen Betriebsystem muss eine Java 6 Version installiert sein. Außerdem ist fürden Prototyp ein Tomcat notwendig. Zu empfehlen ist der Tomcat 6.0.32. Der zugewiesene Speichersollte mit 512 Megabyte generell ausreichen. Je nach Last und Größe der zu verarbeitenden Datenkann der Wert variieren und sollte angepasst werden. Die verwendete Grails Version liegt bei 2.1.0 unddie IDMLlib Version bei 1.1.5. Die IDML-Daten, die in das System einfließen, sollten von InDesignCS4 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 nichtdirekt Teil des Servers sind, sondern individuell je nach Einsatzgebiet gestaltet werden können. Hierist vor allem das Verständnis für die Sprache Groovy und das IDML-Format notwendig, um dieseGroovy-Skripte erstellen zu können.3.2.2 PrototypDer Prototyp orientiert sich an dem Konzept des IDML-Servers. Die Architektur des Prototyps beruhtsomit auf der vorgegebenen Grails Architektur.Der IDML-Server kann über das Kommando grails run-app gestartet werden. Ist die Applikationgestartet kann sie unter http://localhost:8080/IDML-Server betrachtet werden. Dabei wird
  • 43im Browser die Standard Index Seite dargestellt:Abb. 10 IDML-Server Index SeiteDiese zeigt den Status der Applikation, die installierten Plugins und die Controller, die das System zurVerfügung stellt. Bei genauer Betrachtung erkennt man in den Plugins auch den Tomcat Server, der mitdem 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 deutetauf 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 vereinfachtden Umgang mit dem System. Dieser URLAufbau ist standardmäßig von dem Grails-Frameworkvorgegeben kann aber bei Bedarf unter config/UrlMappings.groovy angepasst werden:
  • 44static 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 unddiese als Antwort auf die Anfrage zurückgegeben:Abb. 11 IDML-Server Process Index SeiteDie GSP-Seiten dienen lediglich zur optischen Darstellung für den Entwickler oder Benutzer, derden Webservice manuell testen möchte. Ein späterer produktiver Einsatz erfolg direkt über dieURLs.Um eine Session zu erzeugen, kann die zugehörige URL http://localhost:8080/IDML-Server/process/createSession aufgerufen werden. Diese spricht folgende Action imProcessController an:
  • 45def createSession(){def result = processService.createSession()render result as XML}Hier wird die Funktion createSession() des ProcessServices angesprochen. Der Servicewird 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 Funktionbaut 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-Frameworkdas Interface GrailsApplication. Über diese kann dann direkt auf die config.properties unddie darin konfigurierten Werte zugegriffen werden (grailsApplication.config...):
  • 46def 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=inDie 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 beiUpdates oder Bugfixes eines Systems oft die Konfiguration gar nicht ändert. Anstatt jedes Malerneut die Applikation zu konfigurieren, kann so nur die Applikation ausgetauscht und die Konfi-guration beibehalten werden. Die config.properties muss eingebunden werden, damit das Systemauch 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() Funktionein 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. Einerdieser Schlüsselwörter ist type. Dieser ist dafür zuständig zu unterscheiden, ob das Ergebnis einerfolgreiches oder ein fehlgeschlagenes Ergebnis ist.Ist das Ergebnis erzeugt, wird es zurück an den Controller gegeben, der nichts anderes macht alsdiese 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>
  • 47Das 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 dieFunktion 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.iddef 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 FunktionuploadFile(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
  • 48dem die Datei platziert werden soll. Dies geschieht wiederum in einer speziellen Service-Klasse(FileStructureService) die diese Art von Aufgabenstellung übernimmt. Anschließend wirddie Datei hochgeladen und ein Ergebnis vom Typ Map erzeugt, der wiederum die UUID und einentype enthält. Wird im UploadController keine UUID als Parameter übergeben, wird sofortein Ergebnis mit einer Fehlermeldung erzeugt. In beiden Fällen wird die Map vom Controller inXML gewandelt und zurückgegeben. Die XML sieht bei einem erfolgreichen Upload wie folgtaus:<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 Verarbeitungsprozessbegonnen 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 erwartetmindestens drei Parameter. Der erste Parameter ist der Skript-Parameter. Dieser identifiziert dasGroovy-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 inmehrere Workflows gruppiert. Dadurch können dieselben Skripte in unterschiedlichen Workflowsverwendet werden. Die Gruppierung der Skripte in Workflows dient vor allem der Strukturierungder 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 wirddann das Skript ausgeführt. Als letztes erwartet die Funktion das ganze Parameter-Objekt. DiesesParameter-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:
  • 49def 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 übergebenwerden 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 undkann somit alle nötigen Informationen verwerten. Außerdem werden der Inputordner Pfad und derOutputordner Pfad für die nötigen Zugriffe in das Binding gesetzt. Ist das Binding gesetzt, gibt
  • 50es 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 eingebundenwerden. Diese Klassenpfade können URLs oder lokale Pfade sein, die über die config.propertiesDatei 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, wirddas Groovy-Skript mit den jeweiligen Bindings ausgeführt. Das Ergebnis der Skriptausführungmuss 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ändigdie 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 diedrei erforderlichen Parameter script, workflow und id unabhängig von Erfolg oder Fehlschlagdes Skriptes dem Ergebnis hinzugefügt. Ein Ergebnis in XML-Darstellung könnte dann wie folgtaussehen:<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 Ergebnisseals 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 denDownloadController den Outputordner herunterzuladen. Dieser Vorgang kann im Download-Controller über die Action download() angestoßen werden:
  • 51def 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 Pfadebereitgestellt. Anschließend wird mit dem AntBuilder dann der Outputordner gepackt und indem Temporaryordner abgelegt. Die Entscheidung den Outputordner zu packen, resultiert aus demGrund, dass unter Umständen die binären Ergebnisse sehr groß werden können. Um die Datenmö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 denAnfragenden gesendet. So werden die Binärdaten aus dem Outputordner bereitgestellt und könnenweiter 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ältfolgende Action:
  • 52def closeSession() {def id = params?.iddef 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 UUIDlö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 inder 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()
  • 53Funktion 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 werdendurchlaufen, um das Datum der letzten Änderung eines Ordners mit dem aktuellen Datum, pluseinem konfigurierbarem Werte, zu vergleichen. Wird dieser Wert übertroffen, wird der Session-ordner als zu alt angesehen und direkt gelöscht. Sessions, die beispielsweise versehentlich nichtbeendet wurden, können somit automatisch nach einem festen konfigurierten Zeitlimit gelöschtwerden. Dies gewährleistet, dass eine Session eine maximale Lebensdauer hat.3.2.3 SzenarienIn diesem Abschnitt werden die Szenarien beschrieben und dargestellt, welche Vorzüge diese habenkö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 zukönnen. Es werden sechs Skripte betrachtet, die jeweils ein Szenario darstellen:
  • 54ExtractText.groovy: Dieses Skript ist, dafür zuständig Texte zu extrahieren. Das Skript sieht wiefolgt aus:def resultMap = [:]StringBuilder sb = new StringBuilder()new File(inPath).eachFileRecurse {def idml = new Idml(it.getAbsolutePath())def spreadIterator = DocumentUtil.getSpreadIterator(idml)while (spreadIterator.hasNext()) {def pageItemIterator = SpreadUtil.getPageItemIterator(spreadIterator.next())while (pageItemIterator.hasNext()) {def pageItem = pageItemIterator.next()if (pageItem.isTextFrame()) {def story = PageItemUtil.getParentStory(pageItem.getAsText-Frame())def content = StoryUtil.getContent(story)sb.append(content)}}}idml.save()idml.close()}resultMap.put("text", sb.toString())resultMapAls erstes wird zunächst in dem Skript eine resultMap erzeugt. Dies ist das Ergebnis, welchesspäter befüllt und als XML an der Webservice-Schnittstelle dargestellt wird. Da das Skript Zugriffauf den Inputordner hat, können alle Dateien aus diesem Ordner verarbeitet werden. Hier wirddavon ausgegangen, dass es sich um IDML-Dateien handelt. Diese IDML-Dateien werden überalle Spreads und PageItems durchlaufen und kontrolliert, ob das jeweilige PageItem eineTextFrame ist. Trifft dies zu, wird auf die zugehörige Story zugegriffen und der Textinhalt übereinen StringBuilder zu einem String zusammengefasst. Somit werden alle Texte aus demDokument zu einem String zusammengefasst und in der resultMap positioniert.Das Szenario soll in erster Linie zeigen, dass es ohne großen Programmieraufwand mit dem IDML-Server möglich ist auf die Texte einer IDML-Datei zuzugreifen. Es kommt oftmals vor, dass auf-wendig Unternehmensbroschüren, Flyer oder andere Medienprodukte mit InDesign produziert
  • 55werden und die Texte aus diesen Produkten dann in anderen Medien verwendet werden sollen.Oft wird dann manuell mit InDesign das Dokument geöffnet, um den jeweiligen Text zu kopieren.Dabei können Fehler entstehen und das manuelle Öffnen der Datei erfordert das Programm In-Design. Mit dem IDML-Server und diesem Skript könnten die Textinhalte einer IDML-Datei überden Webservice zur Verfügung gestellt und dann weiter verarbeitet werden. Beispielsweise könnendie Texte auf Webseiten, mobilen Endgeräten dargestellt oder in Suchengines platziert werden, umdie Inhalte durchsuchbar zu machen.TextManipulation.groovy: Dieses Skript bietet die Möglichkeit, Texte aus einer IDML-Datei zuverändern und neu abzuspeichern:def resultMap = [:]new File(inPath).eachFileRecurse {def idml = new Idml(it.getAbsolutePath())def spreadIterator = DocumentUtil.getSpreadIterator(idml)while (spreadIterator.hasNext()) {def pageItemIterator = SpreadUtil.getPageItemIterator(spreadIterator.next())while (pageItemIterator.hasNext()) {def pageItem = pageItemIterator.next()if (pageItem.isTextFrame()) {def story = PageItemUtil.getParentStory(pageItem.getAsText-Frame())story.getParagraphStyleRangeList().get(0).getCharacterStyleR-angeList().get(0).setContent(content);}}}def out = outPath + it.getName()idml.saveAs(out)idml.close()}resultMapDieses Skript arbeitet ähnlich wie das vorherige Skript. Alle Dateien werden aus dem Inputordnerdurchlaufen und über alle Spreads und PageItems iteriert. Ist das PageItem ein TextFramewird wieder auf die Story zugegriffen. Zugriff auf den Textinhalt bekommt man über die Para-graphstylRageList und CharacterStyleRangeList. Hier wird davon ausgegangen, dass
  • 56nur ein ParagraphenstyleRange und ein CharacterStyleRange existieren. Der Inhalt desCharacterStyleranges wird neu gesetzt mit der Variable content. Diese Variable ist wieder outPath und inPath nicht in dem Skript deklariert. Der Wert ist ein Parameter, der durchden Webservice über das Binding in dem Skript verfügbar gemacht wird. Zum Schluss wird dieÄnderung in einer neuen IDML-Datei im Outputordner abgespeichert.Diese Art von Skript kann bei Übersetzungen verwendet werden. Gibt es beispielsweise Medien-produkte, die in verschiedenen Sprachen publiziert werden sollen, bietet der IDML-Server eineMöglichkeit dies zu realisieren. Wichtig in dem Fall ist, dass der reine Textinhalt verändert wird,jedoch keine Stile, Positionen oder andere wichtige Corporate-Design-Vorgaben, die eingehaltenwerden müssen. Zu beachten ist außerdem noch, dass die TextFrames in dem Grunddokumentdafür ausgerichtet sein müssen und genug Platz aufzuweisen. Übersetzte Texte können unter Um-ständen länger werden als der Orginaltext. Das Erkennen eines Textüberschusses in einem Text-Frame kann in IDML nicht direkt erfasst werden. Dazu muss das Dokument beispielsweise einmalmit InDesign gerendert werden.Ein weiterer Bereich für den Einsatz des Skripts liegt im Korrekturworkflow. Eine Web Applika-tion könnte über den Webservice des IDML-Servers auf die Daten zugreifen und die Texte, dieFehler beinhalten, verändern, ohne dass dabei gestalterische Merkmale verändert werden. DerBenutzer, der diese Webapplikation dann verwendet, benötigt kein InDesign Wissen.Validate.groovy: Dieses Skript stellt einfache Validierungsmöglichkeiten von IDML-Dateien vor.Es wird hier in einer minimierten Version dargestellt, da die Möglichkeiten zur Prüfung der Dateisehr umfangreich sein können:def resultMap = [:]new File(inPath).eachFileRecurse {def idml = new Idml(it.getAbsolutePath())def firstSpread = DocumentUtil.getSpreadIterator(idml).next();def nameExists = falsedef pageItemIterator = SpreadUtil.getPageItemIterator(firstSpread,new IPageItemFilter() {public boolean accept(AbstractIdmlPageItem pageItem) {return LabelUtil.hasLabel(pageItem, "Label");}});while (pageItemIterator.hasNext()) {AbstractIdmlPageItem pageItem = pageItemIterator.next();if (pageItem.isTextFrame()) {KeyValuePair label = LabelUtil.getLabel(pageItem.getAsText-
  • 57Frame(), "Label");if (label.getValue().equals("name")) {nameExists = true}}}idml.close()resultMap.put("nameExists", nameExists)}resultMapDas Ziel des Skriptes ist es zu identifizieren, ob ein bestimmtes PageItem in der IDML enthaltenist. Auch hier wird wieder auf die PageItems zugegriffen, jedoch mit dem Unterschied, dass einFilter verwendet wird, der nur PageItems zurück gibt, die ein Label besitzen. Labels sindMarkierungen die über InDesign an PageItems gesetzt werden können.Abb. 12 InDesign Script LabelÜber diese PageItems wird nun iteriert und kontrolliert, ob es ein TextFrame ist. Trifft dies zu,wird weiter der Wert des Labels geprüft. Wenn dieser den Wert name beinhaltet, ist das jeweiligeElement gefunden worden und es wird ein true Wert in die resultMap platziert. Über den Web-service wird dieser dann dargestellt und das Dokument kann als valid weiter behandelt werden.Es sind auch weitere Validierungsmöglichkeiten gegeben. Beispielsweise kann nach Bildern va-lidiert und anhand des Dateinamens kontrolliert werden, ob ein Logo mit speziellem Dateinamenin dem Dokument platziert wurde. Andere Möglichkeiten wären Schriften, Positionen und Farbenin einem Dokument zu kontrollieren. Corporate-Design-Vorgaben können somit automatisch kon-trolliert werden.IdmsGroupExport.groovy: Dieses Skript ist dafür zuständig, Teile einer IDML-Datei als IDMS-Dateien zu exportieren, um diese wieder verwenden zu können. In dem Skript wird eine Funktionverwendet, die aus einer IDML-Datei alle PageItems vom Typ Group in einer Liste zur Verfü-
  • 58gung zu stellen. Diese sieht wie folgt aus:def List<Group> getGroups(Idml idml) {List<Group> groupResult = new ArrayList<Group>();SpreadIterator spreadIterator = DocumentUtil.getSpreadIterator(idml);while (spreadIterator.hasNext()) {Spread spread = spreadIterator.next();PageItemIterator pageItemIterator = SpreadUtil.getPageItemIterator(spread, new IPageItemFilter() {public boolean accept(AbstractIdmlPageItem abstractIdmlPageItem){return abstractIdmlPageItem.isGroup();}});spread.close();while (pageItemIterator.hasNext()) {Group currentGroup = (Group) pageItemIterator.next();groupResult.add(currentGroup);}}return groupResult;}Die programmatische Umsetzung erfolgt über einen PageItemFilter. Dieser prüft, ob das Pa-geItem vom Typ Group ist und diese Gruppe anschließend in einer groupResult Liste ablegt.def resultMap = [:]def idmsFiles = new ArrayList<String>();new File(inPath).eachFileRecurse {def idml = new Idml(it.getAbsolutePath())def groups = getGroups(idml)def snippetBuilder = SnippetBuilder.get()groups.each {group ->def idmsFile = new File(outPath + group.self + ".idms")snippetBuilder.createSnippet(group, idmsFile)idmsFiles.add(idmsFile.getAbsolutePath())}
  • 59idml.close()}resultMap.put("idms files", idmsFiles)resultMapDiese Liste wird weiter verarbeitet und für jede Gruppe, die gefunden wurde, wird eine IDMS-Datei erzeugt, die als Dateinamen die SelfId der Gruppe trägt. Diese ist in einem Dokumentimmer eindeutig. Die Pfade der erzeugten IDMS-Dateien werden in einer Liste abgelegt und zuder resultMap hinzugefügt. Diese werden anschließend im Webservice dargestellt.Ein solches Szenario ist bei wiederkehrenden Elementen im IDML sinnvoll. Hat man beispiels-weise einen Handzettel mit unterschiedlichen Produkten, können diese Produkte als IDMS-Dateiexportiert und in späteren Ausgaben wieder verwendet werden. Dabei können zu einem Produktunterschiedliche Elemente gehören. Besteht ein Produkt aus einem Bild, einem Beschreibungstextund einem Preis, können diese drei Elemente in InDesign als Gruppe zusammengefasst werdenund dann mit diesem Skript exportiert werden. Der Vorteil durch diese Wiederverwendbarkeit liegtdarin, dass die IDMS-Dateien alle gestalterischen Merkmale beibehalten. Ist ein Produkt einmalgestaltet und exportiert worden kann die exportierte IDMS-Datei in anderen InDesign-Dokumen-ten mit allen Stilen, Farben, etc. platziert werden.ImportIdms.groovy: Dieses Skript ist das Gegenstück zum IdmsGroupExport.groovy. Das Zielist es, IDMS-Dateien in IDML-Dateien zu importieren. Dazu werden mehrere IDMS-Dateien ineiner IDML platziert und als neue IDML-Datei abgespeichert:def resultMap = [:]def idmlList = new File(inPath).listFiles({d, f -> f ==~ /.*.idml/ }as FilenameFilter).toList()def idmsList = new File(inPath).listFiles({d, f -> f ==~ /.*.idms/ }as FilenameFilter).toList()idmlList.each {idmlFile ->def idml = new Idml(idmlFile.getAbsolutePath())idmsList.each {idmsFile ->def idms = new Idml(idmsFile.getAbsolutePath())DocumentUtil.importSnippet(idml, idms, 0)}def out = outPath + idmlFile.getName()new File(out).getParentFile().mkdirs()idml.saveAs(out)
  • 60idml.close()}resultMapEin solches Szenario kann dazu dienen vollautomatisch IDML-Dateien zu erzeugen. Betrach-tet man das vorherige Export-Skript, kann eine denkbare Kombination eine Art Baustein-Systemsein. Mit dem Export-Skript können Produkte eines Handzettels exportiert und als einzelne Bau-steine in einem System abgelegt werden. Mit dem Import-Skript kann das System dann mehrereProdukte zu einem Handzettel zusammenbauen. In Kombination mit dem Skript der Textmanipu-lation können dann sogar Texte verändert oder übersetzt werden.DatabasePublishing.groovy: Dieses Skript ist aus einer vorherigen Arbeit adaptiert und für denIDML-Server optimiert worden. Die zugehörigen Informationen sind zu finden unter [Pouryek-ta2011] und das Video dazu unter [DatabasePublishing2011]. Das Skript stellt ein Database-Pu-blishing-Szenario dar. Aus einer XML mit Personendaten (welches als Datenbank fungiert) undeiner IDML (welches als Template fungiert) werden pro Person Visitenkarten erzeugt. Das Skriptkann in den beigefügten Quellen betrachtet werden. Es ist eine Kombination aus dem Validate.groovy Skript und dem TextManipulation.groovy Skript. Über die Labels können wie im Valida-te.groovy die jeweiligen PageItems identifiziert werden. Wie bei dem TextManipulation.groovywerden die Texte dann ausgetauscht, die aus der XML-Datei kommen. Hier wird deutlich, dassder IDML-Server nicht nur IDML-Dateien, sondern auch XML-Dateien ohne Probleme verarbei-ten kann. Auch weitere Formate sind möglich. Bilder werden auch in diesem Skript ausgetauscht.Dazu müssen die Bilder mit in das System geladen werden und in dem XML verfügbar sein. Wasin IDML dann passiert ist, dass die Pfade des Bildes verändert werden und so im IDML das neueBild dargestellt wird.Die Vorteile von Database-Publishing liegen vor allem in der Geschwindigkeit, in der die Doku-mente generiert werden und in der minimierten Fehleranfälligkeit im Vergleich zur manuellenUmsetzung.
  • 614 SchlussbetrachtungIn diesem letzten Kapitel werden noch einmal die Ergebnisse der Umsetzung zusammengetragen undbewertet. Es werden Empfehlungen für die Bereiche angesprochen, in denen ein IDML-Server sinn-voll genutzt werden kann. Da das Konzept nur für eine erste Version des IDML-Servers konzipiertwurde, wird zum Schluss zusätzlich ein Blick in die Zukunft geworfen und mögliche Weiterentwick-lungen des Systems betrachtet.4.1 ErgebnisseDie Ergebnisse sind in zwei Bereiche einzuteilen. Der erste Bereich beschäftigt sich mit den Ergebnis-sen des Prototyps. Der zweite mit den Szenarien, welche den produktiven Einsatz ermöglichen:Prototyp: Bei der Entwicklung des Prototyps ist deutlich geworden, wie ein IDML-Server aus-sehen kann. Die Themen aus den Grundlagen spielen dabei eine wesentliche Rolle. Vor allem derEinsatz des Grails-Frameworks bietet sehr viele Möglichkeiten im Bereich der Entwicklung.Die vier Anforderungen an das System konnten mit dem Konzept und dem Prototypen bestätigtwerden. Die Anforderung der Verarbeitung wird dabei in der Process-Engine realisiert. Sie kap-selt den Verarbeitungsprozess und realisiert ihn durch individuell gestaltbare Groovy-Skripte. DieVereinfachung des Umgangs mit IDML wird durch den ganzen IDML-Server realisiert. Dabeifassen die Skripte spezielle und komplexe Aufgaben zusammen und können durch einen einfachzu bedienenden Webservice angesteuert werden. Die Anforderung der Einbindung des Systemswird auch über den Webservice realisiert. Dieser ist in Teilen individuell durch die Groovy-Skripteerweiterbar. Dies ist auch somit die letzte Anforderung. Die Erweiterbarkeit wird über die Webser-vice-Parameter, die Groovy-Skripte und dem Grails-Pluginsystem gewährleistet.Szenarien: Die Szenarien zeigen mögliche Einsatzbereiche des IDML-Servers. Das ExtractText.groovy Skript zeigt wie Inhalte über einen Webservice zur Verfügung gestellt und somit über an-dere Systeme publiziert werden können. Das TextManipulation.groovy Skript beschreibt den Ein-satzbereich von Web-to-Print-Systemen. Hiermit können Übersetzungs- und Korrekturworkflowsrealisiert werden. Das Validate.groovy Skript ist im Bereich der Qualitätskontrolle einzuordnen.Mit derartigen Skripten kann gewährleistet werden, dass IDML-Dateien eine bestimmt Form auf-weisen. Fehlerhafte Dateien können somit automatisch aussortiert werden. Das IdmlGroupExport.groovy und das ImportIdms.groovy Skript können zusammen im Bereich von Bausteinsystemenverwendet werden. Ganze IDML-Elemente können so wieder verwendet und regelbasiert, vollau-tomatisch zu ganzen Dokumenten zusammengeführt werden. Das DatabasePublishing.groovy hatgezeigt, dass mit IDML auch Database-Publishing möglich ist. Hier wurden individuelle IDML-Dateien in wenigen Sekunden erzeugt.
  • 624.2 BewertungDie Bewertung der Ergebnisse wird auch wieder in den zwei Bereichen Prototyp und Szenarien be-trachtet:Prototyp: Bei dem Prototypen hat sich herauskristallisiert, dass die Wahl der Technologie unddie Orchestrierung dieser eine wesentliche Rolle spielen. Das Grails-Framework in Kombinationmit der Sprache Groovy war hier der richtige Ansatz, um das Konzept über einen Prototypen zubestätigen. Die größten Vorteile liegen einmal darin, dass dieser IDML-Server in der Lage istein komplexes Format zu kapseln. Wichtig ist hier zu erwähnen, dass der IDML-Server nicht dieKomplexität von IDML minimiert, sondern diese nur in den Bereich der Groovy-Skripte ver-schiebt. Über die Groovy-Skripte wird dann die Verarbeitung gewährleistet. Diese Verarbeitungkann über eine einfache URL angestoßen werden. Der Benutzer, der diese URL anstößt, muss keinWissen über das zu verarbeitende Format haben, da die Skripte die Komplexität behandeln undfür die Verarbeitung zuständig sind. Ein weiterer Vorteil, welcher sich während der praktischenUmsetzung deutlich zeigt, ist dass es auf Erweiterbarkeit ausgelegt und nicht zwingend auf IDMLbeschränkt ist. In diesem System wurde lediglich der Fokus auf IDML gesetzt. Es ist jedoch soflexibel ausgelegt, dass es ohne große Anpassungen auch andere Formate verarbeiten kann. Somitsind die Anforderungen an den IDML-Server zufriedenstellend erfüllt.Szenarien: Die Skripte, welche die Szenarien darstellen, können komplexe Prozesse abbildenund durch diese Art von Automatisierung Vorteile bewirken. Diese Vorteile können vor allem imBereich der Produktion liegen, da Prozesse verkürzt und optimiert werden. Auch die Qualität derProdukte kann über spezielle Skripte so gewährleistet werden. Im Bereich der Wirtschaftlichkeitkönnen hier für Unternehmen Vorteile entstehen, da diese Art von IDML-Verarbeitung sonst nurmit einem kostenintensiven InDesign-Server möglich ist. Die Skripte sind speziell für angepassteIDML-Dateien vorbereitet worden. Um diese Groovy-Skripte zu entwickeln, sind Spezialistennotwendig, die Erfahrung in InDesign, IDML und Groovy besitzen. Ein wirklich produktiver Ein-satz der Skripte setzt außerdem einheitliche und strukturierte IDML-Dateien vorraus. Diese Artvon Verarbeitung kann jedoch selten im künstlerischen Bereich eingesetzt werden. Es ist in ersterLinie darauf ausgelegt, strukturierte Abläufe zu optimieren.Zusammenfassend kann gesagt werden, dass der Einsatz eines IDML-Servers große Vorteile bringenkann. Wichtig ist, dass die IDML-Dateien strukturiert aufbereitet sind und die Skripte professionellerstellt werden. Das bedeutet allerdings auch, dass man sich mit diesen Themen intensiv auseinandersetzten muss, um wirklich produktiv diese Vorteile zu erzielen.
  • 634.3 Blick in die ZukunftDas Konzept, das hier betrachtet wurde, kann und soll weiterentwickelt werden. Folgend werden Ideenbetrachtet, die in Zukunft in den IDML-Server einfließen können:JSON: In dieser ersten Version des IDML-Servers gibt der Webservice die Daten als XML zurück.Es kann von Vorteil sein hier auch das JSON-Format zu unterstützen, da es die gleichen Daten oftkleiner als XML darstellen kann. Die Anpassung ist in dem Grails-Framework sehr einfach umzu-setzen und könnte über den Webservice per Parameter beeinflusst werden.Ergebnis: Das Ergebnis, was über den Webservice dargestellt wird, ist in dieser ersten Versioneine Map. Um den Webservice strukturierter aufzubauen, kann eine Ergebnis-Klasse erzeugt wer-den, die feste und variable Werte aufnehmen kann. Die festen Werte können dann beispielsweisefür spezielle Nachrichten und Codes verwendet werden, die immer in einem Webservice-Ergebnisvorhanden sein müssen. Die variablen Werte können dann individuell beansprucht werden.Versionierung: Bei einer Weiterentwicklung des Webservices sollte eine Versionierung des Web-service in Betracht gezogen werden. Ist der IDML-Server einmal in bestehende Workflows ein-gebunden, können Veränderungen des Webservices den ganzen Workflow gefährden. Der Einsatzeines versionierten Webservices könnte hier Abhilfe schaffen.Multiupload: In dieser ersten Version kann pro Serveranfrage immer nur eine Datei hochgeladenwerden. Für zukünftige Versionen könnte man einen Multiupload entwickeln, der den Ablauf be-schleunigen könnte.Parameter: Der Webservice kann individuelle Parameter beinhalten, die dann von den Groovy-Skripten verarbeitet werden können. Diese Parameter werden in dieser ersten Version nicht imWebservice-Ergebnis angebunden. Hier sollten der Vollständigkeit halber nicht nur die festen Pa-rameter, sondern auch die variable Parameter gesetzt werden.Asynchron: Der Server arbeitet in dieser ersten Version synchron. Das bedeutet, es ist möglich anden Server eine Anfrage zu stellen. Diese wird dann verarbeitet und es wird ein Ergebnis zurückgegeben. Dieser Verarbeitungsvorgang kann unter Umständen lange dauern. Daher könnte maneinen asynchronen Ansatz wählen, indem man in der Process-Engine mit einer Queue arbeitet, dieKommandos entgegen nehmen kann. Der Ansatz beruht hier auf dem Command-Muster. Dieser inKombination mit dem State-Muster kann eine asynchronen Verarbeitungsprozess realisieren. DerAnfragende stößt somit nicht direkt die Verarbeitung an, sondern fügt der Queue ein Kommandohinzu. Ein Ergebnis, ob das Kommando in dem Verarbeitungsprozess angekommen ist kann sofort
  • 64zurück gegeben werden. Wann genau das Kommando verarbeitet wurde und wann genau er abge-schlossen wird, ist nicht direkt für den Anfragenden sichtbar. Er kann aber den Status der Verarbei-tung über den Webservice abfragen, der einem dann sofort zurückgeben kann, ob die Verarbeitungnoch im Gange oder bereits abgeschlossen ist.Benutzerverwaltung: Eine weitere Möglichkeit liegt in der Einführung einer Benutzerverwal-tung. Die Unterscheidung zwischen einem Benutzer für das System und einem Administrator kanneine deutliche Trennung zwischen den Aufgabenbereichen darstellen. Ein Administrator kann so-mit das System konfigurieren und Benutzer verwalten. Benutzer können so unterschiedliche Rech-te auf Verarbeitungsprozesse haben. Ein Benutzer kann somit beispielsweise nur Verarbeitungenim Qualitätsbereich ausführen, die keine Veränderungen der Dateien vornehmen. Im Gegensatzdazu könnte ein Übersetzter Rechte auf Verarbeitungen im Bereich der Textmanipulation haben.Skriptverwaltung: Die Skripte könnten in einer weiteren Version des IDML-Servers über eineBenutzeroberfläche verwaltet werden. Dazu könnte es über die Benutzerverwaltung eine Rolle desEntwicklers geben, der Zugriff auf die Skripte hat und diese hochladen, erstellen und verändernkann.Datenbank: Die Verwendung einer Datenbank könnte den IDML-Server weiter optimieren. Da-bei könnten Informationen über die Benutzer und die Skripte in der Datenbank platziert werden.Download: Der Downloadprozess ist in erster Version des IDML-Servers sehr einfach gehalten.Er stellt den ganzen Output zur Verfügung. Bei einer Verarbeitung in der mehrere Dateien erzeugtwerden, kann es erforderlich sein nur Zugriff auf eine spezielle Datei zu erhalten. Der Download-prozess könnte so weiterentwickelt werden, dass auch einzelne Dateien aus dem Outputordnerheruntergeladen werden können.Temporaryordner: Der Temporaryordner wird bislang nur im Downloadprozess verwendet. DerZugriff auf diesen Ordner könnte aber auch in Groovy-Skripten Verwendung finden.Zusammenfassend kann gesagt werden, dass es noch viele Möglichkeiten gibt, diesen IDML-Serversinnvoll auszubauen. Der Blick in die Zukunft zeigt mögliche Entwicklungen.
  • 65AbbildungsverzeichnisAbbildung Beschreibung Seite1 MVC Ablauf 92 SOAP-Nachricht 133 Grails Einordnung 144 Groovy/Java Plattform 155 Spring Modules 206 Grails Applikation 227 IDML Container Aufbau 338 IDML-Server 389 Workflow Ablauf 4010 IDML-Server Index Seite 4311 IDML-Server Process Index Seite 4412 InDesign Script Label 57
  • 66AbkürzungsverzeichnisAbkürzung BeschreibungACID Atomicity Consistency Isolation DurabilityAJAX Asynchronous JavaScript and XMLAOP Aspect-Oriented ProgrammingCoC Convention over ConfigurationCS Creative SuiteCSS Cascading Style SheetsDOM Document Object ModelDI Dependency InjectionDRY Don´t Repeat YourselfDTP Desktop PublishingeBook Electronic BookEL Expression LanguageEPUB Electronic PublicationEVA Eingabe, Verarbeitung, AusgabeGDK Groovy Development KitGORM Grails Object Relational MappingGPath Groovy Path LanguageGSP Groovy Server PageGString Groovy StringHTTP Hypertext Transfer ProtocolIDML InDesign Markup LanguageIDMS InDesign SnippetINDD InDesign Document FormatINX InDesign Interchange FormatIoC Inversion of ControlJDK Java DevelopmentKitJS JavaScriptJSON JavaScript Object NotationJSP Java Server PageJVM Java Virtual MachineMIMETYPE Multipurpose Internet Mail Extensions TypeMVC Model View ControllerORM Object Relational MappingPDF Portable Document Format
  • 67Abkürzung BeschreibungPOJO Plain Old Java ObjectRDF Resource Description FrameworkREST Representational State TransferRNG Regular Language Description for XML New GenerationSEI Software Engineering InstituteSOAP Simple Object Access ProtocolSQL Structured Query LanguageUCF Universal Container FormatURI Uniform Resource IdentifierURL Uniform Resource LocatorUUID Universally Unique IdentifierW3C World Wide Web ConsortiumWSDL Web Service Description LanguageXML Extensible Markup LanguageXPath XML Path LanguageXQuery XML Query LanguageXMP Extensible Metadata PlatformXSLT Extensible Stylesheet Language Transformation
  • 68Literaturverzeichnis[Adobe2012] Adobe Systems 2012, https://wwwimages2.adobe.com/content/dam/Adobe/en/devnet/indesign/sdk/cs6/idml/idml-specification.pdf (2013-01-07)[Bayer2002] Thomas Bayer, REST Web Services, 2002, http://www.oio.de/public/xml/rest-webservices.pdf (2012-12-19)[Booth2004] David Booth, Hugo Haas, Francis McCabe, Eric Newcomer, MichaelChampion, Chris Ferris, David Orchard: Web Services Architecture,2004, http://www.w3.org/TR/ws-arch/ (2012-12-18)[Carnegie2012] Carnegie Mellon Software Engineering Institute, http://www.sei.cmu.edu/architecture/start/glossary/community.cfm#definitions (2012-11-06)[DatabasePublishing2011] Database Publishing mit IDML 2011, https://www.youtube.com/watch?v=IpbJudaJFH4 (2013-02-17)[Davis2008] Scott Davis: Groovy Recipes Greasing the Wheels of Java, ThePragmatic Programmers, 2008[Fielding2000] Roy Thomas Fielding: Architectural Styles and the Design ofNetwork-based Software Architectures, 2000, https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm (2012-12-19)[Freeman2004] Eric Freeman, Elisabeth Freeman, Bert Bates, Kathy Sierra: Head FirstDesign Patterns, O‘Reilly Media, 2004[Frotscher2007] Thilo Frotscher, Marc Teufel, Dapeng Wang: Java Web Services mitApache Axis2, entwickler.press, 2007[Gamma2011] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Ent-wurfsmuster: Elemente wiederverwendbarer objektorientierter Soft-ware, Addion-Wesley Verlag, 2011
  • 69[Grandeur2009] Grandeur: researching groovy & grails, 2009, http://www.gayadesign.com/scripts/uploads/researchpaper.pdf (2012-12-21)[Groovy2012] Groovy Closures - Formal Definition, http://groovy.codehaus.org/Closures+-+Formal+Definition (2012-12-29)[Hunt2003] Andrew Hunt, David Thomas: Der Pragmatische Programmierer, Han-ser, 2003[IDMLlib2013] IDMLlib for Java, http://idmllib.com/ILWebsite/Products/IDMLlib-for-Java (2013-01-13)[Johnson2004] Rod Johnson, Juergen Hoeller: J2EE Development without EJB, Wi-ley Publishing Inc, 2004[Johnson2005] Rod Johnson,Juergen Hoeller,Alef Arendsen,Thomas Risberg,ColinSampaleanu: Professional Java Development with the Spring Frame-work, Wiley Publishing Inc, 2005[Kipphan2000] Helmut Kipphan: Handbuch der Printmedien, Springer Verlag, 2000[König2007] Dierk König, Andrew Glover, Paul King, Guillaume Laforge, JonSkeet: Groovy in Action, Manning Publications Co., 2007[Kruchten1995] Philippe Kruchten: Architectural Blueprints—The “4+1” View Modelof Software Architecture, IEEE Software November 1995 http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf (2012-11-06)[Oltmanns2007] Daniel Oltmanns, Stefan Edlich: Spring 2 für Grünschnäbel, Bookson Demand GmbH, 2007[Pouryekta2011] Peyman Pouryekta: Analyse und Bewertung der InDesign MarkupLanguage - Desktop Publishing vs. Database Publishing, VDM Ver-lag Dr. Müller, 2011[Rocher2009] Graeme Rocher, Jeff Brown: The Definitive Guide to Grails, Apress,2009
  • 70[Snell2002] James Snell,Doug Tidwell,Paul Kulchenko: Webservice-Programmie-rung mit SOAP, O‘Reilly, 2002[SpringDocu2012] Spring Documentation: 1. Introduction to Spring, http://static.springsource.org/spring/docs/3.0.x/reference/overview.html, (2012-12-30)[Starke2009] Gernot Starke: Effektive Software Architekturen, Ein praktischer Leit-faden, Hanser Verlag 2009[Wolff2009] Eberhard Wolff: Über Architekturen und Perfektion, http://jandi-andme.blogspot.de/2009/10/uber-architekturen-und-perfektion.html(2010-11-07)
  • 71AAblaufplan 7abstraction 6Abstraktion 6, 8ACID 25Adobe 4Adobe Creative Suite 30AJAX 27Analyse 7AOP 26application.properties 22Arbeitsaufwand 4Architekturmuster 8Aspect-Oriented-Programming 26Assoziationen 9Ästhetik 6Asynchron 63Asynchronous JavaScript and XML26Atomicity 25Auslieferung 13Authentifizierung 13Autorisierung 13BBackingStory.xml 35Bauplan 7Benutzerverwaltung 64Beschnittzugabe 31Blitzer 31Body 13BootStrap.groovy 22BuildConfig.groovy 22Builder 11Built-in Tag 28CCarnegie Mellon Software Enginee-ring Institute 6Classpath 50Closure 16Cloud 38CoC 21, 48Code-Generierung 13Collection 18Color 34Command 11composition 6Config.groovy 22config.properties 45, 46, 50Consistency 25Constructor-Injection 21Containerformat 33container.xml 35Controller 9, 26Convention over Configuration 21Corporate-Design-Vorgaben 56, 57CRUD 27CS4 4Custom Tag 29DDatabase-Publishing 60, 61DatabasePublishing.groovy 60DataSource.groovy 22Datei Download 41Dateinamen 5Datei Upload 41, 47Datenmodell 9Datentypen 17decomposition 6DELETE-Methode 14Dependency Injection 20designmap.xml 34design pattern 7, 10Desktop-Publishing 5, 30development view 7DI 21Diagramm 5Dokumenterstellung 30Don´t Repeat Yourself 21Druck- und Medienindustrie 4DRY 21DTP 30Durability 25Dynamic Dispatching 27Dynamic Tag 28dynamisch typisiert 15EeBook 31electronic book 31Electronic Publication 31Encoding 33Entwicklungsumgebung 22Entwurfsentscheidungen 7Entwurfsmuster 7, 10Entwurfsprobleme 7Envelope 12EPUB 31Erich Gamma 10Erzeugungsmuster 10esthetics 6EVA-Prinzip 38Expression Language 27Extensible Markup Language 12Extensible Metadata Platform 35Extensible Stylesheet LanguageStichwortverzeichnis
  • 72Transformation 32ExtractText.groovy 54FFlexibilität 8, 9Fließtext 5Flyer 54Fonts.xml 34Formfelder 31Framework 5GGET-Methode 14GORM 23, 24GPath 19Gradients 34Graeme Rocher 5Grails 5, 14grails-app 22Grails-Applikation 21Grails-Framework 5, 6, 14Grails-Kommando 5Grails Object Relational Mapping 23Graphic.xml 34Groovy 5, 6, 15Groovy-Path 19Groovy Server Page 27Groovy-Skripte 41Groovy-String 17Grundlayout 27Gruppen 31GSP 27GString 17Guillaume Laforge 5HHandzettel 59Header 13Hibernate-Framework 15HTML 5HTTP 12Hypertext Transfer Protocol 12IIDML 5, 30IDML-Spezifikation 5, 32IDMS 35IdmsGroupExport.groovy 57Import 15ImportIdms.groovy 59INDD 31InDesign 30InDesign Document Format 31InDesign Markup Language 4InDesign Snippet 35Informationstechnik 4Interchange Format 32Inversion of Control 20INX 32, 33IoC 20Isolation 25JJames Strachan 15JavaScript Object Notation 26Java Server Page 27Java Virtual Machine 15JSON 26, 63JSP 27JVM 15KKapselung 35Klassenpfad 50Knöpfe 31Komplexität 7Komponenten 7Komposition 5Kompression 33Konsequenzabschnitt 10Konstruktionsplan 32Konventionen 5Konzept 4Llayering 8Lazy loading Mechanismus 35Linien-Elemente 31List 18Lizenzkosten 4logical view 7Lösungsabschnitt 10MMap 18Mapping.xml 35MasterSpread 34Medienprodukt 54Messaging-Framework 12metadata.xml 35meta Tag 27MIMETYPE 34Model 9, 39Model View Controller 8Multipurpose Internet Mail Extensi-ons Type 34Multiupload 63Mustername 10MVC 8, 9, 45NNULL-Check 18NullPointerException 18O
  • 73Object Relational Mapping 15Open-Source-Framework 20Orchestrierung 5Ordnung 7ORM 15Oval-Elemente 31PPDF 31Performance 8, 9Persistenz-Framework 15Philippe Kruchten 6, 7physical view 7Plain Old Java Object 15Pläne 7POJO 15Polyglot Programming 35Polygon-Elemente 31Portable Document Format 31POST-Methode 14Präsentation 9Preferences.xml 34Problemabschnitt 10Process-Engine 39, 41process view 7Produktionsumgebung 22Programmsteuerung 9proprietär 4, 31Prototyp 42, 61, 62PUT-Methode 14Python 15QQualität 8Qualitätssicherung 36Quasi-Standard 9RRange 18RDF 35Realisierung 7Rechteck-Elemente 31Regular Language Description forXML New Generation 32Representational State Transfer 6Resource Description Framework 35Resources 34REST 6, 12, 13, 39return Statement 18RNG 32Rod Johnson 5Routing 13Ruby 15SScaffolding 27scenario 7Schichten 8, 39Schichtenmuster 8Scripting 19SEI 6Semikolon 16Session Beendigung 42, 51Session Erzeugung 41, 43Setter-Injection 21Sichten 7Simple Object Access Protocol 6Single Point of Failure 38Singleton 11SiteMesh 15, 27Skriptverwaltung 64Smalltalk 15SOAP 6, 12SOAP-Nachricht 12SOAP-Schnittstelle 39Softwarearchitektur 6Softwareentwicklung 5Spread 34Spring 20Spring-Framework 5SQL 24State 11Stil 6Stories 34Story.xml 35StrokeStyle 34Structured Query Language 24Struktur 7Strukturmuster 10style 6Styles.xml 34Ttaglib 29Tags.xml 35Testumgebung 22Text-Elemente 31TextManipulation.groovy 55Tomcat 30, 43Transaktionskontext 13Transformierung 32Typografie 5, 30Typografische Konventionen 5UÜbersetzungsworkflow 36UCF 33Uniform Resource Identifier 13Universal Container Format 33Universally Unique Identifier 40Unternehmensbroschüren 54URI 13URL 5UrlMappings.groovy 23
  • 74UUID 40VValidate.groovy 56Validator 23Verarbeitung 41, 48Verhaltensmuster 10Versionierung 63Versionskompatibilität 4Verständlichkeit 7, 8View 9WW3C 12WAR 30Wartbarkeit 9Web Application Archive 30Webservice 6, 12, 39Web Service Description Language12Web-to-Print 61Werkzeug 4Wiederverwendbarkeit 59World Wide Web Consortium 12WSDL 12, 13, 40XXML 5, 12, 19XML-Overhead 40XML Path Language 32XML Query Language 32XMP 35XPath 32XQuery 32XSLT 32ZZerlegung 6ZIP 51ZIP-Archiv 33Zusammensetzung 6Zwiebel 8