Μετάβαση στο κύριο περιεχόμενο

Εφαρμογή υπολογιστή που λειτουργεί χωρίς σύνδεση

Μάθετε πώς σχεδιάζεται μια εφαρμογή υπολογιστή που συνεχίζει να λειτουργεί χωρίς διαδίκτυο, με ασφαλή τοπική αποθήκευση, συγχρονισμό και διαχείριση συγκρούσεων.

Εφαρμογή υπολογιστή που λειτουργεί χωρίς σύνδεση

Μια εφαρμογή υπολογιστή που λειτουργεί χωρίς σύνδεση κρατά διαθέσιμες τις βασικές οθόνες, τα δεδομένα και τις ενέργειες στον υπολογιστή, ακόμη και όταν διακοπεί το διαδίκτυο. Όταν επανέλθει η σύνδεση, οι εκκρεμείς αλλαγές μεταφέρονται στον κεντρικό διακομιστή. Η λύση αξίζει μόνο όταν οι επιχειρησιακές ανάγκες δικαιολογούν την πρόσθετη πολυπλοκότητα.

Όταν το δίκτυο πέφτει, η εργασία δεν πρέπει να σταματά

Σε μια αποθήκη, σε ένα κατάστημα ή σε ένα γραφείο με ασταθή σύνδεση, η διακοπή του δικτύου δεν πρέπει να διαγράφει την πρόοδο της ημέρας. Η εφαρμογή χρειάζεται να επιτρέπει τις κρίσιμες ενέργειες τοπικά: καταχώριση παραλαβής, ενημέρωση αποθέματος, δημιουργία παραγγελίας ή συμπλήρωση μιας φόρμας.

Η λογική αυτή συχνά περιγράφεται ως εφαρμογή «πρώτα εκτός σύνδεσης». Δεν σημαίνει ότι όλα τα δεδομένα είναι μόνιμα διαθέσιμα παντού. Σημαίνει ότι η εργασία συνεχίζεται με ένα ελεγχόμενο τοπικό αντίγραφο και ότι ο κεντρικός διακομιστής ενημερώνεται αργότερα.

Αυτό έχει κόστος. Χρειάζονται σαφείς κανόνες για τον συγχρονισμό δεδομένων χωρίς σύνδεση, τις συγκρούσεις και την ανάκτηση μετά από βλάβη. Αν η επιχείρηση απαιτεί κοινή εικόνα σε πραγματικό χρόνο, ίσως ταιριάζει καλύτερα μια πλήρως διαδικτυακή ή υβριδική λύση.

Πώς μοιράζεται η εφαρμογή τη δουλειά ανάμεσα στον υπολογιστή και τον διακομιστή

Η βασική αρχιτεκτονική έχει δύο πλευρές. Στον υπολογιστή υπάρχει τοπική βάση δεδομένων, μαζί με προσωρινή αποθήκευση και καταγραφή των ενεργειών που έγιναν εκτός σύνδεσης. Στον κεντρικό διακομιστή βρίσκεται η κοινή, πιο ολοκληρωμένη εικόνα της επιχείρησης.

Το πρώτο πρακτικό ερώτημα είναι τι χρειάζεται πραγματικά ο χρήστης όταν δεν υπάρχει σύνδεση. Ένας υπάλληλος αποθήκης μπορεί να χρειάζεται τον κατάλογο προϊόντων, τις ποσότητες και τις ανοιχτές εργασίες της βάρδιας. Δεν χρειάζεται κατ’ ανάγκη όλο το ιστορικό παραγγελιών ή κάθε αναφορά της διοίκησης.

Ο περιορισμός των τοπικών δεδομένων μειώνει τη χρήση δίσκου και τον κίνδυνο έκθεσης ευαίσθητων πληροφοριών. Παράλληλα, η εφαρμογή πρέπει να δείχνει καθαρά την κατάσταση σύνδεσης. Ο χρήστης χρειάζεται να γνωρίζει αν μια ενέργεια αποθηκεύτηκε μόνο τοπικά, αν περιμένει αποστολή ή αν επιβεβαιώθηκε από τον διακομιστή.

Η ταυτοποίηση και τα δικαιώματα χρειάζονται ειδική μελέτη. Το ότι ο υπολογιστής λειτουργεί εκτός σύνδεσης δεν σημαίνει ότι πρέπει να παρακάμπτονται οι περιορισμοί πρόσβασης. Μπορεί να χρειαστεί περιορισμένη περίοδος χρήσης χωρίς επαλήθευση, αποθηκευμένα δικαιώματα με ημερομηνία λήξης ή απαγόρευση συγκεκριμένων λειτουργιών έως ότου επανέλθει το δίκτυο.

Τα τοπικά δεδομένα πρέπει επίσης να προστατεύονται με κατάλληλη κρυπτογράφηση, ασφαλή διαχείριση κωδικών και πολιτικές για χαμένους υπολογιστές. Καμία τεχνική επιλογή δεν εγγυάται από μόνη της πλήρη ασφάλεια. Οι απαιτήσεις πρέπει να καταγραφούν μαζί με τα δεδομένα που θα αποθηκεύονται και τον κίνδυνο που έχει η απώλειά τους.

Ο σχεδιασμός της βάσης προηγείται των οθονών. Οι σχέσεις, οι περιορισμοί, η κανονικοποίηση και τα ευρετήρια επηρεάζουν άμεσα την αξιοπιστία της λύσης. Δείτε τον σχεδιασμό βάσης δεδομένων για επιχειρήσεις πριν αποφασίσετε ποια δεδομένα θα παραμένουν τοπικά.

Τι γίνεται όταν επανέλθει το δίκτυο;

Όταν επανέλθει το δίκτυο, η εφαρμογή εντοπίζει τις εκκρεμείς ενέργειες, τις στέλνει στον διακομιστή, λαμβάνει τυχόν νεότερες ενημερώσεις και επιβεβαιώνει ποιες ολοκληρώθηκαν. Ο συγχρονισμός πρέπει να έχει συγκεκριμένη σειρά, καταγραφή και τρόπο επανάληψης όταν μια αποστολή αποτύχει.

Συνήθως η ροή περιλαμβάνει τα εξής βήματα:

  • Έλεγχο της σύνδεσης και ανάκτηση των εκκρεμών ενεργειών.
  • Αποστολή κάθε ενέργειας μαζί με αναγνωριστικό και στοιχεία έκδοσης.
  • Έλεγχο από τον διακομιστή για δικαιώματα, εγκυρότητα και πιθανή σύγκρουση.
  • Ενημέρωση της τοπικής βάσης με την απάντηση και τα νεότερα δεδομένα.
  • Εμφάνιση σαφούς κατάστασης στον χρήστη, ακόμη και όταν απαιτείται παρέμβαση.

Εδώ χρειάζεται μια ουρά εργασιών. Είναι ένας κατάλογος ενεργειών που περιμένουν αποστολή, μαζί με την κατάστασή τους: σε αναμονή, σε προσπάθεια, ολοκληρωμένη ή αποτυχημένη. Η ουρά δεν πρέπει να κρύβεται. Αν ο χρήστης δημιούργησε πέντε παραγγελίες και μόνο οι τρεις έφτασαν στον διακομιστή, αυτό πρέπει να φαίνεται καθαρά.

Οι αποτυχημένες ενέργειες μπορούν να επαναληφθούν, αλλά όχι επ’ αόριστον και όχι χωρίς έλεγχο. Η εφαρμογή χρειάζεται όριο προσπαθειών, καθυστέρηση ανάμεσα στις επαναλήψεις και μήνυμα που εξηγεί το πρόβλημα. Ένα προσωρινό σφάλμα δικτύου διαφέρει από μια απορριφθείσα τιμή ή μια αλλαγή δικαιωμάτων.

Σημαντική είναι και η ασφαλής επανάληψη μιας ίδιας ενέργειας χωρίς διπλή εγγραφή. Αν η σύνδεση διακοπεί αμέσως μετά την αποστολή μιας παραγγελίας, η εφαρμογή πρέπει να μπορεί να ελέγξει αν αυτή καταχωρίστηκε ήδη. Διαφορετικά, μια αυτόματη επανάληψη μπορεί να δημιουργήσει δεύτερη παραγγελία.

Οι κανόνες αυτοί συνδέονται άμεσα με τον σχεδιασμό της βάσης δεδομένων και των επιχειρησιακών διαδικασιών. Χρειάζονται μοναδικά αναγνωριστικά, χρονικές σημάνσεις, εκδόσεις εγγραφών και ιστορικό όπου το ρίσκο το απαιτεί. Η τεχνική υλοποίηση δεν μπορεί να διορθώσει μια διαδικασία που δεν έχει ξεκαθαρίσει ποια αλλαγή υπερισχύει.

Οι συγκρούσεις δεδομένων δεν λύνονται όλες με έναν κανόνα

Σύγκρουση προκύπτει όταν δύο χρήστες ή συσκευές αλλάζουν την ίδια εγγραφή χωρίς να γνωρίζουν ο ένας την αλλαγή του άλλου. Για παράδειγμα, δύο υπάλληλοι μπορούν να ενημερώσουν εκτός σύνδεσης την ποσότητα του ίδιου προϊόντος. Όταν συνδεθούν, το σύστημα πρέπει να αποφασίσει πώς θα συνδυάσει τις αλλαγές.

Η επιλογή «τελευταία αλλαγή κερδίζει» είναι απλή, αλλά μπορεί να σβήσει χρήσιμη πληροφορία. Ταιριάζει μόνο σε δεδομένα όπου η νεότερη τιμή θεωρείται πράγματι σωστή. Σε άλλες περιπτώσεις μπορούν να εφαρμοστούν διαφορετικοί κανόνες:

  • Συγχώνευση ανά πεδίο, όταν οι χρήστες άλλαξαν διαφορετικά στοιχεία της ίδιας εγγραφής.
  • Προτεραιότητα σε συγκεκριμένο ρόλο ή πηγή, όταν μια ενημέρωση έχει μεγαλύτερη επιχειρησιακή βαρύτητα.
  • Άθροιση ή αφαίρεση κινήσεων, όταν δεν αποθηκεύεται μόνο ένα τελικό υπόλοιπο.
  • Χειροκίνητη επίλυση, όταν ένα λάθος μπορεί να επηρεάσει τιμολόγηση, απόθεμα ή συμμόρφωση.

Σε μια διαδικασία αποθήκης, ίσως είναι προτιμότερο να καταγράφονται οι κινήσεις εισόδου και εξόδου αντί να αλλάζει απευθείας ένα κοινό υπόλοιπο. Σε μια παραγγελία, όμως, η αλλαγή κατάστασης μπορεί να απαιτεί έγκριση και ιστορικό. Το κόστος του λάθους καθορίζει τον κανόνα, όχι η ευκολία του προγραμματισμού.

Όταν απαιτείται χειροκίνητη επίλυση, το μήνυμα προς τον χρήστη πρέπει να είναι κατανοητό. Ποιος άλλαξε τι, πότε, από ποια συσκευή και ποια επιλογή θα επηρεάσει την τελική εγγραφή; Χωρίς αυτές τις πληροφορίες, η «επίλυση» μετατρέπεται σε τυχαία επιλογή.

Αποθήκευση, αντίγραφα ασφαλείας και έλεγχος αποτυχίας

Η τοπική αποθήκευση δεδομένων χρειάζεται όρια. Ο δίσκος του υπολογιστή δεν είναι ανεξάντλητος, η βάση μπορεί να μεγαλώνει και παλιές εκκρεμείς εγγραφές μπορεί να συσσωρεύονται. Χρειάζονται πολιτικές για τη διατήρηση δεδομένων, την εκκαθάριση προσωρινών αρχείων και τον έλεγχο ακεραιότητας της τοπικής βάσης.

Το αντίγραφο ασφαλείας δεν είναι το ίδιο με τον συγχρονισμό. Ο συγχρονισμός μεταφέρει αλλαγές μεταξύ συστημάτων. Το αντίγραφο ασφαλείας βοηθά στην επαναφορά μετά από διαγραφή, βλάβη, καταστροφή ή απώλεια συσκευής. Μια εφαρμογή που συγχρονίζει λάθος δεδομένα μπορεί να διαδώσει το λάθος, ενώ ένα σωστό αντίγραφο επιτρέπει επιστροφή σε προηγούμενη κατάσταση.

Πριν από την υλοποίηση χρειάζεται να οριστούν η συχνότητα αντιγράφων, η διάρκεια διατήρησης, η θέση αποθήκευσης και τα δικαιώματα πρόσβασης. Ακόμη σημαντικότερη είναι η δοκιμή επαναφοράς. Ένα αντίγραφο που δεν έχει αποκατασταθεί ποτέ δεν έχει αποδείξει ότι μπορεί να χρησιμοποιηθεί σε κρίσιμη στιγμή.

Για σύγκριση με αρχιτεκτονικές που βασίζονται περισσότερο σε κεντρική πρόσβαση, δείτε τις προσαρμοσμένες διαδικτυακές εφαρμογές. Η επιλογή δεν είναι διαγωνισμός ανάμεσα σε εφαρμογή υπολογιστή και διαδικτυακή εφαρμογή. Εξαρτάται από τη διαθεσιμότητα δικτύου, την κινητικότητα των χρηστών, τις απαιτήσεις δεδομένων και το κόστος υποστήριξης.

Πότε η λειτουργία χωρίς σύνδεση δεν είναι η σωστή επιλογή

Η λειτουργία χωρίς σύνδεση δεν ταιριάζει σε κάθε έργο. Αν όλοι χρειάζονται την ίδια ενημερωμένη εικόνα κάθε στιγμή, η καθυστέρηση συγχρονισμού μπορεί να δημιουργεί μεγαλύτερο κίνδυνο από μια προσωρινή διακοπή. Το ίδιο ισχύει για συναλλαγές που απαιτούν άμεσο έλεγχο υπολοίπου, εγκρίσεων ή διαθεσιμότητας.

Η πλήρως διαδικτυακή λειτουργία απλοποιεί τη διαχείριση κοινών δεδομένων, αλλά εξαρτάται από το δίκτυο. Η τοπική λειτουργία προσφέρει συνέχεια, όμως αυξάνει τις απαιτήσεις για συγχρονισμό, υποστήριξη και προστασία συσκευών. Η υβριδική λύση κρατά εκτός σύνδεσης μόνο τις κρίσιμες εργασίες. Καμία επιλογή δεν είναι καθολικά καλύτερη.

Χρειάζεται επίσης να υπολογιστεί αν η ενημέρωση μετά τον συγχρονισμό πρέπει να ενεργοποιεί επόμενες εργασίες. Για παράδειγμα, μια επιβεβαιωμένη παραλαβή μπορεί να ξεκινά ειδοποίηση ή ανανέωση αποθέματος. Σε τέτοιες ροές, η έξυπνη αυτοματοποίηση χρειάζεται σαφείς κανόνες για το πότε θεωρείται έγκυρο ένα γεγονός.

Λίστα ελέγχου πριν ξεκινήσει ο σχεδιασμός

  • Ποιες λειτουργίες πρέπει να συνεχίζονται χωρίς σύνδεση;
  • Ποια δεδομένα χρειάζεται πραγματικά κάθε ρόλος στον υπολογιστή;
  • Πόσες ώρες ή ημέρες πρέπει να αντέχει η εφαρμογή χωρίς δίκτυο;
  • Πώς θα φαίνεται στον χρήστη ότι μια ενέργεια δεν έχει ακόμη συγχρονιστεί;
  • Τι γίνεται όταν δύο συσκευές αλλάζουν την ίδια εγγραφή;
  • Ποια δεδομένα χρειάζονται ιστορικό αλλαγών και χειροκίνητη επίλυση;
  • Πώς θα αποφεύγονται οι διπλές εγγραφές μετά από επαναλήψεις;
  • Πώς προστατεύονται τα δεδομένα σε περίπτωση απώλειας ή κλοπής συσκευής;
  • Πότε δημιουργούνται αντίγραφα ασφαλείας και πώς δοκιμάζεται η επαναφορά;
  • Πώς θα παρακολουθούνται αποτυχημένες ουρές εργασιών και προβληματικές συσκευές;
  • Έχουν δοκιμαστεί διακοπή δικτύου, διπλές αλλαγές, γεμάτος δίσκος και βλάβη βάσης;

Οι απαντήσεις σε αυτά τα ερωτήματα δίνουν πιο χρήσιμη βάση για τεχνική προσφορά από μια γενική απαίτηση του τύπου «να δουλεύει και χωρίς διαδίκτυο». Κυρίως, δείχνουν αν η λειτουργία χωρίς σύνδεση λύνει πραγματικό πρόβλημα ή αν μεταφέρει απλώς την πολυπλοκότητα σε ένα σημείο που δεν έχει ακόμη σχεδιαστεί.

Συμπέρασμα: σχεδιάστε πρώτα τη συμπεριφορά σε αποτυχία

Μια εφαρμογή υπολογιστή χωρίς σύνδεση αξίζει όταν η συνέχεια της εργασίας είναι πιο σημαντική από το κόστος του συγχρονισμού και οι κανόνες δεδομένων είναι ξεκάθαροι. Καταγράψτε πρώτα τα σενάρια διακοπής, τις συνέπειες κάθε σύγκρουσης και τις απαιτήσεις επαναφοράς. Μετά επιλέξτε αρχιτεκτονική και ξεκινήστε την ανάπτυξη.