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

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (16)

Semelhante a 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

Semelhante a 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 (20)

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