Smart Clients - Definition, Abgrenzung und Aspekte ... - Compeople

Weitere Magazine

Empfehlungen

Info

special Smart Clients Abb. 3: Optimierter Datentransfer mit Objekttransaktionen Abb. 4: Log-Transfer-Komponente des spirit Smart Client Framework len Nutzung auf dem Client oder der Umsetzung auf Datenbank-Transaktionen kann die Objekttransaktion auch für die optimierte Übertragung von Änderungen in einer Menge von Objekten zwischen Client und Server benutzt werden. Abbildung 3 zeigt ein Beispiel für einen solchen Transfer. Um das Datenvolumen auf ein Minimum zu reduzieren, werden die Änderungen aus einer Objekttransaktion in einen Extrakt exportiert. Nur dieser wird auf den Server übertragen und dort durch Zugriffe auf die Datenbank ergänzt. Die dadurch veränderten Objekte kommen auf dem gleichen Weg zurück auf den Client. Preferences Hier soll primär der Speicherort für die Preferences angesprochen werden. Welche Arten von Preferences gibt es denn? Gewöhnlich wird zwischen User-Preferences und System-Preferences unterschieden. Benutzerbezogene Einstellungen enthalten spezifische Informationen für einen einzelnen Benutzer: die Benutzerdaten selbst, die bevorzugte Gestaltung der Oberfläche, Spracheinstellungen und andere Optionen. Für jeden Benutzer eines Systems gibt es einen eigenen Satz. Wenn der Benutzer seine Einstellungen vorfinden soll, unabhängig davon, auf welchen Client-System er sich anmeldet, dann müssen diese Preferences unter seiner Kennung zentral gespeichert und nach der Anmeldung auf den Client übertragen werden. Lohnt sich dieser Aufwand wirklich, oder genügt nicht auch die lokale Speicherung? Erfahrungsgemäß sitzen letztendlich die meisten Benutzer jeden Tag vor demselben Rechner, der nur alle paar Jahre gegen ein neueres Modell ausgetauscht wird. Systembezogene Einstellungen enthalten Informationen über die aktuelle Umgebung. Pfade im Dateisystem, die Auflösung des Monitors und die verwendete Netzwerkverbindung machen genau auf diesem einen Rechner Sinn. Es gibt nur einen Satz pro Rechner. Und der gehört wohl kaum auf den Server. Spätestens bei dem URL des verwendeten Web Services ist die Notwendigkeit einer lokalen Speicherung offensichtlich. Logging Eine Anwendung soll nicht nur während der Entwicklung, sondern auch in der Produktion Logging-Informationen erfassen können. Entweder nur zur Fehlersuche oder zusätzlich zur Protokollierung, um das Nutzungsverhalten auszuwerten oder Bedienungsprobleme zu erkennen. Es ist schließlich schon von Interesse, ob Bestellvorgänge öfters bei der Eingabe der Kreditkartennummer oder nach der Anzeige der Versandkosten abgebrochen werden. Auf dem Server ist es einfach, das Logging dynamisch zu konfigurieren, zu sichern und auszuwerten. Auf dem Client ist das eigentlich auch einfach. Allerdings ist nicht der Benutzer an den Logs interessiert, sondern der zentrale Support. Die am weitesten verbreitete Lösung bindet den Benutzer trotzdem in diesen Prozess ein. Nachdem er sich mit einem Pro- blem an den Support gewandt hat, erhält er Anweisungen, wie er das Logging einschaltet, wo er das Resultat findet und wie er es übermittelt. Eine anschließende Synchronisierung mit dem dazugehörigen Server-Log muss manuell erfolgen. Dieses Verfahren ist unbequem und fehleranfällig. Eine andere Lösungsmöglichkeit überlässt die Kontrolle und Steuerung dem Server. Unbedingt vorher zu klären sind hierbei die Fragen des Datenschutzes. Schließlich lässt sich so auch eine sehr weitgehende Überwachung des Benutzers realisieren. Bei einer automatischen Lösung überträgt der Client die gesammelten Log-Einträge regelmäßig an einen Server. Jeden einzelnen Log sofort zu übertragen wäre dagegen keine gute Idee. Praktikabel und weniger belastend ist es, die Log-Einträge auf dem Client zwar zu sammeln, aber nur im Fehlerfall zu übertragen. Sonst werden sie periodisch einfach wieder gelöscht. Für das Sammeln, Synchronisieren und Auswerten der Logs empfiehlt sich ein eigener Server. Abbildung 4 stellt Ihnen eine Log-Transfer-Komponente vor. Fehlerbehandlung Die Verarbeitung von aufgetretenen Fehlern ist eng verwandt mit dem Logging. Clientseitige Fehler werden in der Regel lokal verarbeitet. Für die zentralen Web Services sind diese nicht von Interesse. Durch die Benutzeroberfläche muss eine geeignete Präsentation erfolgen, für den Support werden Log-Informationen erzeugt und möglicherweise auch automatisch übertragen. 9.2006 © Software & Support Verlag GmbH 2006 www.javamagazin.de
Serverseitige Fehler sind für den Client dann interessant, wenn sie dessen Arbeit beeinflussen. Ob dabei besser eine auf dem Server aufgetretene native Exception oder eine verständlichere Nachricht übermittelt wird, hängt vom angestrebten Benutzerkreis ab. Universelle Lösungen sind im Falle von Fehlern nötig, die nicht von den eigenen Services, sondern vom Webserver oder von der Transportschicht kommen. Ihre Behandlung wird dadurch erschwert, dass sie bei der Implementierung des Clients oft gar nicht bekannt sind. Für die Erkennung, Klassifizierung und Verarbeitung solcher Fehler bietet sich ein globaler Handler an. Hilfe und Dokumentation Es ist nicht verboten, sich von anderen, gut durchdachten Lösungen anregen zu lassen. Empfehlenswert ist zum Beispiel ein Blick auf das Hilfe- und Supportcenter von Windows. Hilfe und Dokumentation komplett auf dem Client, das klingt logisch und funktioniert auch. Andererseits wird der größte Teil davon erfahrungsgemäß nie angeschaut werden. Ein Smart Client soll doch online verteilt und aktualisiert werden. Macht es da nicht Sinn, wenn diese Informationen auf dem Server bleiben, bis sie gebraucht werden? Natürlich muss der grundlegende Teil, zum Beispiel die Anleitung zur Fehlerbehebung bei Netzwerkproblemen, immer lokal verfügbar bleiben. Ist in ihrem Anwendungsfall eine verteilte Dokumentation denkbar? Erst wird die Information lokal gesucht und bei Misserfolg auf den Server weitergeleitet? Dann ist es kein allzu großer Schritt mehr bis zum Angebot, direkt eine Verbindung zum Supportcenter herzustellen. Installation und Update Ein grundlegendes Merkmal eines Smart Client ist die Möglichkeit, ihn online zu verteilen und zu aktualisieren. Eine automatische, zwangsweise Aktualisierung stellt sicher, dass jeder Benutzer immer nur mit der neuesten Version arbeitet. Wartung und Support sind erheblich einfacher, wenn ältere Versionen nicht unterstützt werden müssen. Zentrale Services müssen nur mit einer einzigen Version des Clients zusammenarbeiten. In vielen Anwendungen muss die Datenbasis oder die Programmlogik in regelmäßigen Abständen aktualisiert werden, zum Beispiel bei jährlichen Anpassungen an geänderte Steuergesetze. Das beeinflusst die Frage, ob eine Komponente am besten auf den Client oder auf den Server gehört. Wo liegt die aktuelle Wetterkarte und wo die Kartenbasis eines Routenplaners? Zwei maßgebliche Faktoren sind also die voraussichtliche Häufigkeit einer Aktualisierung und die dabei zu übertragende Datenmenge. Daten, die sehr schnell veralten und/ oder nur sporadisch gebraucht werden, gehören nicht auf den Client. Aber auch Daten, die vielleicht nur einmal im Jahr www.javamagazin.de © Software & Support Verlag GmbH 2006 9.2006 special Smart Clients aktualisiert werden müssen, dann aber viele Megabyte Update bedeuten würden, sind auf dem Server besser aufgehoben. Um der Bedeutung der automatischen Verteilung und Aktualisierung als eine der Kernkomponenten eines Smart Client gerecht zu werden, wird sich ein eigener Artikel mit deren Technik befassen. Fazit Ein Smart Client macht die Entwicklung einer Anwendung nicht automatisch einfacher. Seine Stärke ist die Flexibilität, die mehr Möglichkeiten der Umsetzung erlaubt. Ob ein Service auf dem Client oder auf dem Server liegt, wird nicht durch die verwendete Technologie vorgegeben. Stattdessen liegt es in der Verantwortung des Entwicklungsteams, die für die gegebene Problemstellung jeweils am besten geeignete Lösung zu finden. Falls sich diese Lösung später doch nicht als optimal herausstellt oder sich die Rahmenbedingungen ändern, kann der Service leicht verlagert werden. Das verringert das Risiko und erleichtert den Einstieg in die Entwicklung mit einem Smart-Client-Framework. Oliver Kleber arbeitet als IT-Consultant bei der compeople AG in Frankfurt. Seine Schwerpunkte sind Client-Server-Frameworks, agile Entwicklungsmethoden und Build-Management. Links & Literatur [1] spirit Smart Client Framework: www.compeople.de/smartclient.html 9
Seite 1 und 2: Smart Clients, Teil 1: Was ist ein
Seite 3 und 4: Fremdanwendungen stellt er eine Alt
Seite 5 und 6: Smart Clients, Teil 2: Aspekte eine
Seite 7: nicht möglich ist, muss das Design

Smart Clients - Definition, Abgrenzung und Aspekte ... - Compeople

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?