Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung

Freie wissenschaftliche Arbeit zur Erlangung des akademischen Grades
Master of Science in Wirtschaftsinformatik
Entwicklung eines Konzepts und einer flexiblen
Architektur für ein Framework zur automatisierten,
plattformübergreifenden Generierung von SDKs zum
Zugriff auf Webservices unter Anwendung von
Methoden der modellgetriebenen Softwareentwicklung.
Abschlussarbeit
im Master-Studiengang Wirtschaftsinformatik
im Fachbereich Wirtschaftswissenschaften II
der Hochschule für Technik und Wirtschaft Berlin
Vorgelegt von: Mathias Slawik
Achillesstr. 44
13125 Berlin
Matr.-Nr.: 517918
Erstbetreuer: Prof. Dr. Margret Stanierowski
Zweitbetreuer: Prof. Dr. Holger Hemling
Abgabetermin: 5. September 2011

Inhaltsverzeichnis
i
Inhaltsverzeichnis
1 Einleitung ............................................................................................1
2 Analyse von Technologien und Methoden...........................................3
2.1 Modellgetriebene Softwareentwicklung ......................................................... 3
2.1.1 Konsequenzen modellgetriebener Entwicklung.......................................... 5
2.2 Kommunikations-Architekturstile in Serviceorientierten Architekturen ........... 6
2.2.1 Remote Procedure Call (XML-RPC, SOAP)................................................ 6
2.2.2 Ressourcenorientiert (REST) ...................................................................... 9
2.3 Eclipse Modeling Project .............................................................................. 11
2.3.1 Eclipse Modeling Framework (EMF) ........................................................ 13
2.3.2 Ecore ...................................................................................................... 15
2.4 Haupttechnologien des vorhandenen Frameworks........................................ 18
2.4.1 openArchitectureWare............................................................................ 18
2.4.2 Xtend ..................................................................................................... 19
2.4.3 Xpand..................................................................................................... 23
2.4.4 Modeling Workflow Engine (MWE) ........................................................ 24
2.5 Einzusetzende Technologien in GenerationREST........................................... 25
2.5.1 Xtend 2 .................................................................................................. 25
2.5.2 Xtext ...................................................................................................... 29
2.5.3 Modeling Workflow Engine 2 (MWE2) ................................................... 31
2.5.4 Docbook XML ........................................................................................ 32
2.6 Developer Garden......................................................................................... 32
3 Analyse der vorhandenen Lösung......................................................34
3.1 Iteration 1: SOAP-Benutzerdokumentation................................................... 35
3.2 Iteration 2: REST........................................................................................... 40
3.3 Iteration 3: SDK-Generierung........................................................................ 46
3.4 Iteration 4: AutoScout24 – API...................................................................... 54
3.5 Iteration 5: Refaktorierung / Eclipse OSGi .................................................... 57
3.6 Ableitung eines neuen Lösungsansatzes....................................................... 59

Inhaltsverzeichnis
ii
4 GenerationREST: Konzipierung und Implementierung .......................61
4.1 Metamodell.................................................................................................. 62
4.1.1 Paket structure ....................................................................................... 62
4.1.2 Paket rest ............................................................................................... 66
4.1.3 Paket documentation.............................................................................. 69
4.1.4 Paket generation .................................................................................... 71
4.1.5 Paket sdk................................................................................................ 74
4.2 Realisierungsmöglichkeiten funktionaler Erweiterungen............................... 76
4.3 Umsetzung der funktionalen Erweiterungen in GenerationREST ................... 79
4.4 Grammatiken................................................................................................ 80
4.4.1 Service-Grammatik ................................................................................. 81
4.4.2 Konfigurations-Grammatik...................................................................... 84
4.5 Code-Generatoren........................................................................................ 86
4.6 Dokumentations-Generator .......................................................................... 87
4.7 Weitere Komponenten.................................................................................. 87
4.8 Test des Framework-Prototypen ................................................................... 88
5 Zusammenfassung und Ausblick........................................................92
5.1 Vergleich des Konzepts mit anderen Frameworks......................................... 94
5.2 Zukunft von GenerationREST........................................................................ 97
6 Fazit ..................................................................................................98

Abbildungsverzeichnis
iii
Abbildungsverzeichnis
Abbildung 1 - Überblick über das Eclipse Modeling Project ......................................... 11
Abbildung 2 - Beispiel für EMP-Amalgamation............................................................... 13
Abbildung 3 - Ecore-Modellelemente (Auswahl)............................................................. 15
Abbildung 4 - Xtend-Funktionen (Ausschnitt)................................................................. 19
Abbildung 5 - Xtend dynamische Bindung: Klassenhierarchie ..................................... 21
Abbildung 6 - Xtend dynamische Bindung: Xtend-Ausdrücke ..................................... 21
Abbildung 7 - Automatische Leerraum-Behandlung in Xtend Rich Strings................ 28
Abbildung 8 - Xtext-DSL (Ausschnitt) ............................................................................... 30
Abbildung 9 - Multiple Zugriffsmöglichkeiten auf Xtext-Dateien ................................ 30
Abbildung 10 - Abstrakte und konkrete Syntax der ersten Iteration ............................ 36
Abbildung 11 - Content-Repository (Ausschnitt)............................................................. 37
Abbildung 12 - Grundkonzept der ersten Iteration ......................................................... 38
Abbildung 13 - Metamodell nach der ersten Iteration (Januar 2010) ............................ 39
Abbildung 14 - Neue REST-Elemente der zweiten Iteration (März 2010) .................... 42
Abbildung 15 - Bildung der REST-URL aus Modellelementen...................................... 43
Abbildung 16 - Lösungskonzept der Iteration 3............................................................... 49
Abbildung 17 - Neue Elemente und Beziehungen der dritten Iteration....................... 51
Abbildung 18 - Diagramm des Pakets structure............................................................... 63
Abbildung 19 - Generische Typparameter ........................................................................ 65
Abbildung 20 - "Xtext Syntax Graph" (Ausschnitt).......................................................... 81
Abbildung 21 - Typ-Deklaration (Beispiel) ....................................................................... 81
Abbildung 22 - Vorlagen-Definition (Beispiel) ................................................................. 82
Abbildung 23 - Endpunkt-Deklaration (Beispiel)............................................................. 82
Abbildung 24 - Service- und Methoden-Deklaration (Beispiel)..................................... 83
Abbildung 25 - Generations-Konfiguration (Beispiel)..................................................... 85
Abbildung 26 - Konfiguration einer neuen GenerationREST Eclipse-Instanz............. 89

Verwendete Konventionen
iv
Verwendete Konventionen
In dieser Arbeit werden die folgenden typograﬁschen Konventionen verwendet:
Serifenlose Fettschrift
Verwendet für alle Überschriften, sowie gliedernde Wortgruppen.
Serifenlose Normalschrift
Verwendet für alle Modellelement-Referenzen
Serifenbehaftete Schrift
Verwendet für den Textkörper
Diktengleiche Schrift
Verwendet für Programmcode und literale Ausdrücke

Einleitung
1
1 Einleitung
Eine Betrachtung der aktuellen Trends in der Informationstechnologie zeigt eine kla-
re Hinwendung vieler Technologien zum Cloud Computing, der Bereitstellung von
Infrastruktur, Diensten und Software im Internet. Dieser Wandel bringt neue Prob-
lemfelder mit sich, unter anderem die effiziente Kommunikation zwischen Cloud-
Diensten, bzw. Web Services.
Viele Unternehmen wenden RPC als Architekturstil und darauf aufbauend SOAP als
Kommunikationsprotokoll in unternehmensinternen Serviceorientierten Architektu-
ren an. SOAP bietet Lösungen für Problemstellungen im Unternehmensumfeld, wie
beispielsweise verteiltes Transaktionsmanagement1
oder die Zusicherung von Integ-
rität und Vertraulichkeit2
der Service-Kommunikation. Die Formalisierung von
SOAP über die WSDL ermöglicht darüber hinaus die automatische Generierung von
Schnittstellenadaptern.
Die Vielzahl an Anforderungen an SOAP im Unternehmenseinsatz geht mit einer
häufigen Schwergewichtigkeit plattformspezifischer SOAP-Frameworks einher.
Durch den teilweise komplexen Aufbau von SOAP-Kommunikation gestaltet sich die
Ansprache von SOAP-Schnittstellen ohne generierte Adapter als sehr aufwändig.
Diese Faktoren tragen dazu bei, dass Cloud-Dienste andere Architekturmodelle und
Kommunikationsprotokolle als RPC/SOAP einsetzen.3
Für die Konzipierung der Kommunikation mit Cloud-Diensten wird häufig der
REST-Architekturstil4
angewendet. Die Ansprache von REST-Schnittstellen ist auf-
grund zahlreicher Aspekte5
im Vergleich mit SOAP deutlich einfacher.
Jedoch existiert ohne formale Beschreibungssprache von REST - Schnittstellen keine
Möglichkeit, den Implementierungsaufwand von Schnittstellenadaptern und SDKs
durch automatische Generierung zu verringern. Zwar existieren einige Ansätze für
eine formale Beschreibung von REST-Schnittstellen und darauf aufbauender Code-
Generierung6
, gleichwohl hat in Praxi keiner davon eine weite Verbreitung gefun-
den.
1
WS-Transaction: (Organization for the Advancement of Structured Information Standards, 2011A)
2
WS-Security: (Organization for the Advancement of Structured Information Standards, 2011)
3
Vgl. (ProgrammableWeb.com, 2011): Von 3.400 gelisteten APIs sind nur 16% (560) SOAP-APIs
4
(Fielding, 2000)
5
(Richardson, et al., 2007 S. 299-314)
6
Siehe Kapitel 5.1 (S. 102)

Einleitung
2
Im Laufe meiner Beschäftigung bei der Deutschen Telekom AG habe ich seit Anfang
des Jahres 2010 in mehreren Iterationen ein Framework entwickelt, auf dessen Basis
die SDKs zur Ansprache der REST – Schnittstellen des Developer Gardens generiert
werden. Grundlage dieses Frameworks ist eine formale Beschreibungssprache der
REST-APIs des Developer Gardens, sowie Code-Templates.
In dieser Arbeit wird auf Basis einer umfangreichen Analyse des vorhandenen
Frameworks ein allgemeines Metamodell für REST-Schnittstellen entwickelt und da-
rauf aufbauend eine ﬂexible Architektur für ein plattformübergreifendes Generie-
rungsframework, GenerationREST, konzipiert. Dieses Konzept generalisiert und er-
weitert das entwickelte Telekom-Framework zu einem universellen Werkzeug zur
Generierung von REST-Schnittstellenadaptern. Darüber hinaus arbeitet das Konzept
die während der Konzeption und Realisierung des derzeitigen Frameworks erlang-
ten Erkenntnisse mit ein.
In einer prototypischen Realisierung wird die Anwendbarkeit des Konzepts im
Rahmen der Developer Garden REST-API, sowie zwei weiterer nicht-Telekom REST-
APIs nachgewiesen. Außerdem wird das Konzept mit bestehenden alternativen
Konzepten zur Beschreibung von REST-Schnittstellen verglichen.
Als Abschluss der Arbeit wird ein Ausblick auf die Fertigstellung und die Zukunft
des Frameworks gegeben.

Analyse von Technologien und Methoden
3
2 Analyse von Technologien und Methoden
Dieses Kapitel soll die eingesetzten Technologien und Methoden hinsichtlich der
Verwendung in dieser Arbeit analysieren. Dies bildet die Grundlage für die darauf
folgende Anwendung der Technologien und Methoden in der Konzipierung und
prototypischen Implementierung von GenerationREST.
2.1 Modellgetriebene Softwareentwicklung7
Der Begriff „Modellgetriebene Softwareentwicklung“8
bezeichnet eine Entwick-
lungsmethodik, bei der Software-Bestandteile aus formalen Modellen generiert wer-
den. Software-Bestandteile sind beispielsweise Programmcode, Konfigurationsdatei-
en oder Dokumentation. Modelle können textuell oder grafisch repräsentiert werden.
Im Gegensatz zur modellgetriebenen Entwicklung spielen Modelle bei vielen ande-
ren Softwareentwicklungsmethoden im Entwicklungsprozess eine geringe Rolle, da
sie meist lediglich zur Dokumentation eingesetzt werden (z.B. UML-Diagramme).
In der modellgetriebenen Softwareentwicklung sind Modelle domänenspezifische, d.h.
auf ein konkretes Anwendungsgebiet bezogene, Abstraktionen der Realität, sie wer-
den häufig, gerade bei textueller Repräsentation, „Domänenspezifische Sprache“9
genannt. Sie unterscheiden sich damit von Abstraktionen, wie beispielsweise der
UML, die als universelle Abstraktion von Software und anderen Systemen dient.
Das Verhältnis von manuell implementierten zu generierten Softwarebestandteilen
variiert je nach Projekt: Die Suche nach dem für ein Softwareentwicklungsprojekt
optimalen Verhältnis zwischen den beiden Arten ist eine große Herausforderung, da
eine Erhöhung des Anteils an generierten Software-Bestandteilen zwar Produktivi-
tätszuwächse durch Automatisierung mit sich bringt, auf der anderen Seite jedoch
immer auch mit Aufwänden zur Konzipierung und Implementierung weiterer Meta-
Modelle und Modelltransformationen verbunden ist.
Meta-Modellebenen
Der Begriff „Meta-“ beschreibt die Beziehung zwischen zwei Modellen bzw. Ebe-
nen.10
Im Bereich der modellgetriebenen Softwareentwicklung werden Modelle in
hierarchische Ebenen aufgeteilt, wobei die Modellelemente der tieferen Ebene die
Elemente der nächsthöheren Ebene instanziieren.
7
Vgl. auch (Balzert, 2009 S. 79-87), (Beltran, et al., 2007 S. 11-13)
8
engl.: Model Driven Software Design = MDSD
9
engl.: Domain Specific Language = DSL
10
(Stahl, et al., 2007 S. 62)

4
Dabei wird häufig eine in den Veröffentlichungen der Object Management Group
(OMG)11
befindliche Definition verwendet:
Metaebene Rolle Beispiel
M3 Meta-Metamodell Formale Syntax und Semantik für
Metamodelle
ECore12
M2 Metamodell Formale Syntax und Semantik für
Modelle.
Service-Metamodell, Sample-
Metamodell, etc.
M1 Modell Legt fest, in welcher Form das Mo-
dell durch die M0-Ebene instanziiert
werden soll.
Developer Garden Modelle,
Flickr Modell
M0 Software Laufzeit-Instanz des Modells Developer Garden SDKs,
Flickr SDKs
Am Beispiel des Developer Garden SDKs werden diese Beziehungen deutlich:
• Die Developer Garden SDKs (M0) werden generiert aus dem Developer Gar-
den Modell (M1)
• Das Developer Garden Modell (M1) enthält Instanzen des Service-
Metamodells (M2)
• Das Service-Metamodell (M2) ist ein ECore-Modell (M3)
• ECore (M3) wird beschrieben durch ECore (M3)
Voraussetzungen
Voraussetzungen für die Durchführung von modellgetriebener Entwicklung sind:
• Formales Metamodell
Ein formales Metamodell stellt die Voraussetzung zur Definition von domä-
nenspezifischen Modellen dar. Das Metamodell enthält die Definition der für
die Modellierung zur Verfügung stehenden Sprachelemente.
• Domänenspezifisches Modell
Ein domänenspezifisches Modell enthält alle Informationen zum Anwen-
dungsbereich, die für die Generierung des Softwaresystems notwendig sind.
• M2T – Transformationen
Die Modell-zu-Text – Transformationen wandeln das in der Sprache des for-
malen Metamodells beschriebene, domänenspezifische Modell in Software-
Bestandteile um.
11
Beispielsweise (Object Management Group, 2009B S. 16-19)
12
Kapitel 2.3.2 (S. 16)

5
Für die Unterstützung modellgetriebener Softwareentwicklungsprojekte sind dar-
über hinaus weitere Technologien sinnvoll, beispielsweise:
• Grafische und Textuelle Syntax
Für unterschiedliche Domänen sind unterschiedliche Repräsentationsformen
optimal; so erfassen Domänenexperten aus der Betriebswirtschaft komplexe
modellierte Prozessketten besser, als XML-Code. Auf der anderen Seite sind
textuelle Syntaxen besonders bei technisch versierten IT-Domänenexperten
beliebt.
• M2M – Transformation
Umfangreiche Software-Entwicklungsprojekte verlangen meist nach mehreren
domänenspezifischen Modellen. Zur Transformation dieser Modelle unterei-
nander ist die Verfügbarkeit einer M2M-Transformationstechnologie von Vor-
teil.
• Dynamische Modellwerkzeuge
Zur Steigerung der Produktivität von modellgetriebenen Technologien sind
dynamische Modellwerkzeuge von Vorteil. Dies könnten beispielsweise eige-
ne Programmiersprachen zur besseren Handhabung von Modellrepräsentati-
onen sein oder Toolunterstützung bei der Anwendung modellgetriebener
Technologien in Software-Entwicklungsprojekten.
2.1.1 Konsequenzen modellgetriebener Entwicklung
Die Konsequenzen modellgetriebener Entwicklung gegenüber herkömmlichen Me-
thoden sind überaus mannigfaltig.
Grundsätzlich lässt sich feststellen, dass bei modellgetriebener Entwicklung Aspekte
der Produktivitäts- und Qualitätssteigerungen erhöhten Aufwänden durch abstrak-
tere und komplexere Problemlösungen gegenüber stehen.
Hiernach folgend sollen einige häufig auftretende positive, wie negative Konsequen-
zen modellgetriebener Entwicklung dargestellt werden:
Steigerung von Produktivität und Qualität Erhöhte Aufwände
Automatisierbarkeit wiederkehrender
Programmieraufgaben
Höherer Abstraktionsgrad, daher meist
komplexere Gesamtlösung und größere
Herausforderung
Wiederverwendbarkeit von Modellen,
DSLs und Generatoren
Fehlersuche durch höhere Komplexität
erschwert
Griffigere, domänenspezifische Abs-
traktion von Problemstellungen
Manuell implementierter Code u.U. leis-
tungsfähiger als generierter Code

6
Steigerung von Produktivität und Qualität Erhöhte Aufwände
Modell und Software sind immer kon-
sistent
Debugging meist nur für generierten
Code möglich
Modellwissen ist zugänglicher, als
Code-inhärentes Wissen
Zusammenführung von automatisch
generiertem und manuell implementier-
tem Code herausfordernd
Ein valides Modell erzeugt validen
Code
Plattformunabhängigkeit durch Ver-
meidung plattformspezifischer Aspekte
in den Modellen
Kommunikation mit Fachexperten fällt
durch Domänenspezifische Sprache
leichter
Meine eigenen Erfahrungen mit modellgetriebener Entwicklung stützen die genann-
ten positiven und negativen Konsequenzen.
2.2 Kommunikations-Architekturstile in Serviceorientierten Architekturen
Für die Kommunikation in Serviceorientierten Architekturen haben sich zwei Archi-
tekturstile etabliert: Remote Procedure Call (RPC) und der ressourcenorientierte Ar-
chitekturstil (REST).
2.2.1 Remote Procedure Call (XML-RPC, SOAP)
Remote Procedure Call ist ein Architekturstil, welcher den Aufruf von Prozeduren in
entfernten Kontexten abbildet. Diese Kontexte können sich entweder auf demselben
Rechner (RPC als Interprozess-Kommunikation) oder auf einem entfernten Rechner
befinden (RPC in Client-Server Systemen). Das Ziel von RPC ist die höchstmögliche
Transparenz des Aufrufs einer entfernten Prozedur im Vergleich zum Aufruf einer
Prozedur im selben Programm.
Erste Erwähnung findet der Stil bereits Mitte der siebziger Jahre des vergangenen
Jahrhunderts13
.
13
(White, 1975)

7
Mittlerweile existieren auf Remote Procedure Call aufbauende Technologien für eine
große Anzahl an Plattformen, unter anderem:
• Java Remote Method Invocation14
(RMI)
• Sun RPC15
für Unixoide Betriebssysteme
• Microsoft .NET Remoting16
und Remote Procedure Call17
Die vorgenannten Technologien haben die Gemeinsamkeit, auf bestimmte Pro-
grammiersprachen und Betriebssysteme beschränkt zu sein. Daher eignen sie sich
nur sehr beschränkt für heterogene Serviceorientierte Architekturen und Cloud
Dienste.
Das Internet ist das größte heterogene Rechnernetzwerk. Daher ist es naheliegend,
aus den Technologien, die das Internet hervorgebracht haben, Rückschlüsse für eine
plattform- und Programmiersprachenunabhängige RPC-Technologie zu ziehen, wel-
che in heterogenen Serviceorientierten Architekturen verwendet werden kann.
Zwei entscheidende RPC-Technologien, die das im Internet weit verbreitete HTT-
Protokoll zum Nachrichtenaustausch verwenden, sind XML-RPC und SOAP.
XML-RPC
XML-RPC18
ist eine im Sommer 1999 von einer Frühversion von SOAP („SOAP 98“)
abgeleitete19
Spezifikation für ein RPC-Protokoll, welche in heterogenen Netzwerken
(z.B. dem Internet) verwendet werden kann.
XML-RPC Nachrichten und Antworten stellen Prozeduraufrufe und Rückgabewerte
dar. Diese sind in einem in der XML-RPC Spezifikation festgeschriebenen XML-
Format codiert und werden per HTTP POST-Aufruf an einen Server versandt, wel-
cher synchron auf die Prozeduraufrufe mit einer Antwort- oder Fehlernachricht rea-
giert.
Das Besondere an XML-RPC ist die simpel strukturierte und dadurch für Menschen
relativ einfach zugängliche Nachrichtenformatierung. Allerdings enthält die XML-
RPC – Spezifikation über die Angaben zur Nachrichtenformatierung und Serialisie-
rungsformate einiger Datentypen keine Ansätze, Herausforderungen im Unterneh-
menseinsatz, wie z.B. verteilte Transaktionen oder verlässliche Übertragung, zu lö-
sen.
14
(Oracle Corporation, 2010)
15
(Sun Microsystems, Inc., 1988) und (Srinivasan, 1995)
16
(Parys, et al., 2004)
17
(Microsoft Corporation, 2011A)
18
(Winer, 1999)
19
(Box, 2001)

8
Obwohl zahlreiche Implementierungen bestehen20
und auch einige Softwareproduk-
te XML-RPC als Kommunikationstechnologie einsetzen21
, hat sich die Spezifikation
in Praxi nicht in großem Umfang durchgesetzt.
SOAP
SOAP ist wie XML-RPC eine Spezifikation für ein auf XML basierendes RPC-
Protokoll, welches in heterogenen Netzwerken, wie dem Internet, verwendet werden
kann.
Der erste Entwurf für SOAP entstand im März 1998 („SOAP 98“) durch drei Micro-
soft-Mitarbeiter als Alternative zum gescheiterten Versuch, Microsoft DCOM als
plattform- und programmiersprachenunabhängige RPC-Technologie zu etablieren.22
Im Laufe der Zeit wurde SOAP von Microsoft und gewonnenen Industriepartnern
(u.A. IBM, Sun & Oracle) weiterentwickelt und ist nun als offizielle W3C Spezifikati-
on23
verfügbar.
SOAP-Nachrichten und Antworten haben im Gegensatz zu XML-RPC einen komple-
xeren Aufbau. Eine SOAP-Nachricht besteht aus drei Teilen: SOAP Envelope, SOAP
Header und SOAP Body. Der SOAP Envelope, sozusagen der „Umschlag“ der Nach-
richt, ist das XML-Wurzelelement und kennzeichnet durch eine XML Namensraum-
Definition die Version der verwendeten SOAP-Version. Der SOAP Envelope enthält
zum einen optionale Kopfdaten der Nachricht und zum anderen den Nachrichten-
körper (SOAP Body).
Im Gegensatz zu XML-RPC erzwingt die SOAP-Spezifikation kein zu verwendendes
Transportprotokoll. SOAP-Nachrichten können daher je nach Anwendungsgebiet
über unterschiedliche Transportwege verschickt werden, beispielsweise per HTTP
(das geläufigste Transportprotokoll), SMTP (E-Mail) oder JMS (Warteschlangen-
Systeme).
Formale Beschreibung von SOAP
Eine Besonderheit von SOAP ist die formale Beschreibungssprache WSDL, mithilfe
derer SOAP-APIs beschrieben werden können. Aufgrund der Existenz einer forma-
len Beschreibungssprache ist es möglich, Schnittstellen-Adapter automatisch zu ge-
nerieren.
Allerdings trägt die Komplexität von SOAP und WSDL zur Verringerung der Ver-
ständlichkeit der Beschreibungssprache und der ausgetauschten Nachrichten bei.
20
u.A. für Java, Perl, PHP, Python und .NET, siehe (St.Laurent, et al., 2001)
21
Es existieren viele XML-RPC APIs für CMS- und Blog-Applikationen, u.A. (WordPress.org, 2011),
Joomla!: (Davenport, et al., 2010), SharePoint: (Microsoft Corporation, 2011)
22
(Ferguson, 2004)
23
(Gudgin, et al., 2007)

9
2.2.2 Ressourcenorientiert (REST)
Der Ressourcenorientierte Architekturstil (REST) wurde erstmals in der Doktorarbeit
von Roy Thomas Fielding24
ausgearbeitet, einem der Hauptautoren der HTTP25
und
URI26
– Spezifikationen.
Die grundlegende Idee besteht darin, eine Schnittstelle nicht wie bei RPC als Menge
von Methoden und Parametern zu abstrahieren, sondern mithilfe von Ressourcen
und Operationen. REST integriert die Standards URI und HTTP in ihrer originären
Anwendungsdomäne: Mithilfe von URIs werden Ressourcen adressiert, das HTTP-
Protokoll definiert die auf Ressourcen anzuwendenden Operationen, im Regelfall
GET, POST, PUT und DELETE.
Darüber hinaus nutzen REST-Schnittstellen viele im HTT-Protokoll vorgesehenen
Mechanismen in ihrer originären Anwendungsform. So wird z.B. die HTTP Content-
Negotiation (HTTP-Header Accept und Content-Type) für das Vereinbaren eines
gemeinsamen Datenaustauschformats wiederverwendet. Außerdem können REST
Antworten über dieselben Mechanismen zwischenspeichert werden, wie herkömmli-
che Internet-Inhalte (z.B. durch Übermittlung von Expire oder Last-Modified Hea-
dern). Letztendlich finden sich auch HTTP-Statuscodes in REST-Schnittstellen in ei-
ner vergleichbaren Rolle wieder, wie bei gängigen Internet-Anwendungen.
Obwohl der REST-Architekturstil wenige abstrakte Vorgaben bezüglich der konkre-
ten Gestaltung von REST-APIs beinhaltet, so zeigt sich in der Vielzahl der REST
Webservice-Schnittstellen die allgemeine Anwendbarkeit und die Qualität des Kon-
zepts. Außerdem tragen die Klarheit der Schnittstellendefinition sowie die Bezie-
hung auf ausgereifte Standards dazu bei, dass der REST-Architekturstil mittlerweile
zum vorherrschenden Muster für den Entwurf und die Implementierung von Web
Service-Schnittstellen geworden ist.
Beispiel der Anwendung des REST-Architekturstils anhand Amazon S3
27
Der Amazon Simple Storage Service (S3) ist ein gutes Beispiel für die Anwendung
des REST-Architekturstils zum Entwurf und zur Anwendung von Cloud-Services.
24
(Fielding, 2000)
25
(Fielding, et al., 1999) und (Berners-Lee, et al., 1996)
26
(Berners-Lee, et al., 2005A)
27
Entnommen, zusammengefasst und übersetzt aus (Richardson, et al., 2007 S. 49-54)

10
Amazon S3 ermöglicht die Speicherung beliebig strukturierter Daten und Metadaten
als Objekte in sog. „Buckets“. „Buckets“ spielen eine ähnliche Rolle, wie Verzeich-
nisse in herkömmlichen Dateisystemen und bieten eine logische Strukturierungs-
möglichkeit für Datenobjekte. Die Amazon S3 REST-Schnittstelle bietet die üblichen
CRUD-Operationen28
auf diesen Daten an.
Die folgende Tabelle zeigt die Umsetzung der S3 REST-API, d.h. die Resourcen und
unterstützten HTTP-Operationen:
Ressource GET HEAD PUT DELETE
Liste der Buckets
/
Listet die eigenen
Buckets auf
- - -
Ein Bucket
/{bucket}
Listet die Objekte
eines Buckets auf
-
Erzeugt ein Bu-
cket
Löscht ein Bucket
Ein Objekt
/{bucket}/{object}
Holt das Objekt
und die Metada-
ten
Holt die Metada-
ten des Objekts
Speichert den
Wert eines Ob-
jekts und dessen
Metadaten
Löscht ein Objekt
In dieser Tabelle zeigt sich die Besonderheit eines guten REST-Entwurfs: „Everything
does what it says.“29
.
Die Kombination von einfach adressierbaren Ressourcen und Standard HTTP-
Verben führt zu einer deutlich einfacheren Schnittstellenbeschreibung als mit RPC
jemals möglich wäre. Denn bei RPC-Schnittstellen würde für jede mögliche Operati-
on eine Methode definiert werden müssen, z.B. „ListAllMyBuckets“ oder „GetObjec-
tInBucket“. Darüber hinaus lösen viele RPC-Schnittstellen die Adressierung von Res-
sourcen über schnittstellenspezifische Mechanismen, die häufig weniger zugänglich
sind, als URIs.
Insgesamt ist es bemerkenswert, dass die prinzipielle Schnittstellenbeschreibung ei-
nes REST Web Services, wie Amazon S3, durch eine solch kurze Tabelle ausdrückbar
ist.
Formale Beschreibungssprachen
Es existieren einige Ansätze30
für formale Beschreibungssprachen für REST-
Schnittstellen, jedoch hat bisher keiner der Ansätze eine weite Verbreitung gefunden.
28
Create, Read, Update, Delete: Erzeugen, Speichern, Ändern, Löschen
29
(Richardson, et al., 2007 S. 53)
30
Kapitel „Proposals on Description Languages for REST APIs“: (Steiner, 2007)

11
Einige Frameworks31
nutzen WADL32
als Beschreibungssprache, jedoch existieren in
Praxi viele Zweifel33
, ob eine formale Beschreibungssprache für den REST-
Architekturstil grundsätzlich sinnvoll ist. Allerdings sind die Zweifel meist mit der
hohen Komplexität der SOAP-Beschreibungssprache WSDL verbunden.
2.3 Eclipse Modeling Project
Eclipse Modeling Framework (EMF)
= Zentrales Projekt, stellt u.A. Metamodell bereit
EMF (Core) CDOCompareQuery Query 2
TransactionNet4j SDO Teneo Validation
Textual Modeling Framework (TMF)
Xtext TCS
Graphical Modeling Project (GMP)
Tooling Runtime
Notation Graphiti
Definition konkreter Syntax
Model Development
Tools (MDT)
BPMN Metamodel
eTrice (ROOM)
MoDisco
OCL
Papyrus
Sphinx
UML2
XSD
M2M
Atlas (ATL)
M2T
JET Xpand
Modelltransformation
Technology & Research
GMT
AM3
AMW
MOFScript
UMLX
Viatra2
Epsilon GEMS MoDisco
Forschungund
Inkubation
Anwendung
Amalgam
Verfügbarmachung
Abbildung 1 - Überblick über das Eclipse Modeling Project34 35
31
Vgl. auch Kapitel 5.1 (S. 106)
32
(Hadley, 2011)
33
Vgl. auch (Gregorio, 2007) und (Rotem-Gal-Oz, 2007)
34
Quelle: Eigene Darstellung
35
Für eine vollständige Übersicht aller Technologien siehe: (The Eclipse Foundation, 2011)

12
Das Eclipse Modeling Project ist der „Schmelztiegel“ der modellgetriebenen Ent-
wicklung auf Basis der Eclipse Plattform.36
Es beherbergt zahlreiche Technologien für
ein weites Spektrum an Anwendungen modellgetriebener Entwicklungsmethoden:
Abstract Syntax Development & Concrete Syntax Development
Die Definition von Modellen innerhalb der Eclipse-Plattform gliedert sich in zwei
Bereiche: der Definition der abstrakten Syntax, d.h. die Festlegung der zur Verfü-
gung stehenden Sprachelemente sowie der Definition der konkreten Syntax, d.h. die
Verwendung der Sprachelemente zur Definition eines konkreten Modells.
Die abstrakte Syntax innerhalb modellgetriebener Eclipse-Entwicklungsprojekte
wird durch die Technologien des Eclipse Modeling Frameworks (EMF) festgelegt,
vor allem durch das darin enthaltene Metamodell Ecore.
Die Entwicklung konkreter Syntaxdefinitionen kann sowohl grafisch (Graphical Mo-
deling Project – GMP), als auch textuell (Textual Modeling Framework – TMF) erfol-
gen.
Model Development Tools (MDT)
Zur Unterstützung der modellgetriebenen Eclipse-Entwicklung stehen in Form der
Model Development Tools (MDT) Technologien zur Verfügung, die beispielsweise
den Umgang mit UML2-, BPNM-, XSD- und anderen Modellen erleichtern. Darüber
hinaus enthalten die MDT die Object Constraint Language (OCL), welche häufig als
Ausdruckssprache für Abfragen und Bedingungen innerhalb der anderen Technolo-
gien des EMP verwendet wird.
Model Transformation
Zur Modelltransformation, also Modell-zu-Modell (M2M) und Modell-zu-Text (M2T)
stehen ebenfalls EMP-Technologien zur Verfügung.
Technology and Research
Das Eclipse-Projekt bietet häufig Raum für Forschungsprojekte und innovative Pro-
jektideen. Besonders im Bereich des EMP finden sich zahlreiche akademische Pro-
jektbeiträge, Proof-of-Concept – Implementierungen und sonstige Prototypen. Diese
werden dem Anwendungsbereich Technology and Research zugeordnet.
36
(Steinberg, et al., 2008 S. 22)

13
Amalgam / Modeling Amalgamation Project
Der Name des Amalgam-Bereichs des EMP leitet sich von dem englischen Begriff
amalgamation = Vereinigung, Vermischung ab. Die Technologien des Modeling
Amalgamation Projects tragen zu einer einheitlichen Endnutzer-Erfahrung bei der
Verwendung von Technologien aus dem breit aufgestellten Eclipse Modeling Project
bei. So wurde ab Eclipse 2.6 ein Auswahldialogfeld implementiert, welches die vor-
her relativ komplexe Installation von Modellierungstechnologien stark vereinfacht
und somit auch seltener verwendete Technologien leichter verfügbar macht.
Abbildung 2 - Beispiel für EMP-Amalgamation37
2.3.1 Eclipse Modeling Framework (EMF)
Das Eclipse Modeling Framework (EMF)38
stellt eine Reihe von grundlegenden
Komponenten für die Modellgetriebene Entwicklung innerhalb der Eclipse-Plattform
bereit.
37
Eigene Darstellung
38
(Skrypuch, 2011)

14
Eine zentrale Rolle nimmt dabei der Unterbereich EMF (Core) ein: EMF (Core) defi-
niert das übergreifende Metamodell aller Modellierungstechnologien (Ecore), sowie
Code-Generatoren, um Java-Code auf Basis von Ecore-Modellen zu generieren39
. Der
generierte Java-Code unterteilt sich in Klassen zur Serialisierung, zur Adaptierung
für Anzeige und Bearbeitung, zum Testen, sowie in einen generischen Modell-Editor
als Basis für weitere Anpassungen.
Darüber hinaus definiert EMF (Core) Laufzeitbibliotheken für Persistenz, Ände-
rungsmeldungen und eine reflexive API zur Verarbeitung von Ecore-Modellen ohne
generierte Modellklassen.
Zuletzt existiert auch ein Framework zur Unterstützung der Implementierung von
Editoren für Ecore-Modelle. Darin enthalten sind etwa Dialogklassen zur Bearbei-
tung von Modelleigenschaften und ein Kommando-Mechanismus zur vereinfachten
Implementierung von Editoren mit „Rückgängig“-Funktionalität.
Neben EMF (Core) enthält das EMF-Projekt weitere Technologien zur Unterstützung
der Arbeit mit Ecore-Modellen:
• CDO: 3-Tier Framework zur verteilten Bereitstellung von EMF-Modellen
• Compare: Vergleichen und Zusammenführen von Ecore-Modellen
• Model Query (1/2): Spezifizierung von Abfragen auf Ecore-Modellen
• Model Transaction: Modell-Transaktionsmanagement
• Net4j: Erweiterbares Client-Server System (Nutzung durch u.A. CDO)
• SDO: EMF-basierte Implementierung von Service Data Objects (SDO)
• Teneo: Datenbank-Persistenzlösung auf Basis von Hibernate oder EclipseLink
• Validation Framework: Framework zur Zusicherung von Modell-Integrität
39
Sog.: EMF.Codegen

15
2.3.2 Ecore
Ecore ist das zentrale Metamodell des EMF. Die folgende Darstellung zeigt die wich-
tigsten Ecore-Elemente:
Abbildung 3 - Ecore-Modellelemente (Auswahl)40
Eine Modellklasse (EClass) enthält eine Reihe von strukturellen Eigenschaften (EStruc-
turalFeature). Modellklassen unterstützen Mehrfachvererbung (eSuperTypes).
Eine strukturelle Eigenschaft ist entweder ein Attribut (EAttribute) oder eine Referenz
(EReference). Attribute sind typisiert (EDataType). Eine Referenz hat den Typ einer
Modellklasse (eReferenceType). Eine Referenz kann eine „Beinhaltet“-Beziehung dar-
stellen (containment). Darüber hinaus kann eine Referenz bidirektional sein (eOpposi-
te). Die EMF-Laufzeitbibliothek sichert hierbei die bidirektionale referentielle Integri-
tät des Modells zu. Darüber hinaus kann die Multiplizität von Referenzen speziﬁziert
werden (lowerBound und upperBound). Hierüber lassen sich z.B. übliche 1:n, 1:1 und
m:n – Beziehungen realisieren.
Datenklassen, strukturelle Eigenschaften und Datentypen sind benannt (name).
40
aus (Steinberg, 2008 S. 19)

16
Eine Besonderheit an Ecore ist die Möglichkeit der Modell-Deﬁnition über verschie-
dene, erweiterbare Mechanismen, unter anderem UML, XML, XMI und annotierte
Java-Klassen.41
Generische Programmierung
Das EMF unterstützt seit der Version 2.3 auch die Modellierung unter Anwendung
generischer Typen. Dadurch stehen in Ecore die gleichen generischen Ausdrücke zur
Verfügung, wie sie auch ab der Version 1.5 der Java-Programmiersprache unterstützt
werden.42
Persistenz von Ecore-Modellen
Eine Besonderheit des EMF ist die Entkopplung des Ecore-Metamodells von einem
konkreten Serialisierungsformat.43
Durch die Auslagerung der Zuständigkeit der Se-
rialisierung auf konkrete Implementierungen von Resource und ResourceFactory wird
die Möglichkeit geschaffen, Ecore-Modelle auf sehr unterschiedliche Arten zu persis-
tieren. EMF enthält Implementierungen zur Serialisierung von Ecore-Modellen als
XMI, XML und EMOF.
Innerhalb des Eclipse-Ökosystems existieren weitere Implementierungen von EMF-
Persistenz, unter anderem Teneo44
zur Umsetzung der Persistenz von EMF-Modellen
in relationalen Datenbanken.
Referenzen, Attribute und die Rolle des ID-Flags
Die Referenz eines Ecore-Elements auf ein anderes Ecore-Element kann in einer
XML-Serialisierung auf zwei Arten gespeichert werden: Entweder über den Wert des
Attributs des referenzierten Elements, das durch die Eigenschaft id=true gekenn-
zeichnet wurde45
, oder über die Angabe der Hierarchie46
.
Die erste Variante bietet große Vorteile bei der Verarbeitung von Ecore-Modellen
durch XSL, da die Suche nach einem Element, dessen Attribut einen bestimmten
Wert aufweist, sich mit Hilfe von Xpath relativ trivial gestaltet.
41
(Steinberg, et al., 2008 S. 122-259)
42
Details zur Implementierung von generischen Typen in EMF: (Boldt, 2007)
43
Vgl. (Steinberg, et al., 2008 S. 472-535)
44
(Taal, et al., 2011)
45
z.B. wird das Element mit name=“el1“ in einem anderen als referencedElement=“el1“ referenziert
46
z.B. referencedElement=“#//Element.1 “

17
Allerdings muss in Ecore die gekennzeichnete Eigenschaft global für alle Elemente
eindeutig sein. Da dies z.B. beim Developer Garden – Modell nicht der Fall ist47
, kann
diese Form der Serialisierung nicht ohne Probleme verwendet werden und die Ver-
arbeitung des Modells aus XSL-T heraus gestaltet sich im derzeitigen Framework
relativ aufwändig.
Reflexive Ecore-API
Die reflexive Ecore-API48
bietet den Zugriff auf Ecore-Modelle ohne generierte EMF-
Klassen. Hierdurch wird die Verwendung des EMF mit Modellen ermöglicht, deren
Metamodell zur Kompilierzeit nicht zur Verfügung steht.
Ein gutes Beispiel für die Verwendung der reflexiven Ecore-API ist der im Standard-
umfang von EMF enthaltene „Sample Reflective Ecore Model Editor“, der die Bear-
beitung jeder Art49
von EMF-Modell unterstützt, solange das Modell in der EMF-
Laufzeitumgebung registriert wurde.
Allerdings ist die Verwendung von generierten EMF-Klassen gegenüber der reflexi-
ven Ecore-API deutlich leistungsfähiger.
47
Es gibt z.B. zwei Elemente namens „sendSms“ - einen Service und eine Methode
48
Vgl. (Steinberg, et al., 2008 S. 455-467)
49
D.h. auch Docbook, Xtend 2.0 und das Developer Garden Service-Modell

18
2.4 Haupttechnologien des vorhandenen Frameworks
Im Folgenden sollen die Haupttechnologien des vorhandenen Frameworks analysiert
werden. Eine besondere Detaillierung erfahren die Ursachen, die zur Ablösung der
jeweiligen Technologie geführt haben.
2.4.1 openArchitectureWare
Das openArchitectureWare-Projekt50
ist ein seit 199951
in der Entwicklung befindli-
ches Projekt, welches Technologien zur Modellgetriebenen Entwicklung bereitstellt.
Mit der Version 4.0 (Release im April 2006) wurde die Integration der openArchitec-
tureWare-Technologien in die Technologien des Eclipse Modeling Frameworks vo-
rangetrieben.
Als Ergebnis wurde im September 2009 der bis dahin zwar offene, aber nicht voll-
ständig52
unter einer EPL-Lizenz stehende Quellcode nach eclipse.org überführt, un-
ter EPL lizenziert, eine oAW-Arbeitsgruppe gebildet und die Projekttools (Forum,
Wiki, Downloads, etc.) unter eclipse.org eingerichtet.53
Durch die Lizenzierung des
Quellcodes unter der EPL können die oAW-Technologien auch in anderen Projekten
der Eclipse-Plattform verwendet werden, da die Eclipse IP-Vorgaben die EPL-Lizenz
als maßgeblich für die Beisteuerung von Quellcode erachten.54
Mittlerweile (August 2011) sind die oAW-Technologien und deren Nachfolger Be-
standteile von Projekten des Eclipse Modeling Projects. Darüber hinaus nutzen auch
andere Eclipse-Projekte die oAW-Technologien55
, sodass mittlerweile von einer voll-
ständigen Integration von oAW in das Eclipse-Ökosystem gesprochen werden kann.
oAW-Typsystem
Eine Besonderheit der openArchitectureWare-Technologien ist das gemeinsame
Typsystem.56
Innerhalb des Typsystems existieren Repräsentationen für häufige Ty-
pen objektorientierter Programmierung, unter anderem Zeichenketten, Klassen, Ob-
jekte und Listen. Da alle Technologien innerhalb oAW (Xtend, Xpand, Check und
Xtext) dieses gemeinsame Typsystem verwenden, lassen sich z.B. Xtend-
Erweiterungen innerhalb von Xpand-Codetemplates referenzieren.
50
(openArchitectureWare.org, 2009)
51
oAW-Geschichte: (Thoms, 2006)
52
(Hunter, 2009)
53
Offizieller Letter of Intent: (openArchitectureWare.org, 2009A)
54
(The Eclipse Foundation, 2011B)
55
z.B. GMF, siehe (Shatalin, et al., 2009)
56
(Efftinge, et al., 2008 S. 53-58)

19
Darüber hinaus bildet das oAW-Typsystem eine Abstraktionsschicht über verschie-
dene Metamodell-Implementierungen:
• „Built-Ins“, d.h. eingebaute oAW-Typen
• Java Meta-Modelle, d.h. Meta-Modelle auf Basis beliebiger Java-Klassen
• EMF-Metamodelle, d.h. auf Ecore basierende Meta-Modelle oder aus EMF-
annotierten Java-Klassen, bzw. XML-Schemas abgeleitete EMF-Modelle
Durch diese Abstraktion lassen sich mit vergleichsweise geringem Aufwand auch
komplexe Aufgaben realisieren, wie beispielsweise die Modelltransformation zwi-
schen verschiedenen Metamodellen oder die Verwendung beliebigem Java-Code in-
nerhalb von Code-Templates.
2.4.2 Xtend
Xtend ist eine Sprache zur Deﬁnition umfangreicher Bibliotheken und nicht-
invasiver Meta-Modell Erweiterungen auf Basis von Java-Methoden oder oAW-
Ausdrücken. Diese Bibliotheken können von allen anderen textuellen Sprachen refe-
renziert werden, die auf dem gemeinsamen Typsystem basieren.57
/**
* Funktionen, welche das Modell betreffen
*/
import service;
extension org::eclipse::xtend::util::stdlib::io;
String getPlatform() : GLOBALVAR platform;
String getServices() : GLOBALVAR services;
Boolean getMultiple(Field f) :
let property = f.metaType.allProperties.selectFirst(e|e.name == "multiple") :
property == null ? (
false
) : (
property.get(f)
)
;
// Der Typ einer Sample-Variable
String getType(SampleVariable v) :
null
;
// Hole alle Response-Typen
List[ServiceType] getResponseTypes(Service s) :
let responseTypes = s.types.select(e|s.methods.return.contains(e.name)) :
let dependendTypes = responseTypes.getDependendTypes() :
{responseTypes, dependendTypes}.ﬂatten()
;
Abbildung 4 - Xtend-Funktionen (Ausschnitt)58
57
Übersetzt aus: (Efftinge, et al., 2008 S. 66)
58
Quelle: Eigene Darstellung (com.telekom.restsdks.ext.common.Model)

20
Grundlegende Eigenschaften der Sprache
59
Xtend ist eine funktionale Programmiersprache und daher der Erfahrung nach be-
sonders für Ausdrücke und Modelltransformationen geeignet.
Xtend ermöglicht einen ﬂexiblen Aufruf von Funktionen, indem zwei verschiedene
Syntaxen unterstützt werden:
• Funktionale Syntax
Die Funktion a auf b angewendet: a(b)
• Objekt-Member Syntax
Die Funktion a auf b angewendet: b.a()
Hierbei wird das Ziel („this“) als erster Parameter der Funktion übergeben.
Typinferenz und Rekursivität
Typinferenz bedeutet, dass die Rückgabewerte von Xtend-Funktionen nicht explizit
deklariert werden müssen, sondern aus den jeweiligen Ausdrücken hergeleitet wer-
den. Dies führt zu der inhärenten Typsicherheit von Xtend-Ausdrücken und führt zu
lesbarerem Programmcode.
Zusätzlich unterstützt Xtend rekursive Funktionsaufrufe. Hierbei muss allerdings
der Rückgabetyp explizit angegeben werden.
Dynamische Bindung
Dynamische Bindung ist die Fähigkeit einer Programmiersprache, die konkrete Im-
plementierung einer Methode zur Laufzeit je nach Parametertyp auszuwählen.
In Java wird dies anhand der standardmäßig virtuellen Klassenmethoden deutlich.
Jede Java-Klasse kann geerbte Methoden überschreiben. Die virtuelle Maschine ent-
scheidet also zur Laufzeit, ob sie die Implementierung der Elternklasse ausführt oder
eine überschriebene Methode einer von dieser Klasse erbenden Instanz.
Da Xtend eine funktionale Programmiersprache ist, geschieht die dynamische Bin-
dung auf Funktionsebene. Werden mehrere Funktionen deﬁniert, so wird immer die
Funktion ausgewählt, die für die jeweiligen Parameter am passendsten ist.
59
Für Sprachreferenz siehe (Efftinge, et al., 2008 S. 66-73)

21
Folgendes Beispiel soll die dynamische Bindung von Xtend erläutern: 60
Gegeben seien die folgenden Klassen:
Person
+matrikelnummer
Student
+mitarbeiternummer
Mitarbeiter
«extends»«extends»
Abbildung 5 - Xtend dynamische Bindung: Klassenhierarchie61
Weiter sind folgende Xtend-Ausdrücke gegeben:
getIdentification(Person p) :
"Anonyme Person"
;
getIdentification(Mitarbeiter m) :
"Mitarbeiter, Nummer " + m.mitarbeiternummer
;
getIdentification(Student s) :
"Student, Matrikelnummer " + s.matrikelnummer
;
Abbildung 6 - Xtend dynamische Bindung: Xtend-Ausdrücke62
Falls unter den gegebenen Voraussetzungen nun beispielsweise eine deklarierte
Person-Liste iteriert und die Funktion getIdentification(Person) aufgerufen wird,
so würden für Mitarbeiter- und Student-Instanzen die unteren beiden Funktionen und
für Person- und andere davon erbende Klassen die erste Funktion aufgerufen
werden.
Somit verhält sich die dynamische Bindung von Xtend sehr ähnlich überschriebenen
Klassenmethoden aus anderen objektorientierten Sprachen.
60
Angelehnt und Erweitert von (Efftinge, et al., 2008 S. 78-79)
61
Eigene Darstellung
62
Eigene Darstellung

22
Caching
Xtend unterstützt das Zwischenspeichern der Rückgabewerte von Funktionen. Wenn
eine Zwischenspeicherung gewünscht ist („cached“ – Schlüsselwort vor Funktions-
deklaration), so wird bei jedem Funktionsaufruf mit identischen Funktionsparame-
tern dasselbe Ergebnis zurückgegeben.
Java-Extensions
Java-Extensions sind Xtend-Funktionen, die mit einer öffentlichen, statischen Java-
Methode verknüpft sind. Bei Aufruf der Xtend-Funktion wird die Java-Methode auf-
gerufen und das Ergebnis wiederum der aufrufenden Xtend-Funktion bereitgestellt.
Ein Typumwandlungsmechanismus sorgt hierbei für die Einhaltung der Typsicher-
heit.
Durch die Verwendung von Java-Extensions ergeben sich vielfältige Möglichkeiten
der Anwendung von Xtend über die typischen Anwendungsszenarien hinaus.
Create-Extensions (Modelltransformation)
63
Ein häuﬁges Problem der Transformation von Modellen, welches Create-Extensions
adressieren liegt in der Referenzierung von noch nicht initialisierten Modell-
Elementen.
Typischerweise läuft eine Modelltransformation in zwei Durchläufen ab:
1. Transformation der Struktur
2. Transformation der Attribute und Referenzen
Dies folgt aus dem Sachzwang, dass eine Referenz zwischen zwei Elementen erst
dann erstellt werden kann, wenn beide Elemente existieren. Wenn erst ein Element
existiert und durch die Transformation das referenzierte Element erstellt wird, wür-
den bei mehreren transformierten Elementen unterschiedliche referenzierte Elemente
erstellt werden.
Create-Extensions lösen dieses Problem und erlauben die Modelltransformation in
einem Durchlauf. Dies wird dadurch erreicht, dass ähnlich wie bei cached-
Extensions das Ergebnis einer Funktion zwischengespeichert wird und bei identi-
schen Parametern dasselbe Objekt zurückgegeben wird. Dies verhindert die mehrfa-
che Erstellung von Modellelementen. Darüber hinaus stellt Xtend sicher, dass keine
Modellinitialisierung durchgeführt wird, bevor nicht alle abhängigen Objekte instan-
ziiert werden.
63
Für ein ausführliches Beispiel siehe (Efftinge, et al., 2008 S. 70-72)

23
Durch Create-Extensions können auch komplexe Transformationen, wie die
cleanModel-Transformation64
in einem Durchlauf erfolgen.
Einbindung von Xtend in Java
Java-Code kann Xtend-Code nicht direkt aufrufen, sondern nur über ein Fassaden-
Objekt (XtendFacade) ansprechen. Dieses Objekt bietet Funktionen, um Xtend-Code
auszuführen, sowie die Xtend-Laufzeitumgebung zu konfigurieren (u. A. die Angabe
von Metamodell-Implementierungen). Hinter dem Fassaden-Objekt steht der Xtend-
Interpreter, welcher den Xtend Code zur Laufzeit interpretiert und ausführt.
Gründe zur Ablösung der Technologie
Im Verlauf des Jahres 2010 fokussierte sich die Arbeit des Haupt-Entwicklungsteams
der itemis AG immer mehr auf das Framework Xtext, welches ursprünglich zur Ver-
einfachung der Entwicklung von Eclipse IDE-Unterstützung entstand.65
Im September 2010 wurde Xbase angekündigt66
, eine sog. „teilweise Programmier-
sprache“67
, welche in Xtext-Sprachen inkludiert werden kann. Schlussendlich wurde
im Dezember 2010 Xtend 2, die Xtend-Nachfolgetechnologie, vorgestellt.
Das neue Framework setzt auf Xtend 2, da vieles darauf hindeutet, dass Xtend und
Xpand keine Weiterentwicklung mehr erfahren und damit auch nicht als Basis für
das neue Framework geeignet sind.
2.4.3 Xpand
Xpand ist eine Sprache zur Definition von Templates zur Verwendung in Modell-zu-
Text – Transformationen.68
Die Verwendung des oAW-Typsystems durch Xpand er-
möglicht die Verwendung von Xtend-Erweiterungen und -Ausdrücken innerhalb
von Code-Templates.
Darüber hinaus definiert Xpand eigene Sprachkonstrukte zur Verbesserung der Les-
barkeit von Templates, beispielsweise IF- oder FOREACH-Anweisungen. Außerdem
ermöglicht Xpand eine Art aspektorientierter M2T-Transformation: Es können Point
Cuts deklariert werden, die Ausführungspunkte im Code markieren, um die per
AROUND – Anweisung Code generiert werden kann.
64
Siehe 3.3 (Seite 35)
65
(u.A. für Xpand, Xtend und Check): siehe (Efftinge, 2010A)
66
(Efftinge, 2010)
67
Engl: partial programming language
68
(Efftinge, et al., 2010)

24
In Xpand definierte Code-Templates nutzen dieselbe Semantik, wie Xtend-
Funktionen, d.h. ein Xpand Code-Template für ein Element des Typs A entspricht
von der Semantik her einer Xtend-Methode, deren erster Parameter vom Typ A ist.
Dadurch ist Xpand in der Lage, das für ein spezifisches Objekt zu generierende
Code-Template auf Basis dynamischer Bindung auszuwählen.
Einbindung von Xpand in Java
Für Xpand gelten dieselben Aussagen, wie für Xtend. Auch für Xpand existiert ein
Fassaden-Objekt (XpandFacade), welches den Zugriff auf Xpand auf dieselbe Art
ermöglicht, wie auf Xtend-Code.
Die Gründe zur Ablösung der Technologie sind dieselben, wie für Xtend. Die Xtend-
Nachfolgetechnologie Xtend 2.0 vereinigt die Funktionalität von Xtend und Xpand.
2.4.4 Modeling Workflow Engine (MWE)
Die Modeling Workflow Engine ist eine per deklarativer XML-Konfiguration gesteu-
erte Workflow-Sprache. Ein MWE-Workflow besteht aus mehreren Komponenten,
die der Reihe nach ausgeführt werden. Die XML-Syntax definiert die Referenzierung,
Instanziierung und Konfiguration der Komponenten.
Alle oAW-Technologien stellen Komponenten zur Verwendung in der MWE bereit,
beispielsweise, um Modelle einzulesen, Xpand-Transformationen auszuführen oder
Xtend-Ausdrücke anzuwenden.
MWE-Workflows besitzen ein Slot-Konzept: Slots können beliebige Objekte beinhal-
ten und dienen so der Kommunikation von Komponenten untereinander. So liest
beispielsweise eine Reader-Komponente ein Ecore-Modell ein und stellt dieses über
einen Slot A bereit, sodass eine im Anschluss konfigurierte Xpand-Komponente an-
gewiesen werden kann, auf den Inhalt des Slots A eine M2T-Transformation auszu-
führen.
Die Implementierung neuer Komponenten wird durch vordefinierte, abstrakte Ba-
sisklassen, beispielsweise AbstractWorkflowComponent stark vereinfacht. Diese
Komponenten stellen unter anderem Funktionen bereit, mit denen der Slot-
Mechanismus vergleichsweise leicht verwendet werden kann.
Es existiert mit der MWE2 eine Nachfolgetechnologie, die auf denselben Prinzipien
und Komponenten wie die MWE basiert, jedoch aufgrund einer Xtext basierenden
Syntax gegenüber der XML-Syntax der MWE einfacher in der Handhabung ist.

25
2.5 Einzusetzende Technologien in GenerationREST
2.5.1 Xtend 2
Xtend 2 ist die Weiterentwicklung und Zusammenführung der beiden oAW-
Technologien Xtend und Xpand auf Basis von Xtext.
Die von Xtend 2 adressierten Problemfelder von Xpand und Xtend sind:69
• Ausführungsgeschwindigkeit
Aufgrund der Interpretierung von Xpand und Xtend zur Laufzeit ist die Aus-
führungsgeschwindigkeit dieser Sprachen, nicht zuletzt durch den wenig op-
timierten Interpreter, relativ eingeschränkt.
• Unterstützung durch die IDE
Die IDE-Unterstützung wurde manuell implementiert - der Entwicklungslei-
ter weist ihr die Attribute „not well tested“ und „a bit buggy“ zu.
Während der Arbeit am aktuellen Framework konnte ich dies ausdrücklich
nachvollziehen. So wurde unter anderem sehr häuﬁg korrekter Code als Feh-
ler in der IDE gekennzeichnet und es konnte in bestimmten Kontexten die Au-
to-Vervollständigen Funktion nicht aktiviert werden.
• Konzeptionelle Schwächen
Der Entwicklungsleiter beurteilt in der Retrospektive viele Entscheidungen
negativ. Dies betrifft unter anderem die Verwendung eingebauter Funktionen
höherer Ordnung anstatt Funktionsabschlüssen (Closures) sowie eingebaute
Collection-Klassen anstatt generischer Programmierung.
Xtend 2 - Konzept
Die grundlegende Idee an Xtend 2.0 ist die Deﬁnition eines Großteils der Sprache auf
Basis von Xtext. Dieser Teil der Xtend-Sprache, Xbase, ist anpassbar und lässt sich in
andere Xtext-Sprachen integrieren. Die Verwendung des Xtext - Frameworks ermög-
licht die automatische Bereitstellung vieler Funktionen, die in Xtend manuell imple-
mentiert wurden. So werden beispielsweise der Parser, Lexer, und die Mechanismen
zur Unterstützung von Auto-Vervollständigung durch Xtext automatisch bereitge-
stellt.
Darüber hinaus wird Xtend nicht mehr interpretiert, sondern durch Code-Templates
direkt in Java-Code umgewandelt und ausgeführt. Dies verbessert vor allem die In-
tegration von Xtend in andere Java-Programme und Bibliotheken, sowie die Fehler-
suche.
69
(Efftinge, 2010A)

26
Insgesamt lässt sich feststellen, dass Xtend 2 nahezu alle Funktionen von Xtend und
Xpand bietet (wenn auch mit veränderter Syntax) und darüber hinaus weitere Funk-
tionen einführt.
Eigenschaften der Sprache
Die Sprache Xtend 2 teilt viele Eigenschaften mit dem Vorgänger Xtend. Weiterhin
gilt: Xtend 2 ist eine statisch typisierte, funktionale Programmiersprache, in der jedes
Sprachkonstrukt einen Ausdruck darstellt - es gibt keine Anweisungen. Der ﬂexible
Aufruf von Funktionen über eine wahlweise funktionale oder Objekt-Member Syn-
tax wird wie die Typinferenz weiterhin unterstützt.
Darüber hinaus unterstützt Xtend 2 einen vereinfachten Aufruf von Java Gettern und
Settern70
: Das Java-Konstrukt o.getName() kann in Xtend 2 als o.name, das Java-
Konstrukt o.setName("ABC") kann in Xtend 2 als o.name = "ABC" notiert werden.
Ebenso kann eine boolesche Java-Funktion, z.B. o.isNamed() als o.named angespro-
chen werden.
Dynamische Bindung
Xtend 2 unterstützt wie Xtend dynamische Bindung. Allerdings müssen in Xtend 2
dynamisch gebundene Methoden mit einem dispatch-Schlüsselwort gekennzeich-
net werden.
Diese fakultative dynamische Bindung verbessert die Ausführungsgeschwindigkeit
von Xtend 2 – Code, da nur bei dispatch-Methoden aufwändige Typprüfungen
vorgenommen werden müssen.
Caching und Create Extensions
Xtend 2 unterstützt Create Extensions bis auf syntaktische Änderungen wie Xtend.
Caching wird in Xtend 2 über Create Extensions unterstützt, da beide semantisch
gleichwertig sind. Daher entfällt das cached-Schlüsselwort.
Integration von Xtend 2 und Java
Java-Extensions erübrigen sich in Xtend 2, da Xtend 2 – Code direkt nach Java über-
führt wird und es keine eigenen Xtend 2 – Klassen mehr gibt. Alle Xtend 2 – Objekte
sind Java-Objekte und erben daher von java.lang.Object. Daher kann auch jedes
Java-Objekt von Xtend 2 – Code instanziiert, referenziert und verwendet werden.
Wegfall der Metamodell-Implementierungen und des oAW-Typsystems
Eine Änderung von Xtend 2 gegenüber Xtend ist der Wegfall des oAW-Typsystems
und damit der Metamodell-Implementierungen (u. A. für EMF-Modelle).
70
Siehe JavaBeans-Speziﬁkation: (Sun Microsystems, Inc., 1997)

27
Die Konstrukte zur dynamischen Ansprache von Ecore-Modellen sind in Xtend 2
gleich denen, wie sie auch in einem Java-Programm verwendet werden und damit
komplexer, als in Xtend.
So konnte in Xtend ein Ecore-Modellelement über ein einfaches new-Konstrukt in-
stanziiert werden71
. Das oAW-Typsystem von Xtend sorgt mit der EMF Metamodell-
Implementierung für die automatische Umwandlung des new-Konstrukts in einen
Aufruf der zuständigen create-Methode eines EMF-Factory Singletons72
.
Der Wegfall des Typsystems als Zwischen-Abstraktionsschicht führt allerdings
gleichermaßen zu einer Vereinfachung der Gesamtlösung. Meine Erfahrung mit der
Fehlersuche in Xtend – gerade in Bezug auf die Automatismen der einzelnen Meta-
modell-Implementierungen – unterstützt die Entscheidung, zur Vereinfachung ein-
zig das Typsystem der JVM zu verwenden.
Dependency Injection
Alle neuen Technologien, Xtext 2.0, Xtend 2 und MWE2, setzen in ihrer Implementie-
rung auf das Dependency Injection – Entwurfsmuster und das DI-Framework
Google Guice73
. Google Guice unterstützt neben der umfangreichen Konfiguration
des DI-Kontextes ebenfalls die aspektorientierte Änderung des Verhaltens von inji-
zierten Objekten.
Extension-Mechanismus
Eine Xtend 2-Klasse kann andere Xtend 2-Klassen als sog. Extensions importieren.
Durch einen Import stehen alle Funktionen der importierten Xtend 2-Klassen in der
importierenden Xtend 2-Klasse zur Verfügung. Dabei erfolgt die Zuweisung der
konkreten Implementierung der Extension-Klasse durch Dependency Injection.
Dadurch lässt sich das Verhalten von Extensions sehr flexibel ändern.
Rich Strings
Rich Strings entsprechen der Integration von Xpand in Xtend 2. Die Hauptanwen-
dung von Rich Strings ist die Implementierung von Modell-zu-Text Transformatio-
nen. Dabei ist die Syntax von Xpand in Xtend 2 Rich Strings nahezu identisch.
Im Gegensatz zu Xpand sind Rich Strings allerdings Ausdrücke und daher auch in-
nerhalb von Methoden flexibel verwendbar.
71
z. B.: let p = new Person
72
z. B.: Person p = ModelFactory.eINSTANCE.createPerson()
73
(Google Inc., 2011B)

28
Die Unterstützung der Code-Generierung durch Xtend 2 Rich Strings enthält gegen-
über Xpand einige Verbesserungen. Vor allem die automatische Leerraum-
Behandlung ist in Xtend 2 ausgereifter, als in Xpand. Leerräume vor Blöcken werden
in Xtend 2 nicht mehr automatisch in Ausgabedateien übernommen. Dadurch ergibt
sich eine deutliche Besserung in der Lesbarkeit von Code-Templates, sowie weniger
Aufwand für die Template-Erstellung.
Abbildung 7 - Automatische Leerraum-Behandlung in Xtend Rich Strings74
Darüber hinaus hebt der Xtend 2 Editor zusammengehörige Klammern innerhalb
von Rich Strings automatisch hervor.
null-Behandlung
Xtend 2.0 unterstützt die automatische Behandlung von leeren Referenzen in der
Form, dass anstatt einer Überprüfung if(a != null) a.do() vereinfachend
a?.do() notiert werden kann. Hierbei ist der Gesamtausdruck automatisch null,
falls a == null ist.
Zusammenfassung
Die Arbeit mit Xtend 2 zeigt viele Verbesserungen gegenüber Xtend und Xpand. Be-
sonders die verbesserte IDE-Unterstützung, das bessere Laufzeitverhalten und das
neue Feature Rich Strings hat die modellgetriebene Entwicklung des neuen Frame-
works produktiv unterstützt. Das Konzept der Überführung von Xtend-Code nach
Java ermöglichte zudem erstmals die Analyse von Fehlverhalten in Xtend 2 - Code.
74
Eigene Darstellung

29
Allerdings ist die Xtend Code-Generierung bei der Behandlung von generischen
Klassen, wie die des Service-Modells des neuen Frameworks, fehleranfällig. Xtend
setzt oft fehlerhaft die beiden Klasseneinschränkungen <?> und <? extends Ob-
ject> gleich. Dadurch müssen einige formal gültige Xtend 2-Konstrukte umformu-
liert werden, um gültigen Java-Code zu generieren.
Dieses Fehlverhalten könnte allerdings auch im Type Erasure von generischen Klas-
sen in Java und damit in der Architektur und nicht in der Technologie begründet
sein; eine genaue Fehlerursachenanalyse steht hierbei noch aus.
2.5.2 Xtext
Xtext ist ein Framework zur Definition textueller domänenspezifischer Sprachen auf
Basis von Technologien des EMP. Die Definition dieser Sprachen erfolgt in Form der
Xtext-DSL75
, welche mithilfe EBNF ähnlicher Ausdrücke die Grammatik einer Spra-
che definieren lässt. Die Laufzeit-Instanz des durch die Sprache ausgedrückten Mo-
dells verwendet Ecore und das EMF als Meta-Metamodell - Technologien. Das Meta-
Modell der Sprache kann entweder aus der Grammatik generiert, oder über ein vor-
handenes Ecore-Metamodell definiert76
werden.
Auf Basis der Grammatik wird ein Parser für die jeweilige Sprache generiert, der so-
wohl in der Lage ist, grammatikkonforme Textdateien in eine Modell-Instanz zu
transformieren, als auch eine Modell-Instanz wieder zurück in eine grammatikkon-
forme Textdatei zu transformieren.
Der Parser ist Crosslinking-fähig77
. Das bedeutet, dass Referenzen zwischen Mo-
dellelementen in Xtext-Sprachen modelliert und in einer textuellen Form ausge-
drückt werden können. Für die unterschiedlichen Crosslinking-Konzepte stehen ver-
schiedene Implementierungen zur Verfügung, deren Anpassung möglich und vorge-
sehen ist. Hierunter fallen die einfache Verlinkung über name-Attribute, die Definiti-
on verschiedener, getrennter Namensräume, sowie die Spezifizierung von sprach-
spezifischen Gültigkeitsbereichen.78
Der Hauptnutzen von Xtext besteht darin, dass das Framework auf Basis dieser
Grammatik-Definition Komponenten zur Integration der DSL in die Eclipse-IDE au-
tomatisiert generieren kann, unter anderem Eclipse Editor-Komponenten.
75
Die Xtext DSL zur Definition der Grammatik ist in Xtext definiert: (itemis AG, 2011)
76
Zur Verwendung vorhandener Ecore-Metamodelle: (Efftinge, 2009)
77
(Behrens, 2011B)
78
Dokumentation der Implementierung verschiedener Crosslinking-Konzepte: (Behrens, 2011A)

30
/*
* Data Types
*/
RestString returns rest::RestDataTypeString:
name=ID 'String' ('(charset:' charset=STRING ')')?
;
RestNumber returns rest::RestDataTypeNumber:
name=ID 'Numeric' ('('(signed?="signed")? (length=MetaNumberPrecision)?')')?
;
RestBoolean returns rest::RestDataTypeBoolean:
name=ID 'Boolean' ('(' trueValue=STRING ',' falseValue=STRING ')')?
;
Abbildung 8 - Xtext-DSL (Ausschnitt)79
Die generierten Xtext-Editoren ermöglichen eine funktionsreiche80
und komfortable
Verwendung von Xtext-Sprachen im Rahmen der Eclipse-IDE. Bereitgestellte Funkti-
onen sind beispielsweise Syntax-Hervorhebung, Auto-Vervollständigung, automati-
sche Validierung, Zusammenfaltung von Code-Blöcken, Aufﬁndung von Referenzen
sowie automatische Code-Formatierung.
Da die Laufzeit-Instanz einer Xtext-Sprachdatei als Ecore-Modell vorliegt, kann auf
diese auch über reﬂexive und generierte Ecore Modelleditoren zugegriffen werden:
Abbildung 9 - Multiple Zugriffsmöglichkeiten auf Xtext-Dateien81
79
Eigene Darstellung (Datei: org.generationrest.dsl.ServiceDsl.xtext)
80
Liste aller Funktionen generierter Xtext Editoren: (Behrens, 2011)
81
Eigene Darstellung

31
Gründe für die Verwendung von Xtext im neuen Framework
Textuelle DSLs ermöglichen kompakte, ausdrucksstarke und zugängliche Modellbe-
schreibungen. Die Funktionen des generierten Xtext-Editors sind denen des generier-
ten strukturierten Ecore-Editors weit überlegen. Daher ist zu erwarten, dass die Spe-
zifizierung von REST-Schnittstellen mithilfe einer textuellen DSL einem Anwender
des zu entwickelnden Frameworks leichter fallen wird, als mithilfe des strukturierten
Ecore-Editors.
Darüber hinaus ist der Implementierungsaufwand für Benutzbarkeit verbessernde
Änderungen an generierten EMF-Editoren meiner Erfahrung nach höher, als bei
Xtext. Zwar sehen beide Technologien Anpassungen als üblichen Arbeitsschritt der
Bereitstellung vor, dies wird jedoch von Xtext mit einer größeren Anzahl an vorhan-
denen Framework-Artefakten unterstützt, als dies bei EMF der Fall ist.
Zusammenfassung
Xtext ist ein sehr umfangreiches, flexibles und leistungsstarkes Framework zur Defi-
nition textueller domänenspezifischer Sprachen. Die neueste Aktualisierung (Version
2.0 vom 22. Juni 2011) bringt zahlreiche Verbesserungen und Änderungen82
mit sich,
die zu einer signifikanten Steigerung der Benutzbarkeit des Frameworks führen.
Allerdings zeichnet sich das Xtext-Framework durch eine hohe Komplexität aus und
erfordert, gerade bei der Einarbeitung, ein hohes Abstraktionsvermögen und gute
Kenntnisse der Eclipse-Technologien, besonders des Eclipse Modeling Frameworks.
Die Quantität und Qualität der Dokumentation hat sich mit der neuesten Aktualisie-
rung ebenso verbessert und unter Anderem lässt die Aktivität in den Xtext Eclipse
Community Foren83
auf eine relativ große Anwenderbasis schließen.
Ein negativer Aspekt der Arbeit mit Xtext ist allerdings die sehr hohe Speicheranfor-
derung des Xtext Builders, welche besonders bei umfangreichen Projekten, wie dem
GenerationREST-Framework unter Umständen zu einem Speicherverbrauch der Java
Virtual Machine von über 2 GByte führt. Der als Verbesserung von Xtext 2.0 gegen-
über Xtext (1.x) genannte „verringerte Speicherverbrauch“84
konnte während der Re-
alisierungstätigkeiten nicht festgestellt werden.
2.5.3 Modeling Workflow Engine 2 (MWE2)
Die Modeling Workflow Engine 2 (MWE2) ist eine Neuimplementierung der Mode-
ling Workflow Engine auf Basis von Xtext. Dabei ist die MWE2 abwärtskompatibel
zur MWE, d.h. alle MWE-Komponenten sind ohne Anpassungen in einem MWE2-
Workflow lauffähig.
82
Siehe auch: (Efftinge, et al., 2011) und (Efftinge, 2010B)
83
(The Eclipse Foundation, 2011A)
84
(Zarnekow, et al., 2011)

32
Die Verwendung von Xtext verbessert die Zugänglichkeit der Workflow-Definition
durch eine kompakte DSL und einen generierten Xtext-Editor mit Auto-
Vervollständigung, Syntax-Hervorhebung und weiteren Funktionen.
MWE2 ermöglicht die Flexibilisierung eines Workflows über optionale und fakulta-
tive Parameter, sowie die Injektion von Komponenten per Google Guice.
2.5.4 Docbook XML
Docbook85
ist ein von der OASIS gepflegter, offener Standard für ein Schema ver-
schiedener Arten von Dokumenten – vor allem technischer Dokumentation. Die erste
Version (1.0) erschien bereits 1992, damals als SGML-DTD.86
Mittlerweile ist die
normative DTD RELAX NG, es existieren auch andere Schemas, unter anderem ein
XSD-Schema.
Docbook ist durch die lange Entwicklungsphase mittlerweile sehr ausgereift und
wird von einer Vielzahl an Projekten – besonders im Open Source-Bereich87
– als
Schema für Dokumentation eingesetzt.
In Kombination mit Docbook wird sehr häufig auf die DocBook XSL Stylesheets des
DocBook Projects88
zurückgegriffen. Diese ermöglichen die Transformation von Doc-
book-Dokumenten in eine Vielzahl an Ausgabeformaten, unter anderem (X)HTML,
XSL-FO (zur PDF-Transformation) und ePUB.
2.6 Developer Garden
Der Developer Garden89
ist das Entwicklerportal der Deutschen Telekom AG.
Durch den Developer Garden werden zwei Ansätze verfolgt: Zum einen werden die
Aktivitäten der Deutschen Telekom in den Bereichen Open Development und Open
Innovation gebündelt dargestellt und zum anderen stellt das Developer Garden Pro-
jekt eigene SOAP- und REST-Schnittstellen (sog. Network APIs) zum Zugriff auf
Kerndienste der Deutschen Telekom bereit, darunter mehrere Telefonie-APIs, sowie
SMS und MMS-APIs.
Darüber hinaus stellt der Developer Garden auch Kollaborations-Möglichkeiten zur
Verfügung, unter anderem ein mehrsprachiges Foren-System.
85
(Docbook Committee, 2007)
86
(O'Reilly & Associates, Inc., 1992)
87
u.A. GNOME, KDE, Eclipse, PHP, Zend
88
(The DocBook Project, 2005)
89
(Deutsche Telekom AG, 2011C)

33
REST Network APIs
Unterstützte Datenformate der REST-Schnittstelle sind XML, JSON und Text. Vor der
Nutzung der Network APIs ist eine Registrierung im Developer Center90
der Deut-
schen Telekom AG notwendig - die Abrechnung der Dienste erfolgt über einen Pre-
Paid-Mechanismus. Zur Unterstützung von Entwicklung und Evaluierung der Ser-
vices stehen sowohl eine Sandbox-, als auch eine Mock-Umgebung zur Verfügung.
Die Authentiﬁzierung gegenüber der REST-Schnittstelle erfolgt über einen Token-
Mechanismus: Vom Telekom Secure Token Server wird unter Angabe der Developer
Center – Zugangsdaten ein Token angefordert, der in den HTTP-Header des Aufrufs
einer REST-Methode eingebunden werden muss.91
Die REST-Schnittstelle wurde nach der SOAP-Schnittstelle konzipiert und implemen-
tiert und wendet den REST-Architekturstil überwiegend an.
Abweichungen gibt es beispielsweise darin, dass zur Identiﬁkation von erstellten
Ressourcen (z.B. Telefongesprächen) IDs anstatt URLs zurückgegeben werden.
Außerdem sind nicht alle Ressourcen per URL erreichbar, beispielsweise würde man
die Teilnehmer einer Telefonkonferenz unter
/conference/{conferenceID}/participants
und die Zeitinformationen unter
/conference/{conferenceID}/schedule
erwarten, jedoch sind nur alle Informationen komplett unter
/conference/{conferenceID}
erreichbar.
90
(Deutsche Telekom AG, 2011A)
91
Details siehe: (Slawik, 2011)

Analyse der vorhandenen Lösung
34
3 Analyse der vorhandenen Lösung
Zur Generierung der Developer Garden SDKs wurde von mir während der Beschäf-
tigung bei der Deutschen Telekom AG ein Framework konzipiert und implementiert,
welches in der derzeitigen Version Aufgabenstellungen für den Anwendungsbereich
der Developer Garden APIs adressiert.
In diesem Kapitel werden die vorhandene Telekom-Lösung und ihre Entwicklung
detailliert analysiert, um darauf aufbauend einen neuen, allgemeinen Lösungsansatz
für die Aufgabenstellungen des Frameworks zu erarbeiten.
Aufgabenstellung
Eine Herausforderung im Bereich Serviceorientierter Architekturen besteht in der
Befähigung von Entwicklern, bereitgestellte Services optimal zu nutzen. Denn die
Aufteilung von Informationssystemen in abgeschlossene Dienste mit differenzierten
Zuständigkeiten erhöht die Distanz zwischen den mit der Entwicklung von Informa-
tionssystemen in dieser Anwendungsdomäne betrauten Personen und verschlechtert
damit die Verfügbarkeit unmittelbarer Informationsquellen.
Im Bereich Cloud Computing, also der Bereitstellung von abgeschlossenen Diensten
für einen sehr großen Personenkreis, ist diese Distanz noch größer, da die Nutzer der
Dienste selten in direktem Kontakt mit der bereitstellenden Firma stehen.
In diesem Kontext kommen drei Aspekten besondere Geltung zu:
Formale Beschreibung der API
Eine formale Beschreibung der API erleichtert die Ansprache von Diensten erheblich.
Sollten sowohl Daten, als auch Operationen formal beschrieben sein (wie bspw.
durch WSDL/XSD), ermöglicht dies die komplette Generierung von Schnittstellen-
Adaptern in der jeweiligen Zielsprache, bzw. im verwendeten Framework.
Sollten entweder nur das Datenschema oder die Operationen beschrieben sein, hilft
die formale Beschreibung zumindest jede indifferente sprachliche Beschreibung zu
präzisieren.
Bereitstellung von SDKs
Die Bereitstellung von SDKs verringert den Integrationsaufwand von Diensten in
bestehende Applikationen erheblich. Dies wird besonders bei REST SDKs deutlich,
bei denen sich der manuellen Implementierungsaufwand von HTTP-
Aufrufmethoden, Datenklassen und weiteren typischen Bestandteilen von SDKs er-
übrigt.

35
Obwohl zu einem Service eine formale Schnittstellendefinition vorliegt, ist der Auf-
wand zur Durchführung der Generierung von Schnittstellenadaptern, beispielsweise
bei komplexen SOAP-Frameworks, relativ hoch. Daher können auch bereitgestellte
SOAP-Frameworks Implementierungsaufwand verringern.
Letzten Endes besteht der Nutzen eines SDKs nicht nur in der vereinfachten Hand-
habung von Daten und Operationen, sondern auch in einer geeigneten Abstraktion
des anzusprechenden Services. Ist diese Abstraktion gelungen, so verringert sich der
Integrationsaufwand der API in vorhandene und neue Entwicklungen zusätzlich.
Bereitstellung von Dokumentation
Formale Beschreibungen und SDKs liefern nur die Syntax der Operationen und Da-
tenstrukturen. Die Semantik wird durch die Dokumentation festgelegt. Dokumenta-
tion ist in diesem Kontext Quellcode-Kommentare, konzeptionelle Dokumentation
(z.B. „Überblick“, „Wie anfangen?“), Beispielcode und Tutorials.
3.1 Iteration 1: SOAP-Benutzerdokumentation
Vor der Implementierung des Frameworks zur Generierung der Dokumentation be-
standen die Quellen der Benutzerdokumentation aus lediglich zwei verhältnismäßig
großen92
Docbook XML-Dateien, welche jeweils die deutsche und englische Version
der Benutzerdokumentation enthielten. Diese Dateien wurden von unterschiedlichen
Personen mithilfe eines grafischen Docbook-Editors verfasst. Ein ANT-Workflow
und angepasste Docbook XSL-Stylesheets transformierten die Docbook XML-Dateien
in die Ausgabeformate HTML single, HTML chunked und PDF.
Meine ursprüngliche Arbeitsaufgabe war es, die Probleme dieses Vorgehens zu lö-
sen:
P1 Unterschiede zwischen deutscher und englischer Dokumentation
Durch die Trennung der Sprachversionen war zu keinem Zeitpunkt gesichert,
dass sich deutsche und englische Dokumentation in Ihrer Struktur gleichen.
Dieses Problem zeigte sich besonders im Kapitel 4, der detaillierten Schnitt-
stellenbeschreibung der SOAP-API.
P2 Anpassungen am Layout aufwändig
Obwohl das Layout für die Beschreibung von Schnittstellendetails, wie bei-
spielsweise Parametern oder Rückgabewerten immer dieselbe Struktur hat,
war es aufgrund des manuellen Pflegeverfahrens nicht möglich, diese an einer
zentralen Stelle anzupassen.
92
Ca. 500 kByte

36
P3 Vielgestaltiges Layout
Durch die manuelle Pﬂege von unterschiedlichen Sprachversionen durch un-
terschiedliche Mitarbeiter konnte nicht sichergestellt werden, dass das Layout
bestimmter verwandter Bereiche über die gesamte Dokumentation gleich
bleibt.
P4 Monolithische Struktur
Die Benutzerdokumentation enthält unterschiedliche Kapitel zu unterschied-
lichen Aspekten der Developer Garden Services, diese sind jedoch alle in einer
Datei zusammengefasst. Dies mindert die Übersicht bei der Bearbeitung des
Dokuments durch einen Mitarbeiter.
Die erarbeiteten Lösungsansätze für die genannten Probleme werden in den folgen-
den Abschnitten dargestellt:
Einführung von modellgetriebenen Methoden und Technologien
Die Vorteile von modellgetriebenen Methoden und Technologien konnten von mir
schon in der Vergangenheit im Kontext der Arbeit im Developer Garden - Projekt
nachvollzogen werden.93
Daher war es naheliegend, diese auch im Problembereich
der Benutzerdokumentation anzuwenden.
Definition abstrakter und konkreter Syntax für Developer Garden APIs
Abbildung 10 - Abstrakte und konkrete Syntax der ersten Iteration94
93
(Slawik, 2008)
94
Eigene Darstellung

37
Erster Schritt der Anwendung von modellgetriebenen Methoden und Technologien
war die Definition von abstrakter und konkreter Syntax für die Developer Garden
APIs. Es wurde eine abstrakte Ecore-Syntax konzipiert und eine Dynamische XMI –
Instanz als konkrete Syntax der verfügbaren Developer Garden APIs definiert.
Trennung von Struktur und Inhalt der Benutzerdokumentation
Durch die Verfügbarkeit einer formalen Beschreibung der Developer Garden APIs
konnte die Struktur vom Inhalt der Benutzerdokumentation getrennt werden.
Der Inhalt des Kapitels 4 (der Schnittstellenbeschreibung) fand sich im neu geschaf-
fenen Content-Repository wieder, einer Docbook XML-Datei, die eine einfache Pflege
der deutschen und englischen Beschreibungen der Modellelemente zuließ, da sie mit
denselben Werkzeugen bearbeitet werden konnte, wie die Benutzerdokumentation.
Darüber hinaus war es durch die Beibehaltung des Docbook XML-Schemas relativ
einfach, das Content-Repository per XSL-Stylesheet zu verarbeiten.
Abbildung 11 - Content-Repository (Ausschnitt)95
Dadurch, dass beide Beschreibungen (deutsch & englisch) sich auf ein und dasselbe
Modellelement beziehen (über die Referenzierung der name-Attribute) konnte das
Problem P1 gelöst werden.
Darüber hinaus wurde im Content-Repository die Möglichkeit geschaffen, sich wie-
derholende Parameterbeschreibungen anzulegen, beispielsweise die Beschreibung
des account-Parameters, welcher bei allen Methoden die gleiche Bedeutung hat.
Hierdurch konnten überflüssige Redundanzen in der Benutzerdokumentation abge-
baut werden.
Implementierung einer Modell-zu-Text – Transformation
Die Probleme P2 und P3 konnten durch eine Modell-zu-Text (M2T) – Transformation
gelöst werden. In der ersten Iteration war diese M2T-Transformation XSLT-basiert,
sodass die Verarbeitung von Docbook damit relativ leicht zu implementieren war.
95
Eigene Darstellung

38
Die Transformation enthielt Layout-Vorlagen, die ein einheitliches Aussehen der Be-
nutzerdokumentation möglich machten. Darüber hinaus konnten durch eine Anpas-
sung dieser Layout-Vorlage grundsätzliche Änderungen am Aussehen der Benut-
zerdokumentation durchgeführt werden.
Aufteilung der Dokumentation in einzelne Dateien
Die Dokumentation wurde in einzelne Dateien aufgeteilt, um Problem P4 zu lösen.
Das Hauptkapitel 4, die Schnittstellenbeschreibung wird automatisch generiert. Die
sonstigen Kapitel werden weiterhin manuell gepﬂegt, da diese lediglich ergänzende
Informationen enthalten. Vor der Transformation in die Ausgabeformate durch die
Docbook XSL-Stylesheets werden die manuell gepﬂegten und automatisch generier-
ten Artefakte in ein Dokument zusammengeführt.
Die folgende Abbildung verdeutlicht nochmals das Grundkonzept der ersten Iterati-
on:
Abbildung 12 - Grundkonzept der ersten Iteration96
96
Eigene Darstellung
Metamodell
service.ecore
Modell
developergarden.xmi
Abstrakte Syntax
Content-Repository
content.xml
M2T-Transformation
generateChapterFromModel.xsl
Struktur Inhalt
Layout
Kapitel 4 (Service-Beschreibung)
ch04.de.xml / ch04.en.xml
Andere Kapitel
ch0x.de.xml / ch0x.en.xml
Docbook XSL
Stylesheets
HTML
single
HTML
chunked
PDF

39
Das Metamodell besitzt nach der ersten Iteration die folgende Struktur:
Abbildung 13 - Metamodell nach der ersten Iteration97
(Januar 2010)
Provider ist das Wurzelelement des Service-Metamodells. Ein Provider bietet Dienste
(Service) an. Jeder Dienst kann über verschiedene Methoden (Method) aufgerufen
werden. Ein Methodenaufruf wird durch Parameter gesteuert (parameters). Der Typ
von Parametern ist Field. Parameter können optional sein.
Es gibt zwei verschiedene Typen von Parametern: Einmal einfache Zeichenketten
(SimpleField) und komplexe Typen (ComplexField) mit Unterfeldern. Die Unterfelder
werden über die Referenz fields des Typs (ServiceType) festgelegt. Rückgabeobjekte
von Methoden werden über die Referenz return angegeben. Dienste, Methoden, Fel-
der und Typen werden über das Attribut name referenziert.
Eine Besonderheit des Service-Metamodells ist die Beschränkung auf die konzeptio-
nelle Beschreibung der Developer Garden SOAP-Schnittstelle. Es wurde aufgrund
der Übersichtlichkeit der Benutzerdokumentation bewusst auf die Beschreibung der
vielen zusätzlichen Details einer WSDL-Datei verzichtet. Dennoch bietet die Benut-
zerdokumentation hinreichend viele Details zum Aufbau und zur Funktionsweise
der APIs, sodass dadurch die Ansprache der Schnittstelle, sowie die Verwendung
der SOAP-SDKs unterstützt werden.
97
Eigene Darstellung

40
Die erste Iteration des Frameworks konnte die gestellten Aufgaben P1-P4 lösen. Al-
lerdings ergaben sich Aufgrund der geringen Erfahrungen mit den eingesetzten
Werkzeugen und der aufgrund der zeitlichen Vorgaben für die Realisierung relativ
kurz ausgefallenen Konzeptionsphase einige Kompromisse in der Realisierung:
Modellierung der Rückgabewerte
Die Modellierung der Rückgabewerte (return) über Typen ist im Nachhinein betrach-
tet nicht optimal. Das Service-Modell enthält dadurch für n Methoden auch n Typen,
was die Lesbarkeit des Modells beeinträchtigt.
Das Modellelement „Typ“ (ServiceType) sollte mehrfach auftauchende, Service spezifi-
sche Datenrepräsentationen darstellen, wie beispielsweise „Details einer Person“ o-
der „IP-Adresse“. Ein Rückgabetyp ist 1:1 mit der Methode verknüpft, daher könnte
dieser besser über eine Aggregation von Feldern (Field) modelliert werden.
Transformation durch XSL / Referenzierung durch name
Die Modelltransformation der dynamischen XMI-Instanz in das Docbook-
Ausgabeformat durch XSL wurde gewählt, da Aufgrund der Erfahrungen mit XSL-T
ein schneller Fortschritt bei der Generierung der SOAP-Dokumentation erzielt wer-
den konnte. Außerdem ist die einfache Zugänglichkeit des Docbook Content-
Repositories durch das Zusammenspiel von XSL-T und XML gegeben.
Allerdings mussten zur Verarbeitbarkeit der XMI-Instanz durch XSL-T die name-
Attribute als ID definiert werden, was zu einer Invalidität des Modells geführt hat,
da alle IDs global eindeutig sein müssen – und das über alle Modellelemente.98
So hat
die Methode sendSms beispielsweise die gleiche ID, wie der Service sendSms. Diese
fehlende Validität des Modells hat allerdings in dieser Iteration noch keine Auswir-
kungen auf die Funktionsfähigkeit der Lösung gehabt.
Außerdem kann aus einer XSL-T – Transformationen nicht auf Xtend, Xpand und
EMF – Funktionen zugegriffen werden, was sich erst bei späteren Iterationen ausge-
wirkt hat.
3.2 Iteration 2: REST
Kurz nach der Fertigstellung der ersten Iteration wurden alle Developer Garden
APIs um eine REST-Schnittstelle erweitert. Die vorhandenen APIs wurden nicht nach
dem REST-Architekturstil grundlegend umstrukturiert, sondern lediglich in ein URI-
Schema gepasst, welches eine Art Ressourcenorientiertheit zeigt. Daher lassen sich
auch für fast jedes REST-Element (Service, Methode, Parameter) ein korrespondie-
rendes SOAP-Element finden.
98
Vgl. „Referenzen, Attribute und die Rolle des ID-Flags“ in Kapitel 2.3.2 (Seite 12)

41
Folgende Aufgaben bestanden für diese Iteration:
A1 Ergänzen der Benutzerdokumentation um Informationen zur neuen REST-
Schnittstelle
Die Benutzerdokumentation sollte um alle Informationen ergänzt werden,
die notwendig sind, um die REST-Schnittstelle zu verwenden. Dazu gehö-
ren der Aufbau der Aufrufe und Antworten, die Fehlercodes sowie die
Struktur der URLs.
A2 Darstellung der Zusammenhänge zwischen SOAP- und REST-Methoden
Da jede SOAP-Methode nun auch per REST aufgerufen werden kann (und
vice versa), sollte diese Information der Beschreibung hinzugefügt werden.
A3 Vermeidung von Redundanzen zwischen SOAP- und REST-
Methodenbeschreibungen
Die vorhandenen Beschreibungen der SOAP-Parameter im Content-
Repository lassen sich bis auf wenige Ausnahmen als Beschreibungen der
REST-Parameter verwenden. Daher sollte die Pﬂege von doppelten Para-
metern umgangen werden.
In der nachfolgenden Abbildung werden die neuen Modellelemente der zweiten Ite-
ration dargestellt. Die Klassen ComplexField und Method wurden nur zur Darstellung
der neuen Vererbungsbeziehungen eingefügt.

42
Abbildung 14 - Neue REST-Elemente der zweiten Iteration99
(März 2010)
Die Modellelemente Service und Provider wurden um neue REST-Informationen,
teilweise auch Telekom-Speziﬁka (z.B. realm) ergänzt. Das neue Modellelement
ErrorCode abstrahiert die von der REST-Schnittstelle zurückgegebenen Fehlercodes,
wobei die deutschen und englischen Fehlercode-Beschreibungen zum Content-
Repository hinzugefügt wurden.
Weiterhin wurden neue Modellelemente hinzugefügt:
SimpleFieldRest
SimpleFieldRest stellt ein REST-Feld (Parameter) inkl. Unterfeldern (subfields)
dar. Ein REST-Feld ohne Unterfelder wird weiterhin als SimpleField
repräsentiert.
99
Eigene Darstellung

43
In der Iteration 2 wird dieses Modellelement nur bei Antwortnachrichten
verwendet, da kein Service eine Parameter-Feldhierarchie besitzt
ComplexFieldRest
ComplexFieldRest stellt wiederkehrende Datentypen dar und wird in der
zweiten Iteration vorerst nicht verwendet.
ErrorCode
Zur Repräsentation der REST-Fehlercodes dient das Meta-Modellelement
ErrorCode. Es enthält den HTTP Statuscode (restHttpCode), die Server-
Statusnachricht (statusMessage) und den numerischen, fachlichen Fehlercode
der Schnittstelle (statuscode).
Das Attibut module legt fest, ob es sich um übergreifende Fehlercodes handelt
(module = base) oder ob der Fehlercode zu einem speziﬁschen Service (module
= name-Attribut eines Service-Elements) gehört.
Über das Attribut baseCode wird eine architektonische Besonderheit der
Developer Garden Schnittstelle abgebildet: Durch die Kapselung der
einzelnen Services auf dem Open Development Gateway besteht die
Möglichkeit, dass ein übergreifender Fehlercode (z.B. für „Keine
Berechtigung“ = 0020) in einem Service einen anderen Fehlercode zugewiesen
bekommt (z.B. „keine Berechtigung“ im Conference Call Service = 0093). Das
Attribut baseCode legt den Fehlercode fest, der durch den jeweiligen
Fehlercode überschrieben wird.
RestResource
RestResource stellt ein Pfadelement in der REST-URL dar. Das Attribut dynamic
legt fest, dass der Wert eines Pfadelements änderbar ist und es dadurch eine
Art von Parameter darstellt.
Die URL für einen Aufruf wird wie folgt gebildet:
Abbildung 15 - Bildung der REST-URL aus Modellelementen100
100
Eigene Darstellung
POSThttp://gateway.developer.telekom.com/p3gw-mod-odg-voicebutler/rest/{environment}/call
httpMethod = POST
NewCall : RestMethod
restEndpoint = /p3gw-mod-odg-voicebutler/rest
VoiceCallService : Service
restHostname = gateway.developer.telekom.com
DeveloperGardenProvider : Provider
name = environment
dynamic = true
Environment : RestResource
name = call
dynamic = false
Call : RestResource

44
Eine Besonderheit der Developer Garden REST-Schnittstelle ist die Möglichkeit, die
Rückgabewerte der Methoden in drei unterschiedlichen Formaten anzufordern.101
Dies wird u.A. durch die serverseitige Verwendung des Frameworks Jersey102
er-
reicht.
Das entworfene Metamodell zeigt, dass alle Repräsentationsformen (XML, JSON und
Text) durch ein und dieselben Metamodellelemente ausgedrückt werden können.
Auswertung
Die vorgenannten Maßnahmen lösen die Aufgabenstellung A1. Zur Lösung der Auf-
gabenstellung A2 wurden die strukturellen Eigenschaften correspondingType, corres-
pondingField und correspondingMethod eingeführt, welche die mit REST-Elementen
zusammenhängenden SOAP-Elemente referenzieren. So werden im Voice Call Ser-
vice die Parameter bprivacy der REST-Methode und privacyB der SOAP-Methode
über das Setzen des correspondingField-Attributs auf privacyB (dem Namen des
SOAP-Parameters) verknüpft.
Aufgabenstellung A3 wurde gelöst, indem die Beschreibung der mit REST-
Modellelementen korrespondierenden SOAP-Modellelemente verwendet wird, um
die REST-Modellelemente zu beschreiben. Zur vereinfachten Instanziierung des Me-
tamodells wurde darüber hinaus die Konvention geschaffen, dass gleich benannte
Parameter einer REST-Methode und einer mit dieser Methode korrespondierenden
SOAP-Methode automatisch die gleiche Beschreibung erhalten, beispielsweise beim
expiration-Parameter der REST- und SOAP-Methode newCall. Im Anhang 1 (Seite
v) werden diese Eigenschaften an einem Auszug des Developer Garden – Modells
demonstriert. Die geschaffene Konvention kann überschrieben werden, indem cor-
respondingType auf einen beliebigen Wert gesetzt wird und mithilfe dieses Wertes
eine Beschreibung im Content-Repository abgelegt wird.
Durch die Änderungen am Metamodell, die Ergänzungen des Modells und die Er-
weiterung der sonstigen Bestandteile des Frameworks wurden alle Aufgaben dieser
Iteration erfolgreich gelöst.
In der Retrospektive dieser Iteration ergeben sich die nachfolgend erläuterten Prob-
lemstellungen.
101
(Deutsche Telekom AG, 2011B)
102
(Oracle Corporation, 2011A)

45
Rolle des multiple-Attributs
Die semantische Bedeutung des multiple-Attributs ist die Kennzeichnung eines REST-
Feldes als Array. Vom Prinzip her kann diese Kennzeichnung auch auf SOAP-Felder
zutreffen, wurde aber bis zur Iteration 3 im Beschreibungstext des jeweiligen Feldes
vermerkt (z.B. „Dieses Feld enthält eine Liste von …“) und ist daher nicht im Modell
formalisiert.
Vererbungsbeziehungen zwischen REST- und SOAP-Elementen und subfields-Referenz
In der Domäne „Developer Garden Benutzerdokumentation“ sind sowohl die Verer-
bungsbeziehung zwischen SOAP- und REST-Elementen, als auch die Einführung
einer subfields-Referenz für die Darstellung von Feldhierarchien durchaus zutreffend.
Denn die Dokumentation von SOAP-Elementen wird bei REST-Elementen um zusätz-
liche Eigenschaften erweitert, wie z.B. der Rest-Endpunkt (restEndpoint-Attribut) oder
eine Feldhierarchie (subfields).
Allerdings hat sich gezeigt, dass viele Template-Konstrukte und funktionale Erweite-
rungen vereinfacht werden könnten, indem der Problemraum anders abstrahiert
wird: Basiselemente (z.B. Field) bilden die Struktur einer Schnittstelle ab (also auch
die Feldhierarchie) und technologiespezifische (also SOAP/REST) Elemente erben
von diesen Strukturelementen und enthalten technologiespezifische Informationen,
wie z.B. (z.B. RestField und SOAPField).
Modellierung der corresponding-Attribute als String
Die Verknüpfungen zwischen REST und SOAP-Elementen wurden nicht als ECore-
Referenzen modelliert, sondern als einfache String-Attribute. Dies hat den
Hintergrund, dass die gewählten ID-Attribute (z.B. Service.name oder Method.name)
innerhalb des Modells nicht eindeutig sind.103
Dies hat auf der einen Seite die Nachteile, dass bei der Modellpflege keine Vorschlä-
ge für zutreffende Werte unterbreitet werden können und erst Funktionen zur Er-
mittlung der korrespondierenden Elemente implementiert werden müssen.
Da die corresponding-Attribute nur für die Generierung der Dokumentation eine Rol-
le spielen, ergibt sich hier auch ein Vorteil: Durch die Definition nicht vorhandener
Namen von korrespondierenden SOAP-Elementen kann im Content Repository eine
Beschreibung gepflegt werden, die nur auf REST-Elemente zutreffend ist und somit
eventuell vorhandene semantische Differenzen zwischen SOAP und REST abgefan-
gen werden.
103
Vgl. „Referenzen, Attribute und die Rolle des ID-Flags“ in Kapitel 2.3.2 (Seite 12)

46
Abbildung komplexer Felder
In der Iteration 2 wurden komplexe Felder durch die subfields-Referenz der Simple-
FieldRest-Modellklasse abstrahiert. Diese Referenz wurde als SimpleFieldRest deklariert
um auszudrücken, dass nur REST-Felder andere REST-Felder enthalten.
Allerdings wird dadurch die Möglichkeit ausgeschlossen, dass auch typisierte REST-
Felder (ComplexFieldRest) Unterfelder von REST-Feldern sein können. Dies hatte erst
in der Iteration 4 Auswirkungen, da erst dort das erste Mal REST-Typen und damit
auch typisierte REST-Felder in das Modell eingepflegt wurden.
3.3 Iteration 3: SDK-Generierung
Die dritte Iteration (März bis Oktober 2010) erweiterte den Umfang des Frameworks
erheblich: Die vorhandenen Developer Garden SOAP-SDKs104
sollten durch automa-
tisch generierte REST-SDKs ersetzt werden.
Durch diese Aufgabe werden die zu Beginn der dritten Iteration vorhandenen Prob-
lemfelder adressiert:
P1: Qualitätsprobleme des externen Lieferanten
Bis zum Abschluss der dritten Iteration pflegte ein externer Lieferant die Developer
Garden SOAP SDKs. Über die Projektdauer (seit Anfang 2008) ergaben sich häufig
Probleme bezüglich der Qualität der gelieferten Leistung.
Lösungsansatz: Die Verschiebung der Verantwortung zum Developer Garden-
Team und der neue modellgetriebene Ansatz soll die Qualität der SDKs steigern.
P2: Veraltete Technologien
Die Developer Garden SOAP SDKs setzten seit der ersten Implementierung (Anfang
2008) auf veraltete Technologien. So basiert das Java-SDK auf dem veralteten Axis1105
und die .NET-SDKs auf den von Microsoft abgekündigten Web Services Extensi-
ons106
.
Lösungsansatz: Um dieses Problemfeld in der Zukunft zu umgehen, basieren die
REST SDKs auf zum Zeitpunkt der Veröffentlichung aktuellen Technologien.
P3: „Schwergewichtige“ Lösungen
Mehrere Eigenschaften der SOAP SDKs tragen zu einer wahrgenommenen „Schwer-
gewichtigkeit“ bei. Zum einen enthalten alle SDKs die umfangreiche Telekom
LibSTS, von der nur ein äußerst kleiner Teil durch die SDKs verwendet wird.
104
Letzte Version archiviert unter (Deutsche Telekom AG, 2011)
105
(The Axis Development Team, 2006)
106
(Microsoft Corporation, 2005)

47
Zum anderen benötigt das Java-SDK für die Ausführung 7 Mbyte an Java *.jar-
Dateien, obwohl die *.jar-Datei des SDKs selbst nur 400 kByte belegt.
Lösungsansatz: Die neuen SDKs sollen mit so wenigen Abhängigkeiten, wie mög-
lich implementiert werden.
P4: Eingeschränkte Anwendbarkeit des Java SDKs
Durch die Abhängigkeit des Java-SDKs von mehreren externen Bibliotheken ist das
SDK nur sehr umständlich innerhalb des Java-Applikationsservers JBoss oder mit
dem Framework Struts verwendbar.107
Lösungsansatz: Das Java-SDK soll gar keine Abhängigkeiten zu externen Bibliothe-
ken enthalten. Darüber hinaus soll das Java-SDK Java 1.4 – kompatibel sein, sodass
es auch in Legacy-Lösungen integriert werden kann.
P5: Kommunikations-Overhead und Ressourcenverbrauch
Dieses Problemfeld entsteht durch die Verwendung von SOAP als Kommunikations-
Architekturstil.108
Lösungsansatz: Es ist zu erwarten, dass die Verwendung des REST - Architektur-
stils den Kommunikations-Overhead, sowie den Ressourcenverbrauch deutlich re-
duzieren kann.
P6: Mangelhafte Dokumentation
Die Dokumentation der SDKs, vor allem die Source Code-Kommentare sind mit ei-
nigen Mängeln behaftet. So sind sie nicht für alle SDKs einheitlich, enthalten sprach-
liche Fehler und die Semantik einiger Beschreibungen unterscheidet sich im Ver-
gleich zur Benutzerdokumentation erheblich.
Lösungsansatz: Die Source-Code Dokumentation wird per Transformation aus
demselben Content-Repository extrahiert, wie die Benutzerdokumentation. Dadurch
werden Fehler und Ungleichmäßigkeiten ausgeschlossen.
P7: Keine Testfähigkeit des SDKs
Die SDKs enthalten Unit-Tests, die lediglich im internen Telekom-Netz ausführbar
sind, nicht jedoch von den letztendlichen Benutzern.
Lösungsansatz: Es werden Unit-Tests generiert, die von jedem Nutzer in der Deve-
loper Garden Mock-Umgebung ausgeführt werden können.
107
(Zimmer, 2009)
108
Siehe auch „SOAP“ (Seite 8)

48
P8: Keine Abbildung der Developer Garden Status-Codes
Es existieren in den SDKs weder eine Auﬂistung der möglichen Fehlercodes eines
Services, eine Beschreibung der Services noch Konstanten zur Überprüfung der
Antworten. Dadurch wird die Fehlerbehandlung in der Arbeit mit den SDKs er-
schwert.
Lösungsansatz: Es sollen sowohl alle Fehlercodes eines Services durch Konstanten
abgebildet, als auch eine Beschreibung der Fehler generiert werden. Da das Content-
Repository zweisprachig ist, können sowohl deutsche, als auch englische Fehlerbe-
schreibungen generiert werden.
P9: Exposition interner Details
Die SOAP SDKs enthalten Klassen und Parameter, die lediglich Telekom-intern ver-
wendet werden: Neben der nur zu einem kleinen Teil verwendeten Telekom LibSTS
enthalten die Konstruktoren der Service-Clients Parameter zur Veränderung der an-
gesprochenen URLs, welche bei Telekom-internen Service-Tests verwendet werden.
Jedoch ist für Endnutzer der SDKs nur eine URL verfügbar - die Möglichkeit der
Veränderung also überﬂüssig.
Konkrete Anfragen an den Developer Garden Support gab es gehäuft bezüglich des
ungeschickt gewählten und dokumentierten Konstruktor-Parameters domain, der
immer auf den Wert t-online.de gesetzt werden muss. Einige Nutzer haben,
durchaus nachvollziehbar, den Wert auf die Domain developergarden.com gesetzt,
wodurch sie das SDK nicht nutzen konnten.
In der Quellcode-Dokumentation wurde außerdem nicht erwähnt, dass Parameter
für einen Endnutzer unveränderlich sind und lediglich für interne Verwendung an-
geboten werden.109
Lösungsansatz: Es werden keine Parameter oder Quellcode generiert, die nicht für
einen Endnutzer gedacht sind. Aufgrund des modellgetriebenen Verfahrens ist es
relativ einfach für den internen Gebrauch automatisch andere SDKs mit veränderten
URLs zu generieren.
109
Bsp.: domain: „The domain of the user who wants to use the service.“

49
P10: Keine Mehrsprachigkeit
Obwohl die Benutzerdokumentation zweisprachig vorliegt, existieren die SDKs le-
diglich in einer Sprache: Englisch. Mehrsprachigkeit ist keine übliche Eigenschaft
von SDKs, jedoch steigert ein SDK mit Code-Kommentaren in Deutsch und damit in
der Muttersprache der meisten Kunden des Developer Gardens die Verständlichkeit
und damit auch die Benutzbarkeit der Developer Garden API.
Lösungsansatz: Da das Content-Repository zweisprachig vorliegt, ist es naheliegend
die Transformation für beide Sprachen durchzuführen. Dadurch können mehrere
SDK-Sprachversionen angeboten werden.
Lösungskonzept
Auf Basis der vorgenannten Lösungsansätze wurde folgendes Lösungskonzept erar-
beitet:
Abbildung 16 - Lösungskonzept der Iteration 3110
110
Eigene Darstellung
Metamodell
service.ecore
Modell
developergarden.xmi
Abstrakte Syntax
Content-Repository
content.xml
Xtend-Transformation
cleanModel.ext
„Sauberes“ REST-Modell
Developergarden.clean.xmi
Struktur
Inhalt Auflösung der Feldhierarchien
Ermittlung der Dokumentation
SDK Quellcode
Java SDK
DE
Java SDK
EN
.NET SDK
DE
.NET SDK
EN
PHP SDK
DE
PHP SDK
EN
Code-Generierung
ANT Workflow
SDK - Endergebnis
Java SDK
DE
Java SDK
EN
.NET SDK
DE
.NET SDK
EN
PHP SDK
DE
PHP SDK
EN
Statische
Bestandteile
Plattformspezifischer
Build-Vorgang
Xpand - Templates
Xtend - Funktionen

50
Grundlage der Generierung ist eine erweiterte Version des vorhandenen Metamo-
dells. Da das Modell sowohl Elemente zur Beschreibung der SOAP-Schnittstelle, als
auch der REST-Schnittstelle enthält, wurde zur Vereinfachung der Code-
Generierung eine Xtend-Transformation implementiert (cleanModel.ext), welche
das Modell „säubert“, also die SOAP-Elemente aus dem Modell entfernt.
Transformation der Feldhierarchie
Darüber hinaus löst die Xtend-Transformation die Feldhierarchie auf, d. h. für jede
Ebene der Antwortformate wird ein REST-Modellelement erstellt. Dies ermöglicht
eine relativ einfache Transformation der neuen Typen in Klassen der Zielsprachen
der SDKs.
Das folgende Beispiel zeigt anhand eines Ausschnitts aus der getConferenceStatus-
Antwortnachricht diesen Mechanismus:
developergarden.xmi
Typ getConferenceStatusRestReturn
• Feld conference
o Unterfeld detail
 Unterfeld name
⇒ developergarden.clean.xmi
Typ GetConferenceStatusResponse
• Feld conference (Typ: GetConferenceStatusConferenceResponse)
Typ GetConferenceStatusConferenceResponse
• Feld detail (Typ: GetConferenceStatusConferenceDetailResponse)
Typ GetConferenceStatusConferenceDetailResponse
• Feld name
Ermittlung der Dokumentation
Da die Ermittlung der Dokumentation der jeweiligen Modellelemente aus dem Con-
tent Repository ein relativ aufwändiger Prozess ist, wird die Dokumentation in deve-
lopergarden.clean.xmi in den Feldern descriptionGerman und descriptionEnglish zwi-
schengespeichert.
Somit können beispielsweise Änderungen an den Code-Templates durchgeführt
werden, ohne die cleanModel.ext-Transformation erneut durchführen zu müssen.
Build-Vorgang
Der Build-Vorgang der SDKs gliedert sich in zwei Schritte:
• Code-Generierung
Die Code-Generierung erfolgt durch Xpand Code-Templates.
Zusätzlich existieren Xtend-Funktionsbibliotheken, welche während der Trans-
formation wiederholt benötigte Ausdrücke enthalten. Dies sind zum Beispiel
Funktionen zur Berechnung von plattformspeziﬁschen Namen von Klassen, In-
terfaces, etc. oder Funktionen zur Selektion von Elementen innerhalb des Mo-
dells.

51
• Plattformspezifischer Build-Vorgang
Der generierte Code wird mit statischen Bestandteilen zusammengeführt und
im Anschluss daran nach plattformspezifischen Vorgaben gebaut.
Statische Bestandteile sind beispielsweise Basisklassen der Developer Garden
Clients, Konfigurationsdateien für Apache Maven111
oder Sandcastle Help File
Builder112
XML-Dateien.
Der plattformspezifische Build-Vorgang beinhaltet meist die Kompilierung des
Quellcodes, die Erzeugung von Dokumentations-Dateien mit Hilfe von Tools
der Zielplattform sowie die Ausführung der Unit-Tests.
Der Build-Vorgang der SDKs wird auf einem Server für die kontinuierliche Integra-
tion durchgeführt.
Anpassungen am Metamodell
Abbildung 17 - Neue Elemente und Beziehungen der dritten Iteration113
111
Tool zum Management von Softwareprojekten: (The Apache Software Foundation, 2011)
112
Tool zur Generierung der .NET – Dokumentation: (Woodruff, 2011)
113
Eigene Darstellung

52
Mit der Erweiterung der Anforderungen an das Framework wurde auch das Meta-
modell erweitert. Die vorhergehende Abbildung zeigt neue Elemente und Implemen-
tiert-Beziehungen der dritten Iteration. Zur Steigerung der Übersichtlichkeit wurden
die konkreten Implementierungen von UnitTestStep und SampleStep ausgelassen.
Einige der neuen Modell-Elemente sollen im Folgenden kurz erläutert werden:
DocumentedClass
DocumentedClass dient dazu, die Beschreibungen von Modellelementen zwi-
schen zu speichern.114
Jedes beschriebene Element implementiert dieses Inter-
face.
Durch die Speicherung der Beschreibung in den Attributen descriptionGerman
und descriptionEnglish sind die Beschreibungen innerhalb der Code-
Transformationen sehr einfach zugänglich.
UnitTest
UnitTest abstrahiert Unit-Tests für einzelne Services. Das Attribut environment
legt fest, in welcher Developer Garden Umgebung der Unit-Test ausgeführt
werden soll. Ein UnitTest enthält ein oder mehrere Test-Schritte (UnitTestStep).
UnitTestStep
Ein UnitTestStep ist ein Schritt in einem Unit-Test. Im Metamodell enthaltene
Schritte sind zum einen die Ausführung einer REST-Methode mit bestimmba-
ren Parametern und zum anderen Überprüfungen (Assertions) von Eigenschaf-
ten der Rückgabewerte (z.B. „gleich einem bestimmten Wert“ oder „nicht
null“).
Sample
Ein Sample ist ein dem SDK beiliegendes Beispiel zur Verwendung eines Ser-
vices. Ein Sample besteht ähnlich wie Unit-Tests aus Beispiel-Schritten und es
existieren daher auch gemeinsame Xtend-Ausdrücke zur Verarbeitung von
Samples und Unit-Tests.
SampleStep
Ein SampleStep ist ein Schritt in einem dem SDK beiliegendem Beispiel. Im Me-
tamodell enthaltene Schritte sind die Deﬁnition von Variablen (SampleStepDefi-
neVariable), der Aufruf von Methoden (SampleStepInvokeMethod) sowie die Aus-
gabe von Rückgabewerten auf der Konsole (SampleStepPrintVariable).
114
Siehe „Ermittlung der Dokumentation“ (Seite 40)

53
ErrorCode.constantName und Service.number
Um die architektonische Besonderheit der Developer Garden Fehlercodes115
ab-
zubilden wurden zwei Attribute zum Metamodell hinzugefügt.
Das Attribut constantName der Metamodellklasse ErrorCode weist jedem Fehler-
code eine eindeutige Konstante zu (z.B. „MESSAGE_TOO_LONG“ oder
„TOO_MANY_NUMBERS“), die in den Zielsprachen mithilfe des jeweiligen Kon-
stanten-Mechanismus (z.B. „public static final int“-Felder in Java) um-
gesetzt wird.
Mithilfe des Attributs number der Metamodell-Klasse Service wird jedem Service
eine Nummer zugewiesen, die in einem Algorithmus verwendet wird, der die
korrekte Zuordnung von Konstanten und Beschreibungen zu überschriebenen
Fehlercodes implementiert.
Auswertung
Insgesamt lässt sich feststellen, dass alle Problemfelder durch die Lösungsansätze
der REST SDKs adressiert werden konnten:
• Das Java REST SDK enthält keine externen Bibliotheken und ist zudem nun
abwärtskompatibel bis zur Java Version 1.4. Dadurch ergeben sich neue Ein-
satzmöglichkeiten des SDKs.
• Im .NET-SDK konnten die veralteten Web Services Extensions durch die
Windows Communication Foundation116
abgelöst werden.
• Das PHP-SDK ist nun abwärtskompatibel zu PHP Version 5.0 (vorher: 5.2.12).
Außerdem muss lediglich das PHP-Modul cURL aktiviert sein.117
• Die Abhängigkeit zur Telekom LibSTS entfällt in allen SDKs. Dadurch ergibt
sich eine geringere Download-Größe und ein verminderter Ressourcenver-
brauch.
• Die Dokumentation der SDKs konnte durch die Verwendung des Content-
Repositories der Benutzerdokumentation deutlich verbessert werden. Dar-
über hinaus werden die SDKs nun zweisprachig angeboten.
• Die Testfähigkeit der SDKs ist mit der Einbindung von Unit-Tests gegeben
• Der Developer Garden Status-Code – Mechanismus wird in allen SDKs abge-
bildet.
• Es werden keine internen Details durch die SDKs exponiert. (Problemfeld P9)
115
Beschrieben in „ErrorCode“ (Seite 32)
116
(Microsoft Corporation, 2011C)
117
Für das SOAP SDK sind die Module SOAP, OpenSSL, mcrypt und mhash erforderlich

54
Benchmark-Ergebnisse
Zur genauen Analyse der Auswirkungen der modellgetriebenen Entwicklung der
REST SDKs in Bezug auf Speicherverbrauch und Performance wurde ein Benchmark
beider Java-SDKs (SOAP & REST) durchgeführt. Getestet wurden die Dauer eines
Aufrufs der Methode newCall (Aufbau einer Sprachverbindung) und der Speicher-
verbrauch des Code-Samples vor und nach dem Lauf des Garbage Collectors.
Der Testaufbau war ein Intel Core i7 – Prozessor mit 2,6 Ghz unter Windows 7 und
Java 1.6, beides in der 64bit-Version. Die einzelnen Tests wurden mehrmals wieder-
holt und ein Durchschnitt der Messwerte gebildet.
Aufgabe SOAP-SDK REST-SDK Reduzierung
Dauer newCall() ~ 3250 ms ~ 1400 ms - 57 %
Speicherverbrauch vor GC() 12,1 MByte 2,5 MByte - 79 %
Speicherverbrauch nach GC() 4,8 MByte 1,6 MByte - 67 %
Der Benchmark zeigt sehr deutlich, dass die generierten REST SDKs einen überzeu-
genden Lösungsansatz des Problembereichs P5 (Overhead und Ressourcenver-
brauch) bieten.
3.4 Iteration 4: AutoScout24 – API
Zum Ende Mai 2011 wurde das Developer Garden API – Portfolio um eine Schnitt-
stelle zur Abfrage des Datenbestandes der Telekom-Tochtergesellschaft AutoScout24
erweitert. Dafür musste ab Oktober 2010 das entwickelte Framework für die Unter-
stützung der AutoScout24-API ergänzt werden.
Dadurch ergaben sich einige Herausforderungen:
Hohe Komplexität der Schnittstelle
Die AutoScout24-Schnittstelle besitzt eine unnötig hohe Komplexität, da im Vorfeld
der Realisierung versäumt wurde, die Anforderungsdeﬁnition auf Vereinfachungs-
potential zu überprüfen.
Daher werden viele Aspekte durch komplexere Konstrukte ausgedrückt, als eigent-
lich notwendig wäre. Beispielsweise müssen Wertebereiche als verschachtelte JSON-
Konstruktionen angegeben werden118
, anstatt durch einfache Zeichenketten119
.
118
z.B. Felder begin und end von FindArticlesRestReturn.response.vehicles.vehicle.availability
119
z.B. 1-5 für den Bereich von 1 bis 5 oder -5 bzw. 1- für den Bereich „bis 5“ beziehungsweise „ab 1“

55
Darüber hinaus sind alle mehrfachen Parameter und Rückgabewerte mit mindestens
einer Ebene mehr ausgestattet, als notwendig. Beispielsweise könnte die Liste der
gefundenen Inserate durch ein JSON-Array vehicles[] repräsentiert werden. An-
statt dessen existiert ein JSON-Objekt vehicles, welches ein JSON-Array vehicle[]
enthält.120
Andererseits wird durch die AutoScout24 – Schnittstelle eine Ungleichheit in die De-
veloper Garden APIs eingeführt, da bei allen anderen APIs Wertemengen als kom-
magetrennte Listen angegeben werden, bei der AutoScout24-Schnittstelle jedoch als
JSON-Arrays.
Großer Umfang der AutoScout24 – Schnittstelle
Die AutoScout24-Schnittstelle besitzt einen relativ großen Umfang. Dies wird unter
anderem im Java-SDK deutlich, in welchem 31% der Codebasis zur AutoScout24-
Schnittstelle gehören.121
Um die Deﬁnition der AutoScout24-API im Developer Garden Service-Modell (de-
velopergarden.xmi) zu vereinfachen, wurde eine XSLT-Transformation zur auto-
matischen Überführung der WSDL-Datei der SOAP-Schnittstelle in eine Beschrei-
bung der REST Schnittstelle implementiert.
Fakultativer environment-Parameter
Die ursprüngliche Version der AutoScout24 – Schnittstelle, für die das erstellte
Framework angepasst wurde, enthielt keinen environment-Parameter. Da alle ande-
ren APIs diesen Parameter besitzen, mussten die Code-Templates und funktionale
Erweiterungen angepasst werden, um diese Besonderheit zu unterstützen.
Aus Gründen der Einheitlichkeit wurde der environment-Parameter in der aktuellen
Version der API wieder eingefügt.
Änderung im Format der Aufrufe
Bisher wurden alle API-Aufrufe entweder als multipart/form-data122
, bzw. als ap-
plication/x-www-form-urlencoded123
versendet.
Die AutoScout24-API erwartet jedoch Funktionsparameter im JSON-Format124
, so-
dass erhebliche Änderungen und Ergänzungen in den Code-Templates, sowie den
funktionalen Ergänzungen vorgenommen werden mussten, um JSON-Objekte als
Aufrufparameter zu unterstützen.
120
Detaillierung und weitere Beispiele siehe Anhang 4
121
Im Java-SDK 3.1.10 sind 4.772 Zeilen von 15.558 Zeilen Code AutoScout24 bezogen
122
(Masinter, 1998)
123
(Berners-Lee, et al., 2005)
124
(Crockford, 2006)

56
Zur Umsetzung dieser Änderungen wurde im Metamodell der Typ der subfields-
Referenz der SimpleFieldRest-Modellklasse auf Field gesetzt (vorher SimpleFieldRest).
Eingeschränkte Verfügbarkeit, Zeitdruck
Aufgrund meiner Verpflichtungen im Studium und den Anforderungen anderer De-
veloper Garden Vorhaben (u.A. der Umstellung des Portalsystems auf TYPO3) blieb
für die umfangreichen Änderungen am Framework zum Anfang der Realisierung
relativ wenig Zeit. Aufgrund entstandenen Zeitdrucks für die Fertigstellung der An-
passungen wurde auf eine Ergänzung des Sample- und Unit-Test-Modells verzichtet
und anstatt dessen manuelle Code-Samples beigesteuert.
Allerdings musste hierdurch eine Möglichkeit geschaffen werden, einem SDK manu-
elle Samples hinzuzufügen, was besonders in der .NET-Plattform aufwändig ist, da
Sample-Dateien analysiert werden müssen, um sie in ein bestehendes .NET-Projekt
einzubinden.
Zur Unterstützung wurde außerdem die Pflege der AutoScout24-Dokumentation im
Content-Repository durch einen weiteren Mitarbeiter durchgeführt.
Tiefe Feldhierarchie
Die Hierarchie der Felder der AutoScout24 Nachrichten und Parameter ist deutlich
tiefer, als bei allen anderen APIs. Dadurch entstehen sehr lange Klassennamen, da
diese nach der Feldhierarchie gebildet werden.
Um die Rekursion während der Bildung der Klassennamen zu unterbinden, wurde
der Modellklasse SimpleFieldRest das Attribut breakNameGenerationRecursion hinzuge-
fügt.
Anwendbarkeit der Dokumentations-Generierung über XSL-T
Während der Änderungen am Metamodell und der Pflege der Dokumentation zeigte
sich, dass die Generierung der Dokumentation über eine XSL-Transformation kon-
zeptionelle Schwächen aufweist, da die technologische Trennung zwischen XSL-
Interpreter und Xtend-Transformation relativ groß ist.
So kann weder in der XSL-Transformation auf einfache Weise auf Xtend-Funktionen
zugegriffen werden, noch können Xtend-Code und Xpand-Templates auf Funktionen
der Dokumentations-Generierung zugreifen. Dadurch entstehen Redundanzen in der
Realisierung der Code- und Benutzer-Dokumentation.
Daher wurde die Dokumentations-Generierung in der Iteration 4 von XSL-T nach
Xtend migriert.

57
Auswertung
Das implementierte Framework konnte für die Generierung der AutoScout24-
Schnittstelle angepasst werden.
Allerdings zeigte sich, dass die Integration einer API mit grundverschiedener Konzi-
pierung gegenüber der ursprünglichen Domäne der anderen Developer Garden APIs
einen relativ hohen Implementierungsaufwand darstellt.
Daher soll bei der Ableitung eines neuen Lösungsansatzes die Anwendungsdomäne
möglichst umfassend definiert werden, sodass viele verschiedene REST APIs abge-
bildet werden können.
Außerdem wurde während der Realisierung der Anpassungen deutlich, dass das
Framework eine Refaktorierung durchlaufen sollte, um den Realisierungsaufwand
für zukünftige Entwicklungen zu verbessern.
3.5 Iteration 5: Refaktorierung / Eclipse OSGi
Die letzte Iteration des Frameworks schloss sich an die Ergänzung und Anpassung
für die AutoScout24 API an und beinhaltete diverse Refaktorierungen, sowie die
OSGi-befähigung des Frameworks.
Motivation für die Durchführung der Refaktorierung war die Erleichterung der Mig-
ration der Framework-Bestandteile zu einem zu erstellenden Framework. Außerdem
sollte die Analyse des Frameworks durch die Arbeiten an der Refaktorierung unter-
stützt werden und ein größeres Verständnis für die Eclipse-Plattform durch die OS-
Gi-befähigung des Frameworks erzielt werden. Dies alles soll die Realisierung eines
neuen Frameworks unterstützen.
Die durchgeführten Aufgaben der Iteration 5 waren wie folgt:
Auslagerung des Docbook- und Service-Metamodells in Eclipse Plug-Ins
Der Zugriff auf das Content Repository durch die Transformation zur Generierung
der Benutzerdokumentation und der Code-Kommentare erfolgt über die reflexive
Ecore-API. Da die Ecore Laufzeitrepräsentation des Docbook-XML – Modells auf-
grund der Vielzahl an Elementen relativ aufwändig zur Laufzeit neu berechnet wer-
den muss, wird das Laufzeitverhalten der Gesamtlösung dadurch eingeschränkt.
Daher wurde in der Iteration 5 der Zugriff auf das Docbook-Modell von reflexiver
API zu generierten EMF-Klassen umgestellt. Ebenso wurden die Modellklassen in
Eclipse Plug-Ins ausgelagert, da ansonsten die Eclipse Plattform bei jedem Erstell-
vorgang der Arbeitsumgebung ressourcenintensive Analysen der Quelldateien und
des Ecore-Modells durchführen würde.
Dieselben Tätigkeiten wurden auch für das Service-Modell durchgeführt.

58
Aufteilung des Build-Workflows
Der Umfang des Build-Workflows zur Generierung der SDKs und der Benutzerdo-
kumentation ist im Laufe der Realisierung erheblich gewachsen. In der Iteration 5
wurde der Ant-Workflow daher modularisiert und einige Anweisungen zur Steige-
rung der Les- und Wartbarkeit refaktoriert.
Überführung der Code-Generierung von MWE nach MWE2
Zur Evaluierung der MWE2 wurde der Workflow zur Code-Generierung von MWE
nach MWE2 überführt. Um diesen MWE2-Workflow aus dem Build-Workflow her-
aus zu starten, wurde ein Ant-Task implementiert (Mwe2Task).
Der Ant-Task übernimmt automatisch alle Ant-Properties in den Kontext der Mwe2-
Tranformation und erleichtert dadurch die Weitergabe von Konfigurationsoptionen
in den Code-Workflow, beispielsweise die aktuelle Sprache oder die zu generieren-
den Services.
Identifizierung von Redundanzen innerhalb der Arbeitsumgebung
Durch die erneute Einrichtung des Arbeitsbereichs auf Basis eines leeren Verzeich-
nisses wurden nur die Dateien überführt, die zur Generierung der SDKs und der Be-
nutzerdokumentation notwendig sind.
Hierdurch konnten Redundanzen innerhalb des Arbeitsbereichs aufgelöst und über-
flüssige Dateien entfernt werden.
Bewertung
Die Refaktorierungsarbeiten führten zu Verbesserungen bei der Strukturierung und
der Wartbarkeit des entwickelten Frameworks. Außerdem wurden viele Erkenntnis-
se gewonnen, welche die Realisierung den neuen Frameworks unterstützen. Gerade
die Implementierung des Ant-Tasks und die Überführung von Teilen des Frame-
works in OSGi-Plugins waren notwendig, um ein Verständnis für die Wirkungswei-
sen der Eclipse Plugin-Entwicklung zu erzielen.

59
3.6 Ableitung eines neuen Lösungsansatzes
Die Analyse der Iterationen des Frameworks zeigt eine grundlegende Änderung der
Anforderungen an das Framework: Von der Generierung der SOAP-
Benutzerdokumentation hin zur plattformübergreifenden Erstellung von REST-SDKs
für unterschiedliche Realisierungsstile der Developer Garden Web Services. Aller-
dings erfolgten diese Änderungen graduell über einen Zeitraum von mittlerweile
nahezu zwei Jahren, sodass seit der ersten Iteration keine grundlegende Überarbei-
tung, Refaktorierung oder Neuimplementierung des Frameworks vonstattenging.
Darüber hinaus ist die Weiterentwicklung der Haupttechnologien des Frameworks,
Xtend und Xpand, mittlerweile eingestellt, sodass zur Sicherung der Zukunftsfähig-
keit des Frameworks und zur Nutzbarmachung von technologischen Verbesserun-
gen auf die Nachfolgetechnologie Xtend 2.0 umgestellt werden muss.
Der analysierte Entwicklungsverlauf und die mittlerweile veralteten Technologien
führen zu einer Minderung der Qualität des Frameworks im Gegensatz zu einer
Neu-Implementierung auf Basis aktueller Anforderungen und Technologien. Dies
bezieht sich insbesondere auf die Zugänglichkeit, Wartbarkeit und Leistungsfähig-
keit des Frameworks.
Alle vorgenannten Fakten deuten darauf hin, dass nur eine grundlegende Überarbei-
tung die aufgezeigten Problemfelder lösen wird. Die vorhergehende Analyse bildet
das Fundament der im Folgenden dargestellten neuen Lösungsansätze:
Überarbeitung der Konzeption des Frameworks und des Metamodells
Die Konzeption des neuen Frameworks sollte sich an den Erfahrungen orientieren,
die in der Analyse der derzeitigen Konzeption aufgezeigt werden. Die Analyse un-
terstützt vor allem die Strukturierung der Implementierung des neuen Frameworks
in OSGi-Pakete und die intensivere Nutzung der Möglichkeiten der Eclipse IDE.
Außerdem sollte das neue Service-Metamodell in der Lage sein, die Eigenschaften
nahezu aller REST-Schnittstellen zu abstrahieren. Denn sowie im Service-Metamodell
Annahmen zu grundsätzlichen Eigenschaften einer Schnittstelle aus wenigen, spezi-
ellen Schnittstellen (z.B. den vorhandenen Developer Garden APIs) abstrahiert wer-
den, hat dies Auswirkungen auf nahezu alle Bestandteile eines Frameworks. Bei ei-
ner Änderung oder Erweiterung des Metamodells müssten dann aufwändige Ände-
rungen am Framework durchgeführt werden. Dies gilt es im neuen Framework
durch eine universelle Service-Abstraktion zu vermeiden.
Nutzung aktueller Technologien
Das neue Framework soll aktuelle Technologien nutzen, vor allem die Xtend/Xpand
Nachfolgetechnologie Xtend 2.0.

60
Es ist zwar zu diesem Zeitpunkt nicht abzusehen, welche technologische Entwick-
lung im EMP vonstattengehen wird, jedoch ist die Wahrscheinlichkeit als hoch ein-
zuschätzen, dass die beiden vor kurzem grundlegend aktualisierten Technologien
Xtend 2.0 und Xtext auf absehbare Zeit unterstützt und weiterentwickelt werden.
Modelldefinition über textuelle DSL
Die Definition von REST-Schnittstellen über eine kompakte textuelle DSL auf der
technologischen Basis von Xtext 2.0 ist im Vergleich zum bisherigen strukturierten
Editor deutlich zugänglicher und ausdrucksstärker. Daher soll zusätzlich zum gene-
rierten Ecore-Editor eine textuelle DSL für REST-Schnittstellen implementiert wer-
den.
Außerdem bietet die Definition einer zugänglichen und ausdrucksstarken DSL als
formale Beschreibungssprache von REST-Schnittstellen die Möglichkeit, Zweifel an
der Sinnhaftigkeit von REST-Beschreibungssprachen entgegen zu treten.
Modellierung der Zielsprachen
Im derzeitigen Framework existieren keine Modellelemente für Code-Artefakte der
Zielsprachen. Dadurch entstehen teilweise Redundanzen in Code-Templates und
funktionalen Erweiterungen. Außerdem lässt sich das Generierungsverhalten nur
über Anpassungen an Text-Templates steuern.
Das zu erstellende Framework soll Modellelemente für Zielsprachen-Artefakte defi-
nieren, um so eine bessere Strukturierung der Code-Generierung zu ermöglichen,
sowie Redundanzen in Templates soweit wie möglich einschränken zu können.
Anpassbarkeit und Erweiterbarkeit des Frameworks
Das Meta-Modell und die funktionalen Ergänzungen sollen zwar so wenig Annah-
men wie möglich über konkrete Implementierungseigenschaften von REST-
Schnittstellen machen, das Framework muss jedoch einen Mechanismus zur flexiblen
Anpassung und Erweiterung enthalten, sodass Service-spezifische Eigenarten defi-
niert werden können.
Überführung und Generalisierung vorhandener Funktionalität
Die Funktionalität der derzeitig generierten SDKs sollte im zu erstellenden Frame-
work weiterhin vorhanden sein, um keine Nachteile für die aktuellen Nutzer der
SDKs entstehen zu lassen. Darunter fallen beispielsweise die mehrsprachige Bereit-
stellung, die Unit-Tests und Code-Beispiele. Dies kann unter anderem durch die
Übernahme von Teilen der aktuellen Code-Templates geschehen.
Darüber hinaus sollte bei der Überführung von Code-Templates die Trennung zwi-
schen allgemeingültigen und Telekom-Spezifika beachtet werden.

GenerationREST: Konzipierung und Implementierung
61
4 GenerationREST: Konzipierung und Implementierung
GenerationREST ist der Name des neuen Frameworks, welches den aus der Analyse
der Entwicklung des derzeitigen Frameworks abgeleiteten Lösungsansatz umsetzen
soll. GenerationREST stellt eine Generalisierung und Erweiterung des entwickelten
Frameworks dar und ist daher ein universelles Werkzeug zur Generierung von
REST-Schnittstellenadaptern.
Die modellgetriebene Grundkonzeption des vorhandenen Frameworks wird hierbei
beibehalten: Auf Basis formaler Metamodelle werden mithilfe textueller DSLs die
Informationen zur Generierung von REST-Schnittstellenadaptern spezifiziert. Dies
sind unter anderem eine Beschreibung der REST-Schnittstelle sowie die Spezifizie-
rung der zu generierenden Artefakte, d.h. beispielsweise Plattform und Sprache des
zu generierenden SDKs.
GenerationREST ist in die Eclipse IDE integriert und nutzt auf sinnvolle Weise die
von der IDE bereitgestellte Funktionalität.
Projektaufbau
GenerationREST ist eine Menge von Eclipse Plugin-Projekten, welche die verschie-
denen Bestandteile des Frameworks kapseln und durch diese Strukturierung die
Komplexität der Gesamtlösung reduzieren:
org.generationrest.metamodel
Das gemeinsame Metamodell der Gesamtlösung.
Enthält ebenso den AspectJ-Aspekt, welcher für die Zusammenführung von
implementiertem und generiertem Code verantwortlich ist.
org.generationrest.framework
Alle funktionalen Ergänzungen des Metamodells, sowie die Code-
Generatoren.
org.generationrest.dsl
Die Xtext-Grammatiken und der MWE2-Workflow, welcher verwendet wird,
um die Xtext-Artefakte der Eclipse-Integration (z.B. den Editor) zu generieren.
org.generationrest.dsl.tests
Automatisch generiertes Projekt, welches für zukünftig zu implementierende
Validierungsregeln für die domänenspezifische Sprache vorgesehen ist.
org.generationrest.dsl.ui
Vom MWE2-Workflow automatisch generierte Xtext-Sprachbestandteile.

62
4.1 Metamodell
Das GenerationREST-Metamodell ist ein Ecore-Metamodell, welches in mehrere Pa-
kete aufgeteilt ist, die jeweils unterschiedliche Aspekte der Modellierung adressieren:
structure
Abstrakte Strukturelemente für gemeinsame Attribute aller Service-Modelle
(z.B. Service, Endpunkt, Feld, Methode, …)
rest
Aus structure abgeleitete Elemente mit REST-spezifischen Informationen (z.B.
HTTP-Authentifizierungsmechanismus, REST-Resourcenpfad, …)
documentation
Modellelemente zur Abstraktion der Dokumentation anderer Modellelemente
generation
Generatoren und Generator-Parameter.
sdk
Strukturklassen für die Modellierung der zu generierenden SDKs.
Sowohl generation als auch sdk enthalten Unterpakete je Zielplattform (java, php, dot-
net). Alle Pakete sind Unterpakete des Wurzelpakets service.
Falls das Metamodell für eine effektive Verarbeitung zu einem späteren Zeitpunkt zu
umfangreich werden sollte, so könnten die einzelnen Aspekte dann auch in getrennte
Ecore-Dateien aufgeteilt werden.
4.1.1 Paket structure
Das Paket structure abstrahiert gemeinsame Attribute aller Kommunikationstechno-
logien und bildet daher die Grundlage des REST-Modells (Paket rest). Die Aufteilung
in structure und rest wurde zur Verdeutlichung der Trennung zwischen allgemeiner
Struktur, sowie spezifischer Implementierungsdetails gewählt.
GenerationREST ist entgegen dem Namen offen gegenüber späteren Erweiterungen
um weitere Kommunikationstechnologien, wie z.B. XMLRPC oder SOAP. Diese
könnten auf denselben Klassen aufbauen, wie das REST-Modell und sogar einige der
für die structure-Elemente definierten Erweiterungen nutzen.
Das folgende Ecore-Diagramm zeigt die Modellelemente sowie die Attribute und
Referenzen. Zwecks Übersichtlichkeit wurde auf die Darstellung der implementiert-
Beziehung zwischen allen Modellelementen (außer DatatypeContainer) und dem Inter-
face NamedElement verzichtet.

63
Abbildung 18 - Diagramm des Pakets structure
125
Beschreibung der Modellelemente
Provider
Das Wurzelelement aller Service-Beschreibungen. Ein Provider enthält Metho-
den-Vorlagen (templateMethods), Endpunkte (endpoints) und Services (ser-
vices). Da ein Provider ein DatatypeContainer ist, enthält er Service-übergreifende
Datentypen.
Endpoint
Ein Endpoint abstrahiert den Endpunkt, über den ein Service aufgerufen wer-
den kann. Ein Service kann mehrere Endpunkte haben, beispielsweise einen
öffentlichen und mehrere Firmen-interne Test-Endpunkte. Die Beschreibung
der Art der Adressierung (z.B. über URLs) ist je nach Kommunikationstechno-
logie unterschiedlich und daher Bestandteil der abgeleiteten Service-
Modellelemente.
Service
Ein Service enthält Methoden (methods). Außerdem ist ein Service ein Data-
typeContainer und enthält dadurch Service-speziﬁsche Datentypen.
125
Eigene Darstellung

64
Method
Eine Methode kann Parameter (parameters) und eine Antwort (response) ent-
halten. Parameter sind Felder (Field); Antworten bestehen ebenso aus mehre-
ren Feldern.
Darüber hinaus kann eine Methode einer oder mehreren Vorlagen (templates)
vom Typ MethodTemplate entsprechen.
MethodTemplate
Vorlagen (MethodTemplate) dienen zur vereinfachten Erfassung von Metho-
den. Vorlagen enthalten Felder (Field), welche vor oder nach Parametern (pa-
rametersBefore und parametersAfter) beziehungsweise vor oder nach den Fel-
dern der Antwortnachricht (responseBefore und responseAfter) zu setzen sind.
Beispiele für die Anwendung durch die Developer Garden-SDKs sind die Sta-
tus-Informationen oder der account-Parameter.
Field
Ein Feld (Field) wird in verschiedenen vorgenannten Kontexten verwendet.
Ein Feld kann optional sein, eine Liste darstellen (multiple) oder beides.
Es gibt zwei Typen von Feldern:
ValueField
Ein ValueField ist ein typisiertes (dataType) Daten-Feld. Der Wert des Daten-
feldes kann vorbelegt sein (staticValue).
Dies könnte beispielsweise eine Versions-Nummer sein, die in jeder Nach-
richt mit demselben Wert gesendet werden muss.126
Die Art der Serialisie-
rung des Attributs staticValue wird von den Generatoren bestimmt.
StructuredField
Ein StructuredField ist eine aus weiteren Feldern (Field) bestehende Daten-
struktur. Das Serialisierungsformat (XML, JSON, Text, …) wird durch die
jeweilige Kommunikationstechnologie festgelegt.
DataType
Ein Datentyp (DataType) legt den Typ eines Daten-Feldes (ValueField) fest.
Die konkreten Datentypen der jeweiligen Kommunikationstechnologie wer-
den in den abgeleiteten Modellelementen deﬁniert.
126
Vgl. den v-Parameter der Google Maps API: (Google Inc., 2011)

65
NamedElement
Ein benanntes Element ist ein Modellelement, welches die Schnittstelle
NamedElement implementiert. Damit erhält das implementierende Element ein
Attribut name.
Um Redundanzen in der Modellierung zu reduzieren und eine generische
Verarbeitung von Modellelementen zu ermöglichen wurde das Attribut in ein
Interface ausgelagert.
DatatypeContainer
Ein DatatypeContainer ist ein Behältnis (dataTypes) für Datentypen (DataType).
Dabei sind sowohl Service, als auch Provider ein DatatypeContainer.
Die Modellierung eines DatatypeContainers dient der semantischen Unterschei-
dung zwischen Service-spezifischen und allgemeinen (Provider-spezifischen)
Datentypen.
NamedElement
NamedElement definiert ein identifizierendes Attribut (name) von nahezu allen
Metamodell-Elementen.
Generische Programmierung im structure-Paket
Alle Klassen sind abstrakt (abstract = true) und enthalten jeweils generische Typpa-
rameter. Dadurch wird erzwungen, dass zur Definition einer konkreten Kommuni-
kationstechnologie (REST, SOAP, etc.) nur alle Klassen des structure-Pakets gemein-
sam abgeleitet werden können.
Am Beispiel des Method-Elements wird der Mechanismus deutlich
Abbildung 19 - Generische Typparameter127
Die Strukturelemente templates (Vorlagen), parameters (Parameter) und response
(Rückgabewerte) sind parametrisiert. Daher kann Method nicht abgeleitet werden,
ohne die Typ-Einschränkungen der Parameter T und F zu erfüllen.
127
Eigene Darstellung

66
Um diese Einschränkungen zu erfüllen, müssen jedoch Field und MethodTemplate ab-
geleitet werden, da beide abstrakt sind und somit nicht instanziiert werden können.
Da alle Modellelemente in structure abstrakt und parametrisiert sind, wird daher er-
zwungen, alle Elemente abzuleiten.
Dadurch wird verhindert, dass Modellelemente unterschiedlicher Kommunikations-
technologien gemischt verwendet werden.
Es existiert keine sinnvolle Alternative für die Deﬁnition von gemeinsamen, abstrak-
ten Elementen aller Kommunikationstechnologien, als der vorgenannte Mechanis-
mus.
Andere Alternativen wären:
Alternative 1: „Klassische“ Vererbungsbeziehung
Eine aus anderen objektorientierten Sprachen bekannte Vererbungsbeziehung, d.h.
überschreiben des Typs eines Feldes (z.B. Field durch RestField) in einer abgeleiteten
Klasse (z.B. RestMethod → Method), ist in Ecore nicht anwendbar128
, da innerhalb ei-
ner Klassenhierarchie nicht zwei strukturelle Eigenschaften mit gleichem Namen
existieren können.
Alternative 2: Beibehaltung der Attribute und Typen in abgeleiteten Klassen
Die gemeinsamen Elemente aller Kommunikationstechnologien könnten auch inklu-
sive ihres Typs in den abgeleiteten Klassen beibehalten werden. Der Nachteil daran
wäre, dass dann die Verarbeitung von REST-Modellelementen immer mit Typum-
wandlungen einhergehen müsste, um z.B. die REST-speziﬁschen Attribute auszu-
werten.
Beispielsweise müsste die parameters-Referenz in RestMethod von Field nach RestField
typgewandelt werden, was die Lesbarkeit des Codes der funktionalen Erweiterun-
gen deutlich beeinträchtigen würde.
4.1.2 Paket rest
Das Paket rest implementiert die Struktur-Modellelemente des structure-Pakets und
stellt gleichermaßen eine Generalisierung des bisherigen Telekom Service-
Metamodells dar. Für das Paket rest existiert eine Xtext - Grammatik.
Im Folgenden werden die einzelnen Modellklassen beschrieben und ihre Implemen-
tierungsbeziehung durch ein → angegeben. Bei Modellklassen, die weder neue At-
tribute einführen, noch die Semantik der geerbten Klasse verändern, wird zur Ver-
meidung von Redundanzen auf eine ausführliche Beschreibung verzichtet.
128
(Merks, 2009)

67
RestProvider → Provider
RestEndpoint → Endpoint
Die Adressierung eines REST-Endpunkts geschieht durch das URI-Attribut.
RestService → Service, RestResource
RestMethod → Service, RestResource
Attribute einer REST-Methode sind die zu verwendende Übertragungsart der
Parameter (encoding), das HTTP-Verb (httpVerb), die Authentifizierungslogik
(authorization), sowie die HTTP-Header (headers).
RestMethodEncoding
Die Übertragungsart der Parameter von REST-Methoden. Unterstützt werden
Parameter in der URL sowie als HTTP-Formulardaten.
RestMethodAuthorization
Die Authentifizierungslogik einer REST-Methode. Unterstützt wird HTTP Ba-
sic-Authentifikation, d.h. Authentifikation über Benutzername und Passwort.
Neben der Verwendung von RestMethodAuthorization besteht auch die Mög-
lichkeit, einen HTTP Authorization-Header in der headers-Auflistung einer
REST-Methode zu definieren und zur Laufzeit zu berechnen, wie beispiels-
weise für die Developer Garden Token-Authentifizierung.
RestHttpVerbs
Eine Enumeration der möglichen HTTP-Verben129
.
RestResource
REST-Ressourcen, also REST-Methoden (RestMethod) und REST-Services
(RestService) werden durch eine URL adressiert, welche aus der Konkatenation
der URL des Endpunkts, sowie aller Pfadelemente (path) der jeweiligen Me-
thode und des Services gebildet wird.
RestResourcePathElement
Ein REST-Ressourcenpfad-Element.
129
Siehe (Fielding, et al., 1999 S. 51-57)

68
RestResourcePathStaticElement
Ein statisches, d.h. nicht änderbares Element eines REST-Ressourcenpfades.
Der Wert des Elements wird über das name-Attribut festgelegt.
RestResourcePathDynamicElement
Ein variables Element eines REST-Ressourcenpfades. Der Datentyp des Ele-
ments kann über das dataType-Attribut festgelegt werden.
RestMethodTemplate →MethodTemplate
Eine Vorlage für REST-Methoden.
Enthält gemeinsame HTTP-Header (headers), sowie voran- (pathElementsBefo-
re) und hintanzustellende (pathElementsAfter) Pfadelemente.
RestField → Field
RestValueField → RestField, ValueField<RestDataType>
RestStructuredField → RestField, StructuredField<RestDataType>
RestDataType → DataType
Im Gegensatz zum derzeitigen Framework, welches lediglich Zeichenketten
als Methodenparameter akzeptiert, werden im REST-Modell zusätzliche Da-
tentypen deﬁniert. Dies ermöglicht die clientseitige Typprüfung innerhalb ei-
nes SDKs und damit eine Formalisierung des erwarteten Formats von gesen-
deten Nachrichten.
RestDataTypeStructured → RestDataType
Ein strukturierter REST-Datentyp, d.h. ein Typ mit Unterfeldern (fields).
RestDataTypeString → RestDataType
Eine Zeichenkette mit optional speziﬁzierbarem Zeichensatz (charset, stan-
dardmäßig UTF-8). Im bisherigen Framework wurden Zeichenketten als ein-
ziger Datentyp unterstützt.
RestDataTypeNumber → RestDataType
Ein numerischer Datentyp mit der Möglichkeit, den Wertebereich (length) an-
zugeben. Außerdem kann bestimmt werden, ob es sich um eine vorzeichenlo-
se (signed=false) oder vorzeichenbehaftete (signed=true) Zahl handelt.

69
MetaNumberPrecision
Der Wertebereich einer Zahl, z.B. int8, int16 oder int32.
RestDataTypeBoolean → RestDataType
Ein boolescher Datentyp mit Speziﬁzierung der Zeichenkette für die Werte
wahr (trueValue) und unwahr (falseValue). Standardmäßig werden die Zei-
chenketten true und false als Serialisierung verwendet.
RestDataTypeEnum → RestDataType
Eine Enumeration. Unterstützt die Angabe des Serialisierungsformats der
Werte (valueType), sowie der möglichen Einträge (entries).
RestEnumEntry
Ein Eintrag in einer Enumeration. Jeder Eintrag ist eine Schlüssel (key) – Wert
(value) Kombination.
RestDataTypeCustom → RestDataType
Ein benutzerdeﬁnierter Datentyp, bestimmt durch eine Klasse der Zielsprache.
RestDataTypeFile → RestDataType
Ein Datei-Datentyp, welcher zur Abstraktion der unterschiedlichen Möglich-
keiten dient, Dateien an eine REST-Schnittstelle zu versenden, beispielsweise
als application/octet-stream innerhalb von HTML Form-Daten oder
Base64-codiert als Parameter.
RestDatatypeContainer → DatatypeContainer<RestDataType>
4.1.3 Paket documentation
Das Paket documentation enthält alle Metamodell-Elemente zur Abstraktion von Do-
kumentations-Artefakten und der Dokumentations-Generierung:
DocumentedElement
Alle Modellklassen, die das DocumentedElement-Interface implementieren, ver-
fügen über eine Dokumentation vom Typ Documentation, welche über einen
DocumentationProvider abgerufen werden kann.
Der für ein Element zuständige DocumentationProvider ist über die documenta-
tionProvider-Referenz eines DocumentedElements abrufbar.

70
Die im GenerationREST-Framework implementierten Erweiterungen verein-
fachen den Abruf des jeweiligen DocumentationProviders in der Form, dass der
jeweils übergeordnete DocumentationProvider verwendet wird, sollte die docu-
mentationProvider-Referenz leer (null) sein.
DocumentationProvider
Das Interface DocumentationProvider implementierende Modellklassen bieten
über die Methode retrieveDocumentation(…) die Möglichkeit, für ein Documen-
tedElement (Parameter element) einen bestimmten Typ von Dokumentation
(Parameter type) in einer Sprache (Parameter language) abzurufen.
Documentation
Ein Documentation-Element stellt einen bestimmten Typ von Dokumentation
(Parameter type) für ein bestimmtes DocumentedElement (Attribut element) in
einer bestimmten Sprache (Attribut language) dar.
Der Inhalt der Dokumentation (Attribut docbook) ist immer ein Docbook
XML-Element, gleich welcher Mechanismus zum Abrufen der Dokumentation
angewendet wird.
DocbookDocumentationProvider
Eine abstrakte Implementierung eines DocumentationProviders auf Basis von
Quelldateien im Docbook XML-Format (contentFiles).
GenerationREST enthält Xtend 2.0 – Extensions zur deutlichen Vereinfachung
von konkreten DocbookDocumentationProvider Implementierungen, die bei-
spielsweise die Extension-Methode applyXpath bereitstellen, welche die An-
wendung von XPath-Ausdrücken auf die Quelldateien ermöglicht.
DocumentationType
Der Typ einer Dokumentation. Derzeit sind „Titel“ (Title=0), „Beschreibung“
(Description=1) und „Konzeptionelle Dokumentation“ (ConceptualDocumentati-
on=2) vorgesehen.
Die Konzeption des Pakets documentation ermöglicht eine ﬂexible Implementierung
der unterschiedlichen Vorgehensweisen zum Abruf der Dokumentation eines do-
kumentierten Elements.
Die Vereinbarung, dass gleich welcher Vorgehensweise zum Abruf der Dokumenta-
tion die konkrete Dokumentation immer im Docbook XML-Format vorliegen muss,
vereinfacht die Implementierung der Überführung der Dokumentation in Quellcode-
Kommentare und konzeptionelle Dokumentation.

71
Da in jeder Zielsprache unterschiedliche Dokumentations-Repräsentationsformate
verwendet werden (z.B. JavaDoc, MAML, XML-Kommentare), muss durch diese
Vereinbarung immer nur eine Transformation (von Docbook nach Zielformat) im-
plementiert werden, und nicht mehrere (z.B. von Docbook, WikiText, Text, etc.).
4.1.4 Paket generation
Das Paket generation enthält Elemente zur Abstraktion und Konfiguration des Gene-
rierungsvorganges von Ziel-Artefakten (z.B. SDKs und Dokumentation). Für die
Elemente des Pakets generation steht eine Xtext-Grammatik zur Verfügung.
GenerationConfiguration
Das Wurzelelement einer Konfiguration für einen Generierungsvorgang.
Enthält importierte Elemente (imports), Parameter zur Steuerung des Generie-
rungsvorganges (parameters), sowie konfigurierte Generatoren (generators).
Import
Eine Referenz auf ein importiertes Element. Das Element wird über das Attri-
but importURI referenziert. Diese Modellierung stellt eine Implementierung des
Standard-Vorgehens unter Xtext 2.0 zur Referenzierung externer Ressourcen
dar.130
Die Referenzierung ermöglicht den Zugriff auf REST-
Schnittstellenbeschreibungen aus Konfigurationsdateien eines Generierungs-
vorganges.
SDKGenerator
Ein abstrakter SDK-Generator. Über die Methode generate() wird der Generie-
rungsvorgang gestartet. Der Generierungsvorgang kann durch Parameter (pa-
rameters) beeinflusst werden.
Die Xtend 2.0 – Referenzimplementierung eines SDKGenerators schreibt alle
Dateien (files) in die durch GeneratorParamOutlet-Parameter konfigurierten
Ausgabeverzeichnisse. Die konkreten Generator-Implementierungen legen die
Art fest, wie files berechnet wird.
130
„ImportURI Mechanism“: (Behrens, 2011A)

72
Mit SDKGeneratorComponent131
steht eine MWE2-Komponente bereit, welche
die Generation anhand einer Konfiguration aus einem MWE2-Workflow her-
aus starten kann.
GeneratorParam
Ein Generierungs-Parameter. Steuert den Generierungsvorgang.
GeneratorParamGenerationSelection → GeneratorParam
Legt die zu generierenden Services (servicesOfEndpoint) und den anzuspre-
chenden Endpunkt (endpoint) fest.
GeneratorParamLanguage → GeneratorParam
Die zu generierende Sprache (language).
GeneratorParamOutlet → GeneratorParam
Das Verzeichnis (directoryUri), in welches die Ausgabedateien der Generierung
gespeichert werden sollen.
GeneratorParamPackageNameTemplate → GeneratorParam
Die Vorlage (template) für die zu generierenden Paketnamen. Die Zeichenkette
{service} wird durch den Namen des jeweiligen Service-Pakets ersetzt.
Das Modellelement wird je Zielsprache überschrieben.
GeneratorParamCollection
Eine Sammlung von Generierungs-Parametern. Dies ist entweder ein konkre-
tes Behältnis (GeneratorParamContainmentCollection) oder eine Referenz auf eine
andere Sammlung (GeneratorParamCollectionLink).
Diese Abstraktion wurde gewählt, um eine möglichst flexible Abbildung aller
gewünschten SDK Generations-Konfigurationen zu ermöglichen.
GeneratorParamContainmentCollection → GeneratorParamCollection
Ein Behältnis für Generierungs-Parameter. Kann Parameter (parameters) und
Referenzen auf andere Sammlungen (links) enthalten.
131
Paket org.generationrest.framework.components

73
GeneratorParamCollectionLink → GeneratorParamCollection
Ein Verweis auf ein oder mehrere Parameter-Sammlungen (parameterCollec-
tions).
Zu den vorgenannten Modellklassen werden im Zuge der vollständigen Realisierung
des Frameworks sicherlich noch weitere Klassen deﬁniert. Unter anderem ist vorge-
sehen, dass bestimmte REST-Parameter als „Client-persistent“ deklariert werden
können, sodass diese Parameter bei der Laufzeit-Instanziierung der Service-Clients
angegeben, immer mit demselben Wert verwendet werden. Geeignet dafür ist unter
anderem der environment-Parameter der Developer Garden APIs, d.h. die Angabe
der zu verwendenden Umgebung.
Unterpaket java
Das Unterpaket java implementiert prototypisch Elemente zur Generierung eines Ja-
va-SDKs:
JavaGeneratorParam → GeneratorParam
Ein Generierungs-Parameter für einen Java SDK-Generator.
JavaSDKGenerator → SDKGenerator
Ein Java SDK-Generator. Das Verhalten des Generators wird per Xtend 2.0 Ex-
tension implementiert.132
CompatibilityLevel → JavaGeneratorParam
Generierungs-Parameter, der die zu erfüllende Java-Kompatibilität (level) an-
gibt.
JavaPackageNameTemplate → GeneratorParamPackageNameTemplate
Die Vorlage zur Generierung der Paketnamen für ein Java-SDK, beispielswei-
se „com.telekom.api.{service}“.
JavaSDKCompatibilityLevel
Enumeration der möglichen Java-SDK Kompatibilitätsebenen, z.B. Java 1.4
(OneFour=4), Java 1.5 (OneFive=5) oder Java 6.0 (Six=6).
132
org.generationrest.framework.extensions.generation.java.JavaSDKGeneratorExtension

74
Weitere Unterpakete
Während der prototypischen Realisierung des Frameworks wurden noch keine wei-
teren Unterpakete definiert. Allerdings ist vorgesehen, je Zielsprache ein Unterpaket
zu bilden.
4.1.5 Paket sdk
Das Paket sdk setzt die Modellierung der Zielsprachen, eine der Vorgaben des neuen
Lösungsansatzes um.
Basisklassen der Modellierung befinden sich im Unterpaket general:
Generatable
Das Basis-Interface aller Generierungs-Artefakte. Ein Generierungs-Artefakt
wird dadurch gekennzeichnet, dass es generierbaren Inhalt (content) besitzt.
File → Generatable
Eine Datei ist ein Generierungs-Artefakt mit Dateipfad (path). Der Pfad ist re-
lativ zu einem konfigurierten Ausgabeverzeichnis eines Generators.
Unterpaket java
Das Unterpaket java enthält im Prototyp 27 Modellklassen zur Abbildung der Struk-
tur des Java-SDKs. Die Modellierung und die Xtend 2.0 – Implementierung des Ver-
haltens der Modellklassen orientiert sich an der vorhandenen Struktur des Java-
SDKs.
Alle Modellklassen vorzustellen, würde den Rahmen des Kapitels überschreiten, al-
lerdings werden im Folgenden einige Modellierungsaspekte des java-Unterpakets
dargestellt.
Rolle der JavaModule-Modellklasse
Die JavaModule-Modellklasse reduziert Redundanzen in den bisherigen Code-
Templates erheblich, indem die Gemeinsamkeiten aller Klassen und Interfaces des
Java-SDKs abstrahiert werden und ein allgemeines M2T-Template für Java-
Quellcode definiert wird.
JavaModule ist vom Typ File, d.h. der generierte Inhalt wird in Dateien überführt.
Durch das Überschreiben der getPath-Methode wird der Pfad einer Java-Quelldatei
durch den Paketnamen (package) bestimmt, der wiederum von den Unterklassen
überschrieben wird.
Weiterhin enthält ein JavaModule eine Liste von Methoden (methods) und Feldern
(fields). Die konkrete Aufzählung wird in den Unterklassen überschrieben und richtet
sich nach dem jeweiligen SDK-Bestandteil.

75
Das Text-Template der JavaModule-Modellklasse kann den Inhalt eines Moduls gene-
rieren, da z.B. alle Methoden von JavaMethod erben und dort die notwendigen In-
formationen zur Generierung zur Verfügung stehen.
Unterklassen von JavaModule sind beispielsweise Java-Datenklassen (DataClass), Ser-
vice-Interfaces (ServiceInterface) und –Implementierungen (ServiceImplementation).
Abstraktion von Typen
Das Interface TypedElement kennzeichnet ein typisiertes Java-Element, z.B. ein Feld
oder eine Methode. Zur Abstraktion der verwendeten Typen stehen drei Modellklas-
sen zur Verfügung. Zum einen elementare Typen (JavaElementaryType), beispielsweise
int oder boolean. Darüber hinaus werden Typen aus der JVM (JavaFrameworkType)
mithilfe des Paketnamens (package) gekennzeichnet. Typen aus dem SDK werden als
JavaSdkType abstrahiert, die das jeweilige JavaModule über die Referenz module refe-
renzieren. Außerdem existiert der Typ JavaCollectionType, welcher eine Sammlung
(Array, Liste, …) von Elementen des jeweils referenzierten JavaTypes darstellt.
Abstraktion der Abbildung von REST-Elementen
Im Java-SDK existieren Datenklassen (DataClass) zur Abbildung unterschiedlicher
REST-Elemente. Die Datenklassen sind dabei jeweils gleich aufgebaut: sie enthalten
private Felder, sowie Getter- und Setter-Methoden zum Abfragen und Setzen dieser
Felder. Darüber hinaus enthalten Datenklassen Methoden zur Serialisierung und De-
serialisierung in das JSON-Format.
Jede Datenklasse enthält ein DataMapping<D> - Element, welches eine Referenz
(mappedElement) auf das abzubildende REST-Element (vom Typ D) enthält. Durch
die Modellierung dieses Elements wird ermöglicht, dass für alle Datenklassen nur
ein Template implementiert werden muss.
Im java-Paket existieren die folgenden Modellelemente:
• DataMappingMethodResponse → DataMapping<RestMethod>
Abbildung des Rückgabetyps einer REST-Methode
• DataMappingRestDataType → DataMapping<RestDataType>
Abbildung eines strukturierten REST-Datentyps
• DataMappingRestStructuredField → DataMapping<RestStructuredField>
Abbildung eines strukturierten REST-Feldes
Es ist anzunehmen, dass während der Realisierung des gesamten Frameworks noch
Modellklassen zum Paket java hinzugefügt werden.

76
Weitere Unterpakete
Während der prototypischen Realisierung des Frameworks wurden noch keine wei-
teren Unterpakete definiert. Allerdings ist vorgesehen, je Zielsprache ein Unterpaket
zu bilden.
4.2 Realisierungsmöglichkeiten funktionaler Erweiterungen
Das derzeitige Telekom-Framework enthält keine Abbildung von Elementen der
Zielsprachen – das Service-Modell wird direkt in Code der Zielsprachen umgewan-
delt. Die Einführung der Modellierung der Zielsprachen-Artefakte im neuen Genera-
tionREST-Framework hingegen strukturiert die Zielsprachen-Artefakte und macht
ihre Eigenschaften deutlich. Es ergibt sich allerdings die Fragestellung, wie die Attri-
but-Werte und referenzierte Elemente aus dem REST Service-Modell ermittelt wer-
den können.
Zur Lösung dieser Fragestellung bieten sich in der Regel eine Modell zu Modell
(M2M) – Transformation an: Die Zielsprachen-Elemente werden in einer Transforma-
tion erstellt und ihre Attribut-Werte und referenzierten Elemente innerhalb dieser
Transformation aus dem Service-Modell ermittelt. Ein großer Nachteil an M2M-
Transformationen ist jedoch die Trennung des Mechanismus zur Ermittlung von At-
tribut-Werten & Referenzen und dem jeweiligen Modell-Element. Dieser Nachteil
kann in Teilen umgangen werden, indem die Zielsprachen-Elemente selbst die Er-
mittlung anhand vorgegebener Ursprungselemente vornehmen.
Für die Implementierung einer solchen Ermittlung durch die Zielsprachenelemente
stehen mehrere Möglichkeiten zur Verfügung, die nachfolgend analysiert werden:
Änderung des generierten EMF-Codes
Die auf Basis der Ecore-Modellelemente generierten EMF Java-Klassen ermöglichen
eine Änderung aller Methodenkörper. Durch das Entfernen des @generated – Tags
wird der geänderte Code bei weiteren EMF-Generierungsläufen beibehalten. Aller-
dings muss so der gesamte generierte EMF-Code unter Versionsverwaltung gestellt
werden, um die Änderungen der Methodenkörper beizubehalten.
Da der EMF Code-Generator bei Änderungen am Metamodell das Entfernen von
überflüssigem Code in den generierten EMF Java-Klassen nicht unterstützt, entste-
hen erhöhte Aufwände bei der Pflege des Metamodells, da der generierte Code ma-
nuell angepasst werden muss.
Außerdem müssten bei der Verwendung von Xtend 2.0 für die Implementierung des
geänderten Verhaltens an zwei Stellen Code gepflegt werden: Einmal der Aufruf ei-
ner Xtend 2.0-Methode in den EMF-Klassen und an einer anderen Stelle die Imple-
mentierung der Berechnung selbst.

77
Nutzung von EMF-Annotationen
Das EMF ermöglicht die Spezifizierung von Programmcode in Metamodell-
Annotationen.133
Dies ermöglicht die Versionierung der Implementierung von Mo-
dellklassen-Verhalten zusammen mit dem Modell – die generierten EMF-Klassen
müssten dabei nicht versioniert oder Teile davon manuell gepflegt werden.
Allerdings unterstützt das EMF lediglich die Spezifizierung von Programmcode für
modellierte EMF-Methoden und nicht für Java-Getter und -Setter. Daher müsste die
Überschreibung von Gettern und Settern dennoch über Änderungen an generierten
EMF-Code stattfinden und der vorgenannte Vorteil würde entfallen.
Darüber hinaus gibt es keine IDE-Unterstützung für die Spezifizierung von Pro-
grammcode in Metamodell-Annotationen, sowie das Erfassen von Import-
Anweisungen.
Ableitung von generierten EMF-Klassen
Die Implementierung von aus generierten EMF-Klassen abgeleiteten Java-Klassen
und die Überschreibung von Verhalten in diesen Klassen ist eine weitere Möglich-
keit, Verhalten von Metamodell-Klassen zu spezifizieren.
Allerdings müssten alle generierten EMF-Klassen eines Pakets abgeleitet werden, um
die Vererbungshierarchie korrekt abzubilden. Daher würde bei diesem Vorgehen
erheblicher Implementierungsaufwand entstehen.
Verwendung von aspektorientierter Programmierung (AOP)
Aspektorientierte Programmierung stellt eine weitere Möglichkeit dar, Verhalten von
Metamodell-Klassen zu implementieren. Dies geschieht in der Regel in zwei Schrit-
ten: zuerst wird das neue Verhalten implementiert, danach wird die verwendete
Technologie angewiesen, die neue Implementierung anstatt der Implementierung
der Metamodell-Klassen zu verwenden.
Die Anpassung von Verhalten von Metamodell-Klassen über aspektorientierte Pro-
grammierung bietet den Vorteil der Trennung zwischen implementiertem Verhalten
und den überschriebenen Metamodell-Klassen. Diese Trennung führt allerdings auch
zu einer verschlechterten Nachvollziehbarkeit des Verhaltens und dadurch einer
teilweisen Erschwerung der Fehlersuche. Außerdem ist die Konfiguration der Tech-
nologien teilweise relativ komplex.
133
(Steinberg, et al., 2008 S. 141)

78
Untersuchte Technologien zur Umsetzung dieser Aspektorientierung sind:
Object Teams
Object Teams134
ist eine Erweiterung der Java-Programmiersprache zur Unterstüt-
zung rollenbasierter und aspektorientierter Programmierung. Die Weiterentwick-
lung geschieht hauptsächlich durch die TU Berlin, Fraunhofer FIRST und eine große
Anzahl an Studien- und Abschlussarbeiten135
.
Object Teams ist eine durchaus funktionsreiche und anwendbare Technologie. Aller-
dings ist die Grundkonzeption und Anwendung der Technologie relativ komplex.
Außerdem ist nicht zu erkennen, inwieweit die Technologie außerhalb des universi-
tären Umfelds in Praxi - beispielsweise bei großen Softwarehäusern - Anwendung
ﬁndet. Darüber hinaus zeigt eine Beispielanwendung eine relativ hohe Komplexität
im Zusammenspiel mit anderen Bestandteilen des EMF.136
Aus diesen Gründen wird Object Teams in GenerationREST nicht verwendet.
Google Guice
Google Guice137
ist ein Dependency Injection – Framework mit AOP-Funktionalität.
Da die zur Implementierung von Verhalten von Metamodell-Klassen eingesetzte
Technologie Xtend 2.0 Google Guice als DI-Framework verwendet, ist es nahelie-
gend, Google Guice auch zur aspektorientierten Implementierung von Verhalten von
Metamodell-Klassen zu verwenden.
Allerdings kann Google Guice nur die Klassen aspektorientiert erweitern, die vom
Framework instanziiert werden. Im Regelfall wäre davon auszugehen, dass das
Xtext-Framework, welches für das Laden des Service-Modells und damit der Instan-
ziierung der Metamodell-Klassen zuständig ist, diese Instanziierung über Google
Guice vornimmt und damit auch die aspektorientierte Erweiterung des Verhaltens
möglich ist.
Nach einer intensiven Prüfung stellte sich allerdings heraus, dass die entscheidende
Anweisung an die EMF-Factory zur Erzeugung einer Metamodell-Klasse nicht vom
Google Guice – Framework erfolgt.
Daher kann entgegen der Erwartung Google Guice nicht für diese Aufgabenstellung
angewendet werden.
134
(Herrmann, 2011)
135
Vornehmlich der TU Berlin: (Technische Universität Berlin, 2011)
136
Anwendung von Object Teams zur aspektorientierten Anpassung von EMF-Editoren: (Böttge, 2009)
137
(Google Inc., 2011B)

79
AspectJ
AspectJ138
ist ein Framework zur Erweiterung von Java um aspektorientierte Pro-
grammierung. Hauptunterstützer des Projekts sind IBM, SpringSource, die Universi-
ty of British Columbia, sowie Oracle (vormals BEA Systems Inc.).
AspectJ unterstützt die Konfiguration und Implementierung von Aspekten sowohl
über eine eigene AspectJ-Sprache, als auch über Java-Annotationen. Gerade die Im-
plementierung von Aspekten über herkömmlichen Java-Code vereinfacht den Um-
gang mit der Technologie erheblich.
Aufgrund der Zugänglichkeit, Leistungsfähigkeit und der Bewährung der Technolo-
gie in Praxi wird im GenerationREST-Frameworks AspectJ verwendet.
4.3 Umsetzung der funktionalen Erweiterungen in GenerationREST
Im GenerationREST-Framework wird ein hybrider Ansatz zwischen Transformation
und aspektorientierter Implementierung von Verhaltensänderungen realisiert: Die
generate()-Methode der Code-Generatoren stellt den Startpunkt einer eingeschränk-
ten M2M-Transformation dar. Anhand des Ausgangsmodells und der Generations-
Konfiguration werden die Modellklassen der Bestandteile eines SDKs instanziiert
und über die files-Auflistung bereitgestellt. Allerdings werden nur die Attribute und
Referenzen initialisiert, die ein Metamodell-Element zwingend benötigt, um daraus
die restlichen modellierten Attribute und Referenzen herzuleiten. Diese Herleitung
geschieht durch per Aspektorientierung überschriebene Getter-Methoden zur Lauf-
zeit.
Beispielsweise werden durch den Code-Generator Datenklassen (DataClass) für alle
Datentypen, Methoden-Rückgabewerte und strukturierte REST-Felder instanziiert.
Die Instanziierung speichert das jeweilige abzubildende REST-Element in der Daten-
klasse. Alle anderen Eigenschaften dieser Datenklasse, wie Name, Sichtbarkeit, ent-
haltene Methoden und Felder werden zur Laufzeit bei Abruf der Getter-Methoden
aus dem REST-Element durch eine per Aspektorientierung aufgerufene Xtend 2.0
Methode berechnet.
Implementierung des AspectJ-Aspekts ImplementedByExtensionMethodAspect
139
Der AspectJ-Aspekt ImplementedByExtensionMethodAspect prüft bei jedem Auf-
ruf einer Metamodell-Methode zur Laufzeit, ob eine bestimmte Xtend 2.0 Klasse in-
nerhalb eines entsprechenden Framework-Pakets existiert, die zur Überschreibung
von Verhalten definiert wurde.
138
(The Eclipse Foundation, 2011C)
139
Paket org.generationrest.metamodel.aspects

80
Diese Prüfung vergleicht die Klassenhierarchie, den Klassen- und den Methodenna-
men auf Übereinstimmung, sowie die Typ-Übereinstimmung zwischen dem ersten
Parameter der Ziel-Methode und der Metamodell-Klasse.140
Um das Laufzeitverhalten zu verbessern, werden alle Überprüfungsergebnisse zwi-
schengespeichert. Außerdem ermöglicht eine integrierte Typumwandlung, die Xtend
2.0 „Rich String“-Funktion auch zur Implementierung von Methoden zu verwenden,
die java.lang.String zurückgeben.
Bewertung und Ausblick
Der Aspekt ImplementedByExtensionMethodAspect ermöglicht die Veränderung
von Metamodellklassen-Verhalten durch Xtend 2.0 – Extensions.
Das Besondere daran ist, dass dies ohne spezielle Konfiguration ermöglicht wird:
Durch das Vorhandensein einer Methode in einer Klasse, die bestimmte Konventio-
nen erfüllt, wird diese Methode automatisch anstatt der Metamodell-Methode ver-
wendet. Dies ist ein großer Vorteil gegenüber herkömmlichen Ansätzen.
Derzeit ist das Extension-Paket im Quellcode konfiguriert. Um den Lösungsansatz
„Anpassbarkeit und Erweiterbarkeit des Frameworks“ umzusetzen, wird die Konfi-
guration, welche Pakete nach Extension-Methoden durchzusuchen sind, externali-
siert, sodass auch Erweiterungen durch Dritte an GenerationREST möglichst einfach
möglich werden.
Erweiterung um Hook-Mechanismus
Darüber hinaus ist angedacht, nicht nur eine Überschreibung von Verhalten zu er-
möglichen, sondern auch eine Veränderung. Hierfür soll ein Hook-Mechanismus
implementiert werden, der das Ergebnis einer aufgerufenen Methode an eine andere
Extension-Methode weiterleitet und somit die nachträgliche Veränderung von ande-
ren Extension-Methoden ermöglicht.
Insgesamt ist zu hoffen, dass durch den gewählten hybriden, aspektorientierten Me-
chanismus eine hohe Anpassbarkeit des Frameworks mit niedrigem Implementie-
rungsaufwand erreicht werden kann.
4.4 Grammatiken
Um den Lösungsansatz „Modelldefinition über textuelle DSL“ umzusetzen, wurden
zwei Xtext 2.0 – Grammatiken für die Beschreibung des Service-Modells, sowie der
Generations-Konfiguration definiert. Bei der Konzipierung und Implementierung der
Grammatik wurden eine intuitive Erfassbarkeit und möglichst geringer Aufwand bei
der Definition eines REST-Services als Leitlinien verfolgt.
140
Grafische Darstellung des Mechanismus: Siehe Anhang 2

81
Eine graﬁsche Übersicht der Grammatik kann über die Xtext 2.0 – Ansicht „Xtext
Syntax Graph“ abgerufen werden:
Abbildung 20 - "Xtext Syntax Graph" (Ausschnitt)141
4.4.1 Service-Grammatik
Wurzelelement der Grammatik ist ein benanntes Provider-Element. Hiernach folgt
die Deklaration von Typen, Vorlagen, Endpunkten und Methoden, wie in den fol-
genden Abschnitten dargestellt.
Typ-Deklaration
Eine beispielhafte Deklaration fast aller möglichen Service-Typen lautet beispielhaft
wie folgt:
Types {
DGString String (charset: "utf-8")
DGNumber Numeric (signed int16)
DGBool Boolean ("1", "0")
DGFile File
Environment Enum DGString {
production : "production"
sandbox : "sandbox"
mock : "mock"
}
DeveloperGardenStatus {
DGString statusCode
DGString statusMessage
}
}
Abbildung 21 - Typ-Deklaration (Beispiel)142
Die Deklaration hat dabei folgende Syntax:
<Typname> <Typ> [<Optionen>]
141
Eigene Darstellung (Datei: ServiceDsl.xtext im Paket org.generationrest.dsl)
142
Eigene Darstellung aus developergarden.servicedsl

82
Optionen sind fakultativ, je nach Typ unterschiedlich und folgen intuitiv dem REST
Service-Modell.
Vorlagen-Definition
Eine Definition von Methoden-Vorlagen lautet beispielhaft wie folgt:
| /{Environment : environment} => TemplateMethod DGMethod {
headers {
DGString Accept "application/json"
DGString "User-Agent" "Telekom Java SDK/4.0"
DGString Authorization
}
responseBefore {
DeveloperGardenStatus status
}
}
}
Abbildung 22 - Vorlagen-Definition (Beispiel)143
Die erste Zeile folgt dem Muster:
<Rest-Pfadvorlage> => TemplateMethod <Vorlagen-Name> { <Details> }
Die Rest-Pfadvorlage folgt dem Muster:
[<Pfadelemente vor Vorlage>] | [<Pfadelemente nach Vorlage>]
Die Syntax der Pfadelemente wird in der Beschreibung des Service-Modells näher
erläutert.
Die Definition der Bestandteile einer Vorlage, also HTTP Kopfdaten (headers), Para-
meter (parametersAfter, parametersBefore) und Rückgabewerte (responseAfter, respon-
seBefore) entspricht der gleichen Syntax, wie die der Methoden-Deklaration.
Endpunkt-Deklaration
Eine Endpunkt-Deklaration lautet beispielhaft wie folgt:
Endpoint odg "https://gateway.developer.telekom.com" {
voiceCall
conferenceCall
autoScout24
ipLocation
quota
sendSms
sendMms
smsValidation
}
Abbildung 23 - Endpunkt-Deklaration (Beispiel)144
143

83
Die Syntax ist intuitiv:
Endpoint <Name> "<URL>" { <Liste von Services> }
Service- und Methoden-Deklaration
Eine Service- und Methoden-Deklaration lautet beispielhaft wie folgt:
/rest-v1/tokens/odg => Service secureTokenService {
GET => Method getToken {
authorization usernamePassword
headers {
DGString Accept "application/json"
DGString "User-Agent" "Telekom Java SDK/4.0"
}
response {
DGString tokenFormat
DGString tokenEncoding
DGString token
}
}
}
Abbildung 24 - Service- und Methoden-Deklaration (Beispiel)145
Die Syntax der Service-Deklaration lautet:
[<Ressourcen-Pfad>] => Service <Service-Name> { <Methoden und Typen des Services> }
Der Ressourcen-Pfad besteht aus einer Verkettung von statischen und dynamischen
Bestandteilen.
Statische Bestandteile werden wie folgt angegeben:
/<Name>
Dynamische Bestandteile können typisiert sein und werden wie folgt angegeben:
/{<Name> [: <Typ>]}
Eine Service-Deklaration folgt der folgenden Syntax:
<HTTP-Verb> [<Ressourcen-Pfad>] => Method <Name> { <Details> }
Unter Details fallen die Deﬁnition des Authentiﬁzierungs-Mechanismus, sowie die
Angabe von HTTP-Header, Parameter und Rückgabewerten.
144
145

84
Der optionale Authentifizierungsmechanismus HTTP Basic, d.h. Authentifizierung
über Benutzernamen und Passwort kann derzeit nur wie folgt angegeben werden:
authorization usernamePassword
Die Einleitung der weiteren Details beginnt mit dem jeweiligen Schlüsselwort für
HTTP-Header (headers), Parameter (parameters) und Rückgabewerte (response) und
beinhaltet die Definition von REST-Feldern. Diese REST-Felder können bei Parame-
tern und Rückgabewerten sowohl typisiert, als auch strukturiert sein. Die Liste der
HTTP-Header unterstützt nur typisierte Felder.
Typisierte REST-Felder werden mit einer der folgenden Syntaxen deklariert:
<Typ> <Name>
<Typ>[] <Name>
<Typ> <Name>?
<Typ>[] <Name>?
Das „[]“ hinter der Typ-Definition kennzeichnet ein Datenfeld (Array), das „?“ hin-
ter dem Feld-Namen ein optionales Feld.
Strukturierte REST-Felder werden mit einer der folgenden Syntaxen deklariert:
<Name> { <Unterfelder> }
<Name>[] { <Unterfelder> }
<Name>? { <Unterfelder> }
<Name>[]? { <Unterfelder> }
Die Semantik von „[]“ und „?“ bleibt unverändert, lediglich die Position des Kenn-
zeichners ändert sich.
4.4.2 Konfigurations-Grammatik
Eine Generations-Konfiguration besteht aus Parametern und Generatoren. Eine bei-
spielhafte Generations-Konfiguration lautet wie folgt:
import "developergarden.servicedsl"
Configuration {
parameters {
general {
endpoint odg {
sendSms sendMms smsValidation
voiceCall conferenceCall ipLocation
autoScout24 speechToText quota
}
endpoint sts {
secureTokenService
}
}
java {
JavaPackageNameTemplate "com.telekom.api.{service}"

85
}
java_de {
ref java, general
language "de"
outlet "c:datenruntime-EclipseApplicationservicedsl.testoutput"
}
}
generators {
JAVA developergarden_sdk_java_de {
ref java_de
}
}
}
Abbildung 25 - Generations-Konfiguration (Beispiel)146
Einer Konfiguration stehen ein oder mehrere Import-Direktiven vor. Diese Direkti-
ven ermöglichen die Bezugnahme der Generations-Konfiguration auf ein oder meh-
rere Service-Modelle.
Die Syntax einer Import-Direktive lautet wie folgt:
import "<Relativer Pfad zur importierenden Datei>"
Hiernach folgt die Konfiguration der Parameter und Generatoren. Die Syntax lautet:
Configuration { parameters { <Parameter> } generators { <Generatoren> }
Die Auflistung <Parameter> enthält Behältnisse für Generierungs-Parameter. Die Syn-
tax für ein Behältnis lautet:
<Name des Behältnisses> { <Enthaltene Parameter und Verweise > }
Für jeden möglichen Parameter ist eine Syntax definiert, die meist mit einem Schlüs-
selwort beginnt (z.B. language für die Konfiguration der Sprache) und danach den
Wert des Parameters erwartet (z.B. eine Zeichenkette "de" für „Deutsch“).
Eine besondere Rolle kommt der Konfiguration der zu generierenden Services und
Endpunkte zu. Diese Syntax lautet wie folgt:
endpoint <Endpunkt-Name> { <Zu generierende Services des Endpunkts> }
146
Eigene Darstellung, Datei: developergarden.generationdsl

86
Die Auto-Vervollständigung der Liste der zu generierenden Services wurde durch
eine selbstdeﬁnierte Methode147
angepasst, sodass der generierte Xtend-Editor für die
Liste der zu generierenden Services nur die Services zur Auto-Vervollständigung
anbietet, die auch tatsächlich laut dem referenzierten Service-Modell an dem ange-
gebenen Endpunkt zur Verfügung stehen.148
Verlinkungen zu anderen Parameter-Behältnissen werden wie folgt deklariert:
ref <Name des verlinkten Parameter-Behältnisses>
Die Deklaration eines Generators lautet wie folgt:
<Schlüsselwort> <Name des Generators> { <Parameter> }
Das Schlüsselwort gibt die Art des zu instanziierenden Generators an, z.B. JAVA für
einen Java-SDK – Generator. Die Syntax der Parameter wurde bereits erläutert.
4.5 Code-Generatoren
Um den Lösungsansatz „Modellierung der Zielsprachen“ umzusetzen, existieren in
GenerationREST Zielsprachen-Modellelemente, welche die Struktur der zu generie-
renden SDKs abbilden. Die Eigenschaften (d.h. Attribute und Referenzen) dieser
Zielsprachen-Modellelemente, also auch der letztendliche Programmcode, werden
aspektorientiert über Xtend 2.0 – Extensions implementiert. Dadurch ergibt sich auf
der einen Seite eine deutlich bessere Strukturierung der Code-Generierung und au-
ßerdem eine Einschränkung der Redundanzen in den Quellcode – Vorlagen.
Ein GenerationREST Code-Generator besteht daher einerseits aus einer Menge von
Modellelementen der Zielsprachen, implementiert und erweitert durch Xtend 2.0 –
Extensions, sowie einer von SDKGenerator abgeleiteten Klasse, welche auf Basis der
jeweiligen Generations-Konﬁguration festlegt, welche konkreten Zielsprachen-
Elemente in Code zu überführen sind.
Die Struktur der SDKs soll im fertiggestellten GenerationREST-Framework möglichst
gleich zu den bisherigen SDKs sein, da sich deren Struktur in Praxi bewährt hat und
viele Problemfelder149
adressiert. Dies vereinfacht auch die Übernahme von Teilen
der bisherigen Code-Templates. Die restlichen Bestandteile der derzeitigen Code-
Generatoren werden in Hinblick auf den neuen, universalen Ansatz angepasst.
147
Methode scope_GeneratorParamGenerationSelection_servicesOfEndpoint(…) der Klasse
org.generationrest.dsl.scoping.GenerationDslScopeProvider
148
Mechanismus-Beschreibung in Sektion „Declarative Scoping“ in (Behrens, 2011A)
149
Siehe Kapitel 3.3 (S. 46)

87
Im Prototyp wurde der Java SDK-Generator insoweit implementiert, dass mithilfe
des generierten Codes erste Aufrufe von Methoden der Developer Garden REST-API
möglich sind. Hierdurch wird exemplarisch dargestellt, wie die beschriebene Über-
nahme, Anpassung und Generalisierung von bisherigen Code-Templates möglich ist.
4.6 Dokumentations-Generator
Die Darstellung des Metamodell-Pakets documentation beschreibt das Konzept der
Abstraktion von Dokumentations-Artefakten und der Dokumentations-
Generierung.150
Im Zuge der Fertigstellung des GenerationREST-Frameworks wird die Klasse Docbo-
okDocumentationProvider abgeleitet und mithilfe der von dieser Klasse bereitgestellten
Funktionalität die konkrete Vorgehensweise zur Ermittlung von Dokumentation aus
dem Telekom Docbook Content-Repository implementiert. Darüber hinaus werden
die Code-Generatoren um die Generierung von Code-Dokumentation erweitert, um
die ermittelte Dokumentation in die SDKs zu übernehmen.
Zudem wird ein Generator konzipiert und realisiert, welcher auf Basis einer über-
führten Docbook-Vorlage die Developer Garden Benutzerdokumentation generiert.
Aufgrund der neuen Möglichkeiten von Xtend 2.0 und der verbesserten Integration
von Xtend 2.0, EMF und Java ist mit einer vereinfachten Implementierung der Do-
kumentations-Generierung zu rechnen.
4.7 Weitere Komponenten
Generations-Workflow
Der Generations-Workflow wird je nach Anwendungsgebiet und Framework-
Anpassungen teilweise erheblich differieren und sollte daher anwenderspezifisch
implementiert werden.
Zur Unterstützung dieser Implementierung wird ein Beispiel-Workflow bereitge-
stellt, der dann je nach Bedarf geändert und übernommen werden kann. Dieser
Workflow beinhaltet eine Beispiel-Komponente zum Aufruf von generate() – Metho-
den der jeweils konfigurierten GenerationREST-Generatoren.
150
Siehe Kapitel 4.1.3 (S. 75)

88
Erstellvorgang
Das bisherige Framework bildet den Erstellvorgang der jeweiligen SDKs über einen
modularisierten ANT-Workflow ab. ANT erscheint aufgrund der Erfahrungen mit
dem bisherigen Framework weiterhin als geeignetes Mittel, um auch den Erstellvor-
gang von GenerationREST-SDKs abzubilden, jedoch muss der bisherige Workflow
noch generalisiert und Telekom-Spezifika ausgelagert werden.
Im ANT-Workflow bietet sich ebenfalls ein einfacher Hook-/Extension-
Mechanismus an, um eine Anpassbarkeit des Erstellvorganges zu ermöglichen.
4.8 Test des Framework-Prototypen
In diesem Kapitel soll die bisher umgesetzte Funktionalität des Framework-
Prototyps und damit die Anwendbarkeit des Konzepts und der darauf aufbauenden
flexiblen Architektur aufgezeigt werden.
Hierfür wird auf der einen Seite das Developer Garden – Modell in das Generation-
REST-Framework überführt und ein einfacher Code-Generierungslauf gestartet.
Darüber hinaus wird die Anwendbarkeit von GenerationREST außerhalb des Deve-
loper Gardens durch die Generierung von zwei weiteren REST-
Schnittstellenadaptern gezeigt: einerseits für die Google Web Search API151
und an-
dererseits für die World Weather Online-API152
.
Überführung des Developer Garden - Modells
Die Überführung des Developer Garden Modells erfolgt über eine Xpand-
Transformation153
, welche im Workspace des bisherigen Frameworks implementiert
wurde. Diese lädt die derzeitige Version des Developer Garden Modells und über-
führt diese in eine der REST-Service – Syntax entsprechende Form.
Bemerkenswert ist die geringe Größe der Transformation (93 Zeilen Quellcode).
Implementierung der weiteren Service-Modelle
Die Google Websearch-Schnittstellenbeschreibung wurde auf Basis der bereitgestell-
ten Dokumentation154
verfasst. Die Schnittstellenbeschreibung des World Weather
Online – Services konnte mithilfe des bereitgestellten „Weather API Request Buil-
der“155
auf Basis der Antwortnachrichten schlussgefolgert werden.
151
(Google Inc., 2011A)
152
(World Weather Online, 2011)
153
generationrest.xpt im Paket com.telekom.restsdks.template.generationrest
154
(Google Inc., 2011A)
155
(World Weather Online, 2011A)

89
Einrichten und Konfigurieren des Frameworks
Da GenerationREST ein aus mehreren OSGi-Plugins bestehendes Eclipse-Feature ist,
existieren zwei getrennte Eclipse-Workspaces: Auf der einen Seite der Entwicklungs-
Workspace mit dem Quelltext des GenerationREST-Frameworks, auf der anderen
Seite der Workspace, in welchem das Feature ausgeführt und zur Generierung der
SDKs verwendet wird (Projekt-Workspace).
Innerhalb der Eclipse-Plattform existiert die Ausführungskonfiguration „Eclipse Ap-
plication“, mit der das GenerationREST-Framework getestet werden kann.
In den Einstellungen dieser Ausführungskonfiguration werden die GenerationREST-
Plugins des aktuellen Workspaces ausgewählt, die dann in der neu gestarteten Eclip-
se-Instanz zur Verfügung stehen:
Abbildung 26 - Konfiguration einer neuen GenerationREST Eclipse-Instanz156
Je nach Bedarf können weitere Konfigurationsoptionen gesetzt werden, beispielswei-
se das Verzeichnis des Projekt-Workspaces oder die Parameter der Java-VM. Auf-
grund der Komplexität der Gesamtlösung empfiehlt sich das Heraufsetzen der Größe
des Heap- und Keller-Speichers, sowie des Speicher-Limits der langlebigen Genera-
tion des automatischen Speicherbereinigers.157
156
Eigene Darstellung
157
JVM-Parameter des Projekt-Workspaces: -Xms40m -Xmx2048m -XX:MaxPermSize=2048M

90
Nach dem Start der neuen Eclipse-Instanz steht ein leerer Workspace zur Verfügung,
in welchem das neue GenerationREST-Projekt angelegt werden kann. Dieses Projekt
enthält zum einen die überführte Service-Beschreibung der Developer Garden REST-
API, sowie die Konfiguration eines Java-SDK – Generators.
Durchführung der Generierung
Die Generierung wird von MWE2-Workflows durchgeführt.
Diese Workflows bestehen aus den folgenden Komponenten und Beans:
1. org.eclipse.emf.mwe.utils.StandaloneSetup
Diese Bean ist für die Registrierung der generierten EMF-Klassen zuständig. Dies
ist für die korrekte Verarbeitung des Service- und Konfigurationsmodells uner-
lässlich.
Die Bean wird mit registerGeneratedEPackage-Anweisungen konfiguriert, die für
alle Pakete des GenerationREST-Frameworks aufgerufen werden.
2. org.eclipse.xtext.mwe.Reader
Diese Komponente lädt Service-Beschreibung und Generations-Konfiguration und
speichert Referenzen zu allen konfigurierten SDK-Generatoren in einem benann-
ten Slot.
3. org.eclipse.emf.mwe.utils.DirectoryCleaner
Leert das Ausgabe-Verzeichnis
4. org.generationrest.framework.components.SDKGeneratorComponent
Startet alle im Schritt 2 referenzierten Generatoren durch einen Aufruf der genera-
te()-Methode.
Untersuchung des Generats
Wenngleich auch nur ein Teil der konzipierten Funktionalität zur Verfügung steht,
so wurden durch den Java SDK-Generator Prototyp auf Basis des kompletten Deve-
loper Garden REST-Modells bereits 5.800 Zeilen Code generiert, was 39% der 15.000
Zeilen Code des aktuellen Java-SDKs ausmacht.158
158
Messung mit Hilfe des Tools CLOC – Count Lines of Code: (Danial, 2010)

91
Um die grundlegende Funktionsfähigkeit des generierten Codes zu zeigen, wurde
mithilfe der Testklasse SendSMS der Developer Garden SendSMS-Service zum Ver-
sand einer SMS aufgerufen. Der Aufruf beinhaltet die Anforderung eines Security
Tokens vom Telekom STS per HTTP Basic-Authentiﬁzierung und die Einbindung
des Token-Werts in die Anfrage an den Developer Garden Service.
Weiterhin wurden erfolgreiche Serviceaufrufe - eine Google-Suche nach „Berlin“
sowie die Abfrage des aktuellen Wetters für Berlin159
- mithilfe der Testklassen
GoogleSearch.java und Weather.java durchgeführt.
159
World Weather Online-Beispiel: Siehe Anhang 3

Zusammenfassung und Ausblick
92
5 Zusammenfassung und Ausblick
Der auf Basis des neuen Lösungsansatzes konzipierte Prototyp ermöglicht fast alle
grundsätzlich notwendigen Funktionen der Generierung von Java-SDKs für nahezu
beliebige REST-Schnittstellen. Darin enthalten sind die Generierung von Adapter-
Implementierungen, sowie die dafür notwendigen Datenklassen.
Diese Generierung erfolgt auf Basis eines hybriden Ansatzes zwischen Modell-zu-
Modell – Transformation und der Berechnung von Zielsprachen-Modellelement-
Eigenschaften durch aspektorientierte Programmierung zur Laufzeit. Die erkennbar
verbesserte Struktur des GenerationREST-Prototyps gegenüber dem bisherigen Tele-
kom-Framework lässt auf die tatsächliche Verbesserung von Qualität, Zugänglich-
keit, Wartbarkeit und Leistungsfähigkeit schließen, die durch das vollständige
Framework zu erwarten ist.
Während der Implementierung konnte insbesondere die enorme Leistungssteige-
rung der gesamten Modell-zu-Text Transformation beobachtet werden, die gleich-
falls vom Xtend 2.0 – Projektleiter beschrieben160
wurde. Ebenso wirkt sich die Mo-
dellierung der Zielsprachen positiv auf die Struktur und damit die Zugänglichkeit
des Frameworks aus. Darüber hinaus ist zu erwarten, dass der Hook- und Extension-
Mechanismus eine flexible, aspektorientierte Anpassung des GenerationREST-
Frameworks erlauben wird.
Fertigstellung von GenerationREST
Es besteht die Zusage der Deutschen Telekom, dass ich nach der Fertigstellung dieser
Abschlussarbeit das GenerationREST-Framework bis Anfang Dezember 2011 fertig-
stelle und dass es als Open Source – Projekt, voraussichtlich im Rahmen des Develo-
per Gardens, veröffentlicht wird.
Noch ausstehende Implementierungsarbeiten sind in folgenden Bereichen zu finden:
Hook-Mechanismus
Ein möglichst flexibler Hook-Mechanismus soll aspektorientierte Anpassungen am
Framework ermöglichen. Einige dieser Anpassungen erfolgen aufgrund von Deve-
loper Garden REST-Spezifika, die getrennt vom universellen GenerationREST-
Framework gepflegt werden.
160
Eine typische M2T-Transformation ist mit Xtend 2.0 um den Faktor 10 schneller, als mit Xpand
(Efftinge, 2011)

93
Konfiguration des Generierungs-Vorganges
Im Zuge der Realisierung weiterer Code-Templates und des gesamten Erstellvor-
gangs werden sich Erweiterungen am Konfigurations-Metamodell ergeben, um eine
flexible SDK-Erstellung zu ermöglichen.
REST-Modell
Es ist zu erwarten, dass nach intensiver Arbeit an und mit GenerationREST an eini-
gen Stellen Änderungen am REST-Modell zu erwarten sind, um bis jetzt noch nicht
bedachte Eigenheiten von REST-Schnittstellen abzubilden.
Außerdem könnte dem REST-Modell die Möglichkeit hinzugefügt werden, Verer-
bungsbeziehungen abzubilden. Hierdurch wäre z.B. die derzeitige Klassenhierarchie
der Developer Garden - SDKs (z.B.: alle Antwortnachrichten erben von Developer-
GardenResponse) abbildbar.
Beispiel-Code und Unit-Tests
Für Beispiel-Code und Unit-Tests existiert im derzeitigen Telekom-Framework ein
Metamodell mit darauf aufbauenden Code-Templates. Durch die Überführung und
Neu-Konzipierung dieser Modelle und die Implementierung einer textuellen Xtext –
DSL sind deutliche Vereinfachungen bei der Definition von Code-Beispielen und
Unit-Tests gegenüber dem Telekom-Framework zu erwarten.
Code-Templates
Die Java Code-Templates sind fertigzustellen und für die Programmiersprachen
C#/.NET und PHP zu implementieren. Weitere Programmiersprachen, die im kom-
menden Jahr hinzugefügt werden könnten, sind u.A. Ruby und Objective-C.
Generierung der Dokumentation
Zur Generierung der Dokumentation existieren im bisherigen Framework relativ
viele Vorlagen und funktionale Erweiterungen. Diese sind nach GenerationREST zu
überführen.
Besonders aufgrund der vereinfachten Verbindung zwischen Xtend 2.0, EMF und
Docbook durch die Funktionen des DocbookDocumentationProviders ist mit einer Ver-
besserung der Handhabbarkeit der Dokumentations-Generierung zu rechnen.
Erstellvorgang und Generations-Workflow
Das in Kapitel 4.7 (S. 87) dargestellte Konzept des Erstellvorgangs und des Generati-
ons-Workflows ist umzusetzen.
Kontinuierliche Integration
Zur dauerhaften Pflege und Weiterentwicklung von GenerationREST sollte wie beim
derzeitigen Telekom-Framework eine kontinuierliche Integration eingerichtet wer-
den, um Teile des Entwicklungsprozesses zu automatisieren.

94
Weitere Telekom-Spezifika
Das derzeitige Framework bietet die Möglichkeit, Fehlercodes von Developer Gar-
den APIs und deren Beschreibungen in den generierten SDKs abzubilden.
Es ist zu prüfen, ob das GenerationREST-Framework diesen Mechanismus abstrahie-
ren und generalisiert bereitstellen kann.
Flexibilisierung der Serialisierungsformate
Derzeit unterstützt das GenerationREST-Framework JSON als Serialisierungsformat,
da es von einem Großteil der vorhandenen REST-APIs unterstützt wird. Es existieren
jedoch auch REST-APIs, die andere Serialisierungsformate unterstützen, z.B. XML.
Um ein universelles Framework zu schaffen, sollten mehrere Serialisierungsformate
unterstützt werden.
5.1 Vergleich des Konzepts mit anderen Frameworks
Im Gegensatz zur Generierung von Code auf Basis von WSDL/SOAP existieren für
den Anwendungsbereich von GenerationREST relativ wenige alternative Frame-
works. Dennoch sollen einige dieser Frameworks und deren Ansätze im Folgenden
analysiert werden, um das GenerationREST-Framework im Vergleich zu diesen ein-
ordnen zu können.
Thrift
Thrift161
ist ein ursprünglich von Facebook entwickeltes Open Source - Framework
zur Deﬁnition und plattformübergreifenden Generierung von RPC-
Schnittstellenadaptern.
Thrift hat mit GenerationREST gemein, dass es auf Basis eines Modells plattform-
übergreifende Schnittstellenadapter generiert. Allerding ist die Generierung von be-
gleitender Dokumentation (z.B. Code- oder konzeptionelle Dokumentation) nicht
vorgesehen.
Größte Auffälligkeit von Thrift ist die Art, wie der Code für die Schnittstellenadapter
hinterlegt wird. Der Java-Generator besteht aus einer monolithischen, fast 4.000
Code-Zeilen umfassenden C++ Datei162
, die sowohl Generationslogik, als auch Java-
Texttemplates enthält. Es ist anzuzweifeln, dass diese Art der Code-Hinterlegung
ﬂexibel anpassbar und auf Dauer wartbar ist.
161
(The Apache Software Foundation, 2011A)
162
(Farrell, 2011)

95
RESTclient for WCF
RESTclient for WCF163
ist eine quelloffene Lösung, um .NET-Clients zur Ansprache
von mithilfe von WADL beschriebenen REST-Services zu generieren. Dabei ist die
Lösung als Prototyp-Implementierung zu sehen, die seit Anfang 2010 nicht mehr
weiterentwickelt wird und lediglich einige der mit WADL beschreibbaren Eigen-
schaften von REST-Schnittstellen unterstützt.
Ein interessanter Ansatz von RESTClient for WCF ist die Verwendung des Sys-
tem.CodeDom-Namespaces164
. Anstatt textbasierter Code-Templates werden die
.NET eigenen Funktionen zur Ausgabe von Quelltext verwendet. Hierdurch entfällt
die Notwendigkeit zur Implementierung einer Abstraktionsschicht der Zielsprache
.NET. Allerdings unterstützt der System.CodeDom-Namespace lediglich die Spra-
chen C#, JScript, C++ und Visual Basic und ist dadurch auf die .NET-Plattform be-
schränkt.
Eine ähnliche Funktion, wie System.CodeDom besteht in der Eclipse-Plattform in-
nerhalb der Java Development Tools. Hierbei können die Klassen des Java AST-
Parsers verwendet werden, um Code zu generieren.165
Dieser Mechanismus ist aller-
dings auf Java beschränkt.
HTTP4e – Eclipse Restful HTTP Client Plugin
HTTP4e ist eine kommerzielle Lösung auf Basis der Eclipse IDE, mit derer die Ent-
wicklung im Zusammenhang mit REST-Schnittstellen unterstützt wird. HTTP4e
kann Client-Code zur Ansprache einer beschriebenen REST-Methode für zahlreiche
Programmiersprachen generieren, unter anderem für Java, PHP, C# und Ruby.
Das besondere an HTTP4e ist das Aufzeigen kommerzieller Nutzungsmöglichkeiten
von Code-Generatoren, auch auf Basis von Open Source Technologie, wie Eclipse.
Allerdings ist der Umfang von HTTP4e deutlich geringer, als der von Generation-
REST.
NetBeans Web Services
Die NetBeans-IDE unterstützt die Generierung von Java und JavaScript-Client Code
für mithilfe von WADL beschriebene REST-Schnittstellen.166
Zur Unterstützung und
Demonstration werden WADL-Beschreibungen für viele geläuﬁge REST-
Schnittstellen mit der IDE ausgeliefert.167
163
(Schidler, 2010)
164
(Microsoft Corporation, 2011B)
165
(Vogel, 2011)
166
Ausführliches Tutorial: (Oracle Corporation, 2011)
167
Unter anderem Amazon, Facebook, Flickr, Google und Yahoo

96
Bemerkenswert an der REST Web Service – Unterstützung von NetBeans ist die ver-
gleichsweise einfache Verwendung, die gute Integration der Code-Generierung in
die IDE und die Vielzahl an Dokumentation. Allerdings ist die Zahl der Zielsprachen
begrenzt und einfache Anpassungsmöglichkeiten der Client-Code Templates nicht
gegeben.
REST API Code Generation
REST API Code Generation168
ist ein Open Source Projekt zur Generierung von Java
und C# - Schnittstellenadaptern auf Basis einer WADL-Beschreibung. Ähnlich, wie
bei Thrift, beﬁnden sich die Code-Templates als Zeichenketten innerhalb von Java-
Quellcode, was die Anpassbarkeit und Wartbarkeit der Lösung beeinträchtigt. Au-
ßerdem ist der Umfang des Projekts gegenüber GenerationREST deutlich geringer.
Mittlerweile wird das Projekt nicht mehr weiterentwickelt.
Vergleichende Einordnung von GenerationREST
Keiner der analysierten Frameworks bietet eine in der Art und im Umfang vergleich-
bare Lösung zur Generierung von Schnittstellenadaptern und Dokumentation, wie
GenerationREST und das vorhergehende Telekom-Framework.
Auffallend ist vor allem der häuﬁge Bezug auf die REST-Beschreibungssprache
WADL und die seltene Verwendung einer dezidierten Template-Sprache, wie bei-
spielsweise Xpand oder JET. Außerdem sind die Anpassungsmöglichkeiten der
Code-Generierung in allen Frameworks viel zu gering um das Anwendungsgebiet
der Frameworks über die jeweiligen Zielsprachen und Plattformen hinaus zu erwei-
tern.
Die Generierung von Schnittstellen-Dokumentation oder die Bereitstellung von
Code-Dokumentation wird von keinem der Frameworks adressiert.
Zusammenfassend ist festzustellen, dass es keine zu GenerationREST ähnlichen öf-
fentlich verfügbaren Lösungen gibt.
168
(Steiner, et al., 2008)

97
5.2 Zukunft von GenerationREST
Es ist zum jetzigen Zeitpunkt unklar, ob die Deutsche Telekom nach meiner Tätigkeit
für das Developer Garden Projekt, voraussichtlich ab Anfang 2012, das Framework
als Hauptnutzer vorantreiben wird, oder wieder zur manuellen Pﬂege der Developer
Garden SDKs zurückkehrt.
Dies hat vor allem drei Ursachen: Einerseits gibt es vom Management Bedenken auf-
grund der hohen Komplexität und den damit verbundenen Aufwänden des modell-
getriebenen Ansatzes. Auf der anderen Seite fehlt derzeit das Wissen im Team zu
den eingesetzten Technologien, sodass für den Fortbestand von GenerationREST zu
hoffen ist, dass es mir gelingt, alle Kenntnisse an das Team weiterzugeben, um die
Weiterentwicklung des Frameworks durch jemand anderen sicherzustellen. Und zu-
letzt wurden auch viele Vorteile des modellgetriebenen Ansatzes, vor allem die
mehrsprachige Bereitstellung von SDKs, von einigen Teammitgliedern als nicht not-
wendig betrachtet.
Allerdings kann aufgrund der universellen Anwendbarkeit des Frameworks die An-
nahme getroffen werden, dass sich weitere Unternehmen, Institutionen oder Privat-
personen in einem offenen Entwicklungsprozess ﬁnden, um das Framework zu nut-
zen und weiter zu entwickeln.

Fazit
98
6 Fazit
Aus einem erarbeiteten, tiefen Technologie-Verständnis und auf Basis der umfang-
reichen Analyse des Seit Ende 2009 von mir entwickelten Frameworks wurde in der
vorliegenden Arbeit das GenerationREST-Framework konzipiert und prototypisch
realisiert.
Das Framework enthält mehrere Metamodelle zur Beschreibung allgemeiner und
konkreter Eigenschaften von REST-Schnittstellen und den dafür zu generierenden
Schnittstellenadaptern. Die Modell-Beschreibung kann über eine kompakte und
leicht zugängliche textuelle DSL vorgenommen werden. Weiterhin ist das Frame-
work durch seine Architektur ﬂexibel an spezielle Anforderungen anpassbar. Gene-
rationREST setzt auf aktuelle Technologien und löst durch neue Ansätze viele Prob-
leme des vorhandenen Frameworks. Darüber hinaus ist GenerationREST innovativ,
da keine vergleichbaren, öffentlich verfügbaren Lösungen existieren.
Die Bereitschaft der Telekom, das Framework zu nutzen und nach Abschluss der
Masterarbeit von mir fertigstellen zu lassen, unterstreicht die Praxistauglichkeit des
Konzepts. Die allgemeine Anwendbarkeit des entwickelten Frameworks und die
Veröffentlichung als Open Source-Produkt im Developer Garden lassen annehmen,
dass das Framework neben der Telekom weitere Nutzer und Entwickler ﬁnden wird.
Die Reichweite des Developer Gardens und die dort bereitgestellten Kollaborations-
möglichkeiten unterstützen diese Annahme zusätzlich.
Alles in allem ist das Ergebnis dieser Arbeit mehr als zufriedenstellend, da sowohl
konzeptionelle, technologische als auch wirtschaftliche Problemstellungen detailliert
analysiert und fundierte Lösungsansätze erarbeitet und realisiert wurden.

Anhang 1: Darstellung der Zusammenhänge zwischen REST- und SOAP-Elementen
v
Anhang 1: Darstellung der Zusammenhänge zwischen REST- und SOAP-Elementen
<methods name="newCall" return="newCallReturn">
<parameters xsi:type="service:SimpleField" name="aNumber"/>
<parameters xsi:type="service:SimpleField" name="bNumber"/>
<parameters xsi:type="service:SimpleField" name="privacyA"/>
<parameters xsi:type="service:SimpleField" name="privacyB"/>
<parameters xsi:type="service:SimpleField" name="expiration"/>
<parameters xsi:type="service:SimpleField" name="maxDuration"/>
<parameters xsi:type="service:SimpleField" name="greeter"/>
<parameters xsi:type="service:SimpleField" name="account" optional="true"/>
</methods>
<methods xsi:type="service:RestMethod" name="newCall" return="newCallRestReturn" correspondingMethods="newCall newCallSequenced"
httpMethod="POST">
<parameters xsi:type="service:SimpleFieldRest" name="anumber" correspondingField="aNumber"/>
<parameters xsi:type="service:SimpleFieldRest" name="bnumber" correspondingField="bNumber"/>
<parameters xsi:type="service:SimpleField" name="expiration" optional="true"/>
<parameters xsi:type="service:SimpleFieldRest" name="maxduration" optional="true" correspondingField="maxDuration"/>
<parameters xsi:type="service:SimpleFieldRest" name="maxwait" optional="true" correspondingField="maxWait"/>
<parameters xsi:type="service:SimpleFieldRest" name="aprivacy" optional="true" correspondingField="privacyA"/>
<parameters xsi:type="service:SimpleFieldRest" name="bprivacy" optional="true" correspondingField="privacyB"/>
<parameters xsi:type="service:SimpleField" name="account" optional="true"/>
<restResources name="environment" dynamic="true"/>
<restResources name="call"/>
</methods>

Anhang 2: Beispiel zum Aspekt ImplementedByExtensionMethodAspect
vi
Anhang 2: Beispiel zum Aspekt ImplementedByExtensionMethodAspect

Anhang 3: World Weather Online-Beispiel
vii
Service-Beschreibung (Auszug):
Provider worldweather {
Types {
WString String (charset:"UTF-8")
}
Endpoint weather "http://free.worldweatheronline.com/feed/weather.ashx" {
weatherService
}
Service weatherService {
types {
ConditionData {
WString humidity
WString temp_C
ValueData[] weatherDesc
<Weitere Wetterdaten>
}
ValueData {
WString value
}
Request {
WString query
WString type
}
Weather {
WString date
WString tempMaxC
WString tempMinC
ValueData[] weatherDesc
<Weitere Wetterdaten>
}
}
GET => Method getWeather {
parameters {
WString q
WString format
WString num_of_days
WString key
}
response {
data {
ConditionData[] current_condition
Request[] request
Weather[] weather
}
}
}
}
}

viii
Programmcode für Abruf der Wettervorhersage
169
import com.worldweatheronline.api.weatherservice.data.GetWeatherData;
import com.worldweatheronline.api.weatherservice.data.GetWeatherResponse;
import com.worldweatheronline.api.weatherservice.data.Weather;
import com.worldweatheronline.api.weatherservice.service.impl.WeatherServiceServiceImpl;
public class WeatherQuery {
public static final String CITY = "Berlin";
public static void main(String[] args) {
long start = System.currentTimeMillis();
WeatherServiceServiceImpl weatherService = new WeatherServiceServiceImpl();
GetWeatherResponse response = weatherService.getWeather(CITY, "json", "3", "<API-Schlüssel>");
GetWeatherData data = response.getData();
System.out.println("Weather forecast for " + CITY);
System.out.println("====================================================");
Weather[] weathers = data.getWeather();
for(Weather w : weathers) {
System.out.println("Date : " + w.getDate());
System.out.println("Condition : " + w.getWeatherDesc()[0].getValue());
System.out.println("Temperature : " + w.getTempMinC() + "°C up to " + w.getTempMaxC() + "°C");
System.out.println("Wind : " + w.getWindspeedKmph() + " kmph");
System.out.println("====================================================");
}
long stop = System.currentTimeMillis();
System.out.println("Processing time: " + (stop-start) + " ms");
}
}
169
Der API-Schlüssel ist nach einer kostenlosen Registrierung verfügbar

ix
Ausgabe
Weather forecast for Berlin
====================================================
Date : 2011-09-03
Condition : Sunny
Temperature : 13°C up to 28°C
Wind : 13 kmph
====================================================
Date : 2011-09-04
Condition : Sunny
Wind : 18 kmph
====================================================
Date : 2011-09-05
Condition : Light rain
Wind : 20 kmph
====================================================
Processing time: 202 ms

Anhang 4: Vereinfachungspotentiale in AutoScout24-Nachrichten
x
Anhang 4: Vereinfachungspotentiale in AutoScout24-Nachrichten
Beispiel 1: Formatierung der Rückgabewerte
Aktuell:
"response": {
"vehicles": {
"vehicle" : [
{ Inserat 1 },
{ Inserat 2 },
{ Inserat n }
]
}
}
Optimierung:
"response": {
"vehicles" : [
{ Inserat 1 },
{ Inserat 2 },
{ Inserat n }
]
}
Beispiel 2: Rückgabe der Bilder zu einem Inserat
Aktuell:
"media": {
"images": {
"image" : [
{ Bild 1 },
{ Bild 2 },
{ Bild n }
]
}
}
Optimierung:
"images": [
{ Bild 1 },
{ Bild 2 },
{ Bild n }
]
Da es keine anderen media-Objekte, außer Bilder (images) gibt, könnten hier sogar
zwei Hierarchieebenen eingespart werden.

Literaturverzeichnis
xi
Balzert, Helmut. 2009. Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements
Engineering. 3. Auflage. Heidelberg : Spektrum Akademischer Verlag, 2009. 978-3-
8274-1705-3.
Behrens, Heiko. 2011. Xtext - Main Features. eclipse.org. [Online] 2011. [Zitat vom: 29.
August 2011.] http://www.eclipse.org/Xtext/#FeatureList.
—. 2011A. Xtext - Reference Documentation - Runtime Concepts - Scoping. eclipse.org.
[Online] 2011A. [Zitat vom: 29. August 2011.]
http://www.eclipse.org/Xtext/documentation/2_0_0/080-scoping.php.
—. 2011B. Xtext Reference Documentation - Runtime Concepts - Linking. eclipse.org.
[Online] 2011B. [Zitat vom: 29. August 2011.]
http://www.eclipse.org/Xtext/documentation/2_0_0/070-linking.php.
Beltran, Juan Carlos Flores, et al. 2007. Modellgetriebene Softwareentwicklung. MDA
und MDSD in der Praxis. [Hrsg.] Jens Trompeter und Georg Pietrek. Frankfurt :
Software & Support Verlag GmbH, 2007. ISBN 978-3-939084-11-2.
Berners-Lee, Tim, et al. 2005. Uniform Resource Identifier (URI): Generic Syntax. Santa
Clara : RFC-Editor, 2005. RFC-3986.
Berners-Lee, Tim, Fielding, Roy Thomas und Masinter, Larry. 2005A. Uniform
Resource Identifier (URI): Generic Syntax. Santa Clara : RFC-Editor, 2005A. RFC-3986.
Berners-Lee, Tim, Fielding, Roy Thomas und Nielsen, Henrik Frystyk. 1996.
Hypertext Transfer Protocol -- HTTP/1.0. Santa Clara : RFC-Editor, 1996. RFC-1945.
Boldt, Nick. 2007. EMF/EMF 2.3/Generics. Eclipse.org Wiki. [Online] 21. Dezember
2007. [Zitat vom: 2. September 2011.]
http://wiki.eclipse.org/EMF/EMF_2.3/Generics.
Böttge, René. 2009. Automatisierung der Erstellung sprachbasierter Anwendungen mittels
openArchitectureWare als Alternative zu einem bereits existierenden, proprietären
Generierungs-Werkzeug. Berlin : Hochschule für Technik und Wirtschaft Berlin, 2009.
Box, Don. 2001. A Brief History of SOAP. XML From the Inside Out -- XML
development, XML resources, XML specifications. [Online] 4. April 2001. [Zitat vom: 14.
Juli 2011.] http://www.xml.com/pub/a/ws/2001/04/04/soap.html.
Crockford, Douglas. 2006. The application/json Media Type for JavaScript Object Notation
(JSON). Santa Clara : RFC-Editor, 2006. RFC-4627.

xii
Danial, Al. 2010. CLOC - Count Lines of Code. SourceForge. [Online] 2. Dezember
2010. [Zitat vom: 1. September 2011.] http://cloc.sourceforge.net/.
Davenport, Chris, et al. 2010. Xml-rpc changes in Joomla! 1.6. Joomla! Documentation.
[Online] 1. November 2010. [Zitat vom: 24. August 2011.]
http://docs.joomla.org/Xml-rpc_changes_in_Joomla!_1.6.
Deutsche Telekom AG. 2011. Archive: SDK Version 2.7, Frameworks & Extensions.
Developer Garden. [Online] 2011. [Zitat vom: 17. August 2011.]
http://www.developergarden.com/?id=352.
—. 2011A. Developer Center - Ihr persönliches Entwicklerkonto. Developer Center.
[Online] 2011A. [Zitat vom: 2. September 2011.]
http://www.developercenter.telekom.com/.
—. 2011B. Developer Garden - APIs : A.3. Ansprache der Services über die REST-
Schnittstelle. Developer Garden - APIs : APIs. [Online] Deutsche Telekom AG, 2011B.
[Zitat vom: 12. Juli 2011.]
http://www.developergarden.com/index.php?id=511&L=1&vURL=apas03.html&c
Hash=47220646742fe1859f3e4e777f17cc14#N15B93.
—. 2011C. Developer Garden - APIs : APIs. Developer Garden. [Online] September
2011C. [Zitat vom: 2. September 2011.] http://www.developergarden.com/.
Docbook Committee. 2007. DocBook Technical Committee Document Repository.
OASIS - Organization for the Advancement of Structured Information Standards. [Online]
2. November 2007. [Zitat vom: 2. September 2011.] http://www.oasis-
open.org/docbook/.
Efftinge, Sven. 2011. A rough performance comparison between Xpand and Xtend 2.
Sven Efftinge's Blog. [Online] 21. März 2011. [Zitat vom: 2. September 2011.]
http://blog.efftinge.de/2011/03/rough-performance-comparison-between.html.
Efftinge, Sven und Software & Support Media GmbH. 2011. Xtext 2.0: DSLs
unleashed - Xtext-Lead Sven Efftinge über die Neuerungen in Xtext 2.0. it republik :
jaxenter. [Online] Februar 2011. [Zitat vom: 29. August 2011.] http://it-
republik.de/jaxenter/artikel/Xtext-2.0-DSLs-unleashed-3604.html.
Efftinge, Sven. 2010. Xbase - A new programming language? Sven Efftinge's Blog.
[Online] 30. September 2010. [Zitat vom: 26. August 2010.]
http://blog.efftinge.de/2010/09/xbase-new-programming-language.html.

xiii
—. 2010A. Xtend 2 - the Successor to Xpand. Sven Efftinge's Blog. [Online] 3.
Dezember 2010A. [Zitat vom: 26. August 2011.]
http://blog.efftinge.de/2010/12/xtend-2-successor-to-xpand.html.
—. 2009. Xtext - Using existing Ecore models. Sven Efftinge's Blog. [Online] 24.
November 2009. [Zitat vom: 29. August 2011.]
http://blog.efftinge.de/2009/11/xtext-using-existing-ecore-models.html.
—. 2010B. Xtext in Indigo. Sven Efftinge's Blog. [Online] 29. September 2010B. [Zitat
vom: 29. August 2011.] http://blog.efftinge.de/2010/09/xtext-in-indigo.html.
Efftinge, Sven, et al. 2008. openArchitectureWare User Guide.
openarchitectureware.org. [Online] 15. Dezember 2008. [Zitat vom: 11. August 2011.]
http://www.openarchitectureware.org/pub/documentation/4.3.1/openArchitectur
eWare-4.3.1-Reference.pdf.
Efftinge, Sven, et al. 2010. Xpand - Eclipsepedia. Eclipsepedia. [Online] 9. Dezember
2010. [Zitat vom: 10. August 2011.] http://wiki.eclipse.org/Xpand.
Farrell, Jake. 2011. Contents of /thrift/tags/thrift-
0.7.0/compiler/cpp/src/generate/t_java_generator.cc. Apache-SVN. [Online] 13.
August 2011. [Zitat vom: 29. August 2011.]
http://svn.apache.org/viewvc/thrift/tags/thrift-
0.7.0/compiler/cpp/src/generate/t_java_generator.cc?revision=1157427&view=mar
kup.
Ferguson, Derek. 2004. Exclusive .NET Developer's Journal "Indigo" Interview with
Microsoft's Don Box. .NET Developer's Journal. [Online] 10. August 2004. [Zitat vom:
14. Juli 2011.] http://dotnet.sys-con.com/node/45908.
Fielding, Roy Thomas. 2000. Architectural Styles and the Design of Network-based
Software Architectures. donald bren school of information and computer sciences @ the
university of california, irvine. [Online] 2000. [Zitat vom: 7. Juli 2011.]
http://www.ics.uci.edu/~ﬁelding/pubs/dissertation/top.htm.
Fielding, Roy Thomas, et al. 1999. Hypertext Transfer Protocol -- HTTP/1.1. Santa
Clara : RFC-Editor, 1999. RFC-2616.
Google Inc. 2011. Google Maps JavaScript API V3 – Allgemeines. Google code.
[Online] 2011. [Zitat vom: 16. August 2011.] http://code.google.com/intl/de-
DE/apis/maps/documentation/javascript/basics.html.

xiv
—. 2011A. Google Web Search API. Google code. [Online] 2011A. [Zitat vom: 3.
September 2011.] http://code.google.com/apis/websearch/docs/.
—. 2011B. google-guice - Guice. Google Project Hosting. [Online] 2011B. [Zitat vom: 1.
September 2011.] http://code.google.com/p/google-guice/.
Gregorio, Joe. 2007. Do we need WADL? BitWorking. [Online] 5. Juni 2007. [Zitat
vom: 2. September 2011.] http://bitworking.org/news/193/Do-we-need-WADL.
Gudgin, Martin, et al. 2007. SOAP Version 1.2 Part 1: Messaging Framework (Second
Edition). Word Wide Web Consortium (W3C). [Online] 27. April 2007. [Zitat vom: 24.
August 2011.] http://www.w3.org/TR/soap12/.
Hadley, Marc. 2011. Web Application Description Language (WADL) - Specification
and Tools - Java.net. java.net. [Online] 2011. [Zitat vom: 2. September 2011.]
http://wadl.java.net/.
Herrmann, Stephan. 2011. Object Teams home. The Eclipse Foundation. [Online] 2011.
[Zitat vom: 1. September 2011.] http://www.eclipse.org/objectteams/.
Hunter, Anthony. 2009. Bugzilla - Bug 277397. bugs.eclipse.org. [Online] 1. Juni 2009.
[Zitat vom: 11. August 2011.]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=277397#c2.
itemis AG. 2011. Xtext git repository. git.eclipse.org. [Online] 10. August 2011. [Zitat
vom: 29. August 2011.]
http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/tree/plugins/org.eclipse.xtext/src
/org/eclipse/xtext/Xtext.xtext.
Masinter, Larry. 1998. Returning Values from Forms: multipart/form-data. Santa Clara :
RFC Editor, 1998. RFC-2388.
Merks, Ed. 2009. Two features named in the model by the same name. Eclipse
Community Forums. [Online] 21. August 2009. [Zitat vom: 16. August 2011.]
http://www.eclipse.org/forums/index.php/mv/msg/153408/483174/#msg_48317
4.
Microsoft Corporation. 2011. [MS-FSCX]: Configuration XML-RPC Protocol
Specification. Microsoft Developer Network: Open Specifications Developer Center.
[Online] 10. Juni 2011. [Zitat vom: 24. August 2011.] http://msdn.microsoft.com/en-
us/library/ee627322(office.12).aspx.

xv
—. 2011A. Remote Procedure Call. MSDN – Explore Desktop, Web, Cloud, and Phone
Software Development. [Online] 12. Mai 2011A. [Zitat vom: 14. Juli 2011.]
http://msdn.microsoft.com/en-us/library/aa378651(VS.85).aspx.
—. 2011B. System.CodeDom-Namespace. Microsoft Developer Network - .NET
Framework Developer Center. [Online] 2011B. [Zitat vom: 29. August 2011.]
http://msdn.microsoft.com/de-de/library/system.codedom.aspx.
—. 2005. Web Services Enhancements (WSE) 3.0 for Microsoft .NET. Microsoft
Download Center. [Online] 11. Juli 2005. [Zitat vom: 17. August 2011.]
http://www.microsoft.com/download/en/details.aspx?id=14089.
—. 2011C. Windows Communication Foundation (WCF). .NET Framework Developer
Center. [Online] 2011C. [Zitat vom: 22. August 2011.]
http://msdn.microsoft.com/de-de/netframework/aa663324.aspx.
openArchitectureWare.org. 2009. openArchitectureWare.org - Official
openArchitectureWare Homepage. openArchitectureWare.org - Official
openArchitectureWare Homepage. [Online] itemis AG, 2009. [Zitat vom: 10. August
2011.] http://www.openarchitectureware.org/.
—. 2009A. Why openArchitectureWare moved to Eclipse.org.
openarchitectureware.org. [Online] 20. September 2009A. [Zitat vom: 11. August 2011.]
http://www.openarchitectureware.org/staticpages/index.php/oaw_eclipse_letter_
of_intent.
Oracle Corporation. 2011. Creating RESTful Service Clients in NetBeans Modules.
NetBeans.org. [Online] 2011. [Zitat vom: 29. August 2011.]
http://netbeans.org/kb/docs/websvc/jersey-rcp-client.html.
—. 2011A. Glassfish » Jersey. Java.net. [Online] Oracle Corporation, 2011A. [Zitat
vom: 12. Juli 2011.] http://jersey.java.net/.
—. 2010. Remote Method Invocation Home. Oracle | Hardware and Software,
Engineered to Work Together. [Online] 16. Juli 2010. [Zitat vom: 14. Juli 2011.]
http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136424.html.
O'Reilly & Associates, Inc. 1992. DocBook 1.0. OASIS - Organization for the
Advancement of Structured Information Standards. [Online] 12. November 1992. [Zitat
vom: 2. September 2011.] http://www.oasis-
open.org/docbook/sgml/1.0/docbk10.zip.

xvi
Organization for the Advancement of Structured Information Standards. 2011.
OASIS Web Services Security (WSS) TC. OASIS | Advancing open standards for the
information society. [Online] 2011. [Zitat vom: 5. Juli 2011.] http://www.oasis-
open.org/committees/wss/.
—. 2011A. OASIS Web Services Transaction (WS-TX) TC. OASIS | Advancing open
standards for the information society. [Online] 2011A. [Zitat vom: 5. Juli 2011.]
http://www.oasis-open.org/committees/ws-tx/.
Parys, Dariusz und Mauerer, Jürgen. 2004. .NET Remoting. MSDN: Microsoft
Developer Network (Deutschland). [Online] 14. November 2004. [Zitat vom: 14. Juli
2011.] http://msdn.microsoft.com/de-de/library/bb979191.aspx.
ProgrammableWeb.com. 2011. API Directory - ProgrammableWeb.
ProgrammableWeb - Mashups, APIs, and the Web as Platform. [Online] 2011. [Zitat vom:
5. Juli 2011.]
http://www.programmableweb.com/apis/directory/1?protocol=REST.
Richardson, Leonard und Ruby, Sam. 2007. RESTful Web Services. Sebastopol :
O'Reilly Media, Inc., 2007. 978-0-596-52926-0.
Rotem-Gal-Oz, Arnon. 2007. Debate: Does REST Need a Description Language?
InfoQ. [Online] 6. Juni 2007. [Zitat vom: 2. September 2011.]
http://www.infoq.com/news/2007/06/rest-description-language.
Schidler, Patrick. 2010. RESTclient for WCF. Codeplex. [Online] 27. Januar 2010.
http://restclient.codeplex.com/.
Shatalin, Alexander und Gronback, Richard. 2009. GMF Xpand Migration howto.
wiki.eclipse.org. [Online] 19. März 2009. [Zitat vom: 11. August 2011.]
http://wiki.eclipse.org/GMF_Xpand_Migration_howto.
Skrypuch, Neil. 2011. Eclipse Modeling - EMF - Home. The Eclipse Foundation.
[Online] 2011. [Zitat vom: 2. September 2011.]
http://www.eclipse.org/modeling/emf/.
Slawik, Mathias. 2011. Ansprache der Services über die REST-Schnittstelle. Developer
Garden. [Online] 2011. [Zitat vom: 2. September 2011.]
http://www.developergarden.com/index.php?id=511&L=1&vURL=apas03.html&c
Hash=47220646742fe1859f3e4e777f17cc14.

xvii
—. 2008. Entwicklung und Anwendung eines Integrationskonzepts für das Typo3 CMS
unter Verwendung von Methoden der Modellgetriebenen Softwareentwicklung. Berlin : s.n.,
2008.
Srinivasan, Raj. 1995. RPC: Remote Procedure Call Protocol Specification Version 2
(PROPOSED STANDARD). Santa Clara : RFC Editor, 1995. RFC-1831.
St.Laurent, Simon, Johnston, Joe und Dumbill, Edd. 2001. Programming Web Services
with XML-RPC. Sebastopol : O'Reilly & Associates, Inc., 2001. 0-596-00119-3.
Steinberg, Dave. 2008. Fundamentals of the Eclipse Modeling. eclipse.org. [Online] 17.
März 2008. [Zitat vom: 17. August 2009.]
http://www.eclipse.org/modeling/emf/docs/presentations/EclipseCon/EclipseCo
n2008_309T_Fundamentals_of_EMF.pdf.
Steinberg, Dave, et al. 2008. EMF: Eclipse Modeling Framework, Second Edition. Boston :
Addison-Wesley Professional, 2008. ISBN-13: 978-0-321-33188-5.
Steiner, Thomas. 2007. Automatic Multi Language Program Library Generation for
REST APIs. Google Documents. [Online] Juni 2007. [Zitat vom: 2. September 2011.]
https://docs.google.com/Doc?id=dgdcn6h3_38fz2vn5.
Steiner, Thomas, Bruckner, Alexander und Botterill, Louis. 2008. rest-api-code-gen
REST API Code Generation. Google Code. [Online] 9. November 2008. [Zitat vom: 29.
August 2011.] http://code.google.com/p/rest-api-code-gen/.
Sun Microsystems, Inc. 1997. JavaBeans API specification. Oracle Technology Network.
[Online] 8. August 1997. [Zitat vom: 2. September 2011.]
http://www.oracle.com/technetwork/java/javase/documentation/spec-
136004.html.
—. 1988. RPC: Remote Procedure Call Protocol Specification Version 2
(INFORMATIONAL). Santa Clara : RFC Editor, 1988. RFC-1057.
Taal, Martin und Irawan, Hendy. 2011. Teneo. Eclipse.org Wiki. [Online] 1. März
2011. [Zitat vom: 2. September 2011.] http://wiki.eclipse.org/Teneo#teneo.
Technische Universität Berlin. 2011. Publications. Object Teams. [Online] 2011. [Zitat
vom: 1. September 2011.] http://www.objectteams.org/publications/index.html.
The Apache Software Foundation. 2011. Apache Maven Project. The Apache Software
Foundation. [Online] 11. August 2011. [Zitat vom: 18. August 2011.]
http://maven.apache.org/.

xviii
—. 2011A. Thrift. The Apache Software Foundation. [Online] 2011A. [Zitat vom: 29.
August 2011.] http://thrift.apache.org/.
The Axis Development Team. 2006. Web Services - Axis. The Apache Software
Foundation. [Online] 22. April 2006. [Zitat vom: 17. August 2011.]
http://axis.apache.org/axis/.
The DocBook Project. 2005. The DocBook Project. SourceForge.net. [Online] 19.
November 2005. [Zitat vom: 2. September 2011.] http://docbook.sourceforge.net/.
The Eclipse Foundation. 2011. Eclipse Modeling Project. Eclipse - The Eclipse
Foundation open source community website. [Online] 2011. [Zitat vom: 30. Juni 2011.]
http://www.eclipse.org/modeling.
—. 2011A. Home - Modeling - TMF (Xtext). Eclipse Community Forums. [Online]
2011A. [Zitat vom: 29. August 2011.]
http://www.eclipse.org/forums/index.php?t=thread&frm_id=27.
—. 2011B. Intellectual Property Policy. eclipse.org. [Online] 21. Juli 2011B. [Zitat vom:
11. August 2011.] http://eclipse.org/org/documents/Eclipse_IP_Policy.pdf.
—. 2011C. The AspectJ Project. The Eclipse Foundation. [Online] 2011C. [Zitat vom: 1.
September 2011.] http://www.eclipse.org/aspectj/.
Thoms, Karsten. 2006. openArchitectureWare.org Forum - History of oAW.
openArchitectureWare.org - Ofﬁcial openArchitectureWare Homepage. [Online] itemis AG,
28. August 2006. [Zitat vom: 10. August 2011.]
http://www.openarchitectureware.org/forum/viewtopic.php?showtopic=1995.
Vogel, Lars. 2011. Eclipse JDT - Abstract Syntax Tree (AST) and the Java Model -
Tutorial. Java, Eclipse, Android, and Web Programming Tutorials. [Online] 16. August
2011. [Zitat vom: 29. August 2011.]
http://www.vogella.de/articles/EclipseJDT/article.html.
White, James. 1975. High-level framework for network-based resource sharing. Menlo
Park : RFC Editor, 1975. RFC-707.
Winer, Dave. 1999. XML-RPC Speciﬁcation. XML-RPC Home Page. [Online] 15. Juni
1999. [Zitat vom: 14. Juli 2011.] http://www.xmlrpc.com/spec.
Woodruff, Eric. 2011. Sandcastle Help File Builder. CodePlex - Open Source
Community. [Online] Microsoft Corporation, 1. Mai 2011. [Zitat vom: 18. August
2011.] http://shfb.codeplex.com/.

xix
WordPress.org. 2011. WordPress Codex: XML-RPC Support. WordPress.org. [Online]
22. Juli 2011. [Zitat vom: 24. August 2011.] http://codex.wordpress.org/XML-
RPC_Support.
World Weather Online. 2011. Free Local Weather API Overview. World Weater
Online. [Online] 2011. [Zitat vom: 3. September 2011.]
http://www.worldweatheronline.com/free-weather-feed.aspx.
—. 2011A. Free Local Weather API Request Builder. World Weather Online. [Online]
2011A. [Zitat vom: 3. September 2011.] http://www.worldweatheronline.com/feed-
generater.aspx.
Zarnekow, Sebastian und Köhnlein, Jan. 2011. What's Cooking in Xtext 2.0.
slideshare.net. [Online] 6. April 2011. [Zitat vom: 11. August 2011.]
http://www.slideshare.net/schwurbel/whats-cooking-in-xtext-20.
Zimmer, Frank. 2009. Developer Garden Forum - Re: Java: LT02: Text is not a valid
token. Developer Garden. [Online] 2. Juni 2009. [Zitat vom: 17. August 2011.]
http://www.developergarden.com/apis/forum/?tx_mmforum_pi1%5Baction%5D=
list_post&tx_mmforum_pi1%5Btid%5D=92&tx_mmforum_pi1%5Bpage%5D=&tx_m
mforum_pi1%5B.

Eidesstattliche Versicherung
Ich versichere hiermit, dass ich die vorliegende Masterthesis selbstständig und ohne
fremde Hilfe angefertigt und keine andere als die angegebene Literatur benutzt habe.
Alle von anderen Autoren wörtlich übernommenen Stellen wie auch die sich an die
Gedankengänge anderer Autoren eng anlehnenden Ausführungen meiner Arbeit
sind besonders gekennzeichnet.
Diese Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungs-
behörde vorgelegt und auch nicht veröffentlicht.
Datum, Unterschrift

Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung

Weitere ähnliche Inhalte

Was ist angesagt?

Andere mochten auch

Ähnlich wie Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung

Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung