SlideShare ist ein Scribd-Unternehmen logo
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)
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
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
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
9
2.2.2 Ressourcenorientiert (REST)
Der Ressourcenorientierte Architekturstil (REST) wurde erstmals in der Doktorarbeit
von Roy Thomas Fielding24
ausgearbeitet, einem der Hauptautoren der HTTP25
und
URI26
– Spezifikationen.
Die grundlegende Idee besteht darin, eine Schnittstelle nicht wie bei RPC als Menge
von Methoden und Parametern zu abstrahieren, sondern mithilfe von Ressourcen
und Operationen. REST integriert die Standards URI und HTTP in ihrer originären
Anwendungsdomäne: Mithilfe von URIs werden Ressourcen adressiert, das HTTP-
Protokoll definiert die auf Ressourcen anzuwendenden Operationen, im Regelfall
GET, POST, PUT und DELETE.
Darüber hinaus nutzen REST-Schnittstellen viele im HTT-Protokoll vorgesehenen
Mechanismen in ihrer originären Anwendungsform. So wird z.B. die HTTP Content-
Negotiation (HTTP-Header Accept und Content-Type) für das Vereinbaren eines
gemeinsamen Datenaustauschformats wiederverwendet. Außerdem können REST
Antworten über dieselben Mechanismen zwischenspeichert werden, wie herkömmli-
che Internet-Inhalte (z.B. durch Übermittlung von Expire oder Last-Modified Hea-
dern). Letztendlich finden sich auch HTTP-Statuscodes in REST-Schnittstellen in ei-
ner vergleichbaren Rolle wieder, wie bei gängigen Internet-Anwendungen.
Obwohl der REST-Architekturstil wenige abstrakte Vorgaben bezüglich der konkre-
ten Gestaltung von REST-APIs beinhaltet, so zeigt sich in der Vielzahl der REST
Webservice-Schnittstellen die allgemeine Anwendbarkeit und die Qualität des Kon-
zepts. Außerdem tragen die Klarheit der Schnittstellendefinition sowie die Bezie-
hung auf ausgereifte Standards dazu bei, dass der REST-Architekturstil mittlerweile
zum vorherrschenden Muster für den Entwurf und die Implementierung von Web
Service-Schnittstellen geworden ist.
Beispiel der Anwendung des REST-Architekturstils anhand Amazon S3
27
Der Amazon Simple Storage Service (S3) ist ein gutes Beispiel für die Anwendung
des REST-Architekturstils zum Entwurf und zur Anwendung von Cloud-Services.
24
(Fielding, 2000)
25
(Fielding, et al., 1999) und (Berners-Lee, et al., 1996)
26
(Berners-Lee, et al., 2005A)
27
Entnommen, zusammengefasst und übersetzt aus (Richardson, et al., 2007 S. 49-54)
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
11
Einige Frameworks31
nutzen WADL32
als Beschreibungssprache, jedoch existieren in
Praxi viele Zweifel33
, ob eine formale Beschreibungssprache für den REST-
Architekturstil grundsätzlich sinnvoll ist. Allerdings sind die Zweifel meist mit der
hohen Komplexität der SOAP-Beschreibungssprache WSDL verbunden.
2.3 Eclipse Modeling Project
Eclipse Modeling Framework (EMF)
= Zentrales Projekt, stellt u.A. Metamodell bereit
EMF (Core) CDOCompareQuery Query 2
TransactionNet4j SDO Teneo Validation
Textual Modeling Framework (TMF)
Xtext TCS
Graphical Modeling Project (GMP)
Tooling Runtime
Notation Graphiti
Definition konkreter Syntax
Model Development
Tools (MDT)
BPMN Metamodel
eTrice (ROOM)
MoDisco
OCL
Papyrus
Sphinx
UML2
XSD
M2M
Atlas (ATL)
M2T
JET Xpand
Modelltransformation
Technology & Research
GMT
AM3
AMW
MOFScript
UMLX
Viatra2
Epsilon GEMS MoDisco
Forschungund
Inkubation
Anwendung
Amalgam
Verfügbarmachung
Abbildung 1 - Überblick über das Eclipse Modeling Project34 35
31
Vgl. auch Kapitel 5.1 (S. 106)
32
(Hadley, 2011)
33
Vgl. auch (Gregorio, 2007) und (Rotem-Gal-Oz, 2007)
34
Quelle: Eigene Darstellung
35
Für eine vollständige Übersicht aller Technologien siehe: (The Eclipse Foundation, 2011)
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
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
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
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 “
Analyse von Technologien und Methoden
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
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
20
Grundlegende Eigenschaften der Sprache
59
Xtend ist eine funktionale Programmiersprache und daher der Erfahrung nach be-
sonders für Ausdrücke und Modelltransformationen geeignet.
Xtend ermöglicht einen 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)
Analyse von Technologien und Methoden
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
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
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.
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
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
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
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
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
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)
Analyse von Technologien und Methoden
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.
Analyse der vorhandenen Lösung
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
Analyse der vorhandenen Lösung
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
Analyse der vorhandenen Lösung
37
Erster Schritt der Anwendung von modellgetriebenen Methoden und Technologien
war die Definition von abstrakter und konkreter Syntax für die Developer Garden
APIs. Es wurde eine abstrakte Ecore-Syntax konzipiert und eine Dynamische XMI –
Instanz als konkrete Syntax der verfügbaren Developer Garden APIs definiert.
Trennung von Struktur und Inhalt der Benutzerdokumentation
Durch die Verfügbarkeit einer formalen Beschreibung der Developer Garden APIs
konnte die Struktur vom Inhalt der Benutzerdokumentation getrennt werden.
Der Inhalt des Kapitels 4 (der Schnittstellenbeschreibung) fand sich im neu geschaf-
fenen Content-Repository wieder, einer Docbook XML-Datei, die eine einfache Pflege
der deutschen und englischen Beschreibungen der Modellelemente zuließ, da sie mit
denselben Werkzeugen bearbeitet werden konnte, wie die Benutzerdokumentation.
Darüber hinaus war es durch die Beibehaltung des Docbook XML-Schemas relativ
einfach, das Content-Repository per XSL-Stylesheet zu verarbeiten.
Abbildung 11 - Content-Repository (Ausschnitt)95
Dadurch, dass beide Beschreibungen (deutsch & englisch) sich auf ein und dasselbe
Modellelement beziehen (über die Referenzierung der name-Attribute) konnte das
Problem P1 gelöst werden.
Darüber hinaus wurde im Content-Repository die Möglichkeit geschaffen, sich wie-
derholende Parameterbeschreibungen anzulegen, beispielsweise die Beschreibung
des account-Parameters, welcher bei allen Methoden die gleiche Bedeutung hat.
Hierdurch konnten überflüssige Redundanzen in der Benutzerdokumentation abge-
baut werden.
Implementierung einer Modell-zu-Text – Transformation
Die Probleme P2 und P3 konnten durch eine Modell-zu-Text (M2T) – Transformation
gelöst werden. In der ersten Iteration war diese M2T-Transformation XSLT-basiert,
sodass die Verarbeitung von Docbook damit relativ leicht zu implementieren war.
95
Eigene Darstellung
Analyse der vorhandenen Lösung
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
96
Eigene Darstellung
Metamodell
service.ecore
Modell
developergarden.xmi
Abstrakte Syntax
Content-Repository
content.xml
M2T-Transformation
generateChapterFromModel.xsl
Struktur Inhalt
Layout
Kapitel 4 (Service-Beschreibung)
ch04.de.xml / ch04.en.xml
Andere Kapitel
ch0x.de.xml / ch0x.en.xml
Docbook XSL
Stylesheets
HTML
single
HTML
chunked
PDF
Analyse der vorhandenen Lösung
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
Analyse der vorhandenen Lösung
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)
Analyse der vorhandenen Lösung
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.
Analyse der vorhandenen Lösung
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.
99
Eigene Darstellung
Analyse der vorhandenen Lösung
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
100
Eigene Darstellung
POSThttp://gateway.developer.telekom.com/p3gw-mod-odg-voicebutler/rest/{environment}/call
httpMethod = POST
NewCall : RestMethod
restEndpoint = /p3gw-mod-odg-voicebutler/rest
VoiceCallService : Service
restHostname = gateway.developer.telekom.com
DeveloperGardenProvider : Provider
name = environment
dynamic = true
Environment : RestResource
name = call
dynamic = false
Call : RestResource
Analyse der vorhandenen Lösung
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)
Analyse der vorhandenen Lösung
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)
Analyse der vorhandenen Lösung
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)
Analyse der vorhandenen Lösung
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)
Analyse der vorhandenen Lösung
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.“
Analyse der vorhandenen Lösung
49
P10: Keine Mehrsprachigkeit
Obwohl die Benutzerdokumentation zweisprachig vorliegt, existieren die SDKs le-
diglich in einer Sprache: Englisch. Mehrsprachigkeit ist keine übliche Eigenschaft
von SDKs, jedoch steigert ein SDK mit Code-Kommentaren in Deutsch und damit in
der Muttersprache der meisten Kunden des Developer Gardens die Verständlichkeit
und damit auch die Benutzbarkeit der Developer Garden API.
Lösungsansatz: Da das Content-Repository zweisprachig vorliegt, ist es naheliegend
die Transformation für beide Sprachen durchzuführen. Dadurch können mehrere
SDK-Sprachversionen angeboten werden.
Lösungskonzept
Auf Basis der vorgenannten Lösungsansätze wurde folgendes Lösungskonzept erar-
beitet:
Abbildung 16 - Lösungskonzept der Iteration 3110
110
Eigene Darstellung
Metamodell
service.ecore
Modell
developergarden.xmi
Abstrakte Syntax
Content-Repository
content.xml
Xtend-Transformation
cleanModel.ext
„Sauberes“ REST-Modell
Developergarden.clean.xmi
Struktur
Inhalt Auflösung der Feldhierarchien
Ermittlung der Dokumentation
SDK Quellcode
Java SDK
DE
Java SDK
EN
.NET SDK
DE
.NET SDK
EN
PHP SDK
DE
PHP SDK
EN
Code-Generierung
ANT Workflow
SDK - Endergebnis
Java SDK
DE
Java SDK
EN
.NET SDK
DE
.NET SDK
EN
PHP SDK
DE
PHP SDK
EN
Statische
Bestandteile
Plattformspezifischer
Build-Vorgang
Xpand - Templates
Xtend - Funktionen
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden Generierung von SDKs zum Zugriff auf Webservices unter Anwendung von Methoden der modellgetriebenen Softwareentwicklung

Weitere ähnliche Inhalte

Was ist angesagt?

Agiles Projektmanagement – Projektentwicklung mit Scrum, Kanb an & Co.
Agiles Projektmanagement – Projektentwicklung mit Scrum, Kanb an & Co.Agiles Projektmanagement – Projektentwicklung mit Scrum, Kanb an & Co.
Agiles Projektmanagement – Projektentwicklung mit Scrum, Kanb an & Co.
TechDivision GmbH
 
Praxishandbuch Berufsorientierung im multikulturellen Kontext
Praxishandbuch Berufsorientierung im multikulturellen KontextPraxishandbuch Berufsorientierung im multikulturellen Kontext
Praxishandbuch Berufsorientierung im multikulturellen Kontext
HPI - Human Potential Institut e.U.
 
Künstlervermarktung und Präsentation im Bereich Social Media/Social Networks
Künstlervermarktung und Präsentation im Bereich Social Media/Social NetworksKünstlervermarktung und Präsentation im Bereich Social Media/Social Networks
Künstlervermarktung und Präsentation im Bereich Social Media/Social Networks
Felix Bauer
 
Bachelorarbeit - Die vergleichende Potentialanalyse des Reittourismus im inte...
Bachelorarbeit - Die vergleichende Potentialanalyse des Reittourismus im inte...Bachelorarbeit - Die vergleichende Potentialanalyse des Reittourismus im inte...
Bachelorarbeit - Die vergleichende Potentialanalyse des Reittourismus im inte...Roxana Darjan
 
Design Thinking für Dummies
Design Thinking für DummiesDesign Thinking für Dummies
Design Thinking für Dummies
Hochschule Ruhr West
 
Venture Philanthropy. Ein Partnerschaftsmodell zwischen Unternehmen und Nonpr...
Venture Philanthropy. Ein Partnerschaftsmodell zwischen Unternehmen und Nonpr...Venture Philanthropy. Ein Partnerschaftsmodell zwischen Unternehmen und Nonpr...
Venture Philanthropy. Ein Partnerschaftsmodell zwischen Unternehmen und Nonpr...
Sira Saccani
 
2b version bachelorarbeit
2b  version bachelorarbeit2b  version bachelorarbeit
2b version bachelorarbeitkamer3
 
Wissensmanagement in der Praxis - Ein Reader, Prof. Lutz Leuendorf
Wissensmanagement in der Praxis - Ein Reader, Prof. Lutz LeuendorfWissensmanagement in der Praxis - Ein Reader, Prof. Lutz Leuendorf
Wissensmanagement in der Praxis - Ein Reader, Prof. Lutz Leuendorf
Andreas Genth
 
Ivor Vidjen - Diplomarbeit
Ivor Vidjen - DiplomarbeitIvor Vidjen - Diplomarbeit
Ivor Vidjen - DiplomarbeitIvor Vidjen
 
Zweiter bericht-der-nationalen-plattform-elektromobiltaet
Zweiter bericht-der-nationalen-plattform-elektromobiltaetZweiter bericht-der-nationalen-plattform-elektromobiltaet
Zweiter bericht-der-nationalen-plattform-elektromobiltaet
ZERAuto nl
 
Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 - Ergebniss...
Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 -  Ergebniss...Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 -  Ergebniss...
Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 - Ergebniss...eBusinessLotse-Suedwestfalen-Hagen
 
Untersuchung zum Stellenwert der Vinylschallplatte im Internet
Untersuchung zum Stellenwert der Vinylschallplatte im InternetUntersuchung zum Stellenwert der Vinylschallplatte im Internet
Untersuchung zum Stellenwert der Vinylschallplatte im Internet
Sarah Steffen
 
Handbuch CONSIDEO Modeler V 5.0
Handbuch CONSIDEO Modeler V 5.0Handbuch CONSIDEO Modeler V 5.0
Handbuch CONSIDEO Modeler V 5.0
Detlef Kahrs
 
Team Oldenburger Robo-Fußball – Abschlussbericht der Projektgruppe 2010
Team Oldenburger Robo-Fußball – Abschlussbericht  der Projektgruppe  2010Team Oldenburger Robo-Fußball – Abschlussbericht  der Projektgruppe  2010
Team Oldenburger Robo-Fußball – Abschlussbericht der Projektgruppe 2010Johannes Diemke
 
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
PROJECT CONSULT Unternehmensberatung Dr. Ulrich Kampffmeyer GmbH
 
Katalog von KTS Kettentechnik GmbH
Katalog von KTS Kettentechnik GmbHKatalog von KTS Kettentechnik GmbH
Katalog von KTS Kettentechnik GmbH
Sebastian Klemm
 
BISS_Expertise.pdf
BISS_Expertise.pdfBISS_Expertise.pdf
BISS_Expertise.pdf
unn | UNITED NEWS NETWORK GmbH
 
Magisterarbeit Lars Focke
Magisterarbeit Lars FockeMagisterarbeit Lars Focke
Magisterarbeit Lars Focke
Lars Focke
 

Was ist angesagt? (20)

Agiles Projektmanagement – Projektentwicklung mit Scrum, Kanb an & Co.
Agiles Projektmanagement – Projektentwicklung mit Scrum, Kanb an & Co.Agiles Projektmanagement – Projektentwicklung mit Scrum, Kanb an & Co.
Agiles Projektmanagement – Projektentwicklung mit Scrum, Kanb an & Co.
 
Praxishandbuch Berufsorientierung im multikulturellen Kontext
Praxishandbuch Berufsorientierung im multikulturellen KontextPraxishandbuch Berufsorientierung im multikulturellen Kontext
Praxishandbuch Berufsorientierung im multikulturellen Kontext
 
Künstlervermarktung und Präsentation im Bereich Social Media/Social Networks
Künstlervermarktung und Präsentation im Bereich Social Media/Social NetworksKünstlervermarktung und Präsentation im Bereich Social Media/Social Networks
Künstlervermarktung und Präsentation im Bereich Social Media/Social Networks
 
Handbuch
HandbuchHandbuch
Handbuch
 
Bachelorarbeit - Die vergleichende Potentialanalyse des Reittourismus im inte...
Bachelorarbeit - Die vergleichende Potentialanalyse des Reittourismus im inte...Bachelorarbeit - Die vergleichende Potentialanalyse des Reittourismus im inte...
Bachelorarbeit - Die vergleichende Potentialanalyse des Reittourismus im inte...
 
Design Thinking für Dummies
Design Thinking für DummiesDesign Thinking für Dummies
Design Thinking für Dummies
 
Venture Philanthropy. Ein Partnerschaftsmodell zwischen Unternehmen und Nonpr...
Venture Philanthropy. Ein Partnerschaftsmodell zwischen Unternehmen und Nonpr...Venture Philanthropy. Ein Partnerschaftsmodell zwischen Unternehmen und Nonpr...
Venture Philanthropy. Ein Partnerschaftsmodell zwischen Unternehmen und Nonpr...
 
2b version bachelorarbeit
2b  version bachelorarbeit2b  version bachelorarbeit
2b version bachelorarbeit
 
Wissensmanagement in der Praxis - Ein Reader, Prof. Lutz Leuendorf
Wissensmanagement in der Praxis - Ein Reader, Prof. Lutz LeuendorfWissensmanagement in der Praxis - Ein Reader, Prof. Lutz Leuendorf
Wissensmanagement in der Praxis - Ein Reader, Prof. Lutz Leuendorf
 
Ivor Vidjen - Diplomarbeit
Ivor Vidjen - DiplomarbeitIvor Vidjen - Diplomarbeit
Ivor Vidjen - Diplomarbeit
 
Zweiter bericht-der-nationalen-plattform-elektromobiltaet
Zweiter bericht-der-nationalen-plattform-elektromobiltaetZweiter bericht-der-nationalen-plattform-elektromobiltaet
Zweiter bericht-der-nationalen-plattform-elektromobiltaet
 
Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 - Ergebniss...
Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 -  Ergebniss...Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 -  Ergebniss...
Elektronischer Geschäftsverkehr in Mittelstand und Handwerk 2010 - Ergebniss...
 
Untersuchung zum Stellenwert der Vinylschallplatte im Internet
Untersuchung zum Stellenwert der Vinylschallplatte im InternetUntersuchung zum Stellenwert der Vinylschallplatte im Internet
Untersuchung zum Stellenwert der Vinylschallplatte im Internet
 
Handbuch CONSIDEO Modeler V 5.0
Handbuch CONSIDEO Modeler V 5.0Handbuch CONSIDEO Modeler V 5.0
Handbuch CONSIDEO Modeler V 5.0
 
Mocek Thesis
Mocek ThesisMocek Thesis
Mocek Thesis
 
Team Oldenburger Robo-Fußball – Abschlussbericht der Projektgruppe 2010
Team Oldenburger Robo-Fußball – Abschlussbericht  der Projektgruppe  2010Team Oldenburger Robo-Fußball – Abschlussbericht  der Projektgruppe  2010
Team Oldenburger Robo-Fußball – Abschlussbericht der Projektgruppe 2010
 
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
[DE] Dr. Ulrich Kampffmeyer - Artikel auf Wikipedia | 2015
 
Katalog von KTS Kettentechnik GmbH
Katalog von KTS Kettentechnik GmbHKatalog von KTS Kettentechnik GmbH
Katalog von KTS Kettentechnik GmbH
 
BISS_Expertise.pdf
BISS_Expertise.pdfBISS_Expertise.pdf
BISS_Expertise.pdf
 
Magisterarbeit Lars Focke
Magisterarbeit Lars FockeMagisterarbeit Lars Focke
Magisterarbeit Lars Focke
 

Andere mochten auch

Die Tschechische Republik
Die Tschechische RepublikDie Tschechische Republik
Die Tschechische Republik
michaeladavidova
 
Social Media und Fische
Social Media und FischeSocial Media und Fische
Social Media und Fische
Olaf Nitz
 
Gost 14063 68
 Gost 14063 68 Gost 14063 68
Gost 14063 68Kinlay89
 
Das gemeinnützige Schulprojekt "Fotobuch Landkreis Bamberg"
Das gemeinnützige Schulprojekt "Fotobuch Landkreis Bamberg"Das gemeinnützige Schulprojekt "Fotobuch Landkreis Bamberg"
Das gemeinnützige Schulprojekt "Fotobuch Landkreis Bamberg"
Arno Schimmelpfennig
 
Referenza - Dott Peter Hoeyng
Referenza - Dott Peter HoeyngReferenza - Dott Peter Hoeyng
Referenza - Dott Peter HoeyngCallie Jordan
 
Kundenentscheidungen in multimedialen Vertriebswelt
Kundenentscheidungen in multimedialen VertriebsweltKundenentscheidungen in multimedialen Vertriebswelt
Kundenentscheidungen in multimedialen VertriebsweltKatja Schneider
 
Was tun im Social Web?
Was tun im Social Web?Was tun im Social Web?
Was tun im Social Web?
Olaf Nitz
 
Facebook
FacebookFacebook
Facebook
Bilal Günaydin
 
Markenrivalität : War of the Brands
Markenrivalität : War of the BrandsMarkenrivalität : War of the Brands
Markenrivalität : War of the BrandsPaul Pernez
 
PackageRide - erste Schweizer Mitfahrgelegenheit für Pakete, so geht's
PackageRide - erste Schweizer Mitfahrgelegenheit für Pakete, so geht'sPackageRide - erste Schweizer Mitfahrgelegenheit für Pakete, so geht's
PackageRide - erste Schweizer Mitfahrgelegenheit für Pakete, so geht's
PackageRide
 
PR im Social Web
PR im Social WebPR im Social Web
PR im Social Web
Olaf Nitz
 
fotokurse zürich
fotokurse zürichfotokurse zürich
fotokurse zürich
Linda Bonham
 

Andere mochten auch (16)

TIK KELAS 9 BAB 2
TIK KELAS 9 BAB 2TIK KELAS 9 BAB 2
TIK KELAS 9 BAB 2
 
Die Tschechische Republik
Die Tschechische RepublikDie Tschechische Republik
Die Tschechische Republik
 
Social Media und Fische
Social Media und FischeSocial Media und Fische
Social Media und Fische
 
Hamster
HamsterHamster
Hamster
 
Gost 14063 68
 Gost 14063 68 Gost 14063 68
Gost 14063 68
 
Das gemeinnützige Schulprojekt "Fotobuch Landkreis Bamberg"
Das gemeinnützige Schulprojekt "Fotobuch Landkreis Bamberg"Das gemeinnützige Schulprojekt "Fotobuch Landkreis Bamberg"
Das gemeinnützige Schulprojekt "Fotobuch Landkreis Bamberg"
 
Referenza - Dott Peter Hoeyng
Referenza - Dott Peter HoeyngReferenza - Dott Peter Hoeyng
Referenza - Dott Peter Hoeyng
 
Kundenentscheidungen in multimedialen Vertriebswelt
Kundenentscheidungen in multimedialen VertriebsweltKundenentscheidungen in multimedialen Vertriebswelt
Kundenentscheidungen in multimedialen Vertriebswelt
 
Was tun im Social Web?
Was tun im Social Web?Was tun im Social Web?
Was tun im Social Web?
 
Facebook
FacebookFacebook
Facebook
 
Markenrivalität : War of the Brands
Markenrivalität : War of the BrandsMarkenrivalität : War of the Brands
Markenrivalität : War of the Brands
 
Absolventa_LK
Absolventa_LKAbsolventa_LK
Absolventa_LK
 
PackageRide - erste Schweizer Mitfahrgelegenheit für Pakete, so geht's
PackageRide - erste Schweizer Mitfahrgelegenheit für Pakete, so geht'sPackageRide - erste Schweizer Mitfahrgelegenheit für Pakete, so geht's
PackageRide - erste Schweizer Mitfahrgelegenheit für Pakete, so geht's
 
PR im Social Web
PR im Social WebPR im Social Web
PR im Social Web
 
fotokurse zürich
fotokurse zürichfotokurse zürich
fotokurse zürich
 
Winder
WinderWinder
Winder
 

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

Leich begruendung
Leich begruendungLeich begruendung
Leich begruendung
plvisit
 
German Original
German OriginalGerman Original
German Original
guestbf6d98
 
Machbarkeitsanalyse und prototypische Entwicklung eines eMagazines für das A...
Machbarkeitsanalyse und prototypische Entwicklung eines eMagazines für das A...Machbarkeitsanalyse und prototypische Entwicklung eines eMagazines für das A...
Machbarkeitsanalyse und prototypische Entwicklung eines eMagazines für das A...
Jonathan Keller
 
Final Opentrans 2.0 Rfq
Final Opentrans 2.0   RfqFinal Opentrans 2.0   Rfq
Final Opentrans 2.0 Rfqguest6f1fb4
 
Filipchudzinski envisioning v1.02_auszug
Filipchudzinski envisioning v1.02_auszugFilipchudzinski envisioning v1.02_auszug
Filipchudzinski envisioning v1.02_auszug
dburle
 
Evaluierungsmodell
EvaluierungsmodellEvaluierungsmodell
Evaluierungsmodelloneduphine
 
Evaluierungsmodell
EvaluierungsmodellEvaluierungsmodell
Evaluierungsmodelloneduphine
 
HTML5 und CSS3 Übersicht
HTML5 und CSS3 ÜbersichtHTML5 und CSS3 Übersicht
HTML5 und CSS3 Übersicht
Sven Brencher
 
Weerth: Das neue Ausfuhrverfahren, 1. Auflage 2005, Inhaltsverzeichnis
Weerth: Das neue Ausfuhrverfahren, 1. Auflage 2005, InhaltsverzeichnisWeerth: Das neue Ausfuhrverfahren, 1. Auflage 2005, Inhaltsverzeichnis
Weerth: Das neue Ausfuhrverfahren, 1. Auflage 2005, Inhaltsverzeichnis
Dr. Carsten Weerth BSc (University of Glasgow) LLM MA
 
Master thesis pascal_mueller01
Master thesis pascal_mueller01Master thesis pascal_mueller01
Master thesis pascal_mueller01guest39ce4e
 
Entwicklung eines Frameworks zum automatisierten Handel eines Multi-Broker-PA...
Entwicklung eines Frameworks zum automatisierten Handel eines Multi-Broker-PA...Entwicklung eines Frameworks zum automatisierten Handel eines Multi-Broker-PA...
Entwicklung eines Frameworks zum automatisierten Handel eines Multi-Broker-PA...
Sascha Jonas
 
Berliner Open-Data-Strategie
Berliner Open-Data-StrategieBerliner Open-Data-Strategie
Berliner Open-Data-Strategie
Projekt Zukunft Berlin
 
Sappres Netweaver Identity Management
Sappres Netweaver Identity ManagementSappres Netweaver Identity Management
Sappres Netweaver Identity Managementgueste2a899
 
Algorithmen und Applikationen zur interaktiven Visualisierung und Analyse ch...
Algorithmen und Applikationen zur interaktiven  Visualisierung und Analyse ch...Algorithmen und Applikationen zur interaktiven  Visualisierung und Analyse ch...
Algorithmen und Applikationen zur interaktiven Visualisierung und Analyse ch...
Frank Oellien
 
Homematic
HomematicHomematic
Homematic
guest3f30e4
 
Diplomarbeit
DiplomarbeitDiplomarbeit
Diplomarbeit
Thorsten Grün
 
Blended learning mathe_v1.7_03052010
Blended learning mathe_v1.7_03052010Blended learning mathe_v1.7_03052010
Blended learning mathe_v1.7_03052010
Carsten Freundl
 
Projektkommunikation: Leseprobe
Projektkommunikation: LeseprobeProjektkommunikation: Leseprobe
Projektkommunikation: Leseprobe
vdf Hochschulverlag AG
 

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

BSI Audit
BSI AuditBSI Audit
BSI Audit
 
Leich begruendung
Leich begruendungLeich begruendung
Leich begruendung
 
German Original
German OriginalGerman Original
German Original
 
Machbarkeitsanalyse und prototypische Entwicklung eines eMagazines für das A...
Machbarkeitsanalyse und prototypische Entwicklung eines eMagazines für das A...Machbarkeitsanalyse und prototypische Entwicklung eines eMagazines für das A...
Machbarkeitsanalyse und prototypische Entwicklung eines eMagazines für das A...
 
Final Opentrans 2.0 Rfq
Final Opentrans 2.0   RfqFinal Opentrans 2.0   Rfq
Final Opentrans 2.0 Rfq
 
Filipchudzinski envisioning v1.02_auszug
Filipchudzinski envisioning v1.02_auszugFilipchudzinski envisioning v1.02_auszug
Filipchudzinski envisioning v1.02_auszug
 
Evaluierungsmodell
EvaluierungsmodellEvaluierungsmodell
Evaluierungsmodell
 
Evaluierungsmodell
EvaluierungsmodellEvaluierungsmodell
Evaluierungsmodell
 
HTML5 und CSS3 Übersicht
HTML5 und CSS3 ÜbersichtHTML5 und CSS3 Übersicht
HTML5 und CSS3 Übersicht
 
Weerth: Das neue Ausfuhrverfahren, 1. Auflage 2005, Inhaltsverzeichnis
Weerth: Das neue Ausfuhrverfahren, 1. Auflage 2005, InhaltsverzeichnisWeerth: Das neue Ausfuhrverfahren, 1. Auflage 2005, Inhaltsverzeichnis
Weerth: Das neue Ausfuhrverfahren, 1. Auflage 2005, Inhaltsverzeichnis
 
Master thesis pascal_mueller01
Master thesis pascal_mueller01Master thesis pascal_mueller01
Master thesis pascal_mueller01
 
Entwicklung eines Frameworks zum automatisierten Handel eines Multi-Broker-PA...
Entwicklung eines Frameworks zum automatisierten Handel eines Multi-Broker-PA...Entwicklung eines Frameworks zum automatisierten Handel eines Multi-Broker-PA...
Entwicklung eines Frameworks zum automatisierten Handel eines Multi-Broker-PA...
 
Berliner Open-Data-Strategie
Berliner Open-Data-StrategieBerliner Open-Data-Strategie
Berliner Open-Data-Strategie
 
Sappres Netweaver Identity Management
Sappres Netweaver Identity ManagementSappres Netweaver Identity Management
Sappres Netweaver Identity Management
 
Algorithmen und Applikationen zur interaktiven Visualisierung und Analyse ch...
Algorithmen und Applikationen zur interaktiven  Visualisierung und Analyse ch...Algorithmen und Applikationen zur interaktiven  Visualisierung und Analyse ch...
Algorithmen und Applikationen zur interaktiven Visualisierung und Analyse ch...
 
Homematic
HomematicHomematic
Homematic
 
Homematic
HomematicHomematic
Homematic
 
Diplomarbeit
DiplomarbeitDiplomarbeit
Diplomarbeit
 
Blended learning mathe_v1.7_03052010
Blended learning mathe_v1.7_03052010Blended learning mathe_v1.7_03052010
Blended learning mathe_v1.7_03052010
 
Projektkommunikation: Leseprobe
Projektkommunikation: LeseprobeProjektkommunikation: Leseprobe
Projektkommunikation: Leseprobe
 

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

  • 1. 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
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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)
  • 7. 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.
  • 8. 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)
  • 9. Analyse von Technologien und Methoden 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)
  • 10. Analyse von Technologien und Methoden 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
  • 11. Analyse von Technologien und Methoden 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)
  • 12. Analyse von Technologien und Methoden 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)
  • 13. Analyse von Technologien und Methoden 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)
  • 14. Analyse von Technologien und Methoden 9 2.2.2 Ressourcenorientiert (REST) Der Ressourcenorientierte Architekturstil (REST) wurde erstmals in der Doktorarbeit von Roy Thomas Fielding24 ausgearbeitet, einem der Hauptautoren der HTTP25 und URI26 – Spezifikationen. Die grundlegende Idee besteht darin, eine Schnittstelle nicht wie bei RPC als Menge von Methoden und Parametern zu abstrahieren, sondern mithilfe von Ressourcen und Operationen. REST integriert die Standards URI und HTTP in ihrer originären Anwendungsdomäne: Mithilfe von URIs werden Ressourcen adressiert, das HTTP- Protokoll definiert die auf Ressourcen anzuwendenden Operationen, im Regelfall GET, POST, PUT und DELETE. Darüber hinaus nutzen REST-Schnittstellen viele im HTT-Protokoll vorgesehenen Mechanismen in ihrer originären Anwendungsform. So wird z.B. die HTTP Content- Negotiation (HTTP-Header Accept und Content-Type) für das Vereinbaren eines gemeinsamen Datenaustauschformats wiederverwendet. Außerdem können REST Antworten über dieselben Mechanismen zwischenspeichert werden, wie herkömmli- che Internet-Inhalte (z.B. durch Übermittlung von Expire oder Last-Modified Hea- dern). Letztendlich finden sich auch HTTP-Statuscodes in REST-Schnittstellen in ei- ner vergleichbaren Rolle wieder, wie bei gängigen Internet-Anwendungen. Obwohl der REST-Architekturstil wenige abstrakte Vorgaben bezüglich der konkre- ten Gestaltung von REST-APIs beinhaltet, so zeigt sich in der Vielzahl der REST Webservice-Schnittstellen die allgemeine Anwendbarkeit und die Qualität des Kon- zepts. Außerdem tragen die Klarheit der Schnittstellendefinition sowie die Bezie- hung auf ausgereifte Standards dazu bei, dass der REST-Architekturstil mittlerweile zum vorherrschenden Muster für den Entwurf und die Implementierung von Web Service-Schnittstellen geworden ist. Beispiel der Anwendung des REST-Architekturstils anhand Amazon S3 27 Der Amazon Simple Storage Service (S3) ist ein gutes Beispiel für die Anwendung des REST-Architekturstils zum Entwurf und zur Anwendung von Cloud-Services. 24 (Fielding, 2000) 25 (Fielding, et al., 1999) und (Berners-Lee, et al., 1996) 26 (Berners-Lee, et al., 2005A) 27 Entnommen, zusammengefasst und übersetzt aus (Richardson, et al., 2007 S. 49-54)
  • 15. Analyse von Technologien und Methoden 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)
  • 16. Analyse von Technologien und Methoden 11 Einige Frameworks31 nutzen WADL32 als Beschreibungssprache, jedoch existieren in Praxi viele Zweifel33 , ob eine formale Beschreibungssprache für den REST- Architekturstil grundsätzlich sinnvoll ist. Allerdings sind die Zweifel meist mit der hohen Komplexität der SOAP-Beschreibungssprache WSDL verbunden. 2.3 Eclipse Modeling Project Eclipse Modeling Framework (EMF) = Zentrales Projekt, stellt u.A. Metamodell bereit EMF (Core) CDOCompareQuery Query 2 TransactionNet4j SDO Teneo Validation Textual Modeling Framework (TMF) Xtext TCS Graphical Modeling Project (GMP) Tooling Runtime Notation Graphiti Definition konkreter Syntax Model Development Tools (MDT) BPMN Metamodel eTrice (ROOM) MoDisco OCL Papyrus Sphinx UML2 XSD M2M Atlas (ATL) M2T JET Xpand Modelltransformation Technology & Research GMT AM3 AMW MOFScript UMLX Viatra2 Epsilon GEMS MoDisco Forschungund Inkubation Anwendung Amalgam Verfügbarmachung Abbildung 1 - Überblick über das Eclipse Modeling Project34 35 31 Vgl. auch Kapitel 5.1 (S. 106) 32 (Hadley, 2011) 33 Vgl. auch (Gregorio, 2007) und (Rotem-Gal-Oz, 2007) 34 Quelle: Eigene Darstellung 35 Für eine vollständige Übersicht aller Technologien siehe: (The Eclipse Foundation, 2011)
  • 17. Analyse von Technologien und Methoden 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)
  • 18. Analyse von Technologien und Methoden 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)
  • 19. Analyse von Technologien und Methoden 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
  • 20. Analyse von Technologien und Methoden 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)
  • 21. Analyse von Technologien und Methoden 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 “
  • 22. Analyse von Technologien und Methoden 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
  • 23. Analyse von Technologien und Methoden 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)
  • 24. Analyse von Technologien und Methoden 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)
  • 25. Analyse von Technologien und Methoden 20 Grundlegende Eigenschaften der Sprache 59 Xtend ist eine funktionale Programmiersprache und daher der Erfahrung nach be- sonders für Ausdrücke und Modelltransformationen geeignet. Xtend ermöglicht einen 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)
  • 26. Analyse von Technologien und Methoden 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
  • 27. Analyse von Technologien und Methoden 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)
  • 28. Analyse von Technologien und Methoden 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)
  • 29. Analyse von Technologien und Methoden 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.
  • 30. Analyse von Technologien und Methoden 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)
  • 31. Analyse von Technologien und Methoden 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)
  • 32. Analyse von Technologien und Methoden 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)
  • 33. Analyse von Technologien und Methoden 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
  • 34. Analyse von Technologien und Methoden 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)
  • 35. Analyse von Technologien und Methoden 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
  • 36. Analyse von Technologien und Methoden 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)
  • 37. Analyse von Technologien und Methoden 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)
  • 38. Analyse von Technologien und Methoden 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)
  • 39. 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.
  • 40. Analyse der vorhandenen Lösung 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
  • 41. Analyse der vorhandenen Lösung 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
  • 42. Analyse der vorhandenen Lösung 37 Erster Schritt der Anwendung von modellgetriebenen Methoden und Technologien war die Definition von abstrakter und konkreter Syntax für die Developer Garden APIs. Es wurde eine abstrakte Ecore-Syntax konzipiert und eine Dynamische XMI – Instanz als konkrete Syntax der verfügbaren Developer Garden APIs definiert. Trennung von Struktur und Inhalt der Benutzerdokumentation Durch die Verfügbarkeit einer formalen Beschreibung der Developer Garden APIs konnte die Struktur vom Inhalt der Benutzerdokumentation getrennt werden. Der Inhalt des Kapitels 4 (der Schnittstellenbeschreibung) fand sich im neu geschaf- fenen Content-Repository wieder, einer Docbook XML-Datei, die eine einfache Pflege der deutschen und englischen Beschreibungen der Modellelemente zuließ, da sie mit denselben Werkzeugen bearbeitet werden konnte, wie die Benutzerdokumentation. Darüber hinaus war es durch die Beibehaltung des Docbook XML-Schemas relativ einfach, das Content-Repository per XSL-Stylesheet zu verarbeiten. Abbildung 11 - Content-Repository (Ausschnitt)95 Dadurch, dass beide Beschreibungen (deutsch & englisch) sich auf ein und dasselbe Modellelement beziehen (über die Referenzierung der name-Attribute) konnte das Problem P1 gelöst werden. Darüber hinaus wurde im Content-Repository die Möglichkeit geschaffen, sich wie- derholende Parameterbeschreibungen anzulegen, beispielsweise die Beschreibung des account-Parameters, welcher bei allen Methoden die gleiche Bedeutung hat. Hierdurch konnten überflüssige Redundanzen in der Benutzerdokumentation abge- baut werden. Implementierung einer Modell-zu-Text – Transformation Die Probleme P2 und P3 konnten durch eine Modell-zu-Text (M2T) – Transformation gelöst werden. In der ersten Iteration war diese M2T-Transformation XSLT-basiert, sodass die Verarbeitung von Docbook damit relativ leicht zu implementieren war. 95 Eigene Darstellung
  • 43. Analyse der vorhandenen Lösung 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 96 Eigene Darstellung Metamodell service.ecore Modell developergarden.xmi Abstrakte Syntax Content-Repository content.xml M2T-Transformation generateChapterFromModel.xsl Struktur Inhalt Layout Kapitel 4 (Service-Beschreibung) ch04.de.xml / ch04.en.xml Andere Kapitel ch0x.de.xml / ch0x.en.xml Docbook XSL Stylesheets HTML single HTML chunked PDF
  • 44. Analyse der vorhandenen Lösung 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
  • 45. Analyse der vorhandenen Lösung 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)
  • 46. Analyse der vorhandenen Lösung 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.
  • 47. Analyse der vorhandenen Lösung 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. 99 Eigene Darstellung
  • 48. Analyse der vorhandenen Lösung 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 100 Eigene Darstellung POSThttp://gateway.developer.telekom.com/p3gw-mod-odg-voicebutler/rest/{environment}/call httpMethod = POST NewCall : RestMethod restEndpoint = /p3gw-mod-odg-voicebutler/rest VoiceCallService : Service restHostname = gateway.developer.telekom.com DeveloperGardenProvider : Provider name = environment dynamic = true Environment : RestResource name = call dynamic = false Call : RestResource
  • 49. Analyse der vorhandenen Lösung 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)
  • 50. Analyse der vorhandenen Lösung 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)
  • 51. Analyse der vorhandenen Lösung 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)
  • 52. Analyse der vorhandenen Lösung 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)
  • 53. Analyse der vorhandenen Lösung 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.“
  • 54. Analyse der vorhandenen Lösung 49 P10: Keine Mehrsprachigkeit Obwohl die Benutzerdokumentation zweisprachig vorliegt, existieren die SDKs le- diglich in einer Sprache: Englisch. Mehrsprachigkeit ist keine übliche Eigenschaft von SDKs, jedoch steigert ein SDK mit Code-Kommentaren in Deutsch und damit in der Muttersprache der meisten Kunden des Developer Gardens die Verständlichkeit und damit auch die Benutzbarkeit der Developer Garden API. Lösungsansatz: Da das Content-Repository zweisprachig vorliegt, ist es naheliegend die Transformation für beide Sprachen durchzuführen. Dadurch können mehrere SDK-Sprachversionen angeboten werden. Lösungskonzept Auf Basis der vorgenannten Lösungsansätze wurde folgendes Lösungskonzept erar- beitet: Abbildung 16 - Lösungskonzept der Iteration 3110 110 Eigene Darstellung Metamodell service.ecore Modell developergarden.xmi Abstrakte Syntax Content-Repository content.xml Xtend-Transformation cleanModel.ext „Sauberes“ REST-Modell Developergarden.clean.xmi Struktur Inhalt Auflösung der Feldhierarchien Ermittlung der Dokumentation SDK Quellcode Java SDK DE Java SDK EN .NET SDK DE .NET SDK EN PHP SDK DE PHP SDK EN Code-Generierung ANT Workflow SDK - Endergebnis Java SDK DE Java SDK EN .NET SDK DE .NET SDK EN PHP SDK DE PHP SDK EN Statische Bestandteile Plattformspezifischer Build-Vorgang Xpand - Templates Xtend - Funktionen