Verwendung von iBeacons unter Android

[toc]

Der folgende Artikel befasst sich mit der Nutzung von iBeacons als Bluetooth Low Energy Lokalisierungshilfsmittel fürAndroid-Geräten. Nach einer kurzen Einführung in die grundsätzliche Funktionsweise von iBeacons werden Installationsanleitungen sowie Codebeispiele zur Verwendung von iBeacons mittels Estimote-SDK und AltBeacon bereitgestellt. 

Begriff iBeacons

Der Begriff iBeacon wurde von Apple 2013 eingeführt und steht als Markenname für ein auf Bluetooth Low Energy (BLE) bzw. Bluetooth 4.0 basierendes Produkt, das z.B. zur Indoor-Navigation genutzt werden kann. Hierbei stellt das iBeacon einen Sender dar, der in kontinuierlichen Zeitabständen Daten an entsprechende Empfangsgeräte (Smartphone, Tablet, …) sendet. Diese Daten können mittels einer speziellen App genutzt werden, um beispielsweise die eigene Position zu ermitteln. Ein iBeacon zeichnet sich durch seine lange Laufzeit und vergleichsweise hohen Reichweite aus. Die Technologie wird von verschiedenen Herstellern angeboten, wobei die im Weiteren aufgeführten Tests und Beispiele unter Verwendung von Estimote-iBeacons durchgeführt wurden.

[singlepic id=1794 w=618 float=center]

Nutzung

Im folgenden Abschnitt werden die Vorraussetzungen für die Nutzung sowie die wesentlichen Daten und Begriffe, die für die Arbeit mit iBeacons relevant sind, aufgeführt.

Voraussetzung

Die Nutzung von iBeacons kann nur unter bestimmten Voraussetzungen erfolgen. Das jeweilige Mobile Device muss BLE / Bluetooth 4.0 unterstützen, was somit Geräte ab iOS7 und Android 4.3 umfasst.

Entsprechende Bibliotheken werden für IOS von Apple bereitgestellt. Android-Entwickler müssen hingegen auf Bibliotheken der jeweiligen Hersteller zurückgreifen, da Google keine offiziellen zur Verfügung stellt.

Daten eines iBeacons

Die Daten, die ein iBeacons sendet, sind im Folgenden Beispielhaft aufgeführt.

  • UUID: B9407F30-F5F8-466E-AFF9-25556B57FE6D
  • Minor: 1
  • Major: 2
  • RSSI: -55
  • measuredPower: 62

Die nachfolgende Abbildung stellt die Funktion der jeweiligen Werte schematisch dar:

[singlepic id=1793 w=618 float=center]

Ein beispielhafter Anwendungsfall ist die Kennzeichnung von Bereichen in einem Unternehmen mit mehreren Standorten. So würde jedes iBeacon des Unternehmens mit der gleichen UUID initialisiert werden. Jeder Standort erhält einen entsprechenden Major-Wert und ein eine Abteilung an einem Standort einen Minor-Wert. Unternehmen X verwendet also die UUID „B9407F30-F5F8-466E-AFF9-25556B57FE6D“ und Standort A und B jeweils die Major-Werte  „1“ bzw. „2“. Die Abteilung „I“ und „J“ werden jeweils mit den Minor „1“ und „2“ verknüpft. So ist nun Abteilung I an Standort B des Unternehmens X mit den entsprechenden Werten(UUID: „B9407F30-F5F8-466E-AFF9-25556B57FE6D“, Major: „2“, Minor: „1“) eindeutig identifizierbar. Die Distanz zu einem iBeacon lässt sich aus den Werten RSSI und measuredPower berechnen

Monitoring, Ranging und Region

Die Begriffe Monitoring und Ranging beschreiben die zwei Kommunikationsweisen zwischen iBeacons und Empfangsgeräten. Eine Region ist ein Bereich, der sich durch festgelegte Werte (UUID, Major und Minor) definiert. Eine Region umfasst je nach Initialisierung ein bis beliebig viele iBeacons.

Beim Monitoring wird überprüft, ob ein bestimmter Bereich (Region) betreten oder verlassen wurde. Hierbei wird in zeitlichen Abständen getrackt, ob bzw. ob keine iBeacons einer Region empfangen werden; dementsprechend können Programmabschnitte aufgerufen werden. Monitoring ist speziell für Hintergrundprozesse geeignet, da nur beim Eintreten der zuvor erwähnten Ereignisse ein Aufruf entsprechender Methoden erfolgt.

Im Gegensatz zum Monitoring handelt es sich beim Ranging um einen kontinuierlichen Aufruf von entsprechenden Methoden, da dauerhaft eine Aktualisierung der empfangenen iBeacons erfolgt. Ranging eignet sich daher für Vordergrundprozesse, in denen eine Aktualisierung der entsprechenden Daten (z.B. Distanz zum iBeacon) erforderlich ist.

Verwendung unter Android

Wie zu Beginn dieses Beitrags erwähnt, müssen bei für Android-Anwendung die SDKs der jeweiligen Hersteller verwendet werden, z.B. das von Estimote. Alternativ dazu wird mit dem OpenSource-Projekt AltBeacon ein entsprechendes SDK zur allgemein gültigen Nutzung bereitgestellt, das weiter unten ebenfalls betrachtet wird.

Estimote

Eine Beispielanwendung, die Monitoring und Ranging verwendet, ist im Folgenden dokumentiert.

Zunächst muss die estimote-sdk-preview.jar in das /libs Verzeichniss des Projekts kopiert werden. Im build.gradle File muss nun folgende Abhängigkeit hinzugefügt werden:

 dependencies {
   compile files('libs/estimote-sdk-preview.jar')
 }

Folgende Zeilen müssen im Manifest (AndroidManifest.xml) ergänzt werden:

<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />

Anschließend muss der Service in der selben Datei deklariert werden. Dies geschieht innerhalb des Application Tags.

<service android:name="com.estimote.sdk.service.BeaconService" android:exported="false" />

Nun wird eine neue Activity erstellt und eine neue Region erzeugt, die alle Estimote-iBeacons umfasst. Außerdem wird ein BeaconManager erzeugt:

private static final String ESTIMOTE_PROXIMITY_UUID = "B9407F30-F5F8-466E-AFF9-25556B57FE6D";
private static final Region ALL_ESTIMOTE_BEACONS = new Region("regionId",ESTIMOTE_PROXIMITY_UUID, null, null);
private BeaconManager beaconManager = new BeaconManager(this);

Als nächstes wird in der onStart()-Methode der BeaconManager mit dem Service verbunden und je nach Bedarf das Ranging bzw. Monitoring gestartet.

@Override
protected void onStart() {
  super.onStart();
  beaconManager.connect(new BeaconManager.ServiceReadyCallback() {
    @Override public void onServiceReady() {
      try {
        beaconManager.startRanging(ALL_ESTIMOTE_BEACONS);
      } catch (RemoteException e) {
      }
    }
  });
}

Nun kann ein entsprechender Listener erzeugt und dem BeaconManager zugewiesen werden:

beaconManager.setRangingListener(new BeaconManager.RangingListener() {
  @Override public void onBeaconsDiscovered(Region region, List<Beacon> beacons) {
    System.out.println(beacons);
  }
});

AltBeacon

Radius-Networks stellt mit AltBeacon eine gut dokumentierte Open-Source Lösung zu Apples iBeacons zur Verfügung. Standardmäßig erkennt die Bibliothek nur iBeacons, die nach dem AltBeacon Standard spezifiziert sind. Zur Interaktion mit z.B. iBeacons von Estimote oder anderer Hersteller muss der enthaltene BeaconParser[ref]Vgl. https://altbeacon.github.io/android-beacon-library/javadoc/org/altbeacon/beacon/BeaconParser.html.[/ref] verwendet werden. Beispiele zur Verwendung der Bibliothek können auf der entsprechenden GitHub-Seite eingesehen werden.

Vergleich der Frameworks

Die Konfiguration des Estimote-SDK[ref]Vgl. https://github.com/Estimote/Android-SDK.[/ref] ist im Gegensatz zur Alternative AltBeacon einfacher, jedoch nur auf die entsprechenden iBeacons ausgelegt, sodass für den Einsatz anderer Hardware zusätzliche Bibliotheken eingebunden werden müssen. Zudem fehlen Methoden zur Entfernungsbestimmung, sodass die Berechnung selbst durchgeführt werden muss.

AltBeacon zeichnet sich durch seine Flexibilität und guten Dokumentation aus, jedoch muss zunächst der entsprechende BeaconParser erzeugt werden (siehe oben).

Probleme der Technologie

Die RSSI-Werte variieren sehr stark. Zum einen wird das empfangene Signal durch die Haltung des Device (Tablet, Smartphone) beeinträchtigt und zum anderen ist die Position des jeweiligen iBeacons entscheidend. Positioniert man dieses beispielsweise zwischen Regalen, so leidet das Signal je nach Position des Empfängers.

Aufgrund der Ungenauigkeit des Signals, sollten mehrere iBeacons möglichst mit größerem Abstand eingesetzt werden, um mögliche Störungen oder Überscheidungen der Signale zu vermeiden.

Fazit

Die Verwendung von iBeacons unter Android ist mit den entsprechenden Frameworks, die von den Herstellern bereitgestellt werden, mit geringem Aufwand möglich. Jedoch umfasst der Funktionsumfang der SDKs, die in diesem Beispiel zum Einsatz gekommen sind, nicht den der iOS-Bibliotheken.

Die Technologie könnte beispielsweise für die Kennzeichnung von bestimmten Bereichen in Gebäuden verwendet werden, sofern die iBeacons bzw. die Bereiche einen ausreichenden Abstand zu einander haben. Eine zufriedenstellende Indoor-Navigation ist jedoch nur schwer umsetzbar, da die Signale bisher zu störanfällig sind.

Multitouch-Entwicklung mit MT4j

[toc]Dieser Artikel stellt den Auftakt einer Serie weiterer Berichte zu „ersten Schritten“ mit aktuell verfügbaren Multitouch-Entwicklungsumgebungen dar. Innerhalb dieser Serie liefert der vorliegene Bericht einen Überblick über die Entwicklung von Multitouch-Anwendungen mit Multitouch for Java (MT4j). Das Framework bietet umfangreiche Funktionalität für das Arbeiten mit Multitouch-Hardware und einfach adaptierbare Konzepte zur Entwicklung eigener Anwendungen. Im Folgenden wird nach einer kurzen Einführung die Einrichtung mit Eclipse erläutert, einige Beispielanwendungen vorgestellt sowie ein Minimal-Beispiel implementiert.

Einführung

  • Java-Framework zur Entwicklung von Multitouch-Anwendungen
  • Verwendung verschiedener Komponenten (Bilder, Videos, 3D-Objekte)
  • Anbindung unterschiedlicher Hardware und Protokolle
  • 10 vorhandene Multitouch-Gesten sowie Möglichkeit zur Erstellung von eigenen Gesten
  • Performante Darstellung durch OpenGL

Demo

Um vor der Vorstellung der technischen Details einen ersten Eindruck zu schaffen, demonstriert das folgende Beispielvideo die Funktionalität der mitgelieferten Kartenapplikation:

Historie

Das MT4j-Framework wird vom Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO) entwickelt und basiert (wie der Name schon sagt) auf der weit verbreiteten objektorientierten Programmiersprache Java. Im Herbst 2009 wurde das Framework unter Open Source-Lizenz veröffentlicht und wird seitdem durch die OpenSource-Gemeinde weiterentwickelt. Die Multitouch-Plattform übernimmt alle benötigten Aufgaben, wie beispielsweise die Erkennung von Multitouch-Gesten, deren Umsetzung in Events sowie die erforderliche Grafikausgabe. Es bietet eine umfangreiche Bibliothek mit vorgefertigten Grafiken, Gesten und Schriften und ist sehr generisch implementiert, sodass eigene Gesten und Grafiken problemlos hinzugefügt werden können. Das Framework ist prinzipiell kompatibel zu allen Multitouch Geräten, da es die Inputs der Hardware abstrahiert.  Als Grundlage hierfür wird die Anbindung an verschiedene APIs (z.B. TUIO) bereitgestellt, welche die Eingaben des Touchscreens interpretieren. Die Darstellung erfolgt über die Grafikschnittstelle OpenGL, sodass die Anwendungen auf entsprechender Hardware sehr performant sind.

Komponenten und Aufbau

Die nachfolgende Tabelle gibt einen Überblick über die technischen Eigenschaften sowie bereitgestellten Gesten und Komponenten des Frameworks:

Eigenschaft Ausprägung bei MT4j
Programmiersprache
  • Java
Rendering
  • OpenGL
  • Software-Rendering
Hardware-Anbindung
  • Hardwareabstraktion und Input Abstraktion
  • Es können beliebige Eingabegeräte integriert werden
  • Native Unterstützung von Windows 7 Multitouch-Features
  • Unterstützung des TUIO-Protokolls
Multitouch-Gesten
  • Drag
  • Rotate
  • Scale
  • Tap
  • Double Tap
  • Tap and Hold
  • Arcball Rotate
  • Lasso Select
  • Flick
  • Gesture Draw
  • Eigene Gesten können definiert werden
Bereitgestellte Komponenten
  • Primitive Vektorgrafiken [ref]Vierecke, Ellipsen, Polygone, etc. .[/ref]
  • Schriften [ref]Standardschriftarten (True Type) und Vektor-basierte Schriftarten.[/ref]
  • Bilder [ref]Unterstützung gängiger Formate (.jpg, .png, .bmp).[/ref]
  • 3D-Objekte [ref].3ds und .obj Dateien mit Texturen.[/ref]
  • Videos [ref]Unterstützung gängiger Formate.[/ref]

Installation

Das MT4j Framework steht als quelloffener Download, derzeit in Version 0.95 zur Verfügung und ist bereits als ein Eclipse-Projekt strukturiert.

MT4j läuft derzeit nur mit der 32bit-Variante von Java. Soll ein 64bit System eingesetzt werden, muss trotzdem der 32bit JDK installiert werden. Unter Eclipse muss entsprechend die 32bit Variante von Java zum Ausführen der MT4j Anwendungen ausgewählt werden!

  1. Java Development Kit 32bit (gekennzeichnet als x86) herunterladen und installieren
  2. Die heruntergeladene ZIP-Datei entpacken (MT4j 0.95 full release)
  3. Im Paketexplorer von Eclipse mit Rechtsklick importieren wählen
  4. In dem Importfenster ein „bereits existierendes Projekt“ auswählen
  5. Den unter 2. entpackten Ordner auswählen und importieren

[nggtags gallery=MT4j+Installation]

Mitgelieferte Beispiele

Das MT4j-Paket enthält 19 einfache Beispielanwendungen. Diese sind unterteilt in die Pakete „basic“ und „advanced“ und sind im Ordner „examples“ zu finden. Die Basic Examples dienen zum Verstehen und Testen der grundlegenden Techniken in sehr einfach gehaltenen Applikationen. Die Advanced Examples demonstrieren die Leistungsfähigkeit des Frameworks, indem beispielsweise 3D Modelle verwendet werden. Jede Anwendung befindet sich in einem eigenen Paket. Es ist keine weitere Konfiguration erforderlich, da das Framework alle benötigte Komponenten automatisch sucht und auswählt. Zum Starten ist jeweils eine „Start…Example.java“ Datei hinterlegt, die als „Java Application“ in Eclipse ausgeführt werden kann. Nach dem Start öffnet sich ein neues Fenster innerhalb dessen die Multitouch-Interaktion möglich ist.

Basic-Anwendungen

[nggtags gallery=MT4j+Beispielanwendung+basic]

Advanced-Anwendungen

[nggtags gallery=MT4j+Beispielanwendung+advanced]

Minimalimplementierung

Eine Multitouch-Anwendung mit MT4j zu schreiben ist denkbar einfach, da sie nur zwei Klassen (Scene und MTApplication) benötigt. Die folgenden beiden Abschnitte geben einen Überblick über die Implementierung eine einfachen Applikation zur Bildmanipulation. Die Anwendung, die zum Selbsttest ebenfalls als Download verfügbar ist, ermöglicht es, ein Bild anzuzeigen und dieses mit Standard-Multitouch-Gesten zu manipulieren.

Scene

Eine „Scene als erste benötigte Bestandteil der Anwendung muss die abstrakte Klasse „AbstractScene“ erweitern. In dieser Klasse wird festgelegt, welche Komponenten angezeigt werden. Es gibt viele vorgefertigte Elemente, die insbesondere Standard-Multitouch-Gesten bereits beherrschen. Hierzu gehören beispielsweise Grafiken, Textfelder und Rahmen für verschiedene andere Objekte. Für unser Minimalbeispiel benötigen wir folgenden Code für die Scene-Klasse:

package MinimalExample;

import org.mt4j.MTApplication;
import org.mt4j.components.TransformSpace;
import org.mt4j.components.visibleComponents.widgets.MTImage;
import org.mt4j.input.gestureAction.InertiaDragAction;
import org.mt4j.input.inputProcessors.componentProcessors.dragProcessor.DragProcessor;
import org.mt4j.sceneManagement.AbstractScene;
import org.mt4j.util.math.Vector3D;

import processing.core.PImage;

public class PictureScene extends AbstractScene
{
  private String picturePath =  "MinimalExample" + MTApplication.separator + "data" + MTApplication.separator;

  public PictureScene (MTApplication mtApplication, String name)
  {
    super(mtApplication, name);

    MTApplication app = mtApplication;
    PImage img = app.loadImage(picturePath + "pic.jpg");
    MTImage image = new MTImage(img,app);
    image.setUseDirectGL(true);
    image.setPositionGlobal(new Vector3D(400,400,0));
    image.scale(0.2f, 0.2f, 0.2f, image.getCenterPointLocal(), TransformSpace.LOCAL);
    image.addGestureListener(DragProcessor.class, new InertiaDragAction());
    this.getCanvas().addChild(image);
  }

  @Override
  public void init() {}

  @Override
  public void shutDown() {}
}

Datei ist zu beachten, dass sich das entsprechende Bild im Paket „MinimalExample.data“ (gekennzeichnet als „picturePath“) befinden muss, damit es geladen werden kann!

MTApplication

Die „Application“-Klasse dient zum Starten der Anwendung und muss die abstrakte Klasse „MTApplication“ erweitern. Die vorher beschriebene Scene wird lediglich hinzugefügt. Anschließend wird die Anwendung mit dem Methodenaufruf „initialize()“ gestartet. Dazu sind lediglich die Folgenden Codezeilen erforderlich:

package MinimalExample;

import org.mt4j.MTApplication;

public class StartMinimalExample extends MTApplication
{
  private static final long serialVersionUID = 1L;

  public static void main(String args[])
  {
    initialize();
  }

  @Override
  public void startUp()
  {
    this.addScene(new PictureScene(this, "Picture scene"));
  }
}

CommunityMashup – Ein erster Überblick

[toc] Das CommuntiyMashup ist eine Integrationslösung für Daten aus sozialen Diensten. Es vereinheitlicht und verbindet Daten aus den unterschiedlichsten Quellen. Hierbei steht im Sinne des „Social Web“ die Person im Vordergrund. Eine definierte Schnittstelle mit vorgefertigen Anwendungskompenten lässt eine einfache Verwendung der Daten in verschiedensten Anwendungsszenarien zu. Diese Seite gibt einen Überblick über die dem CommunityMashup zugrundeliegenden Konzepte und vermittelt einen Einblick in seine vielfältigen Verwendungsmöglichkeiten.

Ausgangssituation

Mit dem Erfolg von Web 2.0 im privaten und Enterprise 2.0 im unternehmensweiten Bereich veränderte sich die Art und Weise wie Informationen strukturiert und kosumiert werden.

[singlepic id=220 w=618 float=center]

Auswirkungen des Erfolg von Social Software

Im Zuge des immer verbreiteteren Einsatzes von Social Software auch im Unternehmenskontext vollzieht sich eine Entwicklung von einer datenzentrischen Systemsicht hin zu einer personzentrischen Perspektive. Soziale Netzwerke wie Facebook oder Microblogging Dienste wie Twitter sind nur zwei Arten von Diensten die Einzug in unser tägliches Leben gefunden haben. Insgesamt lässt sich beoachten, dass fast jeder Nutzer inzwischen mehr als einen Dienst benutzt, sei es wegen spezieller Funktionalitäten, den Personen die über den jeweiligen Dienst erreichbar sind oder schlichtweg um private und berufliche Nutzung zu trennen. So sind wir unter anderem gezwungen den richtigen Kanal zu wählen um Informationen zu konsumieren bzw. zu verteilen. Dies nährt den Wunsch nach einer Integrationslösung, die unsere Daten aus unterschiedlichen Diensten vereint ohne dabei ein neues zentralisiertes System zu schaffen. Insbesondere muss uns die Wahl der Dienste und die Art und Weise, wie wir diese nutzen wollen offen bleiben.

Mobile und ubiquitäre Nutzung

Eine weitere Veränderung der letzten Jahre lässt sich in der Nutzung verschiedenster Geräte, mit denen wir Informationen konsumieren, festhalten. Sei es mit dem Tablet zuhause im Wohnzimmer, unterwegs per Smartphone oder klassisch im Büro mit dem Desktoprechner. Hinzukommen ubiquitäre Systeme wie interaktive Wandbildschirme, welche die letzten Lücken unserer Informationsversorgung schließen. Eine zukunftsfähige Integrationslösung muss daher dem Nutzer die Möglichkeiten der freien Geräte- und Plattformwahl offen lassen.

Nutzerzentrische Aggregation verschiedener Quellen

Der Grundgedanke des Web 2.0 beinhaltet die starke Einbeziehung aller Nutzer bei der Erstellung von Inhalten und die Möglichkeit diese mit anderen Personen zu teilen. Mit der Integration von Daten aus uterschiedlichen Diensten entsteht der Wunsch diese untereinander mit zusätzlichen Informationen zu Verknüpfen und diese wiederum mit anderen zu teilen. Hierin liegt auch ein Kritikpunkt an aktuellen Integrationssystemen, die meist nur aus einer Single-User Perspektive getrieben sind. Beispielsweise ist die Verteilung der Information innerhalb einer Gruppe, wer welche Artikel zu einem gemeinsamen Interessensgebiet gelesen hat, aus dieser Perspektive unmöglich. Wobei die Artikel natürlich aus verschiedensten Quellen stammen können. Zusammen mit der personenzentrischen Sicht auf Daten, der Vielzahl verschiedenster genutzer Dienste und der Verwendung unterschiedlichster Geräte führt dies zum Wunsch einer neuen Integrationslösung für die wir im folgenden die Konzepte und Lösungsansätze vorstellen.

Grundidee

Das CommunityMashup verbindet die Inhalte aus verschiedensten sozialen Diensten. Dazu zählen beispielsweise Soziale Netzwerke wie facebook, Microblogging Dienste wie twitter oder Bild-Dienste wie flickr, aber auch spezielere wie beispielsweise der Referenzmanagement-Dienst Mendeley für wissenschaftliche Veröffentlichungen. Die Daten aus diesen Diensten werden über die Schnittstellen der Services abgerufen und über spezielle Adapter vereinheitlicht, so dass sie miteinander vermischt und verbunden werden können („mashup“). Die vereinheitlichten Daten werden anschließen wieder über spezielle Schnittstellen bereitgestellt. Hierbei wird auf unterschiedliche Anwendungsszenarien und deren spezielle Anforderung eingegangen, die insbesondere durch verschiedene Geräte und Plattformen beeinflusst sind. Wir unterscheiden ganz allgemein zwischen Web-Anwendungen, Desktop-Anwendungen und Anwendungen für mobile Geräte. Die folgende Grafik visualisiert diese Zusammenhänge noch einmal grafisch. Hierbei ist vorallem zu beachten, dass Daten nicht nur von den angebunden Diensten zu den Endbenutzer Anwendungen fließen, sondern auch in umgekehrter Richtung.
[singlepic id=603 w=618 float=center]

Model Driven Approach

Ausgehend von der Grundidee einer Integrationslösung für soziale Dienste, die Daten vereinheitlicht und über spezielle Schnittstellen wieder bereitstellt, stellt sich die Frage nach dem passenden Entwicklungsansatz. Erfahrungen haben gezeigt, dass Internetdienste sowie ihre ggf. vorhandenen Schnittstellen einer permanenten Änderung und Weiterentwicklung unterworfen sind. Dienste kommen und gehen bzw. sind populären oder unpopulärer ebenso verhält es sich mit ihren Funktionen und Schnittstellen. Um flexibel auf diesen kontinuierlichen Wandel reagieren zu können und dabei eine stetige Evolution der Integrationslösung zu ermöglichen, schlagen wir einen modellgetriebenen Ansatz vor. Dieser basiert auf einem dafür konzipierten personenzentrischen Datenmodell, das die Zusammenhänge in sozialen Diensten wiedergibt. Dieses Datenmodell und die darauf aufbauenden Anwendungskomponenten stellen wir im weiteren Verlauf näher vor.

Datenmodell

Untenstehende Abbildung zeigt die Kernelemente des personenzentrischen CommunityMashup-Datenmodells. Es enthält die drei Kernelmente Person, Organisation und Inhalt (Content). Organisationen wie auch Inhalte können hierarchisch strukturiert werden. Inhalte werden über eine Autor-Beziehung mit Personen verknüpft, diese wiederum können über Organisationen gruppiert werden. Personen-Objekte spiegeln jeweils reale Menschen wieder, d. h. für eine Person wird nicht ein eigenes Element für je benutzten Dienst erzeugt werden, vielmehr bilden alle verteilten Profile zusammen eine digitale Identität ab. Das Selbe gilt auch für die Profile von Organisationen. Jeder weitere Dienst trägt seine zusätzlichen Profilinformationen über Erweiterungs-Objekte (Extensions) bei. So bleibt auch der Bezug zur ursprünglichen Quelle erhalten.
[singlepic id=600 w=618 float=center]

Ein Kernkonzept des Datenmodells ist die bewusst offene Verwendung von Tags für Metainformationen, um ein Minimum von zusätzlichen Attributen für die einzelnen Daten-Objekte fix speichern zu müssen. Beispielsweise erhält eine Person nicht mehr zwei Attribute für die private und die berufliche E-Mail-Adresse, sondern Referenzen zu zwei E-Mail Objekten getaggt mit privat bzw. beruflich. Ein E-Mail Objekt lässt sich dann beispielsweise noch facebook taggen um so deren Verwendung auszuzeichnen. Dieses Verfahren wird auf alle Objekte des Datenmodells angewandt und erlaubt sehr flexible Such- und Filtermethoden und ermöglicht dadurch letztlich eine nutzungsoffene Verwendung der Integrationslösung.

Anwendungskomponenten

Mit der aus dem Datenmodell hervorgehend Abbildungsvorschrift, die es erlaubt Daten aus sozialen Diensten zu vereinheitlichen und miteinander zu verbinden, stellt sich die Frage, welche Teile einer konkreten Anwendung direkt vom vorliegenden Datenmodell abängen und somit ebenfalls automatisch aus dem Modell generiert werden können. Um eine nachhaltige und erweiterbare Lösung zu ermöglichen, ist es quasi ein Muss, dass alle diese direkt ableitbaren Teile automatisch bzw. zumindest semi-automatisch generiert werden. Die folgende Grafik gibt einen Überblick über die für das CommunityMashup relevanten, automatisch generierbaren Anwendungskomponenten:
[singlepic id=604 w=618 float=center]

Viele UML-Werkzeuge unterstützen mittlerweile die automatische Erzeugung einer (Java) Schnittstelle mit zugehörigen leeren Klassen und Methoden. Für eine durchgängige Lösung wird allerdings ausführbare Code mit einer Laufzeitumgebung (RunTime) benötigt. Diese kümmert sich beispielsweise um die Erzeugung von Objekten bzw. um die Bereitstellung von Methoden zur Manipulation solcher Instanzen. Ein zusätzlicher Event-Mechanismus erlaubt das Verfolgen dieser Änderungen. Eine weitere wichtige Anwendungskomponente stellt die Persistierung dar. Diese wird beispielsweise für Caching benötigt. Für die Persistierung von Daten ist eine Serialisierung und Deserialisierung der Objekte notwendig. Diese wird ebenfalls für den Datenaustaustausch über Web-Schnittstellen im XML-Format benötigt. Im Rahmen des CommunityMashup-Projektes wird aktuell eine durchgängige Werkzeugkette aufgebaut, die die automatische Erstellung dieser Komponenten ermöglicht. Wir wenden den gleichen modellgetrieben Ansatz auch auf ein Meta-Modell an, das die möglichen Konfigurationen des CommunityMashup beschreibt. Hierfür werden viele identische Komponenten benötigt, allerdings jeweils bezogen auf ein anderes Modell. Die Verwendung des Meta-Modells erlaubt es, Konfigurationen speichern und laden zu lassen (Persitierung) und beispielsweise aus Gründen der Fernwartung auch über eine Web-Schnittstelle abfragen und verändern zu lassen.

Service-Orientierte-Architektur

Alleine durch die oben beschrieben, aus einem Modell erzeugbaren Komponenten lässt sich noch keine gesamte Integrationslösung erstellen. Ziel des CommunityMashups ist nicht nur ein flexibles Entwicklungskonzept das durch den modellgetriebenen Ansatz erreicht wird, sondern auch eine flexible Systemarchitektur die aufgrund von Anforderungen wie Skalierbarkeit, Performance und Ausfallsicherheit eine Verteilung von Systemkomponenten zulässt. Diese Service-Orientierte-Architektur, muss sich dadurch auszeichnen, dass definierte Systemkomponenten als eigenständige Services mit definierten Schnittstellen realisiert werden. So lassen sich selbst zur Laufzeit einzelne Komponenten aktualisieren bzw. austauschen ohne die Verfügbarkeit des Gesamtsystems zu beeinflussen. Nachfolgende Abbildung zeigt ein exemplarisches verteiltes Szenario mit Client- und Server Komponenten.
[singlepic id=601 w=618 float=center]

Die Verbindung der Daten aus den eizelnen Quelldiensten (Source 1 bis Source n) wird auf einem Server durchgeführt und durch eine Konfiguration gesteuert. Jede dieser Quellkomponenten wird als eigener Service realisiert, der sich sich einzeln aktualiseren lässt, beispielsweise um auf die Änderung einer entfernten Schnittstelle zu reagieren.Java Intern überführen die dargestellten Quellkomponenten Daten der externen Dienste in das dem personenzentrische CommunityMashup-Datenmodell und tragen diese hierdurch sukzessive zu einem gemeinsamen Datensatz zusammen. Die zentrale CommunityMashup-Komponente stellt diesen Datensatz (ggf. je nach Bedarf gefiltert) wieder über eine Java Schnittstelle bereit. Darauf aufbauend lässt sich eine REST Schnittstelle hinzufügen, die die aggregierten und gefilterten Daten (zugriffsbeschränkt) über das Web verfügbar macht. Spezielle Anwendungskomponenten lassen nun eine Verwendung der Daten auf Client-Seite über eine identische Java API zu. Die je nach Client-Typ (im oben abgebildeten Beispiel eine klassische Desktop Anwendung in Kombination mit einem Android Mobile Device) speziell ausgeprägten Anwendungskomponenten kümmern sich im Hintergrund transparent um den Datenaustausch und verlagern je nach Client rechenintensive Aufgaben auf den Server.

CommunityMashup REST-Schnittstelle

[toc] Das CommunityMashup stellt Anwendungen eine auf Web2.0-Inhalte spezialisierte und auf einem personenzentrischen Datenmodell basierende Datenbasis zur Verfügung. Um Anwendern/Entwicklern generische Zugriffsmöglichkeiten auf diese Datenbasis zu ermöglichen, wurde im Rahmen einer Masterarbeit eine REST-Schnittstelle für das CommunityMashup entwickelt, die nachfolgend kurz vorgestellt wird

Problemstellung

Zu Beginn der Entwicklung des CommunityMashups wurde der Zugriff auf die Daten des Frameworks lediglich über eine Java-Schnittstelle ermöglicht, d.h. eine es nutzende Anwendung musste in Java implementiert sein und auf der gleichen Maschine wie das CommunityMashup laufen.Eine auf verschiedene Geräte oder Architekturen verteilte Nutzung wurde somit starkt erschwert (vgl. Abbildung links).

[singlepic id=582 h=270 float=left] [singlepic id=583 h=270 float=left]

Um diesem Problem zu begegnen, wurde das CommunityMashup im Rahmen einer Masterarbeit um eine REST-Schnittstelle erweitert. Mit Hilfe dieser Schnittstelle können verschiedenste Arten von Anwendungen (z.B. normale Anwendungen, Smartphone-Apps oder Widgets) auf unterschiedlichen Geräten auf die Daten eines oder mehrerer CommunityMashups zugreifen und diese verwenden sowie manipulieren (vgl. Abbildung rechts).

Verwendung der Schnittstelle

Die Schnittstelle kann prinzipiell von jeder Anwendung verwendet werden, die entsprechend der Schnittstellen-Dokumentation erstellt/konfiguriert wurde:

[singlepic id=581 w=518]

Da die Kommunikation mit der REST-Schnittstelle über das HTTP-Protokoll und damit potentiell dem gesamten Internet geschehen kann, ist die Anwendungsentwicklung sowohl was den Ort als auch die Architektur des Zielsystems betrifft vom CommunityMashup unabhängig.

Die REST-Schnittstelle wird vom CommunityMashup in Form eines Java-Servlets bereitgestellt, welches ebenfalls die Dokumentation der Schnittstelle enthält.

Beide können über die URL des CommunityMashup-REST-Services erreicht werden, der eine selbsterklärende Beschreibung der angebotenen Dienste bereithält. Unter anderem kann die Syntax der REST-Anfragen nachgeschlagen werden und die Anfragen können im Browser getestet werden, was bei der Entwicklung kompatibler Anwendungen hilft.

[singlepic id=595 w=618 float=center]

[singlepic id=584 w=618 float=center]

Technische Umsetzung

Um die REST-Schnittstelle mit der modellgetriebenen Entwicklung des CommunityMashups[ref]Vgl. https://soziotech.org/communitymashup/model-driven-approach/.[/ref] im Einklang zu halten, werden die dynamischen (vom Datenmodell des CommunityMashups anhängigen) Methoden und Funktionen mit Hilfe angepasster JET-Templates automatisch aus dem Modell generiert, was eine spätere manuelle Anpassung der Schnittstelle an Änderungen des CommunityMashups überflüssig macht:

[singlepic id=589 w=618 float=center]

Um den unauthorisierten Zugriff auf das CommunityMashup einzuschränken, wurde ein Sicherheitssystem entwickelt, das nur registrierten Anwendungen den Zugriff auf die Daten und Funktionen des CommunityMashups gestattet. Die Absicherung der REST-Anfragen geschieht durch eine Signatur, welche die Anfrage vor einer Manipulation schützt und den Absender der Anfrage eindeutig identifiziert.

Sicherheitssystem der Schnittstelle

Die Sicherheit der Daten des CommunityMashups wird durch die Verwendung sogenannter Message Authentication Codes (MAC) sichergestellt, welche auch bei anderen (REST)-Schnittstellen namhafter Online-Dienstanbieter wie Amazon, GoogleMaps oder Flickr verwendet wird. Dabeiwird neben der eigentlichen Anfrage der Hashcode der Anfrage und eines geheimen Schlüssels übermittelt, wodurch zum einen die Integrität der Nachricht und zum anderen die Identität des Absenders sichergestellt sind.

REST-Zugriff

Die folgenden Prozessdiagramme liefern einen kurzen Überblick über die Zugriffsmöglichkeiten auf das CommunityMashup über die REST-Schnittstelle, darunter auch über den Ablauf einer gesicherten REST-Anfrage:

[nggtags gallery=REST+Zugriff]

Howto – Touchscreen Komponenten mit JavaFX und Adobe Illustrator

In diesem Howto wird gezeigt wie Interaktionskomponenten für Touchscreen Systeme mit Adobe Illustrator erstellt werden können, um diese mittels JavaFX interaktiv in einer GUI einzubinden. Dies geschieht exemplarisch anhand des in einer Bachelorarbeit entwickelten GUI-Entwurfs für ein Fussgänger-Navigationssystems der UnibwM. „Howto – Touchscreen Komponenten mit JavaFX und Adobe Illustrator“ weiterlesen

Touchscreen-basiertes Campus-Navigationssystem für die Universität der Bundeswehr München

[toc]Dieser Artikel beschreibt die wesentlichen Ergebnisse der Bachelorarbeit „Konzeption und Umsetzung eines Touchscreen-basierten Campus-Navigationssystems für die Universität der Bundeswehr München“ von Markus Schran. Ziel der Bachelorarbeit war die Konzeption und prototypische Umsetzung eines stationären Navigationssystems auf einem Outdoor-Kiosk-Terminal. Hierzu wurde zunächst zur Verfügung stehendes Kartenmaterial gesammelt und anwendungsspezifisch bewertet. Anschließend wurde der Besucherverkehr der Universität über mehrerer Tage protokolliert, bevor verschiedene Umsetzungsmöglichkeiten im Bezug auf Programmiersprache und Software Entwicklungstools gegeneinander abgewogen werden konnten. Das Ziel der praktischen Arbeit bestand darin, ein benutzerfreundliches und übersichtliches Programm für das touchscreen-basierte Terminal  zu programmieren. Neben den Grundfunktionen des Programms befasste sich die Arbeit vor allem mit späteren Weiterentwicklungsmöglichkeiten. Nach einer kurzen Einführung in die grundlegende Problematik werden in diesem Artikel die wichtigsten Schritte der Arbeit sowie die erzeugten Artefakte vorgestellt.

„Touchscreen-basiertes Campus-Navigationssystem für die Universität der Bundeswehr München“ weiterlesen