Konzeption eines IDML Servers

  • Published on
    12-May-2015

  • View
    2.255

  • Download
    6

Transcript

1.FOM Hochschule fr 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-152. 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. 34.1 Ergebnisse.............................................................................................................................. 614.2 Bewertung.............................................................................................................................. 624.3 Blick in die Zukunft .............................................................................................................. 63Abbildungsverzeichnis........................................................................................................................ 65Abkrzungsverzeichnis....................................................................................................................... 66Literaturverzeichnis............................................................................................................................ 68Stichwortverzeichnis........................................................................................................................... 71 4. 41 EinleitungDiese Thesis beschftigt 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,knnen die Vorzge 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 hufig das ProgrammAdobe InDesign (im weiteren Verlauf InDesign) verwendet. InDesign ist proprietr 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 eingefhrt das sich InDesign Markup Language (IDML) nennt.Dieses Format ist einmal fr die Versionskompatibilitt zwischen den InDesign Versionen ab CS4verantwortlich und zum anderen fr die externe Verarbeitung von InDesign-Dokumenten. Dadurch dasIDML offengelegt wurde, knnen neue Mglichkeiten im Bereich von Automatisierungen auerhalbvon InDesign entwickelt werden. IDML ist jedoch ein komplexes Dateiformat und der Umgang damiterfordert tiefes Wissen ber InDesign und IDML. Um diese Komplexitt 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. Hufig knnen solche Prozesse individuell durch IDML automatisiertwerden. Ein weiterer Aspekt ist, dass einfache Aufgaben oft abhngig von InDesign sind, wodurchzustzlicher Arbeitsaufwand sowie Lizenzkosten entstehen knnen. Durch den Einsatz von IDMLkann in bestimmten Bereichen eine von InDesign unabhngige und in andere Systeme integrierbareLsung 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 fr die IDML-Verarbeitung verwen-den kann. In dieser Arbeit steht der IDML-Server im Fokus. Darber 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 besttigen sollen.1.3 LeserkreisDie Arbeit ist hauptschlich an Personen aus der Informationstechnik gerichtet, die sich mit IDMLbeschftigen und dessen Einsatzmglichkeiten betrachten wollen. Ein grundsolides Vorwissen ber 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 bestmglich zu erlutern. Folgende Konventionen werden eingehalten:Flietext: Die Schriftart fr den Flietext ist eine Times in der Gre 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 beschftigt 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 Basisverstndnis 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 Primrliteratur besonderer Wert gelegt. Rod Johnson (Spring-Framework), GraemeRocher (Grails-Framework) und Guillaume Laforge (Groovy) sind dabei die Kpfe der jeweiligenTechnologien. Zum Thema IDML ist kaum Literatur vorhanden, deshalb wird hauptschlich mit derIDML-Spezifikation gearbeitet. Diese behandelt jedoch nicht ausreichend den Einsatz von IDML,weshalb Vorwissen ber InDesign und eine eigenstndige Motivation zur Erarbeitung von Kenntnissenim Bereich IDML vorausgesetzt wird. 6. 62 GrundlagenDieses Kapitel beschftigt sich mit den grundlegenden Themen, die fr das Verstndnis der Arbeit re-levant sind. Als Erstes wird der Begriff Softwarearchitektur beleuchtet. Hier wird vor allem erlutert,was eine Softwarearchitektur ist, welche Ziele sie verfolgt und wie diese umgesetzt werden kann.Im Kapitel 2.2 wird erlutert, 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 erlutert.Das Kapitel 2.3 beschftigt sich mit dem Grails-Framework. Hier werden die Konzepte des Frame-works erlutert. Auch die eingesetzte Sprache Groovy wird hier betrachtet und grundstzlich gezeigt,wie eine Grails-Applikation aufgebaut ist.Anschlieend wird im Kapitel 2.4 auf die IDML eingegangen. Zunchst wird erklrt, was berhauptInDesign ist. Danach wird das Dateiformat IDML betrachtet und sein Aufbau beschrieben. Danachwird auf die Mglichkeit eingegangen, wie dieses Format verarbeitet werden kann.In allen Grundlagenkapitel werden nur die wesentlichen Aspekte angesprochen. Genauere Informatio-nen knnen anhand des Literaturverzeichnisses herangezogen werden.2.1 SoftwarearchitekturIn diesem Abschnitt wird der Begriff Softwarearchitektur erlutert. Es beginnt mit der Definition desBegriffes. Dann wird auf dieArchitekturmuster und Entwurfsmuster eingegangen. Diese sind abstrakteBeschreibungen einer Lsung fr hufig vorkommende Probleme. Dabei betrachtenArchitekturmusterzum einen das gesamte System, whrend 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 erlutert 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 Verfgung [vgl. Carnegie2012]. Anhand dieser Sammlung kann grundstzlich gesagtwerden, dass Softwarearchitektur sich mit folgenden Aspekten beschftigt: 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 Komplexitt eines Softwaresystems mit Hilfe einer Struktur beherrschbar zu machen.Beschreibung einer Lsung: Eine Softwarearchitektur wird in Form von Plnen realisiert. Siebeschreibt eine Lsung und besteht aus abstrakten Komponenten. Diese Plne fhren 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 knnen Entwurfsmuster (design patterns)ansetzen, um eine Lsung fr 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 zuknftiges Problem zu l-sen. Dieses Problem wird im Rahmen der Analyse erfasst. Die Softwarearchitektur beschreibt dieFunktionsweise und den Aufbau des Systems, welches das Problem lst. Sie dient bei der Soft-wareentwicklung als Vorgehensmodel.Sichten: Eine Softwarearchitektur wird in unterschiedlichen Sichten dargestellt. Philippe Kruch-ten unterscheidet dabei die fnf 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 genaueErluterung der Sichten ist zu finden unter: [Kruchten1995, S.1f].Verstndlichkeit: Eine Softwarearchitektur schafft Ordnung und ermglicht einen berblick berdas System. Um die Komplexitt eines Systems verstndlich zu machen, werden die Anforderun-gen in Strukturen berfhrt und dokumentiert. Die Dokumentation ist hierbei ein wichtiger Punkt. 8. 8Denn nur so knnen alle Beteiligten ein Verstndnis ber die einzelnen Komponenten und derenZusammenspiel bekommen. [vgl. Starke2009, S.18]Flexibilitt: Eine Softwarearchitektur sorgt dafr, dass das Softwaresystem weiterentwickelt wer-den kann. Die Software muss einen Aufbau gewhrleisten, der es ermglicht, das System flexibelzu erweitern. [vgl. Starke2009, S.19] Das bedeutet auch, dass in der Praxis generell keine perfekteSoftwarearchitekturen entstehen, da diese hufig nicht flexibel hinsichtlich ihrer Weiterentwick-lung sind. [vgl. Wolff2009]Abstraktion: Eine Softwarearchitektur beschreibt ein abstraktes System. Dabei werden Informa-tionen bewusst weggelassen, um die Verstndlichkeit des Systems zu erhhen. Die wesentlichenKerneigenschaften der Software werden in einer Softwarearchitektur dargestellt. [vgl. Starke2009,S.19]Qualitt: Eine durchdachte Softwarearchitektur kann die Qualitt der Software erhhen. Die Qua-litt besteht aus mehreren Kriterien, wie zum Beispiel Performance, Verstndlichkeit, Flexibilittetc. [vgl. Starke2009, S.19]Um diese Aspekte auch realisieren zu knnen, wird hufig auf bestehende Methoden wie beispielswei-se Architekturmuster zurckgegriffen.2.1.2 ArchitekturmusterArchitekturmuster untersttzen 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 erlutert. Diese sind fr die sptere 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 darber liegenden Schicht eine definierte Anzahl an Diensten an. Der Aufbau einessolchen Systems wird hufig 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 darber liegende Schicht. Eine Mehrfachnutzung von Diensten durch andereSchichten ist zu vermeiden, da die Abhngigkeiten der Schichten dadurch erhht werden. [vgl.Starke2009, S.149f]Eine mgliche Aufteilung der Schichten fr ein Softwaresystem wre die Unterteilung in: Daten-,Domnen-, Anwendungs- und Prsentationsschicht. 9. 9Folgende Vor- und Nachteile ergeben sich durch den Einsatz eines Schichtenmusters:Vorteile Unabhngigkeit der Schichten in der Erstellung und im Betrieb Implementierung einer Schicht kann aufgrund ihrer Unabhngigkeit ausgetauscht werden Minimierung der Abhngigkeiten zwischen Komponenten des Systems Leicht zu verstehendes Strukturkonzept[vgl. Starke2009, S.150]Nachteile Beeintrchtigung der Performance, da eine Anfrage unter Umstnden 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 (Prsentation) und Controller (Programmsteuerung). Ziel des MVC Mustersist es, eine bessere Wartbarkeit und Flexibilitt 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 fr die Anzeige derDaten. Der Controller ist fr 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 StatusnderungNeuer StatusView anzeigenBenutzer Eingabe 10. 10Diese beiden Architekturmuster werden hufig verwendet, um die ganzheitliche Sicht eines Systemszu organisieren. Oft tauchen whrend der Implementierungsphase jedoch auch Probleme auf, die nichtmit Architekturmustern abgedeckt werden knnen. Hier setzen Entwurfsmuster an.2.1.3 EntwurfsmusterEin Entwurfsmuster (design pattern) ist die abstrakte Beschreibung einer Lsung fr ein hufig vor-kommendes Problem. Allgemein betrachtet besitzt ein Muster vier Elemente:Mustername: Der Mustername ist die aussagekrftige Benennung des Entwurfsproblems und derLsung mit ein oder zwei Worten. Sie erweitert das Entwurfsvokabular und sorgt fr 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 lst und in welchem Kontext es sich befindet. Es beschreibt spezifische Ent-wurfsprobleme und Bedingungen, die erfllt sein mssen. [vgl. Gamma2011, S.3]Lsungsabschnitt: Der Lsungsabschnitt beschreibt die Elemente des Entwurfs und deren Be-ziehungen, Zustndigkeiten und Interaktionen. Die dargestellte Lsung 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 fr die Beurteilung des Entwurfs gegenber anderen Alternativen. [vgl.Gamma2011, S.4]Es gibt unterschiedliche Arten von Entwurfsmustern. Erich Gamma klassifiziert sie nach drei Aufga-benbereichen:Erzeugung: Die Erzeugungsmuster sind dafr zustndig, Objekte zu erzeugen. Sie kapseln denProzess der Erzeugung und vereinfachen den Umgang damit. Der Einsatz von Erzeugungsmusterngewhrleistet 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 dafr zustndig, den Aufbau von Objekten und deren Bezie-hungen untereinander zu vereinfachen. Der Einsatz von Strukturmuster kann die Komplexitt ei-ner Software minimieren. [vgl. Gamma2011, S.169]Verhalten: Die Verhaltensmuster schaffen einen einheitlichen Umgang in der Kommunikation 11. 11zwischen den Objekten. Der Einsatz von Verhaltensmustern kann die Flexibilitt der Software imBereich der Kommunikation zwischen Objekten erhhen. [vgl. Gamma2011, S.271]Entwurfsmuster werden hufig in Frameworks verwendet. Fr die sptere Umsetzung werden hiereinige kurz dargestellt:Singleton: Das Singleton Entwurfsmuster gehrt 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 gewhrleisten, wird die Zustndigkeit 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 gehrt 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 Ausfhrung mehrerer komplexer Aktionen. Dabeiwird eine Anfrage in ein Command gekapselt. Durch das Ausfhren eines Commands werdenmehrere Aktionen ausgefhrt, die von auen nicht ersichtlich sind. Entwurfsmuster werden auchhufig miteinander kombiniert. Zum Erzeugen von Commands kann zum Beispiel das BuilderEntwurfsmuster verwendet werden. [vgl. Freeman2004, S.206]State: Das State Entwurfsmuster gehrt zu den Verhaltensmustern und ist objektbasierend. DerZweck des Musters ist es Objekten die Mglichkeit zu geben, ihren Zustand zu definieren und aufdiesen aufmerksam zu machen. Eine Kombination mit dem Command-Entwurfsmuster knnteso aussehen, dass sich bei der Beendigung der Ausfhrung eines Commands der Zustand einesObjekts ndert und darauf aufmerksam macht, dass diese Ausfhrung beendet wurde. [vgl. Free-man2004, S.410]Diese Entwurfsmuster lsen 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 Benutzeroberflche realisiert. Ist das System jedoch auf die Kommunikationmit anderen Maschinen ausgerichtet, so kann die Kommunikation ber einen Webservice stattfinden. 12. 122.2 WebserviceDer folgende Abschnitt beginnt mit der Definition des Begriffs Webservice. Danach werden wie zuvorerwhnt 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 fllt auf, dass das W3C in dieser Definition weitere Technologien auffhrt, 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 Abhngigkeiten verstanden undkann unter gegebenen Umstnden andere Formate und Technologien implementieren. Die Kernauf-gabe von Webservices, sind die Maschine zu Maschine Interaktion ber ein Netzwerk und ber einemplattformunabhngigen Kommunikationsformat.2.2.2 SOAPUrsprnglich 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 knnen, ist eine Transportmglichkeit notwendig. Bei einemWebservice erfolgt dies in den hufigsten Fllen ber HTTP. Dabei stellt sich die Frage, wie dieseDaten vorliegen. SOAP bietet hier eine XML basierte Lsung.Relevant fr 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. 13In dem Envelope befindet sich ein optionaler Header und ein zwingend erforderlicher Body.Der Header enthlt mehrere Headerblcke, die Angaben zu Routing, Auslieferung, Authentifizie-rung, Autorisierung und Transaktionskontexte beinhalten knnen. 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 ermglicht,einen Webservice standardisiert zu beschreiben. Die Beschreibung enthlt alle notwendigen In-formationen, um den Webservice anwenden zu knnen. Darin enthalten sind alle Operationender zu versendenden Nachrichten und Datentypen. Auerdem 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 plattformunabhngig. [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-fhrt werden kann, die genau ein Ergebnis liefert. Das erfolgt bei REST in den hufigsten Fllen berHTTP. [vgl. Fielding2000]Im Folgenden wird dargestellt, welche HTTP Standardmethoden REST im Webanwedungskontexthauptschlich verwendet:EnvelopeHeaderBody 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 knnen Prozesse oder Datenbankfelder verndert 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. Auerdem 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. 15SiteMesh ist dabei ein Layout Framework mit dem es mglich 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 mglich 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) luft. 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 fr Groovy hatte, wurde bei der Entwicklung von Groovy von denEigenschaften der Sprachen Python, Ruby und Smalltalk inspiriert. [vgl. Knig2007, S.3f] Es folgendie wesentlichen Besonderheiten von Groovy gegenber 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 fr den Entwickler. Das zeichnet sich vor allem darin aus, dassdie Entwicklung mit einer dynamischen Sprache oft schneller ist, da die Syntax der Sprache kr-zer gehalten und aussagekrftiger ist. Dem gegenber steht die langsamere Geschwindigkeit beider Ausfhrung. Dadurch, das whrend der Laufzeit der Code verndert werden kann, und somitneu kompiliert werden muss, knnen bei der Geschwindigkeit Einbuen entstehen. [vgl. Gran-deur2009, S.12]Import: Das Groovy Development Kit (GDK) erweitert das Java Development Kit (JDK) mitzustzlichen Methoden und der funktionalen Erweiterung durch Closures. Dabei werden automa-tisch folgende Importierungen eingebunden:Plattform (Linux, Windows...)Java Virtual MachineJavaGroovy 16. 16 groovy.lang.*; groovy.util.*; java.lang.*; java.util.*; java.net.*; java.io.*; java.Math.BigInteger; java.Math.BigDecimal;[Davis2008, S.42]Zustzlich wird eine Anzahl an Methoden verkrzt. 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 fr mehr Flexibilitt. Es sind Code-blcke, die referenziert und als Argument oder Rckgabewert in anderen Funktionen verwendetwerden knnen. [vgl. Knig2007, 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 Schlsselwort 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. 17print Halloprint Welt!//Ausgabe: Hallo Welt!print Hallo; print Welt!;//Ausgabe: Hallo Welt!Datentypen: In Groovy mssen keine Datentypen definiert werden. Stattdessen wird das Schls-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. 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 zurck. [vgl. Grandeur2009, S.17]def method(){"Hallo Welt!"}print method()//Ausgabe: Hallo Welt!NULL-Check: In Groovy knnen Objekte durch ein ? auf NULL geprft werden. Dadurch kn-nen NullPointerExceptions vermieden werden. [vgl. Grandeur2009, S.17]def string = "Hallo Welt!"println string.size()//Ausgabe: 12 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 skriptfhig ist. Ist Groo-vy auf einem Betriebsystem installiert, so knnen ohne weiteres Skripte erstellt und ausgefhrtwerden. Es ist nicht zwingend notwendig wie in Java Klassen zu erstellen. Ein einfaches Skript(test.groovy) knnte wie folgt aussehen:#!/usr/bin/env groovyprintln "Hallo Welt!"XML: Groovy bietet eine einfache Mglichkeit ber Groovy-Path (GPath) mit XML umzugehen.Um diese XML nun einlesen zu knnen 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. 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 werdenknnen, aber nicht zwingend erforderlich sind. Auerdem hat es den Anspruch, den Anwendungscodeunabhngig gestalten zu knnen, 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. Vollstndigkeitshalber werden im folgendenDiagramm diese aufgefhrt: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: "Dont call us, well 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. 21DI: DI ist eine Spezialisierung von IoC und wird auf zwei Wegen eingesetzt: Die erste Mglich-keit ist Setter-Injection. Dabei wird ber eine Setter-Methode ein Objekt injiziert. Die zweite Mg-lichkeit ist die Constructor-Injection. Hierbei wird ber den Konstruktor ein Objekt injiziert. Beibeiden Mglichkeiten 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 nchste Ebene der Abstraktion zu heben. Es bietet Mglichkeiten die andere Frameworks seit Jah-ren bieten aber bislang nicht in der Java-Welt auf einfachem Wege verfgbar waren. Der Anspruch andie Flexibilitt 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 Dont 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 dafr sorgen, dassKonfigurationen wegfallen knnen. Ein Beispiel dafr 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 Verstndlichkeit des Systemserhht und die Fehleranflligkeit reduziert.DRY: Bei DRY geht es um die Vermeidung von Redundanzen. Ein Problem bei der Softwareent-wicklung ist, dass der Entwickler in einer stndigen Wartungsphase ist. Sobald sich Anforderun-gen verndern, mssen diese aufgenommen und im Code angepasst werden. Bei einem redun-danten Code ist dies sehr aufwndig, 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. 22Um eine Grails-Applikation zu erstellen wird das Kommando grails create-app verwendet.Dieses Kommando fordert einen Namen fr 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 hlt Properties, die angepasst werden knnen. 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 fr die Applikation sind in diesem Konfigurations-ordner enthalten.Die BootStrap.groovy Datei ermglicht vor dem Start der Applikation oder nach dem Herunterfah-ren der Applikation zustzlichen Code auszufhren. So kann diese beispielsweise dazu verwendetwerden, einen Defaultbenutzer anzulegen, der beim Start der Applikation erzeugt wird.Die BuildConfig.groovy Datei ist zustndig fr das Buildmanagement der Applikation. Hier kn-nen beispielsweise Maven-Repositories und Grails-Plugins eingebunden werden.Die Config.groovy ist fr die Konfiguration der Applikation gedacht. Hier werden Log4J, Enco-ding und weitere Konfigurationsmglichkeiten geboten.Die DataSource.groovy behandelt die Konfiguration der Datenquelle. Wird in der Applikationmit einer Datenbank gearbeitet, so besteht hier die Mglichkeit fr 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. 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 werdenknnen. Zu der Domain-Klasse Person gibt es beispielsweise direkt auch eine Datenbank-Tabelledazu.Domain-Klassen knnen auerdem 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 dafr, dass die Werte firstname und lastname nicht leersein drfen. min:1 dagegen prft, ob der Wert age mindestens bei 1 liegt. Der Validator email:true berprft, 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) Funktionalitt zur Verfgung.Um ein Objekt aus der Datenbank auszulesen wird die get() Methode verwendet.def person = Person.get(id) 24. 24Dabei fllt auf, dass die Klasse Person keine get() Methode definiert. Alle Domain-Klassenbekommen zur Laufzeit diese Methoden hinzugefgt. Grails ermglicht dies mit Groovy ber Me-taprogramming. [vgl. Rocher2009, S.249f] Um mehrere Personen als Liste zurck zu bekommenkann die getAll() Methode verwendet werden:def persons = Person.getAll(1,2,3)Die list() Methode bietet zustzliche 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 Lschen 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 Schlsselwrternzusammen: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 standardmig Sin-geltons. Sie knnen ber das Autowiring-Konzept von Spring automatisch ber DI in einem Ser-vice oder einem Controller injiziert werden. [vgl. Rocher2009, S.289f] 25. 25class PersonController{ def personService ...}Eine Service-Klasse arbeitet im Normalfall mit den Domain-Klassen und reprsentiert die Busi-nesslogik der Anwendung. Die Operationen in der Service-Klasse knnen Datenbanknderungenbehandeln. Somit mssen die Service-Klassen transaktional sein. Jede bietet die Mglichkeit dieTransaktionalitt zu setzen. [vgl. Rocher2009, S.295f]class PersonService{ boolean transactional = true ...}Transaktionalitt wird beschrieben durchAtomicity, Consistency, Isolation und Durability (ACID): Atomicity bedeutet, dass jede atomare Operation in der Transaktion entweder ganz oder garnicht ausgefhrt wird. Consistency bedeutet, dass nach der Ausfhrung 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 gewhrleistet wird, dass die Daten dauerhaftin der Datenbank abgespeichert werden.[vgl. Rocher2009, S.295f]Service-Klassen knnen unterschiedliche scopes aufweisen. Bei Bedarf kann diese Eigenschaftangepasst werden. [vgl. Rocher2009, S.297f]class PersonService{ boolean transactional = true static scope = request}Das Schlsselwort request bedeutet hier, dass fr jede Anfrage ein Service erzeugt wird. 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 kannber die URL angesteuert werden (/person/index). Der Name des Clousures (hier: index)wird automatisch fr die View verwendet (CoC). Somit wird vorausgesetzt, dass eine View mitdem Dateinamen index.gsp existiert. Um eine individuelle View zu rendern, gibt es die Mglich-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 auerdem noch Aspect-Oriented-Programming (AOP) in Form von In-terceptors. Somit kann vor oder nach einem Closure zustzlicher Code ausgefhrt 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 knnen als Rckgabe an die View direkt auch XML oder JavaScript ObjectNotation (JSON) zurckgeben. Dies wird im Zusammenhang mit Asynchronous JavaScript and 27. 27XML (AJAX) oder beispielsweise direkt als Webservice verwendet. Die einfachste Mglichkeit,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. Auerdem 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 whrendder 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 dazugehrigen Views gene-riert. Mit dem Kommando grails generate-controller wird der Controller erzeugt. Mitdem Kommando grails generate-views werden die dazugehrigen Views erzeugt. Mchteman 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 ...Um der View Funktionalitt 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 Funktionalittsmglichkeit in der View eingesetzt. [vgl. Rocher2009,S.111f] Hallo ${firstname}Firstname: ${it.firstname} Lastname: ${it.lastname}Dynamic Tags sind Tags, welche unterschiedliche Darstellungen annehmen knnen. Einerseitsknnen sie wie die Built-in Tags in XML Form dargestellt werden [vgl. Rocher2009, S.116f]:"> dynamic linkAndererseits gibt es die Mglichkeit, die gleiche Funktionalitt durch einen Methoden-Aufruf zurealisieren: dynamic link 29. 29Diese zweite Darstellungsmglichkeit wird als sauberer empfunden, da die XML Tags nicht mehr-fach ineinander verschachtelt sind.Custom Tags sind dynamic Tags. Sie knnen individuell vom Entwickler programmiert werden,um spezielle Aufgaben zu bewltigen. Sie werden in dem taglib Ordner positioniert.taglib: Individuelle Tag-Libraries knnen 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 zugehrige Tag in der View sieht wie folgt aus: Hallo ${it.firstname}Im lib Ordner knnen weiter Libraries platziert werden, die dann von der Applikation in Anspruchgenommen werden knnen.Im scripts Ordner knnen zustzliche Skripte hinterlegt werden. Diese knnen dann ber das grailsKommando ausgefhrt werden.Der src Ordner beinhaltet einen java und einen groovy Ordner. In diesen Ordnern knnen jeweilsJava und Groovy Code eingebunden werden. Gibt es beispielsweise bereits Businesslogik, die in Javaimplementiert wurde, knnen 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 Funktionalitt derApplikation ausgiebig getestet werden.Der web-app Ordner beinhaltet den WEB-INF Ordner mit den Spring und SiteMesh Konfigurations- 30. 30dateien. Darber hinaus sind Cascading Style Sheets (CSS), Bild und JavaScript (JS) Ordner verfg-bar, in denen die jeweiligen bentigten Dateien positioniert werden knnen.Eine Grails Applikation ist sofort nach der Erstellung ausfhrbar. 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 Erluterung von dem Programm InDesign. Der wesentliche Aufbau,die Ziele und die Ideen des IDML-Formats werden anschlieend beschrieben. Im letzten Abschnittwird eine Mglichkeit dargestellt, IDML-Dateien zu verarbeiten.2.4.1 InDesignInDesign ist ein Desktop-Publishing (DTP) Programm. DTP Programme ermglichen es alle Ttigkei-ten, die vor dem Druck einer Publikation erfolgen mssen, an einem Desktop-Computer zu erledigen.Zu diesen Ttigkeiten gehren: 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 fr Print, aber auch fr digitale Publikationen zu erstellen.InDesign bietet dabei sehr viele Funktionen. Das gngige 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 spter bei der Bearbeitung verndert werden. Die Doppelseiten-Funktion entscheidet, ob das Dokument doppelseitig erzeugt werden soll.Dies ist beispielsweise bei Bchern oder Broschren relevant. Die Seitengre kann individuell in unterschiedlichen Einheiten festgelegt werden. Die Ausrichtung der Seite entscheidet, ob das Dokument als Hoch- oder Querformat angelegtwird. Spalten knnen 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 Die Rnder knnen in unterschiedlichen Einheiten definiert werden. Die Beschnittzugabe ist bei Dokumenten relevant, die spter in den Druck kommen. Hier kn-nen Beschnittzugaben definiert werden, um Blitzer2zu vermeiden.Elementplatzierung: Ist das Dokument erstellt, knnen auf diesem unterschiedliche Arten vonElementen platziert werden: Text-Elemente werden fr die Textdarstellung verwendet. Hier knnen umfangreiche typo-grafische Auszeichnungen vorgenommen werden und Stile auf Absatz- oder Zeichenebenezugewiesen werden. Rechteck-Elemente knnen als grafische Darstellung definiert werden. Diese knnen bei-spielsweise Farb-, Bild- oder Videoinhalte aufweisen. Polygon-Elemente knnen individuelle Formen annehmen und wie Rechteck-Elemente Inhal-te aufweisen. Oval-Elemente sind fr kreisfrmige Darstellungen ausgelegt. Auch diese knnen wiederumInhalte aufweisen. Linien-Elemente knnen Kurven darstellen. Formfelder und Knpfe knnen zur Erzeugung von Formularen verwendet werden. Gruppen fassen alle mglichen Elemente zusammen.Dokumentenausgabe: Je nach InDesign Version gibt es unterschiedliche Ausgabemglichkeiten.Die grundlegenden Ausgabemglichkeiten sind: InDesign Document Format (INDD) ist das proprietre Dateiformat, welches von InDesigngenutzt wird. Dieses Dateiformat ist nicht abwrtskompatibel. Adobe Portable Document Format (PDF) lsst sich mit umfangreichen Einstellungsmglich-keiten in InDesign definieren, um bestmgliche Druck-, Web- oder interaktive PDF-Doku-mente zu erstellen. Electronic Publication (EPUB) ist ein offener Standard fr electronic books (eBook), welchesim mobilen Bereich eingesetzt wird. InDesign Markup Language (IDML) ist zum einen das Dateiformat, mit dem die Versions-kompabilitt von InDesign gewhrleistet wird und zum anderen ein offenes Dateiformat, wel-ches anders als bei INDD die Mglichkeit bietet, es lesen und somit durch Drittsysteme ver-arbeiten zu knnen.2 Blitzer sind weie Zwischenrume, die an den Rndern eines Dokumentes auftauchen, wenn keine Beschnitt zugabe definiert wurde. 32. 322.4.2 DateiformatDas Dateiformat IDML wurde mit der InDesign Version CS4 eingefhrt und reprsentiert ein In-Design-Dokument als XML. Es ist ein Konstruktionsplan fr InDesign-Dokumente. Wird eine IDML-Datei in InDesign geffnet erzeugt InDesign aus dem IDML ein INDD.Auerdem lst IDML das InDesign Interchange Format (INX) ab und sorgt fr die Versionskompatibi-litt ab CS4. Ein wesentlicher Unterschied zu INX besteht darin, dass INX zwar auch XML basierendist, aber es nur maschinenlesbar und somit hauptschlich nur fr 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 Vergleichsmglichkeit von Inhalten ber unterschiedliche Versionen von Doku-menten.Die Ziele, die IDML nach der Spezifikation verfolgt, sind folgende [vgl. Adobe2012, S.15f]:Vollstndigkeit: Alle Elemente, die in InDesign erzeugt werden knnen, 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 verfgbar sind.Lesbarkeit: IDML hat den Anspruch menschenlesbar und verstndlich zu sein. Jemand der dengrundlegenden Umgang mit InDesign kennt, soll sich im IDML-Dokument zurecht finden knnen.Verarbeitung: IDML-Dokumente sollen durch externe Applikationen gelesen und geschriebenwerden knnen.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-rungsmglichkeiten, um grobe Fehler in IDML zu vermeiden. 33. 33Rckwrtskompatibilitt: Die Rckwrtskompatibilitt zu einer Vorgngerversion soll durchIDML gewhleistet werden.Performanz: Die Performanz von INX-Dateien soll durch IDML bersteigern.Verbesserungen gegenber INX: IDML soll eine Verbesserung gegenber 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. 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 Rckgrad der IDML-Datei. Alle weiteren Dateien in derIDML werden von ihr referenziert. Auerdem sind die Reihenfolge und Beziehungen, die in dieserXML aufgefhrt sind wesentlich. [vgl. Adobe2012, S.44f]MasterSpreads: MasterSpreads sind Vorlagen fr 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 knnen 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 reprsentieren [vgl. Adobe2012, S.21]: Die Graphic.xml definiert beispielsweise Farben (Color), Rahmenstile (StrokeStyle) und Ver-lufe (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. Dazuzhlen: paragraph, character, object, cell, table und table of contens styles. [vgl. Adobe2012,S.345f] Die Preferences.xml definiert Grundeinstellungen und Darstellungsmglichkeiten des Doku-mentes in InDesign. Es hat keine Auswirkungen auf das Dokument selbst. [vgl. Adobe2012,S.281f]Spreads: Spreads sind Druckbgen. Der Spread Ordner hlt alle Spreads, die in dem InDesign-Dokument definiert werden als Spread.xml Datei. Ein Spread kann mehrere Seiten (Page) bein-halten. Auf einem Spread knnen 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 hlt alle Stories, 35. 35die in dem InDesign Dokument definiert werden als Story.xml. Diese Stories beinhalten den Text,die zugehrigen Stile und eine Referenz auf den zugehrigen 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 fr 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 hlt einmal die container.xml Datei. Diese ist notwendig fr 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 ermglicht IDML-Dokumente zu lesen und zu schrei-ben. Ein weiteres Ziel der Library ist es, die Komplexitt des IDML-Formates zu reduzieren undeine Schnittstelle zu bieten, mit der es mglich 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 fr 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 luft auf den Betriebssystemen Windows, Linux und Mac OS. Vorausgesetzt wird dasJDK 5. Auerdem ist die IDMLlib unabhngig von InDesign. Somit lassen sich Workflows konzipie-ren, die Automatisierungsaufgaben auerhalb von InDesign ersetzen und diese flexibler und perfor-manter umsetzen knnen.3 Polyglot bedeutet mehrsprachig. In diesem Zusammenhang ist der Zugriff von anderen Sprachen auf die IDMLlib gemeint. 36. 36Einige Einsatzmglichkeiten werden auf der IDMLlib Webseite genannt [vgl. IDMLlib2013]: Individuelle Validierung von Dokumenten. Vorbereiten von InDesign-Dokumenten fr InDesign. Publizieren von Inhalten, die aus InDesign-Dokumenten ausgelesen werden. Qualittssicherung durch Validierung und Vergleichen von Dokumenten. bersetzungsworkflows fr mehrsprachige Dokumente. Einbinden von InDesign-Dokumenten in Drittsysteme. 37. 373 UmsetzungDieses Kapitel beschftigt sich mit der Umsetzung des IDML-Servers. Nachdem in Kapitel 2 dieGrundlagen betrachtet wurde, wird zunchst auf das Konzept des IDML-Servers eingegangen. ImKapitel 3.2 erfolgt darauf die praktische Umsetzung, welche die Realisierung des Konzepts besttigensoll. 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 fr das System relevant sind. Darauf folgt die Systemarchitektur, welche mageblich 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 fr 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 knnen.Vereinfachung: Das System soll den Umgang mit IDML vereinfachen. Da das IDML-Formatsehr komplex aufgebaut ist, soll das System diese Komplexitt kapseln und ber leicht verstndli-che Funktionen verfgbar machen.Einbindung: Das System soll in bestehende Workflows integriert werden sowie Prozesse verein-fachen und automatisieren knnen.Erweiterbarkeit: Das System soll erweiterbar sein, um zuknftigen Anforderungen gerecht wer-den zu knnen.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 gewhlt. FolgendeVor- und Nachteile ergeben sich bei dem Einsatz eines Servers: 38. 38Vorteile Ein Server ist generell ein zentrales System und kann in Workflows integriert werden. In einemWorkflow knnen so Probleme schneller erkannt werden, da es eine klare Aufgabenverteilung gibtund so deutlich wird, welcher Server fr welche Aufgaben verantwortlich ist. Die Datensicherung ist bei einem zentralen Server einfacher zu handhaben, da die Daten an einemOrt einheitlich gesichert werden knnen. Server knnen in bestehende Workflows ber Schnittstellen eingebunden werden. Eine Cloudversion eines Servers ist mglich.Nachteile Initialkosten eines Serversystems sind oft hher als bei Desktopsystemen, da die technische Kom-plexitt hher 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 80fr Webservices gewhlt, 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 fr die Ausfhrung von vordefinierten Ablufen zustndig. Diese fhrt dientigen Funktionen aus und liefert ein Ergebnis. Das Ergebnis wird wieder zurck an den Webservicegeleitet, der die Daten als Antwort in Form von XML (blicherweise wird XML verwendet. Es knnenjedoch auch andere Formate verwendet werden, wie zum Beispiel JSON.) an den Anfragenden wiederzurck sendet.IDML-ServerWebservice Process-EngineIDML, ParameterIDML, XML 39. 39Der Server ist nach dem MVC-Muster und dem Schichtenmuster aufgebaut. Dabei ist das Model imBereich der Process-Engine anzuordnen. Dieser ist zustndig fr 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 dafr zustndig, 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 Komplexitt 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 gewhlte Framework fr die Implementierung ist das Grails-Framework. Diedarunterliegenden Technologien, wie beispielsweise Spring-Framework, Groovy, Java und IDMLlib,gewhrleisten, dass die Anforderungen an das System erfllt werden. Java und das Spring-Frameworkliefern dabei eine sehr groe Anzahl an erprobten Libraries, die in unterschiedlichsten Bereichen derSoftwareentwicklung eingesetzt werden knnen. Auerdem bietet Java Plattformunabhngigkeit 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 derSkriptfhigkeit der Sprache starke Vorteile in den Bereichen der Flexibilitt 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 knnen zu einer Grails-Web-Applikationentwickelt und installiert werden. Auerdem bietet das Grails-Framework die Mglichkeit, 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 dafr zustndig,die Komplexitt des IDML Formats zu kapseln und Zugang und Verarbeitung von IDML-Dateien zugewhren.3.1.3 WebserviceDer Webservice des IDML-Servers muss die Anforderungen wie Vereinfachung, Einbindung und Er-weiterbarkeit erfllen.In erster Linie sollte der Webservice selbsterklrend und einfach zu bedienen sein. Hier ist die Wahlauf eine XML basierende REST-Schnittstelle gefallen, statt auf eine SOAP-Schnittstelle, da RESTber 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 fr Dritte mglichst einfach gestaltet werden soll. Alternative zu 40. 40XML wre hier JSON. JSON hat im Vergleich zu XML eine einfachere Syntax. Diese ist krzer undminimalistischer ausgelegt. Fr 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 Hauptgrunddafr ist, das REST keine festgelegte Norm ist und somit flexibler gestaltet werden kann. Auerdementfllt im Vergleich zu SOAP ein XML-Overhead, da REST beispielsweise kein WSDL bentigt.Die Erweiterbarkeit der REST-Schnittstelle wird ber eine Parameter-Liste gewhrleistet. Diese be-steht aus einer Anzahl fest definierter Parameter, die fr eine spezielle Anfrage notwendig sind undeiner flexiblen Anzahl an Parametern, die individuell je nach Anforderung definiert werden knnen.Der Webservice behandelt drei Arten von Anfragen:Upload: Die Uploadanfrage ist zustndig fr den Upload von Dateien, wobei der Webservice eineErfolgs- oder Fehlermeldung als Ergebnis zurckgibt.Aktion: Eine Aktionsanfrage beinhaltet keine Binrdaten. Hier wird ber die Anfrage mit spe-ziellen Parametern eine bestimmte Aktion ausgefhrt, die eine Erfolgs- oder Fehlermeldung alsErgebnis zurckgibt.Download: Eine Downloadanfrage liefert Binrdaten. 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 mglicher Ablauf knnte 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. 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 bentigt, um einen Sessionordner zu erzeugen,in dem die Session dann fr den weiteren Ablauf behandelt wird. In diesem Sessionordner werdendrei weitere Ordner erzeugt. Der erste ist ein Inputordner, welcher fr die eingehenden Dateienzustndig 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 knnen,die beispielsweise im Verarbeitungsprozess abgelegt werden mssen. Das Ergebnis der Session-Erzeugung ist im gnstigsten Fall eine Erfolgsmeldung. Dabei wird eine XML zurckgesendet,welche die UUID enthlt.Datei Upload: Ist die Session erzeugt, knnen 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 enthlt.Verarbeitung: Bei der Verarbeitung stellt sich die Frage, wie die Daten genau verarbeitet werdensollen. Um dieses Problem mglichst flexibel zu gestalten, wird ein Workflowordner in dem Sys-tem definiert. In diesem Ordner knnen weitere Ordner platziert werden. Diese Ordner reprsentie-ren einen Workflow. In dem Ordner knnen individuelle Groovy-Skripte abgelegt werden und allentigen Dateien, die fr diesen Workflow bentigt werden. Die Gruppierung der Groovy-Skriptein Workflows hat den Sinn, das System berschaulich und strukturiert verwalten zu knnen. DerWorkflow und das jeweilige Groovy-Skript kann ber den Webservice anhand von definiertenParamterern angesteuert und somit ausgefhrt werden. Die Ausfhrung selber erfolgt dann in demSessionordner, wobei die Dateien aus dem Inputordner fr die Ausfhrung verwendet werden unddas Binr Ergebnis der Verarbeitung in dem Outputordner platziert wird. Das Groovy-Skript kanndabei auf alle Libraries zugreifen, die im System verfgbar sind und somit jede Art von Dateienverarbeiten. Es ist somit also nicht nur beschrnkt 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 ausgefhrten Groovy-Skript gesetzt werden kann.Datei Download: Ist die Verarbeitung abgeschlossen und wurden dabei Binrdaten erzeugt, findetman diese in dem Outputordner. Um nun Zugang auf die Dateien zu ermglichen, kann der Out-putordner heruntergeladen werden. Dabei wird der ganze Outputordner in ein ZIP-Format gepackt 42. 42und ber den Webservice zur Verfgung gestellt.Session Beendigung: Nachdem alle Prozesse abgearbeitet wurden muss die Session nun auchbeendet werden. Dies kann ber den Webservice angestoen werden. Die Process-Engine lschtdurch den Ansto ber den Webservice den Sessionordner und alle enthalteten Informationen.Sollte die Session nicht ber den Webservice beendet werden existiert zustzlich ein Task, derzeitgesteuert ber die bestehenden Sessionordner iteriert und kontrolliert, ob der Sessionordnereine festgelegte Zeit berschritten hat. Ist dies der Fall, wird der Sessionordner gelscht. Dadurchknnen Sessions beendet werden, die beispielsweise versehentlich vergessen wurden beendet zuwerden.3.2 Praktische UmsetzungUm das Konzept (Kapitel 3.1) zu besttigen und produktive Einsatzszenarien durchspielen zu knnen,wird ein Prototyp entwickelt. Dieser hat keinen Anspruch auf Vollstndigkeit und kann Fehler beinhal-ten. Zunchst wird auf die Systemanforderungen eingegangen, die notwendig sind fr den Prototypen.Im nchsten 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 zunchst 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. Auerdem ist frden Prototyp ein Tomcat notwendig. Zu empfehlen ist der Tomcat 6.0.32. Der zugewiesene Speichersollte mit 512 Megabyte generell ausreichen. Je nach Last und Gre 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 einflieen, sollten von InDesignCS4 erzeugt worden sein und der Document Object Model (DOM) Version 6.0 entsprechen.Weitere wesentliche Anforderungen ergeben sich durch die auszufhrenden Groovy-Skripte, die nichtdirekt Teil des Servers sind, sondern individuell je nach Einsatzgebiet gestaltet werden knnen. Hierist vor allem das Verstndnis fr die Sprache Groovy und das IDML-Format notwendig, um dieseGroovy-Skripte erstellen zu knnen.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. 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 zurVerfgung 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 angestoen.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 ausgefhrt werden soll. Dieses Verhalten der Controller ist einheitlich gelst und vereinfachtden Umgang mit dem System. Dieser URLAufbau ist standardmig von dem Grails-Frameworkvorgegeben kann aber bei Bedarf unter config/UrlMappings.groovy angepasst werden: 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 zugehrige gleichnamige GSP-Seite verwiesen unddiese als Antwort auf die Anfrage zurckgegeben:Abb. 11 IDML-Server Process Index SeiteDie GSP-Seiten dienen lediglich zur optischen Darstellung fr den Entwickler oder Benutzer, derden Webservice manuell testen mchte. Ein spterer produktiver Einsatz erfolg direkt ber dieURLs.Um eine Session zu erzeugen, kann die zugehrige URL http://localhost:8080/IDML-Server/process/createSession aufgerufen werden. Diese spricht folgende Action imProcessController an: 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 dafr gesorgt, dass die Session ID und alle notwendigen Strukturen erzeugt werden.Als erstes wird eine zufllige UUID generiert. Anhand dieser UUID wird ber den FileStruc-tureService die Funktion createSessionStructure(id)aufgerufen. Diese ist dafr ver-antwortlich die lokale Ordnerstruktur zu erzeugen, in der spter 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 knnen, bietet das Grails-Frameworkdas Interface GrailsApplication. ber diese kann dann direkt auf die config.properties unddie darin konfigurierten Werte zugegriffen werden (grailsApplication.config...): 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 fr den Inputordner definiert:idml.server.local.work.in.folder.name=inDie config.properties Datei ist dabei eine extern verwaltete Konfigurationsdatei. Diese liegt nor-malerweise auerhalb der Applikation. Der Grund fr 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 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 auszufhrende Skript spter Zugriff auf die jeweiligen Parameter undkann somit alle ntigen Informationen verwerten. Auerdem werden der Inputordner Pfad und derOutputordner Pfad fr die ntigen Zugriffe in das Binding gesetzt. Ist das Binding gesetzt, gibt 50. 50es zustzlich noch die Mglichkeit Zugriff auf weitere Ressourcen zu nehmen. ber die getRo-ots() Funktion knnen weitere Klassenpfade (Classpath) in die Ausfhrung mit eingebundenwerden. Diese Klassenpfade knnen URLs oder lokale Pfade sein, die ber die config.propertiesDatei gesetzt werden knnen.String[] getRoots() { def commaRoots = grailsApplication.config.idml.server.groovy.script. engine.roots def roots = commaRoots.split(",") return roots}Als nchstes wird das GroovyScriptEngine Objekt mit den optionalen Klassenpfaden erzeugt.Dieses Objekt ist fr die Ausfhrung des Skripts verantwortlich. Welches Skript ausgefhrt wer-den soll, wird ber den workflow und den script Parameter entschieden. Der FileStructure-Service sorgt dafr, dass der richtige Pfad des Skripts erzeugt wird. Ist das Skript verfgbar, wirddas Groovy-Skript mit den jeweiligen Bindings ausgefhrt. Das Ergebnis der Skriptausfhrungmuss eine Map sein. Diese Map kann in den Skripten dann mit den Ergebniswerten befllt werden,die fr das jeweilige Szenario relevant sind. Somit hat der Entwickler des Skripts eigenstndigdie Mglichkeit zu entscheiden, was als Ergebnis angezeigt werden soll. Zu dieser Map wird zu-stzlich ein success type hinzugefgt. Ist das Skript jedoch nicht verfgbar, wird eine Fehler-meldung und der zugehrige error type dem Ergebnis hinzugefgt. Zum Schluss werden diedrei erforderlichen Parameter script, workflow und id unabhngig von Erfolg oder Fehlschlagdes Skriptes dem Ergebnis hinzugefgt. Ein Ergebnis in XML-Darstellung knnte dann wie folgtaussehen:successexportExtractText764c7d8e-c276-4ef2-be2f-45b00fda0868Datei Download: Nachdem der Verarbeitungsprozess durchlaufen wurde, knnen die Ergebnisseals XML an den Anfragenden zurckgegeben worden sein. Aber es knnen auch Binrdaten er-zeugt worden sein. Um Zugang zu diesen Binrdaten zu erhalten, gibt es die Mglichkeit ber denDownloadController den Outputordner herunterzuladen. Dieser Vorgang kann im Download-Controller ber die Action download() angestoen werden: 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 if (uuidFolder.isDirectory()) { def now = new Date() long limit = grailsApplication.config.idml.server.tasks. cleanup.workdir.time.limit as long def folderDateWithLimit = new Date(uuidFolder.lastModi fied() + limit) if (now.after(folderDateWithLimit)) { log.info("delete folder: " + uuidFolder.getAbsolute Path()) fileStructureService.deleteSessionFolder(uuidFolder) } } } log.info("end cleanUpWorkDirTask")}Der Task betrachtet den Workordner in dem alle Sessionordner liegen. Alle Sessionordner werdendurchlaufen, um das Datum der letzten nderung eines Ordners mit dem aktuellen Datum, pluseinem konfigurierbarem Werte, zu vergleichen. Wird dieser Wert bertroffen, wird der Session-ordner als zu alt angesehen und direkt gelscht. Sessions, die beispielsweise versehentlich nichtbeendet wurden, knnen somit automatisch nach einem festen konfigurierten Zeitlimit gelschtwerden. Dies gewhrleistet, dass eine Session eine maximale Lebensdauer hat.3.2.3 SzenarienIn diesem Abschnitt werden die Szenarien beschrieben und dargestellt, welche Vorzge diese habenknnen. Sie werden ber Groovy-Skripte realisiert und sind fr den Verarbeitungsprozess verantwort-lich. Die Groovy-Skripte gehren nicht direkt zum IDML-Server, knnen aber nach individuellen An-forderungen entwickelt und in diesen eingebunden werden. Die Skripte sind auf vorgegebene IDML-Dateien ausgerichtet. Diese sind speziell vorbereitet, um die ausgewhlten Szenarien darstellen zuknnen. Es werden sechs Skripte betrachtet, die jeweils ein Szenario darstellen: 54. 54ExtractText.groovy: Dieses Skript ist, dafr zustndig Texte zu extrahieren. Das Skript sieht wiefolgt aus:def resultMap = [:]StringBuilder sb = new StringBuilder()new File(inPath).eachFileRecurse {def idml = new Idml(it.getAbsolutePath())def spreadIterator = DocumentUtil.getSpreadIterator(idml)while (spreadIterator.hasNext()) {def pageItemIterator = SpreadUtil.getPageItemIterator(spreadIterator.next())while (pageItemIterator.hasNext()) {def pageItem = pageItemIterator.next()if (pageItem.isTextFrame()) {def story = PageItemUtil.getParentStory(pageItem.getAsText-Frame())def content = StoryUtil.getContent(story)sb.append(content)}}}idml.save()idml.close()}resultMap.put("text", sb.toString())resultMapAls erstes wird zunchst in dem Skript eine resultMap erzeugt. Dies ist das Ergebnis, welchesspter befllt und als XML an der Webservice-Schnittstelle dargestellt wird. Da das Skript Zugriffauf den Inputordner hat, knnen alle Dateien aus diesem Ordner verarbeitet werden. Hier wirddavon ausgegangen, dass es sich um IDML-Dateien handelt. Diese IDML-Dateien werden beralle Spreads und PageItems durchlaufen und kontrolliert, ob das jeweilige PageItem eineTextFrame ist. Trifft dies zu, wird auf die zugehrige Story zugegriffen und der Textinhalt bereinen StringBuilder zu einem String zusammengefasst. Somit werden alle Texte aus demDokument zu einem String zusammengefasst und in der resultMap positioniert.Das Szenario soll in erster Linie zeigen, dass es ohne groen Programmieraufwand mit dem IDML-Server mglich ist auf die Texte einer IDML-Datei zuzugreifen. Es kommt oftmals vor, dass auf-wendig Unternehmensbroschren, Flyer oder andere Medienprodukte mit InDesign produziert 55. 55werden und die Texte aus diesen Produkten dann in anderen Medien verwendet werden sollen.Oft wird dann manuell mit InDesign das Dokument geffnet, um den jeweiligen Text zu kopieren.Dabei knnen Fehler entstehen und das manuelle ffnen der Datei erfordert das Programm In-Design. Mit dem IDML-Server und diesem Skript knnten die Textinhalte einer IDML-Datei berden Webservice zur Verfgung gestellt und dann weiter verarbeitet werden. Beispielsweise knnendie Texte auf Webseiten, mobilen Endgerten dargestellt oder in Suchengines platziert werden, umdie Inhalte durchsuchbar zu machen.TextManipulation.groovy: Dieses Skript bietet die Mglichkeit, Texte aus einer IDML-Datei zuverndern und neu abzuspeichern:def resultMap = [:]new File(inPath).eachFileRecurse {def idml = new Idml(it.getAbsolutePath())def spreadIterator = DocumentUtil.getSpreadIterator(idml)while (spreadIterator.hasNext()) {def pageItemIterator = SpreadUtil.getPageItemIterator(spreadIterator.next())while (pageItemIterator.hasNext()) {def pageItem = pageItemIterator.next()if (pageItem.isTextFrame()) {def story = PageItemUtil.getParentStory(pageItem.getAsText-Frame())story.getParagraphStyleRangeList().get(0).getCharacterStyleR-angeList().get(0).setContent(content);}}}def out = outPath + it.getName()idml.saveAs(out)idml.close()}resultMapDieses Skript arbeitet hnlich wie das vorherige Skript. Alle Dateien werden aus dem Inputordnerdurchlaufen und ber alle Spreads und PageItems iteriert. Ist das PageItem ein TextFramewird wieder auf die Story zugegriffen. Zugriff auf den Textinhalt bekommt man ber die Para-graphstylRageList und CharacterStyleRangeList. Hier wird davon ausgegangen, dass 56. 56nur ein ParagraphenstyleRange und ein CharacterStyleRange existieren. Der Inhalt desCharacterStyleranges wird neu gesetzt mit der Variable content. Diese Variable ist wieder outPath und inPath nicht in dem Skript deklariert. Der Wert ist ein Parameter, der durchden Webservice ber das Binding in dem Skript verfgbar gemacht wird. Zum Schluss wird dienderung in einer neuen IDML-Datei im Outputordner abgespeichert.Diese Art von Skript kann bei bersetzungen verwendet werden. Gibt es beispielsweise Medien-produkte, die in verschiedenen Sprachen publiziert werden sollen, bietet der IDML-Server eineMglichkeit dies zu realisieren. Wichtig in dem Fall ist, dass der reine Textinhalt verndert wird,jedoch keine Stile, Positionen oder andere wichtige Corporate-Design-Vorgaben, die eingehaltenwerden mssen. Zu beachten ist auerdem noch, dass die TextFrames in dem Grunddokumentdafr ausgerichtet sein mssen und genug Platz aufzuweisen. bersetzte Texte knnen unter Um-stnden lnger werden als der Orginaltext. Das Erkennen eines Textberschusses in einem Text-Frame kann in IDML nicht direkt erfasst werden. Dazu muss das Dokument beispielsweise einmalmit InDesign gerendert werden.Ein weiterer Bereich fr den Einsatz des Skripts liegt im Korrekturworkflow. Eine Web Applika-tion knnte ber den Webservice des IDML-Servers auf die Daten zugreifen und die Texte, dieFehler beinhalten, verndern, ohne dass dabei gestalterische Merkmale verndert werden. DerBenutzer, der diese Webapplikation dann verwendet, bentigt kein InDesign Wissen.Validate.groovy: Dieses Skript stellt einfache Validierungsmglichkeiten von IDML-Dateien vor.Es wird hier in einer minimierten Version dargestellt, da die Mglichkeiten zur Prfung der Dateisehr umfangreich sein knnen:def resultMap = [:]new File(inPath).eachFileRecurse {def idml = new Idml(it.getAbsolutePath())def firstSpread = DocumentUtil.getSpreadIterator(idml).next();def nameExists = falsedef pageItemIterator = SpreadUtil.getPageItemIterator(firstSpread,new IPageItemFilter() {public boolean accept(AbstractIdmlPageItem pageItem) {return LabelUtil.hasLabel(pageItem, "Label");}});while (pageItemIterator.hasNext()) {AbstractIdmlPageItem pageItem = pageItemIterator.next();if (pageItem.isTextFrame()) {KeyValuePair label = LabelUtil.getLabel(pageItem.getAsText- 57. 57Frame(), "Label");if (label.getValue().equals("name")) {nameExists = true}}}idml.close()resultMap.put("nameExists", nameExists)}resultMapDas Ziel des Skriptes ist es zu identifizieren, ob ein bestimmtes PageItem in der IDML enthaltenist. Auch hier wird wieder auf die PageItems zugegriffen, jedoch mit dem Unterschied, dass einFilter verwendet wird, der nur PageItems zurck gibt, die ein Label besitzen. Labels sindMarkierungen die ber InDesign an PageItems gesetzt werden knnen.Abb. 12 InDesign Script Labelber diese PageItems wird nun iteriert und kontrolliert, ob es ein TextFrame ist. Trifft dies zu,wird weiter der Wert des Labels geprft. Wenn dieser den Wert name beinhaltet, ist das jeweiligeElement gefunden worden und es wird ein true Wert in die resultMap platziert. ber den Web-service wird dieser dann dargestellt und das Dokument kann als valid weiter behandelt werden.Es sind auch weitere Validierungsmglichkeiten gegeben. Beispielsweise kann nach Bildern va-lidiert und anhand des Dateinamens kontrolliert werden, ob ein Logo mit speziellem Dateinamenin dem Dokument platziert wurde. Andere Mglichkeiten wren Schriften, Positionen und Farbenin einem Dokument zu kontrollieren. Corporate-Design-Vorgaben knnen somit automatisch kon-trolliert werden.IdmsGroupExport.groovy: Dieses Skript ist dafr zustndig, Teile einer IDML-Datei als IDMS-Dateien zu exportieren, um diese wieder verwenden zu knnen. In dem Skript wird eine Funktionverwendet, die aus einer IDML-Datei alle PageItems vom Typ Group in einer Liste zur Verf- 58. 58gung zu stellen. Diese sieht wie folgt aus:def List getGroups(Idml idml) {List groupResult = new ArrayList();SpreadIterator spreadIterator = DocumentUtil.getSpreadIterator(idml);while (spreadIterator.hasNext()) {Spread spread = spreadIterator.next();PageItemIterator pageItemIterator = SpreadUtil.getPageItemIterator(spread, new IPageItemFilter() {public boolean accept(AbstractIdmlPageItem abstractIdmlPageItem){return abstractIdmlPageItem.isGroup();}});spread.close();while (pageItemIterator.hasNext()) {Group currentGroup = (Group) pageItemIterator.next();groupResult.add(currentGroup);}}return groupResult;}Die programmatische Umsetzung erfolgt ber einen PageItemFilter. Dieser prft, ob das Pa-geItem vom Typ Group ist und diese Gruppe anschlieend in einer groupResult Liste ablegt.def resultMap = [:]def idmsFiles = new ArrayList();new File(inPath).eachFileRecurse {def idml = new Idml(it.getAbsolutePath())def groups = getGroups(idml)def snippetBuilder = SnippetBuilder.get()groups.each {group ->def idmsFile = new File(outPath + group.self + ".idms")snippetBuilder.createSnippet(group, idmsFile)idmsFiles.add(idmsFile.getAbsolutePath())} 59. 59idml.close()}resultMap.put("idms files", idmsFiles)resultMapDiese Liste wird weiter verarbeitet und fr jede Gruppe, die gefunden wurde, wird eine IDMS-Datei erzeugt, die als Dateinamen die SelfId der Gruppe trgt. Diese ist in einem Dokumentimmer eindeutig. Die Pfade der erzeugten IDMS-Dateien werden in einer Liste abgelegt und zuder resultMap hinzugefgt. Diese werden anschlieend im Webservice dargestellt.Ein solches Szenario ist bei wiederkehrenden Elementen im IDML sinnvoll. Hat man beispiels-weise einen Handzettel mit unterschiedlichen Produkten, knnen diese Produkte als IDMS-Dateiexportiert und in spteren Ausgaben wieder verwendet werden. Dabei knnen zu einem Produktunterschiedliche Elemente gehren. Besteht ein Produkt aus einem Bild, einem Beschreibungstextund einem Preis, knnen diese drei Elemente in InDesign als Gruppe zusammengefasst werdenund dann mit diesem Skript exportiert werden. Der Vorteil durch diese Wiederverwendbarkeit liegtdarin, dass die IDMS-Dateien alle gestalterischen Merkmale beibehalten. Ist ein Produkt einmalgestaltet und exportiert worden kann die exportierte IDMS-Datei in anderen InDesign-Dokumen-ten mit allen Stilen, Farben, etc. platziert werden.ImportIdms.groovy: Dieses Skript ist das Gegenstck zum IdmsGroupExport.groovy. Das Zielist es, IDMS-Dateien in IDML-Dateien zu importieren. Dazu werden mehrere IDMS-Dateien ineiner IDML platziert und als neue IDML-Datei abgespeichert:def resultMap = [:]def idmlList = new File(inPath).listFiles({d, f -> f ==~ /.*.idml/ }as FilenameFilter).toList()def idmsList = new File(inPath).listFiles({d, f -> f ==~ /.*.idms/ }as FilenameFilter).toList()idmlList.each {idmlFile ->def idml = new Idml(idmlFile.getAbsolutePath())idmsList.each {idmsFile ->def idms = new Idml(idmsFile.getAbsolutePath())DocumentUtil.importSnippet(idml, idms, 0)}def out = outPath + idmlFile.getName()new File(out).getParentFile().mkdirs()idml.saveAs(out) 60. 60idml.close()}resultMapEin solches Szenario kann dazu dienen vollautomatisch IDML-Dateien zu erzeugen. Betrach-tet man das vorherige Export-Skript, kann eine denkbare Kombination eine Art Baustein-Systemsein. Mit dem Export-Skript knnen Produkte eines Handzettels exportiert und als einzelne Bau-steine in einem System abgelegt werden. Mit dem Import-Skript kann das System dann mehrereProdukte zu einem Handzettel zusammenbauen. In Kombination mit dem Skript der Textmanipu-lation knnen dann sogar Texte verndert oder bersetzt werden.DatabasePublishing.groovy: Dieses Skript ist aus einer vorherigen Arbeit adaptiert und fr denIDML-Server optimiert worden. Die zugehrigen Informationen sind zu finden unter [Pouryek-ta2011] und das Video dazu unter [DatabasePublishing2011]. Das Skript stellt ein Database-Pu-blishing-Szenario dar. Aus einer XML mit Personendaten (welches als Datenbank fungiert) undeiner IDML (welches als Template fungiert) werden pro Person Visitenkarten erzeugt. Das Skriptkann in den beigefgten Quellen betrachtet werden. Es ist eine Kombination aus dem Validate.groovy Skript und dem TextManipulation.groovy Skript. ber die Labels knnen wie im Valida-te.groovy die jeweiligen PageItems identifiziert werden. Wie bei dem TextManipulation.groovywerden die Texte dann ausgetauscht, die aus der XML-Datei kommen. Hier wird deutlich, dassder IDML-Server nicht nur IDML-Dateien, sondern auch XML-Dateien ohne Probleme verarbei-ten kann. Auch weitere Formate sind mglich. Bilder werden auch in diesem Skript ausgetauscht.Dazu mssen die Bilder mit in das System geladen werden und in dem XML verfgbar sein. Wasin IDML dann passiert ist, dass die Pfade des Bildes verndert werden und so im IDML das neueBild dargestellt wird.Die Vorteile von Database-Publishing liegen vor allem in der Geschwindigkeit, in der die Doku-mente generiert werden und in der minimierten Fehleranflligkeit im Vergleich zur manuellenUmsetzung. 61. 614 SchlussbetrachtungIn diesem letzten Kapitel werden noch einmal die Ergebnisse der Umsetzung zusammengetragen undbewertet. Es werden Empfehlungen fr die Bereiche angesprochen, in denen ein IDML-Server sinn-voll genutzt werden kann. Da das Konzept nur fr eine erste Version des IDML-Servers konzipiertwurde, wird zum Schluss zustzlich ein Blick in die Zukunft geworfen und mgliche Weiterentwick-lungen des Systems betrachtet.4.1 ErgebnisseDie Ergebnisse sind in zwei Bereiche einzuteilen. Der erste Bereich beschftigt sich mit den Ergebnis-sen des Prototyps. Der zweite mit den Szenarien, welche den produktiven Einsatz ermglichen:Prototyp: Bei der Entwicklung des Prototyps ist deutlich geworden, wie ein IDML-Server aus-sehen kann. Die Themen aus den Grundlagen spielen dabei eine wesentliche Rolle. Vor allem derEinsatz des Grails-Frameworks bietet sehr viele Mglichkeiten im Bereich der Entwicklung.Die vier Anforderungen an das System konnten mit dem Konzept und dem Prototypen besttigtwerden. Die Anforderung der Verarbeitung wird dabei in der Process-Engine realisiert. Sie kap-selt den Verarbeitungsprozess und realisiert ihn durch individuell gestaltbare Groovy-Skripte. DieVereinfachung des Umgangs mit IDML wird durch den ganzen IDML-Server realisiert. Dabeifassen die Skripte spezielle und komplexe Aufgaben zusammen und knnen durch einen einfachzu bedienenden Webservice angesteuert werden. Die Anforderung der Einbindung des Systemswird auch ber den Webservice realisiert. Dieser ist in Teilen individuell durch die Groovy-Skripteerweiterbar. Dies ist auch somit die letzte Anforderung. Die Erweiterbarkeit wird ber die Webser-vice-Parameter, die Groovy-Skripte und dem Grails-Pluginsystem gewhrleistet.Szenarien: Die Szenarien zeigen mgliche Einsatzbereiche des IDML-Servers. Das ExtractText.groovy Skript zeigt wie Inhalte ber einen Webservice zur Verfgung gestellt und somit ber an-dere Systeme publiziert werden knnen. Das TextManipulation.groovy Skript beschreibt den Ein-satzbereich von Web-to-Print-Systemen. Hiermit knnen bersetzungs- und Korrekturworkflowsrealisiert werden. Das Validate.groovy Skript ist im Bereich der Qualittskontrolle einzuordnen.Mit derartigen Skripten kann gewhrleistet werden, dass IDML-Dateien eine bestimmt Form auf-weisen. Fehlerhafte Dateien knnen somit automatisch aussortiert werden. Das IdmlGroupExport.groovy und das ImportIdms.groovy Skript knnen zusammen im Bereich von Bausteinsystemenverwendet werden. Ganze IDML-Elemente knnen so wieder verwendet und regelbasiert, vollau-tomatisch zu ganzen Dokumenten zusammengefhrt werden. Das DatabasePublishing.groovy hatgezeigt, dass mit IDML auch Database-Publishing mglich ist. Hier wurden individuelle IDML-Dateien in wenigen Sekunden erzeugt. 62. 624.2 BewertungDie Bewertung der Ergebnisse wird auch wieder in den zwei Bereichen Prototyp und Szenarien be-trachtet:Prototyp: Bei dem Prototypen hat sich herauskristallisiert, dass die Wahl der Technologie unddie Orchestrierung dieser eine wesentliche Rolle spielen. Das Grails-Framework in Kombinationmit der Sprache Groovy war hier der richtige Ansatz, um das Konzept ber einen Prototypen zubesttigen. Die grten Vorteile liegen einmal darin, dass dieser IDML-Server in der Lage istein komplexes Format zu kapseln. Wichtig ist hier zu erwhnen, dass der IDML-Server nicht dieKomplexitt von IDML minimiert, sondern diese nur in den Bereich der Groovy-Skripte ver-schiebt. ber die Groovy-Skripte wird dann die Verarbeitung gewhrleistet. Diese Verarbeitungkann ber eine einfache URL angestoen werden. Der Benutzer, der diese URL anstt, muss keinWissen ber das zu verarbeitende Format haben, da die Skripte die Komplexitt behandeln undfr die Verarbeitung zustndig sind. Ein weiterer Vorteil, welcher sich whrend der praktischenUmsetzung deutlich zeigt, ist dass es auf Erweiterbarkeit ausgelegt und nicht zwingend auf IDMLbeschrnkt ist. In diesem System wurde lediglich der Fokus auf IDML gesetzt. Es ist jedoch soflexibel ausgelegt, dass es ohne groe Anpassungen auch andere Formate verarbeiten kann. Somitsind die Anforderungen an den IDML-Server zufriedenstellend erfllt.Szenarien: Die Skripte, welche die Szenarien darstellen, knnen komplexe Prozesse abbildenund durch diese Art von Automatisierung Vorteile bewirken. Diese Vorteile knnen vor allem imBereich der Produktion liegen, da Prozesse verkrzt und optimiert werden. Auch die Qualitt derProdukte kann ber spezielle Skripte so gewhrleistet werden. Im Bereich der Wirtschaftlichkeitknnen hier fr Unternehmen Vorteile entstehen, da diese Art von IDML-Verarbeitung sonst nurmit einem kostenintensiven InDesign-Server mglich ist. Die Skripte sind speziell fr angepassteIDML-Dateien vorbereitet worden. Um diese Groovy-Skripte zu entwickeln, sind Spezialistennotwendig, die Erfahrung in InDesign, IDML und Groovy besitzen. Ein wirklich produktiver Ein-satz der Skripte setzt auerdem einheitliche und strukturierte IDML-Dateien vorraus. Diese Artvon Verarbeitung kann jedoch selten im knstlerischen Bereich eingesetzt werden. Es ist in ersterLinie darauf ausgelegt, strukturierte Ablufe zu optimieren.Zusammenfassend kann gesagt werden, dass der Einsatz eines IDML-Servers groe Vorteile bringenkann. Wichtig ist, dass die IDML-Dateien strukturiert aufbereitet sind und die Skripte professionellerstellt werden. Das bedeutet allerdings auch, dass man sich mit diesen Themen intensiv auseinandersetzten muss, um wirklich produktiv diese Vorteile zu erzielen. 63. 634.3 Blick in die ZukunftDas Konzept, das hier betrachtet wurde, kann und soll weiterentwickelt werden. Folgend werden Ideenbetrachtet, die in Zukunft in den IDML-Server einflieen knnen:JSON: In dieser ersten Version des IDML-Servers gibt der Webservice die Daten als XML zurck.Es kann von Vorteil sein hier auch das JSON-Format zu untersttzen, da es die gleichen Daten oftkleiner als XML darstellen kann. Die Anpassung ist in dem Grails-Framework sehr einfach umzu-setzen und knnte ber den Webservice per Parameter beeinflusst werden.Ergebnis: Das Ergebnis, was ber den Webservice dargestellt wird, ist in dieser ersten Versioneine Map. Um den Webservice strukturierter aufzubauen, kann eine Ergebnis-Klasse erzeugt wer-den, die feste und variable Werte aufnehmen kann. Die festen Werte knnen dann beispielsweisefr spezielle Nachrichten und Codes verwendet werden, die immer in einem Webservice-Ergebnisvorhanden sein mssen. Die variablen Werte knnen dann individuell beansprucht werden.Versionierung: Bei einer Weiterentwicklung des Webservices sollte eine Versionierung des Web-service in Betracht gezogen werden. Ist der IDML-Server einmal in bestehende Workflows ein-gebunden, knnen Vernderungen des Webservices den ganzen Workflow gefhrden. Der Einsatzeines versionierten Webservices knnte hier Abhilfe schaffen.Multiupload: In dieser ersten Version kann pro Serveranfrage immer nur eine Datei hochgeladenwerden. Fr zuknftige Versionen knnte man einen Multiupload entwickeln, der den Ablauf be-schleunigen knnte.Parameter: Der Webservice kann individuelle Parameter beinhalten, die dann von den Groovy-Skripten verarbeitet werden knnen. Diese Parameter werden in dieser ersten Version nicht imWebservice-Ergebnis angebunden. Hier sollten der Vollstndigkeit halber nicht nur die festen Pa-rameter, sondern auch die variable Parameter gesetzt werden.Asynchron: Der Server arbeitet in dieser ersten Version synchron. Das bedeutet, es ist mglich anden Server eine Anfrage zu stellen. Diese wird dann verarbeitet und es wird ein Ergebnis zurckgegeben. Dieser Verarbeitungsvorgang kann unter Umstnden lange dauern. Daher knnte maneinen asynchronen Ansatz whlen, indem man in der Process-Engine mit einer Queue arbeitet, dieKommandos entgegen nehmen kann. Der Ansatz beruht hier auf dem Command-Muster. Dieser inKombination mit dem State-Muster kann eine asynchronen Verarbeitungsprozess realisieren. DerAnfragende stt somit nicht direkt die Verarbeitung an, sondern fgt der Queue ein Kommandohinzu. Ein Ergebnis, ob das Kommando in dem Verarbeitungsprozess angekommen ist kann sofort 64. 64zurck gegeben werden. Wann genau das Kommando verarbeitet wurde und wann genau er abge-schlossen wird, ist nicht direkt fr den Anfragenden sichtbar. Er kann aber den Status der Verarbei-tung ber den Webservice abfragen, der einem dann sofort zurckgeben kann, ob die Verarbeitungnoch im Gange oder bereits abgeschlossen ist.Benutzerverwaltung: Eine weitere Mglichkeit liegt in der Einfhrung einer Benutzerverwal-tung. Die Unterscheidung zwischen einem Benutzer fr das System und einem Administrator kanneine deutliche Trennung zwischen den Aufgabenbereichen darstellen. Ein Administrator kann so-mit das System konfigurieren und Benutzer verwalten. Benutzer knnen so unterschiedliche Rech-te auf Verarbeitungsprozesse haben. Ein Benutzer kann somit beispielsweise nur Verarbeitungenim Qualittsbereich ausfhren, die keine Vernderungen der Dateien vornehmen. Im Gegensatzdazu knnte ein bersetzter Rechte auf Verarbeitungen im Bereich der Textmanipulation haben.Skriptverwaltung: Die Skripte knnten in einer weiteren Version des IDML-Servers ber eineBenutzeroberflche verwaltet werden. Dazu knnte es ber die Benutzerverwaltung eine Rolle desEntwicklers geben, der Zugriff auf die Skripte hat und diese hochladen, erstellen und verndernkann.Datenbank: Die Verwendung einer Datenbank knnte den IDML-Server weiter optimieren. Da-bei knnten Informationen ber die Benutzer und die Skripte in der Datenbank platziert werden.Download: Der Downloadprozess ist in erster Version des IDML-Servers sehr einfach gehalten.Er stellt den ganzen Output zur Verfgung. Bei einer Verarbeitung in der mehrere Dateien erzeugtwerden, kann es erforderlich sein nur Zugriff auf eine spezielle Datei zu erhalten. Der Download-prozess knnte so weiterentwickelt werden, dass auch einzelne Dateien aus dem Outputordnerheruntergeladen werden knnen.Temporaryordner: Der Temporaryordner wird bislang nur im Downloadprozess verwendet. DerZugriff auf diesen Ordner knnte aber auch in Groovy-Skripten Verwendung finden.Zusammenfassend kann gesagt werden, dass es noch viele Mglichkeiten gibt, diesen IDML-Serversinnvoll auszubauen. Der Blick in die Zukunft zeigt mgliche Entwicklungen. 65. 65AbbildungsverzeichnisAbbildung Beschreibung Seite1 MVC Ablauf 92 SOAP-Nachricht 133 Grails Einordnung 144 Groovy/Java Plattform 155 Spring Modules 206 Grails Applikation 227 IDML Container Aufbau 338 IDML-Server 389 Workflow Ablauf 4010 IDML-Server Index Seite 4311 IDML-Server Process Index Seite 4412 InDesign Script Label 57 66. 66AbkrzungsverzeichnisAbkrzung BeschreibungACID Atomicity Consistency Isolation DurabilityAJAX Asynchronous JavaScript and XMLAOP Aspect-Oriented ProgrammingCoC Convention over ConfigurationCS Creative SuiteCSS Cascading Style SheetsDOM Document Object ModelDI Dependency InjectionDRY Dont Repeat YourselfDTP Desktop PublishingeBook Electronic BookEL Expression LanguageEPUB Electronic PublicationEVA Eingabe, Verarbeitung, AusgabeGDK Groovy Development KitGORM Grails Object Relational MappingGPath Groovy Path LanguageGSP Groovy Server PageGString Groovy StringHTTP Hypertext Transfer ProtocolIDML InDesign Markup LanguageIDMS InDesign SnippetINDD InDesign Document FormatINX InDesign Interchange FormatIoC Inversion of ControlJDK Java DevelopmentKitJS JavaScriptJSON JavaScript Object NotationJSP Java Server PageJVM Java Virtual MachineMIMETYPE Multipurpose Internet Mail Extensions TypeMVC Model View ControllerORM Object Relational MappingPDF Portable Document Format 67. 67Abkrzung BeschreibungPOJO Plain Old Java ObjectRDF Resource Description FrameworkREST Representational State TransferRNG Regular Language Description for XML New GenerationSEI Software Engineering InstituteSOAP Simple Object Access ProtocolSQL Structured Query LanguageUCF Universal Container FormatURI Uniform Resource IdentifierURL Uniform Resource LocatorUUID Universally Unique IdentifierW3C World Wide Web ConsortiumWSDL Web Service Description LanguageXML Extensible Markup LanguageXPath XML Path LanguageXQuery XML Query LanguageXMP Extensible Metadata PlatformXSLT Extensible Stylesheet Language Transformation 68. 68Literaturverzeichnis[Adobe2012] Adobe Systems 2012, https://wwwimages2.adobe.com/content/dam/Adobe/en/devnet/indesign/sdk/cs6/idml/idml-specification.pdf (2013-01-07)[Bayer2002] Thomas Bayer, REST Web Services, 2002, http://www.oio.de/public/xml/rest-webservices.pdf (2012-12-19)[Booth2004] David Booth, Hugo Haas, Francis McCabe, Eric Newcomer, MichaelChampion, Chris Ferris, David Orchard: Web Services Architecture,2004, http://www.w3.org/TR/ws-arch/ (2012-12-18)[Carnegie2012] Carnegie Mellon Software Engineering Institute, http://www.sei.cmu.edu/architecture/start/glossary/community.cfm#definitions (2012-11-06)[DatabasePublishing2011] Database Publishing mit IDML 2011, https://www.youtube.com/watch?v=IpbJudaJFH4 (2013-02-17)[Davis2008] Scott Davis: Groovy Recipes Greasing the Wheels of Java, ThePragmatic Programmers, 2008[Fielding2000] Roy Thomas Fielding: Architectural Styles and the Design ofNetwork-based Software Architectures, 2000, https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm (2012-12-19)[Freeman2004] Eric Freeman, Elisabeth Freeman, Bert Bates, Kathy Sierra: Head FirstDesign Patterns, OReilly Media, 2004[Frotscher2007] Thilo Frotscher, Marc Teufel, Dapeng Wang: Java Web Services mitApache Axis2, entwickler.press, 2007[Gamma2011] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Ent-wurfsmuster: Elemente wiederverwendbarer objektorientierter Soft-ware, Addion-Wesley Verlag, 2011 69. 69[Grandeur2009] Grandeur: researching groovy & grails, 2009, http://www.gayadesign.com/scripts/uploads/researchpaper.pdf (2012-12-21)[Groovy2012] Groovy Closures - Formal Definition, http://groovy.codehaus.org/Closures+-+Formal+Definition (2012-12-29)[Hunt2003] Andrew Hunt, David Thomas: Der Pragmatische Programmierer, Han-ser, 2003[IDMLlib2013] IDMLlib for Java, http://idmllib.com/ILWebsite/Products/IDMLlib-for-Java (2013-01-13)[Johnson2004] Rod Johnson, Juergen Hoeller: J2EE Development without EJB, Wi-ley Publishing Inc, 2004[Johnson2005] Rod Johnson,Juergen Hoeller,Alef Arendsen,Thomas Risberg,ColinSampaleanu: Professional Java Development with the Spring Frame-work, Wiley Publishing Inc, 2005[Kipphan2000] Helmut Kipphan: Handbuch der Printmedien, Springer Verlag, 2000[Knig2007] Dierk Knig, Andrew Glover, Paul King, Guillaume Laforge, JonSkeet: Groovy in Action, Manning Publications Co., 2007[Kruchten1995] Philippe Kruchten: Architectural BlueprintsThe 4+1 View Modelof Software Architecture, IEEE Software November 1995 http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf (2012-11-06)[Oltmanns2007] Daniel Oltmanns, Stefan Edlich: Spring 2 fr Grnschnbel, Bookson Demand GmbH, 2007[Pouryekta2011] Peyman Pouryekta: Analyse und Bewertung der InDesign MarkupLanguage - Desktop Publishing vs. Database Publishing, VDM Ver-lag Dr. Mller, 2011[Rocher2009] Graeme Rocher, Jeff Brown: The Definitive Guide to Grails, Apress,2009 70. 70[Snell2002] James Snell,Doug Tidwell,Paul Kulchenko: Webservice-Programmie-rung mit SOAP, OReilly, 2002[SpringDocu2012] Spring Documentation: 1. Introduction to Spring, http://static.springsource.org/spring/docs/3.0.x/reference/overview.html, (2012-12-30)[Starke2009] Gernot Starke: Effektive Software Architekturen, Ein praktischer Leit-faden, Hanser Verlag 2009[Wolff2009] Eberhard Wolff: ber Architekturen und Perfektion, http://jandi-andme.blogspot.de/2009/10/uber-architekturen-und-perfektion.html(2010-11-07) 71. 71AAblaufplan 7abstraction 6Abstraktion 6, 8ACID 25Adobe 4Adobe Creative Suite 30AJAX 27Analyse 7AOP 26application.properties 22Arbeitsaufwand 4Architekturmuster 8Aspect-Oriented-Programming 26Assoziationen 9sthetik 6Asynchron 63Asynchronous JavaScript and XML26Atomicity 25Auslieferung 13Authentifizierung 13Autorisierung 13BBackingStory.xml 35Bauplan 7Benutzerverwaltung 64Beschnittzugabe 31Blitzer 31Body 13BootStrap.groovy 22BuildConfig.groovy 22Builder 11Built-in Tag 28CCarnegie Mellon Software Enginee-ring Institute 6Classpath 50Closure 16Cloud 38CoC 21, 48Code-Generierung 13Collection 18Color 34Command 11composition 6Config.groovy 22config.properties 45, 46, 50Consistency 25Constructor-Injection 21Containerformat 33container.xml 35Controller 9, 26Convention over Configuration 21Corporate-Design-Vorgaben 56, 57CRUD 27CS4 4Custom Tag 29DDatabase-Publishing 60, 61DatabasePublishing.groovy 60DataSource.groovy 22Datei Download 41Dateinamen 5Datei Upload 41, 47Datenmodell 9Datentypen 17decomposition 6DELETE-Methode 14Dependency Injection 20designmap.xml 34design pattern 7, 10Desktop-Publishing 5, 30development view 7DI 21Diagramm 5Dokumenterstellung 30Dont Repeat Yourself 21Druck- und Medienindustrie 4DRY 21DTP 30Durability 25Dynamic Dispatching 27Dynamic Tag 28dynamisch typisiert 15EeBook 31electronic book 31Electronic Publication 31Encoding 33Entwicklungsumgebung 22Entwurfsentscheidungen 7Entwurfsmuster 7, 10Entwurfsprobleme 7Envelope 12EPUB 31Erich Gamma 10Erzeugungsmuster 10esthetics 6EVA-Prinzip 38Expression Language 27Extensible Markup Language 12Extensible Metadata Platform 35Extensible Stylesheet LanguageStichwortverzeichnis 72. 72Transformation 32ExtractText.groovy 54FFlexibilitt 8, 9Flietext 5Flyer 54Fonts.xml 34Formfelder 31Framework 5GGET-Methode 14GORM 23, 24GPath 19Gradients 34Graeme Rocher 5Grails 5, 14grails-app 22Grails-Applikation 21Grails-Framework 5, 6, 14Grails-Kommando 5Grails Object Relational Mapping 23Graphic.xml 34Groovy 5, 6, 15Groovy-Path 19Groovy Server Page 27Groovy-Skripte 41Groovy-String 17Grundlayout 27Gruppen 31GSP 27GString 17Guillaume Laforge 5HHandzettel 59Header 13Hibernate-Framework 15HTML 5HTTP 12Hypertext Transfer Protocol 12IIDML 5, 30IDML-Spezifikation 5, 32IDMS 35IdmsGroupExport.groovy 57Import 15ImportIdms.groovy 59INDD 31InDesign 30InDesign Document Format 31InDesign Markup Language 4InDesign Snippet 35Informationstechnik 4Interchange Format 32Inversion of Control 20INX 32, 33IoC 20Isolation 25JJames Strachan 15JavaScript Object Notation 26Java Server Page 27Java Virtual Machine 15JSON 26, 63JSP 27JVM 15KKapselung 35Klassenpfad 50Knpfe 31Komplexitt 7Komponenten 7Komposition 5Kompression 33Konsequenzabschnitt 10Konstruktionsplan 32Konventionen 5Konzept 4Llayering 8Lazy loading Mechanismus 35Linien-Elemente 31List 18Lizenzkosten 4logical view 7Lsungsabschnitt 10MMap 18Mapping.xml 35MasterSpread 34Medienprodukt 54Messaging-Framework 12metadata.xml 35meta Tag 27MIMETYPE 34Model 9, 39Model View Controller 8Multipurpose Internet Mail Extensi-ons Type 34Multiupload 63Mustername 10MVC 8, 9, 45NNULL-Check 18NullPointerException 18O 73. 73Object Relational Mapping 15Open-Source-Framework 20Orchestrierung 5Ordnung 7ORM 15Oval-Elemente 31PPDF 31Performance 8, 9Persistenz-Framework 15Philippe Kruchten 6, 7physical view 7Plain Old Java Object 15Plne 7POJO 15Polyglot Programming 35Polygon-Elemente 31Portable Document Format 31POST-Methode 14Prsentation 9Preferences.xml 34Problemabschnitt 10Process-Engine 39, 41process view 7Produktionsumgebung 22Programmsteuerung 9proprietr 4, 31Prototyp 42, 61, 62PUT-Methode 14Python 15QQualitt 8Qualittssicherung 36Quasi-Standard 9RRange 18RDF 35Realisierung 7Rechteck-Elemente 31Regular Language Description forXML New Generation 32Representational State Transfer 6Resource Description Framework 35Resources 34REST 6, 12, 13, 39return Statement 18RNG 32Rod Johnson 5Routing 13Ruby 15SScaffolding 27scenario 7Schichten 8, 39Schichtenmuster 8Scripting 19SEI 6Semikolon 16Session Beendigung 42, 51Session Erzeugung 41, 43Setter-Injection 21Sichten 7Simple Object Access Protocol 6Single Point of Failure 38Singleton 11SiteMesh 15, 27Skriptverwaltung 64Smalltalk 15SOAP 6, 12SOAP-Nachricht 12SOAP-Schnittstelle 39Softwarearchitektur 6Softwareentwicklung 5Spread 34Spring 20Spring-Framework 5SQL 24State 11Stil 6Stories 34Story.xml 35StrokeStyle 34Structured Query Language 24Struktur 7Strukturmuster 10style 6Styles.xml 34Ttaglib 29Tags.xml 35Testumgebung 22Text-Elemente 31TextManipulation.groovy 55Tomcat 30, 43Transaktionskontext 13Transformierung 32Typografie 5, 30Typografische Konventionen 5Ubersetzungsworkflow 36UCF 33Uniform Resource Identifier 13Universal Container Format 33Universally Unique Identifier 40Unternehmensbroschren 54URI 13URL 5UrlMappings.groovy 23 74. 74UUID 40VValidate.groovy 56Validator 23Verarbeitung 41, 48Verhaltensmuster 10Versionierung 63Versionskompatibilitt 4Verstndlichkeit 7, 8View 9WW3C 12WAR 30Wartbarkeit 9Web Application Archive 30Webservice 6, 12, 39Web Service Description Language12Web-to-Print 61Werkzeug 4Wiederverwendbarkeit 59World Wide Web Consortium 12WSDL 12, 13, 40XXML 5, 12, 19XML-Overhead 40XML Path Language 32XML Query Language 32XMP 35XPath 32XQuery 32XSLT 32ZZerlegung 6ZIP 51ZIP-Archiv 33Zusammensetzung 6Zwiebel 8

Recommended

View more >