Die Anbindung von mobilen Endgeräten wie Smartphones oder Tablets ist für die meisten CONZEPT 16-Applikationen ein wichtiges Thema. Eine mobile Anwendung beinhaltet zunächst einmal die gleichen Elemente wie eine Desktop-Anwendung: Oberfläche, Programmlogik und Datenbankzugriff. Die Anwendungsumgebungen unterscheiden sich jedoch stark voneinander und ergeben auch verschiedene Lösungen.
GUI
Der offensichtlichste Unterschied zur Desktop-Anwendung findet sich in der Oberfläche. Eine GUI für große Bildschirme, die mit Tastatur und Maus bedient wird, ist klarerweise für den Einsatz auf einem Smartphone mit Touchscreen nicht besonders geeignet. Der Benutzer erwartet auf diesen Systemen (genau wie bei einer Windows-Oberfläche) Anwendungen mit nativem Look and Feel. Web-basierte Oberflächen sind ein Kompromiss, der auch nur ungern akzeptiert wird ("Gibt’s denn keine App?"), da meist Anzeige und Bedienung nicht dem geräteeigenen Schema entsprechen. Für eine optimale Lösung führt daher kein Weg an einer gerätespezifischen Oberfläche vorbei. Zumindest existieren Tools, die eine plattformübergreifende Entwicklung erlauben.
Datenbankzugriff
Drei wichtige Faktoren unterscheiden den Datenzugriff mobiler Devices von Desktops.
Zuerst ist nicht immer eine Online-Verbindung verfügbar. Soll die mobile Anwendung auch einen Offline-Betrieb ermöglichen, muss eine Zwischenspeicherung von Daten implementiert werden, die gegebenenfalls auch Offline-Datenänderungen berücksichtigt.
Außerhalb des heimischen WLAN erhöhen sich die Zugriffslatenzen erheblich. Anstatt 0,1 ms pro Anfrage sind schnell 20-40ms (im Extremfall auch mehr als 100ms) erreicht. Die Anzahl von möglichen Datenbankzugriffen pro Sekunde sinkt also beträchtlich, eine RecRead-basierte Anwendung ist dann nicht mehr einsetzbar. Dabei ist es unerheblich, ob die Verbindung über eine fremdes WLAN, UMTS oder GPRS erfolgt, die Verzögerung ergibt sich dabei primär aus der Nutzung des Internets.
Authentifizierung und Verschlüsselung müssen ebenfalls berücksichtigt werden. Entweder wird eine VPN-Verbindung genutzt oder es muss ein verschlüsseltes Protokoll (HTTPS) mit abgesicherter Anmeldung verwendet werden.
Prozeduren und Programmlogik
Aus den oben aufgeführten Gründen ist auch die Durchführung von CONZEPT 16-Prozeduren (im Rahmen einer denkbaren Programmierschnittstelle für diese Plattformen) auf den mobilen Geräten nicht sinnvoll.
Eine Realisierungstrategie ist die Datenaufbereitung und Übermittlung durch den CONZEPT 16-SOA-Service. Die Datenanfragen liegen dabei auf der Ebene der Applikation und nicht auf der Ebene der Datenbank – so können auf eine Anfrage hin auch Daten mehrerer Datensätze auch aus unterschiedlichen Tabellen in einer Antwort gesendet werden. Durch die Verwendung standardisierter Protokolle und Formate (wie beispielsweise HTTPS und JSON) kann ein solcher Dienst universell verwendet werden. Auch eine Anpassung an fremde Apps ist machbar.
Die gesamte Programmlogik außerhalb der Oberflächensteuerung verbleibt damit in den Prozeduren und kann in einem sicheren Umfeld durchgeführt werden.
19 Antworten
Pauschal lässt sich diese Frage leider nicht beantworten. Beim Einsatz des SOA-Service liegt die komplette Verarbeitung in Ihrer Kontrolle, aber somit auch in Ihrer Verantwortung. Hierbei liegt es am Entwickler ein robustes Design, das wenig Angriffsmöglichkeiten und hohe Verfügbarkeit gewährleistet, zu programmieren. Der IIS, auf dem die Web-Schnittstelle aufsetzt, bietet bereits nativ gewisse Sicherheiten.
@Andrej, Florian
Vielen Dank. Es sieht so aus, dass der SOA-Dienst in diesem Fall doch mehr flexibel ist. Noch eine Frage: welche Implementierung finden Sie zuverlässiger und sicherer: Webserver + C16-Webschnittstelle oder C16-SOA-basierter Server?
Client-seitig macht es von der Implementierung keinen Unterschied ob Sie einen Server mit dem SOA-Service oder der Web-Schnittstelle realisieren. Über einen Browser, z.B. auf einem mobilen Gerät, können Sie beides ansprechen, wenn Sie den SOA-Service als Webserver implementieren.
Heißt es, dass ein Fat Client auf dem Mobil-Gerät fürs SOA-Service geschrieben werden soll, während ein Thin Client (eigentlich, ein Internet Browser) für die Webschnittstelle genug ist?
@Alex Kosman
Hier muss unterschieden werden, ob der Service für den reinen Datenzugriff genutzt wird oder für eine interaktive Webanwendung. Grundsätzlich kann der SOA-Service für beides verwendet werden.
Bei der Web-Schnittstelle muss als Voraussetzung ein Webserver installiert sein, eine Webanwendung kann unter Umständen schneller realisiert werden. Für den Datenzugriff ist der Aufwand ähnlich hoch, der SOA-Service ist aber flexibler.
@ Andrej:
welche Vorteile und Nachteile hat nach Ihrer Meinung die Verwendung des CONZEPT16-SOA-Diensts im Vergleich mit der CONZEPT16-Webschnittstelle für mobile Anwendungen?
@Florian
Das ist sehr gut. Das Verketten längerer Kommentare war doch etwas umständlich.
(Vier)tausend Dank 🙂
Hallo Kilian, es können jetzt noch längere Kommentare abgegeben werden als zuvor, nämlich bis zu 4000 Zeichen =)
@Andrej
Klar, auch betriebswirtschaftliche Überlegungen müssen bei all dem berücksichtigt werden, aber nicht von mir. Ich bin als Kunde nur dazu da, Wünsche & konstruktive Kritik beizutragen 🙂
So oder so: Wenn man den Zahlen trauen darf, die Apple bei seinen regelmässigen Marketingfeten unter die Leute bringt und die man teilweise auch bei Wikipedia nachlesen kann, dürfte es bald eher zur betriebswirtschaftlichen Frage werden, warum man da nicht mitmacht 😉
@Andros
das wäre tatsächlich ein Traum …
@Kilian
Das Latenzproblem ist bei einer SQL-Anfrage ähnlich: Connect, Query senden, Fetch der einzelnen Ergebniszeilen, Disconnect. Trotzdem könnte man (je nach Anwendung) auch direkt mit dem Server kommunizieren, es ist nur eben nicht die beste Lösung.
Bei einem embedded Server stellt sich das Latenzproblem natürlich nicht.
Auf welchen Plattformen welche Komponenten von CONZEPT 16 von uns angeboten werden, hängt von der vorhandenen und zu erwartenden Nachfrage ab. Neben der technischen Machbarkeit ist eben auch die betriebswirtschaftliche Seite relevant.
Es gab in der Vergangenheit ja beispielsweise den CONZEPT 16-Server für Netware, OS/2, Solaris, AIX etc. oder auch die Programmierschnittstelle für UNIX.
Ist ja bald Weihnachten, da darf man sich was wünschen und träumen darf man ja sowieso:
Einen C16-Server "Lite", der auf mobilen Geräten läuft (wie z.B. SQLLite). Der synchronisiert dann automatisch bei aktiver Onlineverbindung gezielt (markierte) Datensätze mit dem "echten" Inhouse C16-Server. Die App würde dann gewöhnlich für Abfragen nur diesen lokalen Server abfragen. Ach ja: und man entwickelt die App mit dem selben Tool (Designer), wie auch den Windows-Client….
Jaja…*träum* 🙂
@tsauter
Noch ein Missverständnis muss ich ausräumen:
Mir geht es nicht um eine Basisschicht für die Kommunikation mit einem SOA-Service, sondern um eine Basis-Schicht für die Kommunikation mit einem normalen C16-Server, wenn es diese Basisschicht für alle gängigen Plattformen gibt (etwa für Linux), dann kann man darüber eine Schicht implementieren z.B. in Java, die es dann wieder ermöglicht, z.B. Android-Apps mit dem üblichen C16-Komfort zu schreiben.
@tsauter
Eine embedded Datenbank macht vor allem Sinn, wenn ich mit C16 darauf zugreife, ich will ja RAD haben wie auf dem PC auch. Eine App ist ja ein mehr oder weniger autarkes Softwarepaket, da würde ich es sinnvoll finden, wenn alles von der GUI bis zu DB in der Applikation zusammenflösse.
Dies liesse sich erreichen, indem man Client und Server einfach zusammenpackt aber auch, indem man eine embedded DB in den Client einführt (das wäre sicher viel effeizienter).
Damit kann ich dann eine App schreiben, die ihren eigenen Datenspeicher hat (ohne Latenzprobleme, ist ja alles lokal). Alle anderen Themen wie Sync mit einem SOA-Service usw. bleiben davon ja völlig unberührt und können z.b. als Hintergrundprozesse realisiert werden usw…
@Kilian
Tatsächlich geht die Einfachheit von Conzept16 in einer mobilen Umgebung verloren. Eine Basisschicht (oder Framework) für die Kommunikation mit dem SOA-Dienst wäre schon hilfreich. Wir haben das Thema für uns schon gelöst, doch mancher will sich nicht ans das Thema wagen.
Macht eine embedded Datenbank wirklich Sinn, wenn darauf mit Java, Javascript u.ä. zugegriffen wird? Wo ist da der Vorteil gegenüber schon erhältlichen Produkten?
Folgende Überlegungen halte ich daher für anstellenswert:
– Sollte es C16-Clients für mehr Plattformen als nur Windows geben?
– Sollte man eine C16-Client-Basisschicht entwickeln, auf die man dann Plattformspezifisch aufsetzen kann (z.B. mit Javascript-, Java-, Objective-C-Frameworks oder oder) und die die Kommunikation mit beliebigen C16-Servern auch mobiltauglich effizient und robust erledigt
– Sollte es eine embedded C16-Datenbank geben (also praktisch einen Client ohne Server aber mit Datenbank)
Ich bin der Meinung, dass man gerade die Stärken einer RAD wie Conzept16 auch in diesem neuen Umfeld der mobilen Anwendungen irgendwie aufrecht erhalten muss, sonst schwinden die Gründe, in diesem Feld so etwas einzusetzen gänzlich.
Warum sollte ich z.B. eine Android-App schreiben (in Java wohlgemerkt), die sich mit einem Conzept16-SOA-Service synchronisiert? Doch wohl nur, wenn es diesen Service ohnehin schon gibt. Mache ich aber alles neu, so kann ich auch auf der Serverseite dann etwas anderes einsetzen (z.B. einen Service, der auch in Java programmiert wird).
Oder: Wie soll ich es als C16-Programmierer anstellen, einen iOS-Client für einen bestehenden Service einer Drittpartei zu schreiben? Ich müsste erst einen SOA-Service aufsetzen, der die Dienste der Drittpartei in Anspruch nimmt und dann auf dem Mobilgerät vollkommen C16-unabhängig ein Programm schreiben, das den C16-SOA-Service nutzt. Das wäre absurd.
Also das Problem steigender Latenzen haben ja alle, die für eine mobile Plattform entwickeln, also auch andere Datenbankbasierte Anwendungen, es ist wohl eher nicht Conzept16-spezifisch.
Oder doch? Natürlich kann es sein (über diese Interna kann ich nichts wissen), dass die Kommunikation zwischen C16-Client und C16-Server aus irgendwelchen Gründen zu ineffizient oder nicht robust genug für WLAN und Mobilverbindungen ist, das wäre dann aber sicher eher ein Grund dafür, diese Mängel zu beseitigen, als einer, die entsprechenden Anwendungsfälle auszuschliessen, denke ich.
Abgesehen davon gibt es auch den Fall, dass ich vielleicht eine kleine Applikation schreiben möchte, die mit einer embedded DB ausgestattet ist, also Client und Server gemeinsam auf einem mobilen Gerät ausführen möchte. Dem steht vermutlich prinzipiell nichts im Wege, abgesehen von der Tatsache, dass die entscheidenden Plattformen (iOS, Android) derzeit nicht bedient werden können.
SOA machts möglich, somit können wir die Bedürfnisse für die Zukunft abdecken. Ein wichtiger Schritt in die richtige Richtung!