Το πιο δυνατό στοιχείο του Silverlight είναι η εκφραστικότητα των data binding μηχανισμών του με όλες τις μορφές που μας το παρέχει. Separation of concerns, animations, visual states, MVVM, αλληλένδετα controls και πολλά ακόμα “βαριά” ή ελαφρά features οφείλουν την ύπαρξή τους στο Data Binding. Τι είναι Data Binding; Data Binding είναι η σύνδεση μεταξύ μίας πηγής δεδομένων και ενός προορισμού. Στο silverlight η πηγή είναι ένα CLR αντικείμενο που διατηρεί, ανανεώνει, κτλ πληροφορία (ένα object συγκεκριμένου τύπου)
Διαβάστε περισσότερα »
Το πιο δυνατό στοιχείο του Silverlight είναι η εκφραστικότητα των data binding μηχανισμών του με όλες τις μορφές που μας το παρέχει. Separation of concerns, animations, visual states, MVVM, αλληλένδετα controls και πολλά ακόμα “βαριά” ή ελαφρά features οφείλουν την ύπαρξή τους στο Data Binding. Τι είναι Data Binding; Data Binding είναι η σύνδεση μεταξύ μίας πηγής δεδομένων και ενός προορισμού. Στο silverlight η πηγή είναι ένα CLR αντικείμενο που διατηρεί, ανανεώνει, κτλ πληροφορία (ένα object συγκεκριμένου
Διαβάστε περισσότερα »
Έστω ότι έχουμε έναν αισθητήρα, το οποίον αποκαλούμε sensor node. Αυτός ο αισθητήρας είναι μέρος, ενός ευρύτερου δικτύου αισθητήρων. Έστω τώρα ότι θέλουμε να ανακτήσουμε τα δεδομένα αυτού του αισθητήρα. Έχουν αναπτυχθεί συστήματα τα οποία "βλέπουν" κάθε sensor node σαν μια μικρή πηγή δεδομένων, και το προαναφερόμενο δίκτυο, σαν μια μεγάλη κατανεμημένη βάση δεδομένων. Όταν έχουμε όμως μια κατανεμημένη βάση δεδομένων, μας νοιάζει τι υπάρχει από κάτω; Όχι...κάνουμε SQL queries και απλά ανακτούμε τα αποτελέσματα χωρίς ιδιαίτερη αγωνία για το τι υπάρχει από κάτω. Κάπως έτσι γίνεται και με ένα δίκτυο αισθητήρων.
Ας εξηγήσω πως δουλεύει αυτός ο μηχανισμός. Έστω ότι έχω έναν υπολογιστή και ένα δίκτυο αισθητήρων και θέλω να κάνω ένα query, πώς γίνεται η επικοινωνία με τους αισθητήρες; Ανάμεσα στο δίκτυο και στον υπολογιστή, υπάρχει ένα ειδικός κόμβος-gateway που λειτουργεί ως μεσάζοντας σε αυτήν την επικοινωνία. Στέλνω εγώ μια αίτηση και εκείνος είναι υπεύθυνος να την δρομολογήσει hop-by-hop στο δίκτυο αισθητήρων. Αυτή είναι η φάση της ανάλυσης επερώτησης. Στην συνέχεια έχουμε την ανάκτηση αποτελέσματος η οποία είναι παρόμοια με την πρώτη διαδικασία αλλά σε αντίστροφη πορεία. Τόσο απλό!!!! (εχμ μάλλον δεν είναι τόσο απλό, γιατί κάπου εδώ μπαίνει η επιστήμη. Αυτή η διαδικασία πρέπει να μελετηθεί με μαθηματική ακρίβεια διότι πρέπει να πετύχουμε τη μικρότερη δυνατή κατανάλωση ενέργειας, αλλά λεπτομερής ανάλυση δεν είναι ο σκοπός μου).
Πάμε να πούμε μερικά παραδείγματα επερωτήσεων τώρα. Σε αυτούς λοιπόν τους αισθητήρες, θέλω να κάνω δύο τύπους επερωτήσεων. Κάποιες επερωτήσεις τις κάνω μια φορά (on demand) και κάποιες θέλω να τις κάνω ανα τακτα χρονικά διαστήματα. Η πρώτη κατηγορία είναι απλή και μπορούμε να σκεφτούμε πολλά παραδείγματα. Στην δεύτερη κατηγορία, για παράδειγμα, εμπίπτουν περιβαλλοντολογικές εφαρμογές. Θα θεωρήσουμε ότι έχουμε αισθητήρες θερμοκρασίας, οι οποίοι είναι τοποθετημένοι σε μια δασική έκταση. Για να ελέγχω εγώ αν υπάρχει ένδειξη αύξησης θερμοκρασίας (φωτιά), πρέπει να ελέγχω συνεχώς για μετρήσεις. Πχ σε SQL - like γλώσσα θα είχα κάτι τέτοιο
SELECT sensorId, temperature FROM sensors EVERY 30 sec
Βέβαια από εκεί και πέρα μπορούμε να παίζουμε με τα queries ώστε να παίρνουμε είτε raw data είτε αποτελέσματα με τις MIN, MAX, SUM, COUNT και AVG. Επίσης μπορούμε να παίξουμε με τα events. Αν ανιχνεύαμε φωτιά και θέλαμε να επεξεργαστούμε τα δεδομένα περαιτέρω μπορούσαμε πχ να τρέξουμε κάτι τέτοιο:
ON EVENT ret.temperature > 60 SELECT nodeId, nodeLocation, temperature FROM sensors
Έστω λοιπόν ότι γράψαμε το query μας. Ανάλογα με το τι περιγράφει η επερώτησή μας η προαναφερόμενη gateway αναλαμβάνει να το μεταδώσει καταλλήλως. Αν για παράδειγμα είχαμε και ένα WHERE στο query μας τότε αυτό θα δρομολογηθεί στον συγκεκριμένο κόμβο αντί να είχαμε broadcast (Εδω παίζουν αλγόριθμοι αναζήτησης σε γράφους που είμαι σίγουρος ότι μάθατε σε κάποιο μάθημα πολυπλοκότητας και θεωρούσατε ότι "τι μας τα λένε αυτά τώρα, αφού δεν πρόκειτε να τα χρειαστούμε...".... σιγά σιγά με έκπληξη θα καταλάβετε ότι όλα χρειάζονται :))
Τι γίνεται όμως όταν έχουμε έναν aggregation operator οπως τον SUM...Τότε τα πράγματα δυσκολεύουν. Και αν θέλαμε μέση τιμή από κάποια περιοχή; Τότε τα πράγματα δυσκολεύουν ακόμα πιο πολύ. Οι κόμβοι μεταξύ τους έχουν πληροφορίες για το ποιος είναι ο πατέρας κόμβος, ποια είναι τα παιδιά, ποια είναι τα αδέρφια κτλ. Η πληροφορία πρέπει να ταξιδέψει ανάμεσα από αυτούς τους κόμβους με τα μικρότερα μονοπάτια ανάμεσα στις παραπάνω σχέσεις. Για παράδειγμα. Στην περίπτωση του SUM δείτε το παρακάτω σχηματάκι
A B C
D E F
G H I
Έστω ότι θέλω το άθροισμα των τιμών των A,B,C αισθητήρων και η gateway είναι το G. Δείτε το λίγο.
Αν η αθροιστική πληροφορία πάει από C στο B, μετά C+B στο B και μετά A+B+C στο A και από εκεί στο D και μετά στο G έχουμε μία καλή λύση. Δεν είναι λίγοτερα μηνύματα από το να μεταφέρονταν παράλληλα οι μετρήσεις C->I, B->H , A->G και να άθροιζαν στο επίπεδο G, H, I??
Κάπως έτσι γίνεται η επερώτηση σε ένα δίκτυο αισθητήρων. Βέβαια αν πάω τώρα και πάρω ένα βιβλίο για WSN's (Wireless Sensor Networks) είμαι σίγουρος ότι έκανα την γενίκευση της τάξης των 1500 σελίδων ++... :D Αλλά γενικά, η βασική ιδέα αυτή είναι.
Τώρα για τον προγραμματιστή πραγματική σημασία έχει μόνο το πρώτο στάδιο. Αυτό που κάνει απλές επερωτήσεις στην γλώσσα του δικτύου (για απλά δίκτυα η SQL είναι η πιο κοινά χρησιμοποιούμενη γλώσσα). Οπότε αν έχετε μια εφαρμογή και θέλετε να δοκιμάσετε κάποια δεδομένα από αισθητήρες, πείτε το super duper "Έστω οτι..." και θεωρήστε ότι έχετε μια βάση με πραγματικά δεδομένα.
Enjoy science!
