Freie wissenschaftliche Arbeit zur Erlangung des akademischen Grades
Master of Science in Wirtschaftsinformatik
Entwicklun...
Inhaltsverzeichnis
i
Inhaltsverzeichnis
1 Einleitung ........................................................................
Inhaltsverzeichnis
ii
4 GenerationREST: Konzipierung und Implementierung .......................61
4.1 Metamodell............
Abbildungsverzeichnis
iii
Abbildungsverzeichnis
Abbildung 1 - Überblick über das Eclipse Modeling Project ...................
Verwendete Konventionen
iv
Verwendete Konventionen
In dieser Arbeit werden die folgenden typografischen Konventionen verwen...
Einleitung
1
1 Einleitung
Eine Betrachtung der aktuellen Trends in der Informationstechnologie zeigt eine kla-
re Hinwendu...
Einleitung
2
Im Laufe meiner Beschäftigung bei der Deutschen Telekom AG habe ich seit Anfang
des Jahres 2010 in mehreren I...
Analyse von Technologien und Methoden
3
2 Analyse von Technologien und Methoden
Dieses Kapitel soll die eingesetzten Techn...
Analyse von Technologien und Methoden
4
Dabei wird häufig eine in den Veröffentlichungen der Object Management Group
(OMG)1...
Analyse von Technologien und Methoden
5
Für die Unterstützung modellgetriebener Softwareentwicklungsprojekte sind dar-
übe...
Analyse von Technologien und Methoden
6
Steigerung von Produktivität und Qualität Erhöhte Aufwände
Modell und Software sin...
Analyse von Technologien und Methoden
7
Mittlerweile existieren auf Remote Procedure Call aufbauende Technologien für eine...
Analyse von Technologien und Methoden
8
Obwohl zahlreiche Implementierungen bestehen20
und auch einige Softwareproduk-
te ...
Analyse von Technologien und Methoden
9
2.2.2 Ressourcenorientiert (REST)
Der Ressourcenorientierte Architekturstil (REST)...
Analyse von Technologien und Methoden
10
Amazon S3 ermöglicht die Speicherung beliebig strukturierter Daten und Metadaten
...
Analyse von Technologien und Methoden
11
Einige Frameworks31
nutzen WADL32
als Beschreibungssprache, jedoch existieren in
...
Analyse von Technologien und Methoden
12
Das Eclipse Modeling Project ist der „Schmelztiegel“ der modellgetriebenen Ent-
w...
Analyse von Technologien und Methoden
13
Amalgam / Modeling Amalgamation Project
Der Name des Amalgam-Bereichs des EMP lei...
Analyse von Technologien und Methoden
14
Eine zentrale Rolle nimmt dabei der Unterbereich EMF (Core) ein: EMF (Core) defi-
...
Analyse von Technologien und Methoden
15
2.3.2 Ecore
Ecore ist das zentrale Metamodell des EMF. Die folgende Darstellung z...
Analyse von Technologien und Methoden
16
Eine Besonderheit an Ecore ist die Möglichkeit der Modell-Definition über verschie...
Analyse von Technologien und Methoden
17
Allerdings muss in Ecore die gekennzeichnete Eigenschaft global für alle Elemente...
Analyse von Technologien und Methoden
18
2.4 Haupttechnologien des vorhandenen Frameworks
Im Folgenden sollen die Haupttec...
Analyse von Technologien und Methoden
19
Darüber hinaus bildet das oAW-Typsystem eine Abstraktionsschicht über verschie-
d...
Analyse von Technologien und Methoden
20
Grundlegende Eigenschaften der Sprache
59
Xtend ist eine funktionale Programmiers...
Analyse von Technologien und Methoden
21
Folgendes Beispiel soll die dynamische Bindung von Xtend erläutern: 60
Gegeben se...
Analyse von Technologien und Methoden
22
Caching
Xtend unterstützt das Zwischenspeichern der Rückgabewerte von Funktionen....
Analyse von Technologien und Methoden
23
Durch Create-Extensions können auch komplexe Transformationen, wie die
cleanModel...
Analyse von Technologien und Methoden
24
In Xpand definierte Code-Templates nutzen dieselbe Semantik, wie Xtend-
Funktionen...
Analyse von Technologien und Methoden
25
2.5 Einzusetzende Technologien in GenerationREST
2.5.1 Xtend 2
Xtend 2 ist die We...
Analyse von Technologien und Methoden
26
Insgesamt lässt sich feststellen, dass Xtend 2 nahezu alle Funktionen von Xtend u...
Analyse von Technologien und Methoden
27
Die Konstrukte zur dynamischen Ansprache von Ecore-Modellen sind in Xtend 2
gleic...
Analyse von Technologien und Methoden
28
Die Unterstützung der Code-Generierung durch Xtend 2 Rich Strings enthält gegen-
...
Analyse von Technologien und Methoden
29
Allerdings ist die Xtend Code-Generierung bei der Behandlung von generischen
Klas...
Analyse von Technologien und Methoden
30
/*
* Data Types
*/
RestString returns rest::RestDataTypeString:
name=ID 'String' ...
Analyse von Technologien und Methoden
31
Gründe für die Verwendung von Xtext im neuen Framework
Textuelle DSLs ermöglichen...
Analyse von Technologien und Methoden
32
Die Verwendung von Xtext verbessert die Zugänglichkeit der Workflow-Definition
durc...
Analyse von Technologien und Methoden
33
REST Network APIs
Unterstützte Datenformate der REST-Schnittstelle sind XML, JSON...
Analyse der vorhandenen Lösung
34
3 Analyse der vorhandenen Lösung
Zur Generierung der Developer Garden SDKs wurde von mir...
Analyse der vorhandenen Lösung
35
Obwohl zu einem Service eine formale Schnittstellendefinition vorliegt, ist der Auf-
wand...
Analyse der vorhandenen Lösung
36
P3 Vielgestaltiges Layout
Durch die manuelle Pflege von unterschiedlichen Sprachversionen...
Analyse der vorhandenen Lösung
37
Erster Schritt der Anwendung von modellgetriebenen Methoden und Technologien
war die Defi...
Analyse der vorhandenen Lösung
38
Die Transformation enthielt Layout-Vorlagen, die ein einheitliches Aussehen der Be-
nutz...
Analyse der vorhandenen Lösung
39
Das Metamodell besitzt nach der ersten Iteration die folgende Struktur:
Abbildung 13 - M...
Analyse der vorhandenen Lösung
40
Die erste Iteration des Frameworks konnte die gestellten Aufgaben P1-P4 lösen. Al-
lerdi...
Analyse der vorhandenen Lösung
41
Folgende Aufgaben bestanden für diese Iteration:
A1 Ergänzen der Benutzerdokumentation u...
Analyse der vorhandenen Lösung
42
Abbildung 14 - Neue REST-Elemente der zweiten Iteration99
(März 2010)
Die Modellelemente...
Analyse der vorhandenen Lösung
43
In der Iteration 2 wird dieses Modellelement nur bei Antwortnachrichten
verwendet, da ke...
Analyse der vorhandenen Lösung
44
Eine Besonderheit der Developer Garden REST-Schnittstelle ist die Möglichkeit, die
Rückg...
Analyse der vorhandenen Lösung
45
Rolle des multiple-Attributs
Die semantische Bedeutung des multiple-Attributs ist die Ke...
Analyse der vorhandenen Lösung
46
Abbildung komplexer Felder
In der Iteration 2 wurden komplexe Felder durch die subfields...
Analyse der vorhandenen Lösung
47
Zum anderen benötigt das Java-SDK für die Ausführung 7 Mbyte an Java *.jar-
Dateien, obw...
Analyse der vorhandenen Lösung
48
P8: Keine Abbildung der Developer Garden Status-Codes
Es existieren in den SDKs weder ei...
Analyse der vorhandenen Lösung
49
P10: Keine Mehrsprachigkeit
Obwohl die Benutzerdokumentation zweisprachig vorliegt, exis...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Entwicklung eines Konzepts und einer flexiblen Architektur für ein Framework zur automatisierten, plattformübergreifenden ...
Nächste SlideShare
Wird geladen in …5
×

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.055 Aufrufe

Veröffentlicht am

Eine Betrachtung der aktuellen Trends in der Informationstechnologie zeigt eine klare Hinwendung vieler Technologien zum Cloud Computing, der Bereitstellung von Infrastruktur, Diensten und Software im Internet. Dieser Wandel bringt neue Problemfelder 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 Architekturen an. SOAP bietet Lösungen für Problemstellungen im Unternehmensumfeld, wie beispielsweise verteiltes Transaktionsmanagement oder die Zusicherung von Integrität und Vertraulichkeit 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.

Für die Konzipierung der Kommunikation mit Cloud-Diensten wird häufig der REST-Architekturstil angewendet. Die Ansprache von REST-Schnittstellen ist aufgrund zahlreicher Aspekte 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-Generierung, gleichwohl hat in Praxi keiner davon eine weite Verbreitung gefunden.

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 darauf aufbauend eine flexible Architektur für ein plattformübergreifendes Generierungsframework, GenerationREST, konzipiert. Dieses Konzept generalisiert und erweitert 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 erlangten Erkenntnisse mit ein.

Veröffentlicht in: Bildung
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
1.055
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
2
Aktionen
Geteilt
0
Downloads
2
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

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

×