FOM Hochschule für Oekonomie & ManagementStudienzentrum EssenMaster-Thesiszur Erlangung des Grades einesMaster of Arts (M....
2Inhaltsverzeichnis1 Einleitung..............................................................................................
34.1 Ergebnisse..............................................................................................................
41 EinleitungDiese Thesis beschäftigt sich mit der Fragestellung, wie ein IDML-Server aufgebaut sein und ob die-ser Vortei...
5Softwareentwicklung im Bereich Java und über Desktop-Publishing mit InDesign wird vorausgesetzt.Ein Vorwissen über die Th...
62 GrundlagenDieses Kapitel beschäftigt sich mit den grundlegenden Themen, die für das Verständnis der Arbeit re-levant si...
7Struktur: Eine Softwarearchitektur beschreibt die Komponenten eines Softwaresystems. Es gehthierbei nicht nur um den Aufb...
8Denn nur so können alle Beteiligten ein Verständnis über die einzelnen Komponenten und derenZusammenspiel bekommen. [vgl....
9Folgende Vor- und Nachteile ergeben sich durch den Einsatz eines Schichtenmusters:Vorteile•	 Unabhängigkeit der Schichten...
10Diese beiden Architekturmuster werden häufig verwendet, um die ganzheitliche Sicht eines Systemszu organisieren. Oft tau...
11zwischen den Objekten. Der Einsatz von Verhaltensmustern kann die Flexibilität der Software imBereich der Kommunikation ...
122.2 WebserviceDer folgende Abschnitt beginnt mit der Definition des Begriffs Webservice. Danach werden wie zuvorerwähnt ...
13<?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"><env:Header> </e...
14GET: Beim Aufruf einer GET-Methode wird vom Server eine Ressource gefordert. Dabei kanneine GET-Anfrage beliebig oft abg...
15SiteMesh ist dabei ein Layout Framework mit dem es möglich ist, Seitendekorationen in der View aufeinfachem Weg zu gesta...
16•	 groovy.lang.*;•	 groovy.util.*;•	 java.lang.*;•	 java.util.*;•	 java.net.*;•	 java.io.*;•	 java.Math.BigInteger;•	 ja...
17print Halloprint Welt!//Ausgabe: Hallo Welt!print Hallo; print Welt!;//Ausgabe: Hallo Welt!Datentypen: In Groovy müssen ...
18println gstring.class//Ausgabe: class org.codehaus.groovy.runtime.GStringImplCollections: In Groovy gibt es drei Arten v...
19def empty = nullprintln empty.size()//Ausgabe: java.lang.NullPointerException: Cannot invoke method size()on null object...
20Jonathan Schwartz works for Sun*/2.3.3 SpringSpring ist ein Open-Source-Framework. Es liefert zur Entwicklung einer Anwe...
21DI: DI ist eine Spezialisierung von IoC und wird auf zwei Wegen eingesetzt: Die erste Möglich-keit ist Setter-Injection....
22Um eine Grails-Applikation zu erstellen wird das Kommando grails create-app verwendet.Dieses Kommando fordert einen Name...
23src Ordner, die als Bean in der Grails-Applikation verwendet werden sollen, so kann diese hiereingebunden werden. Die Sp...
24Dabei fällt auf, dass die Klasse Person keine get() Methode definiert. Alle Domain-Klassenbekommen zur Laufzeit diese Me...
25class PersonController{	 def personService	 ...}Eine Service-Klasse arbeitet im Normalfall mit den Domain-Klassen und re...
26controller: In dem controller Ordner werden Controller-Klassen abgelegt. Erzeugen kann mandiese mit dem Kommando grails ...
27XML (AJAX) oder beispielsweise direkt als Webservice verwendet. Die einfachste Möglichkeit,die Grails hier bietet, sind ...
28<html>	 <head>		 <meta name="layout" content="main"/>	 </head>	 ...</html>Um der View Funktionalität zu verleihen und ei...
29Diese zweite Darstellungsmöglichkeit wird als sauberer empfunden, da die XML Tags nicht mehr-fach ineinander verschachte...
30dateien. Darüber hinaus sind Cascading Style Sheets (CSS), Bild und JavaScript (JS) Ordner verfüg-bar, in denen die jewe...
31•	 Die Ränder können in unterschiedlichen Einheiten definiert werden.•	 Die Beschnittzugabe ist bei Dokumenten relevant,...
322.4.2 DateiformatDas Dateiformat IDML wurde mit der InDesign Version CS4 eingeführt und repräsentiert ein In-Design-Doku...
33Rückwärtskompatibilität: Die Rückwärtskompatibilität zu einer Vorgängerversion soll durchIDML gewähleistet werden.Perfor...
34Multipurpose Internet Mail Extensions Type (MIMETYPE): Diese Datei beschreib den Datei-typ. Bei IDML sieht der Inhalt wi...
35die in dem InDesign Dokument definiert werden als Story.xml. Diese Stories beinhalten den Text,die zugehörigen Stile und...
36Einige Einsatzmöglichkeiten werden auf der IDMLlib Webseite genannt [vgl. IDMLlib2013]:•	 Individuelle Validierung von D...
373 UmsetzungDieses Kapitel beschäftigt sich mit der Umsetzung des IDML-Servers. Nachdem in Kapitel 2 dieGrundlagen betrac...
38Vorteile•	 Ein Server ist generell ein zentrales System und kann in Workflows integriert werden. In einemWorkflow können...
39Der Server ist nach dem MVC-Muster und dem Schichtenmuster aufgebaut. Dabei ist das Model imBereich der Process-Engine a...
40XML wäre hier JSON. JSON hat im Vergleich zu XML eine einfachere Syntax. Diese ist kürzer undminimalistischer ausgelegt....
413.1.4 Process-EngineUm zu verstehen, wie die Process-Engine aufgebaut ist, wird anhand des Ablaufs (Abb.9) jeder Schritt...
42und über den Webservice zur Verfügung gestellt.Session Beendigung: Nachdem alle Prozesse abgearbeitet wurden muss die Se...
43im Browser die Standard Index Seite dargestellt:Abb. 10 IDML-Server Index SeiteDiese zeigt den Status der Applikation, d...
44static mappings = {	 ʺ/$controller/$action?/$id?"{		 constraints {			 // apply constraints here		 }	 }	 "/"(view:"/index...
45def createSession(){def result = processService.createSession()render result as XML}Hier wird die Funktion createSession...
46def getInPath(id) {	 getWorkPath() + id + File.separator + grailsApplication.config.idml.		 server.local.work.in.folder....
47Das Wichtigste an diesem Ergebnis ist die ID. Diese muss während des ganzen Prozesses mitge-liefert werden. Sie sorgt fü...
48dem die Datei platziert werden soll. Dies geschieht wiederum in einer speziellen Service-Klasse(FileStructureService) di...
49def executeScript(script, workflow, id, Map<String, String> params) {def result = [:]def binding = handleParams(params, ...
50es zusätzlich noch die Möglichkeit Zugriff auf weitere Ressourcen zu nehmen. Über die getRo-ots() Funktion können weiter...
51def download() {	 def id = params.id	 def resultFile = downloadService.getZippedOutFolder(id)	 response.setContentType("...
52def closeSession() {def id = params?.iddef result = processService.closeSession(id)render result as XML}Notwendig für de...
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Konzeption eines IDML Servers
Upcoming SlideShare
Loading in...5
×

Konzeption eines IDML Servers

2,506

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,506
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Konzeption eines IDML Servers

  1. 1. 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
  2. 2. 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
  3. 3. 34.1 Ergebnisse.............................................................................................................................. 614.2 Bewertung.............................................................................................................................. 624.3 Blick in die Zukunft .............................................................................................................. 63Abbildungsverzeichnis........................................................................................................................ 65Abkürzungsverzeichnis....................................................................................................................... 66Literaturverzeichnis............................................................................................................................ 68Stichwortverzeichnis........................................................................................................................... 71
  4. 4. 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
  5. 5. 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.
  6. 6. 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:
  7. 7. 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.
  8. 8. 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.
  9. 9. 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
  10. 10. 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
  11. 11. 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.
  12. 12. 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. 13. 13<?xml version="1.0" encoding="UTF-8"?><env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope"><env:Header> </env:Header><env:Body> </env:Body></env:Envelope>In dem Envelope befindet sich ein optionaler Header und ein zwingend erforderlicher Body.Der Header enthält mehrere Headerblöcke, die Angaben zu Routing, Auslieferung, Authentifizie-rung, Autorisierung und Transaktionskontexte beinhalten können. Der Body beinhaltet die eigent-liche Nachricht, die ausgeliefert und verarbeitet werden soll. [vgl. Snell2002, S.15f]Abb. 2 SOAP-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
  14. 14. 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
  15. 15. 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. 16. 16• groovy.lang.*;• groovy.util.*;• java.lang.*;• java.util.*;• java.net.*;• java.io.*;• java.Math.BigInteger;• java.Math.BigDecimal;[Davis2008, S.42]Zusätzlich wird eine Anzahl an Methoden verkürzt. Beispielsweise wird System.out.print 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]
  17. 17. 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!
  18. 18. 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
  19. 19. 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
  20. 20. 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
  21. 21. 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]
  22. 22. 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
  23. 23. 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)
  24. 24. 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]
  25. 25. 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.
  26. 26. 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
  27. 27. 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. 28. 28<html> <head> <meta name="layout" content="main"/> </head> ...</html>Um der View Funktionalität zu verleihen und eine Trennung von Inhalt und Funktion zu erlangen,werden Tags eingesetzt. Alle diese GSP-Tags haben ein g: vorangestellt. Grails verwendet 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>
  29. 29. 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-
  30. 30. 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. 31. 31• Die Ränder können in unterschiedlichen Einheiten definiert werden.• Die Beschnittzugabe ist bei Dokumenten relevant, die später in den Druck kommen. Hier kön-nen Beschnittzugaben definiert werden, um 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.
  32. 32. 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.
  33. 33. 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]
  34. 34. 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,
  35. 35. 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.
  36. 36. 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.
  37. 37. 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:
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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
  43. 43. 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:
  44. 44. 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:
  45. 45. 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...):
  46. 46. 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>
  47. 47. 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
  48. 48. 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:
  49. 49. 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
  50. 50. 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:
  51. 51. 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:
  52. 52. 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()

×