Architekturmuster im Umfeld mobiler Anwendungen

1 Architekturmuster im Umfeld mobiler Anwendungen D. Geppert Hochschule Offenburg Seminar Neue Technologien Badstraße 24, 77652, Offenburg 2011 Abstract Im Umfeld mobiler Anwendungen entstehen ständig neue Anforderungen an die Architekturen der Software. Mit den bereits bekannten Mustern ist es nicht weiter möglich die aktuellen Belange der Softwareentwicklung ausreichend abzudecken. Dies macht es erforderlich neue Architekturen für die Entwicklung im Umfeld mobiler Anwendungen einzusetzen. Die neuen Applikationen im Bereich des mobilen Sektors, können den Erwartungen mit aktuell vorhanden Architekturen nicht gerecht werden. Um dieser Problematik entgegen zu wirken, wurden bestehende Muster wie das bewährte Client/Server oder Broker Prinzip angepasst und in das mobile Umfeld übernommen. Gleichzeitig entstehen jedoch auch neue Architekturen wie zum Beispiel der Einsatz von mobilen Programmierschnittstellen oder temporären Peer-to-Peer Netzwerken. I. EINLEITUNG Ein Architekturmuster spiegelt die Unterteilung eines Softwaresystems in Komponenten auf oberster Ebene wieder und stellt deren Interaktion untereinander dar. Dies beschreibt die Grundstruktur einer komplexen Anwendung, während Entwurfsmuster mehr Beschreibungsmuster für jene Probleme sind, die unmittelbar bei der Implementierungsphase auftreten und sich daher nur auf einzelne Teilaspekte beziehen [Eri94]. Beide Arten von Mustern versuchen in ihren Ansätzen bestehende Entwurfsprobleme durch bereits bewährte Vorgehensweisen zu lösen, soweit dies der gegebene Kontext zulässt. Das Ziel ist, am Ende ein Softwaresystem zu erhalten, das wartbar, übersichtlich, testbar und wiederverwendbar ist. Hierbei ist stets nach Situation abzuwägen, ob es sinnvoll ist, ein solches Muster einzusetzen, da diese in den meisten Fällen Seiteneffekte mit sich bringen. Das können unter anderem eine längere Laufzeit, größere Komplexität, höherer Speicherbedarf oder zusätzlicher Kommunikationsaufwand sein [Mar02]. II. BASIS-MUSTER Die sogenannten Basis-Muster sind später in anderen Mustern wieder anzutreffen, da sie auch in verteilten Systemen den Grundaufbau der einzelnen Komponenten definieren. Diese grundlegenden Architekturmuster, welche in den meisten Anwendungen aufzufinden sind, lassen sich dabei in folgende grundlegende Bereiche unterteilen. A. Schichten-Architektur Eine Schichten-Architektur verfolgt das Ziel, komplexe Anwendungen in logische Schichten aufzuteilen. Die Komponenten einer Anwendung werden hierbei übereinander angeordnet.

2 Die Kommunikation zwischen den Schichten erfolgt ausschließlich über die zuvor definierten Schnittstellen [Ste08]. Jede Komponente darf nur auf Komponenten der gleichen beziehungsweise einer darunter liegenden Schicht zugreifen. Die überwiegende Mehrheit aller Anwendungen ist nach dem Prinzip einer Schichten- Architektur aufgebaut. Nachfolgend wird auf die verschiedenen Aufteilungsmöglichkeiten der einzelnen Komponenten (Präsentationsebene, Geschäftsebene und Datenebene) näher eingegangen. 1) Ein-Schicht-Architektur: Alle drei Ebenen werden in einer einzelnen Komponente zusammengefasst. Dies ermöglicht eine zentrale Administration. Bei größeren Anwendungen ist der Einsatz jedoch nicht gebräuchlich, da keine Schnittstellen definiert sind und die Wartung sich auf Grund der Komplexität schwierig gestaltet. 2) Zwei-Schicht-Architektur: Es findet eine Aufteilung zwischen Präsentations- /Geschäftsebene und Datenebene statt. Bedingt dadurch, dass stets nur eine darüber liegende Schicht auf eine darunter liegende zugreift, fungiert die Datenebene (zum Beispiel ein SQL Server) als Dienstanbieter und die darüber liegende Schicht als Client. Die Daten liegen bei dieser Architektur zwar zentral vor, jedoch befinden sich die Datenbankregeln auf dem Client. Eine Änderung der Datenbanklogik müsste daher an jedem Client gleichermaßen vollzogen werden, was bei größeren Strukturen zu erheblichem Aufwand führen kann. 3) Drei-Schichten-Architektur: Komplexe Anwendungen bestehen in den meisten Fällen aus einer Drei-Schichten-Architektur. Hierbei wird die Verarbeitungslogik des Anwendungssystems laut [Jör03] einer separaten Schicht zugeordnet. Die Präsentations-/Geschäftsebene wird aufgeteilt um eine Logikschicht (Bussiness Layer wie in Abbildung 1) zwischen Präsentationsebene und Datenebene zu platzieren. Jede Komponente besitzt nun eine eigene Schicht. Oft werden einzelne Teile auch redundant ausgelegt um die Performance zu steigern und / oder die Ausfallsicherheit zu erhöhen. Die Wartbarkeit der Anwendung steigt, da zentrale Änderungen an der Datenbanklogik möglich sind. Die verschiedenen Schichten sind voneinander getrennt, was einen modularen Aufbau ermöglicht. Durch die lose Architektur ist die Präsentationsebene von der Anwendungsebene, die Anwendungsebene von der Datenbankverwaltungsebene entkoppelt und erfüllt nach [Mic06] folgende Rahmenbedingungen: Integration unterschiedlicher Systemkomponenten, Fusion unterschiedlicher Plattformen, Vereinigung verschiedener Protokolle, hohe Skalierbarkeit des Gesamtsystems (sehr große Anzahl von Clients, sehr hohe Datenübertragungsrate), technische und dienstliche Interoperabilität, hohe Flexibilität und Dynamik (Austausch bzw. Erweiterung der Schichten- Architektur), hohe Performance beim Anfrage/Antwort- Verhalten. Fig. 1. Aufbau einer Drei-Schichten-Architektur 4) Mehrschichten-Architektur: Zu den oben beschriebenen Architekturmustern existieren noch weitere, seltener verbreitete Modelle, die sich im Alltag weniger durchgesetzt haben. In [Kyl01] werden zwei mögliche Bindeschichten der Drei-Schichten-Architektur beschrieben: Die Controllerschicht zwischen der Präsentations- und Anwendungsschicht beinhaltet die für die Präsentation erforderlichen Kontrollstrukturen. Die Data- Mapping-Schicht zwischen der Anwendungsund der Datenschicht enthält die Funktionen zum Abbilden der objektorientierten Daten der Anwendungsschicht auf die relationalen Daten der Datenschicht. [Dee03] teilt hingegen die Präsentationsschicht in zwei weitere Schichten auf. Die Client-Präsentation-Schicht, in der die Präsen-

3 tation auf dem Client berechnet wird (zum Beispiel die Ausgabe mittels Javascript), und die serverseitige Präsentationsschicht, in der die auf dem Server erstellte Ausgabe für den Client generiert wird (zum Beispiel HTML Generatoren). 5) Architekturauswahl: Um die Richtige Architektur für ein Softwareprojekt auszuwählen bedarf es der Beachtung einiger grundlegender Punkte, welche nachfolgend kurz zusammengefasst werden. Je komplexer die Anwendung ist, desto mehr Schichten sollten verwendet werden, da die Anwendung so in mehrere Teile zerlegt werden kann. Umso mehr Schichten verwendet werden, desto besser ist die Anwendung wartbar, weil es einfacher wird, Ressourcen durch andere zu ersetzen oder Änderungen an einzelnen Teilen vorzunehmen. Sollten einige Module der Software an einer anderen Stelle wiederverwendet werden, ist es vorteilhaft mehrere Schichten zu verwenden, da diese einfacher ausgetauscht werden können. Hat das Projekt einen engen Zeitplan, sollten hingegen weniger Schichten verwendet werden, da bereits in der der Planungsphase ein deutlich höherer Mehraufwand entsteht. B. Pipes und Filter-Architektur Bei diesem Architekturmuster besteht die Anwendung aus Filtern und Pipes, welche das System in mehrere verschiedene Stufen unterteilen. Jeder verarbeitende Schritt wird durch eine Filterkomponente abgebildet. Daten zwischen zwei benachbarten Filtern werden mittels Pipes transportiert. Die Filter beschreiben die aktiven Komponenten dieser Architektur und übernehmen einzelne Teilaufgaben. Ein solcher Filter nimmt Nachrichten über die Eingangsschnittstelle an, ergänzt, verfeinert, transformiert oder bearbeitet diese [Tho10]. Über die Ausgangsschnittstelle wird die verarbeitete Nachricht an eine darauf folgende Pipe weitergegeben. Ein Filter muss im Vergleich mit einer Pipe nicht zu jeder Eingabe eine Ausgabe erzeugen. Pipes bilden die Verbindung zwischen Filtern und nehmen daher nur eine passive Rolle in dieser Architektur ein [Tho10]. Jede Pipe bezieht ihre Eingaben von dem davor liegenden Filter und leitet ihre Ausgaben an den darauf folgenden weiter. Ihre Hauptaufgabe besteht lediglich darin, Nachrichten zwischen unterschiedlichen Filtern zu transportieren. 1) Compiler-Architektur: Die Architektur eines Compilers lässt sich zum Beispiel als Pipe/Filter organisieren, bei der aufeinanderfolgend Scanner, Parser, Code-Generator usw. durchlaufen werden. Dabei ist in Abbildung 2 zu sehen, dass die Gesamtaufgabe in mehrere Teilaufgaben zerlegt wird. Jede Phase ist in ihrer eigenen Komponente zu finden, die dann wiederrum eine definierte Aufgabe durchführt. Die erste Komponente erhält aus der Pipe den Sourcecode und überführt ihn in eine compilerinterne abstrakte Syntax. Der Parser kann danach beispielsweise interne Optimierungen durchführen und übergibt das Ergebnis schließlich durch die Pipe zum Codegenerator, der nach der Generierung des Codes diesen ebenfalls weiter leitet. Fig. 2. Compiler Beispiel Architekturmuster Pipe / Filter am 2) UNIX-Verkettung-Architektur: Ein weiterer Architekturansatz stellt die UNIX- Verkettung von Befehlen in einer Pipe dar. Das Listing 1 zeigt wie eine komplexe Aufgabe in eine Sequenz von Unteraufgaben zerlegt wird. Jeder Filter arbeitet hier mit den Ausgabedaten des davor liegenden. Im aktuellen Beispiel bedeutet dies, dass mittels dem ls (List) Filter alle Dateien vom aktuellen Verzeichnis mit der Endung txt ausgewählt werden und über eine Pipe zum darauf folgenden Filter wc (WordCount) gelangen. Dieser zählt die Häufigkeit der ihm übergebenen Wörter und leitet diese an den nächsten Filter weiter. In diesem Beispiel ist das die Konsole, welche eine Ausgabe erzeugt. l s. t x t wc l Listing 1: Beispiel: Pipe/Filter-Architektur unter UNIX Speziell beim Einsatz der Unix-Verkettung ist laut [Uwe98] darauf zu achten, dass

4 definierte Datenformate eingesetzt werden, da diese Filter häufig in einer Toolbox zum Einsatz kommen. Ein einheitliches Datenformat (UNIX ASCII), liefert einen hohen Grad an Flexibilität beim späteren Einsatz, da die Filter so in verschiedener Art und Weise miteinander kombiniert werden können. III. VERTEILTE MUSTER Die Muster in diesem Abschnitt verteilen ihre einzelnen Komponenten meist auf unterschiedliche Hardwareplattformen. Laut [Mic09] betrifft die ein verteiltes System ausmachende Architektur alle Aspekte der Anwendung, unter anderem seinen strukturellen Aufbau, das Verhalten seiner Funktionalität und die zu verwendenden Kommunikationstechniken. A. Client/Server-Architektur Bei der Client/Server-Architektur kann jede Komponente Dienstleistungen anderer Komponenten in Anspruch nehmen, um wiederum selbst Dienstleistungen anbieten zu können. Ein Client erhält in der Regel zu jeder Anfrage an den Server eine Antwort zurück. Laut [Kla02] unterscheidet das Client/Server-Modell zwischen zwei Komponentenarten. Zum einen der Serverkomponente die einen Dienst zur Nutzung anbietet und der Clientkomponente, welche ihn in Anspruch nimmt. das aktuelle Wetter anzeigt näher erläutert. In Abbildung 3 bietet der Webserver ständig das aktuelle Wetter für bestimmte Regionen an. Ein Smartphone beziehungsweise Computer kann bei Bedarf eine Anfrage zum Server senden, welche die gewünschte Wetterregion enthält. Ist diese Region verfügbar, sendet er die aktuellen Daten zum Client zurück, der sie wiederum ausgibt. B. Broker-Architektur Bei dieser speziellen Form der Client- Server-Architektur erfolgt die Zuweisung eines Servers an einen Client mittels eines so genannten Brokers. Der bekannteste Einsatz dieses Architekturmusters stellt die Middleware COR- BA 2 dar. Eine IDL (Interface Definition Language) Datei dient dabei wie in Abbildung 4 ersichtlich zur Definition von Schnittstellen zwischen einzelnen Anwendungskomponenten. Der ORB (Object Request Broker) führt die Auflösung der Objektreferenzen durch, die zuvor in der IDL definiert wurden. Hierüber stellt er die Konnektivität der Anwendungskomponenten sicher. Fig. 4. Broker-Architektur im mobilen Umfeld Fig. 3. Client/Server-Architektur Auf den mobilen Bereich übertragen wird das Beispiel an einer Smartphone App 1, die 1 Anwendung Laut [Xin05] bringt das den Vorteil, dass der Broker sich selbstständig um das Auffinden der Services kümmert und die Anwendung durch die einheitliche Definition von Schnittstellen erweiter- sowie wiederverwendbar macht. Nachteile beim Einsatz eines 2 Common Object Request Broker Architecture

5 solchen Frameworks sind jedoch geringere Effizienz, höhere Netzlast und eine komplexere Implementierung. Google Android setzt diese Architektur ebenfalls ein, da laut [Hei09] jede Anwendung in einem eigenen Prozess abläuft und keine direkte Kommunikation untereinander möglich ist. In der Praxis kommt es oft vor, dass sich Apps aus mehreren Prozessen zusammensetzen. Bei einen Navigationssystem läuft der Kern oft als Service im Hintergrund. Das User Interface (UI) befindet sich jedoch im Vordergrund und ist nur so lange aktiv wie es geöffnet ist. Mittels AIDL (Android Interface Definition Language) dem mobilen Pondon zu IDL lässt sich eine zuverlässige Kommunikation zwischen den Komponenten bereitstellen, die an zentraler Stelle administrierbar ist. Auf Abbildung 4 übertragen würde in der linken Seite mittels Compiler 1 das UI und rechts daneben durch Compiler 2 der Hintergrundservice übersetzt. C. Peer-to-Peer-Architektur Bei einer Peer-to-Peer-Architektur (P2P) handelt es sich nach [Eri06] um ein dezentrales System, das sich dadurch auszeichnet, dass die Teilnehmer gleichberechtigt aufgestellt sind und mittels Nachrichten untereinander kommunizieren. Im Vergleich zur zuvor beschriebenen Client- Server-Architektur wird auf eine Nachricht keine Antwort erwartet. Falls doch eine Antwort erforderlich sein sollte, müsste diese als zusätzliche Nachricht in die Rückrichtung versendet werden. Das Peer-to-Peer- Architekturmuster wird außer bei Musik- und Filmtauschbörsen mittlerweile auch vereinzelt im Umfeld mobiler Anwendungen eingesetzt. Ein Beispiel für einen zukünftigen Einsatzbereich der P2P-Architektur stellt die Anwendung in einem modernen Einkaufszentrum dar. Abbildung 5 zeigt die mobilen Geräte (Peers) die der Anwender mit sich trägt. Während des Einkaufs können diese mittels Bluetooth oder Wireless-Lan interagieren, ohne das im Gebäude selbst eine Infrastruktur bereitgestellt werden muss. Diese kleinen P2P Netzwerke bauen sich selbstständig untereinander auf und wickeln die Kommunikation miteinander ab. Dabei besteht immer nur eine direkte Verbindung unter den Geräten, die sich unmittelbar in Reichweite befinden. Für entferntere Fig. 5. Mobile Peer-to-Peer-Architektur Kommunikation dienen die dazwischen liegenden Geräte als Vermittler. D. Model-View-Controller Dieses Muster verteilt die Zuständigkeiten der Präsentationsschicht auf verschiedene Komponenten, was eine Änderung oder Erweiterung erleichtert und die Logik der Anwendung von ihrer Präsentation trennt [Mic10]. Die Anwendung wird dabei nach [Eri94] in folgende Teile Geschäftslogik und Daten (Model), Bildschirmpräsentation (View) sowie in Steuerung (Controller) aufgeteilt. Die Steuerung nimmt Benutzereingaben entgegen und veranlasst die passenden Operationen der Geschäftslogik. View und Model sind dabei entkoppelt und kommunizieren über ein festgelegtes Protokoll [Eri94]. Ändern sich die Daten im Model benachrichtigt es die View, welche die geänderten Werte anzeigt. Anwendungen, die nach diesem Architekturprinzip aufgebaut sind, lassen sich grundsätzlich einfacher auf mobile Plattformen portieren, da in der Regel nur eine neue View mit angepasstem Controller entwickelt werden muss der auf das bestehende Model zugreifen kann. IV. MOBILE ARCHITEKTURMUSTER In diesem Kapitel wird auf die Einsatzgebiete einiger der bereits vorgestellten Architekturmuster im Umfeld mobiler Anwendungen eingegangen. Architekturmuster eignen sich laut [Joa10] gut zur global verteilten Softwareentwicklung um die Grundzüge des zu entwickelnden Systems festzulegen.

6 Beispiele und Abbildungen beziehen sich in erster Linie auf die Anwendung vom mobilen Geräten wie Smartphones oder Tablet PC s mit dem Betriebssystem Android. A. Mehrschichten-Architektur Android Android wurde Ende 2008 von Google als quelloffenes und frei verfügbares Betriebssystem für mobile Endgeräte vorgestellt. Die Weiterentwicklung und Adaption auf neue Anforderungen wird von der Open Heandset Alliance durchgeführt, in der Google als Mitglied vertreten ist. Mit der einfachen Möglichkeit auf der oberen Schicht (siehe Abbildung 6) Anwendungen zu entwickeln sowie der freien Verfügbarkeit der Entwicklungsplattform Eclipse hat Android nach [Flo10] definitiv das Potenzial zum Marktführer. Fig. 6. Schichten-Architektur Android [Goo11] Android basiert wie in Abbildung 6 zu sehen auf dem Mehrschichtenmodell, das sich in fünf Stufen unterteilt. 1) Linux Kernel: In der Kernschicht abstrahiert ein Linux Kernel aktuell in der Version 2.6 die zugrunde liegende Hardware. Dieser Kernel wurde speziell für den Einsatz auf mobilen Geräten optimiert, was dazu führte, dass zum Beispiel das Energiemanagement oder Speicherverwaltung angepasst wurden um mit den geringen Ressourcen auszukommen. 2) Libraries: Auf dieser Ebene aufbauend realisieren C und C++ Bibliotheken den schnellen Zugriff auf systemnahe Funktionalitäten. Dies können unter anderem Multimediadienste, Verschlüsselungen oder Datenbankdienste sein. 3) Android Runtime: Ebenfalls in der Libraryschicht integriert, ist die Android Runtime. Diese beherbergt in erster Linie die Dalvik Virtual Machine, welche eine Java- Laufzeitumgebung für die Ausführung und Verwaltung der Android Anwendungen bereitstellt. Zusätzlich sind hier auch Kernbibliotheken für die darüber liegenden in Java programmierten Schichten abgelegt. 4) Application Framework: Speziell für den App Entwickler bietet diese Schicht Java- API s zum einfachen und schnellen Zugriff auf vordefinierte Dienste wie Ortsbestimmung, Mikrofon usw. 5) Applications: In der obersten Schicht mit dem höchsten Abstraktionsniveau befinden sich letztendlich die Anwendungen welche dem Endanwender direkt zur Verfügung stehen. Beispiele hierfür sind: Browser, Telefon, Wetteranzeige, Teschenrechner usw. B. Webshop-Architektur Das Shoppen im Internet erfreut sich ständig steigender Beliebtheit. Weshalb es für die Shop-Betreiber stets wichtig ist, den aktuellen Trends hin zum Mobile-Shopping zu folgen und den Anschluss nicht zu verpassen. Drei Architekturen sollten daher aktuell parallel betrieben werden. Dem Anwender werden so in der Zeit des Web 2.0 alle Vorzüge wie komfortables Navigieren im Shop oder interaktive Beteiligung durch Abgabe von Bewertungen und Erfahrungsberichten ermöglicht [Tos07]. 1) Standard-Web: Der erste Pfeil in Abbildung 7 zeigt den Zugriff auf einen Webshop wie er mittels eines normalem PC s zum Beispiel über Mozilla Firefox stattfindet. Solange das Anzeigegerät über eine Ausreichende Auflösung verfügt, ist diese Architektur ohne Probleme einzusetzen. Verfügt das Endgerät jedoch lediglich über eine geringe Auflösung oder wird mittels Touchscreen bedient, stößt man hierbei schnell an die Grenzen. 2) Mobile-Web: Die einfache alternative besteht darin, einen mobilen Webshop parallel zum Standardshop zu betreiben (siehe Abbildung 7, Pfeil Mitte). Diese Architektur bietet ausreichende Funktionalität auf mobilen Endgeräten und ist zugleich auch plattformunabhängig, da sie im integrierten Webbrowser betrieben wird. 3) Mobile-API: Am komfortabelsten ist es jedoch, das Smartphone mit einer Nativen-App durch den Webshop zu navigieren. Diese besitzt eine eigene Anzeige- und Geschäftsschicht, was ihr ermöglicht über die mobile Programmierschnittstellen des Shop-Systems direkt auf die Daten zuzugreifen.

7 Fig. 7. Architekturbeispiel Webshop Im Idealfall ist ein moderner Webshop mit allen drei Architekturen ausgestattet. Dies ermöglicht den Endanwendern die volle Funktionalität des Shops im Browser (PC), mittels der Nativen-App (Smartphone) oder den plattformunabhängigen Mobile-Webshop auf allen anderen Endgeräten auszuschöpfen. C. Aufwand/Möglichkeiten Den Möglichkeiten, welche die verschiedenen Architekturen liefern, muss jedoch auch der Aufwand für die Entwicklung gegenüber gestellt werden. So ist es zum Beispiel bei einem kleinen Webshop mit geringem Umsatz nicht profitabel immense Summen für die Programmierung nativer Apps zu investieren. 1) Web: Die Vorteile der Web-Apps- Architektur sind vielfältig. Für mobile Geräte optimierte Websites ermöglichen es, der breiten Masse von Anwendern über einen benutzerfreundlichen Weg auf den Webshop zuzugreifen. Die meisten Endgeräte verfügen bereits standardmäßig über einen mobilen Browser der hierzu genutzt werden kann. Da die überwiegende Anzahl der Endkunden meist mit der Suchmaschiene Google zum Webshop gelangen, bietet eine Web-App hier den Vorteil, dass diese direkt verlinkt werden kann. Dem Endanwender bleiben somit unnötige Zwischenschritte wie eine App herunterladen, installieren und öffnen erspart. Letztendlich ist die Web-App auch flexibler hinsichtlich der Gestaltung von Updates, da laut [Glo10] keine Evaluierung wie bei nativen Apps durch den Plattformbetreiber erforderlich ist. 2) Web+: Die erweiterten Web-Apps bilden eine Zwischenlösung auf Abbildung 8 platzieren sie sich in der Mitte. Durch Frameworks wie jqtouch oder Sencha die speziell für Webanwendungen auf Basis von HTML 5 entwickelt wurden, ist es nun möglich dem Look&Feel von nativen Anwendungen ohne direkte Programmierung sehr nahe zu kommen. 3) Nativ: Das User Experiance Design einer nativen Anwendung ist in der Regel leistungsstärker als bei Web-Apps, da es laut [Glo10] die einzige Möglichkeit darstellt, um auf Gerätefunktionen wie Kamera, Beschleunigungssensor, Adressbuch, Ortungsschnittstelle oder die Telefonfunktion zuzugreifen. Die Reichweite des Markets bzw. App Stores tragen erheblich zur Verbreitung der Anwendung bei, was wiederrum eine höhere Investition für den Entwicklungsaufwand der nativen App rechtfertigt. Da es sich bei nativen Apps jedoch um Anwendungen handelt, die speziell für eine Plattform entwickelt wurden, entsteht wie in Abbildung 8 zu erkennen meist ein hoher Arbeitsaufwand. Oft ist es erforderlich, die Entwicklung für mehrere Plattformen parallel zu betreiben, da die Zielgruppe meist unterschiedliche Betriebssysteme wie Android, ios 3, WM7 4 oder Symbian auf ihren Endgeräten einsetzt. Fig. 8. Architekturen Aufwand / Nutzen [Ott11], [Spo11] 3 iphone OS 4 Windows Mobile 7

8 Die Architektur einer nativen App birgt dennoch ein starkes Zukunftspotential, da sie die Zugänglichkeit eines Webshops erhöht. Durch erweiterte Dienste wie Push-Funktionen oder ortsgebundene Werbung entstehen neue Möglichkeiten, die laut [Glo10] die Kundenbindung erhöhen. V. SCHLUSSFOLGERUNGEN Architekturmuster haben sich in der Softwareentwicklung bereits seit langer Zeit bewährt. Sie sind notwendig um Anwendungen bereits auf oberster Ebene strukturiert aufzubauen. In den letzten Jahren wurden die bereits bewährten Muster wie das Client/Serveroder Broker-Prinzip aus der traditionellen Entwicklung in den Bereich der mobilen Softwareentwicklung übernommen und erfolgreich angewendet. Dies ist an den zahlreich neu erschienenen Apps beispielsweise im Bereich des Onlinebankings oder mobilen Fernsehens zu erkennen. Laut [Sta04] ist es bereits erwiesen, dass mobile Anwendungen ein integraler Bestandteil unseres Lebens werden. Neue Architekturen im Bereich von mobilen Webshops mit integrierten Zahlungsmöglichkeiten werden sich daher stark weiter entwickeln. Hierbei besteht das Ziel darin, dem Kunden verschiedene Wege zur Verfügung zu stellen, unter denen er den für sich am komfortabelsten frei auswählen kann. Je mehr Möglichkeiten geboten werden, desto höher sind letztendlich auch die Kosten. Hierbei gilt es eine für den Kunden und Webshopbetreiber zufrieden stellenden Kompromis zu finden. Weitere Architekturen wie Peer-to-Peer die sich in den traditionellen Bereichen bereits erfolgreich bewährt haben, befinden sich im mobilen Bereich noch am Anfang ihrer Entwicklungsphase. Diese Muster könnten sehr flexibel eingesetzt werden, da am Einsatzort keine fest installierte Hardware erforderlich ist. Sie versprechen bereits jetzt, ein riesiges Potential für die Zukunft im Bereich der mobilen Kommunikation. [Dee03] REFERENCES DEEPAK ALUR, JOHN CRUPI, DAN MALKS: Core J2EE Patterns: Best Practices and Design Strategies 2nd Edition. Prentice Hall / Sun Microsystems Press, 2003 [Eri94] ERICH GAMMA, RICHARD HELM, RALPH JOHNSON, JOHN VLISSIDES: Design Patterns - Elements of Reusable Object-Oriented Software. Addison-Wesley Longman, Amsterdam, 1994 [Eri06] ERIK BUCHMANN: Erkennung und Vermeidung von unkooperativem Verhalten in Peer-to- Peer-Datenstrukturen, Diss., 2006 [Flo10] FLORIAN MANGOLD: Analyse von IT- Anwendungen mittels Zeitvariation, Diss., 2010 [Glo10] GLOBAL INTELLIGENCE ALLIANCE: Native or Web Application? 2010. Forschungsbericht [Goo11] GOOGLE INC.: Android Online Documentation. http://developer.android.com. Version: 2011 [Hei09] HEIKO MOSEMANN, MATTHIAS KOSE: Android. Hanser Fachbuchverlag, 2009 [Joa10] JOACHIM SAUER: Architekturzentrierte agile Anwendungsentwicklung in global verteilten Projekten, Diss., 2010 [Jör03] JÖRG BECKER, HOLGER HANSMANN, TO- BIAS RIEKE: Architekturen von Informationssystemen. In: ACM (2003) [Kla02] KLAUS BESCHORNER: Untersuchungen zur effizienten Kommunikation in komponentenbasierten Client/Server-Systemen, Diss., 2002 [Kyl01] KYLE BROWN, GARY CRAIG, GREG HESTER, JAIME NISWONGER, DAVID PITT, RUSSELL STINEHOUR: Enterprise Java Programming [Mar02] with IBM WebSphere. IBM Press, 2001 MARTIN FOWLER: Patterns of Enterprise Application Architecture. Addison-Wesley Longman, 2002 [Mic06] MICHAEL NUTTO: Internetbasiertes Fachinformationssystem zur Plattenkinematik, Diss., 2006 [Mic09] MICHAEL DUVIGNEAU: Konzeptionelle Modellierung von Plugin-Systemen mit Petrinetzen, Diss., 2009 [Mic10] MICHAEL ALBERT, THOMAS HEINZ, MIKE IMHOF: Entwicklung eines mobilen Eyetrackers, Diss., 2010 [Ott11] OTTO GMBH & CO KG: Abbildung Otto Online-Shopping. http://www.otto.de. Version: 2011 [Spo11] SPORTSCHECK GMBH: Abbildung SportScheck Online-Shopping. http://www.sportscheck.com. Version: 2011 [Sta04] STAMATIS KARNOUSKOS: Mobile Payment: A Journey through exitsting Procedures and standardization Initiatives. In: IEEE (2004) [Ste08] STEFAN BETERMIEUX: Generierung [Tho10] aufgabenbasierter dialogorientierter Benutzerschnittstellen von Web-Anwendungen, Diss., 2008 THORSTEN SCHEIBLER: Ausführbare Integrationsmuster, Diss., 2010 [Tos07] TOSHIHIKO YAMAKAMI: Mobile Web 2.0: Lessons from Web 2.0 and Past Mobile Internet Development. In: IEEE (2007) [Uwe98] UWE SCHMIDT, INGO SCHLÜTER, NIKOLAUS WINTER, ANDREAS KRUTSCHER, MIRKO MUMBERG, SVEN GARSKE: Seminar Objektorientierter Entwurf. 1998. Forschungsbericht [Xin05] XINYU CHEN, MICHAEL R. LYU: Reliability Analysis for Various Communication Schemes in Wireless CORBA. In: IEEE (2005)