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

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 typografischen 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 flexible 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 S327 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 DevelopmentTools (MDT)

BPMN Metamodel

eTrice (ROOM)

MoDisco

OCL

Papyrus

Sphinx

UML2

XSD

M2M

Atlas (ATL)

M2T

JET Xpand

Mod

elltr

ansf

orm

atio

n

Technology & Research

GMT

AM3

AMW

MOFScript

UMLX

Viatra2

Epsilon GEMS MoDisco

Fors

chun

g un

dIn

kuba

tion

Anwendung

AmalgamVerfü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 spezifiziert 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-Definition ü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 Definition 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}.flatten() ;

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 Sprache59 Xtend ist eine funktionale Programmiersprache und daher der Erfahrung nach be-sonders für Ausdrücke und Modelltransformationen geeignet.

Xtend ermöglicht einen flexiblen 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 definiert, 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äufiges 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.

Gründe zur Ablösung der Technologie 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.

Gründe zur Ablösung der Technologie 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äufig 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 Definition 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 flexible 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-Spezifikation: (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, Auffindung von Referenzen sowie automatische Code-Formatierung.

Da die Laufzeit-Instanz einer Xtext-Sprachdatei als Ecore-Modell vorliegt, kann auf diese auch über reflexive 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 Authentifizierung 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 Identifikation 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 Pflege 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.



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 gepflegt, da diese lediglich ergänzende Informationen enthalten. Vor der Transformation in die Ausgabeformate durch die Docbook XSL-Stylesheets werden die manuell gepflegten 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


Metamodellservice.ecore

Modelldevelopergarden.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 Kapitelch0x.de.xml / ch0x.en.xml

Docbook XSL Stylesheets

HTMLsingle

HTMLchunked 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 Pflege 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-Spezifika (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.



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 spezifischen 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


POST http://gateway.developer.telekom.com/p3gw-mod-odg-voicebutler/rest/{environment}/call

httpMethod = POST

NewCall : RestMethodrestEndpoint = /p3gw-mod-odg-voicebutler/rest

VoiceCallService : Service

restHostname = gateway.developer.telekom.com

DeveloperGardenProvider : Providername = environmentdynamic = true

Environment : RestResource

name = calldynamic = 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 Auflistung 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 überflü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


Metamodellservice.ecore

Modelldevelopergarden.xmi

Abstrakte Syntax

Content-Repositorycontent.xml

Xtend-TransformationcleanModel.ext

„Sauberes“ REST-ModellDevelopergarden.clean.xmi

StrukturInhalt Auflösung der Feldhierarchien

Ermittlung der Dokumentation

SDK Quellcode

Java SDKDE

Java SDKEN

.NET SDKDE

.NET SDKEN

PHP SDKDE

PHP SDKEN

Code-Generierung

ANT Workflow

SDK - Endergebnis

Java SDKDE

Java SDKEN

.NET SDKDE

.NET SDKEN

PHP SDKDE

PHP SDKEN

StatischeBestandteilePlattformspezifischer

Build-Vorgang

Xpand - Templates

Xtend - Funktionen


50

Grundlage der Generierung ist eine erweiterte Version des vorhandenen Metamo-dells. Da das Modell sowohl Elemente zur Beschreibung der SOAP-Schnittstelle, als auch der REST-Schnittstelle enthält, wurde zur Vereinfachung der Code-Generierung eine Xtend-Transformation implementiert (cleanModel.ext), welche das Modell „säubert“, also die SOAP-Elemente aus dem Modell entfernt.

Transformation der Feldhierarchie Darüber hinaus löst die Xtend-Transformation die Feldhierarchie auf, d. h. für jede Ebene der Antwortformate wird ein REST-Modellelement erstellt. Dies ermöglicht eine relativ einfache Transformation der neuen Typen in Klassen der Zielsprachen der SDKs.

Das folgende Beispiel zeigt anhand eines Ausschnitts aus der getConferenceStatus-Antwortnachricht diesen Mechanismus:

developergarden.xmi Typ getConferenceStatusRestReturn

• Feld conference

o Unterfeld detail

Unterfeld name

⇒

developergarden.clean.xmi Typ GetConferenceStatusResponse

• Feld conference (Typ: GetConferenceStatusConferenceResponse) Typ GetConferenceStatusConferenceResponse

• Feld detail (Typ: GetConferenceStatusConferenceDetailResponse) Typ GetConferenceStatusConferenceDetailResponse

• Feld name

Ermittlung der Dokumentation Da die Ermittlung der Dokumentation der jeweiligen Modellelemente aus dem Con-tent Repository ein relativ aufwändiger Prozess ist, wird die Dokumentation in deve-lopergarden.clean.xmi in den Feldern descriptionGerman und descriptionEnglish zwi-schengespeichert.

Somit können beispielsweise Änderungen an den Code-Templates durchgeführt werden, ohne die cleanModel.ext-Transformation erneut durchführen zu müssen.

Build-Vorgang Der Build-Vorgang der SDKs gliedert sich in zwei Schritte:

• Code-Generierung

Die Code-Generierung erfolgt durch Xpand Code-Templates.

Zusätzlich existieren Xtend-Funktionsbibliotheken, welche während der Trans-formation wiederholt benötigte Ausdrücke enthalten. Dies sind zum Beispiel Funktionen zur Berechnung von plattformspezifischen Namen von Klassen, In-terfaces, etc. oder Funktionen zur Selektion von Elementen innerhalb des Mo-dells.


51

• Plattformspezifischer Build-Vorgang

Der generierte Code wird mit statischen Bestandteilen zusammengeführt und im Anschluss daran nach plattformspezifischen Vorgaben gebaut.

Statische Bestandteile sind beispielsweise Basisklassen der Developer Garden Clients, Konfigurationsdateien für Apache Maven111 oder Sandcastle Help File Builder112 XML-Dateien.

Der plattformspezifische Build-Vorgang beinhaltet meist die Kompilierung des Quellcodes, die Erzeugung von Dokumentations-Dateien mit Hilfe von Tools der Zielplattform sowie die Ausführung der Unit-Tests.

Der Build-Vorgang der SDKs wird auf einem Server für die kontinuierliche Integra-tion durchgeführt.

Anpassungen am Metamodell

Abbildung 17 - Neue Elemente und Beziehungen der dritten Iteration113

111 Tool zum Management von Softwareprojekten: (The Apache Software Foundation, 2011) 112 Tool zur Generierung der .NET – Dokumentation: (Woodruff, 2011) 113 Eigene Darstellung


52

Mit der Erweiterung der Anforderungen an das Framework wurde auch das Meta-modell erweitert. Die vorhergehende Abbildung zeigt neue Elemente und Implemen-tiert-Beziehungen der dritten Iteration. Zur Steigerung der Übersichtlichkeit wurden die konkreten Implementierungen von UnitTestStep und SampleStep ausgelassen.

Einige der neuen Modell-Elemente sollen im Folgenden kurz erläutert werden:

DocumentedClass

DocumentedClass dient dazu, die Beschreibungen von Modellelementen zwi-schen zu speichern.114 Jedes beschriebene Element implementiert dieses Inter-face.

Durch die Speicherung der Beschreibung in den Attributen descriptionGerman und descriptionEnglish sind die Beschreibungen innerhalb der Code-Transformationen sehr einfach zugänglich.

UnitTest

UnitTest abstrahiert Unit-Tests für einzelne Services. Das Attribut environment legt fest, in welcher Developer Garden Umgebung der Unit-Test ausgeführt werden soll. Ein UnitTest enthält ein oder mehrere Test-Schritte (UnitTestStep).

UnitTestStep

Ein UnitTestStep ist ein Schritt in einem Unit-Test. Im Metamodell enthaltene Schritte sind zum einen die Ausführung einer REST-Methode mit bestimmba-ren Parametern und zum anderen Überprüfungen (Assertions) von Eigenschaf-ten der Rückgabewerte (z.B. „gleich einem bestimmten Wert“ oder „nicht null“).

Sample

Ein Sample ist ein dem SDK beiliegendes Beispiel zur Verwendung eines Ser-

vices. Ein Sample besteht ähnlich wie Unit-Tests aus Beispiel-Schritten und es existieren daher auch gemeinsame Xtend-Ausdrücke zur Verarbeitung von Samples und Unit-Tests.

SampleStep

Ein SampleStep ist ein Schritt in einem dem SDK beiliegendem Beispiel. Im Me-

tamodell enthaltene Schritte sind die Definition von Variablen (SampleStepDefi-

neVariable), der Aufruf von Methoden (SampleStepInvokeMethod) sowie die Aus-

gabe von Rückgabewerten auf der Konsole (SampleStepPrintVariable).

114 Siehe „Ermittlung der Dokumentation“ (Seite 40)


53

ErrorCode.constantName und Service.number

Um die architektonische Besonderheit der Developer Garden Fehlercodes115 ab-zubilden wurden zwei Attribute zum Metamodell hinzugefügt.

Das Attribut constantName der Metamodellklasse ErrorCode weist jedem Fehler-code eine eindeutige Konstante zu (z.B. „MESSAGE_TOO_LONG“ oder „TOO_MANY_NUMBERS“), die in den Zielsprachen mithilfe des jeweiligen Kon-stanten-Mechanismus (z.B. „public static final int“-Felder in Java) um-gesetzt wird.

Mithilfe des Attributs number der Metamodell-Klasse Service wird jedem Service eine Nummer zugewiesen, die in einem Algorithmus verwendet wird, der die korrekte Zuordnung von Konstanten und Beschreibungen zu überschriebenen Fehlercodes implementiert.

Auswertung Insgesamt lässt sich feststellen, dass alle Problemfelder durch die Lösungsansätze der REST SDKs adressiert werden konnten:

• Das Java REST SDK enthält keine externen Bibliotheken und ist zudem nun abwärtskompatibel bis zur Java Version 1.4. Dadurch ergeben sich neue Ein-satzmöglichkeiten des SDKs.

• Im .NET-SDK konnten die veralteten Web Services Extensions durch die Windows Communication Foundation116 abgelöst werden.

• Das PHP-SDK ist nun abwärtskompatibel zu PHP Version 5.0 (vorher: 5.2.12). Außerdem muss lediglich das PHP-Modul cURL aktiviert sein.117

• Die Abhängigkeit zur Telekom LibSTS entfällt in allen SDKs. Dadurch ergibt sich eine geringere Download-Größe und ein verminderter Ressourcenver-brauch.

• Die Dokumentation der SDKs konnte durch die Verwendung des Content-Repositories der Benutzerdokumentation deutlich verbessert werden. Dar-über hinaus werden die SDKs nun zweisprachig angeboten.

• Die Testfähigkeit der SDKs ist mit der Einbindung von Unit-Tests gegeben

• Der Developer Garden Status-Code – Mechanismus wird in allen SDKs abge-bildet.

• Es werden keine internen Details durch die SDKs exponiert. (Problemfeld P9)

115 Beschrieben in „ErrorCode“ (Seite 32) 116 (Microsoft Corporation, 2011C) 117 Für das SOAP SDK sind die Module SOAP, OpenSSL, mcrypt und mhash erforderlich


54

Benchmark-Ergebnisse Zur genauen Analyse der Auswirkungen der modellgetriebenen Entwicklung der REST SDKs in Bezug auf Speicherverbrauch und Performance wurde ein Benchmark beider Java-SDKs (SOAP & REST) durchgeführt. Getestet wurden die Dauer eines Aufrufs der Methode newCall (Aufbau einer Sprachverbindung) und der Speicher-verbrauch des Code-Samples vor und nach dem Lauf des Garbage Collectors.

Der Testaufbau war ein Intel Core i7 – Prozessor mit 2,6 Ghz unter Windows 7 und Java 1.6, beides in der 64bit-Version. Die einzelnen Tests wurden mehrmals wieder-holt und ein Durchschnitt der Messwerte gebildet.

Aufgabe SOAP-SDK REST-SDK Reduzierung

Dauer newCall() ~ 3250 ms ~ 1400 ms - 57 %

Speicherverbrauch vor GC() 12,1 MByte 2,5 MByte - 79 %

Speicherverbrauch nach GC() 4,8 MByte 1,6 MByte - 67 %

Der Benchmark zeigt sehr deutlich, dass die generierten REST SDKs einen überzeu-genden Lösungsansatz des Problembereichs P5 (Overhead und Ressourcenver-brauch) bieten.

3.4 Iteration 4: AutoScout24 – API

Zum Ende Mai 2011 wurde das Developer Garden API – Portfolio um eine Schnitt-stelle zur Abfrage des Datenbestandes der Telekom-Tochtergesellschaft AutoScout24 erweitert. Dafür musste ab Oktober 2010 das entwickelte Framework für die Unter-stützung der AutoScout24-API ergänzt werden.

Dadurch ergaben sich einige Herausforderungen:

Hohe Komplexität der Schnittstelle Die AutoScout24-Schnittstelle besitzt eine unnötig hohe Komplexität, da im Vorfeld der Realisierung versäumt wurde, die Anforderungsdefinition auf Vereinfachungs-potential zu überprüfen.

Daher werden viele Aspekte durch komplexere Konstrukte ausgedrückt, als eigent-lich notwendig wäre. Beispielsweise müssen Wertebereiche als verschachtelte JSON-Konstruktionen angegeben werden118, anstatt durch einfache Zeichenketten119.

118 z.B. Felder begin und end von FindArticlesRestReturn.response.vehicles.vehicle.availability 119 z.B. 1-5 für den Bereich von 1 bis 5 oder -5 bzw. 1- für den Bereich „bis 5“ beziehungsweise „ab 1“


55

Darüber hinaus sind alle mehrfachen Parameter und Rückgabewerte mit mindestens einer Ebene mehr ausgestattet, als notwendig. Beispielsweise könnte die Liste der gefundenen Inserate durch ein JSON-Array vehicles[] repräsentiert werden. An-statt dessen existiert ein JSON-Objekt vehicles, welches ein JSON-Array vehicle[] enthält.120

Andererseits wird durch die AutoScout24 – Schnittstelle eine Ungleichheit in die De-veloper Garden APIs eingeführt, da bei allen anderen APIs Wertemengen als kom-magetrennte Listen angegeben werden, bei der AutoScout24-Schnittstelle jedoch als JSON-Arrays.

Großer Umfang der AutoScout24 – Schnittstelle Die AutoScout24-Schnittstelle besitzt einen relativ großen Umfang. Dies wird unter anderem im Java-SDK deutlich, in welchem 31% der Codebasis zur AutoScout24-Schnittstelle gehören.121

Um die Definition der AutoScout24-API im Developer Garden Service-Modell (de-velopergarden.xmi) zu vereinfachen, wurde eine XSLT-Transformation zur auto-matischen Überführung der WSDL-Datei der SOAP-Schnittstelle in eine Beschrei-bung der REST Schnittstelle implementiert.

Fakultativer environment-Parameter Die ursprüngliche Version der AutoScout24 – Schnittstelle, für die das erstellte Framework angepasst wurde, enthielt keinen environment-Parameter. Da alle ande-ren APIs diesen Parameter besitzen, mussten die Code-Templates und funktionale Erweiterungen angepasst werden, um diese Besonderheit zu unterstützen.

Aus Gründen der Einheitlichkeit wurde der environment-Parameter in der aktuellen Version der API wieder eingefügt.

Änderung im Format der Aufrufe Bisher wurden alle API-Aufrufe entweder als multipart/form-data122, bzw. als ap-plication/x-www-form-urlencoded123 versendet.

Die AutoScout24-API erwartet jedoch Funktionsparameter im JSON-Format124, so-dass erhebliche Änderungen und Ergänzungen in den Code-Templates, sowie den funktionalen Ergänzungen vorgenommen werden mussten, um JSON-Objekte als Aufrufparameter zu unterstützen.

120 Detaillierung und weitere Beispiele siehe Anhang 4 121 Im Java-SDK 3.1.10 sind 4.772 Zeilen von 15.558 Zeilen Code AutoScout24 bezogen 122 (Masinter, 1998) 123 (Berners-Lee, et al., 2005) 124 (Crockford, 2006)


56

Zur Umsetzung dieser Änderungen wurde im Metamodell der Typ der subfields-Referenz der SimpleFieldRest-Modellklasse auf Field gesetzt (vorher SimpleFieldRest).

Eingeschränkte Verfügbarkeit, Zeitdruck Aufgrund meiner Verpflichtungen im Studium und den Anforderungen anderer De-veloper Garden Vorhaben (u.A. der Umstellung des Portalsystems auf TYPO3) blieb für die umfangreichen Änderungen am Framework zum Anfang der Realisierung relativ wenig Zeit. Aufgrund entstandenen Zeitdrucks für die Fertigstellung der An-passungen wurde auf eine Ergänzung des Sample- und Unit-Test-Modells verzichtet und anstatt dessen manuelle Code-Samples beigesteuert.

Allerdings musste hierdurch eine Möglichkeit geschaffen werden, einem SDK manu-elle Samples hinzuzufügen, was besonders in der .NET-Plattform aufwändig ist, da Sample-Dateien analysiert werden müssen, um sie in ein bestehendes .NET-Projekt einzubinden.

Zur Unterstützung wurde außerdem die Pflege der AutoScout24-Dokumentation im Content-Repository durch einen weiteren Mitarbeiter durchgeführt.

Tiefe Feldhierarchie Die Hierarchie der Felder der AutoScout24 Nachrichten und Parameter ist deutlich tiefer, als bei allen anderen APIs. Dadurch entstehen sehr lange Klassennamen, da diese nach der Feldhierarchie gebildet werden.

Um die Rekursion während der Bildung der Klassennamen zu unterbinden, wurde der Modellklasse SimpleFieldRest das Attribut breakNameGenerationRecursion hinzuge-fügt.

Anwendbarkeit der Dokumentations-Generierung über XSL-T Während der Änderungen am Metamodell und der Pflege der Dokumentation zeigte sich, dass die Generierung der Dokumentation über eine XSL-Transformation kon-zeptionelle Schwächen aufweist, da die technologische Trennung zwischen XSL-Interpreter und Xtend-Transformation relativ groß ist.

So kann weder in der XSL-Transformation auf einfache Weise auf Xtend-Funktionen zugegriffen werden, noch können Xtend-Code und Xpand-Templates auf Funktionen der Dokumentations-Generierung zugreifen. Dadurch entstehen Redundanzen in der Realisierung der Code- und Benutzer-Dokumentation.

Daher wurde die Dokumentations-Generierung in der Iteration 4 von XSL-T nach Xtend migriert.


57

Auswertung Das implementierte Framework konnte für die Generierung der AutoScout24-Schnittstelle angepasst werden.

Allerdings zeigte sich, dass die Integration einer API mit grundverschiedener Konzi-pierung gegenüber der ursprünglichen Domäne der anderen Developer Garden APIs einen relativ hohen Implementierungsaufwand darstellt.

Daher soll bei der Ableitung eines neuen Lösungsansatzes die Anwendungsdomäne möglichst umfassend definiert werden, sodass viele verschiedene REST APIs abge-bildet werden können.

Außerdem wurde während der Realisierung der Anpassungen deutlich, dass das Framework eine Refaktorierung durchlaufen sollte, um den Realisierungsaufwand für zukünftige Entwicklungen zu verbessern.

3.5 Iteration 5: Refaktorierung / Eclipse OSGi

Die letzte Iteration des Frameworks schloss sich an die Ergänzung und Anpassung für die AutoScout24 API an und beinhaltete diverse Refaktorierungen, sowie die OSGi-befähigung des Frameworks.

Motivation für die Durchführung der Refaktorierung war die Erleichterung der Mig-ration der Framework-Bestandteile zu einem zu erstellenden Framework. Außerdem sollte die Analyse des Frameworks durch die Arbeiten an der Refaktorierung unter-stützt werden und ein größeres Verständnis für die Eclipse-Plattform durch die OS-Gi-befähigung des Frameworks erzielt werden. Dies alles soll die Realisierung eines neuen Frameworks unterstützen.

Die durchgeführten Aufgaben der Iteration 5 waren wie folgt:

Auslagerung des Docbook- und Service-Metamodells in Eclipse Plug-Ins Der Zugriff auf das Content Repository durch die Transformation zur Generierung der Benutzerdokumentation und der Code-Kommentare erfolgt über die reflexive Ecore-API. Da die Ecore Laufzeitrepräsentation des Docbook-XML – Modells auf-grund der Vielzahl an Elementen relativ aufwändig zur Laufzeit neu berechnet wer-den muss, wird das Laufzeitverhalten der Gesamtlösung dadurch eingeschränkt.

Daher wurde in der Iteration 5 der Zugriff auf das Docbook-Modell von reflexiver API zu generierten EMF-Klassen umgestellt. Ebenso wurden die Modellklassen in Eclipse Plug-Ins ausgelagert, da ansonsten die Eclipse Plattform bei jedem Erstell-vorgang der Arbeitsumgebung ressourcenintensive Analysen der Quelldateien und des Ecore-Modells durchführen würde.

Dieselben Tätigkeiten wurden auch für das Service-Modell durchgeführt.


58

Aufteilung des Build-Workflows Der Umfang des Build-Workflows zur Generierung der SDKs und der Benutzerdo-kumentation ist im Laufe der Realisierung erheblich gewachsen. In der Iteration 5 wurde der Ant-Workflow daher modularisiert und einige Anweisungen zur Steige-rung der Les- und Wartbarkeit refaktoriert.

Überführung der Code-Generierung von MWE nach MWE2 Zur Evaluierung der MWE2 wurde der Workflow zur Code-Generierung von MWE nach MWE2 überführt. Um diesen MWE2-Workflow aus dem Build-Workflow her-aus zu starten, wurde ein Ant-Task implementiert (Mwe2Task).

Der Ant-Task übernimmt automatisch alle Ant-Properties in den Kontext der Mwe2-Tranformation und erleichtert dadurch die Weitergabe von Konfigurationsoptionen in den Code-Workflow, beispielsweise die aktuelle Sprache oder die zu generieren-den Services.

Identifizierung von Redundanzen innerhalb der Arbeitsumgebung Durch die erneute Einrichtung des Arbeitsbereichs auf Basis eines leeren Verzeich-nisses wurden nur die Dateien überführt, die zur Generierung der SDKs und der Be-nutzerdokumentation notwendig sind.

Hierdurch konnten Redundanzen innerhalb des Arbeitsbereichs aufgelöst und über-flüssige Dateien entfernt werden.

Bewertung Die Refaktorierungsarbeiten führten zu Verbesserungen bei der Strukturierung und der Wartbarkeit des entwickelten Frameworks. Außerdem wurden viele Erkenntnis-se gewonnen, welche die Realisierung den neuen Frameworks unterstützen. Gerade die Implementierung des Ant-Tasks und die Überführung von Teilen des Frame-works in OSGi-Plugins waren notwendig, um ein Verständnis für die Wirkungswei-sen der Eclipse Plugin-Entwicklung zu erzielen.


59

3.6 Ableitung eines neuen Lösungsansatzes

Die Analyse der Iterationen des Frameworks zeigt eine grundlegende Änderung der Anforderungen an das Framework: Von der Generierung der SOAP-Benutzerdokumentation hin zur plattformübergreifenden Erstellung von REST-SDKs für unterschiedliche Realisierungsstile der Developer Garden Web Services. Aller-dings erfolgten diese Änderungen graduell über einen Zeitraum von mittlerweile nahezu zwei Jahren, sodass seit der ersten Iteration keine grundlegende Überarbei-tung, Refaktorierung oder Neuimplementierung des Frameworks vonstattenging.

Darüber hinaus ist die Weiterentwicklung der Haupttechnologien des Frameworks, Xtend und Xpand, mittlerweile eingestellt, sodass zur Sicherung der Zukunftsfähig-keit des Frameworks und zur Nutzbarmachung von technologischen Verbesserun-gen auf die Nachfolgetechnologie Xtend 2.0 umgestellt werden muss.

Der analysierte Entwicklungsverlauf und die mittlerweile veralteten Technologien führen zu einer Minderung der Qualität des Frameworks im Gegensatz zu einer Neu-Implementierung auf Basis aktueller Anforderungen und Technologien. Dies bezieht sich insbesondere auf die Zugänglichkeit, Wartbarkeit und Leistungsfähig-keit des Frameworks.

Alle vorgenannten Fakten deuten darauf hin, dass nur eine grundlegende Überarbei-tung die aufgezeigten Problemfelder lösen wird. Die vorhergehende Analyse bildet das Fundament der im Folgenden dargestellten neuen Lösungsansätze:

Überarbeitung der Konzeption des Frameworks und des Metamodells Die Konzeption des neuen Frameworks sollte sich an den Erfahrungen orientieren, die in der Analyse der derzeitigen Konzeption aufgezeigt werden. Die Analyse un-terstützt vor allem die Strukturierung der Implementierung des neuen Frameworks in OSGi-Pakete und die intensivere Nutzung der Möglichkeiten der Eclipse IDE.

Außerdem sollte das neue Service-Metamodell in der Lage sein, die Eigenschaften nahezu aller REST-Schnittstellen zu abstrahieren. Denn sowie im Service-Metamodell Annahmen zu grundsätzlichen Eigenschaften einer Schnittstelle aus wenigen, spezi-ellen Schnittstellen (z.B. den vorhandenen Developer Garden APIs) abstrahiert wer-den, hat dies Auswirkungen auf nahezu alle Bestandteile eines Frameworks. Bei ei-ner Änderung oder Erweiterung des Metamodells müssten dann aufwändige Ände-rungen am Framework durchgeführt werden. Dies gilt es im neuen Framework durch eine universelle Service-Abstraktion zu vermeiden.

Nutzung aktueller Technologien Das neue Framework soll aktuelle Technologien nutzen, vor allem die Xtend/Xpand Nachfolgetechnologie Xtend 2.0.


60

Es ist zwar zu diesem Zeitpunkt nicht abzusehen, welche technologische Entwick-lung im EMP vonstattengehen wird, jedoch ist die Wahrscheinlichkeit als hoch ein-zuschätzen, dass die beiden vor kurzem grundlegend aktualisierten Technologien Xtend 2.0 und Xtext auf absehbare Zeit unterstützt und weiterentwickelt werden.

Modelldefinition über textuelle DSL Die Definition von REST-Schnittstellen über eine kompakte textuelle DSL auf der technologischen Basis von Xtext 2.0 ist im Vergleich zum bisherigen strukturierten Editor deutlich zugänglicher und ausdrucksstärker. Daher soll zusätzlich zum gene-rierten Ecore-Editor eine textuelle DSL für REST-Schnittstellen implementiert wer-den.

Außerdem bietet die Definition einer zugänglichen und ausdrucksstarken DSL als formale Beschreibungssprache von REST-Schnittstellen die Möglichkeit, Zweifel an der Sinnhaftigkeit von REST-Beschreibungssprachen entgegen zu treten.

Modellierung der Zielsprachen Im derzeitigen Framework existieren keine Modellelemente für Code-Artefakte der Zielsprachen. Dadurch entstehen teilweise Redundanzen in Code-Templates und funktionalen Erweiterungen. Außerdem lässt sich das Generierungsverhalten nur über Anpassungen an Text-Templates steuern.

Das zu erstellende Framework soll Modellelemente für Zielsprachen-Artefakte defi-nieren, um so eine bessere Strukturierung der Code-Generierung zu ermöglichen, sowie Redundanzen in Templates soweit wie möglich einschränken zu können.

Anpassbarkeit und Erweiterbarkeit des Frameworks Das Meta-Modell und die funktionalen Ergänzungen sollen zwar so wenig Annah-men wie möglich über konkrete Implementierungseigenschaften von REST-Schnittstellen machen, das Framework muss jedoch einen Mechanismus zur flexiblen Anpassung und Erweiterung enthalten, sodass Service-spezifische Eigenarten defi-niert werden können.

Überführung und Generalisierung vorhandener Funktionalität Die Funktionalität der derzeitig generierten SDKs sollte im zu erstellenden Frame-work weiterhin vorhanden sein, um keine Nachteile für die aktuellen Nutzer der SDKs entstehen zu lassen. Darunter fallen beispielsweise die mehrsprachige Bereit-stellung, die Unit-Tests und Code-Beispiele. Dies kann unter anderem durch die Übernahme von Teilen der aktuellen Code-Templates geschehen.

Darüber hinaus sollte bei der Überführung von Code-Templates die Trennung zwi-schen allgemeingültigen und Telekom-Spezifika beachtet werden.

GenerationREST: Konzipierung und Implementierung

61

4 GenerationREST: Konzipierung und Implementierung

GenerationREST ist der Name des neuen Frameworks, welches den aus der Analyse der Entwicklung des derzeitigen Frameworks abgeleiteten Lösungsansatz umsetzen soll. GenerationREST stellt eine Generalisierung und Erweiterung des entwickelten Frameworks dar und ist daher ein universelles Werkzeug zur Generierung von REST-Schnittstellenadaptern.

Die modellgetriebene Grundkonzeption des vorhandenen Frameworks wird hierbei beibehalten: Auf Basis formaler Metamodelle werden mithilfe textueller DSLs die Informationen zur Generierung von REST-Schnittstellenadaptern spezifiziert. Dies sind unter anderem eine Beschreibung der REST-Schnittstelle sowie die Spezifizie-rung der zu generierenden Artefakte, d.h. beispielsweise Plattform und Sprache des zu generierenden SDKs.

GenerationREST ist in die Eclipse IDE integriert und nutzt auf sinnvolle Weise die von der IDE bereitgestellte Funktionalität.

Projektaufbau GenerationREST ist eine Menge von Eclipse Plugin-Projekten, welche die verschie-denen Bestandteile des Frameworks kapseln und durch diese Strukturierung die Komplexität der Gesamtlösung reduzieren:

org.generationrest.metamodel

Das gemeinsame Metamodell der Gesamtlösung.

Enthält ebenso den AspectJ-Aspekt, welcher für die Zusammenführung von implementiertem und generiertem Code verantwortlich ist.

org.generationrest.framework

Alle funktionalen Ergänzungen des Metamodells, sowie die Code-Generatoren.

org.generationrest.dsl

Die Xtext-Grammatiken und der MWE2-Workflow, welcher verwendet wird, um die Xtext-Artefakte der Eclipse-Integration (z.B. den Editor) zu generieren.

org.generationrest.dsl.tests

Automatisch generiertes Projekt, welches für zukünftig zu implementierende Validierungsregeln für die domänenspezifische Sprache vorgesehen ist.

org.generationrest.dsl.ui

Vom MWE2-Workflow automatisch generierte Xtext-Sprachbestandteile.


62

4.1 Metamodell

Das GenerationREST-Metamodell ist ein Ecore-Metamodell, welches in mehrere Pa-kete aufgeteilt ist, die jeweils unterschiedliche Aspekte der Modellierung adressieren:

structure

Abstrakte Strukturelemente für gemeinsame Attribute aller Service-Modelle (z.B. Service, Endpunkt, Feld, Methode, …)

rest

Aus structure abgeleitete Elemente mit REST-spezifischen Informationen (z.B. HTTP-Authentifizierungsmechanismus, REST-Resourcenpfad, …)

documentation

Modellelemente zur Abstraktion der Dokumentation anderer Modellelemente

generation

Generatoren und Generator-Parameter.

sdk

Strukturklassen für die Modellierung der zu generierenden SDKs.

Sowohl generation als auch sdk enthalten Unterpakete je Zielplattform (java, php, dot-

net). Alle Pakete sind Unterpakete des Wurzelpakets service.

Falls das Metamodell für eine effektive Verarbeitung zu einem späteren Zeitpunkt zu umfangreich werden sollte, so könnten die einzelnen Aspekte dann auch in getrennte Ecore-Dateien aufgeteilt werden.

4.1.1 Paket structure

Das Paket structure abstrahiert gemeinsame Attribute aller Kommunikationstechno-

logien und bildet daher die Grundlage des REST-Modells (Paket rest). Die Aufteilung

in structure und rest wurde zur Verdeutlichung der Trennung zwischen allgemeiner Struktur, sowie spezifischer Implementierungsdetails gewählt.

GenerationREST ist entgegen dem Namen offen gegenüber späteren Erweiterungen um weitere Kommunikationstechnologien, wie z.B. XMLRPC oder SOAP. Diese könnten auf denselben Klassen aufbauen, wie das REST-Modell und sogar einige der für die structure-Elemente definierten Erweiterungen nutzen.

Das folgende Ecore-Diagramm zeigt die Modellelemente sowie die Attribute und Referenzen. Zwecks Übersichtlichkeit wurde auf die Darstellung der implementiert-

Beziehung zwischen allen Modellelementen (außer DatatypeContainer) und dem Inter-face NamedElement verzichtet.


63

Abbildung 18 - Diagramm des Pakets structure125

Beschreibung der Modellelemente Provider

Das Wurzelelement aller Service-Beschreibungen. Ein Provider enthält Metho-

den-Vorlagen (templateMethods), Endpunkte (endpoints) und Services (ser-

vices). Da ein Provider ein DatatypeContainer ist, enthält er Service-übergreifende Datentypen.

Endpoint

Ein Endpoint abstrahiert den Endpunkt, über den ein Service aufgerufen wer-den kann. Ein Service kann mehrere Endpunkte haben, beispielsweise einen öffentlichen und mehrere Firmen-interne Test-Endpunkte. Die Beschreibung der Art der Adressierung (z.B. über URLs) ist je nach Kommunikationstechno-logie unterschiedlich und daher Bestandteil der abgeleiteten Service-Modellelemente.

Service

Ein Service enthält Methoden (methods). Außerdem ist ein Service ein Data-

typeContainer und enthält dadurch Service-spezifische Datentypen.



64

Method

Eine Methode kann Parameter (parameters) und eine Antwort (response) ent-

halten. Parameter sind Felder (Field); Antworten bestehen ebenso aus mehre-ren Feldern.

Darüber hinaus kann eine Methode einer oder mehreren Vorlagen (templates) vom Typ MethodTemplate entsprechen.

MethodTemplate

Vorlagen (MethodTemplate) dienen zur vereinfachten Erfassung von Metho-

den. Vorlagen enthalten Felder (Field), welche vor oder nach Parametern (pa-

rametersBefore und parametersAfter) beziehungsweise vor oder nach den Fel-

dern der Antwortnachricht (responseBefore und responseAfter) zu setzen sind.

Beispiele für die Anwendung durch die Developer Garden-SDKs sind die Sta-tus-Informationen oder der account-Parameter.

Field

Ein Feld (Field) wird in verschiedenen vorgenannten Kontexten verwendet.

Ein Feld kann optional sein, eine Liste darstellen (multiple) oder beides.

Es gibt zwei Typen von Feldern:

ValueField

Ein ValueField ist ein typisiertes (dataType) Daten-Feld. Der Wert des Daten-

feldes kann vorbelegt sein (staticValue).

Dies könnte beispielsweise eine Versions-Nummer sein, die in jeder Nach-richt mit demselben Wert gesendet werden muss.126 Die Art der Serialisie-

rung des Attributs staticValue wird von den Generatoren bestimmt.

StructuredField

Ein StructuredField ist eine aus weiteren Feldern (Field) bestehende Daten-struktur. Das Serialisierungsformat (XML, JSON, Text, …) wird durch die jeweilige Kommunikationstechnologie festgelegt.

DataType

Ein Datentyp (DataType) legt den Typ eines Daten-Feldes (ValueField) fest.

Die konkreten Datentypen der jeweiligen Kommunikationstechnologie wer-den in den abgeleiteten Modellelementen definiert.

126 Vgl. den v-Parameter der Google Maps API: (Google Inc., 2011)


65

NamedElement

Ein benanntes Element ist ein Modellelement, welches die Schnittstelle NamedElement implementiert. Damit erhält das implementierende Element ein

Attribut name.

Um Redundanzen in der Modellierung zu reduzieren und eine generische Verarbeitung von Modellelementen zu ermöglichen wurde das Attribut in ein Interface ausgelagert.

DatatypeContainer

Ein DatatypeContainer ist ein Behältnis (dataTypes) für Datentypen (DataType).

Dabei sind sowohl Service, als auch Provider ein DatatypeContainer.

Die Modellierung eines DatatypeContainers dient der semantischen Unterschei-

dung zwischen Service-spezifischen und allgemeinen (Provider-spezifischen) Datentypen.

NamedElement

NamedElement definiert ein identifizierendes Attribut (name) von nahezu allen Metamodell-Elementen.

Generische Programmierung im structure-Paket

Alle Klassen sind abstrakt (abstract = true) und enthalten jeweils generische Typpa-rameter. Dadurch wird erzwungen, dass zur Definition einer konkreten Kommuni-kationstechnologie (REST, SOAP, etc.) nur alle Klassen des structure-Pakets gemein-sam abgeleitet werden können.

Am Beispiel des Method-Elements wird der Mechanismus deutlich

Abbildung 19 - Generische Typparameter127

Die Strukturelemente templates (Vorlagen), parameters (Parameter) und response

(Rückgabewerte) sind parametrisiert. Daher kann Method nicht abgeleitet werden, ohne die Typ-Einschränkungen der Parameter T und F zu erfüllen.



66

Um diese Einschränkungen zu erfüllen, müssen jedoch Field und MethodTemplate ab-geleitet werden, da beide abstrakt sind und somit nicht instanziiert werden können.

Da alle Modellelemente in structure abstrakt und parametrisiert sind, wird daher er-zwungen, alle Elemente abzuleiten.

Dadurch wird verhindert, dass Modellelemente unterschiedlicher Kommunikations-technologien gemischt verwendet werden.

Es existiert keine sinnvolle Alternative für die Definition von gemeinsamen, abstrak-ten Elementen aller Kommunikationstechnologien, als der vorgenannte Mechanis-mus.

Andere Alternativen wären:

Alternative 1: „Klassische“ Vererbungsbeziehung Eine aus anderen objektorientierten Sprachen bekannte Vererbungsbeziehung, d.h. überschreiben des Typs eines Feldes (z.B. Field durch RestField) in einer abgeleiteten

Klasse (z.B. RestMethod → Method), ist in Ecore nicht anwendbar128, da innerhalb ei-ner Klassenhierarchie nicht zwei strukturelle Eigenschaften mit gleichem Namen existieren können.

Alternative 2: Beibehaltung der Attribute und Typen in abgeleiteten Klassen Die gemeinsamen Elemente aller Kommunikationstechnologien könnten auch inklu-sive ihres Typs in den abgeleiteten Klassen beibehalten werden. Der Nachteil daran wäre, dass dann die Verarbeitung von REST-Modellelementen immer mit Typum-wandlungen einhergehen müsste, um z.B. die REST-spezifischen Attribute auszu-werten.

Beispielsweise müsste die parameters-Referenz in RestMethod von Field nach RestField typgewandelt werden, was die Lesbarkeit des Codes der funktionalen Erweiterun-gen deutlich beeinträchtigen würde.

4.1.2 Paket rest

Das Paket rest implementiert die Struktur-Modellelemente des structure-Pakets und stellt gleichermaßen eine Generalisierung des bisherigen Telekom Service-

Metamodells dar. Für das Paket rest existiert eine Xtext - Grammatik.

Im Folgenden werden die einzelnen Modellklassen beschrieben und ihre Implemen-

tierungsbeziehung durch ein → angegeben. Bei Modellklassen, die weder neue At-tribute einführen, noch die Semantik der geerbten Klasse verändern, wird zur Ver-meidung von Redundanzen auf eine ausführliche Beschreibung verzichtet.

128 (Merks, 2009)


67

RestProvider → Provider

RestEndpoint → Endpoint

Die Adressierung eines REST-Endpunkts geschieht durch das URI-Attribut.

RestService → Service, RestResource

RestMethod → Service, RestResource

Attribute einer REST-Methode sind die zu verwendende Übertragungsart der

Parameter (encoding), das HTTP-Verb (httpVerb), die Authentifizierungslogik (authorization), sowie die HTTP-Header (headers).

RestMethodEncoding

Die Übertragungsart der Parameter von REST-Methoden. Unterstützt werden Parameter in der URL sowie als HTTP-Formulardaten.

RestMethodAuthorization

Die Authentifizierungslogik einer REST-Methode. Unterstützt wird HTTP Ba-sic-Authentifikation, d.h. Authentifikation über Benutzername und Passwort.

Neben der Verwendung von RestMethodAuthorization besteht auch die Mög-lichkeit, einen HTTP Authorization-Header in der headers-Auflistung einer REST-Methode zu definieren und zur Laufzeit zu berechnen, wie beispiels-weise für die Developer Garden Token-Authentifizierung.

RestHttpVerbs

Eine Enumeration der möglichen HTTP-Verben129.

RestResource

REST-Ressourcen, also REST-Methoden (RestMethod) und REST-Services

(RestService) werden durch eine URL adressiert, welche aus der Konkatenation der URL des Endpunkts, sowie aller Pfadelemente (path) der jeweiligen Me-thode und des Services gebildet wird.

RestResourcePathElement

Ein REST-Ressourcenpfad-Element.

129 Siehe (Fielding, et al., 1999 S. 51-57)


68

RestResourcePathStaticElement

Ein statisches, d.h. nicht änderbares Element eines REST-Ressourcenpfades.

Der Wert des Elements wird über das name-Attribut festgelegt.

RestResourcePathDynamicElement

Ein variables Element eines REST-Ressourcenpfades. Der Datentyp des Ele-ments kann über das dataType-Attribut festgelegt werden.

RestMethodTemplate →MethodTemplate

Eine Vorlage für REST-Methoden.

Enthält gemeinsame HTTP-Header (headers), sowie voran- (pathElementsBefo-

re) und hintanzustellende (pathElementsAfter) Pfadelemente.

RestField → Field

RestValueField → RestField, ValueField<RestDataType>

RestStructuredField → RestField, StructuredField<RestDataType>

RestDataType → DataType

Im Gegensatz zum derzeitigen Framework, welches lediglich Zeichenketten als Methodenparameter akzeptiert, werden im REST-Modell zusätzliche Da-tentypen definiert. Dies ermöglicht die clientseitige Typprüfung innerhalb ei-nes SDKs und damit eine Formalisierung des erwarteten Formats von gesen-deten Nachrichten.

RestDataTypeStructured → RestDataType

Ein strukturierter REST-Datentyp, d.h. ein Typ mit Unterfeldern (fields).

RestDataTypeString → RestDataType

Eine Zeichenkette mit optional spezifizierbarem Zeichensatz (charset, stan-dardmäßig UTF-8). Im bisherigen Framework wurden Zeichenketten als ein-ziger Datentyp unterstützt.

RestDataTypeNumber → RestDataType

Ein numerischer Datentyp mit der Möglichkeit, den Wertebereich (length) an-zugeben. Außerdem kann bestimmt werden, ob es sich um eine vorzeichenlo-

se (signed=false) oder vorzeichenbehaftete (signed=true) Zahl handelt.


69

MetaNumberPrecision

Der Wertebereich einer Zahl, z.B. int8, int16 oder int32.

RestDataTypeBoolean → RestDataType

Ein boolescher Datentyp mit Spezifizierung der Zeichenkette für die Werte wahr (trueValue) und unwahr (falseValue). Standardmäßig werden die Zei-chenketten true und false als Serialisierung verwendet.

RestDataTypeEnum → RestDataType

Eine Enumeration. Unterstützt die Angabe des Serialisierungsformats der Werte (valueType), sowie der möglichen Einträge (entries).

RestEnumEntry

Ein Eintrag in einer Enumeration. Jeder Eintrag ist eine Schlüssel (key) – Wert

(value) Kombination.

RestDataTypeCustom → RestDataType

Ein benutzerdefinierter Datentyp, bestimmt durch eine Klasse der Zielsprache.

RestDataTypeFile → RestDataType

Ein Datei-Datentyp, welcher zur Abstraktion der unterschiedlichen Möglich-keiten dient, Dateien an eine REST-Schnittstelle zu versenden, beispielsweise als application/octet-stream innerhalb von HTML Form-Daten oder Base64-codiert als Parameter.

RestDatatypeContainer → DatatypeContainer<RestDataType>

4.1.3 Paket documentation

Das Paket documentation enthält alle Metamodell-Elemente zur Abstraktion von Do-kumentations-Artefakten und der Dokumentations-Generierung:

DocumentedElement

Alle Modellklassen, die das DocumentedElement-Interface implementieren, ver-fügen über eine Dokumentation vom Typ Documentation, welche über einen

DocumentationProvider abgerufen werden kann.

Der für ein Element zuständige DocumentationProvider ist über die documenta-

tionProvider-Referenz eines DocumentedElements abrufbar.


70

Die im GenerationREST-Framework implementierten Erweiterungen verein-fachen den Abruf des jeweiligen DocumentationProviders in der Form, dass der

jeweils übergeordnete DocumentationProvider verwendet wird, sollte die docu-

mentationProvider-Referenz leer (null) sein.

DocumentationProvider

Das Interface DocumentationProvider implementierende Modellklassen bieten

über die Methode retrieveDocumentation(…) die Möglichkeit, für ein Documen-

tedElement (Parameter element) einen bestimmten Typ von Dokumentation (Parameter type) in einer Sprache (Parameter language) abzurufen.

Documentation

Ein Documentation-Element stellt einen bestimmten Typ von Dokumentation (Parameter type) für ein bestimmtes DocumentedElement (Attribut element) in

einer bestimmten Sprache (Attribut language) dar.

Der Inhalt der Dokumentation (Attribut docbook) ist immer ein Docbook XML-Element, gleich welcher Mechanismus zum Abrufen der Dokumentation angewendet wird.

DocbookDocumentationProvider

Eine abstrakte Implementierung eines DocumentationProviders auf Basis von

Quelldateien im Docbook XML-Format (contentFiles).

GenerationREST enthält Xtend 2.0 – Extensions zur deutlichen Vereinfachung von konkreten DocbookDocumentationProvider Implementierungen, die bei-

spielsweise die Extension-Methode applyXpath bereitstellen, welche die An-wendung von XPath-Ausdrücken auf die Quelldateien ermöglicht.

DocumentationType

Der Typ einer Dokumentation. Derzeit sind „Titel“ (Title=0), „Beschreibung“

(Description=1) und „Konzeptionelle Dokumentation“ (ConceptualDocumentati-

on=2) vorgesehen.

Die Konzeption des Pakets documentation ermöglicht eine flexible Implementierung der unterschiedlichen Vorgehensweisen zum Abruf der Dokumentation eines do-kumentierten Elements.

Die Vereinbarung, dass gleich welcher Vorgehensweise zum Abruf der Dokumenta-tion die konkrete Dokumentation immer im Docbook XML-Format vorliegen muss, vereinfacht die Implementierung der Überführung der Dokumentation in Quellcode-Kommentare und konzeptionelle Dokumentation.


71

Da in jeder Zielsprache unterschiedliche Dokumentations-Repräsentationsformate verwendet werden (z.B. JavaDoc, MAML, XML-Kommentare), muss durch diese Vereinbarung immer nur eine Transformation (von Docbook nach Zielformat) im-plementiert werden, und nicht mehrere (z.B. von Docbook, WikiText, Text, etc.).

4.1.4 Paket generation

Das Paket generation enthält Elemente zur Abstraktion und Konfiguration des Gene-rierungsvorganges von Ziel-Artefakten (z.B. SDKs und Dokumentation). Für die Elemente des Pakets generation steht eine Xtext-Grammatik zur Verfügung.

GenerationConfiguration

Das Wurzelelement einer Konfiguration für einen Generierungsvorgang.

Enthält importierte Elemente (imports), Parameter zur Steuerung des Generie-

rungsvorganges (parameters), sowie konfigurierte Generatoren (generators).

Import

Eine Referenz auf ein importiertes Element. Das Element wird über das Attri-but importURI referenziert. Diese Modellierung stellt eine Implementierung des Standard-Vorgehens unter Xtext 2.0 zur Referenzierung externer Ressourcen dar.130

Die Referenzierung ermöglicht den Zugriff auf REST-Schnittstellenbeschreibungen aus Konfigurationsdateien eines Generierungs-vorganges.

SDKGenerator

Ein abstrakter SDK-Generator. Über die Methode generate() wird der Generie-

rungsvorgang gestartet. Der Generierungsvorgang kann durch Parameter (pa-

rameters) beeinflusst werden.

Die Xtend 2.0 – Referenzimplementierung eines SDKGenerators schreibt alle Dateien (files) in die durch GeneratorParamOutlet-Parameter konfigurierten Ausgabeverzeichnisse. Die konkreten Generator-Implementierungen legen die Art fest, wie files berechnet wird.

130 „ImportURI Mechanism“: (Behrens, 2011A)


72

Mit SDKGeneratorComponent131 steht eine MWE2-Komponente bereit, welche die Generation anhand einer Konfiguration aus einem MWE2-Workflow her-aus starten kann.

GeneratorParam

Ein Generierungs-Parameter. Steuert den Generierungsvorgang.

GeneratorParamGenerationSelection → GeneratorParam

Legt die zu generierenden Services (servicesOfEndpoint) und den anzuspre-

chenden Endpunkt (endpoint) fest.

GeneratorParamLanguage → GeneratorParam

Die zu generierende Sprache (language).

GeneratorParamOutlet → GeneratorParam

Das Verzeichnis (directoryUri), in welches die Ausgabedateien der Generierung gespeichert werden sollen.

GeneratorParamPackageNameTemplate → GeneratorParam

Die Vorlage (template) für die zu generierenden Paketnamen. Die Zeichenkette {service} wird durch den Namen des jeweiligen Service-Pakets ersetzt.

Das Modellelement wird je Zielsprache überschrieben.

GeneratorParamCollection

Eine Sammlung von Generierungs-Parametern. Dies ist entweder ein konkre-tes Behältnis (GeneratorParamContainmentCollection) oder eine Referenz auf eine

andere Sammlung (GeneratorParamCollectionLink).

Diese Abstraktion wurde gewählt, um eine möglichst flexible Abbildung aller gewünschten SDK Generations-Konfigurationen zu ermöglichen.

GeneratorParamContainmentCollection → GeneratorParamCollection

Ein Behältnis für Generierungs-Parameter. Kann Parameter (parameters) und

Referenzen auf andere Sammlungen (links) enthalten.

131 Paket org.generationrest.framework.components


73

GeneratorParamCollectionLink → GeneratorParamCollection

Ein Verweis auf ein oder mehrere Parameter-Sammlungen (parameterCollec-

tions).

Zu den vorgenannten Modellklassen werden im Zuge der vollständigen Realisierung des Frameworks sicherlich noch weitere Klassen definiert. Unter anderem ist vorge-sehen, dass bestimmte REST-Parameter als „Client-persistent“ deklariert werden können, sodass diese Parameter bei der Laufzeit-Instanziierung der Service-Clients angegeben, immer mit demselben Wert verwendet werden. Geeignet dafür ist unter anderem der environment-Parameter der Developer Garden APIs, d.h. die Angabe der zu verwendenden Umgebung.

Unterpaket java

Das Unterpaket java implementiert prototypisch Elemente zur Generierung eines Ja-va-SDKs:

JavaGeneratorParam → GeneratorParam

Ein Generierungs-Parameter für einen Java SDK-Generator.

JavaSDKGenerator → SDKGenerator

Ein Java SDK-Generator. Das Verhalten des Generators wird per Xtend 2.0 Ex-tension implementiert.132

CompatibilityLevel → JavaGeneratorParam

Generierungs-Parameter, der die zu erfüllende Java-Kompatibilität (level) an-gibt.

JavaPackageNameTemplate → GeneratorParamPackageNameTemplate

Die Vorlage zur Generierung der Paketnamen für ein Java-SDK, beispielswei-se „com.telekom.api.{service}“.

JavaSDKCompatibilityLevel

Enumeration der möglichen Java-SDK Kompatibilitätsebenen, z.B. Java 1.4

(OneFour=4), Java 1.5 (OneFive=5) oder Java 6.0 (Six=6).

132 org.generationrest.framework.extensions.generation.java.JavaSDKGeneratorExtension


74

Weitere Unterpakete Während der prototypischen Realisierung des Frameworks wurden noch keine wei-teren Unterpakete definiert. Allerdings ist vorgesehen, je Zielsprache ein Unterpaket zu bilden.

4.1.5 Paket sdk

Das Paket sdk setzt die Modellierung der Zielsprachen, eine der Vorgaben des neuen Lösungsansatzes um.

Basisklassen der Modellierung befinden sich im Unterpaket general:

Generatable

Das Basis-Interface aller Generierungs-Artefakte. Ein Generierungs-Artefakt wird dadurch gekennzeichnet, dass es generierbaren Inhalt (content) besitzt.

File → Generatable

Eine Datei ist ein Generierungs-Artefakt mit Dateipfad (path). Der Pfad ist re-lativ zu einem konfigurierten Ausgabeverzeichnis eines Generators.

Unterpaket java Das Unterpaket java enthält im Prototyp 27 Modellklassen zur Abbildung der Struk-tur des Java-SDKs. Die Modellierung und die Xtend 2.0 – Implementierung des Ver-haltens der Modellklassen orientiert sich an der vorhandenen Struktur des Java-SDKs.

Alle Modellklassen vorzustellen, würde den Rahmen des Kapitels überschreiten, al-lerdings werden im Folgenden einige Modellierungsaspekte des java-Unterpakets dargestellt.

Rolle der JavaModule-Modellklasse

Die JavaModule-Modellklasse reduziert Redundanzen in den bisherigen Code-Templates erheblich, indem die Gemeinsamkeiten aller Klassen und Interfaces des Java-SDKs abstrahiert werden und ein allgemeines M2T-Template für Java-Quellcode definiert wird.

JavaModule ist vom Typ File, d.h. der generierte Inhalt wird in Dateien überführt.

Durch das Überschreiben der getPath-Methode wird der Pfad einer Java-Quelldatei durch den Paketnamen (package) bestimmt, der wiederum von den Unterklassen überschrieben wird.

Weiterhin enthält ein JavaModule eine Liste von Methoden (methods) und Feldern

(fields). Die konkrete Aufzählung wird in den Unterklassen überschrieben und richtet sich nach dem jeweiligen SDK-Bestandteil.


75

Das Text-Template der JavaModule-Modellklasse kann den Inhalt eines Moduls gene-rieren, da z.B. alle Methoden von JavaMethod erben und dort die notwendigen In-formationen zur Generierung zur Verfügung stehen.

Unterklassen von JavaModule sind beispielsweise Java-Datenklassen (DataClass), Ser-

vice-Interfaces (ServiceInterface) und –Implementierungen (ServiceImplementation).

Abstraktion von Typen

Das Interface TypedElement kennzeichnet ein typisiertes Java-Element, z.B. ein Feld oder eine Methode. Zur Abstraktion der verwendeten Typen stehen drei Modellklas-sen zur Verfügung. Zum einen elementare Typen (JavaElementaryType), beispielsweise int oder boolean. Darüber hinaus werden Typen aus der JVM (JavaFrameworkType)

mithilfe des Paketnamens (package) gekennzeichnet. Typen aus dem SDK werden als

JavaSdkType abstrahiert, die das jeweilige JavaModule über die Referenz module refe-renzieren. Außerdem existiert der Typ JavaCollectionType, welcher eine Sammlung

(Array, Liste, …) von Elementen des jeweils referenzierten JavaTypes darstellt.

Abstraktion der Abbildung von REST-Elementen

Im Java-SDK existieren Datenklassen (DataClass) zur Abbildung unterschiedlicher REST-Elemente. Die Datenklassen sind dabei jeweils gleich aufgebaut: sie enthalten private Felder, sowie Getter- und Setter-Methoden zum Abfragen und Setzen dieser Felder. Darüber hinaus enthalten Datenklassen Methoden zur Serialisierung und De-serialisierung in das JSON-Format.

Jede Datenklasse enthält ein DataMapping<D> - Element, welches eine Referenz

(mappedElement) auf das abzubildende REST-Element (vom Typ D) enthält. Durch die Modellierung dieses Elements wird ermöglicht, dass für alle Datenklassen nur ein Template implementiert werden muss.

Im java-Paket existieren die folgenden Modellelemente:

• DataMappingMethodResponse → DataMapping<RestMethod>

Abbildung des Rückgabetyps einer REST-Methode

• DataMappingRestDataType → DataMapping<RestDataType>

Abbildung eines strukturierten REST-Datentyps

• DataMappingRestStructuredField → DataMapping<RestStructuredField>

Abbildung eines strukturierten REST-Feldes

Es ist anzunehmen, dass während der Realisierung des gesamten Frameworks noch Modellklassen zum Paket java hinzugefügt werden.


76

Weitere Unterpakete Während der prototypischen Realisierung des Frameworks wurden noch keine wei-teren Unterpakete definiert. Allerdings ist vorgesehen, je Zielsprache ein Unterpaket zu bilden.

4.2 Realisierungsmöglichkeiten funktionaler Erweiterungen

Das derzeitige Telekom-Framework enthält keine Abbildung von Elementen der Zielsprachen – das Service-Modell wird direkt in Code der Zielsprachen umgewan-delt. Die Einführung der Modellierung der Zielsprachen-Artefakte im neuen Genera-tionREST-Framework hingegen strukturiert die Zielsprachen-Artefakte und macht ihre Eigenschaften deutlich. Es ergibt sich allerdings die Fragestellung, wie die Attri-but-Werte und referenzierte Elemente aus dem REST Service-Modell ermittelt wer-den können.

Zur Lösung dieser Fragestellung bieten sich in der Regel eine Modell zu Modell (M2M) – Transformation an: Die Zielsprachen-Elemente werden in einer Transforma-tion erstellt und ihre Attribut-Werte und referenzierten Elemente innerhalb dieser Transformation aus dem Service-Modell ermittelt. Ein großer Nachteil an M2M-Transformationen ist jedoch die Trennung des Mechanismus zur Ermittlung von At-tribut-Werten & Referenzen und dem jeweiligen Modell-Element. Dieser Nachteil kann in Teilen umgangen werden, indem die Zielsprachen-Elemente selbst die Er-mittlung anhand vorgegebener Ursprungselemente vornehmen.

Für die Implementierung einer solchen Ermittlung durch die Zielsprachenelemente stehen mehrere Möglichkeiten zur Verfügung, die nachfolgend analysiert werden:

Änderung des generierten EMF-Codes Die auf Basis der Ecore-Modellelemente generierten EMF Java-Klassen ermöglichen eine Änderung aller Methodenkörper. Durch das Entfernen des @generated – Tags wird der geänderte Code bei weiteren EMF-Generierungsläufen beibehalten. Aller-dings muss so der gesamte generierte EMF-Code unter Versionsverwaltung gestellt werden, um die Änderungen der Methodenkörper beizubehalten.

Da der EMF Code-Generator bei Änderungen am Metamodell das Entfernen von überflüssigem Code in den generierten EMF Java-Klassen nicht unterstützt, entste-hen erhöhte Aufwände bei der Pflege des Metamodells, da der generierte Code ma-nuell angepasst werden muss.

Außerdem müssten bei der Verwendung von Xtend 2.0 für die Implementierung des geänderten Verhaltens an zwei Stellen Code gepflegt werden: Einmal der Aufruf ei-ner Xtend 2.0-Methode in den EMF-Klassen und an einer anderen Stelle die Imple-mentierung der Berechnung selbst.


77

Nutzung von EMF-Annotationen Das EMF ermöglicht die Spezifizierung von Programmcode in Metamodell-Annotationen.133 Dies ermöglicht die Versionierung der Implementierung von Mo-dellklassen-Verhalten zusammen mit dem Modell – die generierten EMF-Klassen müssten dabei nicht versioniert oder Teile davon manuell gepflegt werden.

Allerdings unterstützt das EMF lediglich die Spezifizierung von Programmcode für modellierte EMF-Methoden und nicht für Java-Getter und -Setter. Daher müsste die Überschreibung von Gettern und Settern dennoch über Änderungen an generierten EMF-Code stattfinden und der vorgenannte Vorteil würde entfallen.

Darüber hinaus gibt es keine IDE-Unterstützung für die Spezifizierung von Pro-grammcode in Metamodell-Annotationen, sowie das Erfassen von Import-Anweisungen.

Ableitung von generierten EMF-Klassen Die Implementierung von aus generierten EMF-Klassen abgeleiteten Java-Klassen und die Überschreibung von Verhalten in diesen Klassen ist eine weitere Möglich-keit, Verhalten von Metamodell-Klassen zu spezifizieren.

Allerdings müssten alle generierten EMF-Klassen eines Pakets abgeleitet werden, um die Vererbungshierarchie korrekt abzubilden. Daher würde bei diesem Vorgehen erheblicher Implementierungsaufwand entstehen.

Verwendung von aspektorientierter Programmierung (AOP) Aspektorientierte Programmierung stellt eine weitere Möglichkeit dar, Verhalten von Metamodell-Klassen zu implementieren. Dies geschieht in der Regel in zwei Schrit-ten: zuerst wird das neue Verhalten implementiert, danach wird die verwendete Technologie angewiesen, die neue Implementierung anstatt der Implementierung der Metamodell-Klassen zu verwenden.

Die Anpassung von Verhalten von Metamodell-Klassen über aspektorientierte Pro-grammierung bietet den Vorteil der Trennung zwischen implementiertem Verhalten und den überschriebenen Metamodell-Klassen. Diese Trennung führt allerdings auch zu einer verschlechterten Nachvollziehbarkeit des Verhaltens und dadurch einer teilweisen Erschwerung der Fehlersuche. Außerdem ist die Konfiguration der Tech-nologien teilweise relativ komplex.

133 (Steinberg, et al., 2008 S. 141)


78

Untersuchte Technologien zur Umsetzung dieser Aspektorientierung sind:

Object Teams Object Teams134 ist eine Erweiterung der Java-Programmiersprache zur Unterstüt-zung rollenbasierter und aspektorientierter Programmierung. Die Weiterentwick-lung geschieht hauptsächlich durch die TU Berlin, Fraunhofer FIRST und eine große Anzahl an Studien- und Abschlussarbeiten135.

Object Teams ist eine durchaus funktionsreiche und anwendbare Technologie. Aller-dings ist die Grundkonzeption und Anwendung der Technologie relativ komplex. Außerdem ist nicht zu erkennen, inwieweit die Technologie außerhalb des universi-tären Umfelds in Praxi - beispielsweise bei großen Softwarehäusern - Anwendung findet. Darüber hinaus zeigt eine Beispielanwendung eine relativ hohe Komplexität im Zusammenspiel mit anderen Bestandteilen des EMF.136

Aus diesen Gründen wird Object Teams in GenerationREST nicht verwendet.

Google Guice Google Guice137 ist ein Dependency Injection – Framework mit AOP-Funktionalität. Da die zur Implementierung von Verhalten von Metamodell-Klassen eingesetzte Technologie Xtend 2.0 Google Guice als DI-Framework verwendet, ist es nahelie-gend, Google Guice auch zur aspektorientierten Implementierung von Verhalten von Metamodell-Klassen zu verwenden.

Allerdings kann Google Guice nur die Klassen aspektorientiert erweitern, die vom Framework instanziiert werden. Im Regelfall wäre davon auszugehen, dass das Xtext-Framework, welches für das Laden des Service-Modells und damit der Instan-ziierung der Metamodell-Klassen zuständig ist, diese Instanziierung über Google Guice vornimmt und damit auch die aspektorientierte Erweiterung des Verhaltens möglich ist.

Nach einer intensiven Prüfung stellte sich allerdings heraus, dass die entscheidende Anweisung an die EMF-Factory zur Erzeugung einer Metamodell-Klasse nicht vom Google Guice – Framework erfolgt.

Daher kann entgegen der Erwartung Google Guice nicht für diese Aufgabenstellung angewendet werden.

134 (Herrmann, 2011) 135 Vornehmlich der TU Berlin: (Technische Universität Berlin, 2011) 136 Anwendung von Object Teams zur aspektorientierten Anpassung von EMF-Editoren: (Böttge, 2009) 137 (Google Inc., 2011B)


79

AspectJ AspectJ138 ist ein Framework zur Erweiterung von Java um aspektorientierte Pro-grammierung. Hauptunterstützer des Projekts sind IBM, SpringSource, die Universi-ty of British Columbia, sowie Oracle (vormals BEA Systems Inc.).

AspectJ unterstützt die Konfiguration und Implementierung von Aspekten sowohl über eine eigene AspectJ-Sprache, als auch über Java-Annotationen. Gerade die Im-plementierung von Aspekten über herkömmlichen Java-Code vereinfacht den Um-gang mit der Technologie erheblich.

Aufgrund der Zugänglichkeit, Leistungsfähigkeit und der Bewährung der Technolo-gie in Praxi wird im GenerationREST-Frameworks AspectJ verwendet.

4.3 Umsetzung der funktionalen Erweiterungen in GenerationREST

Im GenerationREST-Framework wird ein hybrider Ansatz zwischen Transformation und aspektorientierter Implementierung von Verhaltensänderungen realisiert: Die generate()-Methode der Code-Generatoren stellt den Startpunkt einer eingeschränk-ten M2M-Transformation dar. Anhand des Ausgangsmodells und der Generations-Konfiguration werden die Modellklassen der Bestandteile eines SDKs instanziiert und über die files-Auflistung bereitgestellt. Allerdings werden nur die Attribute und Referenzen initialisiert, die ein Metamodell-Element zwingend benötigt, um daraus die restlichen modellierten Attribute und Referenzen herzuleiten. Diese Herleitung geschieht durch per Aspektorientierung überschriebene Getter-Methoden zur Lauf-zeit.

Beispielsweise werden durch den Code-Generator Datenklassen (DataClass) für alle Datentypen, Methoden-Rückgabewerte und strukturierte REST-Felder instanziiert. Die Instanziierung speichert das jeweilige abzubildende REST-Element in der Daten-klasse. Alle anderen Eigenschaften dieser Datenklasse, wie Name, Sichtbarkeit, ent-haltene Methoden und Felder werden zur Laufzeit bei Abruf der Getter-Methoden aus dem REST-Element durch eine per Aspektorientierung aufgerufene Xtend 2.0 Methode berechnet.

Implementierung des AspectJ-Aspekts ImplementedByExtensionMethodAspect139 Der AspectJ-Aspekt ImplementedByExtensionMethodAspect prüft bei jedem Auf-ruf einer Metamodell-Methode zur Laufzeit, ob eine bestimmte Xtend 2.0 Klasse in-nerhalb eines entsprechenden Framework-Pakets existiert, die zur Überschreibung von Verhalten definiert wurde.

138 (The Eclipse Foundation, 2011C) 139 Paket org.generationrest.metamodel.aspects


80

Diese Prüfung vergleicht die Klassenhierarchie, den Klassen- und den Methodenna-men auf Übereinstimmung, sowie die Typ-Übereinstimmung zwischen dem ersten Parameter der Ziel-Methode und der Metamodell-Klasse.140

Um das Laufzeitverhalten zu verbessern, werden alle Überprüfungsergebnisse zwi-schengespeichert. Außerdem ermöglicht eine integrierte Typumwandlung, die Xtend 2.0 „Rich String“-Funktion auch zur Implementierung von Methoden zu verwenden, die java.lang.String zurückgeben.

Bewertung und Ausblick Der Aspekt ImplementedByExtensionMethodAspect ermöglicht die Veränderung von Metamodellklassen-Verhalten durch Xtend 2.0 – Extensions.

Das Besondere daran ist, dass dies ohne spezielle Konfiguration ermöglicht wird: Durch das Vorhandensein einer Methode in einer Klasse, die bestimmte Konventio-nen erfüllt, wird diese Methode automatisch anstatt der Metamodell-Methode ver-wendet. Dies ist ein großer Vorteil gegenüber herkömmlichen Ansätzen.

Derzeit ist das Extension-Paket im Quellcode konfiguriert. Um den Lösungsansatz „Anpassbarkeit und Erweiterbarkeit des Frameworks“ umzusetzen, wird die Konfi-guration, welche Pakete nach Extension-Methoden durchzusuchen sind, externali-siert, sodass auch Erweiterungen durch Dritte an GenerationREST möglichst einfach möglich werden.

Erweiterung um Hook-Mechanismus Darüber hinaus ist angedacht, nicht nur eine Überschreibung von Verhalten zu er-möglichen, sondern auch eine Veränderung. Hierfür soll ein Hook-Mechanismus implementiert werden, der das Ergebnis einer aufgerufenen Methode an eine andere Extension-Methode weiterleitet und somit die nachträgliche Veränderung von ande-ren Extension-Methoden ermöglicht.

Insgesamt ist zu hoffen, dass durch den gewählten hybriden, aspektorientierten Me-chanismus eine hohe Anpassbarkeit des Frameworks mit niedrigem Implementie-rungsaufwand erreicht werden kann.

4.4 Grammatiken

Um den Lösungsansatz „Modelldefinition über textuelle DSL“ umzusetzen, wurden zwei Xtext 2.0 – Grammatiken für die Beschreibung des Service-Modells, sowie der Generations-Konfiguration definiert. Bei der Konzipierung und Implementierung der Grammatik wurden eine intuitive Erfassbarkeit und möglichst geringer Aufwand bei der Definition eines REST-Services als Leitlinien verfolgt.

140 Grafische Darstellung des Mechanismus: Siehe Anhang 2


81

Eine grafische Übersicht der Grammatik kann über die Xtext 2.0 – Ansicht „Xtext Syntax Graph“ abgerufen werden:

Abbildung 20 - "Xtext Syntax Graph" (Ausschnitt)141

4.4.1 Service-Grammatik Wurzelelement der Grammatik ist ein benanntes Provider-Element. Hiernach folgt die Deklaration von Typen, Vorlagen, Endpunkten und Methoden, wie in den fol-genden Abschnitten dargestellt.

Typ-Deklaration Eine beispielhafte Deklaration fast aller möglichen Service-Typen lautet beispielhaft wie folgt:

Types { DGString String (charset: "utf-8") DGNumber Numeric (signed int16) DGBool Boolean ("1", "0") DGFile File Environment Enum DGString { production : "production" sandbox : "sandbox" mock : "mock" } DeveloperGardenStatus { DGString statusCode DGString statusMessage } }

Abbildung 21 - Typ-Deklaration (Beispiel)142

Die Deklaration hat dabei folgende Syntax:

<Typname> <Typ> [<Optionen>]

141 Eigene Darstellung (Datei: ServiceDsl.xtext im Paket org.generationrest.dsl) 142 Eigene Darstellung aus developergarden.servicedsl


82

Optionen sind fakultativ, je nach Typ unterschiedlich und folgen intuitiv dem REST Service-Modell.

Vorlagen-Definition Eine Definition von Methoden-Vorlagen lautet beispielhaft wie folgt:

| /{Environment : environment} => TemplateMethod DGMethod { headers { DGString Accept "application/json" DGString "User-Agent" "Telekom Java SDK/4.0" DGString Authorization } responseBefore { DeveloperGardenStatus status } } }

Abbildung 22 - Vorlagen-Definition (Beispiel)143

Die erste Zeile folgt dem Muster:

<Rest-Pfadvorlage> => TemplateMethod <Vorlagen-Name> { <Details> }

Die Rest-Pfadvorlage folgt dem Muster:

[<Pfadelemente vor Vorlage>] | [<Pfadelemente nach Vorlage>]

Die Syntax der Pfadelemente wird in der Beschreibung des Service-Modells näher erläutert.

Die Definition der Bestandteile einer Vorlage, also HTTP Kopfdaten (headers), Para-meter (parametersAfter, parametersBefore) und Rückgabewerte (responseAfter, respon-seBefore) entspricht der gleichen Syntax, wie die der Methoden-Deklaration.

Endpunkt-Deklaration Eine Endpunkt-Deklaration lautet beispielhaft wie folgt:

Endpoint odg "https://gateway.developer.telekom.com" { voiceCall conferenceCall autoScout24 ipLocation quota sendSms sendMms smsValidation }

Abbildung 23 - Endpunkt-Deklaration (Beispiel)144

143 Eigene Darstellung aus developergarden.servicedsl


83

Die Syntax ist intuitiv:

Endpoint <Name> "<URL>" { <Liste von Services> }

Service- und Methoden-Deklaration Eine Service- und Methoden-Deklaration lautet beispielhaft wie folgt:

/rest-v1/tokens/odg => Service secureTokenService { GET => Method getToken { authorization usernamePassword headers { DGString Accept "application/json" DGString "User-Agent" "Telekom Java SDK/4.0" } response { DGString tokenFormat DGString tokenEncoding DGString token } } }

Abbildung 24 - Service- und Methoden-Deklaration (Beispiel)145

Die Syntax der Service-Deklaration lautet:

[<Ressourcen-Pfad>] => Service <Service-Name> { <Methoden und Typen des Services> }

Der Ressourcen-Pfad besteht aus einer Verkettung von statischen und dynamischen Bestandteilen.

Statische Bestandteile werden wie folgt angegeben:

/<Name>

Dynamische Bestandteile können typisiert sein und werden wie folgt angegeben:

/{<Name> [: <Typ>]}

Eine Service-Deklaration folgt der folgenden Syntax:

<HTTP-Verb> [<Ressourcen-Pfad>] => Method <Name> { <Details> }

Unter Details fallen die Definition des Authentifizierungs-Mechanismus, sowie die Angabe von HTTP-Header, Parameter und Rückgabewerten.

144 Eigene Darstellung aus developergarden.servicedsl 145 Eigene Darstellung aus developergarden.servicedsl


84

Der optionale Authentifizierungsmechanismus HTTP Basic, d.h. Authentifizierung über Benutzernamen und Passwort kann derzeit nur wie folgt angegeben werden:

authorization usernamePassword

Die Einleitung der weiteren Details beginnt mit dem jeweiligen Schlüsselwort für HTTP-Header (headers), Parameter (parameters) und Rückgabewerte (response) und beinhaltet die Definition von REST-Feldern. Diese REST-Felder können bei Parame-tern und Rückgabewerten sowohl typisiert, als auch strukturiert sein. Die Liste der HTTP-Header unterstützt nur typisierte Felder.

Typisierte REST-Felder werden mit einer der folgenden Syntaxen deklariert:

<Typ> <Name> <Typ>[] <Name> <Typ> <Name>? <Typ>[] <Name>?

Das „[]“ hinter der Typ-Definition kennzeichnet ein Datenfeld (Array), das „?“ hin-ter dem Feld-Namen ein optionales Feld.

Strukturierte REST-Felder werden mit einer der folgenden Syntaxen deklariert:

<Name> { <Unterfelder> } <Name>[] { <Unterfelder> } <Name>? { <Unterfelder> } <Name>[]? { <Unterfelder> }

Die Semantik von „[]“ und „?“ bleibt unverändert, lediglich die Position des Kenn-zeichners ändert sich.

4.4.2 Konfigurations-Grammatik Eine Generations-Konfiguration besteht aus Parametern und Generatoren. Eine bei-spielhafte Generations-Konfiguration lautet wie folgt:

import "developergarden.servicedsl" Configuration { parameters { general { endpoint odg { sendSms sendMms smsValidation voiceCall conferenceCall ipLocation autoScout24 speechToText quota } endpoint sts { secureTokenService } } java { JavaPackageNameTemplate "com.telekom.api.{service}"


85

} java_de { ref java, general language "de" outlet "c:\\daten\\runtime-EclipseApplication\\servicedsl.test\\output\\" } } generators { JAVA developergarden_sdk_java_de { ref java_de } } }

Abbildung 25 - Generations-Konfiguration (Beispiel)146

Einer Konfiguration stehen ein oder mehrere Import-Direktiven vor. Diese Direkti-ven ermöglichen die Bezugnahme der Generations-Konfiguration auf ein oder meh-rere Service-Modelle.

Die Syntax einer Import-Direktive lautet wie folgt:

import "<Relativer Pfad zur importierenden Datei>"

Hiernach folgt die Konfiguration der Parameter und Generatoren. Die Syntax lautet:

Configuration { parameters { <Parameter> } generators { <Generatoren> }

Die Auflistung <Parameter> enthält Behältnisse für Generierungs-Parameter. Die Syn-tax für ein Behältnis lautet:

<Name des Behältnisses> { <Enthaltene Parameter und Verweise > }

Für jeden möglichen Parameter ist eine Syntax definiert, die meist mit einem Schlüs-selwort beginnt (z.B. language für die Konfiguration der Sprache) und danach den Wert des Parameters erwartet (z.B. eine Zeichenkette "de" für „Deutsch“).

Eine besondere Rolle kommt der Konfiguration der zu generierenden Services und Endpunkte zu. Diese Syntax lautet wie folgt:

endpoint <Endpunkt-Name> { <Zu generierende Services des Endpunkts> }

146 Eigene Darstellung, Datei: developergarden.generationdsl


86

Die Auto-Vervollständigung der Liste der zu generierenden Services wurde durch eine selbstdefinierte Methode147 angepasst, sodass der generierte Xtend-Editor für die Liste der zu generierenden Services nur die Services zur Auto-Vervollständigung anbietet, die auch tatsächlich laut dem referenzierten Service-Modell an dem ange-gebenen Endpunkt zur Verfügung stehen.148

Verlinkungen zu anderen Parameter-Behältnissen werden wie folgt deklariert:

ref <Name des verlinkten Parameter-Behältnisses>

Die Deklaration eines Generators lautet wie folgt:

<Schlüsselwort> <Name des Generators> { <Parameter> }

Das Schlüsselwort gibt die Art des zu instanziierenden Generators an, z.B. JAVA für einen Java-SDK – Generator. Die Syntax der Parameter wurde bereits erläutert.

4.5 Code-Generatoren

Um den Lösungsansatz „Modellierung der Zielsprachen“ umzusetzen, existieren in GenerationREST Zielsprachen-Modellelemente, welche die Struktur der zu generie-renden SDKs abbilden. Die Eigenschaften (d.h. Attribute und Referenzen) dieser Zielsprachen-Modellelemente, also auch der letztendliche Programmcode, werden aspektorientiert über Xtend 2.0 – Extensions implementiert. Dadurch ergibt sich auf der einen Seite eine deutlich bessere Strukturierung der Code-Generierung und au-ßerdem eine Einschränkung der Redundanzen in den Quellcode – Vorlagen.

Ein GenerationREST Code-Generator besteht daher einerseits aus einer Menge von Modellelementen der Zielsprachen, implementiert und erweitert durch Xtend 2.0 – Extensions, sowie einer von SDKGenerator abgeleiteten Klasse, welche auf Basis der jeweiligen Generations-Konfiguration festlegt, welche konkreten Zielsprachen-Elemente in Code zu überführen sind.

Die Struktur der SDKs soll im fertiggestellten GenerationREST-Framework möglichst gleich zu den bisherigen SDKs sein, da sich deren Struktur in Praxi bewährt hat und viele Problemfelder149 adressiert. Dies vereinfacht auch die Übernahme von Teilen der bisherigen Code-Templates. Die restlichen Bestandteile der derzeitigen Code-Generatoren werden in Hinblick auf den neuen, universalen Ansatz angepasst.

147 Methode scope_GeneratorParamGenerationSelection_servicesOfEndpoint(…) der Klasse

org.generationrest.dsl.scoping.GenerationDslScopeProvider 148 Mechanismus-Beschreibung in Sektion „Declarative Scoping“ in (Behrens, 2011A) 149 Siehe Kapitel 3.3 (S. 46)


87

Im Prototyp wurde der Java SDK-Generator insoweit implementiert, dass mithilfe des generierten Codes erste Aufrufe von Methoden der Developer Garden REST-API möglich sind. Hierdurch wird exemplarisch dargestellt, wie die beschriebene Über-nahme, Anpassung und Generalisierung von bisherigen Code-Templates möglich ist.

4.6 Dokumentations-Generator

Die Darstellung des Metamodell-Pakets documentation beschreibt das Konzept der Abstraktion von Dokumentations-Artefakten und der Dokumentations-Generierung.150

Im Zuge der Fertigstellung des GenerationREST-Frameworks wird die Klasse Docbo-

okDocumentationProvider abgeleitet und mithilfe der von dieser Klasse bereitgestellten Funktionalität die konkrete Vorgehensweise zur Ermittlung von Dokumentation aus dem Telekom Docbook Content-Repository implementiert. Darüber hinaus werden die Code-Generatoren um die Generierung von Code-Dokumentation erweitert, um die ermittelte Dokumentation in die SDKs zu übernehmen.

Zudem wird ein Generator konzipiert und realisiert, welcher auf Basis einer über-führten Docbook-Vorlage die Developer Garden Benutzerdokumentation generiert.

Aufgrund der neuen Möglichkeiten von Xtend 2.0 und der verbesserten Integration von Xtend 2.0, EMF und Java ist mit einer vereinfachten Implementierung der Do-kumentations-Generierung zu rechnen.

4.7 Weitere Komponenten

Generations-Workflow Der Generations-Workflow wird je nach Anwendungsgebiet und Framework-Anpassungen teilweise erheblich differieren und sollte daher anwenderspezifisch implementiert werden.

Zur Unterstützung dieser Implementierung wird ein Beispiel-Workflow bereitge-stellt, der dann je nach Bedarf geändert und übernommen werden kann. Dieser Workflow beinhaltet eine Beispiel-Komponente zum Aufruf von generate() – Metho-den der jeweils konfigurierten GenerationREST-Generatoren.

150 Siehe Kapitel 4.1.3 (S. 75)


88

Erstellvorgang Das bisherige Framework bildet den Erstellvorgang der jeweiligen SDKs über einen modularisierten ANT-Workflow ab. ANT erscheint aufgrund der Erfahrungen mit dem bisherigen Framework weiterhin als geeignetes Mittel, um auch den Erstellvor-gang von GenerationREST-SDKs abzubilden, jedoch muss der bisherige Workflow noch generalisiert und Telekom-Spezifika ausgelagert werden.

Im ANT-Workflow bietet sich ebenfalls ein einfacher Hook-/Extension-Mechanismus an, um eine Anpassbarkeit des Erstellvorganges zu ermöglichen.

4.8 Test des Framework-Prototypen

In diesem Kapitel soll die bisher umgesetzte Funktionalität des Framework-Prototyps und damit die Anwendbarkeit des Konzepts und der darauf aufbauenden flexiblen Architektur aufgezeigt werden.

Hierfür wird auf der einen Seite das Developer Garden – Modell in das Generation-REST-Framework überführt und ein einfacher Code-Generierungslauf gestartet.

Darüber hinaus wird die Anwendbarkeit von GenerationREST außerhalb des Deve-loper Gardens durch die Generierung von zwei weiteren REST-Schnittstellenadaptern gezeigt: einerseits für die Google Web Search API151 und an-dererseits für die World Weather Online-API152.

Überführung des Developer Garden - Modells Die Überführung des Developer Garden Modells erfolgt über eine Xpand-Transformation153, welche im Workspace des bisherigen Frameworks implementiert wurde. Diese lädt die derzeitige Version des Developer Garden Modells und über-führt diese in eine der REST-Service – Syntax entsprechende Form.

Bemerkenswert ist die geringe Größe der Transformation (93 Zeilen Quellcode).

Implementierung der weiteren Service-Modelle Die Google Websearch-Schnittstellenbeschreibung wurde auf Basis der bereitgestell-ten Dokumentation154 verfasst. Die Schnittstellenbeschreibung des World Weather Online – Services konnte mithilfe des bereitgestellten „Weather API Request Buil-der“155 auf Basis der Antwortnachrichten schlussgefolgert werden.

151 (Google Inc., 2011A) 152 (World Weather Online, 2011) 153 generationrest.xpt im Paket com.telekom.restsdks.template.generationrest 154 (Google Inc., 2011A) 155 (World Weather Online, 2011A)


89

Einrichten und Konfigurieren des Frameworks Da GenerationREST ein aus mehreren OSGi-Plugins bestehendes Eclipse-Feature ist, existieren zwei getrennte Eclipse-Workspaces: Auf der einen Seite der Entwicklungs-Workspace mit dem Quelltext des GenerationREST-Frameworks, auf der anderen Seite der Workspace, in welchem das Feature ausgeführt und zur Generierung der SDKs verwendet wird (Projekt-Workspace).

Innerhalb der Eclipse-Plattform existiert die Ausführungskonfiguration „Eclipse Ap-plication“, mit der das GenerationREST-Framework getestet werden kann.

In den Einstellungen dieser Ausführungskonfiguration werden die GenerationREST-Plugins des aktuellen Workspaces ausgewählt, die dann in der neu gestarteten Eclip-se-Instanz zur Verfügung stehen:

Abbildung 26 - Konfiguration einer neuen GenerationREST Eclipse-Instanz156

Je nach Bedarf können weitere Konfigurationsoptionen gesetzt werden, beispielswei-se das Verzeichnis des Projekt-Workspaces oder die Parameter der Java-VM. Auf-grund der Komplexität der Gesamtlösung empfiehlt sich das Heraufsetzen der Größe des Heap- und Keller-Speichers, sowie des Speicher-Limits der langlebigen Genera-tion des automatischen Speicherbereinigers.157

156 Eigene Darstellung 157 JVM-Parameter des Projekt-Workspaces: -Xms40m -Xmx2048m -XX:MaxPermSize=2048M


90

Nach dem Start der neuen Eclipse-Instanz steht ein leerer Workspace zur Verfügung, in welchem das neue GenerationREST-Projekt angelegt werden kann. Dieses Projekt enthält zum einen die überführte Service-Beschreibung der Developer Garden REST-API, sowie die Konfiguration eines Java-SDK – Generators.

Durchführung der Generierung Die Generierung wird von MWE2-Workflows durchgeführt.

Diese Workflows bestehen aus den folgenden Komponenten und Beans:

1. org.eclipse.emf.mwe.utils.StandaloneSetup

Diese Bean ist für die Registrierung der generierten EMF-Klassen zuständig. Dies ist für die korrekte Verarbeitung des Service- und Konfigurationsmodells uner-lässlich.

Die Bean wird mit registerGeneratedEPackage-Anweisungen konfiguriert, die für alle Pakete des GenerationREST-Frameworks aufgerufen werden.

2. org.eclipse.xtext.mwe.Reader

Diese Komponente lädt Service-Beschreibung und Generations-Konfiguration und speichert Referenzen zu allen konfigurierten SDK-Generatoren in einem benann-ten Slot.

3. org.eclipse.emf.mwe.utils.DirectoryCleaner

Leert das Ausgabe-Verzeichnis

4. org.generationrest.framework.components.SDKGeneratorComponent

Startet alle im Schritt 2 referenzierten Generatoren durch einen Aufruf der genera-

te()-Methode.

Untersuchung des Generats Wenngleich auch nur ein Teil der konzipierten Funktionalität zur Verfügung steht, so wurden durch den Java SDK-Generator Prototyp auf Basis des kompletten Deve-loper Garden REST-Modells bereits 5.800 Zeilen Code generiert, was 39% der 15.000 Zeilen Code des aktuellen Java-SDKs ausmacht.158

158 Messung mit Hilfe des Tools CLOC – Count Lines of Code: (Danial, 2010)


91

Um die grundlegende Funktionsfähigkeit des generierten Codes zu zeigen, wurde mithilfe der Testklasse SendSMS der Developer Garden SendSMS-Service zum Ver-sand einer SMS aufgerufen. Der Aufruf beinhaltet die Anforderung eines Security Tokens vom Telekom STS per HTTP Basic-Authentifizierung und die Einbindung des Token-Werts in die Anfrage an den Developer Garden Service.

Weiterhin wurden erfolgreiche Serviceaufrufe - eine Google-Suche nach „Berlin“ sowie die Abfrage des aktuellen Wetters für Berlin159 - mithilfe der Testklassen GoogleSearch.java und Weather.java durchgeführt.

159 World Weather Online-Beispiel: Siehe Anhang 3

Zusammenfassung und Ausblick

92

5 Zusammenfassung und Ausblick

Der auf Basis des neuen Lösungsansatzes konzipierte Prototyp ermöglicht fast alle grundsätzlich notwendigen Funktionen der Generierung von Java-SDKs für nahezu beliebige REST-Schnittstellen. Darin enthalten sind die Generierung von Adapter-Implementierungen, sowie die dafür notwendigen Datenklassen.

Diese Generierung erfolgt auf Basis eines hybriden Ansatzes zwischen Modell-zu-Modell – Transformation und der Berechnung von Zielsprachen-Modellelement-Eigenschaften durch aspektorientierte Programmierung zur Laufzeit. Die erkennbar verbesserte Struktur des GenerationREST-Prototyps gegenüber dem bisherigen Tele-kom-Framework lässt auf die tatsächliche Verbesserung von Qualität, Zugänglich-keit, Wartbarkeit und Leistungsfähigkeit schließen, die durch das vollständige Framework zu erwarten ist.

Während der Implementierung konnte insbesondere die enorme Leistungssteige-rung der gesamten Modell-zu-Text Transformation beobachtet werden, die gleich-falls vom Xtend 2.0 – Projektleiter beschrieben160 wurde. Ebenso wirkt sich die Mo-dellierung der Zielsprachen positiv auf die Struktur und damit die Zugänglichkeit des Frameworks aus. Darüber hinaus ist zu erwarten, dass der Hook- und Extension-Mechanismus eine flexible, aspektorientierte Anpassung des GenerationREST-Frameworks erlauben wird.

Fertigstellung von GenerationREST Es besteht die Zusage der Deutschen Telekom, dass ich nach der Fertigstellung dieser Abschlussarbeit das GenerationREST-Framework bis Anfang Dezember 2011 fertig-stelle und dass es als Open Source – Projekt, voraussichtlich im Rahmen des Develo-per Gardens, veröffentlicht wird.

Noch ausstehende Implementierungsarbeiten sind in folgenden Bereichen zu finden:

Hook-Mechanismus Ein möglichst flexibler Hook-Mechanismus soll aspektorientierte Anpassungen am Framework ermöglichen. Einige dieser Anpassungen erfolgen aufgrund von Deve-loper Garden REST-Spezifika, die getrennt vom universellen GenerationREST-Framework gepflegt werden.

160 Eine typische M2T-Transformation ist mit Xtend 2.0 um den Faktor 10 schneller, als mit Xpand (Efftinge, 2011)


93

Konfiguration des Generierungs-Vorganges Im Zuge der Realisierung weiterer Code-Templates und des gesamten Erstellvor-gangs werden sich Erweiterungen am Konfigurations-Metamodell ergeben, um eine flexible SDK-Erstellung zu ermöglichen.

REST-Modell Es ist zu erwarten, dass nach intensiver Arbeit an und mit GenerationREST an eini-gen Stellen Änderungen am REST-Modell zu erwarten sind, um bis jetzt noch nicht bedachte Eigenheiten von REST-Schnittstellen abzubilden.

Außerdem könnte dem REST-Modell die Möglichkeit hinzugefügt werden, Verer-bungsbeziehungen abzubilden. Hierdurch wäre z.B. die derzeitige Klassenhierarchie der Developer Garden - SDKs (z.B.: alle Antwortnachrichten erben von Developer-GardenResponse) abbildbar.

Beispiel-Code und Unit-Tests Für Beispiel-Code und Unit-Tests existiert im derzeitigen Telekom-Framework ein Metamodell mit darauf aufbauenden Code-Templates. Durch die Überführung und Neu-Konzipierung dieser Modelle und die Implementierung einer textuellen Xtext – DSL sind deutliche Vereinfachungen bei der Definition von Code-Beispielen und Unit-Tests gegenüber dem Telekom-Framework zu erwarten.

Code-Templates Die Java Code-Templates sind fertigzustellen und für die Programmiersprachen C#/.NET und PHP zu implementieren. Weitere Programmiersprachen, die im kom-menden Jahr hinzugefügt werden könnten, sind u.A. Ruby und Objective-C.

Generierung der Dokumentation Zur Generierung der Dokumentation existieren im bisherigen Framework relativ viele Vorlagen und funktionale Erweiterungen. Diese sind nach GenerationREST zu überführen.

Besonders aufgrund der vereinfachten Verbindung zwischen Xtend 2.0, EMF und

Docbook durch die Funktionen des DocbookDocumentationProviders ist mit einer Ver-besserung der Handhabbarkeit der Dokumentations-Generierung zu rechnen.

Erstellvorgang und Generations-Workflow Das in Kapitel 4.7 (S. 87) dargestellte Konzept des Erstellvorgangs und des Generati-ons-Workflows ist umzusetzen.

Kontinuierliche Integration Zur dauerhaften Pflege und Weiterentwicklung von GenerationREST sollte wie beim derzeitigen Telekom-Framework eine kontinuierliche Integration eingerichtet wer-den, um Teile des Entwicklungsprozesses zu automatisieren.


94

Weitere Telekom-Spezifika Das derzeitige Framework bietet die Möglichkeit, Fehlercodes von Developer Gar-den APIs und deren Beschreibungen in den generierten SDKs abzubilden.

Es ist zu prüfen, ob das GenerationREST-Framework diesen Mechanismus abstrahie-ren und generalisiert bereitstellen kann.

Flexibilisierung der Serialisierungsformate Derzeit unterstützt das GenerationREST-Framework JSON als Serialisierungsformat, da es von einem Großteil der vorhandenen REST-APIs unterstützt wird. Es existieren jedoch auch REST-APIs, die andere Serialisierungsformate unterstützen, z.B. XML.

Um ein universelles Framework zu schaffen, sollten mehrere Serialisierungsformate unterstützt werden.

5.1 Vergleich des Konzepts mit anderen Frameworks

Im Gegensatz zur Generierung von Code auf Basis von WSDL/SOAP existieren für den Anwendungsbereich von GenerationREST relativ wenige alternative Frame-works. Dennoch sollen einige dieser Frameworks und deren Ansätze im Folgenden analysiert werden, um das GenerationREST-Framework im Vergleich zu diesen ein-ordnen zu können.

Thrift Thrift161 ist ein ursprünglich von Facebook entwickeltes Open Source - Framework zur Definition und plattformübergreifenden Generierung von RPC-Schnittstellenadaptern.

Thrift hat mit GenerationREST gemein, dass es auf Basis eines Modells plattform-übergreifende Schnittstellenadapter generiert. Allerding ist die Generierung von be-gleitender Dokumentation (z.B. Code- oder konzeptionelle Dokumentation) nicht vorgesehen.

Größte Auffälligkeit von Thrift ist die Art, wie der Code für die Schnittstellenadapter hinterlegt wird. Der Java-Generator besteht aus einer monolithischen, fast 4.000 Code-Zeilen umfassenden C++ Datei162, die sowohl Generationslogik, als auch Java-Texttemplates enthält. Es ist anzuzweifeln, dass diese Art der Code-Hinterlegung flexibel anpassbar und auf Dauer wartbar ist.

161 (The Apache Software Foundation, 2011A) 162 (Farrell, 2011)


95

RESTclient for WCF RESTclient for WCF163 ist eine quelloffene Lösung, um .NET-Clients zur Ansprache von mithilfe von WADL beschriebenen REST-Services zu generieren. Dabei ist die Lösung als Prototyp-Implementierung zu sehen, die seit Anfang 2010 nicht mehr weiterentwickelt wird und lediglich einige der mit WADL beschreibbaren Eigen-schaften von REST-Schnittstellen unterstützt.

Ein interessanter Ansatz von RESTClient for WCF ist die Verwendung des Sys-tem.CodeDom-Namespaces164. Anstatt textbasierter Code-Templates werden die .NET eigenen Funktionen zur Ausgabe von Quelltext verwendet. Hierdurch entfällt die Notwendigkeit zur Implementierung einer Abstraktionsschicht der Zielsprache .NET. Allerdings unterstützt der System.CodeDom-Namespace lediglich die Spra-chen C#, JScript, C++ und Visual Basic und ist dadurch auf die .NET-Plattform be-schränkt.

Eine ähnliche Funktion, wie System.CodeDom besteht in der Eclipse-Plattform in-nerhalb der Java Development Tools. Hierbei können die Klassen des Java AST-Parsers verwendet werden, um Code zu generieren.165 Dieser Mechanismus ist aller-dings auf Java beschränkt.

HTTP4e – Eclipse Restful HTTP Client Plugin HTTP4e ist eine kommerzielle Lösung auf Basis der Eclipse IDE, mit derer die Ent-wicklung im Zusammenhang mit REST-Schnittstellen unterstützt wird. HTTP4e kann Client-Code zur Ansprache einer beschriebenen REST-Methode für zahlreiche Programmiersprachen generieren, unter anderem für Java, PHP, C# und Ruby.

Das besondere an HTTP4e ist das Aufzeigen kommerzieller Nutzungsmöglichkeiten von Code-Generatoren, auch auf Basis von Open Source Technologie, wie Eclipse. Allerdings ist der Umfang von HTTP4e deutlich geringer, als der von Generation-REST.

NetBeans Web Services Die NetBeans-IDE unterstützt die Generierung von Java und JavaScript-Client Code für mithilfe von WADL beschriebene REST-Schnittstellen.166 Zur Unterstützung und Demonstration werden WADL-Beschreibungen für viele geläufige REST-Schnittstellen mit der IDE ausgeliefert.167

163 (Schidler, 2010) 164 (Microsoft Corporation, 2011B) 165 (Vogel, 2011) 166 Ausführliches Tutorial: (Oracle Corporation, 2011) 167 Unter anderem Amazon, Facebook, Flickr, Google und Yahoo


96

Bemerkenswert an der REST Web Service – Unterstützung von NetBeans ist die ver-gleichsweise einfache Verwendung, die gute Integration der Code-Generierung in die IDE und die Vielzahl an Dokumentation. Allerdings ist die Zahl der Zielsprachen begrenzt und einfache Anpassungsmöglichkeiten der Client-Code Templates nicht gegeben.

REST API Code Generation REST API Code Generation168 ist ein Open Source Projekt zur Generierung von Java und C# - Schnittstellenadaptern auf Basis einer WADL-Beschreibung. Ähnlich, wie bei Thrift, befinden sich die Code-Templates als Zeichenketten innerhalb von Java-Quellcode, was die Anpassbarkeit und Wartbarkeit der Lösung beeinträchtigt. Au-ßerdem ist der Umfang des Projekts gegenüber GenerationREST deutlich geringer.

Mittlerweile wird das Projekt nicht mehr weiterentwickelt.

Vergleichende Einordnung von GenerationREST Keiner der analysierten Frameworks bietet eine in der Art und im Umfang vergleich-bare Lösung zur Generierung von Schnittstellenadaptern und Dokumentation, wie GenerationREST und das vorhergehende Telekom-Framework.

Auffallend ist vor allem der häufige Bezug auf die REST-Beschreibungssprache WADL und die seltene Verwendung einer dezidierten Template-Sprache, wie bei-spielsweise Xpand oder JET. Außerdem sind die Anpassungsmöglichkeiten der Code-Generierung in allen Frameworks viel zu gering um das Anwendungsgebiet der Frameworks über die jeweiligen Zielsprachen und Plattformen hinaus zu erwei-tern.

Die Generierung von Schnittstellen-Dokumentation oder die Bereitstellung von Code-Dokumentation wird von keinem der Frameworks adressiert.

Zusammenfassend ist festzustellen, dass es keine zu GenerationREST ähnlichen öf-fentlich verfügbaren Lösungen gibt.

168 (Steiner, et al., 2008)


97

5.2 Zukunft von GenerationREST

Es ist zum jetzigen Zeitpunkt unklar, ob die Deutsche Telekom nach meiner Tätigkeit für das Developer Garden Projekt, voraussichtlich ab Anfang 2012, das Framework als Hauptnutzer vorantreiben wird, oder wieder zur manuellen Pflege der Developer Garden SDKs zurückkehrt.

Dies hat vor allem drei Ursachen: Einerseits gibt es vom Management Bedenken auf-grund der hohen Komplexität und den damit verbundenen Aufwänden des modell-getriebenen Ansatzes. Auf der anderen Seite fehlt derzeit das Wissen im Team zu den eingesetzten Technologien, sodass für den Fortbestand von GenerationREST zu hoffen ist, dass es mir gelingt, alle Kenntnisse an das Team weiterzugeben, um die Weiterentwicklung des Frameworks durch jemand anderen sicherzustellen. Und zu-letzt wurden auch viele Vorteile des modellgetriebenen Ansatzes, vor allem die mehrsprachige Bereitstellung von SDKs, von einigen Teammitgliedern als nicht not-wendig betrachtet.

Allerdings kann aufgrund der universellen Anwendbarkeit des Frameworks die An-nahme getroffen werden, dass sich weitere Unternehmen, Institutionen oder Privat-personen in einem offenen Entwicklungsprozess finden, um das Framework zu nut-zen und weiter zu entwickeln.

Fazit

98

6 Fazit

Aus einem erarbeiteten, tiefen Technologie-Verständnis und auf Basis der umfang-reichen Analyse des Seit Ende 2009 von mir entwickelten Frameworks wurde in der vorliegenden Arbeit das GenerationREST-Framework konzipiert und prototypisch realisiert.

Das Framework enthält mehrere Metamodelle zur Beschreibung allgemeiner und konkreter Eigenschaften von REST-Schnittstellen und den dafür zu generierenden Schnittstellenadaptern. Die Modell-Beschreibung kann über eine kompakte und leicht zugängliche textuelle DSL vorgenommen werden. Weiterhin ist das Frame-work durch seine Architektur flexibel an spezielle Anforderungen anpassbar. Gene-rationREST setzt auf aktuelle Technologien und löst durch neue Ansätze viele Prob-leme des vorhandenen Frameworks. Darüber hinaus ist GenerationREST innovativ, da keine vergleichbaren, öffentlich verfügbaren Lösungen existieren.

Die Bereitschaft der Telekom, das Framework zu nutzen und nach Abschluss der Masterarbeit von mir fertigstellen zu lassen, unterstreicht die Praxistauglichkeit des Konzepts. Die allgemeine Anwendbarkeit des entwickelten Frameworks und die Veröffentlichung als Open Source-Produkt im Developer Garden lassen annehmen, dass das Framework neben der Telekom weitere Nutzer und Entwickler finden wird. Die Reichweite des Developer Gardens und die dort bereitgestellten Kollaborations-möglichkeiten unterstützen diese Annahme zusätzlich.

Alles in allem ist das Ergebnis dieser Arbeit mehr als zufriedenstellend, da sowohl konzeptionelle, technologische als auch wirtschaftliche Problemstellungen detailliert analysiert und fundierte Lösungsansätze erarbeitet und realisiert wurden.

Anhang 1: Darstellung der Zusammenhänge zwischen REST- und SOAP-Elementen

v

Anhang 1: Darstellung der Zusammenhänge zwischen REST- und SOAP-Elementen

<methods name="newCall" return="newCallReturn"> <parameters xsi:type="service:SimpleField" name="aNumber"/> <parameters xsi:type="service:SimpleField" name="bNumber"/> <parameters xsi:type="service:SimpleField" name="privacyA"/> <parameters xsi:type="service:SimpleField" name="privacyB"/> <parameters xsi:type="service:SimpleField" name="expiration"/> <parameters xsi:type="service:SimpleField" name="maxDuration"/> <parameters xsi:type="service:SimpleField" name="greeter"/> <parameters xsi:type="service:SimpleField" name="account" optional="true"/> </methods>

<methods xsi:type="service:RestMethod" name="newCall" return="newCallRestReturn" correspondingMethods="newCall newCallSequenced" httpMethod="POST">

<parameters xsi:type="service:SimpleFieldRest" name="anumber" correspondingField="aNumber"/> <parameters xsi:type="service:SimpleFieldRest" name="bnumber" correspondingField="bNumber"/> <parameters xsi:type="service:SimpleField" name="expiration" optional="true"/> <parameters xsi:type="service:SimpleFieldRest" name="maxduration" optional="true" correspondingField="maxDuration"/> <parameters xsi:type="service:SimpleFieldRest" name="maxwait" optional="true" correspondingField="maxWait"/> <parameters xsi:type="service:SimpleFieldRest" name="aprivacy" optional="true" correspondingField="privacyA"/> <parameters xsi:type="service:SimpleFieldRest" name="bprivacy" optional="true" correspondingField="privacyB"/> <parameters xsi:type="service:SimpleField" name="account" optional="true"/> <restResources name="environment" dynamic="true"/> <restResources name="call"/>

</methods>

Anhang 2: Beispiel zum Aspekt ImplementedByExtensionMethodAspect

vi

Anhang 2: Beispiel zum Aspekt ImplementedByExtensionMethodAspect

Anhang 3: World Weather Online-Beispiel

vii


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


viii

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

169 Der API-Schlüssel ist nach einer kostenlosen Registrierung verfügbar


ix

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

Anhang 4: Vereinfachungspotentiale in AutoScout24-Nachrichten

x

Anhang 4: Vereinfachungspotentiale in AutoScout24-Nachrichten

Beispiel 1: Formatierung der Rückgabewerte Aktuell:

"response": { "vehicles": { "vehicle" : [ { Inserat 1 }, { Inserat 2 }, { Inserat n } ]

} }

Optimierung:

"response": { "vehicles" : [ { Inserat 1 }, { Inserat 2 }, { Inserat n } ] }

Beispiel 2: Rückgabe der Bilder zu einem Inserat

Aktuell:

"media": { "images": { "image" : [ { Bild 1 }, { Bild 2 }, { Bild n } ]

} }

Optimierung:

"images": [ { Bild 1 }, { Bild 2 }, { Bild n } ] Da es keine anderen media-Objekte, außer Bilder (images) gibt, könnten hier sogar zwei Hierarchieebenen eingespart werden.

Literaturverzeichnis

xi


Balzert, Helmut. 2009. Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering. 3. Auflage. Heidelberg : Spektrum Akademischer Verlag, 2009. 978-3-8274-1705-3.

Behrens, Heiko. 2011. Xtext - Main Features. eclipse.org. [Online] 2011. [Zitat vom: 29. August 2011.] http://www.eclipse.org/Xtext/#FeatureList.

—. 2011A. Xtext - Reference Documentation - Runtime Concepts - Scoping. eclipse.org. [Online] 2011A. [Zitat vom: 29. August 2011.] http://www.eclipse.org/Xtext/documentation/2_0_0/080-scoping.php.

—. 2011B. Xtext Reference Documentation - Runtime Concepts - Linking. eclipse.org. [Online] 2011B. [Zitat vom: 29. August 2011.] http://www.eclipse.org/Xtext/documentation/2_0_0/070-linking.php.

Beltran, Juan Carlos Flores, et al. 2007. Modellgetriebene Softwareentwicklung. MDA und MDSD in der Praxis. [Hrsg.] Jens Trompeter und Georg Pietrek. Frankfurt : Software & Support Verlag GmbH, 2007. ISBN 978-3-939084-11-2.

Berners-Lee, Tim, et al. 2005. Uniform Resource Identifier (URI): Generic Syntax. Santa Clara : RFC-Editor, 2005. RFC-3986.

Berners-Lee, Tim, Fielding, Roy Thomas und Masinter, Larry. 2005A. Uniform Resource Identifier (URI): Generic Syntax. Santa Clara : RFC-Editor, 2005A. RFC-3986.

Berners-Lee, Tim, Fielding, Roy Thomas und Nielsen, Henrik Frystyk. 1996. Hypertext Transfer Protocol -- HTTP/1.0. Santa Clara : RFC-Editor, 1996. RFC-1945.

Boldt, Nick. 2007. EMF/EMF 2.3/Generics. Eclipse.org Wiki. [Online] 21. Dezember 2007. [Zitat vom: 2. September 2011.] http://wiki.eclipse.org/EMF/EMF_2.3/Generics.

Böttge, René. 2009. Automatisierung der Erstellung sprachbasierter Anwendungen mittels openArchitectureWare als Alternative zu einem bereits existierenden, proprietären Generierungs-Werkzeug. Berlin : Hochschule für Technik und Wirtschaft Berlin, 2009.

Box, Don. 2001. A Brief History of SOAP. XML From the Inside Out -- XML development, XML resources, XML specifications. [Online] 4. April 2001. [Zitat vom: 14. Juli 2011.] http://www.xml.com/pub/a/ws/2001/04/04/soap.html.

Crockford, Douglas. 2006. The application/json Media Type for JavaScript Object Notation (JSON). Santa Clara : RFC-Editor, 2006. RFC-4627.


xii

Danial, Al. 2010. CLOC - Count Lines of Code. SourceForge. [Online] 2. Dezember 2010. [Zitat vom: 1. September 2011.] http://cloc.sourceforge.net/.

Davenport, Chris, et al. 2010. Xml-rpc changes in Joomla! 1.6. Joomla! Documentation. [Online] 1. November 2010. [Zitat vom: 24. August 2011.] http://docs.joomla.org/Xml-rpc_changes_in_Joomla!_1.6.

Deutsche Telekom AG. 2011. Archive: SDK Version 2.7, Frameworks & Extensions. Developer Garden. [Online] 2011. [Zitat vom: 17. August 2011.] http://www.developergarden.com/?id=352.

—. 2011A. Developer Center - Ihr persönliches Entwicklerkonto. Developer Center. [Online] 2011A. [Zitat vom: 2. September 2011.] http://www.developercenter.telekom.com/.

—. 2011B. Developer Garden - APIs : A.3. Ansprache der Services über die REST-Schnittstelle. Developer Garden - APIs : APIs. [Online] Deutsche Telekom AG, 2011B. [Zitat vom: 12. Juli 2011.] http://www.developergarden.com/index.php?id=511&L=1&vURL=apas03.html&cHash=47220646742fe1859f3e4e777f17cc14#N15B93.

—. 2011C. Developer Garden - APIs : APIs. Developer Garden. [Online] September 2011C. [Zitat vom: 2. September 2011.] http://www.developergarden.com/.

Docbook Committee. 2007. DocBook Technical Committee Document Repository. OASIS - Organization for the Advancement of Structured Information Standards. [Online] 2. November 2007. [Zitat vom: 2. September 2011.] http://www.oasis-open.org/docbook/.

Efftinge, Sven. 2011. A rough performance comparison between Xpand and Xtend 2. Sven Efftinge's Blog. [Online] 21. März 2011. [Zitat vom: 2. September 2011.] http://blog.efftinge.de/2011/03/rough-performance-comparison-between.html.

Efftinge, Sven und Software & Support Media GmbH. 2011. Xtext 2.0: DSLs unleashed - Xtext-Lead Sven Efftinge über die Neuerungen in Xtext 2.0. it republik : jaxenter. [Online] Februar 2011. [Zitat vom: 29. August 2011.] http://it-republik.de/jaxenter/artikel/Xtext-2.0-DSLs-unleashed-3604.html.

Efftinge, Sven. 2010. Xbase - A new programming language? Sven Efftinge's Blog. [Online] 30. September 2010. [Zitat vom: 26. August 2010.] http://blog.efftinge.de/2010/09/xbase-new-programming-language.html.


xiii

—. 2010A. Xtend 2 - the Successor to Xpand. Sven Efftinge's Blog. [Online] 3. Dezember 2010A. [Zitat vom: 26. August 2011.] http://blog.efftinge.de/2010/12/xtend-2-successor-to-xpand.html.

—. 2009. Xtext - Using existing Ecore models. Sven Efftinge's Blog. [Online] 24. November 2009. [Zitat vom: 29. August 2011.] http://blog.efftinge.de/2009/11/xtext-using-existing-ecore-models.html.

—. 2010B. Xtext in Indigo. Sven Efftinge's Blog. [Online] 29. September 2010B. [Zitat vom: 29. August 2011.] http://blog.efftinge.de/2010/09/xtext-in-indigo.html.

Efftinge, Sven, et al. 2008. openArchitectureWare User Guide. openarchitectureware.org. [Online] 15. Dezember 2008. [Zitat vom: 11. August 2011.] http://www.openarchitectureware.org/pub/documentation/4.3.1/openArchitectureWare-4.3.1-Reference.pdf.

Efftinge, Sven, et al. 2010. Xpand - Eclipsepedia. Eclipsepedia. [Online] 9. Dezember 2010. [Zitat vom: 10. August 2011.] http://wiki.eclipse.org/Xpand.

Farrell, Jake. 2011. Contents of /thrift/tags/thrift-0.7.0/compiler/cpp/src/generate/t_java_generator.cc. Apache-SVN. [Online] 13. August 2011. [Zitat vom: 29. August 2011.] http://svn.apache.org/viewvc/thrift/tags/thrift-0.7.0/compiler/cpp/src/generate/t_java_generator.cc?revision=1157427&view=markup.

Ferguson, Derek. 2004. Exclusive .NET Developer's Journal "Indigo" Interview with Microsoft's Don Box. .NET Developer's Journal. [Online] 10. August 2004. [Zitat vom: 14. Juli 2011.] http://dotnet.sys-con.com/node/45908.

Fielding, Roy Thomas. 2000. Architectural Styles and the Design of Network-based Software Architectures. donald bren school of information and computer sciences @ the university of california, irvine. [Online] 2000. [Zitat vom: 7. Juli 2011.] http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.

Fielding, Roy Thomas, et al. 1999. Hypertext Transfer Protocol -- HTTP/1.1. Santa Clara : RFC-Editor, 1999. RFC-2616.

Google Inc. 2011. Google Maps JavaScript API V3 – Allgemeines. Google code. [Online] 2011. [Zitat vom: 16. August 2011.] http://code.google.com/intl/de-DE/apis/maps/documentation/javascript/basics.html.


xiv

—. 2011A. Google Web Search API. Google code. [Online] 2011A. [Zitat vom: 3. September 2011.] http://code.google.com/apis/websearch/docs/.

—. 2011B. google-guice - Guice. Google Project Hosting. [Online] 2011B. [Zitat vom: 1. September 2011.] http://code.google.com/p/google-guice/.

Gregorio, Joe. 2007. Do we need WADL? BitWorking. [Online] 5. Juni 2007. [Zitat vom: 2. September 2011.] http://bitworking.org/news/193/Do-we-need-WADL.

Gudgin, Martin, et al. 2007. SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). Word Wide Web Consortium (W3C). [Online] 27. April 2007. [Zitat vom: 24. August 2011.] http://www.w3.org/TR/soap12/.

Hadley, Marc. 2011. Web Application Description Language (WADL) - Specification and Tools - Java.net. java.net. [Online] 2011. [Zitat vom: 2. September 2011.] http://wadl.java.net/.

Herrmann, Stephan. 2011. Object Teams home. The Eclipse Foundation. [Online] 2011. [Zitat vom: 1. September 2011.] http://www.eclipse.org/objectteams/.

Hunter, Anthony. 2009. Bugzilla - Bug 277397. bugs.eclipse.org. [Online] 1. Juni 2009. [Zitat vom: 11. August 2011.] https://bugs.eclipse.org/bugs/show_bug.cgi?id=277397#c2.

itemis AG. 2011. Xtext git repository. git.eclipse.org. [Online] 10. August 2011. [Zitat vom: 29. August 2011.] http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/tree/plugins/org.eclipse.xtext/src/org/eclipse/xtext/Xtext.xtext.

Masinter, Larry. 1998. Returning Values from Forms: multipart/form-data. Santa Clara : RFC Editor, 1998. RFC-2388.

Merks, Ed. 2009. Two features named in the model by the same name. Eclipse Community Forums. [Online] 21. August 2009. [Zitat vom: 16. August 2011.] http://www.eclipse.org/forums/index.php/mv/msg/153408/483174/#msg_483174.

Microsoft Corporation. 2011. [MS-FSCX]: Configuration XML-RPC Protocol Specification. Microsoft Developer Network: Open Specifications Developer Center. [Online] 10. Juni 2011. [Zitat vom: 24. August 2011.] http://msdn.microsoft.com/en-us/library/ee627322(office.12).aspx.


xv

—. 2011A. Remote Procedure Call. MSDN – Explore Desktop, Web, Cloud, and Phone Software Development. [Online] 12. Mai 2011A. [Zitat vom: 14. Juli 2011.] http://msdn.microsoft.com/en-us/library/aa378651(VS.85).aspx.

—. 2011B. System.CodeDom-Namespace. Microsoft Developer Network - .NET Framework Developer Center. [Online] 2011B. [Zitat vom: 29. August 2011.] http://msdn.microsoft.com/de-de/library/system.codedom.aspx.

—. 2005. Web Services Enhancements (WSE) 3.0 for Microsoft .NET. Microsoft Download Center. [Online] 11. Juli 2005. [Zitat vom: 17. August 2011.] http://www.microsoft.com/download/en/details.aspx?id=14089.

—. 2011C. Windows Communication Foundation (WCF). .NET Framework Developer Center. [Online] 2011C. [Zitat vom: 22. August 2011.] http://msdn.microsoft.com/de-de/netframework/aa663324.aspx.

openArchitectureWare.org. 2009. openArchitectureWare.org - Official openArchitectureWare Homepage. openArchitectureWare.org - Official openArchitectureWare Homepage. [Online] itemis AG, 2009. [Zitat vom: 10. August 2011.] http://www.openarchitectureware.org/.

—. 2009A. Why openArchitectureWare moved to Eclipse.org. openarchitectureware.org. [Online] 20. September 2009A. [Zitat vom: 11. August 2011.] http://www.openarchitectureware.org/staticpages/index.php/oaw_eclipse_letter_of_intent.

Oracle Corporation. 2011. Creating RESTful Service Clients in NetBeans Modules. NetBeans.org. [Online] 2011. [Zitat vom: 29. August 2011.] http://netbeans.org/kb/docs/websvc/jersey-rcp-client.html.

—. 2011A. Glassfish » Jersey. Java.net. [Online] Oracle Corporation, 2011A. [Zitat vom: 12. Juli 2011.] http://jersey.java.net/.

—. 2010. Remote Method Invocation Home. Oracle | Hardware and Software, Engineered to Work Together. [Online] 16. Juli 2010. [Zitat vom: 14. Juli 2011.] http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136424.html.

O'Reilly & Associates, Inc. 1992. DocBook 1.0. OASIS - Organization for the Advancement of Structured Information Standards. [Online] 12. November 1992. [Zitat vom: 2. September 2011.] http://www.oasis-open.org/docbook/sgml/1.0/docbk10.zip.


xvi

Organization for the Advancement of Structured Information Standards. 2011. OASIS Web Services Security (WSS) TC. OASIS | Advancing open standards for the information society. [Online] 2011. [Zitat vom: 5. Juli 2011.] http://www.oasis-open.org/committees/wss/.

—. 2011A. OASIS Web Services Transaction (WS-TX) TC. OASIS | Advancing open standards for the information society. [Online] 2011A. [Zitat vom: 5. Juli 2011.] http://www.oasis-open.org/committees/ws-tx/.

Parys, Dariusz und Mauerer, Jürgen. 2004. .NET Remoting. MSDN: Microsoft Developer Network (Deutschland). [Online] 14. November 2004. [Zitat vom: 14. Juli 2011.] http://msdn.microsoft.com/de-de/library/bb979191.aspx.

ProgrammableWeb.com. 2011. API Directory - ProgrammableWeb. ProgrammableWeb - Mashups, APIs, and the Web as Platform. [Online] 2011. [Zitat vom: 5. Juli 2011.] http://www.programmableweb.com/apis/directory/1?protocol=REST.

Richardson, Leonard und Ruby, Sam. 2007. RESTful Web Services. Sebastopol : O'Reilly Media, Inc., 2007. 978-0-596-52926-0.

Rotem-Gal-Oz, Arnon. 2007. Debate: Does REST Need a Description Language? InfoQ. [Online] 6. Juni 2007. [Zitat vom: 2. September 2011.] http://www.infoq.com/news/2007/06/rest-description-language.

Schidler, Patrick. 2010. RESTclient for WCF. Codeplex. [Online] 27. Januar 2010. http://restclient.codeplex.com/.

Shatalin, Alexander und Gronback, Richard. 2009. GMF Xpand Migration howto. wiki.eclipse.org. [Online] 19. März 2009. [Zitat vom: 11. August 2011.] http://wiki.eclipse.org/GMF_Xpand_Migration_howto.

Skrypuch, Neil. 2011. Eclipse Modeling - EMF - Home. The Eclipse Foundation. [Online] 2011. [Zitat vom: 2. September 2011.] http://www.eclipse.org/modeling/emf/.

Slawik, Mathias. 2011. Ansprache der Services über die REST-Schnittstelle. Developer Garden. [Online] 2011. [Zitat vom: 2. September 2011.] http://www.developergarden.com/index.php?id=511&L=1&vURL=apas03.html&cHash=47220646742fe1859f3e4e777f17cc14.


xvii

—. 2008. Entwicklung und Anwendung eines Integrationskonzepts für das Typo3 CMS unter Verwendung von Methoden der Modellgetriebenen Softwareentwicklung. Berlin : s.n., 2008.

Srinivasan, Raj. 1995. RPC: Remote Procedure Call Protocol Specification Version 2 (PROPOSED STANDARD). Santa Clara : RFC Editor, 1995. RFC-1831.

St.Laurent, Simon, Johnston, Joe und Dumbill, Edd. 2001. Programming Web Services with XML-RPC. Sebastopol : O'Reilly & Associates, Inc., 2001. 0-596-00119-3.

Steinberg, Dave. 2008. Fundamentals of the Eclipse Modeling. eclipse.org. [Online] 17. März 2008. [Zitat vom: 17. August 2009.] http://www.eclipse.org/modeling/emf/docs/presentations/EclipseCon/EclipseCon2008_309T_Fundamentals_of_EMF.pdf.

Steinberg, Dave, et al. 2008. EMF: Eclipse Modeling Framework, Second Edition. Boston : Addison-Wesley Professional, 2008. ISBN-13: 978-0-321-33188-5.

Steiner, Thomas. 2007. Automatic Multi Language Program Library Generation for REST APIs. Google Documents. [Online] Juni 2007. [Zitat vom: 2. September 2011.] https://docs.google.com/Doc?id=dgdcn6h3_38fz2vn5.

Steiner, Thomas, Bruckner, Alexander und Botterill, Louis. 2008. rest-api-code-gen REST API Code Generation. Google Code. [Online] 9. November 2008. [Zitat vom: 29. August 2011.] http://code.google.com/p/rest-api-code-gen/.

Sun Microsystems, Inc. 1997. JavaBeans API specification. Oracle Technology Network. [Online] 8. August 1997. [Zitat vom: 2. September 2011.] http://www.oracle.com/technetwork/java/javase/documentation/spec-136004.html.

—. 1988. RPC: Remote Procedure Call Protocol Specification Version 2 (INFORMATIONAL). Santa Clara : RFC Editor, 1988. RFC-1057.

Taal, Martin und Irawan, Hendy. 2011. Teneo. Eclipse.org Wiki. [Online] 1. März 2011. [Zitat vom: 2. September 2011.] http://wiki.eclipse.org/Teneo#teneo.

Technische Universität Berlin. 2011. Publications. Object Teams. [Online] 2011. [Zitat vom: 1. September 2011.] http://www.objectteams.org/publications/index.html.

The Apache Software Foundation. 2011. Apache Maven Project. The Apache Software Foundation. [Online] 11. August 2011. [Zitat vom: 18. August 2011.] http://maven.apache.org/.


xviii

—. 2011A. Thrift. The Apache Software Foundation. [Online] 2011A. [Zitat vom: 29. August 2011.] http://thrift.apache.org/.

The Axis Development Team. 2006. Web Services - Axis. The Apache Software Foundation. [Online] 22. April 2006. [Zitat vom: 17. August 2011.] http://axis.apache.org/axis/.

The DocBook Project. 2005. The DocBook Project. SourceForge.net. [Online] 19. November 2005. [Zitat vom: 2. September 2011.] http://docbook.sourceforge.net/.

The Eclipse Foundation. 2011. Eclipse Modeling Project. Eclipse - The Eclipse Foundation open source community website. [Online] 2011. [Zitat vom: 30. Juni 2011.] http://www.eclipse.org/modeling.

—. 2011A. Home - Modeling - TMF (Xtext). Eclipse Community Forums. [Online] 2011A. [Zitat vom: 29. August 2011.] http://www.eclipse.org/forums/index.php?t=thread&frm_id=27.

—. 2011B. Intellectual Property Policy. eclipse.org. [Online] 21. Juli 2011B. [Zitat vom: 11. August 2011.] http://eclipse.org/org/documents/Eclipse_IP_Policy.pdf.

—. 2011C. The AspectJ Project. The Eclipse Foundation. [Online] 2011C. [Zitat vom: 1. September 2011.] http://www.eclipse.org/aspectj/.

Thoms, Karsten. 2006. openArchitectureWare.org Forum - History of oAW. openArchitectureWare.org - Official openArchitectureWare Homepage. [Online] itemis AG, 28. August 2006. [Zitat vom: 10. August 2011.] http://www.openarchitectureware.org/forum/viewtopic.php?showtopic=1995.

Vogel, Lars. 2011. Eclipse JDT - Abstract Syntax Tree (AST) and the Java Model - Tutorial. Java, Eclipse, Android, and Web Programming Tutorials. [Online] 16. August 2011. [Zitat vom: 29. August 2011.] http://www.vogella.de/articles/EclipseJDT/article.html.

White, James. 1975. High-level framework for network-based resource sharing. Menlo Park : RFC Editor, 1975. RFC-707.

Winer, Dave. 1999. XML-RPC Specification. XML-RPC Home Page. [Online] 15. Juni 1999. [Zitat vom: 14. Juli 2011.] http://www.xmlrpc.com/spec.

Woodruff, Eric. 2011. Sandcastle Help File Builder. CodePlex - Open Source Community. [Online] Microsoft Corporation, 1. Mai 2011. [Zitat vom: 18. August 2011.] http://shfb.codeplex.com/.


xix

WordPress.org. 2011. WordPress Codex: XML-RPC Support. WordPress.org. [Online] 22. Juli 2011. [Zitat vom: 24. August 2011.] http://codex.wordpress.org/XML-RPC_Support.

World Weather Online. 2011. Free Local Weather API Overview. World Weater Online. [Online] 2011. [Zitat vom: 3. September 2011.] http://www.worldweatheronline.com/free-weather-feed.aspx.

—. 2011A. Free Local Weather API Request Builder. World Weather Online. [Online] 2011A. [Zitat vom: 3. September 2011.] http://www.worldweatheronline.com/feed-generater.aspx.

Zarnekow, Sebastian und Köhnlein, Jan. 2011. What's Cooking in Xtext 2.0. slideshare.net. [Online] 6. April 2011. [Zitat vom: 11. August 2011.] http://www.slideshare.net/schwurbel/whats-cooking-in-xtext-20.

Zimmer, Frank. 2009. Developer Garden Forum - Re: Java: LT02: Text is not a valid token. Developer Garden. [Online] 2. Juni 2009. [Zitat vom: 17. August 2011.] http://www.developergarden.com/apis/forum/?tx_mmforum_pi1%5Baction%5D=list_post&tx_mmforum_pi1%5Btid%5D=92&tx_mmforum_pi1%5Bpage%5D=&tx_mmforum_pi1%5B.

Eidesstattliche Versicherung

Ich versichere hiermit, dass ich die vorliegende Masterthesis selbstständig und ohne fremde Hilfe angefertigt und keine andere als die angegebene Literatur benutzt habe.

Alle von anderen Autoren wörtlich übernommenen Stellen wie auch die sich an die Gedankengänge anderer Autoren eng anlehnenden Ausführungen meiner Arbeit sind besonders gekennzeichnet.

Diese Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungs-behörde vorgelegt und auch nicht veröffentlicht.

Datum, Unterschrift

Education

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