Occasionally Connected Clients – Zeitweise verbundene Clients


Heute möchte ich kurz über ein Thema schreiben, welches mir immer wieder beim Entwurf von Anwendungsarchitekturen begegnet. In der heutigen Zeit sind für Industrieländer durchaus folgende Aussagen gültig:

  1. Die Vernetzung von Computern ist inzwischen sehr weit fortgeschritten – Breitband Internetzugänge, Wireless Hotspots, UMTS Internet Zugang sind Technologien, die verteilte Anwendungsarchitektur ermöglichen.
    Mobile Endgeräte – Laptops, Nettops, PDAs mit Windows Mobile – gibt es auch in vielfältiger Auswahl. Diese Endgeräte können im Büro als auch in anderen Bereichen zum Einsatz kommen.
  2. Allerdings gibt es keine wirklichen Garantien, dass überall und jederzeit ein Internetzugang mit hinreichender Geschwindigkeit vorhanden ist.

Betrachtet man diese 2 Aspekte in Hinblick auf Anwendungsarchitektur, kann man folgende Schlussfolgerungen aus diesen Aussagen ziehen:

  1. Durch die Verfügbarkeit von Internetzugriffsmöglichkeiten und mobiler Hardware --> Mobile Clients von verteilten Anwendungen können durchaus für den Einsatz in mobile Anwendungsbereichen entworfen werden.
  2. Die Internetzugriffsmöglichkeit ist nicht überall in hinreichender Qualität garantiert --> Mobile Clients müssen sowohl mit dem Online- und dem Offline Szenario umgehen können.

Damit muss die Architektur solcher verteilten Anwendungen so entworfen werden, dass es „occasionally connected“ Clients in der Anwendungsarchitektur betrieben werden können.

Die grösste Herausforderung bei der Gestaltung solcher Anwendungen ist es, die Arbeit und die Konsistenz von Daten für den Online/Offline Betrieb gleichermaßen zu gewährleisten. Wenn möglich, sollte die Clientanwendung so programmiert sein, dass ihre Bedienung Online/Offline gleichermassen funktioniert.

Beim Entwurf solcher Clients gibt es 2 Ansätze:

  • Den datenzentrischen Ansatz
  • Den service orientierten Ansatz

Offline

Beim datenzentrischen Ansatz wird die Konsistenz der Daten in der Geschäftsanwendung durch die Synchronisation von Daten sehr nah am echten Datenmodell betrieben. Die Datenstrukturen auf dem Client und dem Server müssen entsprechend gleich sein, um einen einfache Synchronisation zu gewährleisten. Effektiv kann man hier von einer Synchronisation zwischen einer Client Datenbank und einer Server Datenbank ausgehen; - eventuell sogar mit eingebauten Mechanismen der zugrunde liegenden Datenbank z.B. Microsoft SQL Server Replikation.

Beim serviceorientierten Ansatz wird die Konsistenz der Daten in der Geschäftsanwendung durch die Synchronisation von Aufrufen an die Anwendungsdienste geleistet. In diesem Anwendungsszenarion können auf dem Client sehr einfache Datenstrukturen abgelegt werden. Im Synchronisationsszenario nach einem Offlinefall müssen die ändernden Zugriffe auf die Businesslogik der Anwendungsdienste auf den Server ausgeführt werden.

In beiden Szenarien gibt es 2 Typen von Daten zu beachten:

  • Referenzdaten, die am Client nicht verändert werden und die sich selbst sehr selten ändern. Zum Beispiel Kataloge wie die Liste aller Bundesländer oder aller Amtsprachen oder die Liste Modelle eines Autoherstellers.
    Diese Daten sind einfach zu handhaben, beim Online Szenario sollten sie auf den Client gespeichert werden, damit diese Referenzdaten im Offline Betrieb zur Verfügung stehen. Bei der Synchronisation ist nur zu prüfen, dass die aktuellsten Referenzdaten auf den Client gespeichert werden.
  • Anwendungsdaten, die am Client verändert werden. Hier müssen die Änderungen, die offline vorgenommen werden, bei Onlineverfügbarkeit mit dem Server aktualisiert werden. Dabei sind parallele Änderungen am selben Datensatz – konkurriender Zugriff – zu berücksichtigen.

Die Entscheidung, welchen Lösungsansatz verwende, hat direkten Einfluss auf die Architektur der Clientsoftware. Hier gilt es nachhaltig zu prüfen, welcher Ansatz der richtige ist. Wichtige Kriterien können hier sein:

  • Vermeidung von komplizierten Softwarelösungen (Fat clients) die aufwendige Wartungs - und Softwareverteilungsmechanismen benötigen
  • Sicherheitsaspekte
  • u.v.a.m.

In meinen nächsten Blogeinträgen werde ich für beide Ansätze Lösungen vorstellen.

GunnarD

Skip to main content