Partitionierung mobiler Anwendungen

5.3. Identifikation von Teilproblemen und Lösungsansätzen 147

Implikationen für diese Arbeit Zusammenfassend gilt es dementsprechend bei der Implementierung von Profiling-Mechanismen zu berücksichtigen, dass der begrenzte Energie- und Bandbreitenbedarf mobiler Geräte durch das Pro-filing nicht zu stark beansprucht wird und dass dieser Einfluss möglichst dem Profiling selbst zugeordnet werden kann. Im Hinblick auf die in dieser Arbeit untersuchte Fragestellung der kontextadaptiven Ausführung existieren eine Reihe weiterer Kontextattribute, die auch den das Gerät umgebenden Kontext beschreiben und die relevant für eine entsprechende Adaption sein können.

Diese werden jedoch erst im Zusammenhang mit der Entwicklung kontextad-aptiven Verhaltens untersucht werden, da diese Informationen eher periodisch und nicht wie im Profiling nutzungsbezogen im Zusammenhang mit einer be-stimmten Anwendung ermittelt werden.

Nach [LAS⁺15] gilt es, bei der Partitionierung von Anwendungen im mobilen Cloud Computing, die folgenden Anforderungen zu unterstützen:

Die Umsetzung unterschiedlicher Adaptionsziele: wie die Beschleuni-gung der Ausführung oder die Erweiterung der Ressourcen (zum Beispiel Speicher oder Energie) eines mobilen Gerätes.

Die Unterstützung mehrerer Surrogates (multi-site offloading).

Benutzbarkeit des Partitionierungsverfahrens: Der zusätzliche Aufwand für den Entwickler sollte möglichst gering sein.

Adaption zur Laufzeit: Die Anpassung der Partitionierung sollte zur Laufzeit einer mobilen Anwendung erfolgen können.

5.3.4.2. Durchführung der Partitionierung

Zur Durchführung einer Partitionierung ist es zunächst erforderlich, eine ent-sprechende Granularität der Adaption (vergleiche Abschnitt 5.2.6) für die ein-zelnen Einheiten einer mobilen Anwendung auszuwählen. Anschließend kann unter Berücksichtigung des oder der gewünschten Ziele der Adaption (verglei-che Abschnitt 5.2.3) eine Partitionierung erfolgen.

Dabei ist es erforderlich, diese Einheiten um weitere Informationen zu er-gänzen, die beschreiben, auf welchen Surrogates diese Teile der Geschäftslo-gik unter welchen Umständen ausgeführt werden können. Beispielsweise gilt es, zu entscheiden, ob bestimmte Teile der Geschäftslogik überhaupt in die In-frastruktur verlagert werden können, weil diese spezifische Funktionen oder Hardware des mobilen Gerätes nutzen. Ein einfaches Verfahren findet sich bei-spielsweise in [SSSL12], bei welchem auf Basis der von den Entwicklern defi-nierten Java-basierten Annotationen festgelegt wird, welche Teile einer mo-bilen Anwendung überhaupt für eine Migration in die Infrastruktur infrage kommen, bevor die verbleibende Geschäftslogik partitioniert wird.

In diesem Zusammenhang ist anzumerken, dass ein Großteil der verwand-ten Arbeiverwand-ten sich in diesem Aspekt auf eine binäre Partitionierung beschränkt und entsprechend lediglich ein (spezifisches) Surrogate bei der Auslagerung von Funktionalität unterstützt wird. Eine Restriktion, die im Verlauf dieser Arbeit noch gesondert und die entsprechend an dieser Stelle ebenso nicht nä-her betrachtet wird.

Das Ziel der Partitionierung ist es entsprechend, die Geschäftslogik so zwi-schen einem mobilen Gerät und einem Surrogate aufzuteilen, dass ein oder mehrere Adaptionsziele möglichst gut erreicht werden können. Um beispiels-weise die Ausführungszeit zu minimieren, gilt es häufig, den Teil des Kontroll-flusses zu identifizieren und als eine Partition zu markieren, der effizient auf ein Surrogate übertragen und dort ausgeführt werden kann. Die Effizienz wird dabei anhand entstehender Kosten, wie beispielsweise der nötigen Bandbreite, beurteilt, die für die Übertragung des Zustands zwischen dem mobilen Gerät und einem Surrogate entstehen.

5.3. Identifikation von Teilproblemen und Lösungsansätzen 149

Bezüglich der Durchführung dieser Partitionierung lassen sich nach [LAS⁺15] drei Gruppen von Verfahren unterscheiden, nach denen eine Par-titionierung durchgeführt werden kann: die Gruppe der graph-basierten Ver-fahren, die Gruppe der VerVer-fahren, die auf linearer Programmierung basieren, und hybride Verfahren, die eine Kombination der beiden zuvorgenannten An-sätze verwenden. Im Folgenden sollen die unterschiedlichen Verfahren jeweils kurz beschrieben werden:

Graph-basierte Verfahren Häufig erfolgt die Ermittlung einzelner Partitio-nen einer mobilen Anwendung auf Basis eines Graphen. Die Knoten des Gra-phen repräsentieren dabei die einzelnen Einheiten einer mobilen Anwendung und seine Kanten die Abhängigkeiten, die im Hinblick auf das jeweilige Ziel der Adaption relevant sind. Hierbei handelt es sich um Informationen wie die Menge der durchschnittlich ausgetauschten Daten zwischen zwei Partitionen, die Frequenz der jeweiligen wechselseitigen Aufrufe, den Daten- oder Kontroll-fluss oder zu die zu erwartenden Wartezeiten, die sich beim Aufruf zwischen Komponenten ergeben.

Zur Nutzung dieser Verfahren gilt es zunächst, die Einheiten der Geschäfts-logik, beispielsweise Komponenten, einer mobilen Anwendung und ihre Inter-aktion untereinander zu beschreiben. Dieser Zusammhang kann, angelehnt an [KNP15], als ein ungerichteter GraphM, bestehend aus einer Menge von Kom-ponenten (N) einer mobilen Anwendung und einer Menge von Verbindungen (E) zwischen diesen Komponenten, beschrieben werden, die wie folgt definiert sind:

M = (N, E, c_m, c_c, c_t, t_m, t_c, t_t) (5.1) E⊆ {{ni, nj}:ni∈N∧nj∈N∧ni=nj} (5.2) c_m:N →R, c_c:N →R, c_t:E→R (5.3) t_m:N →R, t_c:N →R, t_t:E→R (5.4) Für einen Knoten (das heißt eine Komponente) n ∈ N sind dabei folgende vier Gewichtsfunktionen definiert:

t_m(n)entspricht ihrer Ausführungszeit auf dem mobilen Gerät, t_c(n)entspricht ihrer Ausführungszeit auf dem Surrogate,

c_m(n)entspricht ihrer Ausführungskosten auf dem mobilen Gerät, c_c(n)entspricht ihrer Ausführungskosten auf dem Surrogate.

Für eine Kante e ∈ E sind darüber hinaus zwei Gewichtsfunktionen defi-niert:

t_t(e)entspricht der Zeit für die Synchronisation des für den Aufruf einer Komponente erforderlichen Zustands (state) zwischen dem mobilen Gerät und dem Surrogate,

c_t(e)entspricht den Kosten für die Synchronisation dieses Zustands (bei-spielsweise der erforderlichen Bandbreite) zwischen dem mobilen Gerät und dem Surrogate.

Hierbei sind allerdings die Kosten für die Übertragung des Zustands zwi-schen zwei Komponenten auf demselben Gerät (mobil oder Surrogate) zu ver-nachlässigen. Entsprechend lassen sich für eine Teilmenge von Komponenten auf dem mobilen Gerät (N_m) und eine zweite Teilmenge auf einem Surrogate (N_c) die Kosten der Auslagerung wie folgt ermitteln:

N_c ⊂N, N_m=N\N_c (5.5)

E_t={{n_c, n_m}:{n_c, n_m} ∈E∧n_c∈N_c∧n_m∈N_m} (5.6) c=α

n∈N_c

c_c(n) +β

n∈N_m

c_m(n) +γ

e∈E_t

c_t(e) (5.7)

Die Koeffizienten α, β und γ definieren dabei die Gewichtung der einzel-nen Größen, aus deeinzel-nen sich die für das jeweilige Ziel der Adaption relevanten Kosten ergeben. Tabelle 5.3 zeigt hierzu exemplarisch die unterschiedlichen Gewichtungen dieser Koeffizienten, die sich im Hinblick auf das jeweilige Ad-aptionsziel ergeben. Beispielsweise wird eine Einsparung von Energie auf dem mobilen Gerät dadurch realisiert, dass der Parameter β, verantwortlich für die Gewichtung der Ausführungskosten (in diesem Fall die Energie) auf dem mobilen Gerät, maximiert wird.

Optimierungsziel α β γ

Einsparung von Energie (mobil) 0 1 0

Einsparung von Bandbreite 0 0 1

Kombinierte Einsparung 0,4 0,3 0,3

Tabelle 5.3.:Exemplarische Gewichtung im Hinblick auf das jeweilige Adaptionsziel

Diese graph-basierte Modellierung ermöglicht es, ein Optimierungsproblem zu formulieren. Beispielsweise lässt sich so die Teilmenge von Komponenten finden, die in der Infrastruktur ausgeführt werden kann, während die Ausfüh-rungszeit unterhalb eines bestimmten Maximumst_maxgehalten wird:

N_cmin∈P(N)α

n∈N_c

c_c(n) +β

n∈N_m

c_m(n) +γ

e∈E_t

c_t(e) (5.8)

Wobei P(N) die Potenzmenge der Knotenmenge N darstellt. Der Schwell-wertt≤t_maxkann dabei beispielsweise auf die durchschnittliche Ausführungs-zeit der jeweiligen Anwendung auf dem mobilen Gerät gesetzt werden, um zu verhindern, dass es zu einer subjektiven Einschränkung der Dienstqualität kommt.

5.3. Identifikation von Teilproblemen und Lösungsansätzen 151

Alternativ lassen sich die (gewichteten) Kosten auch nicht nur, wie in Gleichung 5.7 definiert wurde, kollektiv betrachten, sondern auch pro Kante des definierten Abhängigkeitsgraphen, um eine rein graph-basierte Trennung durchzuführen. In diesem Zusammenhang hat sich die Anwendung des MIN-CUT-Algorithmus [SW97] zur binären Partitionierung als nützlich erwiesen, um entweder die Interaktion zwischen den so entstehenden Partitionen der mobilen Anwendung zu optimieren [CM10] oder unter Berücksichtigung eines Adaptionsziels jeweils die Modellierung des hierbei entstehenden Abhängig-keitsgraphen dieser mobilen Anwendung zu konkretisieren, wie es in einer Reihe verwandter Arbeiten vorgeschlagen wurde [OYL06, OYZ07, GNM⁺03, MGB⁺02,WKWS16].

Nach [LAS⁺15] kann ein solches graph-basiertes Modell, unabhängig davon, ob es grob- oder feingranular ist, einen effizienten Weg zur Partitionierung einer mobilen Anwendung darstellen und soll entsprechend näher vorgestellt werden.

Partitionierung auf Basis linearer Programmierung Lineare Programmie-rung stellt ein etabliertes Verfahren dar, um OptimieProgrammie-rungsprobleme, zum Bei-spiel die Minimierung der Ausführungszeit im mobilen Cloud Computing, zu lösen. Hierzu existiert eine Zielfunktion, deren Ergebnis es zu maximieren bzw.

minimieren gilt. In [KCK11] wird diese Modellierung als Optimierungspro-blem mit den in Bezug auf das jeweilige Ziel der Adaption relevanten Para-metern gezeigt. Diese Gruppe von Verfahren liefert so zwar immer ein optima-les Ergebnis für eine bestimmte Zielfunktion, nach [LAS⁺15] verhindert der damit einhergehende hohe Berechnungsoverhead allerdings oft die praktische Nutzbarkeit dieser Verfahren in ihrer reinen Form.

Hybride Verfahren zur Partitionierung Hybride Verfahren kombinieren die beiden zuvor genannten Konzepte. So wird unter anderem in [CBC⁺10] zu-nächst mithilfe eines Profilings ein Aufrufgraph zwischen den einzelnen Me-thoden einer mobilen Anwendung erstellt, um hierauf basierend im Anschluss ein Optimierungsproblem zu lösen. Als effizienteste Variante dieser Katego-rie von Partitionierungsverfahren wird in [LAS⁺15] die Kombination einer ganzzahligen linearen Optimierung mit einer graph-basierten Abbildung des Datenflusses einer mobilen Anwendung angesehen, wie sie beispielsweise in [GRJ⁺09] umgesetzt ist.

5.3.4.3. Weitere Unterscheidungsmerkmale von Partitionierungsverfahren Die verschiedenen Verfahren zur Partitionierung einer mobilen Anwendung können weitergehend darin unterschieden werden, ob sie die Partitionierung statisch oder dynamisch durchführen [LAS⁺15]. Die statische Partitionierung, wie sie beispielsweise in [CIM⁺11,SSSL12, NTG⁺09,BGSH07] Verwendung findet, stützt sich dabei auf eine Analyse des Quellcodes oder des Bytecodes einer bereits kompilierten Anwendung. Die dynamische Partitionierung

hinge-gen nutzt zur Analyse das in Abschnitt 5.3.3 beschriebene Software-Profiling und untersucht das Laufzeitverhalten, um Rückschlüsse auf eine sinnvolle Aufteilung der Geschäftslogik im Hinblick auf die vorgegebenen Adaptions-ziele zu ermitteln.

Im Weiteren können Partitionierungsverfahren nach [LAS⁺15] auch danach unterteilt werden, ob sie das Profiling vollständig automatisiert durchführen oder ob sie entsprechende Hinweise des Entwicklers in Form von Annotatio-nen berücksichtigen. Letztere Variante kann díe Ermittlung der Partitionie-rung deutlich vereinfachen, da beispielsweise Teile der Geschäftslogik, die aus Wahrnehmung der Nutzer für eine nahtlose und verzögerungsfreie Ausfüh-rung der Anwendung verantwortlich sind, nicht in die Infrastruktur verlagert werden. Ein Kriterium, das mithilfe eines vollautomatisierten Profilings nur schwer ermittelt werden kann.

5.3.4.4. Implikationen für diese Arbeit

Im Hinblick auf die Realisierung einer kontextadaptiven Anwendungsarchi-tektur sollen ebenfalls auf Basis eines Software-Profilings zunächst die Ab-hängigkeiten zwischen den einzelnen Komponenten, die als Granularität für die Adaption ausgewählt wurden, und den von ihnen bereitgestellten Diensten ermittelt werden.

Abweichend zu den gezeigten Verfahren soll anschließend jedoch zweistufig vorgegangen werden: In einem ersten Schritt soll im Hinblick auf das jeweilige Adaptionsziel eine Unterteilung in lokal und in entfernt ausführbare Teile der Geschäftslogik erfolgen, wie es bereits erfolgreich in verschiedenen existieren-den Arbeiten umgesetzt wurde [GNM⁺03, MGB⁺02, OYH07]. Entsprechend existiert für jedes zu unterstützende Adaptionsziel jeweils eine Partitionierung der mobilen Anwendung. Diese wird genutzt, um die einzelnen Komponenten auf dem mobilen Gerät und seinem Surrogate entsprechend zu starten. Hierbei wird jedoch versucht, die auf dem Surrogate zu startenden Komponenten eben-falls auf dem mobilen Gerät zu starten, sofern hierfür ausreichend Ressourcen vorhanden sind. Dies dient der Vorbereitung des zweiten Schrittes.

Um angemessen auf den aktuellen Kontext reagieren zu können, erfolgt an-schließend im zweiten Schritt jedoch eine kontextabhängige Entscheidung, die sich ebenfalls an den unterschiedlichen Zielen der Adaption orientiert. Hier-zu werden auf dem mobilen Gerät und den verfügbaren Surrogates die jeweils übrigen, also die der jeweils anderen Partition zugehörigen, Komponenten der mobilen Anwendung gestartet. Dies dient dazu, abhängig von Kontextattribu-ten wie der verfügbaren Bandbreite und der Art des jeweiligen Tasks in Bezug auf das entsprechende Ziel der Adaption zu entscheiden, ob der Aufruf einer Komponente auf die lokale oder die auf dem Surrogate vorhandene Instanz weitergeleitet wird. Mithilfe dieses Ansatzes soll die Komplexität der Parti-tionierung und der darauf aufbauenden Auslagerungsentscheidung möglichst effizient gelöst und trotzdem den formulierten Anforderungen der spontanen Interaktion angemessen gerecht werden.

5.4. Konzeption einer adaptiven Architektur und Systemunterstützung 153

5.4. Konzeption einer adaptiven Architektur und