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

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

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

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

• Ενημέρωση μέσω MSMQ
• Ενημέρωση μέσω Notification Services (νομίζω είναι διαθέσιμο και στον SQLExpress πλέον)

Ποια είναι τα συν και τα πλην τις κάθε λύσεις; Σαν βάση μιλάμε πάντα για SQLExpress. Επίσης στα χαρτιά υπάρχει η πρόβλεψη η εφαρμογή να παίζει και από ένα φορητό το οποίο θα βρίσκεται έξω από την εταιρεία αλλά με σύνδεση στην κεντρική βάση της εταιρείας, οπότε σε αυτό το σημείο τίθεται θέμα σύνδεσης μέσω internet και ότι αυτό συνεπάγεται. Ποια από τις δύο παραπάνω λύσεις είναι πιο φιλική στο σενάριο που παρουσιάζω; Υπάρχει και κάποια τρίτη που πιθανότατα δεν μου έχει περάσει από το μυαλό;

Ευχαριστώ.

Έχουμε κάνει σχετικές κουβέντες στο παρελθόν:

http://www.dotnetzone.gr/cs/forums/thread/40074.aspx
http://www.dotnetzone.gr/cs/forums/thread/40589.aspx

Για να καταλάβω το σενάριο που έχεις, θες δηλαδή να συγχρονίζονται τοπικές βάσεις μεταξύ τους; 'Η με κάποια κεντρική βάση; Ή με κάποια κεντρική βάση αλλά και μεταξύ τους; Και βάσει ποιάς λογικής θα κάνουν refresh τα data τους οι clients; Απ' ότι κατάλαβα, σε ενδιαφέρει ιδιαίτερα ο μηχανισμός του "πότε"; Γενικά, όταν μιλάμε για συγχρονισμό, το θέμα του "πότε" δεν είναι τόσο μεγάλο πρόβλημα, όσο το θέμα του "πως".

Συγνώμη μάλλον δεν έγινα κατανοητός για το σενάριο.

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

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

Ρίξε μία ματιά στο SqlDependency class, το Query Notifications in SQL Server και το Using SqlDependency in a Windows Application για ένα step-by-step παράδειγμα. Το SqlDependency παρακολουθεί τα αποτελέσματα ενός query και όταν αλλάξουν σε ειδοποιεί με το OnChanged event. ΔΕΝ χρησιμοποιεί Notification Services, αλλά το Service Broker, χωρίς όμως εσύ να τον χρησιμοποιείς άμεσα ή έστω να τον αντιλαμβάνεσαι. Απλά πρέπει να βεβαιωθείς ότι ο Service Broker τρέχει.

Μία άλλη λύση είναι τα Synchronization Services for ADO.NET τα οποία δημιουργούν μία τοπική cache με τα δεδομένα της βάσης που θέλεις να χρησιμοποιήσεις και αναλαμβάνουν την επικοινωνία με το server και το synchronization, ακόμα και 2 κατευθύνσεων, όταν το ζητήσεις. Τα Sync Services δεν απαιτούν συνεχή σύνδεση με τη βάση, οπότε παίζουν ακόμα και σε disconnected σενάρια. Από την άλλη, δεν καταλαβαίνουν αμέσως ότι κάτι άλλαξε στη βάση. Θα πρέπει εσύ να ζητήσεις το syncrhonization. Στην περίπτωση σου όμως θα μπορούσες να χρησιμοποιήσεις ένα συνδυασμό SqlDependency και Sync Services για να έχεις και την τοπική σου cache, και την άμεση ειδοποίηση για τους clients του δικτύου. Στο internet θα μπορούσες να χρησιμοποιήσεις τον ίδιο κώδικα μεν,αλλά αντί για dependency να έχεις ένα timer

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

Πάντως, δεν μπορώ να φανταστώ τη χρησιμότητα ενός Queue Server... Γενικά (και χονδρικά), το message queueing χρησιμοποιείται όταν οι clients πρέπει να στείλουν κάποια data στον server, με ρυθμό που να μην προλαβαίνει ο server να τα διαχειριστεί, οπότε τα στέλνουν στο queue και ξεμπερδεύουν χρήγορα. Από την άλλη μεριά, τα Notification Services είναι πλέον obsolete τεχνολογία καθώς σταμάτησαν να παρέχονται στον SQL Server 2008.

Μπορείς ωστόσο να χρησιμοποιήσεις τα Query Notifications τα οποία δεν έχουν να κάνουν με τα Notification Services και έχουν πιο απλό API. Τα έχω χρησιμοποιήσει και ήταν πολύ εύκολα στην υλοποίηση, ωστόσο είχα ένα θέμα γιατί οι περισσότεροι clients ήταν wireless με αποτέλεσμα (ίσως λόγω broadcast?) να μπλοκάρουν αρκετά οι clients. Όσο έπαιζα με ενσύρματους clients ήταν μια χαρά. Μπορείς να το δοκιμάσεις πάντως στο θέμα του wireless, ίσως να ήταν προβληματικό το setup που μου είχε τύχει.

Νομίζω ότι το Query Notifications είναι μια αρκετά καλή λύση.

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

Το ένα έχει να κάνει με το Query Notifications & SQLExpress. Όπως είπα η βάση θα είναι SQLExpress. Διαβάζοντας είδα ότι το QN δεν υποστηρίζεται για τον SQLExpress αν και μερικοί είπαν πως τα κατάφεραν και δουλεύουν πάνω στον SQLExpress. Ίσως περισσότερο διάβασμα να μου λύση τελικά την απορία αυτή.

Το δεύτερο έχει να κάνει με τις πληροφορίες που πέρνω πίσω από το event. Πουθενά δεν μου έχει την εγγραφή που άλλαξε. Ίσως είναι κάτω από κάποιο property που δεν έχω διαβάσει, δει ακόμα. Είναι πολύ βασικό να πάρω και τις τιμές του record που έχει αλλάξει έτσι ώστε με το Change Type ξέρω αν έχω μεταβολή, νέα καταχώρηση ή διαγραφή οπότε να μπορώ να επέμβω άμεσα στο DataCollection μου και να ενημερώσω ανάλογα. Σε καμία περίπτωση δεν θέλω όταν ο χρήστης είναι μέσα σε ένα Grid ξαφνικά το Grid να γίνεται συνολικά Refresh και να πετάει τον χρήστη στην αρχική εγγραφή του Grid ή σε κάποια άλλη τυχαία εγγραφή.

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

Σε SQL Server Express παίζουν μια χαρά, απλά πρέπει το setup να το κάνεις με TSQL Commands καθώς το SSMS δεν παρέχει visual τρόπο. Δεν είναι δύσκολο, μερικές εντολές είναι.

Ως προς το δεύτερο θέμα, αν θυμάμαι καλά, όντως δεν σου φέρνει τις αλλαγές, ωστόσο αν μιλάμε για DataSets είναι αρκετά εύκολο να δεις ποιά data είναι διαφορετικά. Φτιάχνεις ένα νέο DataSet. Κάνεις το τρέχον dataset merge με το νέο, κάνεις AcceptChanges και μετά ξανακάνεις το αποτέλεσμα Merge με το DataSet που ξανατραβάς αφού πάρεις το notification. Mετά παίρνεις τις διαφορές με GetChanges. Ακούγεται περίπλοκο αλλά είναι 4 γραμμές κώδικας:

Dim dsNew as DataSet  = new DataSet()
dsNew.Merge(dsOriginal)
dsNew.AcceptChanges()
dsNew.Merge(dsRefresh)

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

Τα άσχημα της υπόθεσης είναι

• Όταν ο SQL στείλει στην εφαρμογή μου ειδιποίηση ότι τα δεδομένα έχουν αλλάξει τότε βγάζει από το Service Broker την αίτησή μου να ενημερώνομαι για τις αλλαγές που μπορούν να γίνουν σε αυτές τις εγγραφές. Θα πρέπει να τρέξω ξανά το query έτσι ώστε ο Service Broker να καταχωρήσει νέο Dependency.
• Οι πληροφορίες που πέρνω πίσω είναι απλά ότι έγινε μία αλλαγή (σωστά το αναφέρεις KelMan) και όχι πια αλλαγή ήταν αυτή. Συνδέστε αυτό με το επάνω.
• Δεν συνιστάτε όταν έχουμε πολλούς Clients, ας πούμε ένα νούμερο πάνω από 10 σε αναλογία βέβαια σε τι βαθμό χρησιμοποιούμε QN και πάνω σε ποια δεδομένα. Γενικώς συνιστάτε να μην χρησιμοποιείται σε δεδομένα που αλλάζουν συχνά. Εδώ υπάρχει ένα μικρό πρόβλημα θα έλεγα.
• Οι ειδοποιήσεις του SQL Server επιστρέφονται μέσα από μία μόνο SQLConnection την οποία θα πρέπει να ανοίξουμε από την αρχή της εφαρμογής μας και να κλείσουμε στο τέλος. Οπότε ότι inserts, updates deletes θα θέλαμε να κάνουμε θα πρέπει να δημιουργήσουμε νέες συνδέσεις. Μικρό το κακό από την μία, από την άλλη αν κάποιος βασίζεται πάνω στις συνδέσεις που γίνονται στον SQL Server για να μετρήσει πόσοι χρήστες έχουν την δυνατότητα να χρησιμοποιούν την εφαρμογή του θα πρέπει να το βρει με άλλο τρόπο.

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

Στα θετικά της ιστορίας βάζω

• Το απλό γράψιμο κώδικα για να στηθεί από την μεριά της εφαρμογής μου.
• Δεν χρειάζεται να στήσουμε πολλά πράγματα για να παίξει.
• Παίζει κάτω από SQLExpress. Σωστά kelMan βρήκα ένα άρθρο για αυτό.

Όσο για τις ενημερώσεις δυστυχώς, για αυτή την περίπτωση λέω δυστυχώς, έχω εκφράσει την γνώμη μου για τα datasets παλαιότερα, δεν τα χρησιμοποιώ. Αν και δεν είμαι τόσο σίγουρος αν θα βοηθούσαν τελικά. Όχι ότι ο τρόπος που προτείνεις είναι λάθος, αλλά πρακτικά δεν ξέρω πόσο καλά θα παίξει. Είπα στην αρχή ότι τα δεδομένα δεν είναι πολλά δεν είναι όμως και 100 εγγραφές. Σίγουρα όταν ξεκινάει η εφαρμογή θα φορτώνει γύρω στις 3000-10000, το πολύ, εγγραφές. Φαντάζεσαι αυτό με τα datasets να γίνεται, έχοντας QN σε εταιρεία με 12 άτομα προσωπικό σε μόνιμη βάση, συν τους εποχικούς που θα πέρνει... Δεν μου ακούγεται καλό αυτό... Όποτε θα προσπαθούν να γράφουν η εφαρμογή θα δείχνει ότι ψιλό κολλάει για λίγο.

infoCENTER:

• Οι ειδοποιήσεις του SQL Server επιστρέφονται μέσα από μία μόνο SQLConnection την οποία θα πρέπει να ανοίξουμε από την αρχή της εφαρμογής μας και να κλείσουμε στο τέλος. Οπότε ότι inserts, updates deletes θα θέλαμε να κάνουμε θα πρέπει να δημιουργήσουμε νέες συνδέσεις. Μικρό το κακό από την μία, από την άλλη αν κάποιος βασίζεται πάνω στις συνδέσεις που γίνονται στον SQL Server για να μετρήσει πόσοι χρήστες έχουν την δυνατότητα να χρησιμοποιούν την εφαρμογή του θα πρέπει να το βρει με άλλο τρόπο.

Ουσιαστικά εάν θες να τους μετρήσεις, μπορείς απλά να έχεις.. N*2 (οπού Ν=clients) συνδεμένους. Αφού πάντα έχεις ένα ανοιχτό connection για τα QN, τότε ξέρεις ότι πάντα πρέπει να "προσθέτεις" ένα connection ακόμα.

infoCENTER:

• Όταν ο SQL στείλει στην εφαρμογή μου ειδιποίηση ότι τα δεδομένα έχουν αλλάξει τότε βγάζει από το Service Broker την αίτησή μου να ενημερώνομαι για τις αλλαγές που μπορούν να γίνουν σε αυτές τις εγγραφές. Θα πρέπει να τρέξω ξανά το query έτσι ώστε ο Service Broker να καταχωρήσει νέο Dependency.

Ως προς τα παραπάνω, είναι λογική αυτή η συμπεριφορά. Μόλις πάρεις το notification, δεν έχει νόημα να συνεχίσει να στέλνει o server notifications. Οπότε όταν θα ξαναζητήσεις τα data για να δεις τι ακριβώς αλλαγές έχουν γίνει, τότε ξαναsetάρεις (sic!) το depedency.

infoCENTER:

Όσο για τις ενημερώσεις δυστυχώς, για αυτή την περίπτωση λέω δυστυχώς, έχω εκφράσει την γνώμη μου για τα datasets παλαιότερα, δεν τα χρησιμοποιώ. Αν και δεν είμαι τόσο σίγουρος αν θα βοηθούσαν τελικά. Όχι ότι ο τρόπος που προτείνεις είναι λάθος, αλλά πρακτικά δεν ξέρω πόσο καλά θα παίξει. Είπα στην αρχή ότι τα δεδομένα δεν είναι πολλά δεν είναι όμως και 100 εγγραφές. Σίγουρα όταν ξεκινάει η εφαρμογή θα φορτώνει γύρω στις 3000-10000, το πολύ, εγγραφές. Φαντάζεσαι αυτό με τα datasets να γίνεται, έχοντας QN σε εταιρεία με 12 άτομα προσωπικό σε μόνιμη βάση, συν τους εποχικούς που θα πέρνει... Δεν μου ακούγεται καλό αυτό... Όποτε θα προσπαθούν να γράφουν η εφαρμογή θα δείχνει ότι ψιλό κολλάει για λίγο.

Τη σύγκριση παλιών με φρέσκων δεδομένων μπορείς να την κάνεις και χειροκίνητα. Ο βαθμός δυσκολίας έχει να κάνει ανάλογα με τη φύση των δεδομένων και το business logic. Πάντως, όπως και να έχει, με κάθε notification να τραβολογάς 10000 εγγραφές δεν είναι και λίγο πράγμα. Καλύτερα να αξιολογήσεις τη δεύτερη λύση που σου πρότεινε ο Παναγιώτης, notification services σε συνδυασμό με τοπική light βάση και sync services.

Δεν βλέπω αρνητικά τα QN. Είμαι ακόμα θετικός στην σκέψη αυτή και όπως είπα σίγουρα θα μετρήση μαζί με αυτές που ανέφερα στην αρχή.

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

Στην αρχή ανέφερα MSMQ, ας μιλήσουμε λίγο για αυτό. Από μία πρώτη εικόνα που έχω, είναι ότι θα μπορούσα μέσα από εκεί να στείλω ότι πληροφορία θέλω. Θα μπορούσα δηλαδή να πέρνω είτε ολόκληρη την εγγραφή, οπότε καμία επικοινωνία με την βάση, είτε ας πούμε το id της εγγραφής που έχει γίνει update, delete, insert οπότε η πρόσβαση στην βάση μου να είναι πιο συγκεκριμένη. Φυσικά αυτό σημαίνει πως όταν ένα μηχάνημα είναι offline και μπει online ίσως το περιμένουν ένα σωρό μηνύματα από το MSMQ αλλά εύκολα μπορείς να τα απορρίψεις από την στιγμή που έχεις πάρει μία πιο πρόσφατη εικόνα των δεδομένων. Το μήνυμα ότι κάτι καταχωρήθηκε δεν θα το στέλνει ο SQL αλλά ο σταθμός που όντως έκανε την καταχώρηση, οπότε θα μπορούσε να κάνει serialize το object και να το στείλει στο MSMQ μαζί με κάποιες άλλες πληροφορίες. Οπότε οι σταθμοί θα μπορούσαν να το παραλάβουν και άμμεσα να το βάλουν στην λίστα με τις υπόλοιπες εγγραφές χωρίς κάποια πρόσβαση στην βάση. Δείχνει η τέλεια λύση με όλα τα παραπάνω που με προβληματίζουν, είναι όμως; Δεν έχω ασχοληθεί ξανά, οπότε δεν γνωρίζω τι δυσκολίες μπορεί να έχει αυτή η προσπάθεια μπορεί κάποιος που έχει ασχοληθεί να μου πει αρνητικά ή θετικά σχόλια;

Τι γνώμη έχετε για αυτό; Θα το συνιστούσατε ως λύση σε ένα παρόμοιο σενάριο;

Υστ : Σχετικά με τις συνδέσεις. Κοίτα δεν είναι εύκολο να πεις Ν * 2 οπότε πάνω από ένα αριθμό συνδέσεων να υποθέσεις ότι δεν μπορούν να μπουν άλλοι χρήστες. Ανάλογα με το πως σχεδιάζετε μία εφαρμογή δεν είναι ανάγκη όλες οι φόρμες να γίνονται αυτόματα Refresh. Συνήθως το Refresh το θέλουμε σε φόρμες που μας δίνουν μία γενική εικόνα. Αν ένας χρήστης έχει ανοίξει μόνο μία φόρμα και αυτή είναι η φόρμα των καταχωρήσεων τότε όπως καταλαβαίνεις αντί να έχω 10 χρήστες στην εφαρμογή μου με τον κανόνα 10 * 2, μπορεί τελικά να καταλήξω να έχω από 10 και πάνω, από την στιγμή που μερικοί δεν θα χρειάζεται να ανοίξουν και δεύτερο connection για να παρακολουθούν τις ενημερώσεις. Εκτός φυσικά και αν ανοίξεις μία dummy connection και την κρατάς ανοιχτή. χμ... μήπως τελικά αυτή η Microsoft μας γυρίζει γύρω γύρω; Από την μία φύγαμε από την μόνιμη σύνδεση με την βάση και πήγαμε στο απομακρυσμένο μοντέλο και από την άλλη γυρνάμε πάλι στην μόνιμη σύνδεση;

Υστ 2: Βασικά KelMan η πρώτη μου σκέψη ήταν να σταματάει το Notification όταν θα κλείνει το Connection. Με ξένισε λίγο όταν είδα ότι δεν γίνεται όταν το πρωτοδιάβασα, αλλά κατάλαβα ότι από την στιγμή που δεν σου δίνει κάποια πληροφορία τι έχει αλλάξει, οπότε υποχρεωτικά θα πας στην βάση για να ξανακάνεις ερώτημα, το έφτιαξαν έτσι. Και πάλι όμως δεν με πείθει η συγκεκριμένη σκέψη για διάφορους λόγους και σενάρια. Θα περίμενα όταν κλείνει το connection να σταματάει το notification. Ευτυχώς το άρθρο που διάβασα ήταν παλιό γιατί δουλεύοντας όλο το απόγευμα πάνω στα QN τελικά είδα ότι μόλις κλείσει το connection σταματάει και το Notification και όχι όταν σου στείλει την πρώτη ειδοποίηση.

Υστ 3: Δυστυχώς το σενάριο με τις τοπικές βάσεις δεν παίζει, για λόγους που αφορούν την εταιρεία δεν έχει γίνει αποδεκτό. Βλέπεται το πρόβλημα είναι με τους εποχικούς πωλητές και τα φορητά τους.

KelMan:

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

Πάντως, δεν μπορώ να φανταστώ τη χρησιμότητα ενός Queue Server... Γενικά (και χονδρικά), το message queueing χρησιμοποιείται όταν οι clients πρέπει να στείλουν κάποια data στον server, με ρυθμό που να μην προλαβαίνει ο server να τα διαχειριστεί, οπότε τα στέλνουν στο queue και ξεμπερδεύουν χρήγορα. Από την άλλη μεριά, τα Notification Services είναι πλέον obsolete τεχνολογία καθώς σταμάτησαν να παρέχονται στον SQL Server 2008.

Μπορείς ωστόσο να χρησιμοποιήσεις τα Query Notifications τα οποία δεν έχουν να κάνουν με τα Notification Services και έχουν πιο απλό API. Τα έχω χρησιμοποιήσει και ήταν πολύ εύκολα στην υλοποίηση, ωστόσο είχα ένα θέμα γιατί οι περισσότεροι clients ήταν wireless με αποτέλεσμα (ίσως λόγω broadcast?) να μπλοκάρουν αρκετά οι clients. Όσο έπαιζα με ενσύρματους clients ήταν μια χαρά. Μπορείς να το δοκιμάσεις πάντως στο θέμα του wireless, ίσως να ήταν προβληματικό το setup που μου είχε τύχει.

Πριν από λίγο είδα το παραπάνω post σου οπότε μου δίνεις μία σύντομη περιγραφή για τις δύο μου προτάσεις. Δεν το ήξερα αυτό για τα Notification Services. Νομίζω πειραματίζεται η Microsoft πότε το παρουσίασαν πότε αρχίσαμε να ασχολούμαστε με αυτό, εγώ μάλλον δεν πρόλαβα, και πότε το ακύρωσαν...

MSMQ : Ναι έχεις δίκιο για την γενική και χονδρική του χρήση αλλά είπα σε αυτό το σενάριο να χρησιμοποιήσω την λειτουργικότητά του για μία άλλη εργασία. Άλλωστε και ένας από τους λόγους που δημιουργήθηκε ήταν να δώσει τη δυνατότητα σε εφαρμογές να επικοινωνούν μεταξύ τους.

Για να το κάνεις αυτό λες με MSMQ θα πρέπει κάθε client και ο server να τρέχουν το MSMQ service ώστε να μπορούν να στείλουν και να λάβουν μηνύματα. Αυτό έχει διαχειριστικό κόστος, και καθιστά το setup πιο δύσκολο.

Επικοινωνία μεταξύ εφαρμογών μπορεί να γίνει με πολλούς τρόπους. Μπορείς να το κάνεις για παράδειγμα με Remoting - πλέον WCF.

Ναι έχεις δίκιο. Χρειάζεται να τρέχουν services και το setup είναι πιο δύσκολο. Σίγουρα είναι ένα μείον που δεν παραβλέπεται εύκολα, πιο σοβαρό από τα μείον του QN το οποίο εξακολουθεί να είναι πρώτο στην προτίμησή μου λόγω της απλότητάς του Θα ρίξω μία ματιά και στο Remoting (WCF) να δω και από αυτή την μεριά τι γίνεται.

infoCENTER:

Ναι έχεις δίκιο. Χρειάζεται να τρέχουν services και το setup είναι πιο δύσκολο. Σίγουρα είναι ένα μείον που δεν παραβλέπεται εύκολα, πιο σοβαρό από τα μείον του QN το οποίο εξακολουθεί να είναι πρώτο στην προτίμησή μου λόγω της απλότητάς του Θα ρίξω μία ματιά και στο Remoting (WCF) να δω και από αυτή την μεριά τι γίνεται.

Νομίζω η καλύτερη λύση θα ήταν WCF με Sync Services. Το WCF υποστηρίζει τα Sync Services με τέτοιο τρόπο ώστε να μπορεί να γίνεται συγχρονισμός μέσα απο ενα WCF Service με στην κυριολεξία 3 γραμμές κώδικα. Απο εκεί και πέρα, ένα καλό Implementation σε Callback (WCF Callbacks) όταν ενημερώνονται δεδομένα, ώστε να "ειδοποιούνται" οι clients και να κάνουν συγχρονισμό θα σου λύσει τα χέρια τελείως. Ακομά και με τον SQL CE να έχεις Local database, εφόσον το engine του SQL CE μπορεί να τρέξει μέσα απο την εφαρμογή, χωρίς extra setup κλπ, λύνεις και το πρόβλημα των εποχικών πωλητών, γιατί no application, no data. Τα callbacks είναι ουσιαστικά events, κάτι το οποίο μπορούσες να κάνεις και με Remoting και "κλασικά" Events σε προηγούμενες εκδόσεις του .Net, χωρίς αυτό βέβαια να ειναι ΚΑΘΟΛΟΥ μα ΚΑΘΟΛΟΥ διασκεδαστικο και εύκολο καθώς ήταν πατέντα της πατέντας. Με το WCF είναι εξαιρετικά εύκολο, ειδικά όταν το event είναι OneWay (δηλαδή απλά το WCF λέει στον Client "Ενημερώσου" και δεν περιμένει απάντηση).