Lieferung 3.1 Beschreibung der Referenzarchitektur für das BMBF-Projekt

Transkript

1 Lieferung 3.1 Beschreibung der Referenzarchitektur für das BMBF-Projekt Modellgetriebene agile Entwicklung für mobile Anwendungen (ModAgile Mobile) Arbeitspaket AP 3 Referenzarchitektur und Benutzungsfälle Arbeitspaketleitung arconsis IT-Solutions GmbH Förderkennzeichen 01IS11012A-C Projektleitung andrena objects AG Jochen Winzen Partner andrena objects ag arconsis IT-Solutions GmbH FZI Forschungszentrum Informatik Autoren Johannes Tysiak, Achim Baier, Dominic Frei Lieferdatum M3 (Eruierung, Grobskizze) M6 (Beschreibung) Letztes Änderungsdatum Version 0.5 ModAgile Mobile L3.1 Beschreibung der Referenzarchitektur 1

2 Inhalt Lieferung 3.1 Beschreibung der Referenzarchitektur... 1 Modellgetriebene agile Entwicklung für mobile Anwendungen (ModAgile Mobile) Einleitung Erste Iteration: FleetJournal Vorläufige Beschreibung der Referenzarchitektur High-Level Sicht REST-Schnittstelle Android Client iphone Client GWT Client Architekturalternativen Zweite Iteration: MAMEX Vorläufige Beschreibung der Referenzarchitektur High-Level Sicht REST-Schnittstelle Android Client iphone / ipad Client Architektur-/Designkonstrukte in MAMEX... 7 ModAgile Mobile L3.1 Beschreibung der Referenzarchitektur 2

3 1 Einleitung Die Festlegung der Referenzarchitektur erfolgte in zwei Iterationen. In der ersten Iteration wurde eine Referenzarchitektur auf Basis der Applikation FleetJournal der arconsis aufgebaut. Diese Anwendung hat eine klassische Client-Server-Architektur unter Verwendung eines JEE-Servers. Dieses Szenario findet im Enterprise-Umfeld häufige Anwendung und ist somit ein für das Projekt relevanter Architekturansatz. Bemerkung: Die Applikation FleetJournal befindet sich aktuell in der Entwicklung bei der arconsis. Die Erwartungshaltung der arconsis ist es, innerhalb des Lebenszyklus von FleetJournal auch Ergebnisse aus Modagile Mobile anzuwenden Es zeigte sich im Rahmen dieser Arbeiten jedoch, dass die Fachlichkeit der Anwendung FleetJournal für den Zweck der Definition einer Referenzarchitektur in der frühen Phase des Forschungsvorhabens - zu komplex ist. Daher wurde in einer zweiten Iteration das Beispiel MAMEX (ModAgile Mobile Example) entwickelt, bei dem die Fachlichkeit bewusst möglichst einfach gehalten, jedoch dennoch typische/spezifische Architekturkomponenten von Software für mobile Endgeräte aufgenommen wurden. Zudem verwendet dieses Minimalbeispiel serverseitig einen alternativen Satz von Technologien, für den bei der gegebenen Größe, Funktionalität und Komplexität Erweiterungen/Änderungen weniger Aufwand anfällt. In der Praxis sind beide Ansätze relevant. Im weiteren Projektverlauf des Forschungsvorhabens sollen beide Ansätze weiterverfolgt werden. MAMEX soll Fallkonstellationen möglichst einfach abbilden und den Fokus auf grundsätzliche Machbarkeit und Technologien legen. FleetJournal soll gegen Ende des Forschungsvorhabens dann den Fokus stärker auf die Anwendbarkeit (in für uns typischen Projekten) und Fachlichkeit legen. Die beiden unterschiedlichen Ansätze finden sich im Aufbau dieses Dokuments wieder. So wird in Kapitel 2 zunächst die Referenzarchitektur von FleetJournal (M3) und in Kapitel 3 der aktuelle Stand (M6) der Referenzarchitektur für MAMEX präsentiert. 2 Erste Iteration: FleetJournal Zum Projektmonat M3 ist die Referenzarchitektur noch nicht final festgelegt. Bei der Modellgetriebenen Softwareentwicklung geht die Erstellung der Referenzarchitektur Hand-in-Hand mit der Erstellung einer Referenzimplementierung. Bis zur im Forschungsvorhaben benötigten Reife der Referenzarchitektur sind hier noch mehrere Iterationen und Abstimmungen notwendig. Bemerkung: Wie oben beschrieben wird FleetJournal erst wieder gegen Ende des Forschungsvorhabens aufgegriffen (Anwendbarkeit / Demonstrator). Siehe hierzu auch Abschnitt 2.2. Die Referenzimplementierung baut auf der Anwendung Fleet-Journal der arconsis auf. Diese wurde am Projekt-Kickoff vorgestellt. Die Anwendung wurde zunächst (außerhalb des Forschungsvorhabens) traditionell implementiert und wird/wurde teilweise refaktorisiert und ein Durchstich so implementiert, dass eine möglichst hohe Überschneidung mit den Zielen des Forschungsvorhabens gewährleistet ist. Sind diese Arbeiten abgeschlossen, kann daraus die Beschreibung der Referenzarchitektur abgeleitet werden (plus Bezugspunkt für Generatoren, Testartefakte ). Die Anwendung wird außerdem Basis für den im Antrag/Projektplan erwähnten großen Demonstrator. Die Referenzarchitektur wird über die Referenzimplementierung den Projektpartnern zur Verfügung gestellt. Dabei sind neben der reinen Implementierung auch erste Referenzen für Build-Funktionalität und Qualitätssicherung enthalten. ModAgile Mobile L3.1 Beschreibung der Referenzarchitektur 3

4 2.1 Vorläufige Beschreibung der Referenzarchitektur High-Level Sicht Die Anwendung ist eine Client-Server-Anwendung. Der Server stellt Daten und Services über eine REST-Schnittstelle zur Verfügung. Verschiedene Clients verwenden diese Schnittstellen. Android-App und iphone-app als Mobile Clients Rich Internet Application (z.b. für Backoffice-Funktionalitäten) mittels GWT Vom Funktionsumfang können die Clients unterschiedliche Services realisieren (Backoffice z.b. ohne ortsabhängige Funktionalität; Ergebnisfilterung auf Mobile Clients ) REST-Schnittstelle Die REST-Schnittstelle unterstützt primär Security-Funktionalität (PermissionMgr) und Datenhaltung (PersistenceMgr). Als Protokoll zur Kommunikation mit den Clients wird wegen der Verfügbarkeit auf leicht- und schwergewichtigen Plattformen HTTP/JSON verwendet. Die Implementierung orientiert sich dabei an Best Practices und Entwurfsmuster aus dem Bereich Enterprise Applications mit JEE als Technologieplattform Android Client Der Android Client verwendet soweit möglich Framework-Funktionalitäten des Android SDK und orientiert sich dabei ebenfalls an Best Practices. ModAgile Mobile L3.1 Beschreibung der Referenzarchitektur 4

5 2.1.4 iphone Client Referenzimplementierung noch nicht final realisiert GWT Client Der GWT Client ist nicht direkt Gegenstand des Forschungsvorhabens. Jedoch benötigt eine typische mobile Anwendung mit Serveranteil meist einen Verwaltungs-Client mit Funktionalitäten, die typischerweise nicht auf den mobilen Clients bereitgestellt wird. Dies gilt es bei der Gesamtentwicklung zu berücksichtigen (Redundanzen, Synergien, Wartbarkeit ). 2.2 Architekturalternativen Die ausgewählte Architektur ist stark aus den Anforderungen an große und langlebige Unternehmensanwendungen motiviert. Eine weitere im Mobile-Umfeld relevante Klasse von Anwendungen benötigen diese nicht zwingend. Diese Anwendungen zeichnen sich meist durch einen geringeren serverseitigen Anteil der Geschäftslogik aus. Die im Forschungsprojekt erarbeitete Methodik soll zumindest prinzipiell unterschiedliche Architekturen unterstützen. Ob im Forschungsvorhaben auch Generatoren für mehrere unterschiedliche Architekturstile implementiert werden ist offen und abhängig vom damit verbunden Aufwand. Bemerkung: Im Projekt wurde die Entscheidung getroffen erst einmal kleinere Beispiele (MAMEX; siehe Abschnitt 1 und 3) bereitzustellen. FleetJournal erwies sich als zu komplex und Arbeitssitzungen im Forschungsvorhaben hatten dadurch einen zu hohen Anteil an Fachlichkeit der Beispielanwendung. ModAgile Mobile L3.1 Beschreibung der Referenzarchitektur 5

6 3 Zweite Iteration: MAMEX Im Rahmen der zweiten Iteration der Definition der Referenzarchitektur für ModAgile Mobile wurde ein Minimalbeispiel vollständig neu entwickelt. Dieses Minimalbeispiel mit dem Namen MAMEX (ModAgile Mobile Example) hat eine im Vergleich zu FleetJournal stark reduzierte Fachlichkeit. Es konzentriert sich auf die technologischen Fragestellungen und bietet die Möglichkeit, alle im Rahmen des Projekts relevanten Architekturkomponenten aufzunehmen. Zudem wurde in der zweiten Iteration dem in Kapitel 2.2 erwähnten Wunsch nach Architekturalternativen nachgekommen. Hierbei handelt es sich um ein Beispiel mit absichtlich möglichst einfach gehaltener serverseitiger Logik unter Verwendung einer alternativen serverseitigen Technologieplattform. 3.1 Vorläufige Beschreibung der Referenzarchitektur High-Level Sicht Wie bei der Applikation FleetJournal handelt es sich auch bei MAMEX um eine Client-Server- Anwendung. Auch hier werden Daten und Services über eine REST-Schnittstelle zur Verfügung gestellt, so dass beliebige Clients diese Schnittstelle verwenden können REST-Schnittstelle Die REST-Schnittstelle enthält primär Funktionalität zur Datenhaltung der Anwendung. Technologisch basiert der REST-Server nicht auf den aus FleetJournal bekannten JEE-Technologien. Als Datenbank wird mit CouchDB eine dokumentenorientierte Datenbank, in der die Inhalte als JSON-Objekte verfügbar sind. Als Middleware wird mit Node.JS ein Javascript-basiertes ereignisgesteuertes Framework zur Erstellung von Serveranwendungen eingesetzt. Durch die durchgehende Nutzung von JavaScript/JSON sowohl in der Datenbank als auch in der Middleware kann die serverseitige Logik möglichst einfach umgesetzt werden. ModAgile Mobile L3.1 Beschreibung der Referenzarchitektur 6

7 3.1.3 Android Client Der Androd Client baut auf Framework-Funktionalitäten des Android SDK auf und setzt auf bekannte Best Practices und Design Pattern iphone / ipad Client Die Entwicklung eines iphone und ipad Clients für die ModAgile Beispielanwendung hat bereits angefangen. Ziel ist die Entwicklung zweier Clients, die sämtliche Features des Android Clients beinhalten, wobei die Umsetzung auf der Basis von Best Practices und Frameworks aus der ios- Entwicklung erfolgen wird. Durch die Bereitstellung einer Smallscreen - (iphone) und BigScreen (ipad) Variante soll auch die notwendige Variabilität im Screen-Design (nicht nur zwischen Plattformen) verdeutlich werden. Diese umfasst mehr als nur eine andere Anordnung derselben Bildschirmelemente, sondern kann z.b. auch gänzlich andere bzw. zusätzliche Screens enthalten. Dies ist in der späteren Modellierung zu beachten Architektur-/Designkonstrukte in MAMEX In MAMEX werden folgende typische Konstrukte unterstützt: ModAgile Mobile L3.1 Beschreibung der Referenzarchitektur 7

8 Persistente Datenhaltung auf dem mobilen Device Datensynchronisation zwischen dem mobilen Device und einem Server (inklusive Offline- Fähigkeit und Auflösung von möglichen Synchronisationskonflikten) 1-1 Beziehungen (zwischen Personen und Avataren) 1-n Beziehungen (zwischen Personen und Adressen) n:m Beziehungen (zwischen Personen) Text, Daten und binäre Daten (Bilder) Location Based Services (GPS, Adressdaten) Kamerafunktionalität (Avatar) Die grobe Funktionalität von MAMEX kann der folgenden Abbildung entnommen werden. ModAgile Mobile L3.1 Beschreibung der Referenzarchitektur 8