Bausteinsicht von Angular 2

Mit der Bausteinsicht kann ein Softwaresystem mit dem Top-Down oder Bottom-Up Ansatz analysiert werden. Ausgehend vom Systemkontext kann das zu untersuchtende System in die relevanten Bausteine unterteilt werden. Die einzelnen Bausteine können wiederum unterteilt werden. So lässt sich das gesamte System beliebig granular bzw. aus den unterschiedlichsten Blickwinkeln betrachten. Dieser Artikel untersucht die Bausteinsicht von Angular 2 ausgehend vom Systemkontext. Dabei wurden die Bausteine von der ersten Ebene ab dem Systemkontext von Angular 2  untersucht.

Bausteinsicht von Angular 2

Als Bausteine wurden die einzelnen Packete im github-Repository von Angular 2 identifiziert. Die folgende Grafik zeigt die entsprechenden Bausteine.

Identifizierte Bausteine von Angular 2 anhand des github-Repositories.
Identifizierte Bausteine (rot) von Angular 2 anhand des github-Repositories.

Die Abhängigkeiten unter den Bausteinen wurden untersucht und entsprechend visualisiert. Die folgende Grafik zeigt die Zusammenhänge der einzelnen Bausteine.

Die Bausteine von Angular 2 sowie die Zusammenhänge untereinander.
Die Bausteine von Angular 2 sowie die Zusammenhänge untereinander.

Die folgenden Unterkapiteln beschreiben die einzelnen Bausteine von Angular 2. Falls der Name des entsprechenden Bausteins keinen klaren Hinweis auf die Funktionalität bzw. dessen Aufgabe gibt (wie z.B. Facade, Core oder Common), wurden die wichtigsten Funktionen analysiert und dokumentiert.

Facade

Der Baustein bietet für verschiedenste Javascript-Konzepte und externe Abhängigkeiten entsprechende Facaden an. Sämtliche Bausteine von Angular 2 sind vom Facade-Baustein abhängig. Ein Auszug aus Abstraktionen, die der Facaden-Baustein von Angular 2 bietet:

  • Wrapper-Objekte und Hilfsfunktionen für Javascript-Objekte und Sprachkonstrukte wie Math, Date, Timer, NaN und Typenprüfkonstrukte wie zB. isInteger, etc.
  • Event-Emitter, über welchen Broadcast Events von Angular Komponenten und Direktiven gefeuert und abonniert werden können.
  • Abstraktion für Window-Properties wie z.B. window.document, window.location, etc.
  • Collection-Objekte und Funktionalitäten wie z.B. das Anbieten von spezifischen Maps und Sets (wie z.B. den List-, Map- oder String-Wrapper).
  • Modellierung von Exceptions und dessen Behandlung sowie entsprechende Protokollierung.
  • Internationalisierungsaspekte, wie z.B. die Formatierung von Nummer und Datum.

Core

Der Core-Baustein enthält alle zentralen Funktionalitäten von Angular 2. Core ist abhängig vom Angular Facaden Baustein. Anbei die wichtigsten Funktionalitäten:

  • Change Detection Mechanismus
  • Erweiterte Debug-Funktionalitäten
  • Dependency Injection Mechanismus
  • Bereitstellen der sogn. Lifecycle Hooks, welche den Lebenszyklus einer Angular Komponente abbilden.
  • Pipes (früher in AngularJS waren dies Filter)
  • Anbindung ans Web Tracing Framework (WTF) von Google
  • Reflection-Funktionalitäten
  • Unterstützung für E2E-Tests um Test-Hooks auszulösen.
  • Decorator-Interface, um Klassen und Funktionen in einer Angular 2 Anwendung zu dekorieren.
  • Schnittstelle zu zone.js

Common

Der Common-Baustein verwendet, wie alle anderen weiteren Bausteine, den Facaden- und Core-Baustein. Common bietet folgende Funktionalitäten an:

Testing

Der Testing-Baustein enthält diverse unterstützende Mechnismen für das automatische Testing von Angular 2 Anwendungen sowie für das Testing des Frameworks selbst, wie z.B.:

  • Wie unterstützende Testing-Funktionaliäten für den Selenium-Webdriver
  • Fake-Implementationen, wie z.B. für eine Async-Zone oder den Injector
  • Angular spezifische Matchers für Jasmine-Tests
  • Unit-Testing Library, welche Jasmine und die angebotenen Test-Implementationen verwendet.

Router

Der Router ist bei Angular 2 noch nicht fertiggestellt. Er bietet dem Benutzer die ganzen Routing-Mechnismen, um URL-Konzepte auf entsprechende Angular-Komponenten abzubilden.

Web Workers

Angular 2 bietet den nativen Support um Anwendungsteile in Web Workers laufen zu lassen. Dieser Baustein ermöglicht die Verwendung von Web Workers in Angular 2 Anwendungen. Dieses Dokument beschreibt wie man Web Worker kompatible Angular 2 Komponenten baut.

HTTP

Dieser Baustein ermöglicht die Kommuinikation von Angular Komponenten zu Backend-Systemen. Wichtig ist hier, dass mit Observables von RxJS gearbeitet wird und nicht direkt mit Promises. Zusätzlich bietet der Baustein auch fürs Testing diverse Mocks für Backends an.

Platform

Der Platform-Baustein bietet unterschiedliche Funktionalitäten, Workarounds und Abstraktionen im Umgang mit dem Browser (= Platform).

Animate

Der Animation-Teil ist bei Angular 2 noch in Bearbeitung. Das Ziel dieses Bausteins ist es, Animationen für Desktop- und Mobile Anwendungen in einer einfachen Art- und Weise abzubilden und in der Anwendung entsprechend zu verwenden.

Compiler

Der Compiler-Baustein kümmert sich um die Konvertierung der spezifizierten Templates in Angular-Komponenten.

Upgrade

Mit dem Upgrade-Baustein will Angular 2 die Möglichkeit bieten, AngularJS und Angular 2 nebeneinander laufen zu lassen und so einen weichen Übergang von AngularJS nach Angular 2 zu ermöglichen. Die Verwendung dieses Upgrade-Adapters hier hier beschrieben.

Feedback

Falls Du Fragen, Unklarheiten oder Ergänzungen zu diesem Blog-Post hast, nutze dazu einfach die Feedback-Funktion. Vielen Dank!

Nächster Artikel

Der nächste Blog-Post wird die grundlegenden Architekturentscheide von Angular 2 beschreiben.

Qualitätsziele von Angular 2

Qualitätsziele bestimmen die Software-Architektur einer Software-Komponente. Daher dient die Erarbeitung der Qualitätsziele bzw. die nichtfunktionalen Anforderungen (i.d.R. drei bis fünf Qualitätsziele, geordnet nach einer vorgegebenen Priorität) als Voraussetzung für den Start der Realisierung einer Komponente. Die Blog-Post beschreibt die hergeleiteten Qualitätsziele von Angular 2. Einen guten Einstieg zum Thema Qualitätsziele gibt der Blog-Eintrag der Apptiva AG zum Thema Qualität.

Die Eruierung der Qualitätsziele von Angular 2 ist schwierig. Sämtliche Design-Dokumente von Angular 2 findet man im entsprechenden Ordner vom Google Drive des Teams (hier). Klare Qualitätsziele findet man in keinem der Dokumente bzw. auch nicht auf der Webseite von Angular 2. Jedoch können aus den einzelnen Aussagen bzw. Informationen entsprechende Qualitätsziele für Angular 2 abgeleitet werden.

Qualitätsziele von Angular 2

Folgende Qualitätsziele haben wir versucht herzuleiten und entsprechend zu priorisieren.

1. Effizienz

Effizienz umfasst das Zeitverhalten sowie das Verbrauchsverhalten einer Software. Das Zeitverhalten definiert Antwort- und Verarbeitungszeiten sowie Durchsatz bei der Funktionsausführung einer Software und das Verbrauchsverhalten umfasst die Anzahl und die Dauer der benötigten Betriebsmittel für die Erfüllung der Funktionen.
Auf Angular 2 basierende Anwendungen bzw. dessen Inhalte sollen für den Benutzer schnell geladen werden können. D.h. das Framework selbst darf nicht der Verursacher von Performance-Problemen sein.

Performance-Probleme bei AngularJS

Bei AngularJS kam es bei grösseren (Enterprise-) Anwendungen immer wieder zu solchen Herausforderungen, wo man sehr genau prüfen musste, welche Konstrukte man wie und in welchem Kontext einsetzte (siehe Lösungen z.B. hier). Symptome für die Performance-Probleme von AngularJS entdeckt man auch bei einem Konstrukt vom Mobile-Framework Ionic. Sie implementierten ein performanteres ng-repeat, das sogn. collection-repeat. Dies aus der Not heraus, dass auch Listen mit vielen Einträgen auf einem Mobile-Gerät performant angezeigt werden sollen. Das collection-repeat rendert nur die aktuell auf dem Gerät sichtbaren Items in den DOM. Das Konstrukt überwacht dann die Stelle in der Liste, auf welcher Benutzer steht. Ändert diese, werden die neuen Elemente der Liste in den DOM gerendert.

Angular 2 mit effizienz-steigernden Massnahmen

Angular 2 adressiert diese Thematik mit unterschiedlichen Konzeptanpassungen.
So ändert Angular 2 z.B. den gesamten Change-Detection- bzw. Databinding- Mechanismus. Angular 2 fungiert beim Change-Detection Mechanismus als reaktives System, in dem der Komponenten-Baum bei jedem Browser-Event traversiert wird und somit keine periodischen „Überprüfungszykeln“ mehr gibt. Ein anderer Schritt Richtung Performance kommt mit dem sogn. ‚Angular Universal‚, dem sogn. Angular 2 Server Rendering (die Design-Dokumentation findet man hier). Angular-Universal will dabei folgende Ziele erreichen:

Durch das neuartige Konzept verspricht man sich verbesserte initiale Ladezeit sowie eine verbesserte clientseitige Performance (z.B. Rendern einer Seite, welche einen nicht oft ändernden Inhalt enthält oder Seiten mit Visualisierungen).

2. Übertragbarkeit

Für das Qualitätsziel Übertragbarkeit wird vorallem die Konformität untersucht.

Konformität dank Orientierung an Web Standards

Definiert den Grad, in dem die Software Normen oder Vereinbarungen zur Übertragbarkeit erfüllt.
Angular 2 versucht an Web Standards zu orientieren bzw. sich entsprechend diesen Konzepten auszurichten. So z.B. wird die Spezifikation der Web Components unterstützt. Die Spezifikation der Web Componens besteht aus den Teilen Custom Elements (Implementieren von eigenen HTML-Elementen), Shadow DOM (Auslagern des DOMs eines Custom Elements), Templates (Unterstützung eines <template> Elemente ohne dies zu rendern) und HTML Imports (Laden von HTML-Dokumenten in ein entsprechendes Ziel-Dokument). Diese standardisierten Konzepte findet man in Angular 2 wieder.

Konformität durch nachhaltige Unterstützung von Javascript

Nebst der Unterstützung von Web Standards orientiert sich das Framework durch den Einsatz von Typescript auch an den modernen Javascript Spezifikationen (ES6 / ES7 / …) aus. So richtet sich das Framework einerseits nachhaltig gegenüber Javascript aus und andererseits ist das Framework konform gegenüber Brower- und Umgebungsspezifikationen. Aus Sicht Framework-Anwender ist dank dem Einsatz von Typescript auch möglich, Software-Komponenten auf Basis von Angular 2 mit ES5, ES6, Dart und / oder Typescript zu verwenden.
Ein weiteres Ziel von Angular 2 ist es, konform zu unterschiedlichen Sprachen zu sein – d.h. es ist möglich Angular 2 in einem ES5, ES6, Dart und / oder Typescript-Kontext zu verwenden.

3. Benutzbarkeit

Die Benutzbarkeit besteht aus den Merkmalen Verständlichkeit und Erlernbarkeit.

Verbesserte Verständlichkeit dank Typescript

Verständlichkeit definiert sich über den Aufwand der den Benutzer (in unserem Kontext der Entwickler) zum Lernen des Konzeptes bzw. Schaffung über dessen Verständnis. Angular 2 setzt sehr stark auf ein einfaches Verständnis bzw. ein minimaler Aufwand die entsprechenden Kernkonzepte kennenzulernen. Die Ausrichtung nach Typescript fördert das Verständnis bzw. minimiert den Aufwand um den Umgang mit Angular 2 kennenzulernen.

Bessere Verständlichkeit durch überarbeitete Konzepte

Das total überarbeitete Modul- und Komponentenkonstrukt mit dem neuen Dependency Injection Mechanismus ermöglicht es die Anwendung, nach dem Single Responsibility Principle zu strukturieren und so ein einfaches Verständnis in der Software-Architektur der Anwendung zu erreichen. Jedoch sind Module im Angular-Kontext nicht zwingend. Dies gilt auch für andere Konzepte. Mit Angular 2 entsteht eine losere Kopplung an das Framework selbst – man kann sich die Konzepte verwenden die man auch wirklich benötigt. Die Anzahl Angular 2 spezifischen Elemente sind merklich weniger geworden als in AngularJS, was wiederum die Verständlichkeit aber auch die Erlernbarkeit effizienter gestaltet. 

Schnellere Erlernbarkeit dank zielgerichteter Dokumentation

Erlernbarkeit definiert den Aufwand, welcher der Benutzer hat um die Anwendung (bzw. in unserem Kontext das Framework) anwenden zu können. Hier setzt Angular 2 auch sehr stark auf eine einfach verständliche Dokumentation, um das Framework effizient kennenzulernen. Beispielsweise einen guten Einblick in das Metamodell von Angular 2 gibt der Architekturüberblick

Links

Angular 2 Architecture Overview:
https://angular.io/docs/ts/latest/guide/architecture.html

Angular 2 Design Docs:
https://drive.google.com/drive/u/1/folders/0B7Ovm8bUYiUDR29iSkEyMk5pVUk

Ionic Angular 2 Blog-Post Serie:
http://blog.ionic.io/angular-2-series-introduction/

Blog-Post Change-Detection in Angular 2:
http://victorsavkin.com/post/110170125256/change-detection-in-angular-2

Angular Universal Design Doc: https://docs.google.com/document/d/1q6g9UlmEZDXgrkY88AJZ6MUrUxcnwhBGS0EXbVlYicY/edit

Telerik Angular 2 Überblick:
http://developer.telerik.com/featured/will-angular-2-be-a-success-you-bet/

Angular 2 Presentation:
http://tryangular2.github.io/

Web-Components:
http://www.2ality.com/2015/08/web-component-status.html

Blog-Post „What happended to Web Components?“  von Dr. Alex Rauschmayer
http://www.2ality.com/2015/08/web-component-status.html

ISO/IEC 9126 (Qualitätsmerkmale) auf Wikipedia
https://de.wikipedia.org/wiki/ISO/IEC_9126

Blog-Post „Qualitätsziele“
http://apptiva.ch/qualitaetsziele/

Feedback

Falls Du Fragen, Unklarheiten oder Ergänzungen zu diesem Blog-Post hast, nutze dazu einfach die Feedback-Funktion. Vielen Dank!

Nächster Artikel

Der nächste Blog-Post wird die Bausteinsicht von Angular 2 beschreiben.

Systemkontext von Angular 2

Dieser Blog-Artikel beschreibt den Systemkontext von Angular 2. Mit dem Systemkontext lässt sich genau abgrenzen, wo sich das zu beschreibende System gegenüber Umsystemen und Aktoren abgrenzt. Zusätzlich werden die identifizierten Umsysteme grob beschrieben.

Systemkontext von Angular 2

Das folgende Diagramm beschreibt der Kontext von Angular 2 aus Sicht des Entwickler, d.h. des Anwendungsentwicklers. Der Anwendungsentwickler realisiert auf Basis von Angular Webanwendungen.

Systemkontext von Angular 2
Systemkontext von Angular 2

Im Folgenden werden die einzelnen Aktoren und Umsysteme kurz beschrieben:

  • Entwickler: Der Entwickler setzt das Framework Angular 2 ein, um Komponenten für seine Webanwendung zu schreiben.
  • Transpiler: Angular 2 lässt es dem Entwickler offen, mit welcher Sprache (ES5, ES6, Typescript, Dart, ..) er Angular 2 verwendet. U.A. ist auch Angular 2 selbst in Typescript geschrieben. Mittels Transpiler wird dann der Quellcode in der entsprechenden Sprache nach ES6 umgewandelt.
  • Entwicklungswerkzeuge: Auf der Basis von NodeJS werden für die Entwicklung eine Reihe nützlicher unterstützende Entwicklungswerkzeuge, wie z.B. der Live-Server angeboten. NodeJS selbst dient als Laufzeitumgebung für die ganzen unterstützenden Tools. Die Tools werden typischerweise über den eigenen Node Package Manager bezogen.
  • Webanwendung: Hiermit ist die Webanwendung, welche der Entwickler auf Basis von Angular 2 erstellt, gemeint. Die Webanwendungen selbst kann wiederum aus 1..n Komponenten bestehen. Die Komponenten werden von Angular 2 angezogen und entsprechend dem Browser zur Verfügung gestellt.
  • Browser: Der Browser rendert die komplette Webanwendung auf Basis von Angular 2. Wichtig ist hierbei, dass der Quellcode in ES6 ist. Falls der Browser die entsprechenden ES6 Konstrukte nicht versteht, kann mittels sogn. ES6-Shim die Kompatibilität auch zu älteren Javascript Engines gewährleistet werden.
  • Module Loader: Angular 2 benutzt für das Laden von Modulen bzw. Komponenten SystemJS. Mittels SystemJS lassen sich ES6 Module oder Module gemäss AMD– und CommonJS Spezifikation laden. So ist es möglich die Webanwendung feingranular zu schneiden und entsprechende Komponenten einfach zur Laufzeit nachzuladen.
  • Package Management: Die Abhängigkeiten rund um das Ökosystem Angular 2 können mit dem Package Manager JSPM (Javascript Package Manager) oder mit NPM (Node Package Manager) bezogen werden. JSPM – wieder ein weiterer Package-Manager? 🙂 Jein – der Vorteil von JSPM ist, dass der Package Manager Abhängigkeiten über mehrere verschiedene bzw. unterschiedliche Quellen beziehen kann (bower, npm, github, etc.) und so nur die Metadaten der Abhängigkeiten in seiner Registry hält. Zusätzlich interagiert JSPM perfekt mit dem Module Loader SystemJS.
  • IDE / Editor:  Bereits jetzt bieten einige IDE’s oder Editoren kontextspezifische Unterstützung (im Microsoft Jargon ‚Intellisense‘) im Umgang mit Angular 2. Beispiele sind hier IntelliJ bzw. Webstorm von Jetbrains.
  • Polyfills & Shims: Angular 2 benötigt verschiedene Polyfills und Shims. Polyfills sind Bibliotheken welche Funktionalitäten anbieten, die aktuell (noch) nicht im entsprechenden Browser verfügbar sind.
    Angular 2 benötigt zwei Pollyfill-Bibliothken wie das „hauseigene“ zone.js, welches dem Framework ermöglicht sogn. Execution-Kontext-Objekte über asynchrone Methodenaufrufe hinweg zu transportieren. Eine zusätzliche Polyfill-Bibliothek ist reflect-metadata um Methoden-Annotationen mit Metadaten versehen zu können (analog C# / Java).
    Shims überbrücken API-Kompatibilitätsbrüche indem sie als Facaden für API-Aufrufe dienen. Diese benötigen im Angular 2-Kontext die Benutzer, welche Browser einsetzen wollen, die ES6 noch nicht komplett unterstützen. Diese Angular 2 basierenden Anwendungen müssen den entsprechenden ES6-Shim einbinden.
  • Reaktive Programmierung: Angular 2 unterstützt mit ReactiveX bzw. dessen Javascript Implementation RxJS die asynchrone und event-basierte Programmierung in dem sogn. Observable-Collections und -Arrays angeboten werden (z.B. im Angular 2 HTTP-Kontext). Daher ist RxJS eine zwingende externe Abhängigkeit.

Feedback

Falls Du Fragen, Unklarheiten oder Ergänzungen zu diesem Blog-Post hast, nutze dazu einfach die Feedback-Funktion. Vielen Dank!

Nächster Artikel

Der nächste Blog-Post beschreibt die Qualitätsziele (oder auch ‚Architekturziele‘) von Angular 2.

Virtueller Produktkarton von Angular 2

Wer kennt ihn von früher nicht – den klassischen Produktkarton einer Software. Mit dem Kauf eines sogn. ‚Softwarekarton‘ erhielt man früher die ganze Anwendung, d.h. Datenträger (Diskette, CD, DVD, etc.) und eine passende Benutzeranleitung.

Beispielhafte Softwarekartons, wie z.B. Windows XP oder die Office Suite
Beispielhafte Softwarekartons, wie z.B. Windows XP oder die Office Suite – Bild gefunden via Flickr von Hobvias Sudoneighm

Auf der Rückseite des Kartons fand man einen Überblick, was die Anwendung konnte bzw. welche Funktionalitäten (Überblick) man mit dem Produkt kaufte. Natürlich enthielt der Karton u.A. viele Marketingsprüche, damit man das Produkt im Laden dann auch tatsächlich kauft.

Dieser Blog-Artikel stellt ein virtueller Produktkarton von Angular 2, der nächsten Version von AngularJS, dar. Der Artikel besteht aus einem Mission-Statement, dessen Präzisierung sowie die Auflistung der wesentlichen Features von Angular. Der virtuelle Produktkarton von Angular 2 gibt einen leichten Einstieg ins Thema.

Mission Statement

Angular ist eine Entwicklungsplattform, um Mobile- und Desktop Anwendungen zu bauen ¹.

  • Mit Angular lassen sich unter der Berücksichtigung von modernen Web-Standards, wie z.B. die Ausrichtung nach ECMAScript 6 (ES6) oder die Unterstützung von Web Components, zukunftsgerichtete und nachhaltige Anwendungen bauen.
  • Durch den verfolgten Mobile-First Ansatz von Angular erhalten Benutzer auch mit geringerer Bandbreite das beste Nutzererlebnis.
  • Angular ist dank dem modularen Aufbau sehr einfach und schnell zu lernen – ganz nach dem Motto „Start quick, build fast„.

Wesentliche Features

  • Durch den modularen Aufbau von Angular sowie einem mobile ausgerichtetem Routing ist es möglich, den Code strukturiert und so performant zu halten, dass auch Mobile-Benutzer der Anwendung nicht warten müssen.
  • Um für die zukünftige Ausrichtung (ES6, ES7, …) von Javascript gerüstet zu sein, ist Angular komplett in Typescript geschrieben.
  • Der Entwickler ist völlig frei, mit welcher Sprache er Angular verwendet (d.h. ES5, Typescript, Dart, CoffeeScript oder eine andere Sprache die nach Javascript kompiliert wird).
  • Die Änderungserkennung ist gegenüber der Vorgängerversion 5x schneller. Der Einsatz von Angular 2 wird die Anwendung erheblich beschleunigen.
  • Mit dem Einsatz von Angular wird der Code einfach und ausdruckstark, mit dem man zukünftige Komplexität während der Entwicklung erschlagen kann.
  • Mit Angular können komplexe Ansichten abgebildet werden. Das übergreifende Routing-Konzept ermöglicht verschachtelte und verknüpfte Views. Angular unterstützt mit dem neuartigen Routing Card-Stack Navigation, animierte Übergänge sowie Lazy-Loading von abhängigen Sichten.
  • Animationen für eine Mobile-Anwendung als auch Animationen für Desktop-Anwendungen können mittels einfacher Angular Event API oder direkt via CSS, Javascript oder der Web Animation API umgesetzt werden.
  • Angular kommt mit einem leistungsstarken hierarchischen Dependency Injection (DI) Mechanismus, der feingranular geschnittene Anwendungen unterstützt, ohne dass der Entwickler mühsamen Glue-Code schreiben muss.
  • Angular unterstützt Web Components, welche u.A. auch mit Bibliotheken wie Polymer oder X-Tag gebaut wurden. Zusätzlich verwendet Angular Komponenten Web Standards wie z.B. das Konzept des Shadow DOM .
  • Mit dem Einsatz von Angular kann die Internationalisierung (i18n) sowie die Barrierefreiheit einer Anwendung (z.B. Unterstützung ARIA-Attribute) vollumfänglich unterstützt werden.

Feedback

Falls Du Fragen, Unklarheiten oder Ergänzungen zu diesem Blog-Post hast, nutze dazu einfach die Feedback-Funktion. Vielen Dank!

Nächster Artikel

Der nächste Blog-Post modelliert den System-Kontext von Angular 2.


¹ Übersetzt von Angular.io: „Angular is a development platform for building mobile and desktop applications.“

Blog-Post-Serie: Architekturüberblick von Angular 2

Inspiriert vom arc42 Gradle Starschnitt möchten wir hier eine Blog-Post Serie starten.  Die Serie soll einen Architekturüberblick von Angular 2 geben. Die Zielgruppe sind Entwickler, die Angular 2 besser kennenlernen möchten und überlegen, die neue Version des Frameworks auch in eigenen Projekten einzusetzen.

Inhalt Architekturüberblick von Angular 2

Die folgende Grafik zeigt den Aufbau bzw. den Inhalt der angedachten Blog-Post Serie:

Architekturüberblick Angular 2
Inhalt Architekturüberblick von Angular 2

Wie die Grafik zeigt, haben wir die einzelnen Elemente aus dem Gradle-Starschnitt als Referenz genommen. In den einzelnen Kapitel gehen wir nicht auf jedes Konzept von Angular 2 ein, sondern beschreiben die Konzepte lediglich exemplarisch.

Ziele

Folgende Ziele haben wir uns für diese Blog-Post Serie gesetzt (gemäss Priorisierung geordnet):

  • Wir möchten das Dokumentieren von Software-Architekturen trainieren sowie das Template von arc42 besser kennenlernen.
  • Wir möchten den grundlegenden Aufbau sowie dessen Elemente von Angular 2 kennenlernen und verstehen.
  • Nach der Serie möchten wir fähig sein, Empfehlungen für den (u.A. auch partiellen) Einsatz von Angular 2, anhand von konkreten Qualitätsanforderungen, machen zu können.

Warum Angular 2?

Da wir in sämtlichen Projekte (inkl. Mobile-Apps) AngularJS 1.x einsetzen, haben wir so potentiell bereits technische Schulden aufgebaut. Daher interessiert uns Angular 2 sehr stark. Bei der Auswahl der Tools für die Architekturübersicht standen folgende Anwendungen zur Auswahl:

  • Node Package Manager: Package Manager für NodeJS Module sowie neu auch Frontend-Bibliotheken
    • Interessant, weil nun auch Frontend-Abhängigkeiten über NPM aufgelöst werden sollen.
  • Gulp: Build-Engine für das Bauen von Web- und Mobile Anwendungen
    • Interessant, da sehr verbreitet.
  • React: Javascript Framework für Web-Anwendungen
    • Ist direkter Konkurrent von Angular 2

Ein weiterer Faktor, welcher den Entscheid für Angular 2 begünstigte, ist die aktuell nicht oder nur sehr spärlich vorhandene (deutschsprachige) Dokumentation rund um Angular 2. Uns ist bewusst, dass wir hier für den ersten Architekturüberblick eine echte Herausforderung genommen haben – jedoch nehme wir diese Anforderung gerne an :-).

Feedback

Da wir sämtliche Informationen selbst recherchieren und entsprechend aufbereiten, kann es natürlich vorkommen, dass einzelne Blog-Artikel zu dieser Serie inhaltliche Fehler aufweisen. Falls man entsprechende Fehler oder unvollständige Informationen findet, wären wir um ein entsprechendes Feedback dankbar. Am besten dazu einfach die Kommentar-Funktion nutzen. Vielen Dank bereits im Voraus!

Nun viel Spass mit dieser Blog-Post Serie über den Aufbau von Angular 2. Wir werden im zwei/drei Wochenrythmus mit einem neuen Blog-Artikel online gehen. Wir starten mit dem sogn. Produktkarton, welcher beschreibt was Angular überhaupt ist und kann.

Interessantes aus der iSAQB Grundausbildung

Die letzten paar Tage besuchte ich die Grundausbildung (‚Foundation‘) zum iSAQB Certified Professional for Software Architecture. Der Kurs wurde von Stefan Zörner (embarc GmbH) geleitet. Der Kurs ging insgesamt drei Tage. Man beschäftigte sich während diesen drei Tagen intensiv mit Software-Architektur und den Aufgaben der Rolle ‚Software Architekt‘. In diesem Blog-Eintrag möchte ich nicht auf die iSAQB Foundation Zertifizierung eingehen – sondern bestimmte inhaltliche Elemente und auch persönliche ‚Eye-Opener‘ aus dem Kurs festhalten.

Was ist Software-Architektur?
Software-Architektur ist nicht ganz so einfach zu definieren. Am Kurs wurden verschiedene Definitionen diskutiert – am besten hat mir dabei die Definition von Eoin Woods gefallen: „Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.“ Das SEI – Software Engineering Institute hat verschiedene Definitionen zum Begriff ‚Software Architecture‘ gesammelt und bietet die Möglichkeit auch eigene Definitionen zu publizieren.

Start eines Vorhabens
Beim Start eines Vorhabens sollte vorgängig das WAS und anschliessend Teile des WIE erarbeitet werden. Folgende Punkte können das WAS beschreiben:

  • Systemkontext (*)
  • Rahmenbedingungen (*)
  • Qualitätsanforderungen und Qualitätsziele (*)
  • Szenarien
  • Risiken

Wenn die grundlegenden Informationen zum WAS erarbeitet wurden können die WIE-Grundlagen geschaffen werden:

  • Einzusetzende Technologien (*)
  • Architekturstil (-muster) (*)
  • Architekturprinzipien (*)
  • Grobe Gliederung
  • Domänenmodell (Begrifflichkeiten)

Mit einem (*) deklarierten Punkte sind besonders wichtig!

Systemkontext – nicht verhandelbar!
Aus dem Kurs ging hervor, dass das System eingehend mit einem Systemkontext beschrieben werden muss. Der Systemkontext beschreibt das System als Blackbox und zeigt die interagierenden Benutzer in unterschiedlichen Rollen sowie Beziehungen und Schnittstellen zu Umsystemen an. Wichtig ist, dass der Systemkontext anhand des Zielpublikum, das heisst fachlich und/oder technisch, modelliert werden muss.

Qualitätsziele aus Qualitätsanforderungen festlegen
Um Architekturstile, Entwurfsmuster und Strukturen für ein Software-System bzw. dessen Bausteine festlegen und diese implementieren zu können, sind  Qualitätsziele für das Entwicklungsteam essentiell. Ohne ein gemeinsames Verständnis (inkl. wichtige Stakeholder) über Qualitätsziele, läuft man (= der Projektleiter bzw. der Product Owner) in die Gefahr ein Software-System realisieren zu lassen, welches nicht den Erwartungen der Stakeholder bzw. des Auftraggebers entspricht. Daher ist es essentiell, dass man implizite Annahmen zu expliziten (Qualitäts-) Anforderungen macht.
Vor dem Kurs war mir die genaue Abgrenzung zwischen Qualitätsziel und Qualitätsmerkmal nicht klar. Während dem Kurs haben wir intensiv diskutiert – dazu meine Notizen:

  • Qualitätsmerkmale
    • „Mögliche Eigenschaften einer Anwendung“
  • Qualitätsziele
    • „Vorhaben spezifische Ziele, welche sich aus den Qualitätsmerkmalen zusammensetzen.“

Qualitätsziele kann man mittels Qualitätsanforderungen, beschrieben als Szenarien, gemeinsam mit den Stakeholder ermitteln. Dabei priorisiert man ermittelten Qualitätsziele und selektiert die höchst priorsierten 3 – 5 Ziele für das eigene Vorhaben. Die Herausforderung ist dabei, die Qualitätsmerkmale auszubalancieren, z.B. ‚Wartbarkeit‘ vs. ‚Effizienz‘ (Beispiel Modellierung eines Schachfeldes mittels mehrdimensionalen Arrays [8][8] vs. Bitfelder). Die Ermittlung der Qualitätsziele aus den Qualitätsmerkmalen ist dabei immer eine Wechselwirkung: Effizienz vs. Wartbarkeit, Sicherheit vs. Benutzbarkeit (z.B. Two-Factor Authentifizierung, Einsatz von Captchas, etc.), Portierbarkeit vs. Effizienz (Standard SQL vs. T-SQL), Zuverlässigkeit vs. Kosten. Das ganze Entwicklungsteam kennt und verfolgt während der Implementierung die Erreichung der definierten Qualitätsziele. Die definierten Qualitätsziele ermöglichen zu einem späteren Zeitpunkt dem Entwickler-Team Entscheidungen anhand der Ziele zu argumentieren (z.B. wieso eine ‚Schichten-Architektur‘) – siehe auch späteres Kapitel ‚Lösungsstrategie finden‘.

Qualitätsmerkmale konkretisieren
Qualitätsmerkmale sind meistens nicht konkret genug, um entsprechende Qualitätsanforderungen zu evaluieren, Lösungsstrategien abzuwägen und/oder Entscheidungen zu bewerten. Vielfach sind diese auch schwer messbar.
Mit Szenarien können Qualitätsmerkmale konkretisiert werden. Ein Szenario besteht aus einem kurzen Text, welcher beispielhaft die Verwendung des Systems beschreibt. Das Qualitätsmerkmal spielt dabei die Hauptrolle. Das Ziel soll sein, mittels Szenarion über die entsprechenden Qualitätsmerkmale diskutieren zu können. Zusätzlich sollte man sie dadurch auch überprüfen können. Man unterscheidet zwischen den folgenden drei Kategorien von Szenarien. Die Kategorien zielen dabei auf unterschiedliche Qualitätsmerkmale.

  • Verwendungsszenarien: Verwendung des Systems durch einen entsprechenden Akteur.
    • z.B. Qualitätsmerkmal Benutzbarkeit
  • Änderungszenarien: Es wird etwas am System verändert.
    • z.B. Skalierbarkeit oder Wartbarkeit
  • Fehlerszenarien: Es kommt zu unerwarteten Ereignissen.
    • z.B. Robustheit

Szenarien bestehen typischerweise immer aus einer Quelle, einem Auslöser, einem Artefakt / Umgebung, einer Antwort sowie ein entsprechendem Antwort-Mass. Logischerweise kann man nicht erwarten, dass die entsprechenden Attribute immer in dieser Form kommen. Jedoch ist es möglich die Szenarien immer anhand dieser Form herzuleiten. Wichtig ist, dass es kein Szenario gibt ohne Quelle und Auslöser – darauf sollte man achten.

Im Kurs wurde ein weiteres Mittel für die Konkretisierung von Qualitätsmerkmale vorgestellt.  Dabei geht es darum verschiedene Werte für die Erfüllung bzw. nicht-Erfüllung einer Qualitätsanforderung zu definieren. Das Modell stammt ursprünglich von einem Herr Gilb. Um eine Qualitätsanforderung zu konkretisieren werden Werte zu folgenden Eigenschaften definiert. Die folgende Grafik zeigt die Einordnungsmöglichkeiten von entsprechenden Qualitätswerten.

Qualitätsanforderungen konkretisieren

Es geht dabei mit den Stakeholder (Qualitäts-) Werte einordnen zu können, um ein Gefühl zu bekommen, was der erwartete Wert ‚Zielwert‘ ist. So werden die Erwartungen bereits zu Beginn des Vorhabens geglättet.

Mit Prinzipien das Team befähigen.
Das vorherige Kapitel beschreibt ‚Architekturprinzipien‘ als besonders wichtig für den Start eines Vorhabens. Prinzipien befähigen das Entwicklungsteam Entscheide zu treffen. Dabei schaffen Architekturprinzipien ein gemeinsames Verständnis wie wiederkehrende Probleme gelöst werden können (!) oder ermöglichen die Förderung eines ganz bestimmten Architekturstils. Prinzipien sind langlebiger als konkrete Lösungen.  Aus meiner Sicht können Prinzipien ein wertvolles Mittel sein, wenn es nicht DEN Software-Architekt im Team gibt. Wichtig ist, dass diese Prinzipien projektspezifisch formuliert werden.

Architektur Vision als Team-Gedanke
Wie oben beschrieben sind Prinzipien ein Mittel um das Entwicklungsteam zu befähigen Architektur-Entscheidungen herleiten zu können. Neben den Prinzipien gibt es auch noch Elemente wie Randbedingungen, Einflussfaktoren sowie ein zu verfolgendes Architekturmuster, welche Entscheidungen massgäblich beeinflussen. Die Informationen zu diesen Elementen sollte in einer Architektur-Vision (teilweise) gemeinsam mit dem Entwickler-Team erarbeitet und entsprechend dokumentiert werden. So haben auch neue Entwickler die Chance schnell vergangene Entscheidungen zu verstehen, aber auch zukünftige Konzepte danach ausrichten zu können. Persönlich finde ich die Bezeichnung ‚Architektur Vision‘ sehr passend.

Lösungsstrategie finden
Während dem Kurs wurde ein einfaches Instrument für die Erarbeitung einer Lösungsstrategie präsentiert. Die Lösungsstrategie ermöglicht die Evaluierung, Entscheidung und Kommunikation bestimmter Architekturansätze. Das Instrument ist eine einfache Tabelle mit zwei Spalten – Qualitätsziele und die dafür definierten Architekturansätze. Die folgende Tabelle zeigt den möglichen Aufbau einer solchen Tabelle.

Lösungsstrategie erarbeiten

In der linken Spalte führt man die bereits vorgängig definierten Qualitätsziele und rechts die dafür gedachten Architekturansätze. Die Architekturansätze können unterschiedlicher Art sein:

  • Architekturstile – und Muster, wie z.B. Schichten-Architektur, MVC, CQRS, REST, Microservices, etc.
  • Technologieentscheidungen, wie z.B. Programmiersprachen (z.B. Java oder .NET), Einsatz von Frameworks, etc.
  • Prinzipien, wie z.B. ‚Wenn möglich Open-Source einsetzen‘
  • Spezifisch zu verfolgende Konzepte

Durch diese Tabelle können verfolgte Lösungsstrategien argumentiert und verfolgt werden. Zusätzlich dient es einem Software-Architekt als gutes Kommunikationsmittel gegenüber unterschiedlichen Stakeholdern (und auch Kritikern ;-)) – sämtliche Entscheide können über die vorgängig definierten bzw. übergeordneten Qualitätsziele argumentiert werden.

Dokumentation unterstützt Kommunikation
Die Dokumentation ist essentiell – wichtig ist nicht, dass sie vollständig ist, sondern aktuell und angemessen. „Zu viel“ Dokumentation wie auch „Der Source-Code dokumentiert die Architektur.“ passt nicht. Die Schwierigkeit liegt grundsätzlich darin, genau so viel wie nötig zu dokumentieren. Eine Möglichkeit für die Strukturierung von Dokumentation von Architektur-Konzepten bietet die arc42 Vorlage. Im Kurs wurden die sieben Regeln für Dokumentation vorgestellt:

  1. Schreibe aus Sicht des Lesers
  2. Vermeide unnötige Wiederholungen
  3. Vermeide Mehrdeutigkeit und erkläre deine Notation
  4. Verwende eine Standardstrukturierung
  5. Halte Begründungen für Entscheidungen fest
  6. Halte Dokumentation aktuell (aber auch nicht zu aktuell)
  7. Überprüfe Dokumentation auf Gebrauchstauglichkeit

Software-Architektur bewerten
Neben dem Entwurf von Architekturen ist eine Disziplin des Software-Architekten auch das Bewerten von Software-Architekturen. Hier wurde während dem Kurs auf die verbreitete Bewertungsmethodik ‚ATAM‘ – Architecture Tradeoff analysis method eingegangen. ATAM kann früh angewendet werden und ist szenarienbasiert. ATAM ermöglicht, dass Entscheidungen transparent aufgedeckt werden, Feedback gegeben werden kann und Klarheit herrscht.

Wichtig: Es ist nie zu spät eine Architektur zu bewerten. Bewertungen können jederzeit durchgeführt werden und sollten auch vorgesehen und eingeplant werden.

Aufgabe und Rolle des Software-Architekten
Die Rolle des Software-Architekt ist anspruchsvoll. Zu seinen Aufgaben zählen (aus dem Buch ‚Effektive Software-Architekturen von Gernot Starke‘):

  • Anforderungen und Randbedingungen klären
  • Strukturen entwerfen
  • Technische Konzepte entwerfen
    • Architektur kommunizieren
    • Umsetzung begleiten
    • Architektur bewerten

Die Rolle des Software-Architekten ist aktiv, d.h. er geht Aufgaben pro-aktiv an, holt alle notwendigen Stakeholder zusammen, hält Randbedingungen ein, hat immer das sogn. ‚ Big-Picture‘ im Hinterkopf und strebt zugleich nach Einfachheit. Software-Architektur berührt alle Disziplinen der IT: Anforderungsmgmt, Betrieb, Projektmanagement, Implementierung und Design sowie die Berücksichtigung von technischen und organisatorischen Einflussfaktoren.

Ein wichtiger Aspekt in Projekten ist zugleich: Projektziele sind kurzfristig, Architekturziele aber langfristig!

Dies und das.
Folgende interessante Dinge wurden während dem Kurs genannt:

Discovery-Review„: Möglichst früh Architektur-Vision in den Review geben.
Architecture-Speeddating„: Unter Zeitdruck unterschiedliche Sichten der Software-Architektur des eigenen Systems zeichnen und einem Kollegen präsentieren.
Starschnitt“ – siehe http://update.hanser-fachbuch.de/tag/arc42-starschnitt/

Buch
Folgendes Buch dient als Vorbereitung für den Kurs:
Effektive Software-Architekturen von Gernot Starke

Push-Notifications mit hybridem Beigeschmack

Abstract
Auf dem Veranstaltungsportal Watogo (www.watogo.ch) können Benutzer mittels Umfragen mit Ihren Freunden über öffentliche wie auch private Veranstaltungen diskutieren und dabei passende Termine finden. Der Benutzer möchte bei neuen Aktivitäten auf seinen Umfragen sofort informiert werden. Dazu wird der jeweilige Push-Notification Mechanismus auf der entsprechenden Mobile-Plattform verwendet.

Dieser Artikel zeigt die Hürden der Realisierung im Zusammenhang mit dem hybriden Architekturansatzes durch Apache Cordova (https://cordova.apache.org/) und der Cloud Plattform Amazon Web Services (http://aws.amazon.com/de/) sowie die Lessons Learnt dieser plattformübergreifenden Push-Notification Implementierung.

Übersicht – beteiligte Systeme und eingesetzte Technologien
Die folgende Grafik zeigt die beteiligten Systeme und dient als Basis für den folgenden Artikel.

Watogo Push-Notification Systeme

Grün = Watogo, Rot = Amazon Dienst, Blau = proprietärer Benachrichtigungsdienst

Folgende Systeme sind für die Implementierung von Push-Benachrichtigungen beteiligt:
Watogo Mobile-App realisiert mit Apache Cordova für die Zielplattformen Android und iOS. Die Apps kommunizieren für die plattformspezifische Dienst-Registrierung direkt mit ihrem entsprechenden Push-Notification Service und für die applikationsspezifische Interaktion mit dem Applikationsserver von Watogo via HTTP. Um native Unterstützung im Bereich Push-Notifications zu erhalten wurde das offizielle Push-Plugin (https://github.com/phonegap-build/PushPlugin) eingesetzt.
Watogo Web-Client realisiert mit AngularJS und Twitter Bootstrap sowie diversen JQuery-Plugins. Der Web-Client wird nicht benachrichtigt – er löst Benchrichtigungen über den Applikationsserver aus.
Watogo Application Server realisiert mit Java, läuft auf einem Tomcat in einem Amazon EC2 Container und bietet für verschiedene Clients eine HTTP RESTful API an.
Amazon Simple Notification Service (SNS) fungiert als Fasade für das Senden von Push-Benachrichtigungenen und bietet diverse Möglichkeiten für das Verwalten von Push-Endpunkten (u.A. Mobile, E-Mail, HTTP, …). Der SNS ist die einzige Schnittstelle für das Auslösen von Benachrichtigungen. Er bindet die plattformspezifischen Benachrichtigungsdienste an. Der Dienst bietet verschiedene Konstrukte für die Gruppierung von plattformspezischen Endgeräten an.
Diverse proprietäre Benachrichtigungsdienste wie z.B. Google Cloud Messaging, Apple Push Notification Service, E-Mail Service oder das Auslösen von HTTP-Hooks. Diese Dienste Benachrichtigen die entsprechende Zielplattform.

In den folgenden Kapiteln wird auf die einzelnen Ausführungsschritte – von der Registrierung bis zur Benachrichtigung – konkret auf die Implementierung eingegangen.

Registrierung für Push-Notifications
Es werden grundsätzlich zwei Arten von Registrierungen für den Erhalt von Push-Benachrichtigungen unterschieden:
Die technische Registrierung – beim plattformspezifischen Benachrichtigungsdienst, wie z.B. Google Cloud Messaging Service (GCM) oder Apple Push Notification Service (APNS)
Die fachliche Registrierung – beim applikationsspezifischen Server, der die Gruppierung der verschiedenen Benachrichtigungsendpunkten vornimmt

Die folgenden zwei Kapitel beschreiben die beiden Registrierungsverfahren.

Die technische Registrierung
Die mobile App registriert sich anhand ihrer Plattform beim entsprechenden Dienst. Bei der Registrierung enthält die mobile App ein Registrierungs-ID bzw. ein Token, welche die App als eindeutiger Endpoint für Push-Benachrichtigungen legitimiert. Der folgende Ausschnitt aus der obigen Grafik zeigt den entsprechenden Kontext für die Registrierung:

Technische Registrierung

Da die Watogo App mit Apache Cordova, d.h. mit standard Web-Technologien wie HTML, CSS und Javascript gebaut wurde, braucht es ein entsprechendes Cordova-Plugin, das die jeweiligen Plattformen im Kontext von Push-Notifikationen unterstützt. Da die Implementierung von Push-Benachrichtigungen ein häufiger Anwendungsfall ist, gibt es von Phonegap bereits ein ausgereiftes Push-Plugin (https://github.com/phonegap-build/PushPlugin) dazu. Dieses Plugin enthält plattformspezifische Implementierungen für die technische Registrierung beim jeweiligen Dienst.

Das Push-Plugin lässt sich mittels Cordova CLI einfach einbinden:

Die technische Registrierung beim entsprechenden Dienst wird sobald in der WebView das Event ‚deviceready‘ ausgelöst wurde, durchgeführt. Hier wird auch die plattformspezifische Unterscheidung gemacht, wie der folgende Code zeigt:

Wie im obigen Code ersichtlich, muss für die Registrierung beim Google Cloud Messaging Dienst eine Sender-Id mitgegeben werden. Diese wird dann entsprechend im Javascript Code hinterlegt (siehe Property „senderID“). Die Sender-Id bekommt man über die Android Developer Konsole indem man den GCM-Dienst für die eigene Android-App freischaltet. Google beschreibt den Vorgang in einem eigenen Artikel (https://support.google.com/googleplay/android-developer/answer/2663268?hl=de). Der folgende Screenshot zeigt, wo man diese Sender-Id für GCM findet:

GCM Sender ID

Für den Apple Push Notification Dienst muss eine Aktivierung auf der App in der Developer Konsole von Apple (https://developer.apple.com/account) erfolgen. Hier kann man den Push-Notification Dienst aktivieren, wie der folgende Screenshot zeigt.Registrierung Push-Notification bei Apple

Damit die iOS Mobile App sich bei der entsprechenden APNS Plattform (Development oder Distribution) registrieren kann, muss die bauende Instanz ein entsprechendes Zertifikat eingespielt haben. Dieses muss für die Development wie auch für die Distribution Umgebung erstellt werden (dieser Schritt muss auch ohne Verwendung des Push-Dienstes durchgeführt werden). Die Apps sollten sich nach der Generierung des Zertifikates beim entsprechendem Dienst registrieren können. Mit dem Beispiel im git Repository vom Phonegap Push-Plugin kann dies entsprechend gut getestet werden (https://github.com/phonegap-build/PushPlugin/tree/master/Example/www).

Die fachliche Registrierung
Die fachliche bzw. die applikationsspezifische Registrierung für Push-Notifikation ist abhängig von die fachlichen Benachrichtigungsanforderungen an die entsprechende Mobile App. Die folgende Darstellung zeigt die Funktionsweise von Benachrichtigungen im Fall von Watogo.

Watogo Benachrichtigungen

Auf Watogo können mit Freunden zu öffentlichen wie auch privaten Veranstaltungen Umfragen gestartet werden. In den Umfragen können dann einzelne Terminvorschläge publiziert werden. Der Link zur Umfrage kann mit den eingeladenen Gästen geteilt werden. Diese können die Umfrage kommentieren und bestimmen, ob sie teilnehmen möchten oder nicht. Bei jeder Aktivität, d.h. Kommentar oder Teilnahme, wird eine Benachrichtigung ausgelöst. Benutzt man Watogo via App, erhält man in seinen Umfragen eine entsprechende Benachrichtigung. Das fachliche Datenmodell (Entitäten mit Relvanz zur Push-Benachrichtigung) des Umfragen-Konstruktes sieht wie folgt aus:
Fachliches Modell

Dabei gibt es folgende drei relevante Entitäten und Abhängigkeiten untereinander:
Umfrage: Wird verwendet, um einen passenden Termin von öffentlichen oder privaten Veranstaltungen mit seinen Freunden zu finden.
Benutzer: Nimmt an einer Umfrage teil, kommentiert diese und teilt sie u.U. auch mit anderen Freunden
Kommentar: Notiz oder Meinung eines Benutzers zu einer bestimmten Umfrage

Die Entität ‚Umfrage‘ wird als Container für eine bestimmte Empfängerschaft verwendet. Jeder Benutzer, der die Umfrage öffnet, registriert sich automatisch für die Benachrichtigungen und somit im Container ‚Umfrage‘ als potentieller Empfänger. Durch dieses Konstrukt bekommt man aus Sicht des Software-Entwicklers eine zusätzliche Komplexität bei der Verwaltung von Empfänger (sogn. Endpoints).
Wie in der Übersicht bereits aufgezeigt, wird für die Verwaltung der Empfänger sowie für den Versand von Benachrichtigungen der Amazone Simple Notification Service (SNS) verwendet. Dieser unterstützt bei der Realisierung des obengenannten Gruppierungs- und Benachrichtigungskonstruktes. Der SNS bringt ein eigenes Modell mit. Die folgende Grafik zeigt dieses Modell.

SNS Modell

Folgende Elemente gibt es beim SNS:

Plattform Application: Repräsentiert einen Benachrichtigungsdienst wie z.B. GCM oder APNS / APNS_Develop. Pro angebundener Push-Dienst muss eine Plattform Application erstellt werden. Aktuell unterstützte Push-Dienste:
– Amazon Device Messaging (ADM)
– Apple Production (APNS)
– Apple Development (APNS_Develop)
– Baidu Cloud Push for Android in China
– Google Cloud Messaging (GCM)
– Microsoft MPNS for Windows Phone 7+
– Microsoft WNS for Windows Phone 8+ & Windows Phone 8.1+

Im Kontext von Watogo wurden APNS, APNS_Develop und GCM als Platform Application eingerichtet.  Der folgende Artikel von Amazon beschreibt wie die einzelnen Platform Applications eingerichtet werden können: http://docs.aws.amazon.com/sns/latest/dg/mobile-push-send-register.html

Platform Endpoint: Repräsentiert ein Empfängergerät einer bestimmten Plattform Application. Ein Platform Endpoint ist im Kontext von Watogo ein Android- oder ein iOS-Gerät. Die Registrierung von Platform Endpoints an der entsprechenden Plattform Application soll automatisiert über das Amazon SDK laufen.
Topic: Ist eine Gruppierung von einer bestimmten Empfängerschaft (Subscriptions) und ermöglicht so diesen Empfängern gezielt eine Benachrichtigung zu senden. Die Erstellung eines Topics soll automatisiert über das Amazon SDK laufen.
Subscription:  Abonnement eines Topics, d.h. wird in einem Topic eine Benachrichtigung gesendet, wird diese Nachricht an den entsprechenden Endpoint weitergeleitet. Der Endpoint kann u.A. ein Platform Endpoint sein. In diesem Artikel werden nur die Plattform Endpoints besprochen. Die Erstellung einer Subscription soll automatisiert über das Amazon SDK laufen.

Da nun beide Modelle bekannt sind, können diese relativ einfach aufeinander gemappt werden. Das folgende Modell zeigt das Mapping der beiden Modelle.

Mapping der ModelleGrün = Fachliches Modell von Watogo, Rot = Modell von SNS

Aus dem obigen Modell geht folgendes hervor:

– Pro Umfrage muss ein Topic erstellt werden. (automatisiert)
– Pro Teilnehmer muss eine Subscription auf dem entsprechenden Topic erstellt werden. (automatisiert)
– Pro Gerät muss ein Plattform Endpoint erstellt werden. (automatisiert)
– Pro angebundener Benachrichtigungsdienst  muss eine Platform Application erstellt werden (manuell)

Sämtliche anwendungsspezifischen Registrierungen laufen über den Watogo Applikationsserver. In den folgenden Abschnitten wird dabei folgendes behandelt:

Watogo fachliche Registrierung

 

Es wird aufgezeigt wie sich die Geräte anwendungsspezifisch für Benachrichtigungen registrieren sowie diese Elemente auf dem Amazon SNS erstellt bzw. verwaltet wird.

Für die automatisierte Erstellung der Amazon SNS Elemente wird das Amazon SDK for Java (http://aws.amazon.com/de/sdk-for-java/) verwendet. Dieses kann in einem Maven-Projekt als Maven-Dependency (com.amazonaws.aws-java-sdk) referenziert werden.

Tipp: Amazon bietet ein Beispiel-Projekt, welches aufzeigt wie die einzelnen Elemente automatisiert erstellt werden können (Sns-Mobile-Push-Example.zip).

Platform Application(s) manuell erstellen
Pro unterstützte Benachrichtigungsplatform muss eine Platform Application im Amazon SNS erstellt werden.

Apple Push Notification Service (APNS und APNS_Sandbox): Das Einrichten der jeweiligen Platform Application und die Generierung der benötigten Zertifikate für eine APNS oder APNS-Develop Platform Application ist unter dem folgenden Link detailliert beschrieben: http://docs.aws.amazon.com/sns/latest/dg/mobile-push-apns.html

Google Cloud Messaging (GCM): Das Einrichten und die Generierung des benötigten API-Keys ist ebenfalls bei Amazon detailliert beschrieben: http://docs.aws.amazon.com/sns/latest/dg/mobile-push-gcm.html

SNS Client initialisieren
Bevor auf dem SNS Elemente automatisiert erstellt werden können, braucht es ein initialisiertes AmazonSNSClient Objekt. Um das Objekt zu erstellen, müssen folgende Attribute gesetzt sein:

AWSAccessKeyId: Benutzer-ID (mit entsprechenden SNS-Rechten) um auf den SNS-Dienst zugreifen zu können
AWSSecretKey: Benutzerspezifischer Schlüssel um auf den SNS-Dienst zugreifen zu können
Endpoint: SNS-Endpoint (Spezifikation der Region)

Die Benutzerdaten (Accesskey und Secretkey) erhält man, in dem man für den SNS-Dienst einen eigenen Benutzer im AWS IAM erstellt.

Der Code für das Aufsetzen des AmazonSNSClient sieht wie folgt aus:

Topic erstellen
Um einen Container für potentielle Empfänger von Push-Notifications zu erhalten, muss pro Umfrage ein entsprechendes SNS Topic erstellt werden. D.h. sobald ein Benutzer eine Umfrage erstellt, muss automatisch im SNS ein Topic erstellt werden. Der Watogo Anwendungsserver bietet eine Schnittstelle um Umfragen zu erstellen. Dort kann man sich jetzt einhängen und beim Erstellen einer Umfrage ein entsprechendes SNS Topic erstellen. Der Code für das Erstellen eines SNS Topics sieht wie folgt aus.

Die Erstellung eines Topics ist relativ einfach. Man muss lediglich den Namen des gewünschten Topics angeben. In Watogo haben wir die Benennung des Topics mit der Id der Umfrage verknüpft, um das Mapping zwischen Topic und Umfrage herstellen zu können. So ist es auch möglich nicht mehr verwendete  Topics bzw. nicht mehr gültige Umfragen nach einer bestimmten Zeit wieder aufräumen zu können. Bei einer erfolgreichen Erstellung des Topics erhält man im Result-Objekt eine Topic-ARN. Das ARN steht für Amazon Resource Name und ermöglicht eine eindeutige Referenzierung des entsprechenden Amazon Objektes (egal ob Topic, Platform Endpoint, Platform Application, etc.). Dieses Topic-Arn wird bei der Erstellung der Subscription relevant sein.

Platform Endpoint erstellen
Um ein Abonnement bzw. Subscription einem bestimmten Topic anhängen zu können, muss zuerst das Gerät des Benutzers bzw. der Platform Endpoint registriert werden. Im Kapitel „technische Registrierung“ hat das Gerät bei der Initialisierung bereits ein eindeutiges Token bzw. eine Device-Id vom passenden Push-Notification Dienst erhalten. Dieses wird nun verwendet, um einen Platform Endpoint innerhalb einer bereits eingerichteten Platform Application beim Amazon SNS erstellen zu können. Um einen Platform Endpoint erstellen zu können, benötigt man zuerst der ARN der entsprechenden Platform Application (= des Benachrichtigungsdienstes). In Watogo wurde die ARN der pro Platform Application einfach in einem Setting-File hinterlegt. Die mobile App gibt in Watogo über die API mit um welche Schnittstelle es sich beim entsprechenden Gerät handelt. Der folgende Code zeigt die Erstellung eines Platform Endpoint innerhalb einer bestimmten Platform Application anhand der übergebenen Platform von der Mobile-App:

Folgendes wird beim obigen Code ausgeführt:

1. Eintrittsmethode createPlatformEndpoint
Die HTTP REST API ruft beim Registrieren eines mobilen Gerätes bei einer Umfrage diese Methode mit Zielplatform (Parameter Platform – androidos oder ios), mit dem Devicenamen (Hardware-ID des Gerätes) sowie mit dem Token für den entsprechendem Push-Notification Dienst (dieses wurde vorgängig vom Device beim Benachrichtigungsdienst bereits abgeholt). Die Eintrittsmethode createPlatformEndpoint versucht lediglich den Parameter platform zu interpretieren und sucht dabei den richtigen Wert im Enumerator Platform. Falls der Wert gefunden wurde, delegiert sie diesen Wert weiter an die Methode createEndpoint.

2. Methode createEndpoint
Die Methode holt nun den ARN der entsprechenden Platform Application (Methode getArn) aus dem SNS (APNS, APNS_Sandbox oder GCM) und ruft die Methode requestPlatformEndpoint mit der korrekten Platform Application ARN auf.

3. Methode requestPlatformEndpoint
Diese Methode stellt den Request mit den entsprechenden Parametern (Platform Application Arn, Device-Token und Name des Edpoints) und setzt nun diesen Request an den SNS ab. Das Resultat gibt sie dann an die aufrufende Methode (insb. den ARN der erstellten oder bereits existierenden Endpoints) zurück.

So ist es nun möglich, pro Gerät im Amazon SNS ein entsprechender Platform Endpoint zu erstellen. Da nun der ARN des Topics (= Umfrage) sowie der entsprechenden Platform Endpoints (Geräte der Umfrage-Teilnehmer) erstellt sind, müssen lediglich auf dem Topic noch entsprechende Subscription(s) erstellt werden.

Subscription erstellen
Die Subscription ermöglicht die Benachrichtigung über Aktivitäten in einem bestimmten Topic. Die Subscriptions von einem Topic erhalten sämtliche Nachrichten. Deshalb wurde auch in Watogo für eine Umfrage ein entsprechendes Topic erstellt. Alle Aktivitäten wurden im Topic veröffentlicht und so die Geräte via Push-Notification informiert. Durch eine Subscription wird man über alle Topic relevanten Nachrichten entsprechend benachrichtigt. Der folgende Code zeigt, wie man für einen PlatformEndpoint eine Subscription an einem bestimmten Topic macht.

Da der Platform Endpoint innerhalb einer registrierten Platform Application läuft, verläuft die Subscription via Typ ‚Application‘. Es können folgende verschiedene Arten von Subscriptions erstellt werden:

– HTTP
– HTTPS
– E-Mail
– E-Mail-json
– Amazon SQS
– Application
– AWS Lambda

In Watogo wird aktuell lediglich der Typ Application für eine Subscription verwendet.

Benachrichtigungen auslösen
Die Subscriptions auf einem bestimmten Topic wurden erstellt – nun möchte man in einem bestimmten Topic eine Benachrichtigung auslösen. Der SNS bietet hier eine offene Schnittstelle um plattformspezifische Nachrichten zu senden. Jede Plattform erwartet eine spezifische Nachricht (typischerweise im JSON-Format). In der AWS Konsole können diese Nachrichten plattformspezifisch generiert werden, wie der folgende Screenshot zeigt:

Send a Push Notification to a specific message

Wenn nun die JSON-Datei generiert wird, sieht diese so aus:

Wichtig ist hier, dass der SNS lediglich das Nachrichten-Property auf der entsprechenden Plattform abfüllt. Je nach Plattform werden aber noch weitere Attribute unterstützt. Es können auch anwendungsspezifische Daten mitgegeben werden, welche dann von der App entsprechend ausgelesen werden. Der folgende Code zeigt wie man nun eine Nachricht in einem SNS-Topic publiziert:

Benachrichtigungen interpretieren
In der Cordova basierten Mobile-App muss nun die entsprechende Push-Benachrichtigungen interpretiert werden. Hier kommt wieder das Push-Plugin ins Spiel bzw. die anfänglich beschriebene Registrierung. Nachfolgend nochmals der Registrierungscode des Plugins:

Auf Zeile 16 (‚onNotification‘ für GCM) sowie Zeile 26 (‚onNotificationAPN‘ für APNS / APNS_Sandbox) sieht man die Registrierung von Callback-Funktionen für die Interpretation von Push-Benachrichtigungen. Die Interpretation von GCM-Nachrichten verläuft nun wie folgt:

In der Interpretation der Push-Benachrichtigungen muss beachtet werden, ob die App im Vordergrund ist oder nicht. Ist die App im Vordergrund braucht es keine Push-Benachrichtigung sondern einen sogn. Confirmation-Dialog. Die Information, ob eine App im Vordergrund ist oder nicht, wird im Event-Argument mitgeliefert (siehe Zeile 12). Ist die App nicht im Vordergrund, der Benutzer klickt aber auf die Push-Benachrichtigung, muss dies ebenfalls in der App behandelt werden. In Watogo wird die Id der Umfrage in der Nachricht mitgeschickt, damit man beim Klick auf die Nachricht direkt auf die entsprechende Umfrage gelangt. Die Herausforderung bei diesem Fall ist, vom spezifischen Cordova-Plugin Code in die AngularJS basierende SPA zu gelangen und dort ein Event auslösen zu können. Die Lösung des Problems zeigt Zeile 24 – 26. Hier wird das ng-app Element geholt und der entsprechende Injector dazu. Dazu wurde eine Factory ‚cordovaPush‘ erstellt, welche die Notifikationen entgegennimmt und dann in der SPA entsprechende Vorkehrungen trifft (im Fall von Watogo wird die location verändert). Der folgende Code zeigt die Factory.

Die onNotification-Funktion wird vom Plugin spezifischen Code aufgerufen.

Der folgende Code zeigt die Interpretation von APNS-Nachrichten:

Fazit & Lesson learnt
Die Implementierung von Push-Notification auf einem hybriden Stack ist aufwändig, da viele verschiedenen Technologien (HTML, Javascript, CSS, Java) und verschiedene Plattformen involviert sind (Tomcat Applikationsserver, Amazon Web Services, Amazon Simple Notification Service, Android mit verschiedenen Versionen und Geräte,  iOS mit verschiedenen Versionen). Die Fehlersuche bzw. das Debugging ist ebenso aufwändig wie auch Schwierig (lokales Debugging der App und des lokalen Applikationsservers). Auf der positiven Seite erhält man dadurch eine sehr grosse Flexibilität für die Anbindung von neuen bzw. weiteren Platformen .

In Zukunft würden wir das Feature für eine Platform (z.B. GCM) implementieren, anschliessend die Benutzung messen und dann anhand der Benutzer-Daten entscheiden, ob eine Ausweitung auf eine weitere Plattform Sinn macht.