ΣΧΕΔΙΑΣΗ ΚΑΙ ΑΝΑΠΤΥΞΗ ΥΠΗΡΕΣΙΟΣΤΡΕΦΩΝ ΑΡΧΙΤΕΚΤΟΝΙΚΩΝ ΓΙΑ RFID ΣΥΣΤΗΜΑΤΑ ΔΙΠΛΩΜΑΤΙΚΗ ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΠΟΛΥΤΕΧΝΙΚΗ ΣΧΟΛΗ ΕΡΓΑΣΙΑ

Transcript

1 ΑΡΙΣΤΟΤΕΛΕΙΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΘΕΣΣΑΛΟΝΙΚΗΣ ΠΟΛΥΤΕΧΝΙΚΗ ΣΧΟΛΗ ΤΜΗΜΑ ΗΛΕΚΤΡΟΛΟΓΩΝ ΜΗΧΑΝΙΚΩΝ ΚΑΙ ΜΗΧΑΝΙΚΩΝ ΥΠΟΛΟΓΙΣΤΩΝ ΤΟΜΕΑΣ ΗΛΕΚΤΡΟΝΙΚΗΣ ΚΑΙ ΥΠΟΛΟΓΙΣΤΩΝ ΔΙΠΛΩΜΑΤΙΚΗ ΕΡΓΑΣΙΑ ΣΤΑΜΑΤΙΑΔΟΥ ΜΑΡΙΝΑ - ΕΙΡΗΝΗ ΣΧΕΔΙΑΣΗ ΚΑΙ ΑΝΑΠΤΥΞΗ ΥΠΗΡΕΣΙΟΣΤΡΕΦΩΝ ΑΡΧΙΤΕΚΤΟΝΙΚΩΝ ΓΙΑ RFID ΣΥΣΤΗΜΑΤΑ Επιβλέποντες καθηγητές: Λουκάς Πέτρου Ανδρέας Συμεωνίδης Θεσσαλονίκη 2012

2 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα

3 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Ευχαριστίες Σε αυτό το σημείο θα ήθελα να ευχαριστήσω θερμά όλους όσους συνέβαλαν στην εκπόνηση και την επιτυχή ολοκλήρωση της παρούσας διπλωματικής εργασίας. Αρχικά, θα ήθελα να ευχαριστήσω ιδιαίτερα τους καθηγητές μου, κύριο Λουκά Πέτρου και κύριο Ανδρέα Συμεωνίδη, αφενός για την εμπιστοσύνη που έδειξαν προς το πρόσωπό μου με την ανάθεση της διπλωματικής αυτής εργασίας και αφετέρου για την άψογη συνεργασία και την πολύτιμη συνεισφορά τους με τις συμβουλές, τις γνώσεις και την εμπειρία τους καθ όλη τη διάρκεια της εκπόνησής της. Η διαρκής υποστήριξή τους κάθε φορά που τη χρειάστηκα, ήταν το μεγαλύτερο κίνητρο για την επίτευξη των στόχων μου. Επίσης, οφείλω ένα θερμό ευχαριστώ στους γονείς μου, Σταμάτη και Ελένη, καθώς και στις αδερφές μου, Αθηνά και Αναστασία, για τη διαρκή συμπαράστασή τους σε κάθε μου βήμα όλα τα χρόνια των σπουδών μου, η οποία μου έδωσε δύναμη να επιτύχω τους στόχους μου. Τέλος, ένα μεγάλο ευχαριστώ στο συμφοιτητή και φίλο μου Μιλτιάδη Αλλαμανή, για τις πολύτιμες συμβουλές και τη βοήθεια που μου παρείχε όταν χρειάστηκε και στις φίλες μου Ματίνα, Σοφία και Μαρία, για την υπομονή τους όλο αυτό το διάστημα και για τη συμπαράσταση που έδειξαν με το δικό τους τρόπο. [3]

4 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα

5 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Περίληψη Στην επιστήμη της τεχνολογίας λογισμικού ο όρος υπηρεσιοστρεφείς αρχιτεκτονικές αναφέρεται σε ένα σύνολο από κανόνες και μεθοδολογίες για το σχεδιασμό και την ανάπτυξη λογισμικού με τη μορφή διαλειτουργικών υπηρεσιών. Ως βασικά πλεονεκτήματα των υπηρεσιοστρεφών αρχιτεκτονικών ορίζονται η υλοποίηση, η ενοποίηση και ο έλεγχος ενός συνόλου υπηρεσιών οι οποίες αλληλεπιδρούν μεταξύ τους μέσω καλά ορισμένων πρωτοκόλλων. Με βάση αυτά, οι υπηρεσιοστρεφείς αρχιτεκτονικές και οι διαδικτυακές υπηρεσίες έχουν τη δυνατότητα να χρησιμοποιούνται ως τεχνολογία βάσης για την υλοποίηση σεναρίων σε συνεργατικά περιβάλλοντα, αφού επιτρέπουν τη δημιουργία εφαρμογών που σχεδιάζονται με το συνδυασμό διαλειτουργικών, αλλά και χαλαρά συζευγμένων υπηρεσιών. Τα πλεονεκτήματα των αρχιτεκτονικών αυτών γίνονται ακόμη πιο σαφή όταν πρόκειται για τη σύζευξη ετερογενών αρχιτεκτονικών οι οποίες περιλαμβάνουν όλα τα επίπεδα ενός συστήματος, ξεκινώντας από το χαμηλότερο επίπεδο, αυτό της συσκευής. Από την άλλη πλευρά, τα RFID συστήματα έχουν αρχίσει να παίζουν σημαντικό ρόλο στην αυτοματοποίηση επιχειρησιακών διεργασιών όπως τα ERP συστήματα και η ανίχνευση αντικειμένων. Τόσο η ερευνητική, όσο και η εμπορική κοινότητα προσανατολίζονται στην ενίσχυση των διαδικασιών ανάπτυξης και στη χρηστικότητα τέτοιων συστημάτων. Συγκεκριμένα, υπάρχει η τάση προσανατολισμού στην ανάπτυξη μεθοδολογιών οι οποίες θα βασίζονται στη χρήση ενδιάμεσων επιπέδων (middleware) προκειμένου να διευκολύνονται οι διαδικασίες σχεδίασης, ανάπτυξης και υλοποίησης. Στα πλαίσια της παρούσας διπλωματικής εργασίας προτείνεται μια μεθοδολογία σχεδίασης και υλοποίησης μιας υπηρεσιοστρεφούς προσέγγισης ενδιάμεσου επιπέδου για RFID συστήματα. Τα αποτελέσματα της προσέγγισης αυτής αποδεικνύονται πειραματικά με τη χρήση εργαστηριακού RFID reader και RFID tags, σε μια εφαρμογή που απευθύνεται σε ασθενείς πάσχοντες από Alzheimer και υλοποιεί την προσέγγιση αυτήν. Το Silver Alert χρησιμοποιεί υπηρεσιοστρεφείς τεχνικές (SOAP/WSDL) και βασίζεται στο υπηρεσιοστρεφές πλαίσιο Fosstrak, το οποίο και επεκτείνει ώστε να ικανοποιήσει τις ανάγκες μιας πραγματικής εφαρμογής. Σταματιάδου Μαρίνα Ειρήνη, Ιούνιος 2012 [5]

6 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Abstract Design and Implementation of Service-Oriented Architectures for RFID-enabled Systems In software engineering a Service-Oriented Architecture (SOA) is a set of principles and methodologies for designing and developing software in the form of interoperable services. Major advantages of Service Oriented Architectures include their ability to implement, integrate and control of a set of services that interact with each other in a well-defined manner. Based on that, SOA and Web services can serve as a key enabling technology in order to facilitate collaborative scenarios in various environments. SOA represents a style of information systems architecture that enables the creation of applications, built by combining loosely coupled and interoperable services. SOA advantages become even more apparent when it comes to heterogeneous architectures that include all of a system s layers, starting from the lowest one, that of a device. On the other hand, RFID-Based Systems have successfully penetrated the market in order to automate business processes such as ERP systems and object tracking. Several efforts exist striving to enhance the development, deployment and utilization processes of these systems, through the definition and uptake of methodologies for middleware deployment. SOA middleware promises a smooth integration and consolidation of large complex RFID implementation within large system architectures. Within the context of this diploma thesis a design and implementation method of a service-oriented approach for RFID-enabled systems is proposed. The application developed is a system named Silver Alert which implements this methodology. Silver Alert employs web service primitives (SOAP/WSDL) and is based on the Fosstrak service-oriented framework, in order to maximally exploit RFID-enabled systems potential. Apart from the Silver Alert functionality that has been defined and development, the Fosstrak framework is also extended by adding intelligent capabilities to embedded systems, in order to support the application domain needs, addressed to Alzheimer patients. The methodology is tested experimentally using laboratory RFID tags and RFID readers, on an application for Alzheimer patients. Stamatiadou Marina Eirini, June 2012

7 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Περιεχομενα ΕΥΧΑΡΙΣΤΙΕΣ... 3 ΠΕΡΙΛΗΨΗ... 5 ABSTRACT... 6 ΠΕΡΙΕΧΟΜΕΝΑ... 7 ΛΙΣΤΑ ΕΙΚΟΝΩΝ ΛΙΣΤΑ ΠΙΝΑΚΩΝ ΚΕΦΑΛΑΙΟ 1 ΕΙΣΑΓΩΓΗ Αντικείμενο της Διπλωματικής Σκοπός της Διπλωματικής Δομή της Διπλωματικής ΚΕΦΆΛΑΙΟ 2 ΓΝΩΣΤΙΚΟ ΥΠΟΒΑΘΡΟ Υπηρεσιοστρεφής Υπολογιστική - Service Oriented Computing (SOC) Υπηρεσιοστρεφείς Αρχιτεκτονικές - Service-oriented Architectures (SOA) Διαδικτυακές Υπηρεσίες - Web Services (WS) Βασικές αρχές και χαρακτηριστικά των Web Services Τύποι των Web Services Βασικές οντότητες των Web Services Βασικές λειτουργίες των Web Services Στοίβα πρωτοκόλλων SOA Επίπεδο μεταφοράς - Transport Layer Επίπεδο μηνυμάτων - Messaging Layer Επίπεδο περιγραφής και εύρεσης Description and Discovery Layer Επίπεδο ποιότητας υπηρεσιών - Quality of Service (QoS) Σχεδίαση- Ανάπτυξη [7]

8 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα 2.5 Ενσωματωμένα συστήματα - Embedded Systems Αρχιτεκτονική ενσωματωμένων συστημάτων Δικτύωση ενσωματωμένων συστημάτων Η τεχνολογία RFID RFID ετικέτα RFID αναγνώστης RFID Middleware Εφαρμογές RFID συστημάτων Ανασκόπηση κεφαλαίου ΚΕΦΑΛΑΙΟ 3 ΥΠΗΡΕΣΙΟΣΤΡΕΦΕΙΣ ΑΡΧΙΤΕΚΤΟΝΙΚΕΣ ΓΙΑ ΕΝΣΩΜΑΤΩΜΕΝΑ RFID ΣΥΣΤΗΜΑΤΑ ΣΧΕΤΙΚΗ ΕΡΕΥΝΑ Εισαγωγή στο middleware ενσωματωμένων συστημάτων Υπηρεσιοστρεφείς Αρχιτεκτονικές Ενσωματωμένων Συστημάτων Προσέγγιση SOCRADES Επίπεδα αρχιτεκτονικής ενσωματωμένων συστημάτων Μεθοδολογίες ανάπτυξης Πρωτόκολλο WS για συσκευές - Device Protocol for Web Services (DPWS ) Υπηρεσιοστρεφείς Αρχιτεκτονικές Ενσωματωμένων Συστημάτων Προσέγγιση FOSSTRAK Αρχιτεκτονική EPC Network RFID Middleware Ανασκόπηση κεφαλαίου ΚΕΦΑΛΑΙΟ 4 FOSSTRAK MIDDLEWARE Εισαγωγή Δομή Filtering and Collection Middleware with ALE and LLRP support Fosstrak ALE Client Fosstrak LLRP Commander Fosstrak TDT Engine Fosstrak Capturing Application Fosstrak EPCIS Ανασκόπηση κεφαλαίου ΚΕΦΆΛΑΙΟ 5 ΤΟ ΣΥΣΤΗΜΑ SILVER ALERT Εισαγωγή Περιγραφή του προβλήματος... 96

9 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος Προδιαγραφές του συστήματος Χρήστες Λειτουργικές απαιτήσεις Σενάρια χρήσης Σχεδίαση συστήματος Hardware Layer Device Layer Capture Layer Query Application Τεχνολογίες που χρησιμοποιήθηκαν Υλικό που χρησιμοποιήθηκε RFID reader RFID Tags RFID Antenna Υλοποίηση Πακέτο κλάσεων devicelayer Πακέτο κλάσεων capturelayer Πακέτο κλάσεων processinglayer Πακέτο κλάσεων administrationlayer Πακέτο κλάσεων enduserlayer Πακέτο κλάσεων utils Βάση δεδομένων UsersDB Επίδειξη Επίδειξη σεναρίου χρήσης Register User Επίδειξη σεναρίου χρήσης User Login Επίδειξη σεναρίου χρήσης Track Patient Επίδειξη σεναρίου χρήσης Read Tags και Capture Events ΚΕΦΑΛΑΙΟ 6 ΣΥΜΠΕΡΑΣΜΑΤΑ ΚΑΙ ΜΕΛΛΟΝΤΙΚΕΣ ΕΠΕΚΤΑΣΕΙΣ Συμπεράσματα Μελλοντικές επεκτάσεις ΠΑΡΑΡΤΗΜΑ Α XML ΑΡΧΕΙΑ ΠΑΡΑΜΕΤΡΟΠΟΙΗΣΗΣ ΤΟΥ ALE Α.1 LRSpec Α.2 ECSpec References [9]

10 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα

11 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Λίστα εικόνων Σχήμα 2.1: Ρόλοι και λειτουργίες στην τεχνολογία των Web Services Σχήμα 2.2: Κύκλος ζωής της ανάπτυξης WS και ιεραρχία επιπέδων Σχήμα 2.3: Στοίβα πρωτοκόλλων Web Services Σχήμα 2.4: Επικοινωνία μέσω SOAP μηνυμάτων Σχήμα 2.5: Περιγραφή WSDL/SOAP διαδικασιών μεταξύ αιτούντος και παρόχου Σχήμα 2.6: Στοίβες πρωτοκόλλων Web Services Σχήμα 2.7: Τομείς εφαρμογής ενσωματωμένων συστημάτων Σχήμα 2.8: Ιεραρχικό μοντέλο ενσωματωμένων συστημάτων Σχήμα 2.9: Διαγραμματική απεικόνιση ενός RFID συστήματος Σχήμα 2.10: Δομή RFID ετικέτας Σχήμα 2.11: Διάφοροι τύποι RFID αναγνωστών Σχήμα 3.1: Αποκεντρωμένη αρχιτεκτονική βασισμένη σε SOA Σχήμα 3.2: Ιεραρχία επιχειρησιακών επιπέδων Σχήμα 3.3: Διαδικασία ανάπτυξης υπηρεσιών συστήματος Σχήμα 3.4: Διαδικασία ανάπτυξης pure client Σχήμα 3.5: Διαδικασία ανάπτυξης ομότιμων clients Σχήμα 3.6: Διαδικασία ανάπτυξης ασύγχρονων clients Σχήμα 3.7: Αρχιτεκτονική SOCRADES Σχήμα 3.8: Λεπτομερής αρχιτεκτονική SOCRADES Σχήμα 3.9: Στοίβα πρωτοκόλλων του EPCglobal Σχήμα 3.10: Αρχιτεκτονική EPCglobal Σχήμα 3.11: Διαδικασία υποβολής ONS ερωτήματος Σχήμα 3.12: Ιεραρχία επιπέδων του πλαισίου EPCIS Σχήμα 3.13: Περιεχόμενα επιπέδου Abstract Data Model Σχήμα 3.14: Υλοποίηση επιπέδου Abstract Data Model μέσω των κλάσεων του επιπέδου Data Definition Σχήμα 3.15: Υλοποίηση Service Layer Σχήμα 3.16: Κατηγορίες ιστορικών δεδομένων Σχήμα 3.17: Πίνακας χαρακτηριστικών Σχήμα 3.18: Αρχιτεκτονική RFID middleware Σχήμα 3.19: Η μελλοντική σύγκλιση των RFID και των WSN Σχήμα 4.1: Επίπεδα αρχιτεκτονικής του Fosstrak : Παράδειγμα LRSpec αρχείου Σχήμα 4.4: Τα επίπεδα του Fossstrak ALE Middleware Σχήμα 4.3: Παράδειγμα ECSpec αρχείου Σχήμα 4.5: Διάγραμμα τμημάτων του Fosstrak ALE Middleware Σχήμα 4.6: Μέθοδοι που παρέχονται από το ALE Interface Σχήμα 4.7: Διάγραμμα ακολουθιών Fosstrak ALE Middleware κατά τον ορισμό και την ενεργοποίηση του Event Cycle και του subscriber [11]

12 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σχήμα 4.8: Διάγραμμα ακολουθιών Fosstrak ALE Middleware κατά τη διαδικασία ενημέρωσης των subscribers Σχήμα 4.9: Logical Reader Composite Design Pattern Diagram Σχήμα 4.10: Logical Reader Observer Design Pattern Diagram Σχήμα 4.11: Logical Reader Adaptor Design Pattern Diagram Σχήμα 4.12: ALE Web Client Σχήμα 4.13: ALE Standalone Client Σχήμα 4.14: Περιβάλλον εργασίας του LLRP Commander προσαρμόσμένο στο περιβάλλον του Eclipse IDE : Fosstrak Tag Data Translation Engine Σχήμα 4.16: Τα interfaces που παρέχει η βάση δεδομένων του Fosstrak EPCIS Σχήμα 5.1: Επίπεδα αρχιτεκτονικής Silver Alert Σχήμα 5.2: Πακέτο devicelayer για την υλοποίηση του interface μεταξύ RFID reader και ALE middleware Σχήμα 5.3: Πακέτο κλάσεων capturelayer Σχήμα 5.4: Πακέτο κλάσεων processinglayer Σχήμα 5.5: Πακέτο κλάσεων administrationlayer Σχήμα 5.6: Πακέτο κλάσεων enduserlayer Σχήμα 5.7: Πακέτο κλάσεων utils Σχήμα 5.8: Ο Vega Reader Σχήμα 5.9: Η ετικέτα UHF Confidex Corona Σχήμα 5.10: Κεραία UHF RFID Mid Range Kathrein Σχήμα 5.11: Διάγραμμα κλάσεων πακέτου devicelayer Σχήμα 5.12: Διάγραμμα κλάσεων πακέτου capturelayer Σχήμα 5.13: Διάγραμμα κλάσεων πακέτου processinglayer Σχήμα 5.14: Διάγραμμα κλάσεων administrationlayer Σχήμα 5.15: Διάγραμμα κλάσεων πακέτου enduserlayer Σχήμα 5.16: Διάγραμμα κλάσεων πακέτου utils Σχήμα 5.17: Η βάση δεδομένων UsersDB Σχήμα 5.18: Διαδικασία εγγραφής νέου χρήστη στο σύστημα Silver Alert Σχήμα 5.19: Διαδικασία εγγραφής νέου ασθενούς στο σύστημα Silver Alert Σχήμα 5.20: Παράθυρο εισαγωγής του χρήστη στο σύστημα Silver Alert Σχήμα 5.21: Διαδικασία εισαγωγής παραμέτρων για τον εντοπισμό των διαδρομών που έχει ακολουθήσει ο ασθενής Σχήμα 5.22: Απεικόνιση διαδρομής (SQ Start point, EQ End point) Σχήμα 5.23: Απεικόνιση τοποθεσίας : Πρώτο βήμα: καθορισμός ALELR endpoint Σχήμα 5.25: Καθορισμός Logical Reader Σχήμα 5.26: Reader προσομοίωσης Σχήμα 5.27: Καθορισμός ALE endpoint Σχήμα 5.28: Καθορισμός του Event Cycle Σχήμα 5.29: Καθορισμός του subscriber

13 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Σχήμα 5.30: Προσθήκη RFID tag με κωδικό της επιλογής του χρήστη, σε δεκαεξαδική μορφή Σχήμα 5.31: Ο subscriber αποστέλλει κενές αναφορές, καθώς το RFID tag βρίσκεται εκτός εμβέλειας του reader Σχήμα 5.32: Επιτυχής καταχώρηση του event στην EPCIS βάση δεδομένων (capture) Σχήμα 5.33: Επαναλαμβανόμενα events τα οποία απορρίπτονται Σχήμα 5.34: Πειραματικά αποτελέσματα (1) Ανάγνωση RIFD tag και καταχώρηση στην EPCIS βάση δεδομένων (2) απόρριψη του ίδιου RFID tag που αναγνωρίσθηκε σε δύο συνεχόμενους κύκλους ανάγνωσης [13]

14 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Λίστα πινάκων Πίνακας 2.1: Σύγκριση ενεργών παθητικών RFID ετικετών Πίνακας 3.1: Διαδικασία υποβολής ONS ερωτήματος Πίνακας 3.2: Κατηγορίες ιστορικών δεδομένων Πίνακας 3.3: Interfaces που παρέχονται από το επίπεδο ALE Πίνακας 5.1: Βασικά χαρακτηριστικά του reader που χρησιμοποιήθηκε Πίνακας 5.2: Βασικά χαρακτηριστικά των ετικετών που χρησιμοποιήθηκαν Πίνακας 5.3: Βασικά χαρακτηριστικά της κεραίας που χρησιμοποιήθηκε

15 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Κεφάλαιο 1 Εισαγωγή [15]

16 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα 1.1 Αντικείμενο της Διπλωματικής Βιώνοντας την ψηφιακή εποχή στην οποία οι ηλεκτρονικοί υπολογιστές και το διαδίκτυο αποτελούν κομμάτι της καθημερινότητας, οι τεχνολογικές εξελίξεις παρουσιάζουν ραγδαία ανάπτυξη στον τομέα της παροχής ηλεκτρονικών υπηρεσιών. Η ετερογένεια των συστημάτων που συνδυάζονται για να ικανοποιήσουν τις απαιτήσεις που εισάγονται προκειμένου να συνδυασθούν κατάλληλα οι διαφορετικοί τομείς της επιστήμης των υπολογιστών, της τεχνολογίας και των πληροφοριών, καθιστά αδιαμφισβήτητη ανάγκη την υιοθέτηση μιας κοινής μεθοδολογίας ανάπτυξης. Αυτό έχει ως αποτέλεσμα τα τελευταία χρόνια να γίνονται πολυάριθμες προσπάθειες έτσι ώστε κάθε εφαρμογή πέρα από τις υψηλές λειτουργικές της ικανότητες, να έχει επιπλέον τη δυνατότητα να ενοποιείται με το γύρω περιβάλλον της με τρόπο εύκολο, γρήγορο, αξιόπιστο και επεκτάσιμο. Το κλειδί για την κάλυψη των παραπάνω απαιτήσεων είναι η χρήση διαδικτυακών υπηρεσιών (Web Services) οι οποίες υλοποιούν τις υπηρεσιοστρεφείς αρχιτεκτονικές (Service-oriented architectures - SOA). Με την αξιοποίηση των δυνατοτήτων τους σχεδιάζονται συστήματα λογισμικού τα οποία παρέχουν υπηρεσίες τόσο στους τελικούς χρήστες μιας εφαρμογής, όσο και σε άλλες υπηρεσίες που είναι διαμοιρασμένες σε ένα δίκτυο. Ανάμεσα στα συστήματα αυτά βρίσκονται και εκείνα που διαχειρίζονται πληροφορίες και δεδομένα που προέρχονται απευθείας από το επίπεδο της συσκευής, όπως είναι τα RFID συστήματα, τα οποία εξετάζονται στην παρούσα διπλωματική εργασία. Η ευρεία διάδοση των RFID συστημάτων σε πολυάριθμους τομείς απαιτεί ένα πλαίσιο ανάπτυξης της τεχνολογίας πληροφοριών το οποίο θα δίνει τη δυνατότητα διαχείρισης των RFID συσκευών και των δεδομένων που προέρχονται από αυτές και θα υποστηρίζει την ανάπτυξη εφαρμογών. Τα χαρακτηριστικά των παθητικών RFID συστημάτων εισάγουν συγκεκριμένους περιορισμούς όσον αφορά την ανάπτυξη ενδιάμεσων επιπέδων (middleware) που αναλαμβάνουν αυτή τη διαχείριση. Οι περιορισμοί αυτοί γίνονται ακόμα πιο αυστηροί όταν πρόκειται για RFID συστήματα τα οποία συνδέονται σε κάποιο τοπικό δίκτυο ή στο διαδίκτυο, ώστε να επικοινωνούν με άλλα, ετερογενή συστήματα. Χάρη στη χρήση διαδικτυακών υπηρεσιών μπορεί να υπάρχει μεγάλο επίπεδο αφαιρετικότητας και γενίκευσης, γεγονός που επιτρέπει την παραμετροποίηση και τη διαμόρφωση της εκάστοτε εφαρμογής ανεξάρτητα από συγκεκριμένα πρωτόκολλα που πρέπει να ακολουθούνται σε κάθε διαφορετικό σύστημα. Μελετώντας λοιπόν τις δυνατότητες που παρέχει η χρήση SOA στις αρχιτεκτονικές RFID συστημάτων, συμπεραίνουμε ότι πρόκειται για έναν συνδυασμό που προσφέρει πολυάριθμα πλεονεκτήματα τόσο στους μηχανικούς λογισμικού όσο και στους τελικούς χρήστες εφαρμογών.

17 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος Σκοπός της Διπλωματικής Σκοπός της παρούσας διπλωματικής εργασίας είναι η μελέτη των δυνατοτήτων που παρέχουν οι υπηρεσιοστρεφείς αρχιτεκτονικές όταν χρησιμοποιούνται για την ανάπτυξη εφαρμογών που βασίζονται στην τεχνολογία RFID συστημάτων. Αρχικά, ως στόχος τέθηκε η αποσαφήνιση όλων των εννοιών, των τεχνολογιών και των μεθόδων που εμπλέκονται στο πεδίο αυτό. Για το σκοπό αυτό, μελετήθηκαν εκτενώς οι υπηρεσιοστρεφείς αρχιτεκτονικές και τα RFID συστήματα έτσι ώστε να είναι σαφές το γνωστικό υπόβαθρο που απαιτείται για την κατανόηση τόσο της παρούσας υλοποίησης, όσο και των εναλλακτικών προσεγγίσεων που παρουσιάζονται. Στη συνέχεια στόχος ήταν η κατανόηση των μεθοδολογιών που χρησιμοποιούνται για την ανάπτυξη αρχιτεκτονικών που περιλαμβάνουν το επίπεδο της συσκευής (hardware) και εισάγουν επιπλέον απαιτήσεις, καθώς το επίπεδο αυτό είναι συνήθως ετερογενές και εξειδικευμένο. Επόμενος στόχος ήταν η κατανόηση της τεχνολογίας των RFID συστημάτων και του τρόπου με τον οποίο μπορούν να αξιοποιηθούν οι δυνατότητες που παρέχουν κάνοντας χρήση SOA προσεγγίσεων. Επιπλέον, σε αυτό το βήμα κρίθηκε απαραίτητος ο προσδιορισμός της τελικής εφαρμογής ως προς τη βασική λειτουργικότητά της και τις δυνατότητες που θα παρέχει στον τελικό χρήστη, οπότε και ορίστηκε το σύστημα Silver Alert. Κεντρικός άξονας της υλοποίησης ήταν η δημιουργία ενός συστήματος κοινωνικού σκοπού το οποίο απευθύνεται σε ασθενείς πάσχοντες από Alzheimer και παρέχει τη δυνατότητα αναζήτησης και ανάκτησης διαδρομών που ακολουθούν οι ασθενείς στο μακρινό ή κοντινό παρελθόν. Βασικός στόχος ήταν η επιλογή του κατάλληλου πλαισίου ανάπτυξης, πάνω στο οποίο θα στηριζόταν η μελέτη, η σχεδίαση και η υλοποίηση ενός ενδιάμεσου επιπέδου (middleware) το οποίο θα ενσωματώνει τις βασικές αρχές των SOA για RFID συστήματα, έτσι ώστε να μπορεί να ικανοποιήσει τις προδιαγραφές του συστήματος Silver Alert, ενσωματώνοντας όλες τις προδιαγραφές που τέθηκαν κατά τη σχεδίασή του. Τελικός στόχος ήταν η αξιοποίηση του πλαισίου Fosstrak, το οποίο κρίθηκε καταλληλότερο για τις ανάγκες των RFID συστημάτων, η επέκταση της υπάρχουσας δομής ώστε να καλύπτει τις απαιτήσεις του συστήματος Silver Alert και η αξιολόγηση των αποτελεσμάτων που προκύπτουν από τα πειράματα που πραγματοποιήθηκαν. [17]

18 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα 1.3 Δομή της Διπλωματικής Μέχρι το σημείο αυτό έγινε μια γενική εισαγωγή περιγράφοντας τις τεχνολογικές και επιστημονικές περιοχές που καλύπτει η παρούσα διπλωματική εργασία, ενώ δόθηκαν οι βασικοί άξονες πάνω στους οποίους βασίστηκε η υλοποίησή της καθώς και η κύρια ιδέα που αποτέλεσε αφορμή για την εκπόνησή της. Στο 2 ο κεφάλαιο περιγράφεται αναλυτικά το απαιτούμενο γνωστικό υπόβαθρο σχετικά με τεχνολογίες διαδικτυακών υπηρεσιών και με τεχνολογίες RFID συστημάτων. Πιο συγκεκριμένα, αναλύονται οι βασικές οντότητες και λειτουργίες των διαδικτυακών υπηρεσιών, περιγράφεται η στοίβα πρωτοκόλλων η οποία δομεί τη γενικότερη αρχιτεκτονική τους και εξετάζονται οι τρόποι σχεδίασης και ανάπτυξής τους. Επίσης, γίνεται μια εισαγωγή στην έννοια των ενσωματωμένων συστημάτων και στους τρόπους δικτύωσής τους. Παράλληλα εξετάζεται η τεχνολογία των RFID συστημάτων ως προς τα δομικά της στοιχεία (hardware/software) και ως προς τα πεδία στα οποία αυτή βρίσκει εφαρμογή. Στο 3 ο κεφάλαιο εξετάζονται οι αρχιτεκτονικές διαδικτυακών υπηρεσιών που αφορούν σε ενσωματωμένα συστήματα. Πιο συγκεκριμένα, περιγράφονται αναλυτικά δύο βασικές εναλλακτικές προσεγγίσεις, αυτή του SOCRADES και αυτή του EPC Network. Η πρώτη προσέγγιση αφορά σε πιο γενικού σκοπού ενσωματωμένα συστήματα ενώ η δεύτερη είναι καθαρά προσανατολισμένη σε αρχιτεκτονικές RFID συστημάτων. Στο τέλος του κεφαλαίου γίνεται η αποτίμηση της σύγκρισης αυτών των δύο πλαισίων ανάπτυξης. Στο 4 ο κεφάλαιο περιγράφεται εκτενώς η αρχιτεκτονική του Fosstrak. Παρουσιάζονται τα επίπεδα της αρχιτεκτονικής αυτής από το χαμηλότερο επίπεδο, το επίπεδο συσκευής έως το ανώτερο επίπεδο, το επίπεδο εφαρμογής. Η περιγραφή γίνεται τόσο ως προς το ρόλο τους μέσα στο EPC Network όσο και ως προς τη λειτουργικότητά τους. Παράλληλα γίνεται μια εισαγωγή στον τρόπο με τον οποίο μπορεί να χρησιμοποιηθεί το Fosstrak για τη σχεδίαση και την ανάπτυξη εφαρμογών RFID συστημάτων. Στο 5 ο κεφάλαιο περιγράφεται το σύστημα Silver Alert, το σύστημα που αναπτύχθηκε στα πλαίσια της παρούσας διπλωματικής εργασίας. Αρχικά περιγράφεται το πρόβλημα που καλείται να λύσει η υλοποίηση του συστήματος αυτού και εξάγονται οι κυριότερες λειτουργικές απαιτήσεις. Στη συνέχεια, βάσει των απαιτήσεων και των προδιαγραφών του συστήματος δίνονται τα βασικότερα σενάρια χρήσης. Ακολουθεί η περιγραφή της σχεδίασης του συστήματος και του τρόπου με τον οποίο υλοποιήθηκε και τέλος γίνεται η επίδειξη των αποτελεσμάτων που προέκυψαν από πειράματα σε περιβάλλον προσομοίωσης αλλά και σε πραγματικό περιβάλλον. Το 6 ο κεφάλαιο περιλαμβάνει τα συμπεράσματα που προέκυψαν από την υλοποίηση του συστήματος Silver Alert και μία αναφορά σε προτεινόμενες μελλοντικές επεκτάσεις του, ενώ στο παράρτημα Α δίνονται τα αρχεία που χρησιμοποιήθηκαν για την παραμετροποίηση του συστήματος.

19 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Κεφάλαιο 2 Γνωστικό υπόβαθρο [19]

20 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα 2.1 Υπηρεσιοστρεφής Υπολογιστική - Service Oriented Computing (SOC) Στον κόσμο των επιχειρήσεων, εκείνο που κάνει τη μεγαλύτερη αίσθηση είναι η διατύπωση νέων, εξελιγμένων λύσεων, ικανών να επιτύχουν μεγαλύτερο βαθμό αυτοματοποίησης των επιχειρησιακών διαδικασιών. Για την ικανοποίηση της ανάγκης αυτής πρωταρχικό ρόλο παίζει η αναγνώριση των βασικών απαιτήσεων και στη συνέχεια η ανάπτυξη της κατάλληλης εφαρμογής η οποία θα αποτελεί τη βέλτιστη λύση, προσανατολισμένη στο εκάστοτε πρόβλημα (1). Με τη ραγδαία ανάπτυξη της τεχνολογίας, όμως, οι μικρές διαφοροποιήσεις που παρουσιάζονταν οξύνθηκαν, καθιστώντας έτσι την υιοθέτηση μιας κοινής μεθοδολογίας αδιαμφισβήτητη ανάγκη. Αυτό είχε ως αποτέλεσμα τα τελευταία χρόνια να γίνουν πολυάριθμες προσπάθειες προκειμένου να συνδυασθούν κατάλληλα οι διαφορετικοί τομείς της επιστήμης των υπολογιστών, της τεχνολογίας και των πληροφοριών, έτσι ώστε κάθε εφαρμογή πέρα από τις υψηλές λειτουργικές της ικανότητες, να έχει επιπλέον τη δυνατότητα να ενοποιείται με το γύρω περιβάλλον της με τρόπο εύκολο, γρήγορο, αξιόπιστο και επεκτάσιμο. Γι αυτό το σκοπό, αναπτύχθηκε η επιστήμη των υπολογιστών η οποία θα είναι προσανατολισμένη στις υπηρεσίες (Service-oriented computing - SOC) (2). Πρόκειται για μια προσέγγιση η οποία χρησιμοποιεί την υπηρεσία (service) ως βασικό δομικό στοιχείο για να υποστηρίξει την ανάπτυξη γρήγορων και φθηνών κατανεμημένων εφαρμογών ακόμη και σε περιβάλλοντα με μεγάλη ανομοιογένεια. Ως απώτερος στόχος έχει τεθεί η σύνθεση ενός καθολικού συστήματος όπου τα επιμέρους υποσυστήματα θα εκτελούν διεργασίες και θα παρέχουν λειτουργίες μέσω καλά ορισμένων υπηρεσιών (3). 2.2 Υπηρεσιοστρεφείς Αρχιτεκτονικές - Service-oriented Architectures (SOA) Το κλειδί για την κάλυψη των απαιτήσεων που εισάγει η τεχνολογία των υπηρεσιών αλλά και για την υλοποίησή τους είναι η αρχιτεκτονική η οποία έχει υιοθετηθεί. Μιλώντας για υπηρεσιοστρεφή αρχιτεκτονική (Service-oriented architecture - SOA), εννοούμε τη λογική διαδρομή μέσω της οποίας σχεδιάζεται ένα σύστημα λογισμικού έτσι ώστε να παρέχει υπηρεσίες τόσο στους τελικούς χρήστες μιας εφαρμογής, όσο και σε άλλες υπηρεσίες που είναι διαμοιρασμένες σε ένα δίκτυο, μέσω κατάλληλα διαμορφωμένων interfaces. Ο βασικός στόχος της αρχιτεκτονικής αυτής είναι να επιτρέπει τη γενικευμένη διαλειτουργικότητα μεταξύ διαφορετικών συστημάτων και γλωσσών προγραμματισμού αλλά και την επεκτασιμότητα ήδη υπαρχουσών τεχνολογιών. Ο στόχος αυτός αποτελεί και τη βάση για την επικοινωνία μεταξύ εφαρμογών που εκτελούνται σε διαφορετικές και ανεξάρτητες πλατφόρμες μέσω κατάλληλων πρωτοκόλλων επικοινωνίας (3).

21 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος Διαδικτυακές Υπηρεσίες - Web Services (WS) Με το όρο Web Service (διαδικτυακή υπηρεσία) εννοούμε κάθε αυτοτελή-αυτόνομη μονάδα λογισμικού, η οποία είναι διαθέσιμη μέσω δικτύων και έχει τη δυνατότητα να ανταποκρίνεται σε αιτήματα, να διεκπεραιώνει απλές και πολύπλοκες διεργασίες και να διεξάγει συνδιαλλαγές για λογαριασμό άλλων εφαρμογών. Με λίγα λόγια, πρόκειται για μια εφαρμογή η οποία αναλαμβάνει το ρόλο ενός ενδιάμεσου επιπέδου (middleware) προκειμένου να επιτευχθεί η απαιτούμενη επικοινωνία μεταξύ ανεξάρτητων εφαρμογών μέσω του διαδικτύου (1) (3) (4). Σύμφωνα με τον ορισμό που δίνει εμπεριστατωμένα η IBM, «Οι WS είναι μια τεχνολογία που επιτρέπει στις εφαρμογές να επικοινωνούν μεταξύ τους ανεξαρτήτως πλατφόρμας και γλώσσας προγραμματισμού. Μία WS είναι μια διεπαφή λογισμικού (software interface) που περιγράφει μια συλλογή από λειτουργίες οι οποίες μπορούν να προσεγγιστούν από το δίκτυο μέσω πρότυπων μηνυμάτων XML. Χρησιμοποιεί πρότυπα βασισμένα στη γλώσσα XML για να περιγράψει μία λειτουργία (operation) προς εκτέλεση και τα δεδομένα προς ανταλλαγή με κάποια άλλη εφαρμογή. Μια ομάδα από WS οι οποίες αλληλεπιδρούν μεταξύ τους καθορίζει μια εφαρμογή WS» (5). Όλα τα πρωτόκολλα που χρησιμοποιούνται ορίζονται και περιγράφονται μέσω της γλώσσας XML (extensible Markup Language), η οποία έχει σχεδιασθεί για την τυποποιημένη μεταφορά δεδομένων μέσω του διαδικτύου. Κάθε μέρος του κώδικα και κάθε τμήμα μιας εφαρμογής που αναπτύσσεται για κάποιο σύστημα, μπορεί να μετασχηματιστεί έτσι ώστε να συμπεριφέρεται ως WS, η οποία θα είναι διαθέσιμη μέσω τοπικού ή ευρύτερου δικτύου. Οι WS αντικατοπτρίζουν μια προγραμματιστική προσέγγιση προσανατολισμένη σε υπηρεσίες (service-oriented) που βασίζεται στην ιδέα ότι κάθε υπολογιστικός πόρος που είναι διαθέσιμος, μπορεί να συμπεριφερθεί ως προσφερόμενη διαδικτυακή υπηρεσία μέσω καλώς ορισμένων διεπαφών (interfaces). Οι λειτουργικές δυνατότητες των WS ποικίλουν ανάλογα με την εκάστοτε εφαρμογή, υλοποιούνται, όμως, πάντοτε με τέτοιο τρόπο ώστε να εξασφαλίζουν χαλαρή συνδεσιμότητα μεταξύ των εφαρμογών (loosely coupled). Ένα από τα μεγαλύτερα πλεονεκτήματα που παρουσιάζουν οι WS είναι το γεγονός ότι μπορούν να λειτουργήσουν ανεξαρτήτως πλατφόρμας και γλώσσας προγραμματισμού. Αυτό, σε συνδυασμό με την απλότητα της υποδομής τους και του πρωτοκόλλου επικοινωνίας τους, καθιστά ευκολότερη τη διαχείριση της πληροφορίας και των δεδομένων και επιτρέπει την προσαρμογή ήδη υπαρχουσών εφαρμογών στις μεταβαλλόμενες σχεσιακές επιχειρησιακές συνθήκες Βασικές αρχές και χαρακτηριστικά των Web Services Δύο από τις βασικότερες θεωρήσεις στις οποίες στηρίζεται η επιστήμη της Τεχνολογίας Λογισμικού είναι η αρχή της αποδόμησης ενός συστήματος και του διαχωρισμού των απαιτήσεων σύμφωνα με τις οποίες ένα σύνθετο πρόβλημα μπορεί να λυθεί αποτελεσματικότερα εάν διαχωριστεί σε απλούστερα προβλήματα. [21]

22 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Οι WS, εκτός από τις παραπάνω αρχές στις οποίες βασίζεται η ανάπτυξή τους, διαθέτουν επίσης κάποια βασικά χαρακτηριστικά που πρέπει να διέπουν τη λειτουργία και τη συμπεριφορά τους ώστε να πλεονεκτούν έναντι άλλων, κλασικών εφαρμογών. Τα χαρακτηριστικά αυτά δίνονται παρακάτω: 1. Χαλαρή σύζευξη (Loose Coupling) Μιλώντας για σύζευξη αναφερόμαστε στις συσχετίσεις που υπάρχουν μεταξύ δύο εφαρμογών. Η δημιουργία ενός σχεσιακού μοντέλου που περιγράφει τα όρια μιας εφαρμογής, πρέπει να παρέχει υψηλή ανεξαρτησία μεταξύ αυτής και του περιβάλλοντός της (άλλες εφαρμογές, χρήστες). 2. Αφαιρετικότητα (Abstraction) Η έννοια της αφαιρετικότητας έχει να κάνει με τη γενικευμένη απλουστευμένη περιγραφή ενός προβλήματος η οποία εστιάζει στις βασικές του πτυχές χωρίς να εξετάζει τις επιμέρους λεπτομέρειες. Αποδομώντας το πρόβλημα και αποκρύπτοντας πληροφορίες που δεν είναι εξ ολοκλήρου απαραίτητες μειώνεται ο αριθμός των εξαρτήσεων και το χαρακτηριστικό αυτό σχετίζεται άμεσα με την έννοια της χαλαρής σύζευξης. 3. Συνθετικότητα (Composability) Μετά την αποδόμηση και την τμηματοποίηση ενός προβλήματος, πρέπει να υπάρχει η δυνατότητα να ανασυντεθούν οι επιμέρους λύσεις για την επίτευξη του αρχικού στόχου. 4. Επαναχρησιμοποίηση (Reusability) Η ιδέα βασίζεται στο γεγονός ότι κάθε εφαρμογή θα πρέπει να μπορεί να αποτελεί λύση για περισσότερα του ενός προβλήματα. Αυτό μπορεί να γίνει εύκολα κατανοητό αν σκεφτεί κανείς ότι κάτι το οποίο είναι επαναλαμβανόμενα χρήσιμο, τότε παρέχει και επαναλαμβανόμενη αποτελεσματικότητα. 5. Αυτονομία (Autonomy) Ο όρος αυτός αντιπροσωπεύει την ικανότητα που έχει μια εφαρμογή να είναι ανεξάρτητη, αυτορυθμιζόμενη και να έχει τον έλεγχο ώστε να παίρνει τις δικές της αποφάσεις χωρίς την ανάγκη έγκρισης από εξωτερικούς παράγοντες. 6. Μετάθεση της διαχείρισης καταστάσεων (State Management Deferral) Τα δεδομένα που σχετίζονται με την κατάσταση στην οποία βρίσκεται ένα σύστημα έχουν να κάνουν με την τρέχουσα δραστηριότητά του. Η διαχείρισή των δεδομένων αυτών αντιπροσωπεύει ουσιαστικά την επεξεργασία της εισερχόμενης πληροφορίας, η οποία σε κάθε κατάσταση αντιμετωπίζεται διαφορετικά. Παρουσιάζεται λοιπόν η ανάγκη για μείωση των καταστάσεων έτσι ώστε το εκάστοτε σύστημα να έχει δυνατότητες επεκτασιμότητας. 7. Αναγνωρισιμότητα (Discoverability) Πρόκειται για το αποτέλεσμα της διαδικασίας κατά την οποία γίνεται αναζήτηση και εύρεση μιας λογικής λύσης μέσα σε ένα συγκεκριμένο περιβάλλον. Ιδιαίτερα στην περίπτωση όπου η ύπαρξη της λύσης δεν είναι εξ αρχής γνωστή, αυτό έχει ως αποτέλεσμα να αποφεύγεται η δημιουργία πλεονάζουσας πληροφορίας. Σύμφωνα με όλες τις παραπάνω αρχές, για κάθε WS ορίζεται μια τυποποιημένη σύμβαση παροχής υπηρεσιών (Standardized Service Contract) η οποία εξαρτάται από τις απαιτήσεις που ορίζει η κάθε περίπτωση. Αποτέλεσμα όλων των παραπάνω, αποτελεί το γεγονός ότι κάθε WS διαθέτει συγκεκριμένα

23 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 χαρακτηριστικά, μέσω των οποίων διαφαίνονται και τα πλεονεκτήματα που προκύπτουν από τη χρήση τους. Τα κυριότερα από αυτά τα χαρακτηριστικά αυτά είναι: 1. Επεκτασιμότητα (Scalability) 2. Λειτουργικότητα (Functionality) 3. Διαλειτουργικότητα (Interoperability) 4. Διαθεσιμότητα (Availability) 5. Ενσωμάτωση (Integration) 6. Προσαρμοστικότητα (Adaptability) 7. Ευελιξία (Flexibility) 8. Μικρό κόστος υλοποίησης και χρήσης 9. Ευκολία στην επικοινωνία 10. Ανεξαρτησία λογισμικού Τύποι των Web Services Οι WS μπορούν να διαχωριστούν σε κατηγορίες, ανάλογα με την πολυπλοκότητά τους, τις λειτουργίες που επιτελούν και την εσωτερική δομή τους. Έτσι, προκύπτουν οι ακόλουθοι τύποι: Απλές/Πληροφοριακές WS (Simple or Informational Web Services Type I) Παρέχουν πρόσβαση σε δεδομένα και πληροφορίες μέσω απλών ακολουθιών αίτησης/απόκρισης (Request/Response) και μπορούν να αντιμετωπιστούν ως «μονάδες». Υποκατηγορίες σε αυτήν την περίπτωση αποτελούν παραδείγματα απλών συναλλαγών (Simple Trading Services) και καθαρής παροχής υπηρεσιών (Pure Content Services). Σύνθετες WS/Επιχειρησιακές διαδικασίες (Complex Web Services or Business Processes Type II) Προκύπτουν από τη διασύνδεση προϋπαρχόντων WS οι οποίες βρίσκουν εφαρμογή σε διαφορετικές επιχειρήσεις και συνδυάζονται έτσι, ώστε να επιτύχουν μια σταδιακή και ολοκληρωμένη αλληλεπίδραση μεταξύ αυτών Βασικές οντότητες των Web Services Στην τεχνολογία των WS εμπλέκονται τρεις βασικές οντότητες, οι οποίες αποτελούν τα δομικά στοιχεία τους και αναλαμβάνουν τρεις διαφορετικούς ρόλους, προσδιορίζοντάς τους μοναδικά. Αυτές είναι ο Service Provider (πάροχος), o Service Client ή Service Requestor (πελάτης ή αιτών) και το Service Registry (μητρώο/κατάλογος). Web Services Provider Ο πάροχος είναι υπεύθυνος για την υλοποίηση και την παροχή της εκάστοτε υπηρεσίας. Είναι ουσιαστικά ο ιδιοκτήτης της WS και ορίζει την υποδομή που απαιτείται για την πρόσβαση σε αυτήν. Επιπλέον, είναι υπεύθυνος για τη δημοσίευση των διαθέσιμων υπηρεσιών σε κάποιο μητρώο υπηρεσιών στο δίκτυο, με ταυτόχρονη γνωστοποίηση της τοποθεσίας τους και της λειτουργικής περιγραφής τους. [23]

24 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Web Services Requestor/Client Ο client είναι η οντότητα η οποία απαιτεί την επιτυχή εκτέλεση κάποιας συγκεκριμένης λειτουργίας. Κάνοντας αναζήτηση στις δημοσιεύσεις που υπάρχουν σε κάποιο μητρώο υπηρεσιών, επιλέγει την καταλληλότερη. Στη συνέχεια συνδέεται στην τοποθεσία όπου διατίθεται η υπηρεσία αυτή και χρησιμοποιώντας την με τον τρόπο που ορίζουν οι ανάγκες του προβλήματός του, καταλήγει στην επιθυμητή λύση. Πρέπει να σημειωθεί ότι το ρόλο του αιτούντος μπορεί να παίξει τόσο ένας απλός χρήστης, μέσω ενός περιβάλλοντος διεπαφής, όσο και μια εφαρμογή ή κάποια άλλη υπηρεσία, χωρίς την απαίτηση ύπαρξης interface. Web Services Registry Το μητρώο (κατάλογος) υπηρεσιών είναι η οντότητα στην οποία δημοσιεύονται οι WS και οι πληροφορίες που αφορούν σε αυτές, μέσω των providers. Παρέχουν τη δυνατότητα αναζήτησης και εύρεσης μιας WS στους clients, έτσι ώστε να καθίσταται δυνατή η επικοινωνία με τον κατάλληλο provider. Επιπλέον, επιτρέπουν την πρόσβαση σε απαραίτητες πληροφορίες όπως είναι η περιγραφή μιας WS, η λειτουργικότητά της, η τοποθεσία από όπου μπορεί να γίνει η κλήση της και ο τρόπος διασύνδεσης μέσω του interface της Βασικές λειτουργίες των Web Services Για να μπορέσει μια εφαρμογή να επωφεληθεί μιας WS και των αλληλεπιδράσεων μεταξύ των τριών οντοτήτων της, θα πρέπει να εκτελεστούν τρεις βασικές διαδικασίες: η διαδικασία δημοσίευσης (publish), η διαδικασία εύρεσης (find), η διαδικασία διασύνδεσης (bind) και η διαδικασία ανταλλαγής μηνυμάτων (exchanging messages messaging). Διαδικασία δημοσίευσης Η δημοσίευση μιας WS αποτελεί ουσιαστικά τη μέθοδο με την οποία αυτή γίνεται γνωστή στο ευρύτερο περιβάλλον της, έτσι ώστε να είναι διαθέσιμη προς αναζήτηση. Η διαδικασία αυτή περιλαμβάνει δύο επιμέρους λειτουργίες, την περιγραφή και την καταχώρηση μιας WS: 1. Περιγραφή (describing): Οι βασικές πληροφορίες που πρέπει να είναι διαθέσιμες ώστε να είναι πλήρης μια περιγραφή είναι εκείνες που αφορούν στον provider της WS, στις βασικές της ιδιότητες, στον τρόπο κλήσης και εκτέλεσής της. 2. Καταχώρηση (registration): Μετά την ολοκληρωμένη περιγραφή μιας WS, αυτή πρέπει να καταχωρηθεί στον κατάλογο υπηρεσιών, έτσι ώστε να μπορεί να γίνει η αναζήτησή της από κάποιον αιτούντα. Διαδικασία εύρεσης Όπως και η διαδικασία δημοσίευσης, έτσι και η διαδικασία εύρεσης περιλαμβάνει δύο επιμέρους λειτουργίες: 1. Εύρεση των σχετικών προς το πρόβλημα WS μέσα από τον κατάλογο υπηρεσιών.

25 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος Επιλογή της πιο κατάλληλης WS για την εκτέλεση μιας συγκεκριμένης διεργασίας. Η διαδικασία της εύρεσης είναι μια διαδικασία αναζήτησης, σύμφωνα με την οποία ο client ορίζει κάποια συγκεκριμένα κριτήρια και διατυπώνει ένα ερώτημα. Μετά από σύγκριση των κριτηρίων με τις περιγραφές των WS που είναι αποθηκευμένες στον κατάλογο υπηρεσιών, επιστρέφονται τα αποτελέσματα που ταιριάζουν περισσότερο στις προδιαγραφές που έθεσε ο client. Στη συνέχεια, ακολουθεί η επιλογή της WS η οποία θα είναι περισσότερο προσανατολισμένη στις ανάγκες του αιτούντος από τις υπόλοιπες υποψήφιες. Η επιλογή αυτή μπορεί να γίνει είτε χειροκίνητα είτε αυτόματα (μέσω ειδικών δικτυακών εφαρμογών). Διαδικασία διασύνδεσης Η τελική διαδικασία που πρέπει να επιτελεστεί είναι αυτή της διασύνδεσης της WS με τον client. Κατά τη διάρκεια αυτής, ο client εκκινεί μια αλληλεπίδραση μεταξύ αυτού και του provider, κάνοντας κλήση σε κάποια WS. Χρησιμοποιώντας τις λεπτομέρειες που διατίθενται στην περιγραφή της σχετικά με τον τρόπο εκτέλεσης, ακολουθεί την δηλωθείσα σύμβαση και τη δεσμεύει. Η κλήση μπορεί να γίνει είτε απευθείας από τον αιτούντα είτε με τη βοήθεια κάποιου διαμεσολαβητή αναζήτησης (discovery agency). Μετά τη δέσμευση της WS, ακολουθεί η εκτέλεσή της και η επιστροφή των ζητούμενων αποτελεσμάτων στον client. Σχήμα 2.1: Ρόλοι και λειτουργίες στην τεχνολογία των Web Services Το βασικότερο πλεονέκτημα που εισάγει η αρχιτεκτονική των WS είναι ότι παρέχει μια ευέλικτη προσέγγιση μέσω της οποίας οι μηχανικοί λογισμικού μπορούν να υλοποιήσουν καινούριες εφαρμογές μέσα από μια συλλογή επαναχρησιμοποιούμενων μονάδων (υπηρεσιών) που διαθέτουν καλώς ορισμένα περιβάλλοντα διεπαφής και δομημένη ροή πληροφορίας. [25]

26 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Η αρχιτεκτονική των δικτυακών υπηρεσιών (Service-oriented Architecture) μπορεί να ιεραρχηθεί σε έξι επίπεδα, τα οποία παρουσιάζονται στο Σχήμα 2.2. Από το σχήμα αυτό φαίνεται ότι κάθε επίπεδο χρησιμοποιεί τη λειτουργικότητα που παρέχεται από το αμέσως προηγούμενο επίπεδο και προσθέτει σε αυτήν νέες λειτουργικότητες, έτσι ώστε να εξυπηρετεί το σκοπό του. Η λογική ροή βασίζεται σε μια από πάνω προς τα κάτω προσέγγιση ανάπτυξης, δίνοντας έμφαση στην αποδόμηση των επιχειρησιακών διαδικασιών σε ανεξάρτητες WS καθώς και στη συνέχεια, στην υλοποίησή τους (2). Σχήμα 2.2: Κύκλος ζωής της ανάπτυξης WS και ιεραρχία επιπέδων

27 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος Στοίβα πρωτοκόλλων SOA Βασικό γνώρισμα των WS είναι το γεγονός ότι αυτές δεν υλοποιούνται με μονολιθικό τρόπο αλλά αντιθέτως συνδυάζουν μια συλλογή από συναφείς τεχνολογίες. Κύριο άξονα γι αυτό, αποτελεί η στοίβα των πρωτοκόλλων πάνω στην οποία δομείται η αρχιτεκτονική των WS όπως περιγράφηκε παραπάνω (2) (4). Τα πρωτόκολλα είναι σύνολα κανόνων που διέπουν την επικοινωνία και την ανταλλαγή πληροφοριών μεταξύ των οντοτήτων που συναντώνται στην αρχιτεκτονική των WS. Στο Σχήμα 2.4 παρουσιάζεται διαγραμματικά το σύνολο των επιπέδων που συναντάται στη στοίβα πρωτοκόλλων των SOA, ενώ στη συνέχεια δίνεται η περιγραφή των βασικότερων από αυτά. Σχήμα 2.3: Στοίβα πρωτοκόλλων Web Services Επίπεδο μεταφοράς - Transport Layer Στο επίπεδο της μεταφοράς (transport layer) βασικότερα πρωτόκολλα είναι το HTTP (HyperText Transfer Protocol), το SMTP (Simple Mail Transfer Protocol), το FTP (File Transfer Protocol) και το JMS (Java Message Service). Το επίπεδο αυτό είναι υπεύθυνο για τη διακίνηση των μηνυμάτων που ανταλλάσσονται μεταξύ μιας WS και ενός χρήστη ή μιας εφαρμογής (client). [27]

28 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Επίπεδο μηνυμάτων - Messaging Layer Το επίπεδο των μηνυμάτων είναι υπεύθυνο για τον προσδιορισμό της μορφής και τον καθορισμό της κωδικοποίησης των μηνυμάτων που ανταλλάσσονται. Θέτει ουσιαστικά τους κανόνες ώστε η επικοινωνία μεταξύ μιας WS και κάποιας εφαρμογής να γίνεται με κοινό τρόπο. Τα πρωτόκολλα που εμπεριέχονται στο επίπεδο αυτό είναι το SOAP (Simple Object Access Protocol) και το XML-RPC (XML- Remote Procedure Call). Τα μηνύματα που ανταλλάσσονται διακρίνονται σε τρεις κατηγορίες: Μονόδρομα (One-way messages) Ένα μήνυμα αποστέλλεται από κάποιον client σε κάποιον provider για την κλήση κάποιας WS χωρίς να αναμένεται βέβαιη απόκριση. Αίτησης/Απόκρισης (Request/Response messages) Ένα μήνυμα αποστέλλεται από κάποιον client σε κάποιον provider για την κλήση κάποιας WS και ο provider αποκρίνεται αποστέλλοντας με τη σειρά του ένα μήνυμα. Γνωστοποιήσεις (notifications) Ένα μήνυμα αποστέλλεται από κάποιον provider σε κάποιον client Simple Object Access Protocol - SOAP Πρόκειται για ένα απλό πρωτόκολλο το οποίο είναι βασισμένο στο πρωτόκολλο XML-messaging. Σύμφωνα με αυτό, οι WS ανταλλάσουν πληροφορίες και δεδομένα με τη μορφή δομημένων μηνυμάτων (messages), υλοποιώντας ταυτόχρονα ένα μοντέλο αίτησης/απόκρισης για την επικοινωνία μεταξύ των αλληλεπιδρώντων οντοτήτων. Η δομή που έχουν τα μηνύματα βασίζεται στη γλώσσα XML και σε επίπεδο μεταφοράς, η ανταλλαγή γίνεται μέσω του πρωτοκόλλου HTTP. Αξίζει να σημειωθεί ότι τα πρωτόκολλα XML και HTTP είναι ανεξάρτητα από την εκάστοτε πλατφόρμα όπου τρέχει μια εφαρμογή και από τη γλώσσα προγραμματισμού στην οποία έχει γραφεί, επομένως, σε αυτό το επίπεδο, το SOAP συνάδει με τις βασικές αρχές που διέπουν την τεχνολογία των WS. Σχήμα 2.4: Επικοινωνία μέσω SOAP μηνυμάτων Ένα SOAP μήνυμα περιέχει τα ακόλουθα στοιχεία (6): Envelope προσδιορίζει την αρχή και το τέλος του μηνύματος (απαιτούμενο). Header περιλαμβάνει οποιαδήποτε προαιρετικά χαρακτηριστικά του μηνύματος που χρησιμοποιούνται κατά την επεξεργασία του μηνύματος (προαιρετικό).

29 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Body περιλαμβάνει τα XML δεδομένα του μηνύματος που αποστέλλεται (απαιτούμενο). Fault παρέχει πληροφορίες σχετικά με σφάλματα που συμβαίνουν κατά τη διαδικασία προσπέλασης και επεξεργασίας του μηνύματος (προαιρετικό). Η τυπική δομή σύνταξής του καθώς και παραδείγματα αίτησης/απόκρισης, φαίνεται παρακάτω: <?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <SOAP-ENV:Fault> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP_ENV:Envelope> SOAP Request: POST /Quotation HTTP/1.0 Host: Content-Type: text/xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Body xmlns:m=" <m:getquotation> <m:quotationsname>miscrosoft</m:quotationsname> </m:getquotation> </SOAP-ENV:Body> </SOAP-ENV:Envelope> SOAP Response: HTTP/ OK Content-Type: text/xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Body xmlns:m=" <m:getquotationresponse> <m:quotation>here is the quotation</m:quotation> </m:getquotationresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> [29]

30 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα XML-Remote Procedure Call - XML-RPC Πρόκειται για ένα πρωτόκολλο που αποτελείται από ένα σύνολο κανόνων υλοποίησης, οι οποίοι επιτρέπουν σε συστήματα λογισμικού που εκτελούνται σε ανεξάρτητες πλατφόρμες και σε διαφορετικά περιβάλλοντα, να πραγματοποιούν απομακρυσμένες κλήσεις διαδικασιών (remote procedure calls) μέσω δικτύου. Έχει σχεδιαστεί έτσι, ώστε να είναι απλό στη χρήση και ταυτόχρονα να εξυπηρετεί τη μεταφορά, την επεξεργασία και την επιστροφή πολύπλοκων δομών δεδομένων. Αποτελείται από τρία σχετικά μικρά τμήματα (6): XML-RPC data model πρόκειται για ένα σύνολο τύπων που χρησιμοποιούνται ως παράμετροι εισόδου, επιστρεφόμενες τιμές και σφάλματα. XML-RPC request structures πρόκειται για ένα αίτημα τύπου ΗΤΤΡ, το οποίο περιλαμβάνει πληροφορίες μεθόδων και παραμέτρων. XML-RPC response structures - πρόκειται για ένα αίτημα τύπου ΗΤΤΡ, το οποίο περιλαμβάνει επιστρεφόμενες τιμές ή πληροφορίες σφαλμάτων. Οι τύποι δεδομένων που υποστηρίζονται από το XML-RPC πρωτόκολλο είναι: int: ακέραιοι αριθμοί των 32 bit double: αριθμοί κινητής υποδιαστολής των 64 bit boolean: λογικές τιμές true(1)/false(0) string: αρχεία γραμμένα σε κώδικα ASCII datetime.iso8601: ημερομηνίες της μορφής CCYYMMDDTHH:MM:SS base64: δυαδική πληροφορία κωδικοποιημένη κατά base Επίπεδο περιγραφής και εύρεσης Description and Discovery Layer Στο επίπεδο αυτό ορίζεται σαφώς ο τρόπος με τον οποίο περιγράφεται μια WS καθώς και ο τρόπος με τον οποίο αυτές καταγράφονται στους καταλόγους και στη συνέχεια είναι διαθέσιμες προς δημοσίευση και εύρεση από τους clients. Όπως αναφέρθηκε νωρίτερα, η περιγραφή μιας WS περιλαμβάνει πληροφορίες για τη λειτουργικότητά της, την τοποθεσία της και το interface της. Το πρωτόκολλο που ακολουθείται για την περιγραφή μιας WS είναι το WSDL ενώ για την αναζήτηση/εύρεσή της ακολουθείται το πρωτόκολλο UDDI. Web Services Description Language - WSDL Η WSDL είναι το πρωτόκολλο που ορίζει τον τρόπο με τον οποίο περιγράφεται από τους providers η βασική μορφή των αιτήσεων και απαντήσεων των υπηρεσιών πάνω από διαφορετικά πρωτόκολλα και κωδικοποιήσεις. Χρησιμοποιείται δηλαδή, για να περιγράψει τί μπορεί να κάνει μια WS, πού βρίσκεται και πώς να την καλέσει κανείς. Επιπλέον, αντιμετωπίζει τις WS ως ένα σύνολο από τελικά σημεία δικτύου (endpoints) ή θύρες (ports). Ως τελικό σημείο (port) ορίζεται η διασύνδεση μιας δικτυακής διεύθυνσης με μία επαναχρησιμοποιούμενη σύνδεση (binding). Τα τελικά σημεία σε συνδυασμό με τα μηνύματα περιγράφουν με σαφήνεια το interface της WS που είναι διαθέσιμο στο κοινό.

31 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Σχήμα 2.5: Περιγραφή WSDL/SOAP διαδικασιών μεταξύ αιτούντος και παρόχου Ένα αρχείο γραμμένο σε WSDL είναι ουσιαστικά ένα XML αρχείο που περιλαμβάνει ένα σύνολο ορισμών για την περιγραφή μιας WS. Η τυπική δομή σύνταξής του φαίνεται παρακάτω (6): <definitions> <types> definition of types... </types> <message> definition of a message... </message> <porttype> <operation> definition of an operation... </operation> </porttype> <binding> definition of a binding... </binding> <service> definition of a service... </service> </definitions> Όπως φαίνεται λοιπόν και από τους παραπάνω κανόνες σύνταξης, οι WS προσδιορίζονται βάσει έξι κυριότερων στοιχείων τα οποία είναι: types παρέχει τους ορισμούς των τύπων δεδομένων που χρησιμοποιούνται για την περιγραφή των μηνυμάτων που ανταλλάσσονται. [31]

32 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα message αντιπροσωπεύει την αφαιρετική προσέγγιση του ορισμού των δεδομένων που μεταδίδονται. Ένα μήνυμα συνίσταται από λογικά τμήματα, καθένα από τα οποία σχετίζεται με έναν ορισμό εντός κάποιου τύπου συστήματος. porttype πρόκειται για ένα σύνολο αφηρημένων λειτουργιών. Κάθε λειτουργία αναφέρεται σε ένα μήνυμα εισόδου και σε μηνύματα εξόδου. Περιγράφει μια WS, τις λειτουργίες που μπορεί να επιτελέσει και τα μηνύματα που εμπλέκονται σε αυτές τις λειτουργίες. binding προσδιορίζει ένα συγκεκριμένο πρωτόκολλο και μια καθορισμένη δομή δεδομένων για τις λειτουργίες και τα μηνύματα που ορίζει ένας συγκεκριμένος porttype. port προσδιορίζει τη διεύθυνση για τη δέσμευση μιας συγκεκριμένης WS και με αυτόν τον τρόπο ορίζει ένα τελικό σημείο επικοινωνίας (endpoint). service ενοποιεί ένα σύνολο συσχετιζόμενων ports. Πέρα από αυτά τα στοιχεία, σε ένα αρχείο WSDL μπορούν να ορίζονται και παρακάτω προαιρετικά στοιχεία: Documentation πρόκειται για ένα στοιχείο που χρησιμοποιείται για εγγραφές που θα είναι αναγνώσιμες από τον άνθρωπο και μπορεί να περιλαμβάνεται εντός οποιουδήποτε άλλου WSDL στοιχείου. Import πρόκειται για ένα στοιχείο που χρησιμοποιείται για την εισαγωγή άλλων WSDL αρχείων ή XML σχημάτων. Ένα απλό παράδειγμα που δείχνει τη χρήση της παραπάνω δομής δίνεται στη συνέχεια. Στο παράδειγμα αυτό η WS παρέχει μια δημόσια συνάρτηση η οποία ονομάζεται sayhello. Η συνάρτηση αυτή αναμένει ως παράμετρο εισόδου ένα απλό string και επιστρέφει έναν χαιρετισμό υπό μορφή string επίσης. Στο παράδειγμα αυτό τα στοιχεία που εμφανίζονται είναι τα ακόλουθα: definition: HelloService type: Χρήση έτοιμων τύπων δεδομένων που ορίζονται στο XML σχήμα. message: sayhellorequest: firstname παράμετρος εισόδου sayhelloresponse: greeting επιστρεφόμενη τιμή porttype: μέθοδος sayhello, η οποία συνίσταται από μια υπηρεσία αιτήματος και μία υπηρεσία απόκρισης. binding: Κατεύθυνση για τη χρήση του πρωτοκόλλου μεταφοράς SOAP HTTP. Service: Η υπηρεσία παρέχεται στη διεύθυνση port: Συσχετίζει το binding με το URI από όπου μπορεί να προσπελαστεί η ενεργή υπηρεσία.

33 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 <definitions name="helloservice" targetnamespace=" xmlns=" xmlns:soap=" xmlns:tns=" xmlns:xsd=" <message name="sayhellorequest"> <part name="firstname" type="xsd:string"/> </message> <message name="sayhelloresponse"> <part name="greeting" type="xsd:string"/> </message> <porttype name="hello_porttype"> <operation name="sayhello"> <input message="tns:sayhellorequest"/> <output message="tns:sayhelloresponse"/> </operation> </porttype> <binding name="hello_binding" type="tns:hello_porttype"> <soap:binding style="rpc" transport=" <operation name="sayhello"> <soap:operation soapaction="sayhello"/> <input> <soap:body encodingstyle=" namespace="urn:examples:helloservice" use="encoded"/> </input> <output> <soap:body encodingstyle=" namespace="urn:examples:helloservice" use="encoded"/> </output> </operation> </binding> <service name="hello_service"> <documentation>wsdl File for HelloService</documentation> <port binding="tns:hello_binding" name="hello_port"> <soap:address location=" </port> </service> </definitions> Universal Description, Discovery, Integration UDDI Πρόκειται για το πρωτόκολλο το οποίο εστιάζει στον καθορισμό ενός συνόλου από υπηρεσίες που θα υποστηρίζουν την περιγραφή και εύρεση των WS, των providers, των διεπαφών και των λειτουργιών τους. Βασίζεται στα πρωτόκολλα που αναφέρθηκαν νωρίτερα και παρέχει μια θεμελιώδη υποδομή για τη διασύνδεση οποιουδήποτε client με μια WS. Τα στοιχεία που απαρτίζουν το UDDI είναι τρία (6): White pages: Publish Καταχώρηση μιας WS [33]

34 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Αυτή η κατηγορία περιλαμβάνει βασικές πληροφορίες σχετικά με τον provider μιας WS, στοιχεία επικοινωνίας με τον provider (όνομα, διεύθυνση κλπ) και αναγνωριστικά που επιτρέπουν την εύκολη εύρεσή του. Yellow pages: Find Εύρεση μιας WS Αυτή η κατηγορία περιέχει περισσότερες λεπτομέρειες σχετικά με τον provider μιας WS και περιλαμβάνει περιγραφές που αφορούν στην περιγραφή των υπηρεσιών που παρέχονται από αυτόν, ώστε να καθίσταται δυνατή η αναζήτηση και εύρεση της κατάλληλης WS από κάποιον client. Green pages: Bind Διασύνδεση μεταξύ client και WS Η κατηγορία αυτή περιλαμβάνει τεχνικές πληροφορίες σχετικά με τις παρεχόμενες WS, όπως είναι τα interfaces, οι URL τοποθεσίες και τα απαιτούμενα δεδομένα για την κλήση μιας WS. Το πρωτόκολλο UDDI περιλαμβάνει ένα XML σχήμα το οποίο περιγράφει πέντε διαφορετικές δομές. Παραδείγματα των δομών αυτών δίνονται αμέσως μετά τον ορισμός τους. businessentity Η δομή αυτή αντιπροσωπεύει τον provider μιας WS. Εντός του UDDI καταλόγου αυτή η δομή περιλαμβάνει τις πληροφορίες που αναφέρθηκαν στις white pages. <businessentity businesskey="uuid:c0e6d5a8-c446-4f01-99da-70e212685a40" operator=" authorizedname="john Doe"> <name>acme Company</name> <description> We create cool Web services </description> <contacts> <contact usetype="general info"> <description>general Information</description> <personname>john Doe</personName> <phone>(123) </phone> </contact> </contacts> <businessservices>... </businessservices> <identifierbag> <keyedreference tmodelkey="uuid:8609c81e-ee1f-4d5a-b202-3eb13ad01823" name="d-u-n-s" value=" " /> </identifierbag> <categorybag> <keyedreference tmodelkey="uuid:c0b9fe13-179f-413d-8a5b-5004db8e5bb2" name="naics" value="111336" /> </categorybag> </businessentity>

35 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 businessservice η δομή αυτή αντιπροσωπεύει μια συγκεκριμένη WS η οποία παρέχεται από την businessentity. Η περιγραφή της περιλαμβάνει πληροφορίες σχετικά με τη διασύνδεση κάποιου client με τη συγκεκριμένη WS, τον τύπο της και την κατηγορία στην οποία ανήκει. <businessservice servicekey="uuid:d6f1b765-bdb d e5a2a" businesskey="uuid:c0e6d5a8-c446-4f01-99da-70e212685a40"> <name>hello World Web Service</name> <description>a friendly Web service</description> <bindingtemplates>... </bindingtemplates> </categorybag> </businessservice> bindingtemplate πρόκειται για τεχνικές περιγραφές των WS που παρουσιάζουν τον τρόπο υλοποίησης μιας WS όπως αυτός ορίζεται μέσω των green pages. <bindingtemplate servicekey="uuid:d6f1b765-bdb d e5a2a" bindingkey="uuid:c0e6d5a8-c446-4f01-99da-70e212685a40"> <description>hello World SOAP Binding</description> <accesspoint URLType="http"> </accesspoint> <tmodelinstancedetails> <tmodelinstanceinfo tmodelkey="uuid:eb1b645f-cf2f-491f-811a f5904"> <instancedetails> <overviewdoc> <description> references the description of the WSDL service definition </description> <overviewurl> </overviewurl> </overviewdoc> </instancedetails> </tmodelinstanceinfo> </tmodelinstancedetails> </bindingtemplate> tmodel είναι ο τελευταίος βασικός τύπος δεδομένων, ο οποίος αντιπροσωπεύει το τεχνικό μοντέλο μιας παρεχόμενης WS, δίνοντας τη δυνατότητα σε κάθε αφηρημένη έννοια, να μπορεί να καταγραφεί ως tmodel. [35]

36 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα <tmodel tmodelkey="uuid:xyz987..." operator=" authorizedname="john Doe"> <name>helloworldinterface Port Type</name> <description> An interface for a friendly Web service </description> <overviewdoc> <overviewurl> </overviewurl> </overviewdoc> </tmodel> publisherassertion πρόκειται για μια σχεσιακή δομή η οποία συσχετίζει δύο ή περισσότερες οντότητες (businessentities) ανάλογα με τον τύπο της σχέσης που υπάρχει ανάμεσά τους. Αποτελείται από τρία στοιχεία, fromkey, tokey και keydreference όπως φαίνεται και στο παράδειγμα. <element name="publisherassertion" type="uddi:publisherassertion" /> <complextype name="publisherassertion"> <sequence> <element ref="uddi:fromkey" /> <element ref="uddi:tokey" /> <element ref="uddi:keyedreference" /> </sequence> </complextype> Τέλος, δεδομένου ότι η εγγραφή μιας WS στον κατάλογο υπηρεσιών δεν έχει καμία χρησιμότητα εάν δεν υπάρχει τρόπος να προσπελαστεί, απαιτούνται τα κατάλληλα Interfaces. Το UDDI ορίζει δύο τύπους, για τους providers και για τους clients, έτσι ώστε να έχουν πρόσβαση στους καταλόγους υπηρεσιών. Οι providers κάνουν χρήση των μεθόδων των publisher interfaces, ενώ οι clients κάνουν χρήση των μεθόδων των inquiry interfaces Επίπεδο ποιότητας υπηρεσιών - Quality of Service (QoS) Το επίπεδο αυτό αναφέρεται στην επόμενη σημαντική απαίτηση που τίθεται όσον αφορά στις εφαρμογές που είναι προσανατολισμένες στις υπηρεσίες. Πρέπει να λειτουργούν με τέτοιο τρόπο που θα ενεργούν αξιόπιστα και θα παρέχουν τις υπηρεσίες με συνέπεια, σε όλα τα επίπεδα. Αυτό επιτυγχάνεται ορίζοντας σαφώς το σύνολο των λειτουργικών και μη λειτουργικών απαιτήσεων αλλά και περιγράφοντας αναλυτικά το περιβάλλον το οποίο θα φιλοξενήσει τις WS. Ως ποιότητα των υπηρεσιών, λοιπόν, ορίζεται η ικανότητα των WS να ανταποκρίνονται σε αναμενόμενες κλήσεις και να εκτελούν τις αντίστοιχες λειτουργίες με τρόπο ανάλογο με τον προσδοκώμενο. Οι κυριότεροι συντελεστές ποιότητας, τόσο από τη μεριά των providers όσο και από τη μεριά των clients είναι η διαθεσιμότητα, η προσβασιμότητα, η προσαρμογή στα πρωτόκολλα, η ακεραιότητα, η απόδοση, η αξιοπιστία, η επεκτασιμότητα και η ασφάλεια (3).

37 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Αξίζει να σημειωθεί ότι υπάρχουν και άλλα πρωτόκολλα τα οποία έχουν να κάνουν με τη διαχείριση των WS και της πληροφορίας που μεταδίδεται μέσω αυτών. Ένα από αυτά τα πρωτόκολλα είναι το WS Management Protocol (WS-Management), το οποίο περιλαμβάνει προδιαγραφές σχετικά με την απόδοση, τη διαχείριση προβλημάτων, την παρακολούθηση της κατάστασης και τον έλεγχο των υπηρεσιών. Τέλος, ακόμη ένα πρωτόκολλο που ακολουθείται ολοένα και περισσότερο, λόγω της ανάπτυξης των δικτυακών συστημάτων, είναι το WS Coordination Protocol (WS-Coordination) το οποίο περιλαμβάνει προδιαγραφές σχετικά με το συνδυασμό και τη συνεργασία μεταξύ διαφορετικών WS, που ενδέχεται να προέρχονται από τον ίδιο ή από διαφορετικούς providers. Ολοκληρώνοντας την περιγραφή των πρωτοκόλλων βάσει των οποίων δομείται η αρχιτεκτονική των WS, δίνεται ένα αναλυτικότερο σχήμα αυτής, το οποίο την προσεγγίζει από μια διαφορετική και πιο λεπτομερή σκοπιά. Σχήμα 2.6: Στοίβες πρωτοκόλλων Web Services (1) Όσον αφορά την κυριολεκτική έννοια, δεν πρόκειται για στοίβα, εφόσον τα επίπεδα δεν είναι ανεξάρτητα και δομημένα από πάνω προς τα κάτω [37]

38 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σχεδίαση- Ανάπτυξη Για τη σχεδίαση, την ανάπτυξη και τη σύνθεση των κατάλληλων WS που θα παρέχουν τις απαιτούμενες υποδομές και λειτουργικότητες στα επιμέρους συστήματα ενός ενσωματωμένου δικτυακού συστήματος, ακολουθούνται βασικές τεχνικές που διέπουν τις SOA. Οι τεχνικές αυτές είναι ένα σύνολο βημάτων που εξασφαλίζουν ευελιξία και προσαρμοστικότητα, τα δύο κυριότερα χαρακτηριστικά των WS, και μπορούν να υλοποιηθούν από ανθρώπους αλλά και από αυτοματοποιημένα συστήματα. Ο προγραμματιστής αρχικά πρέπει να προσδιορίσει το μοντέλο των επιχειρησιακών διαδικασιών που πρόκειται να ακολουθηθεί, να καθορίσει την αρχιτεκτονική σε επίπεδο εσωτερικής ιεραρχίας, να επιλέξει τις κατάλληλες υπηρεσίες μέσα από μια αποθήκη (repository) παρεχόμενων υπηρεσιών και τέλος να υλοποιήσει μια εφαρμογή που θα ανταποκρίνεται στις απαιτήσεις των σεναρίων που έχουν αναγνωριστεί. Αυτοματοποιημένες μέθοδοι που ακολουθούν την ίδια αλληλουχία ενεργειών, μπορούν να εκτελεστούν και από ειδικού σκοπού συστήματα τα οποία ελέγχουν τη σύνθεση και τη δόμηση των υπηρεσιών αυτόματα. Παρ όλα αυτά, είναι απαραίτητη η ύπαρξη του κατάλληλου interface το οποίο θα δίνει τη δυνατότητα τόσο στο χρήστη-προγραμματιστή όσο και σε εξωτερικά συστήματα λογισμικού να επέμβουν για τη βελτιστοποίηση και την οριστικοποίηση αποτελέσματος (1). Οι WS σχεδιάζονται και υλοποιούνται με τρόπο τέτοιο, ώστε να είναι πλέον σε θέση να χρησιμοποιηθούν σε συνδυασμό με τις περισσότερες τεχνολογίες αιχμής, όπως είναι οι ολοκληρωμένες εφαρμογές ενσωματωμένων συστημάτων και κινητών συσκευών, δίνοντας λύση σε πολλά προβλήματα που παρουσιάζονται λόγω έλλειψης διαλειτουργικότητας και ανεξαρτησίας. Τα πλεονεκτήματα που προκύπτουν από τη χρήση WS και αναφέρθηκαν σε προηγούμενη υπό-ενότητα, αναγνωρίζονται και στο πλαίσιο των τεχνολογιών αυτών (7). Στη συνέχεια ακολουθεί μια εισαγωγή στις βασικές έννοιες των ενσωματωμένων συστημάτων. 2.5 Ενσωματωμένα συστήματα - Embedded Systems Ένα ενσωματωμένο σύστημα (embedded system) είναι ένα εφαρμοσμένο υπολογιστικό σύστημα το οποίο διακρίνεται από άλλους τύπους υπολογιστικών συστημάτων, όπως είναι οι ηλεκτρονικοί υπολογιστές. Παρ όλα αυτά, είναι δύσκολο να δοθεί ένας σαφής ορισμός για τα συστήματα αυτά, καθώς συνεχώς εξελίσσονται εμπλέκοντας νέες τεχνολογίες και μειώνοντας ταυτόχρονα το κόστος υλοποίησής τους. Έτσι, ενώ παλαιότερα ένα ενσωματωμένο σύστημα θεωρούταν ένα σύστημα με περιορισμένες δυνατότητες σε hardware και software συγκρινόμενο με έναν ηλεκτρονικό υπολογιστή και ήταν σχεδιασμένο ώστε να εκτελεί συγκεκριμένες λειτουργίες, σήμερα κάτι τέτοιο δεν ισχύει. Αντιθέτως, έχει καθιερωθεί ο συνδυασμός hardware και software σε υψηλών επιδόσεων πολύπλοκα ενσωματωμένα συστήματα, τα οποία βρίσκουν εφαρμογή στους περισσότερους τομείς, προσφέροντας υψηλότερη αξιοπιστία και καλύτερη ποιότητα από άλλα υπολογιστικά συστήματα. Παρακάτω δίνονται σχηματικά οι τομείς όπου βρίσκουν εφαρμογή τα ενσωματωμένα συστήματα (8).

39 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 ΑΥΤΟΚΙΝΗΤΟΒΙΟΜΗΧΑΝΙΑ ΗΛΕΚΤΡΟΝΙΚΑ ΕΙΔΗ ΕΥΡΕΙΑΣ ΚΑΤΑΝΑΛΩΣΗΣ ΙΑΤΡΙΚΗ Συστήματα ανάφλεξης Συστήματα παραβίασης Συστήματα ελέγχου Συστήματα εντοπισμού θέσης Συστήματα πλοήγησης Ψηφιακές/αναλογικές τηλεοράσεις Ηλεκτρικές συσκευές Κινητά τηλέφωνα Παιχνίδια Κάμερες/φωτογραφικές μηχανές Συστήματα εντοπισμού θέσης (GPS) Ψηφιακές συσκευές Αντλίες έγχυσης Συστήματα καρδιακής παρακολούθησης Τεχνητά μέλη Συστήματα απεικόνισης Συστήματα πρόβλεψης ΒΙΟΜΗΧΑΝΙΚΟΣ ΕΛΕΓΧΟΣ ΕΠΙΧΕΙΡΗΣΕΙΣ Ρομποτικά συστήματα Συστήματα ελέγχου Συστήματα αυτοματισμού Φωτοαντιγραφικά Εκτυπωτές Οθόνες Σαρωτές Τηλεφωνικές συσκευές Σχήμα 2.7: Τομείς εφαρμογής ενσωματωμένων συστημάτων Τα κυριότερα πλεονεκτήματα που εμφανίζουν τα ενσωματωμένα συστήματα έχουν να κάνουν με τη λειτουργικότητα, τη σχεδίαση, την υλοποίηση και το κόστος τους. Δεδομένου ότι πρόκειται για συστήματα τα οποία έχουν πολύ μικρές διαστάσεις, η πολυπλοκότητά τους μειώνεται και η σχεδίασή τους καθίσταται απλούστερη σε σύγκρισή με άλλα συστήματα. Αυτό έχει ως αποτέλεσμα να μπορούν να λειτουργήσουν με μικρότερη κατανάλωση υπολογιστικών πόρων και να έχουν χαμηλότερο κόστος παραγωγής και συντήρησης. Τέλος, ένα από τα σημαντικότερα πλεονεκτήματα των συστημάτων αυτών, είναι το γεγονός ότι μπορούν να ανταποκριθούν σε συνθήκες και απαιτήσεις πραγματικού χρόνου (real time), καθώς το μέγεθός τους είναι τέτοιο που ελαχιστοποιεί τους χρόνους μετάδοσης πληροφορίας κατά μήκος των συνδεσμολογιών τους. Μια εφαρμογή πραγματικού χρόνου (real time application) είναι μια εφαρμογή η οποία λειτουργεί εντός ενός ορισμένου χρονικού πλαισίου, ικανού να δώσει στο χρήστη την εντύπωση άμεσης ή συγχρονισμένης απόκρισης του συστήματος. Η καθυστέρηση πρέπει να είναι μικρότερη από μια προκαθορισμένη τιμή, συνήθως μετρούμενη σε υποδιαιρέσεις του δευτερολέπτου και εξαρτάται άμεσα από το hardware του συστήματος. Για το σχεδιασμό των ενσωματωμένων συστημάτων οι μηχανικοί έχουν υιοθετήσει ορισμένα πρότυπα τα οποία μπορούν να εφαρμοστούν για να περιγράψουν τον κύκλο της διαδικασίας. Τα κυριότερα από αυτά τα πρότυπα εξετάζονται στο επόμενο κεφάλαιο, όπου αναλύονται εκτενώς οι τρόποι σχεδίασης αρχιτεκτονικών για ενσωματωμένα συστήματα. [39]

40 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Αρχιτεκτονική ενσωματωμένων συστημάτων Η αρχιτεκτονική ενός ενσωματωμένου συστήματος είναι μια αφαίρεση της εκάστοτε ενσωματωμένης συσκευής. Αυτό σημαίνει ότι πρόκειται για μια γενίκευση του συστήματος, η οποία αποκρύπτει λεπτομέρειες που αφορούν στην υλοποίησή του, όπως είναι για παράδειγμα ο πηγαίος κώδικας του λογισμικού του ή η κυκλωματική του αναπαράσταση. Στο επίπεδο αυτό, τα τμήματα του υλικού (hardware) και λογισμικού (software) που συμμετέχουν στο σύστημα αναπαρίστανται ως αλληλεπιδρώντα στοιχεία βάσει της συμπεριφοράς τους και της αλληλοσυσχέτισής τους. Η αναπαράστασή τους έχει τη μορφή δομών (structures). Μια δομή είναι ένα στιγμιότυπο του hardware και software του συστήματος κατά τη φάση του σχεδιασμού ή της εκτέλεσης, σε συγκεκριμένες συνθήκες και με καθορισμένες παραμέτρους. Όλες οι δομές είναι εγγενώς συσχετιζόμενες μεταξύ τους και στο σύνολό τους δομούν την αρχιτεκτονική του συστήματος. Ανεξάρτητα όμως από την αρχιτεκτονική που ακολουθείται για το σχεδιασμό και την υλοποίηση των ενσωματωμένων συστημάτων, όλα βασίζονται σε ένα γενικευμένο, ιεραρχικό μοντέλο τριών επιπέδων, αλληλοεξαρτώμενων μεταξύ τους. Το μοντέλο αυτό περιλαμβάνει το hardware του συστήματος, το software του συστήματος και το software της εφαρμογής για την οποία έχει σχεδιασθεί το σύστημα. Σχήμα 2.8: Ιεραρχικό μοντέλο ενσωματωμένων συστημάτων Δικτύωση ενσωματωμένων συστημάτων Με τον όρο δίκτυο εννοούμε τη σύνδεση δύο ή περισσότερων συστημάτων με τρόπο τέτοιο ώστε να υποστηρίζεται η ανταλλαγή δεδομένων και πληροφορίας μεταξύ τους. Όταν ένα ενσωματωμένο σύστημα απαιτεί την επικοινωνία με άλλα συστήματα τότε πρέπει να υποστηρίζει λειτουργίες δικτύωσης. Η κατανόηση της δομής ολόκληρου του δικτύου είναι πολύ σημαντικός παράγοντας, καθώς τα βασικά χαρακτηριστικά του, όπως η απόσταση μεταξύ των διασυνδεδεμένων συστημάτων και το φυσικό μέσο διάδοσης, θα είναι αυτά που θα καθορίσουν και τα πρότυπα που θα πρέπει να

41 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 εφαρμοστούν. Για να καταστεί ένα δίκτυο λειτουργικό, πρέπει καταρχάς όλα τα συστήματα που συνδέονται σε αυτό να διαθέτουν την κατάλληλη υποδομή και στην συνέχεια να προγραμματίζονται με τέτοιο τρόπο ώστε να ακολουθούν από κοινού, συγκεκριμένα πρωτόκολλα δικτυακής επικοινωνίας. Τα συστήματα που συμμετέχουν σε ένα δίκτυο μπορεί να είναι συνδεδεμένα είτε ενσύρματα είτε ασύρματα. Όσον αφορά τα ενσύρματα δίκτυα, ως μέσο διάδοσης χρησιμοποιούνται οι αγωγοί, οι οποίοι σχηματίζουν ένα φυσικό μονοπάτι οδηγώντας έτσι τα ηλεκτρομαγνητικά κύματα στο εσωτερικό τους. Όσον αφορά τα ασύρματα δίκτυα, ως μέσο διάδοσης χρησιμοποιείται το κενό ή ο αέρας. Στην περίπτωση αυτή δε σχηματίζεται κάποιο φυσικό μονοπάτι, επομένως τα ηλεκτρομαγνητικά κύματα δε θεωρούνται οδηγούμενα. Βασικά χαρακτηριστικά που διαφοροποιούν οποιοδήποτε, ενσύρματο ή ασύρματο, μέσο διάδοσης από τα υπόλοιπα, είναι: Ο τύπος δεδομένων που υποστηρίζει το μέσο προς μετάδοση Η χωρητικότητα του μέσου Η ταχύτητα διάδοσης του μέσου Η απόσταση στην οποία υπάρχει η δυνατότητα μετάδοσης των δεδομένων Η ευαισθησία του μέσου σε εξωγενείς παράγοντες Τις τελευταίες δύο δεκαετίες υπήρξε μια αξιοσημείωτη εξέλιξη των ενσωματωμένων συστημάτων, που κατέστησε δυνατή την ενσωμάτωσή τους πάνω στο ίδιο ολοκληρωμένο κύκλωμα (System on Chip - SoC). Η εξέλιξη αυτή προσφέρει δυναμικό συνδυασμό πολύπλοκων λειτουργιών με ταυτόχρονη αύξηση της απόδοσης και της διαλειτουργικότητάς τους σε επίπεδο δικτύου, βελτιστοποιώντας ταυτόχρονα τα παραπάνω χαρακτηριστικά τους ως στοιχεία δικτύων. Η ποικιλία στον τομέα εφαρμογών των ενσωματωμένων συστημάτων επιβάλλει λειτουργικές και μη λειτουργικές απαιτήσεις οι οποίες θα τα καθιστούν ικανά να ανταποκρίνονται σε διαδραστικά περιβάλλοντα πραγματικού χρόνου. Οι βασικοί τεχνολογικοί παράγοντες που επηρεάζουν την ανάπτυξη τέτοιων συνεργαζόμενων συστημάτων είναι τέσσερις, το hardware που χρησιμοποιείται, οι αλγόριθμοι που αναπτύσσονται, οι μη λειτουργικές ιδιότητες και τα συστήματα λογισμικού. Σε αυτό το σημείο θα εστιάσουμε περισσότερο σε RFID συστήματα στο επίπεδο hardware, τα οποία παρουσιάζονται στη συνέχεια. 2.6 Η τεχνολογία RFID Ο όρος RFID (Radio Frequency Identification) αναφέρεται στην ασύρματη επικοινωνία μέσω ραδιοσυχνοτήτων, η οποία χρησιμοποιείται για την ταυτοποίηση έμψυχων ή άψυχων οντοτήτων, εφοδιασμένων με την απαιτούμενη ετικέτα (RFID tag). Πρόκειται για μια τεχνολογία η οποία εμφανίζει ραγδαία ανάπτυξη και χρησιμοποιείται ευρέως τα τελευταία χρόνια σε πολλούς τομείς (9) (10). Ένα τυπικό σύστημα RFID αποτελείται από την RFID ετικέτα (RFID tag), τον αναγνώστη (RFID reader) και το ενδιάμεσο λογισμικό (middleware).η λειτουργία του είναι απλή και βασίζεται στη δυναμική και [41]

42 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα αμφίδρομη επικοινωνία μεταξύ ετικετών και αναγνωστών. Όταν μια ετικέτα βρεθεί εντός εμβέλειας της κεραίας του reader, μια μονάδα ελέγχου επικοινωνεί μέσω ραδιοκυμάτων με την κεραία των RFID ετικετών. Οι ετικέτες ενεργοποιούνται με τη σειρά τους και επιστρέφουν τα ζητούμενα δεδομένα στον reader. Τα δεδομένα αποστέλλονται από τον reader στο ενδιάμεσο λογισμικό, το οποίο αναλαμβάνει την επεξεργασία τους, ανάλογα με την εκάστοτε εφαρμογή. Σχήμα 2.9: Διαγραμματική απεικόνιση ενός RFID συστήματος RFID ετικέτα Η RFID ετικέτα (RFID tag)είναι μια συσκευή η οποία τοποθετείται στην προς ταυτοποίηση οντότητα και φέρει έναν μοναδικό σειριακό αριθμό. Αποτελείται από ένα ολοκληρωμένο κύκλωμα, το οποίο έχει τη δυνατότητα να αποθηκεύει μικρή ποσότητα δεδομένων, και από μια κεραία η οποία χρησιμοποιείται για την αποστολή και λήψη σημάτων μέσω ραδιοκυμάτων. Η διάταξη αυτή τοποθετείται σε ενιαία, γυάλινη ή πλαστική συσκευασία με μέγιστες διαστάσεις μερικών τετραγωνικών εκατοστών. Οι ετικέτες μπορούν να χωριστούν σε διάφορες κατηγορίες με βάση τη χωρητικότητα, τη συχνότητα λειτουργίας, την εμβέλεια και τον τρόπο κωδικοποίησης του σήματος. Ένας επιπλέον τρόπος κατηγοριοποίησης των ετικετών, γίνεται με βάση τον τρόπο με τον οποίο αυτές τροφοδοτούνται με ενέργεια και έτσι προκύπτουν οι ενεργές (active), οι παθητικές (passive)και οι ημι-παθητικές (semi-passive or battery assisted passive) ετικέτες. Σχήμα 2.10: Δομή RFID ετικέτας

43 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Ενεργές ετικέτες: οι ετικέτες αυτές είναι εφοδιασμένες με εσωτερική πηγή (μπαταρία) για την πλήρη ή μερική τροφοδοσία του ολοκληρωμένου κυκλώματος και της κεραίας τους, καθώς και με πομποδέκτη (transceiver) για τη παραγωγή του απαιτούμενου ηλεκτρομαγνητικού σήματος. Η δομή αυτή καθιστά δυνατή την εκπομπή σημάτων και χωρίς την παρουσία κάποιου reader, ενώ ταυτόχρονα αυξάνεται η εμβέλειά τους. Επιπλέον, διαθέτουν μεγαλύτερη μνήμη και η υπολογιστική τους ικανότητα είναι αυξημένη ενώ υπάρχει η δυνατότητα να συνδυασθούν με ενσωματωμένους αισθητήρες προκειμένου να εκπέμπουν τις τιμές των μετρήσεών τους. Τα παραπάνω χαρακτηριστικά κάνουν σαφές το γεγονός ότι οι ετικέτες αυτές έχουν μεγαλύτερο μέγεθος και μεγαλύτερο κόστος ενώ εισάγουν πάντα τον περιορισμό της ανάγκης για συνεχή τροφοδοσία. Παθητικές ετικέτες: οι ετικέτες αυτές τροφοδοτούνται από τον reader. Επιπλέον, καθώς δεν διαθέτουν εσωτερικό πομποδέκτη, διαμορφώνουν κατάλληλα το εισερχόμενο σήμα του reader ώστε να εκπέμψουν τα δεδομένα που βρίσκονται κωδικοποιημένα στη μνήμη τους. Όταν η κεραία βρεθεί εντός της εμβέλειας κάποιου reader, η κεραία που διαθέτει απορροφά την απαραίτητη ενέργεια μέσω του ηλεκτρομαγνητικού σήματος που λαμβάνει, ώστε να ενεργοποιήσει το ολοκληρωμένο κύκλωμα, να διαμορφώσει στη συνέχεια το σήμα αυτό και τέλος να εκπέμψει τα αποθηκευμένα δεδομένα. Η δομή τους είναι ιδιαίτερα απλή, με αποτέλεσμα οι ετικέτες αυτού του είδους να έχουν χαμηλότερο μέγεθος και κόστος ενώ η διάρκεια ζωής τους είναι ιδιαίτερα μεγάλη. Ημι-παθητικές ετικέτες: στην τρίτη κατηγορία ανήκουν ετικέτες οι οποίες διαθέτουν εσωτερική πηγή τροφοδοσίας για την ενίσχυση του σήματος που εκπέμπουν. Δε διαθέτουν εσωτερικό πομποδέκτη, η εμβέλειά τους, όμως, είναι αυξημένη λόγω του ενισχυμένου εκπεμπόμενου σήματος. Η μνήμη τους μπορεί να είναι αρκετά μεγαλύτερη από εκείνη των παθητικών ετικετών ενώ το κόστος και το μέγεθός τους κυμαίνεται ανάμεσα στα αντίστοιχα μεγέθη των άλλων δύο κατηγοριών. Πηγή τροφοδοσίας Πίνακας 2.1: Σύγκριση ενεργών παθητικών RFID ετικετών Active RFID tags Εσωτερική (μπαταρία) Passive RFID tags Εξωτερική (παρεχόμενη από τον reader) Εμβέλεια Έως και 100 μέτρα Έως και 3 μέτρα Αποθήκευση δεδομένων Διάρκεια ζωής Μεγαλύτερο μέγεθος μνήμης (έως και 128 Kbytes) Περιορισμένος (έως 5 χρόνια, αναλόγως την μπαταρία) Περιορισμένο μέγεθος μνήμης (έως και 128 Bytes) Πολύ μεγάλο Κόστος Μεγάλο Μικρό Μέγεθος Μεγάλο Μικρό Οι ετικέτες μπορούν να κατηγοριοποιηθούν και με βάση τον τύπο μνήμης που διαθέτουν. Έτσι, υπάρχουν οι ετικέτες που είναι μόνο για ανάγνωση (read only RO) και ετικέτες που είναι και για ανάγνωση αλλά και για εγγραφή (read/write RW). [43]

44 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Ετικέτες μόνο για ανάγνωση: οι ετικέτες αυτές προγραμματίζονται μία μόνο φορά κατά τη διαδικασία παραγωγής τους και δεν υπάρχει δυνατότητα τροποποίησης των δεδομένων τους. Τα δεδομένα που εισάγονται είναι πολύ περιορισμένα και στατικά, για παράδειγμα σειριακοί αριθμοί, τα οποία μπορούν εύκολα να ενοποιηθούν με ήδη υπάρχοντα συστήματα bar codes, καθώς η λειτουργία τους μοιάζει αρκετά. Ετικέτες εγγραφής/ανάγνωσης: οι ετικέτες αυτές παρέχουν μεγαλύτερη ευελιξία στον τελικό χρήστη, καθώς μπορούν να διατηρήσουν στη μνήμη τους μεγαλύτερη ποσότητα πληροφορίας, η οποία μπορεί να τροποποιηθεί δυναμικά πολλές φορές, ανάλογα με τις εκάστοτε ανάγκες του συστήματος για το οποίο προορίζονται RFID αναγνώστης Ο RFID αναγνώστης (RFID reader) είναι η συσκευή η οποία επικοινωνεί μέσω ραδιοκυμάτων με τις RFID ετικέτες. Το σύστημα ενός RFID reader περιλαμβάνει μία κεραία (εσωτερική ή εξωτερική), RF κυκλώματα, ένα κύκλωμα ελέγχου και θύρες εισόδου/εξόδου για τη διασύνδεση με το υπολογιστικό σύστημα. Οι βασικές λειτουργίες του είναι οι ακόλουθες: Ανάγνωση των δεδομένων που περιέχονται σε μια ετικέτα Εγγραφή δεδομένων σε μία ετικέτα Αναμετάδοση δεδομένων από και προς κάποιο υπολογιστικό σύστημα για περεταίρω επεξεργασία Τροφοδότηση παθητικών και ημι-παθητικών ετικετών με την απαραίτητη ενέργεια Βασικές προϋποθέσεις για να καταστεί δυνατή η επικοινωνία μεταξύ ενός reader και μιας ετικέτας είναι τα πρωτόκολλα επικοινωνίας που υλοποιούνται, καθώς και τα δομικά χαρακτηριστικά τόσο των ετικετών όσο και των αναγνωστών, τα οποία πρέπει να είναι συμβατά. Ο τρόπος επικοινωνίας του reader με το κεντρικό υπολογιστικό σύστημα εξαρτάται από την εκάστοτε εφαρμογή. Οι readers μπορούν να κατηγοριοποιηθούν ανάλογα με την εφαρμογή για την οποία προορίζονται, τα τεχνικά τους χαρακτηριστικά και τις φυσικές τους διαστάσεις: Σταθεροί readers (fixed readers): χρησιμοποιούνται κυρίως στη διαχείριση της εφοδιαστικής αλυσίδας Ενσωματωμένοι readers (embedded readers): χρησιμοποιούνται κυρίως σε εφαρμογές που περιλαμβάνουν ενσωματωμένα συστήματα (embedded systems) Ολοκληρωμένοι readers (integrated readers): έχουν τη μορφή κάρτας και χρησιμοποιούνται σε εφαρμογές που απαιτούν έλεγχο πρόσβασης και μπορούν να διασυνδεθούν με φορητές συσκευές Φορητοί readers χειρός (portable handheld readers): διαθέτουν ενσωματωμένη οθόνη και χρησιμοποιούνται κυρίως στη διαχείριση της εφοδιαστικής αλυσίδας αλλά και σε συστήματα ελέγχου

45 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Τα RFID συστήματα μπορούν να λειτουργήσουν σε τέσσερις κύριες ζώνες συχνοτήτων που ανήκουν στις λεγόμενες ISM (Industrial, Scientific and Medical) συχνότητες: Low Frequency (LF): KHz High Frequency (HF): MHz Ultra High Frequency (UHF): MHz Microwave: 2.45 GHz Αξίζει να σημειωθεί πως παρουσιάζονται σημαντικές διαφοροποιήσεις στην κατανομή των παραπάνω ζωνών, από χώρα σε χώρα. Σχήμα 2.11: Διάφοροι τύποι RFID αναγνωστών RFID Middleware Ο βασικός ρόλος του ενδιάμεσου λογισμικού είναι να οργανώσει, να επεξεργαστεί και να αξιοποιήσει κατάλληλα τα δεδομένα που συλλέγονται από τους readers. Το ενδιάμεσο λογισμικό είναι αυτό το οποίο αναλαμβάνει την αμφίδρομη μεταφορά δεδομένων από και προς το εκάστοτε πληροφοριακό σύστημα με το οποίο είναι συνδεδεμένος ένας reader. Τα δεδομένα αυτά είναι σχετικά τόσο με την πληροφορία που αποθηκεύεται στις ετικέτες, όσο και με την πληροφορία που απαιτείται προκειμένου να επιτευχθεί η επικοινωνία μεταξύ reader και πληροφοριακού συστήματος. Επιπλέον, οι εντολές που δίνονται από το πληροφοριακό σύστημα στον reader, χωρίζονται σε εντολές ετικέτας (εύρεση ετικέτας, ανάγνωση/εγγραφή δεδομένων) και σε εντολές reader (κατάσταση reader, αλλαγή ρυθμίσεων, αλλαγή κωδικού κ.ά.). Για να θεωρηθεί ολοκληρωμένο ένα RFID middleware πρέπει να ικανοποιεί ένα σύνολο από απαιτήσεις. Συγκεκριμένα, πρέπει να παρέχει στον τελικό χρήστη τη δυνατότητα να προγραμματίσει τον reader ώστε να ανταποκρίνεται σε εντολές, μέσω ενός καλά ορισμένου Interface. Στη συνέχεια, τα δεδομένα τα οποία συλλέγονται από τον reader πρέπει να φιλτράρονται κατάλληλα πριν οδηγηθούν στον εκάστοτε προορισμό προς επεξεργασία. Επιπλέον, δεδομένου ότι ο χρόνος που απαιτείται για το σχεδιασμό και την ανάπτυξη ολοκληρωμένων εφαρμογών είναι πολύ σημαντικός παράγοντας, ένα RFID middleware θα πρέπει να διευκολύνει την προσαρμογή, την επεκτασιμότητα και τη διαλειτουργικότητα ενός RFID συστήματος. Τέλος, ένα RFID middleware πρέπει να διαθέτει όλα τα χαρακτηριστικά που θα επιτρέπουν την αξιοποίηση των δεδομένων σε ERP (Enterprise Resource Planning), WMS (Warehouse Management System) και CRM (Customer Relationship Management) συστήματα, παρέχοντας ταυτόχρονα τα κατάλληλα APIs προκειμένου να διευκολύνει την επικοινωνία [45]

46 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα με εξωτερικές εφαρμογές, καθώς και την B2B (Business to Business) συνεργασία και ανταλλαγή δεδομένων (11) Εφαρμογές RFID συστημάτων Όπως αναφέρθηκε, η τεχνολογία των RFID συστημάτων γνωρίζει ραγδαία ανάπτυξη τα τελευταία χρόνια, ενώ όλο και περισσότερες εφαρμογές μπορούν να αξιοποιήσουν τα πλεονεκτήματα που προσφέρουν τα εν λόγω συστήματα σε τομείς της καθημερινότητας και των επιχειρήσεων. Οι πιο καθιερωμένες από αυτές αφορούν σε συστήματα διαχείρισης εφοδιαστικής αλυσίδας (SCM) και συστήματα διαχείρισης αποθήκης (WMS), ενώ η χρήση RFIDs για αναγνώριση αντικειμένων και ζώων είναι πλέον πολύ συνηθισμένη. Γνωστό παράδειγμα αποτελεί επίσης η ενσωμάτωση RFID ετικετών σε ηλεκτρονικές κάρτες έτσι ώστε να γίνεται χρήση τόσο σε συστήματα αυτόματων πληρωμών όσο και σε συστήματα ελέγχου πρόσβασης και ταυτοποίησης. Τέλος, υπάρχουν συστήματα εντοπισμού θέσης (Real Time Locating Systems RTLS) τα οποία υπολογίζουν τη θέση του αντικειμένου που φέρει RFID ετικέτα με ακρίβεια μικρότερη των 2 μέτρων. 2.7 Ανασκόπηση κεφαλαίου Με την εξέλιξη της τεχνολογίας, ολοένα και μικρότερες συσκευές μπορούν να λειτουργήσουν αυτόνομα, ανεξαρτήτως κεντρικού ελέγχου, να εκμεταλλευτούν μεγαλύτερη υπολογιστική ισχύ και να κερδίσουν περισσότερη νοημοσύνη (smart devices) παίρνοντας κρίσιμες αποφάσεις βασιζόμενες στην πληροφορία που δέχονται από το περιβάλλον τους μέσω παρεχόμενων δικτυακών υπηρεσιών. Μπορούν επίσης να διαθέσουν τη λειτουργικότητά τους μέσω καθορισμένων interfaces και να την συνδυάσουν κατάλληλα για να συνθέσουν πιο πολύπλοκες, ενοποιημένες δομές. Λαμβάνοντας υπ όψιν τα παραπάνω, ο τομέας των συνεργαζόμενων αντικειμένων (Cooperating Objects) (12) οραματίζεται τη διασύνδεση τεράστιου αριθμού ενσωματωμένων συστημάτων, όπως είναι τα δίκτυα αισθητήρων και ενεργοποιητών, βιομηχανικές γραμμές και μηχανές ακόμη και οικιακές συσκευές, σε ένα συνεργαζόμενο καθολικό δίκτυο στο οποίο κάθε τμήμα θα προσφέρει στα υπόλοιπα τις υπηρεσίες του. Η λειτουργικότητα και τα δεδομένα αυτών των συστημάτων θα παρέχονται σε πραγματικό χρόνο αλληλεπιδρώντας τόσο με τελικούς χρήστες όσο και με ενδιάμεσες εφαρμογές. Καθώς λοιπόν ο αριθμός των συνεργαζόμενων συστημάτων θα αυξάνεται εκθετικά κάθε χρόνο, ένα καθολικό δίκτυο θα επιτρέπει την ανάπτυξη συνεργαζόμενων διεργασιών. Τα δίκτυα αισθητήρων που αναφέρθηκαν στην προηγούμενη ενότητα, αποτελούν ένα απλό παράδειγμα του ευρύτερου τομέα των συνεργαζόμενων αντικειμένων, ο οποίος προσπαθεί να θέσει τις κατάλληλες βάσεις για να κάνει πραγματικότητα το όραμα του Mark Weiser 1, ο οποίος θεωρείται ο πατέρας του όρου Ubiquitous Computing, για έναν κόσμο όπου οι ηλεκτρονικοί υπολογιστές θα 1

47 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 εκλείψουν. Οι βασικοί τεχνολογικοί παράγοντες που επηρεάζουν την ανάπτυξη τέτοιων συνεργαζόμενων συστημάτων είναι τέσσερις, το hardware που χρησιμοποιείται, οι αλγόριθμοι που αναπτύσσονται, οι μη λειτουργικές απαιτήσεις και τα συστήματα λογισμικού. Ανάμεσα στους τέσσερις αυτούς παράγοντες οι οποίοι επηρεάζουν την ανάπτυξη συνεργαζόμενων ενσωματωμένων συστημάτων, είναι και τα συστήματα λογισμικού. Τα ενσωματωμένα συστήματα τυπικά βρίσκονται σε περιβάλλοντα όπου είναι δύσκολη η εφαρμογή προβλέψεων ή η απόκτηση γνώσης και διαγνωστικής πληροφορίας. Για να ικανοποιηθούν οι συγκεκριμένες απαιτήσεις, οι προδιαγραφές των WS επιτρέπουν στους προγραμματιστές την ανάπτυξη τόσο εφαρμογών-clients όσο και εφαρμογών-providers στο ίδιο ενσωματωμένο σύστημα. Αυτό σημαίνει ότι ένα ενσωματωμένο σύστημα μπορεί να έχει πρόσβαση σε μια παρεχόμενη υπηρεσία αλλά ταυτόχρονα, το ίδιο σύστημα να παρέχει κάποια άλλη υπηρεσία στο δίκτυο. Με τον τρόπο αυτό επιτρέπεται η ροή πληροφορίας και δεδομένων από και προς τις συσκευές hardware ενώ οι προγραμματιστές είναι πλέον σε θέση να αναπτύξουν μηχανισμούς απομακρυσμένου ελέγχου, βελτιστοποιώντας τον κύκλο ζωής των υπηρεσιών διαχείρισης σε δημόσια αλλά και ιδιωτικά δίκτυα (7). Πιο συγκεκριμένα, ο συνδυασμός RFID ενσωματωμένων συστημάτων και WS τεχνολογιών, έχει προωθήσει κατά πολύ τη βελτίωση ολόκληρων των επιχειρησιακών και τεχνολογικών διαδικασιών αλλά και τη συνεχή συνεργασία συστημάτων με διαφορετικό υπόβαθρο και διαφορετικούς στόχους. Στο επόμενο κεφάλαιο πρόκειται να εστιάσουμε σε συστήματα λογισμικού και κυρίως σε αρχιτεκτονικές ενδιάμεσου λογισμικού που αφορούν στην εφαρμογή των τεχνολογιών WS σε ενσωματωμένα RFID συστήματα. [47]

48 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Κεφάλαιο 3 Υπηρεσιοστρεφείς Αρχιτεκτονικές για Ενσωματωμένα RFID Συστήματα Σχετική έρευνα

49 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος Εισαγωγή στο middleware ενσωματωμένων συστημάτων Τα τελευταία χρόνια, το ενδιαφέρον έχει στραφεί στην επικοινωνία και την ενοποίηση ετερογενών ενσωματωμένων συστημάτων, δίνοντας ιδιαίτερη έμφαση στην ανεξαρτησία από πλατφόρμες, σε πραγματικού χρόνου απαιτήσεις, στην ευρωστία και την ασφάλεια. Επιπλέον, η υιοθέτηση αποκεντρωμένων υπηρεσιοστρεφών αρχιτεκτονικών, συμβάλλει στη δημιουργία ευέλικτων και συνεργατικών περιβαλλόντων. Αυτό έχει ως αποτέλεσμα οι πληροφορίες να είναι διαθέσιμες κατά απαίτηση και να επιτρέπεται στις εφαρμογές επιχειρηματικού επιπέδου να τις χρησιμοποιούν ως δείκτες διάγνωσης, ιχνηλασιμότητας και απόδοσης, αυξάνοντας με αυτόν τον τρόπο την αποτελεσματικότητα και την ευελιξία των επιχειρήσεων που βρίσκονται πίσω από αυτές. Το Σχήμα 3.1 (13) συζητά τις αρχιτεκτονικές αυτές. Στο επίπεδο του συστήματος, η SOA επιτρέπει στις συσκευές να εκθέτουν διεπαφές υπηρεσιών υψηλού επιπέδου (high level service interfaces) με τη χρήση των πρωτοκόλλων που αναφέρθηκαν στο υποκεφάλαιο 2.4 (14) (15) (16). Σχήμα 3.1: Αποκεντρωμένη αρχιτεκτονική βασισμένη σε SOA Η διασύνδεση ενός συστήματος σε ένα δίκτυο όπως αυτό που παρουσιάζεται στο Σχήμα 3.1, σημαίνει ότι το σύστημα διατηρεί την αυτονομία του, δέχεται όμως δεδομένα ή υπηρεσίες που του παρέχονται από άλλα συστήματα για να επιτελέσει συγκεκριμένες λειτουργίες και να ολοκληρώσει διεργασίες που απαιτούν πρόσβαση στο εξωτερικό του περιβάλλον. Καθώς απαιτείται υψηλός βαθμός ανεξαρτησίας, [49]

50 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα το εκάστοτε σύστημα δε θα πρέπει να γνωρίζει λεπτομέρειες σχετικά με τα παρεχόμενα δεδομένα και τις παρεχόμενες υπηρεσίες. Για να επιτευχθεί ο στόχος αυτός, έχουν προταθεί πολλές μέθοδοι, οι οποίες προσανατολίζονται είτε στη βελτίωση του hardware είτε στην επέκταση των ήδη υπαρχόντων δικτυακών εφαρμογών. Τέτοια συστήματα, γνωστά και ως συστήματα ενδιάμεσου επιπέδου (middleware), θεωρούνται σήμερα μία από τις καλύτερες προσεγγίσεις. Βασικός στόχος της σχεδίασής τους είναι να αναλαμβάνουν την εύρεση των διαθέσιμων πόρων μέσα σε ένα δίκτυο, να υποστηρίζουν τόσο συγκεντρωμένες όσο και αποκεντρωμένες αρχιτεκτονικές, να εστιάζουν σε θέματα ασφάλειας και αξιοπιστίας και να αναπτύσσονται έτσι ώστε να είναι συμβατά όχι μόνο με νέες τεχνολογίες, αλλά και με παλαιότερες. Οι λόγοι για τους οποίους η επιστήμη προσανατολίζεται σήμερα στη χρήση middleware για να εξασφαλίσει την επικοινωνία μεταξύ ενσωματωμένων συστημάτων, έχει να κάνει με τα πλεονεκτήματα που αυτά προσφέρουν: Επιτρέπουν την απομακρυσμένη επικοινωνία, καθώς άρουν την αναγκαιότητα φυσικής διασύνδεσης μεταξύ των κόμβων ενός δικτύου. Καθιστούν την επικοινωνία μεταξύ των κόμβων ενός δικτύου ανεξάρτητα πλατφόρμας, τοποθεσίας και περιβάλλοντος. Είναι επαναχρησιμοποιούμενα συστήματα, με αποτέλεσμα να μην απαιτείται εκ νέου σχεδίαση σε περιπτώσεις με παρεμφερείς απαιτήσεις. Υποστηρίζουν περιβάλλοντα προσομοίωσης, απαραίτητα για τον έλεγχο των συστημάτων. Ένα middleware σύστημα πρέπει να παρέχει κοινά επίπεδα αφαίρεσης τα οποία θα μπορούν να επαναχρησιμοποιηθούν από διαφορετικές εφαρμογές του ίδιου τεχνολογικού πεδίου. Επιπλέον, πρέπει να είναι σχεδιασμένο έτσι, ώστε να επιδέχεται εύκολα τις απαραίτητες μετατροπές προκειμένου να ανταποκρίνεται σε συγκεκριμένες εφαρμογές. Επιπλέον, βασικά χαρακτηριστικά τα οποία πρέπει να διαθέτει το middleware το οποίο είναι σχεδιασμένο για δικτυωμένα ενσωματωμένα συστήματα, είναι να επιτρέπει την απομακρυσμένη επικοινωνία και να είναι ανεξάρτητο τοποθεσίας. Συμπερασματικά, ένα middleware σύστημα σχεδιάζεται προκειμένου να επεκτείνει τις δυνατότητες ενός άλλου λειτουργικού συστήματος, προσφέροντας υψηλού επιπέδου αφαιρέσεις και υπηρεσίες που μπορούν να χρησιμοποιηθούν σε μια πληθώρα εφαρμογών. Παρέχει λειτουργικότητα όπως η διανομή εργασιών (task distribution), η προσαρμοστικότητα σε μεταβαλλόμενες συνθήκες, ο διαμοιρασμός δεδομένων, η κλήση υπηρεσιών, η ανίχνευση γεγονότων και η διαχείριση του συστήματος. Επιπλέον, υπάρχουν συστήματα middleware τα οποία μεσολαβούν και δρουν ως συνδετικοί κρίκοι στη διασύνδεση ετερογενών ενσωματωμένων συστημάτων και δικτύων. Έχοντας καλύψει τα βασικότερα τεχνολογικά πεδία (Web Services, Service-oriented Computing, Serviceoriented Architectures, RFID Systems, Smart Networked Embedded Systems, Middleware) και έχοντας αποσαφηνίσει τις κυριότερες έννοιες που συναντώνται σε αυτά, προκύπτει η έννοια της νοημοσύνης (intelligence) ενός τέτοιου συνεργατικού συστήματος. Ένα σύστημα θεωρείται ότι έχει νοημοσύνη όταν είναι αυτόνομο και ενεργεί συνεργατικά με το περιβάλλον του με τον τρόπο που ορίζει το ίδιο ότι είναι βέλτιστος, καλύπτοντας τόσο τις δικές του ανάγκες, όσο και τις ανάγκες των χρηστών και των

51 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 συστημάτων που έχουν πρόσβαση σε αυτό. Συστήματα τα οποία διαθέτουν νοημοσύνη και ικανότητες ανίχνευσης και ενεργοποίησης, είναι ετερογενή (heterogeneous systems) και απαιτούν την απρόσκοπτη και εντατική διαλειτουργικότητα μέσω δικτύων. Στη συνέχεια του κεφαλαίου αυτού πρόκειται να παρουσιαστούν δύο εναλλακτικές αρχιτεκτονικές προσεγγίσεις σχεδίασης και ανάπτυξης υπηρεσιοστρεφών middleware συστημάτων. Η πρώτη προσέγγιση είναι αυτή που ακολουθείται από το ευρωπαϊκό έργο SOCRADES και η δεύτερη είναι αυτή που ακολουθείται από τον διεθνή οργανισμό ηλεκτρονικού κωδικού προϊόντος (Electronic Product Code EPC), EPCglobal. 3.2 Υπηρεσιοστρεφείς Αρχιτεκτονικές Ενσωματωμένων Συστημάτων Προσέγγιση SOCRADES Σύμφωνα με τον οργανισμό OASIS (17) (Organization for the Advancement of Structured Information Standards) η αποδόμηση, η σχεδίαση και η υλοποίηση ενός συστήματος καθώς και η εκτέλεση των διεργασιών του μπορούν να προσεγγιστούν από τη σκοπιά της υπηρεσιοστρεφούς αρχιτεκτονικής (SOA). Σε τέτοιες περιπτώσεις, κάθε ενέργεια του συστήματος μπορεί να υλοποιηθεί ως ανεξάρτητη υπηρεσία. Τα πλεονεκτήματα που προκύπτουν από τη χρήση SOA είναι παραπλήσια με αυτά των WS. Έτσι, σε αυτήν την περίπτωση, οι υπηρεσίες είναι αυτόνομες, ανεξάρτητες ενότητες, που διαθέτουν καλώς ορισμένα interfaces για την περιγραφή, τη δημοσίευση, την ανακάλυψη και την κλήση τους μέσω ενός δικτύου. Οι ιδιότητες αυτές επιτρέπουν τη δυναμική σύνθεση των υπηρεσιών σε ολοκληρωμένες εφαρμογές. Η κοινοπραξία του OASiS (Object-centric, Ambient-aware, Service-oriented Sensornet) (18), έχει αναπτύξει ένα σύνολο υπηρεσιών ενδιάμεσου επιπέδου για να υποστηρίξει εφαρμογές αυτού του τύπου. Οι υπηρεσίες διαθέτουν την κατάλληλη υποδομή ώστε να υποστηρίζουν λειτουργίες αισθητήρων και ενεργοποιητών (sensors/actuators), διαδιεργασιακή επικοινωνία και διαρκή υποστήριξη των επιμέρους συστημάτων. Η χρήση middleware χρησιμεύει ως ένα επίπεδο αφαίρεσης, αποκρύπτοντας την πολυπλοκότητα των κατώτερων επιπέδων. Επιπλέον, σύμφωνα με το πρόγραμμα OASiS ένα πολύ σημαντικό πλεονέκτημα που εμφανίζουν οι SOA είναι ότι επιτρέπουν την αποδοτική ενοποίηση ετερογενών δικτύων αισθητήρων, σε ισχυρά και εύρωστα δίκτυα αισθητήρων (sensor web). Ένα sensor web είναι ένα αποκεντρωμένο σύνολο δικτύων αισθητήρων το οποίο μπορεί να περιλάβει μικρές, χαμηλού κόστους συσκευές καθώς επίσης και υψηλών απαιτήσεων σε πόρους πλατφόρμες όπως είναι τα δορυφορικά συστήματα, οι μετεωρολογικοί σταθμοί, τα συστήματα ασφαλείας κ.ά. Παρά το γεγονός ότι οι SOA έχουν ήδη αποδειχθεί επιτυχημένες κατά τη χρήση τους στον παγκόσμιο ιστό, οι τεχνολογίες των WS που αναπτύχθηκαν βασιζόμενες σε διαδικτυακά πρωτόκολλα, δεν μπορούν να υλοποιηθούν σε όλα τα δίκτυα αισθητήρων που έχουν περιορισμένους πόρους. Αυτή η παρατήρηση επιβεβαίωσε την ανάγκη ανάπτυξης middleware το οποίο θα διαχειρίζεται αλλαγές που παρουσιάζονται στην τοπολογία των δικτύων και θα υποστηρίζει τη δυναμική ανακάλυψη των κατάλληλων υπηρεσιών που απαιτούνται για την κάλυψη των απαιτήσεων του εκάστοτε δικτύου. [51]

52 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σε όλα τα παραπάνω βασίστηκε η ομάδα του προγράμματος SOCRADES (13) το οποίο είναι ένα ευρωπαϊκό έργο. Στόχος του έργου ήταν η ανάπτυξη μιας πλατφόρμας σχεδίασης, εκτέλεσης και διαχείρισης για τα αυτόματα βιομηχανικά συστήματα της επόμενης γενιάς, εκμεταλλευόμενο τις SOA τόσο σε επίπεδο συστήματος όσο και σε επίπεδο εφαρμογής (19). Η τεχνική προσέγγιση που ακολουθήθηκε ήταν η δημιουργία ενός υπηρεσιοστρεφούς περιβάλλοντος, στο οποίο τα δικτυακά συστήματα θα αποτελούνται από έξυπνες ενσωματωμένες συσκευές που θα αλληλεπιδρούν με το φυσικό και το οργανωτικό τους περιβάλλον. Προσδίδοντας νοημοσύνη στο επίπεδο της συσκευής, το τελικό σύστημα συνίσταται από επιμέρους έξυπνα υποσυστήματα, τα οποία έχουν χαλαρή σύζευξη μεταξύ τους, είναι επαναδιαμορφώσιμο και προσαρμόσιμο και λειτουργεί σε πραγματικό χρόνο (real time) Επίπεδα αρχιτεκτονικής ενσωματωμένων συστημάτων Το SOCRADES κάνει δύο βασικές θεωρήσεις. Αφενός, τα δικτυωμένα συστήματα χαμηλού επιπέδου (αισθητήρες, ενεργοποιητές, ελεγκτές) πρέπει να συμπεριφέρονται με τρόπο ευέλικτο όσον αφορά ιδιότητες όπως είναι η ανοχή σε σφάλματα, η επαναδιαμόρφωση, η ασφάλεια και η απόκριση σε πραγματικό χρόνο. Από την άλλη πλευρά, όλα τα επίπεδα της ιεραρχίας των ενσωματωμένων συστημάτων και των δυνατοτήτων που παρέχουν, τόσο σε επίπεδο λειτουργικότητας όσο και σε επίπεδο διαχείρισης, θα πρέπει να μπορούν να επικοινωνήσουν βάσει υπηρεσιοστρεφών αρχιτεκτονικών. Αυτές οι δύο θεωρήσεις ικανοποιούνται με βάση τα επίπεδα στα οποία τμηματοποιούνται οι επιχειρηματικές δραστηριότητες και συναντώνται στα κατώτερα επίπεδα της ιεραρχίας, όπως φαίνεται στο Σχήμα 3.2.

53 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Σχήμα 3.2: Ιεραρχία επιχειρησιακών επιπέδων Επίπεδο συστήματος Το κατώτερο επίπεδο είναι αυτό του συστήματος. Στο επίπεδο αυτό, ανήκουν έξυπνες συσκευές, οι οποίες συνθέτουν ενσωματωμένα συστήματα νοημοσύνης. Τα συστήματα αυτά γνωστοποιούν τη λειτουργικότητά τους με τη μορφή WS, μέσω των κατάλληλων πρωτοκόλλων SOA και ανταλλάσσουν μηνύματα με κόμβους του δικτύου στο οποίο ανήκουν. Το επίπεδο αυτό μπορεί να αναλυθεί περεταίρω σε επιμέρους επίπεδα, τα οποία επίσης χρησιμοποιούν αφαιρετική λογική, βασιζόμενη στις υπηρεσίες. Ξεκινώντας από το χαμηλότερο, έχουμε το φυσικό επίπεδο (physical level), το επίπεδο ελέγχου έξυπνης λογικής (smart logic control level) και το επίπεδο των υπηρεσιών. Το τελευταίο επίπεδο είναι αυτό που, ενσωματώνοντας τις αρχές SOA, παρέχει υπηρεσίες στα επικοινωνούντα συστήματα. Επίπεδο ενδιάμεσου λογισμικού Με τη χρήση middleware στο δεύτερο επίπεδο, το επίπεδο δικτύου ενσωματωμένων συστημάτων (device-level middleware), αποκρύπτεται η πλεονάζουσα πληροφορία από τα ανώτερα επίπεδα. Το επίπεδο αυτό είναι υπεύθυνο για τη διασύνδεση του επιπέδου συστήματος με το επίπεδο εφαρμογών και μπορεί να αναλυθεί περεταίρω σε δύο υποεπίπεδα. Το πρώτο από αυτά είναι το επίπεδο αφαίρεσης (device abstraction level) το οποίο παρέχει τις απαραίτητες συνιστώσες για την σύγχρονη ή ασύγχρονη κλήση WS επιπέδου συστήματος και για τη διασύνδεση σε εναλλακτικά πρωτόκολλα υπηρεσιών. Το δεύτερο υποεπίπεδο είναι το επίπεδο διαχείρισης συστήματος (management system level) το οποίο περιλαμβάνει συστήματα ελέγχου που είναι υπεύθυνα για τη διαχείριση σύγχρονης ή [53]

54 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα ασύγχρονης κλήσης υπηρεσιών που παρέχουν τα συστήματα με εκπομπή μηνυμάτων. Επιπλέον, αναλαμβάνει την αποθήκευση δεδομένων που αφορούν στις παρεχόμενες υπηρεσίες (service repository) δημιουργώντας έτσι έναν τοπικό κατάλογο υπηρεσιών (service directory), έτσι ώστε να καθίσταται δυνατή η αναγνώριση των απαιτήσεων μιας WS και των δυνατοτήτων της. Τέλος, έχει τη δυνατότητα να αναγνωρίζει την τρέχουσα κατάσταση του δικτύου και να ενεργεί αναλόγως, ξεκινώντας, σταματώντας, επαναφέροντας ή αντικαθιστώντας υπηρεσίες. Επίπεδο πλατφόρμας εφαρμογών συστημάτων Ένα επίπεδο πιο πάνω, στο επίπεδο της πλατφόρμας εφαρμογών των συστημάτων (device-level application platform), γίνεται χρήση των υπηρεσιών που παρέχονται από το ενδιάμεσο λογισμικό. Πρόκειται για ένα ανοιχτό πλαίσιο για την ενσωμάτωση ενσύρματων ή ασύρματων δικτύων ενσωματωμένων συστημάτων σε μια δομή που θα υποστηρίζει την επικοινωνία αυτών, μέσω υπηρεσιών, με τη χρήση καθορισμένων WS, για το συνδυασμό της λειτουργικότητας σε επίπεδο εφαρμογής και σε επίπεδο συσκευής. Επίπεδο ενδιάμεσου επιχειρησιακού λογισμικού Το επόμενο επίπεδο, αυτό του ενδιάμεσου επιχειρησιακού λογισμικού (enterprise-level middleware), συνδυάζει τις παρεχόμενες υπηρεσίες του προηγούμενου επιπέδου με τρόπο τέτοιο, ώστε να καλύπτονται όλες οι βασικές απαιτήσεις της αρχιτεκτονικής SOA. Βασική προϋπόθεση είναι η σωστή ακολουθία εκτέλεσης και ο συγχρονισμός των υπηρεσιών, ώστε συνδυαζόμενες να παρέχουν το βέλτιστο αποτέλεσμα, σύμφωνα με τις προδιαγραφές του εκάστοτε προβλήματος. Η ανάπτυξη βασίζεται σε ένα πρακτορικό πλαίσιο (agent-based framework) που δομείται ακολουθώντας τις αρχές σχεδιασμού των WS. Επίπεδο πλατφόρμας επιχειρησιακών εφαρμογών Τέλος, το επίπεδο της πλατφόρμας επιχειρησιακών εφαρμογών (enterprise-level application platform) είναι άρρηκτα συνδεδεμένο με την έννοια των πληροφοριακών συστημάτων διαχείρισης. Στο επίπεδο αυτό, βασικό στόχο αποτελεί η οργάνωση όλων των προηγούμενων επιπέδων σε ένα ενιαίο πλαίσιο ανάπτυξης. Σημαντικότερη απαίτηση στο επίπεδο αυτό, είναι η δημοσιοποίηση του πλαισίου αυτού, η οποία θα παρουσιάζει τον τρόπο με τον οποίο η χρήση μιας ομοιόμορφης υποδομής επικοινωνιών μέσω υπηρεσιών δίνει προοπτικές για την ανάπτυξη ολοκληρωμένων, ευέλικτων και ευπροσάρμοστων τεχνολογικών δομών Μεθοδολογίες ανάπτυξης Έχοντας ως βασικό άξονα την παραπάνω ιεραρχία, η ομάδα του SOCRADES εξασφαλίζει τη δυνατότητα ανάπτυξης νέων μεθοδολογιών, τεχνολογιών και εργαλείων για τη μοντελοποίηση, τη σχεδίαση, την υλοποίηση και τη λειτουργία δικτυακών συστημάτων που απαρτίζονται από έξυπνες ενσωματωμένες συσκευές και προσανατολίζονται σε τέσσερις επιστημονικές περιοχές, οι οποίες δίνονται στη συνέχεια.

55 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Ανάπτυξη Ad-hoc δικτυακής πλατφόρμας υπηρεσιών βάσει SOA. Στην περίπτωση αυτή, στόχος είναι ο προσδιορισμός ενός υπηρεσιοστρεφούς πλαισίου για το επίπεδο συστήματος, όπου θα προσδίδεται νοημοσύνη στο σύστημα μέσω έξυπνων φυσικών πρακτόρων, ενσωματωμένων σε έξυπνες συσκευές. Η βάση γι αυτήν την ιδέα είναι η δημιουργία ενός συνόλου κατανεμημένων, έξυπνων, ανεκτικών σε σφάλματα και επαναχρησιμοποιήσιμων μονάδων, που θα λειτουργούν ως συνεργαζόμενες οντότητες σε ένα δίκτυο. Οι οντότητες αυτές θα έχουν ενεργό δράση και θα αλληλεπιδρούν δυναμικά μεταξύ τους για να πετύχουν συγκεκριμένη λειτουργικότητα μικροσκοπικά, ξεκινώντας από το επίπεδο συστήματος, αλλά και μακροσκοπικά, φτάνοντας έως το επίπεδο επιχειρησιακών εφαρμογών. Τα πλεονεκτήματα που προκύπτουν από αυτήν την προσέγγιση αποτελούν και τα βασικά χαρακτηριστικά της και είναι τα ακόλουθα: Επανασχεδιασμός (Reconfigurability) Η υιοθέτηση SOA και ad-hoc υπηρεσιών διευκολύνει την ανακάλυψη και τη σύνθεση εφαρμογών μέσω επαναδιαμόρφωσης των παραμέτρων και όχι με επαναπρογραμματισμό συστημάτων. Αυτό έχει ως αποτέλεσμα να μην υπάρχει ανάγκη για συγγραφή λογισμικού μεγάλων μονολιθικών συστημάτων, αλλά για απλές μετατροπές σε παραμέτρους των χαλαρά συζευγμένων, ενσωματωμένων μονάδων. Διαλειτουργικότητα (Interoperability) Η χρήση SOA επιτρέπει τη χαλαρή σύζευξη μεταξύ ετερογενών συσκευών με τη χρήση των κατάλληλων interfaces που αποκρύπτουν την περιττή πληροφορία από άλλα επίπεδα. Αυτό διευκολύνει τη σύνθεση και την ανακάλυψη των διαθέσιμων υπηρεσιών στις οποίες απαιτούν πρόσβαση συστήματα που αναπτύσσονται σε διαφορετικές πλατφόρμες και βάσει διαφορετικών δικτυακών τεχνικών. Κάθετη ολοκλήρωση (Vertical integration) Οι SOA που υλοποιούνται με τη χρήση τεχνολογίας WS, στο επίπεδο δικτύωσης του συστήματος, επιτρέπει την υιοθέτηση μιας ενιαίας τεχνολογίας για όλα τα επιχειρησιακά στάδια, από αυτό της σχεδίασης αισθητήρων/ενεργοποιητών, μέχρι εκείνο των επιχειρησιακών εφαρμογών. Επεκτασιμότητα (Scalability) Πρόκειται για μια απαίτηση η οποία συναντάται ευρέως στον τομέα της βιομηχανίας και μπορεί να υποστηριχθεί εξ ολοκλήρου από τις SOA και από τις ad-hoc πλατφόρμες υπηρεσιών. Η ταυτοποίηση μιας καινούριας ενσωματωμένης μονάδας μπορεί να γίνει αδιαφανώς μέσω των αρχιτεκτονικών αυτών χωρίς να υπάρχει η ανάγκη μεταποίησης ολόκληρου του συστήματος. Διάγνωση (Diagnosability) Η τεχνολογία που «κρύβεται» πίσω από τις SOA και η επέκτασή της από το πρόγραμμα SOCRADES, υποστηρίζουν τη διάγνωση και αναγνώριση σφαλμάτων καθώς και την επιδιόρθωσή τους σε πραγματικό χρόνο. [55]

56 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Επαναχρησιμοποίηση (Reusability) Οι SOA βελτιώνουν τις δυνατότητες επαναχρησιμοποίησης πόρων και μονάδων συστήματος που αναλαμβάνουν την παροχή υπηρεσιών. Δεδομένου ότι κάθε τμήμα του καθολικού συστήματος μπορεί να αναγνωριστεί εύκολα και να είναι διαχειρίσιμο σε ένα σύστημα που βασίζεται σε SOA, αυτό σημαίνει ότι τα ίδια πλεονεκτήματα διατηρούνται και για οποιοδήποτε άλλο σύστημα, γεγονός που αυξάνει τη χρηστικότητά, μειώνοντας ταυτόχρονα το κόστος. Προστασία πνευματικής ιδιοκτησίας (Intellectual protection) Με τη χρήση SOA υποδομών αυτό που είναι ορατό στο εξωτερικό περιβάλλον ενός συστήματος είναι τα WS που παρέχει και όχι η ίδια η τεχνολογία που κρύβεται πίσω από αυτά. Αυτό επιτρέπει στα συστήματα να δημοσιεύουν μόνο τη λειτουργικότητά τους και όχι τον τρόπο με τον οποίο είναι δομημένα. Για την επίτευξη όλων των παραπάνω, απαιτείται ο προσδιορισμός και η υλοποίηση μιας βελτιωμένης εκδοχής της υποδομής των SOA σε επίπεδο συστήματος (device-level SOA), η οποία θα βασίζεται σε πρωτόκολλα των WS για συσκευές (Devices Profile for Web Services DPWS). Αυτό θα οδηγήσει στην ανάπτυξη νοημοσύνης και δεξιοτήτων υπό μορφή WS και στη γενικότερη διαμόρφωση ενός συντονισμένου περιβάλλοντος διαχείρισης των WS που παρέχουν τα χαμηλού επιπέδου συστήματα. Επιπλέον, απαιτείται ο καθορισμός μιας μεθοδολογίας για την περιγραφή των υπηρεσιών μέσω σημασιολογικών δεδομένων (Semantic Web Services), που θα μπορούν να μεταφράζονται και να προσπελαύνονται από έξυπνους πράκτορες λογισμικού για την εύρεση, την επιλογή και τη σύνθεση των κατάλληλων πόρων του συστήματος. Αυτό με τη σειρά του οδηγεί στην ανάγκη σχεδιασμού ενός κατάλληλα διαμορφωμένου πλαισίου για την υποστήριξη φυσικών πρακτορικών συστημάτων με δυνατότητες παροχής υπηρεσιών. Ανάπτυξη υποδομών για ασύρματα δίκτυα αισθητήρων Στην περίπτωση αυτή, στόχος είναι ο προσδιορισμός νέων πρωτοκόλλων επικοινωνίας σε ασύρματα δίκτυα, που θα παρέχουν την απαιτούμενη αξιοπιστία και ασφάλεια και θα παραμετροποιούν έτσι τα ενσωματωμένα συστήματα, ώστε να λειτουργούν σε πραγματικό χρόνο. Ένα δίκτυο αισθητήρων/ενεργοποιητών είναι ένα δίκτυο από ομότιμους συμμετέχοντες κόμβους χωρίς την ύπαρξη κάποιου κεντρικού ελέγχου, μέσα στο οποίο τα όργανα αυτά αλληλεπιδρούν άμεσα μεταξύ τους με στόχο να λύνουν καθημερινά προβλήματα που απαιτούν ένα βαθμό αυτοματοποίησης. Παρόλο που στη θεωρία αυτό δε θεωρείται επιτακτική ανάγκη, ένα ενσύρματο δίκτυο θα ήταν εκτός πρακτικής σημασίας δεδομένου του αριθμού των κόμβων του, καθώς η διασύνδεση θα καθιστούσε την επικοινωνία αργή και αναξιόπιστη. Η υιοθέτηση ασύρματων δικτύων στον τομέα της βιομηχανίας εξαλείφει τα προβλήματα αυτά, καθώς επιτρέπει τη διασύνδεση μεγάλου αριθμού κόμβων στο ίδιο δίκτυο, χωρίς να επηρεάζεται η απόδοσή του. Τα πλεονεκτήματα που προκύπτουν από αυτήν την προσέγγιση αποτελούν και τα βασικά χαρακτηριστικά της είναι τα ακόλουθα: Δυνατότητα επανασχεδιασμού (Reconfigurability) Οι ασύρματες τεχνολογίες μπορούν αδιαμφισβήτητα να διευκολύνουν την ανάπτυξη και την παραμετροποίηση των δικτύων, μειώνοντας την ανάγκη για νέες εγκαταστάσεις και εκ νέου

57 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 καλωδίωση. Ως συνέπεια, εξοικονομείται χρόνος ενώ αυξάνονται αισθητά οι δυνατότητες για επιδόσεις πραγματικού χρόνου. Φορητότητα (Mobility) Η υιοθέτηση ασύρματων τεχνολογιών στα δίκτυα αισθητήρων/ενεργοποιητών υποστηρίζει δυναμικά τη φορητότητα εξοπλισμού. Συντηρησιμότητα (Maintainability) Η ενσωμάτωση μεγάλου αριθμού συσκευών στο ίδιο δίκτυο αυξάνει τα επίπεδα αφαίρεσης, με αποτέλεσμα η διαχείριση της πληροφορίας να κατανέμεται περισσότερο. Ο έλεγχος για την εμφάνιση σφαλμάτων καθώς και η επιδιόρθωση αυτών γίνεται ευκολότερα και ταχύτερα όταν αφορά σε συστήματα που διατηρούν χαμηλά τα επίπεδα εξάρτησης από άλλα. Αποδοτικότητα κόστους (Cost Efficiency) Η εξάλειψη της ανάγκης για εγκατάσταση και συντήρηση καλωδιώσεων μειώνει αισθητά το γενικότερο κόστος του συστήματος που πηγάζει από την αγορά υλικών, την κατανάλωση χρόνου για εγκατάσταση, μεταφορά και συντήρηση. Διαλειτουργικότητα (Interoperability) Φυσική συνέπεια των ασύρματων αρχιτεκτονικών είναι η αυξημένη και βελτιωμένη διαλειτουργικότητα, εφόσον επιτρέπεται η απρόσκοπτη χρήση ετερογενών συστημάτων ενοποιημένων σε ένα ευρύτερο πλαίσιο. Υποστήριξη νέων εφαρμογών Λαμβάνοντας υπ όψιν όλα τα παραπάνω χαρακτηριστικά, το γενικότερο συμπέρασμα που προκύπτει είναι ότι καθίσταται εφικτή η ανάπτυξη καινούριων εφαρμογών που συμβαδίζουν με τα νέα τεχνολογικά πρότυπα. Για την επίτευξη όλων των παραπάνω, απαιτείται ο προσδιορισμός του middleware που θα είναι υπεύθυνο να ενοποιήσει όλους τους διαφορετικούς μηχανισμούς σε ένα ενιαίο πλαίσιο, ώστε να παρέχεται η κατάλληλη ποιότητα υπηρεσιών (QoS). Επιπλέον, είναι αναγκαία η έρευνα σχετικά με τοπολογίες και αρχιτεκτονικές ασύρματων δικτύων καθώς και με μεθοδολογίες που θα επιτρέπουν την αυτονομία σε επίπεδο κατανάλωσης ενέργειας, διαχείρισης, παραμετροποίησης, δρομολόγησης και επικοινωνίας. Τέλος, παρουσιάζεται η ανάγκη για ανάπτυξη νέων υπηρεσιών για την υποστήριξη τέτοιων δικτύων, μετά από συγχώνευση στα καθιερωμένα μοντέλα του DPWS Πρωτόκολλο WS για συσκευές - Device Protocol for Web Services (DPWS ) Βασισμένο στα πρωτόκολλα που διέπουν τις αρχές ανάπτυξης υπηρεσιοστρεφών αρχιτεκτονικών, είναι και το πρωτόκολλο των WS σε επίπεδο hardware. Περιλαμβάνει ένα σύνολο από στοίβες οι οποίες αναφέρονται τόσο στην επικοινωνία συσκευής με συσκευή (device-to-device) όσο και στην επικοινωνία μεταξύ συσκευής με συστήματα λογισμικού (device-to-workstation) μέσω WS. Πρόκειται για ένα πρωτόκολλο που είναι απόλυτα συνυφασμένο με την υπηρεσιοστρεφή αρχιτεκτονική. Υποστηρίζει την εκτέλεση WS στο επίπεδο συσκευής, στο οποίο οι υπολογιστικές ή δικτυακές ικανότητες είναι τις περισσότερες φορές αρκετά περιορισμένες και προσφέρει πολλά πλεονεκτήματα στη διαδικασία ανάπτυξης: [57]

58 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Ενοποιεί καθιερωμένα πρωτόκολλα υπηρεσιών με τέτοιο τρόπο ώστε να παρέχει επικοινωνία μιας συγκεκριμένης στοίβας με συστήματα και άλλες WS. Επιτρέπει την συνεχή ενσωμάτωση δικτυακών συστημάτων. Συνδυάζει την εμπειρία, τη γνώση και τα εργαλεία που διαθέτει ένας προγραμματιστής. Οι προδιαγραφές του DPWS ορίζουν μια αρχιτεκτονική η οποία διαχωρίζει τις υπηρεσίες σε δύο κατηγορίες: devices ή hosting services και hosted services. Η πρώτη κατηγορία παίζει πολύ σημαντικό ρόλο στις διαδικασίες ανίχνευσης (discovery) υπηρεσιών και ανταλλαγής πληροφοριών και μεταδεδομένων (metadata). Η δεύτερη κατηγορία περιλαμβάνει WS προσανατολισμένες σε συγκεκριμένες εφαρμογές, οι οποίες παρέχουν τη λειτουργική συμπεριφορά του εκάστοτε συστήματος που τις γνωστοποιεί στο δίκτυο. Το DPWS υποστηρίζει επίσης ένα σύνολο ολοκληρωμένων υπηρεσιών: Discovery Services (WS-Discovery) Χρησιμοποιούνται από εκείνα τα συστήματα που είναι συνδεδεμένα σε δίκτυο και δημοσιοποιούν την ύπαρξή τους και από εκείνα που έχουν το ρόλο του client και αναζητούν υπηρεσίες. Metadata Exchange Services (WS-Transfer) Χρησιμοποιούνται από clients για την ανάκτηση πληροφορίας που αφορά σε κάποιο σύστημα συμπεριλαμβανομένων των hosted services του συστήματος αυτού και των δεδομένων που ανταλλάσσει μέσω του δικτύου. Events Publish/Subscribe Services (WS-Eventing) Συνδυάζουν υπηρεσίες που καθορίζονται από μια εφαρμογή με προϋπάρχουσες υπηρεσίες, δημιουργώντας ένα εκτεταμένο μοντέλο, που επιτρέπει στους clients να «ακούν» μηνύματα που εκπέμπονται ασύγχρονα από υπηρεσίες άλλων εφαρμογών και να διαχειρίζονται ανάλογα το περιεχόμενο των μηνυμάτων αυτών. Ο ρόλος του DPWS είναι ουσιαστικά να επιτρέψει στους providers των WS να επικεντρωθούν στον ορισμό των WS και την υλοποίηση της λειτουργικότητάς τους, χωρίς να εμπλέκονται με θέματα που αφορούν στην επικοινωνία και την μετάδοση πληροφορίας. Επιπλέον, εξασφαλίζει ότι οι clients έχουν τη δυνατότητα να βρίσκουν εύκολα και γρήγορα τις WS που αφορούν στο σύστημά τους, χωρίς να εμπλέκονται με θέματα που αφορούν ανώτερα επίπεδα. Για να επιτευχθούν αυτοί οι στόχοι, ορίστηκαν τέσσερα διαφορετικά σενάρια, τα οποία καλύπτουν σαφώς τη διαδικασία ανάπτυξης (20) (21). Ανάπτυξη συστήματος και υπηρεσιών (Services and Device Development) Περιγραφή της διαδικασίας ανάπτυξης αυτόνομων συστημάτων που θα παρέχουν μόνο υπηρεσίες της κατηγορίας hosted services. Οι προδιαγραφές σχεδίασης των hosted services ακολουθούν τα πρότυπα σχεδιασμού των WS, όπως αυτά αναλύθηκαν σε προηγούμενο υποκεφάλαιο. Επιπλέον, περιλαμβάνει λειτουργίες διαμόρφωσης του συστήματος αξιοποιώντας πληροφορίες μετα-δεδομένων και μηχανισμούς plug-and-play. Τα βήματα που ακολουθούνται σε αυτή τη διαδικασία φαίνονται στο Σχήμα 3.3.

59 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Σχήμα 3.3: Διαδικασία ανάπτυξης υπηρεσιών συστήματος Τα βήματα 1 4 και 6 απαιτούνται κατά την ανάπτυξη οποιασδήποτε τεχνολογίας που κάνει χρήση των WS. Αντίθετα, τα βήματα 5 και 7 είναι προσανατολισμένα στη σχεδίαση WS που αναφέρονται στο επίπεδο του συστήματος. Αυτό σημαίνει ότι μετά την υλοποίηση των WS, το επόμενο βήμα απαιτεί την ανάπτυξη αυτών των υπηρεσιών και τη σύνδεσή τους με τα στοιχεία του συστήματος. Στη συνέχεια, απαραίτητη είναι η ρύθμιση των στοιχείων αυτών βάσει των κατάλληλων μετα-δεδομένων, ώστε να υποστηρίζονται τα πρωτόκολλα εύρεσης και ανταλλαγής πληροφορίας. Ανάπτυξη client (Pure Client Development) Περιγραφή της διαδικασίας ανάπτυξης εφαρμογών που θα αναλαμβάνουν το ρόλο του client στις προαναφερθείσες υπηρεσίες, ενώ θα «τρέχουν» σε αυτόνομα υπολογιστικά συστήματα. Η διαδικασία αυτή είναι πολύ πιο απλή από την προηγούμενη. Ξεκινάει από ένα αρχείο WSDL το οποίο περιγράφει την καλούμενη υπηρεσία. Πρόκειται για μια διαδικασία παρόμοια με τη διαδικασία ανάπτυξης client για τις καθιερωμένες μορφές WS, η οποία όμως έχει υποστεί κάποιες προσθήκες που αφορούν σε μηχανισμούς αναζήτησης και εύρεσης. Τα βήματα που ακολουθούνται φαίνονται στο Σχήμα 3.4. Σχήμα 3.4: Διαδικασία ανάπτυξης pure client Ανάπτυξη ομότιμων clients (Peer-to-peer Client Development) Περιγραφή της διαδικασίας ανάπτυξης συστημάτων που θα συμπεριφέρονται τόσο ως clients όσο και ως providers υπηρεσιών. Στο σενάριο αυτό υλοποιείται ουσιαστικά μια ολοκληρωμένη αρχιτεκτονική προσανατολισμένη στις υπηρεσίες που προσφέρουν τα συστήματα τα οποία συμπεριφέρονται ως ομότιμοι κόμβοι εντός του δικτύου. Η διαδικασία που ακολουθείται περιλαμβάνει ένα σύνολο από βήματα τα οποία είναι σχεδόν τα ίδια με εκείνα που ορίστηκαν στο πρώτο σενάριο, με τις εξής διαφορές: [59]

60 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Στη φάση παραγωγής κώδικα περιλαμβάνεται επιπλέον και η παραγωγή απομακρυσμένων τμημάτων (remote service stubs) υπηρεσιών. Επίσης, η υλοποίηση των WS απαιτεί την ενσωμάτωση αυτών των τμημάτων στη λειτουργικότητα της WS. Τέλος, όσον αφορά το στάδιο μεταγλώττισης και σύνδεσης, οι κώδικες που έχουν παραχθεί από την μεριά του provider και από τη μεριά του client πρέπει να συνδυασθούν. Η ακολουθία των βημάτων φαίνεται στο Σχήμα 3.5. Σχήμα 3.5: Διαδικασία ανάπτυξης ομότιμων clients Ανάπτυξη ασύγχρονων clients (Asynchronous and Eventing Client Development) Ανάπτυξη συγκεκριμένων περιπτώσεων στις οποίες κάποιος client δομεί μια δική του αρχιτεκτονική εξυπηρετητή για να λαμβάνει ασύγχρονα μηνύματα από providers. Σε αυτήν την περίπτωση προστίθενται καινούρια βήματα ενώ άλλα επεκτείνονται ώστε να υποστηρίζουν την επιπλέον λειτουργικότητα που απαιτείται. Οι handlers παράγονται προκειμένου να υλοποιήσουν μηχανισμούς αποστολής έτσι ώστε να εξυπηρετούνται ασύγχρονες ανταλλαγές μηνυμάτων, ενώ η ασύγχρονη λήψη μηνυμάτων απαιτεί μηχανισμούς server. Αξίζει να σημειωθεί ότι στην περίπτωση που ο client είναι επίσης μια συσκευή ή ένα σύστημα, τότε η διαδικασία που ακολουθείται περιλαμβάνει και τα βήματα του πρώτου σεναρίου, συνθέτοντας ένα επεκταμένο μοντέλο peer-to-peer. Η ακολουθία των βημάτων φαίνεται στο Σχήμα 3.6.

61 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Σχήμα 3.6: Διαδικασία ανάπτυξης ασύγχρονων clients Το SOCRADES είναι ένα middleware στο οποίο έχει γίνει εκτενής χρήση τόσο των πρωτοκόλλων DPWS σε επίπεδο hardware όσο και των πρωτοκόλλων WS σε επίπεδο επιχειρησιακών εφαρμογών. Συνίσταται από ένα σύνολο επιμέρους υποσυστημάτων τα οποία είναι υπεύθυνα για την αποθήκευση, τη διαχείριση και την επεξεργασία δεδομένων καθώς και για την αξιοποίηση της παραγόμενης πληροφορίας από συνεργαζόμενα πληροφοριακά συστήματα. Η αρχιτεκτονική που ακολουθείται φαίνεται στο Σχήμα 3.8. Σχήμα 3.7: Αρχιτεκτονική SOCRADES [61]

62 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σχήμα 3.8: Λεπτομερής αρχιτεκτονική SOCRADES Συμπερασματικά, τo πρωτόκολλο DPWS λειτουργεί ως μηχανισμός ανίχνευσης και εντοπισμού μιας συσκευής και της λειτουργικότητας που αυτή προσφέρει, μέσω WS, και ταυτόχρονα υποστηρίζει την ανταλλαγή πληροφορίας μεταξύ συσκευών που ανήκουν στο ίδιο δίκτυο με τη μορφή WS. Καινούριες συσκευές μπορούν να εισαχθούν δυναμικά στο υπάρχον δίκτυο ακολουθώντας τις διαδικασίες που αυτό ορίζει. Με τον τρόπο αυτό το DPWS λειτουργεί ως συνδετικός κρίκος μεταξύ των ενσωματωμένων συστημάτων και των βασισμένων σε SOA ανώτερων εφαρμογών (22). Σύμφωνα με την αρχιτεκτονική αυτή, μπορούμε να θεωρήσουμε ότι στο επίπεδο συσκευής (device layer) αντιστοιχεί κάποιο RFID σύστημα. Σε κάθε οντότητα του συστήματος αυτού αντιστοιχούν κάποιες ιδιότητες (σειριακός αριθμός, όνομα, μοντέλο, κατασκευαστής κλπ) με τρόπο τέτοιο ώστε να ακολουθεί τους κανόνες και τα πρωτόκολλα σχεδίασης που αναφέρθηκαν στην ενότητα 2.6. Οι ιδιότητες αυτές εκτίθενται στο δίκτυο ως WS και μπορούν να αλληλεπιδράσουν με οποιαδήποτε SOA εφαρμογή.

63 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος Υπηρεσιοστρεφείς Αρχιτεκτονικές Ενσωματωμένων Συστημάτων Προσέγγιση FOSSTRAK Αρχιτεκτονική EPC Network Μια εναλλακτική προσέγγιση, περισσότερο προσανατολισμένη στην τεχνολογία των RFID συστημάτων, είναι αυτή που ακολουθείται από το Fosstrak (23), μια open-source πλατφόρμα λογισμικού η οποία υλοποιεί τις προδιαγραφές της αρχιτεκτονικής του EPC (Electronic Product Code) Network που θεσπίστηκαν από το ινστιτούτο AUTO-ID Labs 2. Η αρχιτεκτονική του EPC Network υιοθετήθηκε από τoν διεθνή οργανισμό EPCglobal 3, ο οποίος έχει συσταθεί για την τυποποίηση, σε παγκόσμιο επίπεδο, των κανόνων που ακολουθούνται στην τεχνολογία EPC. Έχει αναπτύξει ελεύθερα και καθολικά πρότυπα τα οποία ρυθμίζουν την αλληλεπίδραση μεταξύ όλων των οντοτήτων που ανήκουν σε αυτό το τεχνολογικό πεδίο. Σύμφωνα με αυτά, κάθε οντότητα (αντικείμενο) τυποποιείται μοναδικά βάσει ενός Ηλεκτρονικού Κωδικού Προϊόντος (EPC), έχει τη δυνατότητα διασύνδεσης με άλλες οντότητες καθώς και με πληροφοριακά RFID συστήματα, δομώντας με αυτόν τον τρόπο ένα δίκτυο. Η διαχείριση της μετάδοσης και της αποθήκευσης της πληροφορίας δια μέσου αυτού του δικτύου γίνεται με βάση την αρχιτεκτονική που ορίζει το EPCglobal, η οποία φαίνεται στο Σχήμα 3.9 και στο Σχήμα 3.10 (24) (25) (26). Σχήμα 3.9: Στοίβα πρωτοκόλλων του EPCglobal [63]

64 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σχήμα 3.10: Αρχιτεκτονική EPCglobal

65 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Σύμφωνα με την αρχιτεκτονική αυτή, αναγνωρίζονται τα παρακάτω επίπεδα: Reader Interface: Ορίζει τον έλεγχο και την αποστολή ανεπεξέργαστων δεδομένων από τους readers στο επόμενο επίπεδο. Σε αυτό το επίπεδο ένα event μεταφράζεται ως «Ο reader Α βρήκε τον EPC Χ, τη στιγμή Τ». Filtering and Collection: Συλλέγει και φιλτράρει τα ανεπεξέργαστα δεδομένα που προέρχονται από τους readers σε χρονικά διαστήματα που ορίζονται από το επίπεδο εφαρμογής Filtering and Collection (ALE) Interface: Ορίζει τον έλεγχο και την αποστολή των επεξεργασμένων δεδομένων από το προηγούμενο επίπεδο στο επίπεδο εφαρμογής. Εδώ, ένα event μεταφράζεται ως «Στην τοποθεσία Λ, μεταξύ των χρονικών στιγμών Τ1 και Τ2, αναγνωρίστηκαν οι ακόλουθοι EPCs». Η λίστα των EPCs δεν περιέχει διπλές καταχωρήσεις και δομείται βάσει των προδιαγραφών που ορίζονται από το επίπεδο εφαρμογής. EPCIS Capturing Application: Έχει την εποπτεία της λειτουργικότητας των κατώτερων επιπέδων και εισάγει μια ανώτερου επιπέδου λογική, συνεργαζόμενο με επιχειρησιακές διαδικασίες και εφαρμογές. Το επίπεδο αυτό μπορεί να γίνει αρκετά περίπλοκο συσχετίζοντας και συνδυάζοντας ένα ή περισσότερα διαφορετικά events με μία ή περισσότερες εφαρμογές. EPCIS Capture Interface: Πρόκειται για το interface μέσω του οποίου τα EPC δεδομένα προωθούνται στο επίπεδο επιχειρησιακής λογικής. Τα events σε αυτό το επίπεδο μεταφράζονται ως «Στην τοποθεσία Λ, τη στιγμή Τ, τα αντικείμενα Χ1, Χ2,,Χn αναγνωρίστηκαν βάσει της Ψ ιδιότητάς τους» EPCIS Repository: Καταγράφει όλα τα events που προέρχονται από μία ή περισσότερες EPCIS εφαρμογές καθιστώντας ταυτόχρονα δυνατή την προσπέλασή τους από τις εφαρμογές που έχουν πρόσβαση στο EPC σύστημα. EPCIS Accessing Application: Καθορίζει και πραγματοποιεί ολόκληρες τις επιχειρησιακές διαδικασίες, όπως είναι για παράδειγμα η διαχείριση αποθηκών, εφοδιαστικής αλυσίδας, η αποστολή και η λήψη προϊόντων κλπ, με την αξιοποίηση των EPC δεδομένων των κατώτερων επιπέδων. Η αρχιτεκτονική του EPCglobal παρέχει μια μέθοδο για την ενσωμάτωση των εμπορικών προϊόντων μέσα σε ένα δίκτυο υπηρεσιών πληροφόρησης, κάνοντας πολλές αξιωματικές παραδοχές, με σκοπό να αξιοποιηθούν όσο το δυνατόν καλύτερα οι υπάρχουσες τεχνολογίες των διαδικτυακών υποδομών. Για το σκοπό αυτό, υιοθετεί το «μοντέλο κλεψύδρας» [Willinger & Doyle] του διαδικτύου προδιαγράφοντας έτσι το σχήμα αναγνωριστικών (Identifier Schema) του EPC. Στη συνέχεια εξετάζονται αναλυτικότερα τα επίπεδα της αρχιτεκτονικής που έχει ορίσει το EPCglobal και οι προδιαγραφές που έχουν ορισθεί σε κάθε ένα από αυτά. [65]

66 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Object Name Service - ONS Προκειμένου να γίνει η μέγιστη δυνατή αξιοποίηση των διαδικτυακών συστημάτων και τεχνολογιών, ο EPC είναι κωδικοποιημένος ως URI, χρησιμοποιώντας έτσι το βασικό σχήμα διευθυνσιοδότησης του Παγκόσμιου Ιστού. Παρά το γεγονός ότι το σχήμα αυτό είναι χρήσιμο, δεν μπορεί να χρησιμοποιηθεί από μόνο του εντός ενός δικτύου, παρά μόνο όταν παρέχεται ένας απαραίτητος μηχανισμός εξουσιοδότησης ο οποίος επιτρέπει την διερεύνηση πληροφορίας που είναι σχετική με το συγκεκριμένο αναγνωριστικό. Το ρόλο αυτού του μηχανισμού αναλαμβάνει το επίπεδο ONS, που καθίσταται υπεύθυνο να αναγνωρίζει την τοποθεσία ενός server στον οποίο φιλοξενούνται οι πληροφορίες που είναι απαραίτητες για μια εφαρμογή. Συμπεριφέρεται ως ένας «αντίστροφος τηλεφωνικός κατάλογος» καθώς κάνει χρήση ενός αριθμού (EPC αριθμός) για να κάνει ανάκληση της τοποθεσίας μέσα από τη βάση δεδομένων του. Παραμένοντας στη θεώρηση ότι η αρχιτεκτονική του EPC δικτύου πρέπει να αξιοποιεί κατάλληλα τις υπάρχουσες υποδομές του διαδικτύου, το επίπεδο ONS χρησιμοποιεί το DNS πρωτόκολλο για να αντλεί EPC πληροφορίες. Για να επιτευχθεί αυτό, ο EPC ενός αντικειμένου πρέπει να μετατραπεί στη μορφή domain-name που θα είναι κατανοητή από το DNS (χρήση της διαχωριστικής τελείας από αριστερά προς τα δεξιά), ενώ τα αποτελέσματα που επιστρέφονται πρέπει να προέρχονται από έγκυρους καταγεγραμμένους πόρους. Όλη η διαδικασία απαιτεί την απόδοση του EPC σε απόλυτο URI αναγνωριστικό, όπως αυτό ορίζεται από το EPCglobal (π.χ. urn:epc:id:sgtin: ). Με αυτόν τον τρόπο η μορφή του αιτήματος και της απάντησης ακολουθούν πλήρως τις DNS προδιαγραφές. Από την πλευρά του αιτούντος το σύστημα αντιμετωπίζεται ως μαύρο κουτί, χωρίς να απαιτείται γνώση της DNS υποδομής, ενώ τα βασικά στοιχεία που χρησιμοποιούνται είναι τρία: το όνομα του παρόχου στον οποίο υποβάλλεται το ερώτημα, το domain-name υπό μορφή ερωτήματος και ο τύπος της εγγραφής που ζητείται. Η διαδικασία υποβολής ONS ερωτήματος παρουσιάζεται στον Πίνακας 3.1. Ένα από τα σημαντικότερα θέματα που έχει να αντιμετωπίσει μια εφαρμογή είναι η επιλογή του σωστού URL, μέσα από τη λίστα των URLs που αντιστοιχούν σε έναν συγκεκριμένο EPC και επιστρέφεται από το ONS server. Η δομή που έχει η λίστα αυτή καθορίζεται από το NAPTR (Naming Authority PoinTeR), μια συλλογή πληροφοριών ικανή να δείχνει στη σωστή τοποθεσία στον Παγκόσμιο Ιστό όταν παρέχεται μόνο ένα URL. Η δομή αυτή έχει τη μορφή [Order][Pref][Flags][Service][Regexp][Replacement] Το URL βρίσκεται στη θέση [Regexp] ενώ τα [Order], [Pref] και [Flags] χρησιμοποιούνται για να υποδηλώσουν την σειρά προτίμησης εντός της λίστας. Το [Service] χρησιμοποιείται για να καθορίσει τον τύπο της υπηρεσίας που προσφέρεται, όπως για παράδειγμα HTML ή PML (Physical Mark-up Language) ενώ το [Replacement] είναι δεσμευμένο για μελλοντική χρήση.

67 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος Περιγραφή λειτουργίας Ένας σειριακός αριθμός από bits υποδηλώνει ότι ένας EPC έχει διαβαστεί από μια RFID ετικέτα 64 (ή 96) bit Ο reader αποστέλλει τον EPC με την ίδια μορφή στον τοπικό server Πίνακας 3.1: Διαδικασία υποβολής ONS ερωτήματος Δεδομένα που μεταδίδονται Δυαδικός αριθμός: Δυαδικός αριθμός: Ο EPC μετατρέπεται στον server σε URI (μετατροπή δυαδικού σε ακέραιο) urn:epc: Το URI μετατρέπεται σε domain-name στον τοπικό resolver (υποβολή DNS ερωτήματος) 4 - Αφαίρεση του urn:epc Αφαίρεση του σειριακού EPC Αντιστροφή Προσθήκη πηγής onsroot.org Το DNS επιστρέφει μια σειρά από 5 απαντήσεις οι οποίες περιέχουν τα URL τα οποία δείχνουν σε μία ή περισσότερες αντίστοιχες υπηρεσίες 6 Επιλέγεται και εξάγεται το σωστό URL 7 Ο server αποστέλλει το ερώτημα στο URL Σχήμα 3.11: Διαδικασία υποβολής ONS ερωτήματος [67]

68 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα EPC Information Service - EPCIS Η διαδικασία που περιγράφηκε παραπάνω αποτελεί το κλειδί για την ανάκτηση πληροφοριών που αφορούν κάποιο αντικείμενο που διαθέτει RFID tag, έτσι ώστε να μειώνεται η ποσότητα μνήμης που απαιτείται από τα tags. Η πληροφορίες που ανακτώνται βρίσκονται σε μια βάση δεδομένων, συνδεδεμένη στο δίκτυο, της οποίας το Interface παίζει κυρίαρχο ρόλο, αφού επιτρέπει σε διαφορετικές εφαρμογές να αξιοποιούν τον EPC. Αυτό τo interface αναλαμβάνει να υλοποιήσει το επίπεδο EPCIS του EPC Network, ώστε να δώσει τη δυνατότητα προσπέλασης σε δεδομένα σχετικά με την EPC τεχνολογία, μέσω ερωτημάτων (capturing and querying), χρησιμοποιώντας ένα σύνολο υπηρεσιακών λειτουργιών και EPC προδιαγραφών που συνδυάζονται με τους κατάλληλους μηχανισμούς ασφάλειας. Οι υπάρχουσες βάσεις δεδομένων τρέχουν σε διαφορετικές πλατφόρμες, χρησιμοποιώντας διαφορετικά προγράμματα τα οποία έχουν υλοποιηθεί σε διαφορετικές γλώσσες προγραμματισμού. Αυτό καθιστά αναγκαία την ανάπτυξη μιας δομής στην οποία θα απευθύνονται όλοι οι εμπλεκόμενοι κόμβοι του δικτύου ακολουθώντας τους ίδιους κανόνες επικοινωνίας. Επομένως, χρειάζεται ένας μεταφραστής που θα επιτρέπει τέτοιου είδους επικοινωνίες και αυτός βρίσκεται στο επίπεδο του EPCIS. Το EPCIS παράγει PML κώδικα προκειμένου να επιτρέψει στις τοπικές εφαρμογές να έρθουν σε επικοινωνία με εφαρμογές και συστήματα εκτός τοπικού δικτύου, μέσω του πρωτοκόλλου SOAP, το οποίο αναφέρθηκε εκτενώς στην ενότητα 2.4. Πιο συγκεκριμένα, οι αρμοδιότητες του EPCIS παρουσιάζονται στη συνέχεια με φθίνουσα σειρά: Παρέχει πρόσβαση σε μια αποθήκη όπου συγκεντρώνονται χαμηλού επιπέδου EPC δεδομένα (timestamp, ID reader, EPC value) που παράγονται τη στιγμή που ένας reader ανιχνεύει κάποια ετικέτα, τη στιγμή δηλαδή που υπάρχει κάποιο συμβάν (event). Παρέχει πρόσβαση σε υψηλότερου επιπέδου δεδομένα που αναφέρονται σε κάποια συγκεκριμένη χρονική στιγμή, τα οποία προέρχονται ως ένα βαθμό από χαμηλότερου επιπέδου δεδομένα συνδυαζόμενα με επιπλέον πληροφορία. Επιτρέπει την αποθήκευση χαρακτηριστικών ενός αντικειμένου που καθορίζονται τη στιγμή της δημιουργίας του και μπορεί να μην αποθηκεύονται σε υπάρχοντα πληροφοριακά συστήματα, όπως είναι για παράδειγμα η ημερομηνία παραγωγής ή η ημερομηνία λήξης. Τέλος, παρέχει διαφανή, κατά απαίτηση πρόσβαση σε δεδομένα που αφορούν χαρακτηριστικά ενός αντικειμένου και είναι αποθηκευμένα σε διαφορετικές βάσεις δεδομένων, εξασφαλίζοντας ταυτόχρονα και το συγχρονισμό μεταξύ ετερογενών πληροφοριακών συστημάτων. Το ποικιλόμορφο περιβάλλον μέσα στο οποίο λειτουργεί το EPCIS εισάγει την απαίτηση για αυστηρή κατηγοριοποίηση των προδιαγραφών σε επίπεδα, έτσι ώστε, ανεξάρτητα με τα ετερογενή εξωτερικά συστήματα που συμμετέχουν στο δίκτυο, να διασφαλίζεται η διαλειτουργικότητα και η σταθερότητα

69 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 και να καθίσταται σαφές το νόημα και το περιεχόμενο των δεδομένων που ανταλλάσσονται. Η απαίτηση αυτή ικανοποιείται από ένα σύνολο κανόνων που συνθέτουν το πλαίσιο του EPCIS, σχεδιασμένο ώστε να είναι ιεραρχικό, επεκτάσιμο και τμηματοποιημένο. Όσον αφορά την ιεραρχία των επιπέδων του EPCIS, αυτή φαίνεται στο Σχήμα 3.12 Σχήμα 3.12: Ιεραρχία επιπέδων του πλαισίου EPCIS Abstract Data Model Layer: Το επίπεδο αυτό ορίζει τη γενική δομή που πρέπει να έχουν τα EPCIS δεδομένα και τις απαιτήσεις που πρέπει να ικανοποιούνται για τη δημιουργία ορισμών δεδομένων στο αμέσως ανώτερο επίπεδο. Είναι το μοναδικό επίπεδο το οποίο μπορεί να επεκταθεί μόνο βάσει των προδιαγραφών που ορίζει το ίδιο το EPCIS. Τα περιεχόμενα του επιπέδου αυτού παρουσιάζονται στο Σχήμα 3.13, στο οποίο μπορούμε να δούμε και τη γενική δομή που ακολουθεί ο τρόπος καταγραφής των EPC δεδομένων. [69]

70 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σχήμα 3.13: Περιεχόμενα επιπέδου Abstract Data Model Data Definition Layer: Το επίπεδο αυτό ορίζει τον τύπο των δεδομένων που ανταλλάσσονται μέσω του EPCIS, την αφαιρετική δομή καθώς και τη σημασία που θα έχουν τα δεδομένα αυτά. Πιο συγκεκριμένα, τα στοιχεία που περιέχονται ολοκληρώνουν το συνολικό δομικό πλαίσιο του προηγούμενου επιπέδου. Αξίζει να σημειωθεί ότι στο επίπεδο αυτό παρέχεται η κλάση EPCISEvent η οποία καθορίζει τα βασικά χαρακτηριστικά ενός event (eventtime, recordtime, eventtimezoneoffset) και η υπο-κλάσεις ObjectEvent, QuantityEvent, AggregationEvent και TransactionEvent οι οποίες κληρονομούν την EPCISEvent όπως φαίνεται στο Σχήμα 3.14.

71 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Σχήμα 3.14: Υλοποίηση επιπέδου Abstract Data Model μέσω των κλάσεων του επιπέδου Data Definition Service Layer: Το επίπεδο αυτό ορίζει τα διαφορετικά interfaces (Capture Interface, Query Control Interface, Query Callback Interface) μέσω των οποίων μπορούν να αλληλεπιδρούν οι clients του EPCIS. Τα interfaces αυτά συνηθίζεται να καθορίζονται με αφαιρετικό τρόπο, χρησιμοποιώντας UML διαγράμματα. Επεκτείνοντας το Σχήμα 3.10, το Σχήμα 3.15 παρουσιάζει τη σχέση μεταξύ αυτών των interfaces. Στο επίπεδο αυτό, κάθε service υλοποιεί ένα interface μεταξύ εφαρμογής (client) και EPCIS, μέσω κατάλληλα ορισμένων μεθόδων. Bindings: Οι σύνδεσμοι καθορίζουν τους διακριτούς τρόπους υλοποίησης των προηγούμενων επιπέδων (SOAP και HTTP bindings). Είναι δυνατό να υπάρχουν περισσότεροι από έναν σύνδεσμοι για οποιοδήποτε τμήμα από τα κατώτερα επίπεδα, όλοι όμως κάνουν αναφορά στο βασικό EPCglobal XML σχήμα (EPC Base XSD). [71]

72 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σχήμα 3.15: Υλοποίηση Service Layer Τα EPC δεδομένα που προσπελαύνονται στο επίπεδο EPCIS μπορούν να χωρισθούν σε δύο κατηγορίες: Ιστορικά δεδομένα με σαφή χρονικό προσδιορισμό (timestamped historical data) Τα δεδομένα αυτά μπορεί να εκφράζουν μια αλληλουχία αναγνώσεων RFID tags (tag readings) χαμηλού επιπέδου ή μπορεί να αναφέρονται σε επιχειρησιακές διαδικασίες στις οποίες εμπλέκεται το αντικείμενο, όπως για παράδειγμα εντολές αγορών. Πιο συγκεκριμένα, αναγνωρίζονται τέσσερις υποκατηγορίες, οι οποίες φαίνονται στον Πίνακας 3.2 και στο Σχήμα Πίνακας 3.2: Κατηγορίες ιστορικών δεδομένων Κατηγορία 1 Παρατηρήσεις (observations) 2 Συνδιαλλαγές (transactions) 3 Μετρήσεις (measurements) 4 Συμβολικές τοποθεσίες Λειτουργία - Ποιο αντικείμενο βρέθηκε - Από ποιον reader βρέθηκε - Πότε βρέθηκε - Ποια αντικείμενα έλαβαν μέρος σε μια συγκεκριμένη συνδιαλλαγή - Ποια συνδιαλλαγή σχετίζεται με ένα συγκεκριμένο αντικείμενο - Ιστορικά δεδομένα από αισθητήρες και ετικέτες - Συσχετισμός με τις παρατηρήσεις για εξαγωγή συμπερασμάτων - Πού περιέχεται το αντικείμενο - Πού βρίσκεται το αντικείμενο

73 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Σχήμα 3.16: Κατηγορίες ιστορικών δεδομένων Στατικά χαρακτηριστικά ενός αντικειμένου Τα δεδομένα αυτής της κατηγορίας περιλαμβάνουν μια μεγαλύτερη ποικιλία χαρακτηριστικών τα οποία είναι πολύ πιο συγκεκριμένα όσον αφορά συγκεκριμένους επιχειρηματικούς περιορισμούς. Μια απλή προσέγγιση είναι η δημιουργία ενός πίνακα για να κρατιούνται οι τιμές-κλειδιά των χαρακτηριστικών κάθε EPC, όπως φαίνεται στο Σχήμα Παρ όλα αυτά, μια καλύτερη προσέγγιση είναι η διασφάλιση της διαλειτουργικότητας μεταξύ των εμπορικών εταίρων, εξασφαλίζοντας ότι το κάθε κλειδί θα εκφράζεται μέσω ενός καλά ορισμένου XML σχήματος. Στο παράδειγμα του Σχήμα 3.17 το απλό χαρακτηριστικό «μέγεθος» θα μπορούσε να πάρει διαφορετικές σημασίες ανάλογα με το πλαίσιο εντός του οποίου εξετάζεται. Για να εξαλειφθεί αυτό το πρόβλημα, επιλέγεται το κατάλληλο σχήμα που σχετίζεται με το πλαίσιο μέσα στο οποίο εξετάζεται ένα χαρακτηριστικό για να ορίσει σαφώς σε τι αναφέρεται το χαρακτηριστικό αυτό. Χάρη σε αυτήν την προσέγγιση, το κλειδί για την προσπέλαση μιας συγκεκριμένης ιδιότητας αναφέρεται σε ένα συγκεκριμένο XML σχήμα μέσω ενός URI ενώ στη συνέχεια, αναφέρεται σε ένα συγκεκριμένο στοιχείο ή χαρακτηριστικό μέσα σε αυτό το σχήμα με τη χρήση εκφράσεων (XQL, XPath) που αναγνωρίζουν έναν διακεκριμένο κόμβο μέσα σε αυτό. [73]

74 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σχήμα 3.17: Πίνακας χαρακτηριστικών Επομένως, μιλώντας για ιστορικά δεδομένα, γνωρίζουμε ότι η δομή που ακολουθείται είναι αυτή των καλώς ορισμένων πινάκων, ενώ αναφερόμενοι σε στατικά χαρακτηριστικά, γνωρίζουμε ότι υπάρχει άμεση συσχέτιση με δενδρικές δομές. Για τις δομές πινάκων ο ενδεικνυόμενος τρόπος προσπέλασης των δεδομένων είναι η χρήση σχεσιακών βάσεων δεδομένων, καθώς αυτές επιτρέπουν τη διατύπωση πολλών και διαφορετικών ερωτημάτων. Αντίστοιχα, για τις δενδρικές δομές ο καταλληλότερος τρόπος είναι τα XML εργαλεία, τα οποία προσφέρονται για την απλή αναζήτηση τιμών (κλειδιών). Application Level Interface - ALE Στο αμέσως χαμηλότερο επίπεδο, υπάρχει ένα κατάλληλα διαμορφωμένο πλαίσιο, μέσω του οποίου οι clients μπορούν να αλληλεπιδρούν με τα φιλτραρισμένα EPC δεδομένα που προέρχονται από διάφορες πηγές. Η ύπαρξη αυτού του επιπέδου αντανακλά την απαίτηση των εφαρμογών να προσπελαύνουν δεδομένα τα οποία έχουν υποστεί μια προ-επεξεργασία προκειμένου να μειωθεί η περίσσεια πληροφορίας που προέρχεται απευθείας από το επίπεδο hardware. Αυτό έχει ως συνέπεια να υπάρχει ένα επίπεδο αφαίρεσης σύμφωνα με το οποίο οι εφαρμογές των ανώτερων επιπέδων δε γνωρίζουν τις λεπτομέρειες που αφορούν τα κατώτερα επίπεδα, αυξάνοντας έτσι την αποδοτικότητα, τη χρηστικότητα και την ευελιξία τους. Το interface αυτό, καθώς και η λειτουργικότητα που εισάγει, συνιστούν ολόκληρο το επίπεδο ALE. Έτσι, ο ρόλος του ALE στην EPCglobal αρχιτεκτονική είναι να παρέχει ανεξαρτησία μεταξύ των στοιχείων εκείνων που δέχονται ως είσοδό τους τα προ-επεξεργασίας EPC δεδομένα (π.χ. readers), εκείνων που αναλαμβάνουν τη συλλογή και το φιλτράρισμα των δεδομένων αυτών και των εφαρμογών που τα χρησιμοποιούν για την διεκπεραίωση επιχειρησιακών διεργασιών. Χάρη σε αυτό, οι εφαρμογές των ανώτερων επιπέδων έχουν τη δυνατότητα να επιλέγουν αυτόνομα τη στρατηγική υλοποίησης που θα ακολουθήσουν ώστε να διαχειριστούν τα αιτήματα που δέχονται από το εξωτερικό τους περιβάλλον. Ο client του ALE interface μπορεί να είναι είτε μια ανώτερου επιπέδου επιχειρηματική διαδικασία/εφαρμογή είτε οποιοδήποτε λογισμικό το οποίο έχει σχεδιασθεί προκειμένου να επεξεργάζεται EPC δεδομένα σε ένα επίπεδο ανώτερο του ALE middleware. Τα αιτήματα που

75 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 προέρχονται από κάποιον client μπορούν να είναι είτε άμεσα (immediate) είτε επαναλαμβανόμενα (recurring), ανάλογα με το εάν η πληροφορία παρέχεται μία φορά ή ανά τακτά-προκαθορισμένα χρονικά διαστήματα. Οι βασικές διαφορές που παρουσιάζει αυτό το επίπεδο με τα ανώτερα είναι οι ακόλουθες: Το ALE interface είναι καθαρά προσανατολισμένο σε πραγματικού χρόνου EPC δεδομένα χωρίς να απαιτεί τη συνεχή αποθήκευσή τους. Αντιθέτως, οι εφαρμογές ανώτερων επιπέδων (συμπεριλαμβανομένου του EPCIS) διαχειρίζονται ιστορικά δεδομένα, συνεπώς δεν είναι πραγματικού χρόνου. Τα events που διαχειρίζεται το ALE interface είναι άρρηκτα συνδεδεμένα με τις ερωτήσεις «τι», «πού» και «πότε» χωρίς να εισάγουν κάποιου υψηλότερου επιπέδου λογική, σε αντίθεση με τις ανώτερες εφαρμογές που εισάγουν την έννοια της επιχειρησιακής σημασιολογίας. Το επίπεδο ALE ορίζει συνολικά πέντε διαφορετικούς τύπους interfaces τα οποία δίνονται συνοπτικά στον Πίνακας 3.3. Πίνακας 3.3: Interfaces που παρέχονται από το επίπεδο ALE Interface 1 Reading API 2 Writing API 3 4 Tag Memory Specification API Logical Reader Configuration API 5 Access Control API Λειτουργία Interface μέσω του οποίου οι clients μπορούν να προσπελάσουν χαμηλότερου επιπέδου καταγεγραμμένα και φιλτραρισμένα δεδομένα. Interface μέσω του οποίου οι clients μπορούν να ενεργοποιήσουν κάποια λειτουργία χαμηλότερου επιπέδου. Interface μέσω του οποίου οι clients μπορούν να αποδώσουν συμβολική ονοματολογία σε συγκεκριμένα πεδία δεδομένων των RFID ετικετών. Interface μέσω του οποίου οι clients μπορούν να προσδιορίσουν το όνομα και τα χαρακτηριστικά κάποιου reader τον οποίο θα χρησιμοποιεί το Reading/Writing API. Interface μέσω του οποίου οι clients μπορούν να καθορίζουν τα δικαιώματα πρόσβασης άλλων clients στα εσωτερικά τους interfaces. Κάθε είδους παραμετροποίηση μέσω των προαναφερθέντων interfaces, μπορεί να γίνει με τη χρήση XML αρχείων τα οποία ακολουθούν συγκεκριμένους κανόνες, όπως αυτοί ορίζονται από τα αντίστοιχα XML schemas (XSDs) του EPCglobal. [75]

76 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Discovery Configuration & Initialization - DCI O ρόλος του επιπέδου αυτού είναι να προσδιορίσει τις απαραίτητες αλλά και τις προαιρετικές λειτουργίες ενός reader και ενός client, οι οποίες θα τους επιτρέψουν να αξιοποιήσουν το δίκτυο στο οποίο είναι συνδεδεμένοι, ώστε να επικοινωνούν με άλλες συσκευές. Για να ικανοποιηθούν οι απαιτήσεις αυτές, το επίπεδο DCI πρέπει να παρέχει στους readers τα μέσα ώστε να μπορούν να αναγνωρίσουν, να συνδεθούν και να επικοινωνήσουν με έναν ή περισσότερους ελεγκτές πρόσβασης (access controller) ή clients και αντίστροφα. Τα πρωτόκολλα του DCI υλοποιούνται από κοινού, τόσο στους readers όσο και στους ελεγκτές, επιτρέποντας έτσι στην κάθε οντότητα να αλληλεπιδράσει με την άλλη, μέσα στο πλαίσιο που ορίζει το EPCglobal. Low Level Reader Protocol - LLRP Το πρωτόκολλο του επιπέδου αυτού αναλαμβάνει να δημιουργήσει την κατάλληλη υποδομή για την επικοινωνία μεταξύ ενός reader και ενός client. Τα βασικά δομικά στοιχεία του είναι τα llrp μηνύματα. Τα μηνύματα που προέρχονται από τον client περιέχουν εντολές τύπου get/set και εντολές για τη διαμόρφωση, τον έλεγχο και τη διαχείριση του reader. Πιο συγκεκριμένα, ένα μήνυμα από κάποιον client, μπορεί να περιέχει εντολές προς τον reader για ανίχνευση ετικετών και λήψη των δεδομένων τους, για εγγραφή δεδομένων σε κάποια RW ετικέτα ή εντολές απενεργοποίησης του reader (kill/lock). Αντίστοιχα, τα μηνύματα που προέρχονται από τον reader, περιλαμβάνουν δεδομένα σχετικά με την κατάστασή του και με αποτελέσματα που σχετίζονται με τη λειτουργία ανίχνευσης ετικετών. Επιπλέον, το LLRP πρωτόκολλο παρέχει πρόσβαση στα προ-επεξεργασίας δυαδικά δεδομένα των RFID ετικετών, χωρίς όμως να επιτρέπει τη διαδικασία επανεκπομπής δεδομένων υπό μορφή μηνυμάτων RFID Middleware Έχοντας αποσαφηνίσει τα επίπεδα της EPCglobal αρχιτεκτονικής, μπορούμε πλέον να προδιαγράψουμε τις βασικές αρχές στις οποίες στηρίζεται η σχεδίαση και η υλοποίηση ενός RFID middleware, το οποίο θα παρέχει την αφαιρετική δομή που απαιτείται ώστε να επιτευχθεί η ανεξαρτησία μεταξύ των τμημάτων του συνολικού RFID συστήματος (10). Τα βασικά κριτήρια που πρέπει να ικανοποιεί ένα RFID middleware είναι: Διαχείριση εισερχόμενων δεδομένων σε πραγματικό χρόνο, με ελαχιστοποίηση της απώλειας πληροφορίας Υποστήριξη διαφορετικών τεχνολογιών hardware

77 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Γενικευμένα interfaces, ανεξάρτητα του hardware που χρησιμοποιείται Συγχρονισμό και χρονοπρογραμματισμό των πολλαπλών διεργασιών που εκτελούνται στο επίπεδό του Ικανότητα εξυπηρέτησης πολλαπλών αιτημάτων από διαφορετικές εφαρμογές Επεκτασιμότητα Η βασική προσέγγιση που ακολουθείται κατά το σχεδιασμό ενός RFID middleware είναι αυτή που φαίνεται στο Σχήμα Σύμφωνα με αυτήν, κάθε RFID middleware πρέπει να διαθέτει τρία διακριτά επίπεδα. Το επίπεδο του reader interface είναι υπεύθυνο για τη διαχείριση δεδομένων που προέρχονται από τα κατώτερα επίπεδα hardware. Το επίπεδο επεξεργασίας και αποθήκευσης δεδομένων είναι υπεύθυνο για τη διαχείριση των προ-επεξεργασίας δεδομένων που προέρχονται από τους readers και για την αποθήκευσή τους ώστε να είναι προσπελάσιμα από τις εφαρμογές ανώτερου επιπέδου. Το Interface εφαρμογών είναι υπεύθυνο για τη διαχείριση της διασύνδεσης μεταξύ middleware και εξωτερικών εφαρμογών, καθώς παρέχει τα απαραίτητα μέσα ώστε οι εντολές και τα ερωτήματα ανώτερου επιπέδου να μεταφράζονται σε εντολές που είναι κατανοητές από το middleware. Τέλος, το καθολικό επίπεδο management του middleware είναι υπεύθυνο για τη συνολική διαχείριση του Σχήμα 3.18: Αρχιτεκτονική RFID middleware middleware, καθώς παρέχει πληροφορίες σχετικές με την εκτέλεση διεργασιών σε όλα τα επίπεδα. Επιπλέον, δίνει δυνατότητες στον χρήστη ώστε να διαμορφώνει κατάλληλα το σύστημα προσθέτοντας και αφαιρώντας readers ή μεταβάλλοντας ιδιότητες και παραμέτρους που σχετίζονται με αυτό. 3.4 Ανασκόπηση κεφαλαίου Στο κεφάλαιο αυτό έγινε μια έρευνα σχετικά με τη σχεδίαση και την ανάπτυξη SOA αρχιτεκτονικών για RFID συστήματα. Εξετάσθηκαν δύο βασικές αρχιτεκτονικές προσεγγίσεις, οι οποίες σήμερα αποτελούν τη βάση για πολλά συστήματα λογισμικού που ανήκουν στον τομέα αυτόν. Ωστόσο, η αρχιτεκτονική και οι μεθοδολογίες ανάπτυξης που προτείνονται από το SOCRADES είναι περισσότερο προσανατολισμένες στις ανάγκες που ανακύπτουν κυρίως από ασύρματα δίκτυα αισθητήρων και όχι από RFID συστήματα, όπως συμβαίνει με την αρχιτεκτονική που προτείνεται από το EPC Network. Εν γένει, τα πεδία εφαρμογών των RFID συστημάτων και των ασύρματων δικτύων αισθητήρων διαφέρουν, με αποτέλεσμα να διαφέρει και η αντίστοιχη ερευνητική κατεύθυνση. Δεδομένου ότι για την υλοποίηση του συστήματος της παρούσας διπλωματικής εργασίας θα χρησιμοποιηθούν RFID tags και readers, πρόκειται να υιοθετηθεί η προσέγγιση που ακολουθείται από το EPC Network. Αξίζει παρ όλα αυτά να αναφερθεί ότι οι έρευνες (27) δείχνουν ότι στο μέλλον τα RFID συστήματα και τα δίκτυα ασύρματων αισθητήρων θα συγκλίνουν με έναν τρόπο παρόμοιο με αυτόν που απεικονίζεται στο σχήμα [77]

78 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σχήμα 3.19: Η μελλοντική σύγκλιση των RFID και των WSN

79 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Κεφάλαιο 4 Fosstrak Middleware [79]

80 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα 4.1 Εισαγωγή Στην παρούσα διπλωματική εργασία υιοθετείται η αρχιτεκτονική και τα EPCglobal πρότυπα που ορίζει το EPC Network για τα RFID συστήματα και υλοποιείται με ολοκληρωμένο και επεκτάσιμο τρόπο από το Fosstrak project. Πρόκειται για ένα πλαίσιο λογισμικού το οποίο ενσωματώνει όλα τα επιμέρους επίπεδα ενός RFID συστήματος, από το επίπεδο της συσκευής μέχρι το επίπεδο της τελικής εφαρμογής, ενώ ταυτόχρονα δίνει τη δυνατότητα επέκτασης της υπάρχουσας υποδομής για την ικανοποίηση συγκεκριμένων απαιτήσεων και προδιαγραφών της εκάστοτε εφαρμογής. Στη συνέχεια του κεφαλαίου αυτού γίνεται εκτενής περιγραφή της υποδομής που παρέχει το Fosstrak, των τεχνολογιών στις οποίες αυτό βασίζεται και των απαιτήσεων που εισάγει η χρήση του. 4.2 Δομή Σχήμα 4.1: Επίπεδα αρχιτεκτονικής του Fosstrak Το Fosstrak διαμορφώνεται σε διακριτά τμήματα κάθε ένα από τα οποία ενσωματώνει τις βασικές αρχές και δομικές μονάδες του EPC Network. Τα τμήματα αυτά είναι τα ακόλουθα: Filtering and Collection Middleware with ALE and LLRP support: πρόκειται για το βασικό πυρήνα του Fosstrak, ο οποίος διαχειρίζεται την πληροφορία από/προς το επίπεδο συσκευής και από/προς το επίπεδο εφαρμογής. Ως επιμέρους τμήμα του επιπέδου αυτού μπορούν να θεωρηθούν οι clients που επικοινωνούν με το ALE Middleware και επιτρέπουν την παραμετροποίηση και τη διαχείρισή του.

81 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Capturing Application: πρόκειται για την εφαρμογή εκείνη η οποία είναι υπεύθυνη για τη διαχείριση των events που αποστέλλονται από το ALE middleware και την προώθησή τους βάσει κάποιων κανόνων- στη βάση δεδομένων EPCIS. EPCIS Repository: πρόκειται για τη βάση δεδομένων στην οποία αποθηκεύονται τα events που καταγράφονται από έναν ή περισσότερους RFID readers. LLRP Commander: πρόκειται για το τμήμα εκείνο που υποστηρίζει την αποστολή LLRP (Low Level Reader Protocol) μηνυμάτων από/προς RFID readers. Tag Data Translation (DTD) Library: πρόκειται για το τμήμα εκείνο το οποίο παρέχει τη δυνατότητα μετασχηματισμού ενός EPC από μια μορφή αναπαράστασης σε μια άλλη (π.χ. από δυαδική σε δεκαεξαδική) ανάλογα με τις απαιτήσεις χρήσης Στη συνέχεια δίνεται αναλυτικότερα η περιγραφή των τμημάτων αυτών ως προς τη σχεδίαση, τη λειτουργικότητα, τη διαχείριση και τη χρήση τους Filtering and Collection Middleware with ALE and LLRP support Το επίπεδο αυτό αντιπροσωπεύει το Application Level Interface (ALE) όπως αυτό ορίζεται από τις EPCglobal προδιαγραφές, που παρουσιάστηκαν στην παράγραφο 0. Περιλαμβάνει τρία διακριτά τμήματα, τον server, έναν web client και έναν standalone client. Και οι δύο τύποι client δίνουν τη δυνατότητα παραμετροποίησης του server από την πλευρά του χρήστη, ανάλογα με τις απαιτήσεις και τις προδιαγραφές του συστήματος. Ο server προσφέρει τη λειτουργικότητα του ALE όπως αυτή παρουσιάστηκε στο υποκεφάλαιο Η τρέχουσα έκδοση υποστηρίζει μόνο δύο από τους πέντε τύπους interfaces: το ALE Logical Reader API, το οποίο χρησιμοποιείται για τον ορισμό των αναγνωστών ως οντότητες λογισμικού (λογικοί readers) και το ALE Reading API, το οποίο χρησιμοποιείται για τον καθορισμό της συμπεριφοράς του server ως προς το φιλτράρισμα και τη συλλογή δεδομένων. Η παραμετροποίηση σε αυτό το επίπεδο γίνεται, όπως έχει προαναφερθεί, με τη χρήση XML αρχείων, τα οποία ονομάζονται LRSpecs (Logical Reader Specifications) και ECSpecs (Event Cycle Specifications) αντίστοιχα και δηλώνονται από έναν ή περισσότερους clients. LRSpec: XML αρχείο το οποίο περιλαμβάνει πληροφορία που αφορά τον reader, αντιμετωπίζοντάς τον ως μία οντότητα λογισμικού που διαθέτει συγκεκριμένο όνομα και ιδιότητες και είναι προκαθορισμένου τύπου. ECSpec: XML αρχείο το οποίο περιγράφει τη συμπεριφορά του server, ορίζοντας το μικρότερο χρονικό διάστημα (Event Cycle) κατά το οποίο αυτός θα συλλέγει τα δεδομένα, την πηγή από [81]

82 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα την οποία θα προέρχονται τα δεδομένα αυτά και τη μορφή στην οποία θα μετασχηματίζονται. Στη συνέχεια δίνονται δύο απλά παραδείγματα τέτοιων αρχείων. Στο πρώτο παράδειγμα (Σχήμα 4.2), ορίζεται ένας λογικός reader τύπου MyReader ο οποίος επικοινωνεί μέσω της θύρας 5084 του τοπικού υπολογιστή (localhost) με τον φυσικό reader NewReader. Ως τύπος του λογικού reader ορίζεται η κλάση εκείνη η οποία υλοποιεί το interface μεταξύ επιπέδου συσκευής και ALE (LLRP Adaptor/HAL Adaptor). <?xml version="1.0" encoding="utf-8" standalone="yes"?> <ns3:lrspec xmlns:ns2="urn:epcglobal:ale:wsdl:1" xmlns:ns3="urn:epcglobal:ale:xsd:1"> <iscomposite>false</iscomposite> <readers/> <properties> <property> <name>readertype</name> <value>org.fosstrak.ale.server.readers.llrp.llrpadaptor</value> </property> <property> <name>description</name> <value>llrp reader</value> </property> <property> <name>physicalreadername</name> <value>logicalreader1</value> </property> <property> <name>ip</name> <value>localhost</value> </property> <property> <name>port</name> <value>5084</value> </property> <property> <name>clientinitiated</name> <value>true</value> </property> </properties> </ns3:lrspec> 4.2: Παράδειγμα LRSpec αρχείου Στο δεύτερο παράδειγμα (Σχήμα 4.3), ορίζεται ο κύκλος ανάγνωσης δεδομένων (Event Cycle) για τον reader NewReader στα 10000ms. H έξοδος που δίνεται από το ALE περιλαμβάνει δεδομένα που αφορούν μόνο σε ετικέτες που αναγνώσθηκαν στον τελευταίο κύκλο ανάγνωσης (CURRENT) και ανήκουν σε μια συγκεκριμένη κατηγορία (urn:epc:pat:sgtin-96:x.x.x.*), σε όλες τις δυνατές μορφές (includerawhex, includerawdecimal, includetag, includeepc).

83 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 <?xml version="1.0" encoding="utf-8"?> <ale:ecspec xmlns:ale="urn:epcglobal:ale:xsd:1" xmlns:epcglobal="urn:epcglobal:xsd:1" xmlns:xsi=" schemaversion="1.0" creationdate=" t10:54: :00"> <logicalreaders> <logicalreader>newreader</logicalreader> </logicalreaders> <boundaryspec> <repeatperiod unit="ms">10000</repeatperiod> <duration unit="ms">9500</duration> </boundaryspec> <reportspecs> <reportspec reportname="report1"> <reportset set="current"/> <output includerawhex="true" includerawdecimal="true" includeepc="true" includetag="true"/> <groupspec> <pattern>urn:epc:pat:sgtin-96:x.x.x.*</pattern> </groupspec> </reportspec> </reportspecs> </ale:ecspec> Σχήμα 4.3: Παράδειγμα ECSpec αρχείου Από μια πιο γενική σκοπιά, το Fosstrak ALE μπορεί να χωρισθεί σε τρία επιμέρους επίπεδα, κάθε ένα από τα οποία είναι βασισμένο στο αμέσως προηγούμενό του, όπως δείχνει το σχήμα 4.4 και το σχήμα 4.5. Ο διαχωρισμός αυτός επιτρέπει την απεμπλοκή των τμημάτων που συνιστούν το επίπεδο αυτό, ώστε να είναι πιο σαφής η ανάθεση των λειτουργιών σε κάθε ένα από αυτά. Σχήμα 4.4: Τα επίπεδα του Fossstrak ALE Middleware [83]

84 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σχήμα 4.5: Διάγραμμα τμημάτων του Fosstrak ALE Middleware

85 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 org.fosstrak.ale.server Το επίπεδο αυτό παρέχει τα κατάλληλα interfaces μέσω της κλάσης ALE, μοντελοποιημένα σε γλώσσα WSDL 4, για την επικοινωνία του server μέσω Web Services με τις εφαρμογές που θα υλοποιούν είτε την πλευρά του client είτε τη λογική του Capturing Application. Παρέχει τις κατάλληλες κλάσεις για τον ορισμό των Event Cycles, των Subscribers που θα λαμβάνουν τα δεδομένα που έρχονται από τα χαμηλότερα επίπεδα, καθώς και κλάσεις διαχείρισης των δεδομένων αλλά και ολόκληρου του επιπέδου. Σχήμα 4.6: Μέθοδοι που παρέχονται από το ALE Interface Στη συνέχεια, δίνεται ένα διάγραμμα ακολουθιών που περιγράφει την αλληλουχία των γεγονότων στο επίπεδο αυτό (σχήμα 4.6). Στο διάγραμμα αυτό διακρίνεται, πέρα από τις προαναφερθείσες κλάσεις, και η κλάση ReporsGenerator. Η συγκεκριμένη κλάση διαθέτει τις κατάλληλες μεθόδους ώστε, μετά το τέλος κάθε κύκλου, να δημιουργείται η κατάλληλη αναφορά (Event Cycle Report) που θα περιέχει όλη την πληροφορία σχετικά με τα events που έχουν καταγραφεί στη διάρκεια του κύκλου αυτού. Η αναφορά αυτή αποστέλλεται στη συνέχεια στο ανώτερο επίπεδο προς επεξεργασία. Στην περίπτωση που δεν έχει καταγραφεί κανένα γεγονός στη διάρκεια κάποιου κύκλου, τότε οι αναφορές που αποστέλλονται είναι κενές. Το διάγραμμα ακολουθιών του σχήματος 4.7 εστιάζει περισσότερο στη δημιουργία και την ενημέρωση των subscribers μέσω των μεθόδων που παρέχονται από το interface του ALE. Έτσι, κατά την κλήση της αντίστοιχης μεθόδου από το ALE, ακολουθεί η δημιουργία ενός ή περισσοτέρων subscribers οι οποίοι ενημερώνονται για την ολοκλήρωση κάθε κύκλου και δέχονται τις αντίστοιχες αναφορές. 4 [85]

86 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σχήμα 4.7: Διάγραμμα ακολουθιών Fosstrak ALE Middleware κατά τον ορισμό και την ενεργοποίηση του Event Cycle και του subscriber Σχήμα 4.8: Διάγραμμα ακολουθιών Fosstrak ALE Middleware κατά τη διαδικασία ενημέρωσης των subscribers

87 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 org.fosstrak.ale.server.readers Το επίπεδο αυτό μοντελοποιεί το API του λογικού reader, όπως αυτό ορίστηκε στο υποκεφάλαιο 3.3.1, μέσω της κλάσης LogicalReader. Παρέχει ένα σύνολο κλάσεων για τον ορισμό και την παραμετροποίηση των λογικών readers που αντιστοιχούν σε έναν ή περισσότερους adaptors του χαμηλότερου επιπέδου και αποτελούν το σύνδεσμο με τους φυσικούς readers. Όλη η λειτουργικότητα του επιπέδου αυτού βασίζεται στην κλάση LogicalReaderManager, που διαθέτει τις απαραίτητες μεθόδους για τον ορισμό, την αρχικοποίηση, την εκτέλεση και τη διαχείριση κάθε λογικού reader. Και σε αυτό το επίπεδο οι μέθοδοι προσφέρονται υπό μορφή Web Service 5. Σύμφωνα με τα EPCglobal πρότυπα, υπάρχουν δύο τύποι λογικών reader: ο βασικός (Base Reader) και ο σύνθετος (Composite Reader) οι οποίοι δημιουργούν ένα σύνθετο πρότυπο σχεδίασης (Composite Design Pattern). Το πρότυπο αυτό δίνει τη δυνατότητα διαχείρισης τόσο των απλών όσο και των σύνθετων αντικειμένων με τον ίδιο απλό και εύκολο τρόπο. Σχήμα 4.9: Logical Reader Composite Design Pattern Diagram Προκειμένου να απλουστευθεί η μετάδοση των RFID δεδομένων μέσα στο Logical Reader API επιλέχθηκε ως πρότυπο σχεδίασης το πρότυπο observer, όπως φαίνεται και στο σχήμα 4.9. Αυτή η επιλογή έγινε γιατί αφενός ένα Event Cycle μπορεί να συμπεριφέρεται ως «παρατηρητής» απέναντι στην ανάγνωση δεδομένων από RFID ετικέτες, αλλά και ένας σύνθετος reader να κάνει χρήση του εν λόγω προτύπου σχεδίασης για να «παρατηρεί» τα παιδιά του. Σχήμα 4.10: Logical Reader Observer Design Pattern Diagram 5 [87]

88 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα org.fosstrak.ale.server.readers.xυζ Το επίπεδο αυτό είναι υπεύθυνο για τη σύνδεση οποιουδήποτε φυσικού reader μέσω μιας κλάσηςπροσαρμογέα (adaptor) με το ALE Middleware, ώστε να είναι δυνατή η ανάγνωση των δεδομένων που προέρχονται από τα RFID tags. Ο ρόλος του επιπέδου αυτού είναι να προσαρμόσει κατάλληλα τη λειτουργία του εκάστοτε φυσικού reader ώστε να υφίσταται επικοινωνία μεταξύ αυτού και του ALE Middleware. Υπάρχουν διαφορετικοί τύποι adaptors, που μπορούν να υποστηρίξουν διαφορετικούς τύπους hardware. Γι αυτόν τον λόγο επιλέχθηκε το πρότυπο προσαρμογέα (Adaptor Design Pattern) για τη σχεδίαση του επιπέδου αυτού, προκειμένου να μεταφράζεται το interface του κάθε reader στο interface του Base Reader που είναι συμβατό με τα ανώτερα επίπεδα. Έτσι, για παράδειγμα, το interface από έναν Feig reader μπορεί να είναι εντελώς διαφορετικό από το interface ενός Impinj reader, αλλά το interface στο οποίο «μιλάει» το ALE είναι ένα και κοινό: εκείνο του Base Reader. Σχήμα 4.11: Logical Reader Adaptor Design Pattern Diagram Για τη γενική περίπτωση στην οποία δεν υπάρχει κάποιος συγκεκριμένος adaptor για να υποστηρίξει έναν συγκεκριμένο τύπο reader, παρέχεται η κλάση HardwareAbstraction η οποία περιλαμβάνει τις κατάλληλες μεθόδους για την ενσωμάτωση και προσαρμογή του εκάστοτε reader API στις απαιτήσεις του ALE Middleware API, ώστε να δημιουργηθεί ο κατάλληλος και συμβατός adaptor. Στη συνέχεια αυτός ορίζεται μέσω ενός LRSpec αρχείου και αρχικοποιείται αμέσως μετά τον ορισμό του, σύμφωνα με τις παραμέτρους που δίνονται στο αρχείο αυτό, όπως γίνεται δηλαδή και σε κάθε άλλη περίπτωση Fosstrak ALE Client Όπως προαναφέρθηκε, το Fosstrak παρέχει δύο διαφορετικούς τύπους clients μέσω των οποίων γίνεται η παραμετροποίηση του ALE server: έναν web client (σχήμα 4.11) και έναν client υπό μορφή standalone java εφαρμογής (σχήμα 4.12). Σε κάθε περίπτωση, ο client διαθέτει το κατάλληλο interface ώστε να είναι δυνατός ο καθορισμός των λογικών readers, των event cycles και των ιδιοτήτων τους μέσα από XML αρχεία και δίνει τη δυνατότητα διαχείρισης του ALE από την πλευρά του χρήστη.

89 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Σχήμα 4.12: ALE Web Client Σχήμα 4.13: ALE Standalone Client [89]

90 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Fosstrak LLRP Commander Το Fosstrak υποστηρίζει το Low Level Reader Protocol (LLRP) μέσω του LLRP Commander. Πρόκειται για μία εφαρμογή η οποία επιτρέπει την παραμετροποίηση και τη διαχείριση φυσικών readers οι οποίοι υποστηρίζουν LLRP, μέσω ενός interface για το περιβάλλον του Eclipse (σχήμα 4.13). Η χρησιμότητα του LLRP Commander έγκειται στο γεγονός ότι διευκολύνει τη συγγραφή LLRP μηνυμάτων από την πλευρά του προγραμματιστή/χρήστη. Η εφαρμογή ενσωματώνει ένα φιλικό γραφικό περιβάλλον, προκειμένου να διευκολύνεται και να απλουστεύεται η συγγραφή και η αποστολή LLRP μηνυμάτων, και τα κατάλληλα εργαλεία που επιβεβαιώνουν την ορθότητα των μηνυμάτων που έχουν γραφεί καθώς και τη συμβατότητά τους με τις EPC global προδιαγραφές. Σχήμα 4.14: Περιβάλλον εργασίας του LLRP Commander προσαρμόσμένο στο περιβάλλον του Eclipse IDE

91 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος Fosstrak TDT Engine Το TDT (Tag Data Translation) τμήμα του Fosstrak είναι ένα επίπεδο αρχιτεκτονικής το οποίο ενσωματώνει όλες τις απαραίτητες λειτουργίες για την εύκολη και γρήγορη μετατροπή των EPC από μία μορφή σε άλλη. Συγκεκριμένα, ένας EPC αριθμός μπορεί να είναι σε δυαδική, δεκαδική ή δεκαεξαδική μορφή, σε μορφή URI ή σε κάποια παλαιότερη μη χρησιμοποιούμενημορφή. Ο ρόλος του TDT είναι η κωδικοποίηση και αποκωδικοποίηση μιας EPC αναπαράστασης σε μια άλλη, ανάλογα με τις απαιτήσεις που εισάγει η κάθε εφαρμογή. 4.15: Fosstrak Tag Data Translation Engine Fosstrak Capturing Application Σύμφωνα με τις προδιαγραφές του EPC Network, μια Capturing εφαρμογή είναι εκείνη η οποία καταγράφει τα events που έρχονται υπό μορφή αναφορών (ECReports) από το ALE Middleware στη βάση δεδομένων του EPCIS. [91]

92 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Όπως αναφέρθηκε στο υποκεφάλαιο 4.2.1, κατά τη διαδικασία παραμετροποίησης του ALE server, ορίζονται οι subscribers οι οποίοι θα δέχονται τα δεδομένα που αποστέλλονται από το server υπό μορφή αναφορών, σε μια συγκεκριμένη διεύθυνση. Το ρόλο του subscriber αναλαμβάνει η Capturing εφαρμογή, η οποία επικοινωνεί με τον ALE server μέσω HTTP/TCP πρωτοκόλλου. Οι αναφορές που λαμβάνονται υφίστανται την κατάλληλη επεξεργασία, ανάλογα με τους κανόνες που εισάγουν οι απαιτήσεις του συστήματος, και στη συνέχεια προωθούνται ως events στη βάση δεδομένων προς αποθήκευση. Οι κανόνες μπορούν να δοθούν στο σύστημα είτε με τη μορφή drools rules 6 είτε ως απλές μέθοδοι στα πλαίσια ενός java κώδικα. Συνίσταται η χρήση drools rules όταν οι κανόνες περιλαμβάνουν πολλές if-then-else υποπεριπτώσεις και όταν η επιχειρησιακή λογική είναι αρκετά σύνθετη ώστε να εμπλέκεται με τον κώδικα της εφαρμογής. To Fosstrak, πέρα από την ενσωματωμένη Capturing εφαρμογή που διαθέτει, δίνει τη δυνατότητα επέκτασης και ανάπτυξης, ανάλογα με τις απαιτήσεις και τους περιορισμούς που εισάγει η εκάστοτε περίπτωση Fosstrak EPCIS Όπως έχει προαναφερθεί, το EPCIS βρίσκεται στο ανώτερο επίπεδο της EPCglobal αρχιτεκτονικής και παρέχει τα κατάλληλα interfaces για την αποθήκευση events (capture interface) και για την ανάκτηση δεδομένων που σχετίζονται με τα αποθηκευμένα events (query interface) όπως φαίνεται και στο σχήμα Το Fosstrak παρέχει τρία διαφορετικά τμήματα που σχετίζονται με το EPCIS, την EPCIS βάση δεδομένων, την EPCIS Capturing εφαρμογή και την EPCIS εφαρμογή ερωτημάτων, που μπορούν να χρησιμοποιηθούν για τις λειτουργίες που αναφέρθηκαν παραπάνω. Η αρχιτεκτονική που υιοθετείται σε αυτό το επίπεδο είναι client-server, όπου το ρόλο του client αναλαμβάνει είτε η Capturing είτε η Query εφαρμογή ή και οι δύο. Το ρόλο του server αναλαμβάνει η ίδια η βάση δεδομένων, υπό την έννοια ότι παρέχει τα κατάλληλα interfaces και μπορεί να επεξεργάζεται εισερχόμενα αιτήματα. Η EPCIS βάση δεδομένων υλοποιεί πέντε διαδικασίες σύνδεσης (bindings) σύμφωνα με τις προδιαγραφές που ορίζονται και στο EPCglobal. XML binding για το επίπεδο ορισμού δεδομένων HTTP binding για το capture interface SOAP/HTTP binding για το query control interface HTTP binding για το query callback interface HTTPS binding για το query callback interface Οι συνδέσεις αυτές και οι διαφορές που υπάρχουν μεταξύ τους, περιγράφονται στη συνέχεια στα πλαίσια ενός διαχωρισμού του EPCIS σε επιμέρους λογικά επίπεδα. 6

93 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Σχήμα 4.16: Τα interfaces που παρέχει η βάση δεδομένων του Fosstrak EPCIS Access Tier Το επίπεδο αυτό είναι το σημείο εισόδου στην EPCIS βάση δεδομένων και παρέχει τα κατάλληλα interfaces που θα χρησιμοποιούν οι client εφαρμογές προκειμένου να προσπελάσουν τη βάση. Capture Interface: H HTTP σύνδεση που απαιτείται για το capture interface υλοποιείται μέσω ενός Java Servlet το οποίο εγγράφεται σε έναν servlet container (Apache Tomcat). Το servlet δέχεται αιτήματα από την capturing εφαρμογή, τη στιγμή που αποστέλλεται μια HTTP POST εντολή προς τον servlet container. Τα αιτήματα αυτά πρέπει να περιέχουν EPCIS events σε XML μορφή. Το servlet επικυρώνει ότι το εισερχόμενο XML αρχείο είναι συμβατό με τις προδιαγραφές του EPCglobal EPCIS και στη συνέχεια το προωθεί στο επόμενο επίπεδο. Query Control Interface: Αντίστοιχα, η SOAP/HTTP σύνδεση που απαιτείται για το query interface υλοποιείται μέσω του Apache CXF πλαισίου για Web Services σε συνδυασμό με το JAX-WS και το JAXB ΑΡΙ για την αντιστοίχιση των XML αρχείων σε Java αντικείμενα και αντίστροφα. Το πλαίσιο CXF αντιστοιχίζει τα περιεχόμενα των εισερχόμενων SOAP μηνυμάτων σε Java αντικείμενα, τα διαχειρίζεται με τη χρήση κατάλληλων δομών και τα επεξεργάζεται στο επόμενο επίπεδο. Business Tier Το επίπεδο αυτό δέχεται ως είσοδο δεδομένα από το αμέσως προηγούμενο επίπεδο, και διαθέτει τις κατάλληλες δομές για την επεξεργασία των δεδομένων αυτών. Έτσι, για την διαχείριση δεδομένων που προέρχονται από το capture interface υπεύθυνο είναι το CaptureOperationsModule ενώ για τη διαχείριση δεδομένων που προέρχονται από το query control interface υπεύθυνο είναι το QueryOperationsModule. CaptureOperationsModule: πρόκειται για τη δομή εκείνη που λαμβάνει τα EPCIS events και τα αποθηκεύει σε μια σχεσιακή βάση δεδομένων. [93]

94 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα QueryOperationsModule: πρόκειται για τη δομή εκείνη που μετασχηματίζει δυναμικά τις παραμέτρους των ερωτημάτων σε SQL ερωτήματα τα οποία προωθεί στο επόμενο επίπεδο για επεξεργασία. Τα αποτελέσματα των ερωτημάτων αυτών επιστρέφονται από το ανώτερο επίπεδο και στη συνέχεια προωθούνται προς την client εφαρμογή. Resource Tier Το επίπεδο αυτό συνίσταται από ένα σύστημα διαχείρισης σχεσιακών βάσεων δεδομένων (RDBMS) το οποίο αποθηκεύει όλα τα δεδομένα που περιλαμβάνονται σε ένα event αλλά και όλη την πληροφορία που σχετίζεται με το EPCIS. Query Callback Interface Αντίθετα με το Query Control Interface, to Query Callback Interface δεν είναι άμεσα προσπελάσιμο από client εφαρμογές. Για το λόγο αυτό, o client πρέπει να κάνει εγγραφή (subscription) ενός ερωτήματος μέσω του interface αυτού και τα αποτελέσματα να επιστραφούν και πάλι μέσω αυτού. Τα εγγεγραμμένα ερωτήματα χρησιμοποιούνται στις περιπτώσεις όπου ο χρήστης θέλει περιοδική ενημέρωση για την κατάσταση της βάσης δεδομένων (scheduled query) ή άμεση ενημέρωση όταν αναγνωριστεί κάποιο συγκεκριμένο event (trigger condition). Στη δεύτερη περίπτωση, τα αποτελέσματα από τα ερωτήματα προς τη βάση του EPCIS μπορούν να αποσταλούν κατευθείαν από την capturing στην query εφαρμογή, χωρίς να είναι απαραίτητο να μεσολαβήσει αποθήκευση του event στη βάση. 4.3 Ανασκόπηση κεφαλαίου Στο κεφάλαιο αυτό είδαμε αναλυτικά τα επίπεδα της αρχιτεκτονικής του Fosstrak project και αναλύσαμε το ρόλο που παίζει κάθε ένα από αυτά. Πρόκειται για ένα middleware το οποίο καλύπτει όλες τις βασικές απαιτήσεις για τη σχεδίαση, την υλοποίηση και τη χρήση ενός RFID συστήματος και είναι απόλυτα συμβατό με τις προδιαγραφές που έχει ορίσει το EPC Network για τα εν λόγω συστήματα. Στο επόμενο κεφάλαιο περιγράφεται η υλοποίηση της παρούσας διπλωματικής εργασίας η οποία βασίζεται κυρίως στην επέκταση των έτοιμων δομών που παρέχει το Fosstrak.

95 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Κεφάλαιο 5 Το σύστημα Silver Alert [95]

96 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα 5.1 Εισαγωγή Περιγραφή του προβλήματος Έχοντας αποσαφηνίσει τις βασικότερες έννοιες και τις τεχνικές ανάπτυξης Service-oriented αρχιτεκτονικών για RFID συστήματα, είμαστε σε θέση να προχωρήσουμε στην περιγραφή της υλοποίησης του συστήματος Silver Alert. Το Silver Alert είναι ένα σύστημα που έχει ως βασική λειτουργικότητα την καταγραφή και απεικόνιση διαδρομών που ακολουθούν ασθενείς οι οποίοι πάσχουν από Alzheimer. Η σημασία ενός τέτοιου συστήματος είναι μεγάλη, εάν αναλογισθεί κανείς ότι το μεγαλύτερο πρόβλημα που αντιμετωπίζουν σήμερα οι οικογένειες που έχουν κάποιο μέλος το οποίο πάσχει από τη νόσο του Alzheimer, είναι αυτό της εξαφάνισης. Το πρόβλημα αυτό καλείται να λύσει η εφαρμογή Silver Alert η οποία έχει αναπτυχθεί με τέτοιον τρόπο ώστε να διαφέρει από τα συνηθισμένα συστήματα ανίχνευσης και εντοπισμού θέσης. Σήμερα υπάρχουν διάφορες τεχνολογίες προσδιορισμού θέσης σε εσωτερικούς και εξωτερικούς χώρους: Ασύρματα τοπικά δίκτυα (WLANs) Bluetooth RFID Υπέρυθρη ακτινοβολία Υπερηχητικά σήματα GPS καθώς επίσης και διάφορες τεχνικές προσδιορισμού θέσης, όπως είναι για παράδειγμα η τριγωνοποίηση (triangulation), η μέθοδος της εγγύτητας (proximity) και η μέθοδος της ανάλυσης περιοχής (scene analysis). Τα συστήματα εντοπισμού θέσης που βασίζονται στις τεχνολογίες των RFID σήμερα, στην πλειονότητα των περιπτώσεων, αντιστοιχίζουν τον προς ανίχνευση στόχο με μία RFID ετικέτα, η οποία αποτελεί την ταυτότητά του. Παραδείγματα τέτοιων συστημάτων είναι αυτά που χρησιμοποιούνται στα συστήματα διαχείρισης εφοδιαστικής αλυσίδας, διαχείρισης αποθήκης, ελέγχου καταστημάτων, ασφαλείας κλπ. Σε αυτές τις περιπτώσεις, χρησιμοποιούνται RFID readers στους οποίους αποδίδεται μια συγκεκριμένη φυσική θέση. Με τον τρόπο αυτό, κάθε φορά που ο στόχος βρίσκεται εντός της εμβέλειας κάποιου reader, αναγνωρίζεται η θέση του. Ο τρόπος αυτός είναι αποτελεσματικός όταν πρόκειται για περιπτώσεις όπου ο έλεγχος θέσης γίνεται σε περιορισμένες γεωγραφικές εκτάσεις. Στο πρόβλημα που καλούμαστε να λύσουμε, ως γεωγραφική έκταση θεωρείται οποιοδήποτε γεωγραφικό πλάτος/μήκος μπορεί να είναι προσπελάσιμο από τον άνθρωπο. Συνεπώς, είναι δύσκολη και οικονομικά ασύμφορη η λύση της τοποθέτησης RFID readers σε διακριτά σημεία στο χώρο. Για το λόγο αυτό, θεωρούμε ότι κάθε ασθενής διαθέτει έναν RFID reader (ενσωματωμένο στο κινητό του τηλέφωνο) και κατανεμημένες στο χώρο βρίσκονται RFID ετικέτες, σε κάθε μία από τις οποίες αποδίδεται μια συγκεκριμένη φυσική διεύθυνση (οδός-αριθμός, ταχ. κώδικας, πόλη, χώρα). Με τον τρόπο αυτό, κάθε φορά που ο reader του ασθενούς έχει εντός της εμβέλειάς του κάποια RFID ετικέτα, το σύστημα είναι σε θέση να γνωρίζει το σημείο στο οποίο βρίσκεται ο ασθενής αυτός.

97 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Μια επιπλέον διαφοροποίηση του Silver Alert από τα κλασικά RFID συστήματα εντοπισμού θέσης, είναι το γεγονός ότι η λειτουργικότητά του δεν βασίζεται στη συνεχή παρακολούθηση (tracking) του ασθενούς, αλλά στη διατήρηση ιστορικού σχετικά με τη θέση του. Με αυτόν τον τρόπο, ο τελικός χρήστης, ο οποίος έχει υπό την ευθύνη του κάποιον συγκεκριμένο ασθενή, έχει τη δυνατότητα να εισέλθει στο σύστημα και να ανακτήσει όλες τις διαδρομές (paths) που έχει ακολουθήσει ο ασθενής εντός του δηλωθέντος χρονικού διαστήματος. Οι διαδρομές δίνονται σε μορφή Google Map Paths και κάθε σημείο της διαδρομής, από την αρχή έως το τέλος της, δίνεται και σε μορφή κειμένου. 5.2 Προδιαγραφές του συστήματος Χρήστες Ως χρήστες του συστήματος ορίζονται όλοι εκείνοι που μπορούν να αλληλεπιδρούν με αυτό. Patients: άτομα που πάσχουν από Alzheimer End Users: άτομα που έχουν ορισθεί ως πρόσωπα τα οποία έχουν αναλάβει την επιμέλεια κάποιου ασθενή, συνήθως άτομα του οικογενειακού περιβάλλοντος Administrators: άτομα που είναι υπεύθυνα για τη διαχείριση του συστήματος Reader: ο reader του συστήματος ο οποίος εκκινεί συγκεκριμένες διαδικασίες Στη συνέχεια, ο όρος «χρήστης» θα αναφέρεται στον τελικό χρήστη του συστήματος (end user) ενώ οι υπόλοιποι χρήστες θα κατονομάζονται όπως και παραπάνω Λειτουργικές απαιτήσεις Από την περιγραφή του προβλήματος το οποίο καλείται να λύσει το Silver Alert, προκύπτουν οι βασικές λειτουργικές απαιτήσεις συστήματος. Εξετάζοντας πρώτα τα χαμηλότερα επίπεδα, το σύστημα πρέπει να είναι σε θέση να επικοινωνεί με το hardware μέσω καλά ορισμένων interfaces. Ο RFID reader πρέπει να μπορεί να ενεργοποιείται μέσω της κατάλληλης παραμετροποίησης του ALE ώστε να μπορεί στη συνέχεια να διαβάζει RFID ετικέτες που βρίσκονται εντός της εμβέλειάς του. Μετά από κάθε ανίχνευση μίας ή περισσότερων ετικετών, το σύστημα πρέπει να προωθεί τα events στο ALE Middleware. Προκειμένου να είναι αξιοποιήσιμα, τα events πρέπει να προωθούνται υπό τη μορφή αναφορών (ECRepots) στην capturing εφαρμογή, η οποία αναλαμβάνει το ρόλο του subscriber για το ALE. Το capturing application πρέπει να επικοινωνεί με το ALE Middleware ώστε να μπορεί να λαμβάνει τις εισερχόμενες αναφορές. Στη συνέχεια, πρέπει να διαθέτει τις κατάλληλες μεθόδους ώστε να μετατρέπει τις αναφορές σε events τα οποία μπορούν να αποθηκευτούν στην EPCIS βάση δεδομένων. Η εφαρμογή αυτή πρέπει επιπλέον να μπορεί να αναγνωρίζει επαναλαμβανόμενα events. Αυτό σημαίνει ότι στην περίπτωση που μια νέα αναφορά είναι ίδια με την προηγούμενη, δε θα πρέπει να λαμβάνεται υπ όψιν, καθώς κάτι τέτοιο σημαίνει ότι ο ασθενής έχει σταματήσει σε κάποιο σημείο. [97]

98 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Συνεπώς, τα επαναλαμβανόμενα events απορρίπτονται και δεν αποθηκεύονται στην EPCIS βάση δεδομένων. Εξετάζοντας τα ανώτερα επίπεδα, το σύστημα πρέπει να δέχεται και να επεξεργάζεται τα εισερχόμενα αιτήματα για διαδρομές (paths) που έχει διανύσει ο ασθενής, και να τα παρουσιάζει στον τελικό χρήστη. Πρέπει να ανακτά όλα τα events που έχουν καταγραφεί μέσα στο χρονικό διάστημα που ορίζει ο χρήστης και στη συνέχεια πρέπει να μετασχηματίζει τα events αυτά σε φυσικές διευθύνσεις (σημεία). Επιπλέον, το σύστημα πρέπει να συνθέτει paths από ένα σύνολο σημείων, αναγνωρίζοντας ποια είναι τα σημεία εκείνα που ανήκουν ή όχι σε ένα path. Στην περίπτωση που το σύστημα δεν μπορεί να σχηματίσει κάποιο γνωστό path, πρέπει να επιστρέφει την τελευταία γνωστή θέση (διεύθυνση) στην οποία βρέθηκε ο ασθενής. Τέλος, το σύστημα πρέπει να επιστρέφει τις διαδρομές ή τα σημεία που έχουν προκύψει μετά από την κατάλληλη επεξεργασία σε μορφή εικόνας, αλλά και σε μορφή κειμένου. Από πλευράς διαχείρισης, το σύστημα πρέπει να επιτρέπει την εγγραφή καινούριων χρηστών και καινούριων ασθενών και να διατηρεί τα προσωπικά δεδομένα τους σε μια βάση δεδομένων (UsersDB) η οποία είναι ανεξάρτητη από την EPCIS βάση δεδομένων. Επιπλέον, το σύστημα πρέπει να ζητάει έγκυρα usernames και passwords πριν πραγματοποιηθεί η είσοδος κάποιου χρήστη στο σύστημα. Τέλος, το σύστημα πρέπει να επιτρέπει την αναζήτηση paths μόνο στους εξουσιοδοτημένους χρήστες, σε αυτούς δηλαδή που έχουν δηλωθεί ως άτομα στα οποία έχει παραχωρηθεί η επιμέλεια του συγκεκριμένου ασθενούς για τον οποίο πραγματοποιείται η διαδικασία αναζήτησης Σενάρια χρήσης Για τη σαφέστερη ανάπτυξη του συστήματος, αναγνωρίσθηκαν και καταγράφηκαν τα βασικότερα σενάρια χρήσης, τα οποία περιγράφουν με συντομία και σαφήνεια τη λειτουργικότητά του, βάσει των κυριότερων λειτουργικών απαιτήσεων που δόθηκαν στην προηγούμενη παράγραφο. ΣΧ.1 - Read Tags Το σενάριο αυτό περιγράφει την ανάγνωση RFID tags από τον reader του συστήματος. Χρήστης του συστήματος είναι το ALE, το οποίο εκκινεί τη διαδικασία ανάγνωσης, ενώ προϋπόθεση του σεναρίου είναι η κατάλληλη παραμετροποίηση του ALE ώστε να επικοινωνεί με τον reader. ΣΧ.2 - Capture Events Το σενάριο αυτό σχετίζεται με τη λειτουργικότητα του συστήματος κατά την αλληλεπίδρασή του με το hardware και με την αναγνώριση events. Χρήστης είναι ο reader, ο οποίος εκκινεί το σενάριο στέλνοντας events στο ALE και αυτό στη συνέχεια τα προωθεί υπό μορφή ECReports στο capturing application. Το capturing application απορρίπτει τα επαναλαμβανόμενα events και προωθεί στο EPCIS τα υπόλοιπα, προς αποθήκευση στην EPCIS βάση δεδομένων. Προϋπόθεση του σεναρίου είναι η ενεργοποίηση τόσο του ALE όσο και του capturing application. ΣΧ.3 - User Login Το σενάριο αυτό είναι η απλή περίπτωση εισαγωγής ενός εγγεγραμμένου χρήστη στο σύστημα Silver Alert, δίνοντας το username και το password του. Μετά την επιτυχή ταυτοποίησή του, ο χρήστης

99 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 εισάγεται στο σύστημα και μπορεί να αλληλεπιδράσει με αυτό. Προϋπόθεση του σεναρίου αποτελεί η εγκατάσταση της εφαρμογής Silver Alert στον προσωπικό/φορητό υπολογιστή του χρήστη. ΣΧ.4 - Register User Το σενάριο αυτό αφορά σε μη εγγεγραμμένους χρήστες στο σύστημα. Στην περίπτωση που ο χρήστης δεν διαθέτει λογαριασμό, μπορεί να επιλέξει «Register» από την αρχική οθόνη του GUI και να δημιουργήσει έναν καινούριο, επιλέγοντας το προσωπικό username και password και δίνοντας στη συνέχεια, τα προσωπικά του στοιχεία. Προϋπόθεση του σεναρίου αποτελεί η εγκατάσταση της εφαρμογής Silver Alert στον προσωπικό/φορητό υπολογιστή του χρήστη. ΣΧ.5 - Register Patient Το σενάριο αυτό αποτελεί συνέχεια του προηγούμενου. Μόλις ο χρήστης εισάγει τα προσωπικά του στοιχεία, το σύστημα ζητάει εγγραφή καινούριου ασθενή. Αυτός θα είναι ο ασθενής στον οποίο θα μπορεί να έχει πρόσβαση ο χρήστης σε κάθε επόμενη είσοδό του στο σύστημα. Με τον τρόπο αυτό αντιστοιχίζονται ένας ή περισσότεροι ασθενείς σε έναν συγκεκριμένο χρήστη, με συνέπεια να εξασφαλίζεται έτσι και η ασφάλεια των προσωπικών δεδομένων των ασθενών σε απόπειρα πρόσβασης από μη εξουσιοδοτημένους χρήστες. Το σύστημα είναι συνδεδεμένο με τη βάση δεδομένων UsersDB στην οποία αποθηκεύεται όλη η πληροφορία που αφορά σε προσωπικά δεδομένα ασθενών και χρηστών. Εκτενέστερη περιγραφή της UsersDB θα γίνει στη συνέχεια. ΣΧ.6 - Track patient Το σενάριο αυτό αποτελεί τον πυρήνα της λειτουργικότητας του συστήματος Silver Alert. Ο χρήστης ορίζει ένα συγκεκριμένο χρονικό διάστημα (ημερομηνία και ώρα) μέσα στο οποίο αναζητά τις διαδρομές που έχει ακολουθήσει ένας ασθενής. Απαραίτητη παράμετρος εισόδου είναι και το ID του reader που διαθέτει ο ασθενής, ώστε να αναγνωρίζεται το δικαίωμα του συγκεκριμένου χρήστη να προχωρήσει στη συγκεκριμένη αναζήτηση. Το ID αυτό είναι ένας μοναδικός εργοστασιακός αριθμός, με ένα προς ένα αντιστοιχία με τον εκάστοτε ασθενή. Στη συνέχεια, ακολουθεί μια σειρά από ενέργειες, οι οποίες χωρίζουν τη βασική ροή του σεναρίου αυτού σε διακριτές υπορροές: i. EPCIS Query: Το σύστημα μετατρέπει την εντολή εισόδου στο κατάλληλο ερώτημα προς την EPCIS βάση δεδομένων, ζητώντας να του επιστρέψει όλα τα events που καταγράφηκαν μέσα στο καθορισμένο χρονικό διάστημα, με αύξουσα σειρά από το παλαιότερο στο πιο πρόσφατο. ii. Define Path: Για όλα τα επιστρεφόμενα events το σύστημα ελέγχει εάν μπορούν να σχηματίσουν ένα ή περισσότερα paths, βάσει της χρονικής στιγμής καταγραφής τους (timestamp). iii. Draw Path: Κάθε ένα από τα events που ανήκει σε ένα path έχει ένα μοναδικό EPC και σε κάθε EPC έχει αντιστοιχηθεί μια φυσική διεύθυνση στην εσωτερική βάση του συστήματος. Έτσι, το σύστημα σχηματίζει τις κατάλληλες δομές, ώστε να μπορούν να δοθούν τα paths σε Google Static Map εικόνα στο GUI. Επιπλέον, το σύστημα διατηρεί όλη την πληροφορία που αφορά σε κάθε path και την επιστρέφει σε μορφή κειμένου στο GUI μαζί με την αντίστοιχη εικόνα. [99]

100 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Στην περίπτωση που δε βρεθεί καμία διαδρομή στο διάστημα που έχει ορίσει ο χρήστης, τότε το σενάριο ακολουθεί εναλλακτική ροή, στην οποία το σύστημα ενημερώνει το χρήστη ότι δεν μπορεί να σχηματίσει path και επιστρέφει την τελευταία γνωστή τοποθεσία στην οποία βρέθηκε ο ασθενής. Σε κάθε περίπτωση, προϋπόθεση του σεναρίου αποτελεί η επιτυχής είσοδος του χρήστη στο σύστημα (Login). 5.3 Σχεδίαση συστήματος Μετά την αναγνώριση των απαιτήσεων και των προδιαγραφών του συστήματος και μετά την εξαγωγή των σεναρίων χρήσης, τον κυριότερο ρόλο στην υλοποίηση του συστήματος παίζει η διαδικασία σχεδίασης. Βασισμένο στην αρχιτεκτονική του Fosstrak, το Silver Alert σχεδιάσθηκε με τέτοιο τρόπο ώστε να αλληλεπιδρά με αυτό σε κάθε επίπεδο μέσω των προκαθορισμένων interfaces. Η συνολική αρχιτεκτονική του συστήματος παρουσιάζεται στο σχήμα 5.1 στο οποίο με κόκκινο χρώμα δίνονται τα επίπεδα του Fosstrak τα οποία είναι ήδη υλοποιημένα ενώ με πράσινο χρώμα τα επίπεδα που σχεδιάσθηκαν βάσει των απαιτήσεων του συστήματος Silver Alert. Στην συνέχεια του κεφαλαίου αυτού δίνονται οι λεπτομέρειες σχεδίασης για κάθε ένα από τα επίπεδα που σχεδιάσθηκε για τις ανάγκες του συστήματος Silver Alert.

101 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Σχήμα 5.1: Επίπεδα αρχιτεκτονικής Silver Alert [101]

102 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Hardware Layer Πρόκειται για το χαμηλότερο επίπεδο, το επίπεδο συσκευής, το οποίο περιλαμβάνει είτε φυσικούς RFID readers και πραγματικές RFID ετικέτες είτε λειτουργικές προσομοιώσεις των στοιχείων αυτών. Αξίζει να σημειωθεί πώς για λόγους ευκολίας αλλά και μεγαλύτερης ευελιξίας, τα πειράματα πραγματοποιήθηκαν αρχικά σε περιβάλλον προσομοίωσης το οποίο προσφέρεται από το Fosstrak και στη συνέχεια επαληθεύτηκαν με τη χρήση πραγματικού hardware. O reader που χρησιμοποιήθηκε είναι o Vega UHF reader της εταιρείας ThingMagic ο οποίος εκτός από έτοιμο γραφικό περιβάλλον χρήσης, παρέχει και το δικό του, ενσωματωμένο Java API επιτρέποντας έτσι στο χρήστη να εισάγει τη δική του επιχειρησιακή λογική και λειτουργικότητα στο σύστημα Device Layer Και στις δύο περιπτώσεις που αναφέρθηκαν παραπάνω (προσομοίωση/πραγματικό περιβάλλον), βασική προϋπόθεση επικοινωνίας του hardware layer με τα ανώτερα επίπεδα (μέσω του ALE middleware) είναι ο σωστός και ακριβής καθορισμός των interfaces. Για τις ανάγκες της υλοποίησης σε περιβάλλον προσομοίωσης, ως interfaces χρησιμοποιήθηκαν οι δομές που προσφέρει το Fosstrak. Όπως έγινε σαφές και στην ενότητα 4.2.1, η οντότητα που είναι υπεύθυνη για την επικοινωνία μεταξύ hardware και ALE είναι ο λογικός reader, ο οποίος υλοποιείται μέσω ενός adaptor (HAL/LLRP adaptor). Έχοντας ως δεδομένο ότι ο εργαστηριακός reader δεν υποστηρίζει LLR messaging, επιλέχθηκε ο γενικότερος τύπος HAL. Το HAL interface που υποστηρίζει την επικοινωνία μεταξύ του εργαστηριακού reader και του ALE υλοποιήθηκε βάσει των προδιαγραφών που ορίζει το Fosstrak αλλά και βάσει των περιορισμών που εισάγει το περιβάλλον ανάπτυξης του ίδιου του reader. Το πακέτο το οποίο ενσωματώνει όλες τις απαραίτητες λειτουργίες είναι το devicelayer και περιλαμβάνει ένα interface και την αντίστοιχη υλοποίησή του, όπως φαίνεται και στο σχήμα 5.2. Σχήμα 5.2: Πακέτο devicelayer για την υλοποίηση του interface μεταξύ RFID reader και ALE middleware

103 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος Capture Layer Στο επίπεδο του Capturing Application περιλαμβάνονται δύο πακέτα, to capturingapp και το capturelayer. Το πρώτο είναι έτοιμο πακέτο που παρέχει το Fosstrak και υλοποιεί τη βασική λειτουργικότητα για την προώθηση των events προς το EPCIS. Για την ικανοποίηση των προδιαγραφών του Silver Alert σχεδιάσθηκε το πακέτο capturelayer. Το πακέτο αυτό περιλαμβάνει τις απαραίτητες κλάσεις οι οποίες θα ικανοποιούν τις απαιτήσεις που ορίζει το σενάριο χρήσης Capture Events (παράγραφος 5.2.3) και θα προσδίδουν στο επίπεδο αυτό την αντίστοιχη λειτουργικότητα. Σχήμα 5.3: Πακέτο κλάσεων capturelayer Query Application Στο επίπεδο του Query Application περιλαμβάνονται τέσσερα πακέτα, το processinglayer, το administrationlayer, το enduserlayer και το utils. Το πακέτο το οποίο πραγματοποιεί τα απαραίτητα ερωτήματα (queries) προς το EPCIS είναι το processinglayer, παρ όλα αυτά έχει γίνει η σχεδιαστική επιλογή να συμπεριληφθούν και τα υπόλοιπα πακέτα στο επίπεδο αυτό, καθώς όλα υλοποιούν την ανώτερη «επιχειρησιακή» λογική. processinglayer Το πακέτο αυτό περιλαμβάνει τις απαραίτητες κλάσεις οι οποίες θα ικανοποιούν τις απαιτήσεις που ορίζει το σενάριο χρήσης Track Patient (παράγραφος 5.2.3) και θα προσδίδουν στο επίπεδο αυτό την αντίστοιχη λειτουργικότητα. [103]

104 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σχήμα 5.4: Πακέτο κλάσεων processinglayer administrationlayer Το πακέτο αυτό περιλαμβάνει τις απαραίτητες κλάσεις οι οποίες θα ικανοποιούν τις απαιτήσεις που ορίζουν τα σενάρια χρήσης User Login, Register User και Register Patient (παράγραφος 5.2.3) και θα προσδίδουν στο επίπεδο αυτό την αντίστοιχη λειτουργικότητα. Σχήμα 5.5: Πακέτο κλάσεων administrationlayer

105 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 enduserlayer Το πακέτο αυτό περιλαμβάνει τις απαραίτητες κλάσεις για την υλοποίηση του γραφικού περιβάλλοντος διεπαφής (GUI), το οποίο δίνει τη δυνατότητα στον τελικό χρήστη να αλληλεπιδρά με το σύστημα. Εκτός από το απαραίτητο interface υπάρχει και η αντίστοιχη κλάση ελέγχου, για την αντιστοίχιση των εντολών εισόδου στις κατάλληλες μεθόδους επεξεργασίας. utils Σχήμα 5.6: Πακέτο κλάσεων enduserlayer Το πακέτο αυτό περιλαμβάνει ένα σύνολο από βοηθητικές κλάσεις για την μετατροπή δεδομένων από έναν τύπο σε έναν άλλο. Σχήμα 5.7: Πακέτο κλάσεων utils 5.4 Τεχνολογίες που χρησιμοποιήθηκαν Java: Η γλώσσα προγραμματισμού που χρησιμοποιήθηκε εξ ολοκλήρου για την ανάπτυξη του συστήματος είναι η Java. Η επιλογή έγινε αφενός γιατί οι τεχνολογίες Web Services υποστηρίζονται κυρίως από Java και αφετέρου γιατί το Fosstrak είναι γραμμένο στη γλώσσα αυτήν. Apache CXF: Το Apache CXF είναι ένα framework ανοιχτού κώδικα για τη διαχείριση και την παραμετροποίηση των Web Services. Παρέχει τις κατάλληλες δομές για τη δημιουργία Web [105]

106 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Services (WSDL/SOAP αρχείων) από Java κώδικα και αντίστροφα και επιτρέπει την επιλογή μεταξύ διαφορετικών data-binding τεχνολογιών, με πιο συνηθισμένες τις JAXB (Java XML Binding), XMLBeans και JAX-WS (Java XML - Web Services). Η JAX-WS είναι μια τεχνολογία για την ανάπτυξη Web Services και Web Service Clients που επικοινωνούν μέσω XML αρχείων. Η κλήση κάποιας υπηρεσίας γίνεται μέσω της SOAP αναπαράστασης μέσω HTTP πρωτοκόλλου. Από τις πιο σημαντικές ιδιότητες της τεχνολογίας JAX-WS είναι η ανεξαρτησία από πλατφόρμες, η ευελιξία και το γεγονός ότι μπορεί να αποκρύπτει την πολυπλοκότητα των SOAP μηνυμάτων από τον προγραμματιστή. Βασική προϋπόθεση για τη σωστή λειτουργία της είναι η χρήση των κατάλληλων annotations στον Java κώδικα, τα οποία είναι απαραίτητα για τη σωστή παραμετροποίηση των Web Services. Apache Tomcat: Ο Tomcat είναι ένας servlet container ο οποίος παρέχει το απαραίτητο HTTP interface των εφαρμογών και των υπηρεσιών web στον εξωτερικό κόσμο. Ο Tomcat δηλαδή, είναι ένας διακομιστής εφαρμογών, υλοποιημένος σε Java, γεγονός το οποίο του δίνει τη δυνατότητα να εκτελείται σε οποιοδήποτε λειτουργικό σύστημα έχει εγκατεστημένη την εικονική μηχανή της Java (JVM). ΜySQL: Ως σύστημα διαχείρισης σχεσιακών βάσεων δεδομένων χρησιμοποιήθηκε η MySQL. Πρόκειται για ανοιχτού κώδικα βάση, ιδιαίτερα διαδεδομένη, η οποία τρέχει ως εξυπηρετητής παρέχοντας πρόσβαση πολλαπλών χρηστών σε ένα σύνολο βάσεων δεδομένων. Java Swing: Για τη δημιουργία του GUI χρησιμοποιήθηκε το Swing framework της Java. Πρόκειται για ένα πλαίσιο το οποίο διαθέτει όλα τα απαραίτητα στοιχεία για την κατασκευή ακόμα και ενός απαιτητικού γραφικού περιβάλλοντος, είναι ανεξάρτητο πλατφόρμας και με εύκολα προσαρμόσιμη εμφάνιση και συμπεριφορά. 5.5 Υλικό που χρησιμοποιήθηκε Προκειμένου να αποδειχθούν και πειραματικά τα αποτελέσματα που προκύπτουν από τη λειτουργία του συστήματος σε περιβάλλον προσομοίωσης, χρησιμοποιήθηκε ο εργαστηριακός RFID reader, ένα σύνολο από RFID tags και μία κατευθυντική κεραία RFID reader Χρησιμοποιήθηκε ο Vega UHF Reader της εταιρείας ThingMagic. O reader αυτός έχει σχεδιασθεί έτσι ώστε να μπορεί να λειτουργεί ακόμη και κάτω από δύσκολες και ιδιαίτερα απαιτητικές συνθήκες. Η διασύνδεσή του με υπολογιστικά συστήματα γίνεται μέσω σειριακής θύρας RS-232 και με τη χρήση κατάλληλου λογισμικού. Μπορεί να συνδεθεί με τρεις κεραίες για την ανάγνωση και την εγγραφή RFID tags και με το κατάλληλο λογισμικό διαχείρισης δίνεται η δυνατότητα στο χρήστη να επιλέξει ποια θα είναι κεραία εκπομπής ή λήψης. Το πρωτόκολλο που υποστηρίζει για την ανάγνωση RFID tags είναι το EPC global GEN 2 (ISO C). Μπορεί να διαβάσει μέχρι και 190 RFID tags το δευτερόλεπτο με δυνατότητα αποφυγής συγκρούσεων

107 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 (anti-collision support) κατά τη διάρκεια της διαδικασίας ανάγνωσης και διαθέτει buffer 200 RFID tags. Είναι ιδανικός για χρήση τόσο σε εσωτερικούς αλλά και εξωτερικούς χώρους και μπορεί να υποστηρίξει μια πληθώρα εφαρμογών αφού βασίζεται στο M5e UHF RFID module 7. Σχήμα 5.8: Ο Vega Reader Πίνακας 5.1: Βασικά χαρακτηριστικά του reader που χρησιμοποιήθηκε Βασικά χαρακτηριστικά του Vega UHF RFID reader Διαστάσεις 21,6 x 13, 3 x 3,8 cm Θερμοκρασία λειτουργίας -40 ο C έως +75 ο C Τάση τροφοδοσίας 10 έως 16 Volt DC Ισχύς εξόδου 5dBm έως 30dBm (1Watt) Αντίσταση εξόδου 50 Ω Εμβέλεια Έως 9 μέτρα με κεραία κέρδους 6dBi GPIOs 2 GPIs, 1 GPO RFID Tags Χρησιμοποιήθηκε το μοντέλο Corona της εταιρείας Confidex. Οι συγκεκριμένες ετικέτες έχουν σχεδιασθεί ειδικά για να λειτουργούν κάτω από δύσκολες περιβαλλοντικές συνθήκες. Διαθέτει πιστοποίηση προστασίας ΙΡ67 και υποστηρίζει το πρωτόκολλο EPCglobal Class1 GEN2 (ISO C). Τα κυριότερα χαρακτηριστικά τους παρουσιάζονται στον πίνακα 5.2. Σχήμα 5.9: Η ετικέτα UHF Confidex Corona 7 [107]

108 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Πίνακας 5.2: Βασικά χαρακτηριστικά των ετικετών που χρησιμοποιήθηκαν Βασικά χαρακτηριστικά των Corona Confidex RFID tags Βάρος 1 gr Θερμοκρασία λειτουργίας -35 ο C έως +65 ο C Συχνότητες λειτουργίας 860 έως 960 MHz RFID Antenna Χρησιμοποιήθηκε το μοντέλο UHF RFID Mid Range Antenna της εταιρείας Kathrein. Η κατασκευή της είναι συμπαγής και διαθέτει πιστοποίηση ΙΡ67 με αποτέλεσμα να μπορεί να χρησιμοποιηθεί σε εσωτερικούς και εξωτερικούς χώρους και σε περιβάλλονται με δύσκολες συνθήκες. Η διασύνδεσή της με τον reader γίνεται με τη χρήση καλωδίου (connector) TNC. Υποστηρίζει τη ζώνη συχνοτήτων UHF (Ultra High Frequency) και για το λόγο αυτό μπορεί να ανιχνεύει tags ακόμα και σε μεγάλες αποστάσεις. Η μέγιστη ακτινοβολούμενη ισχύς της κεραίας είναι 0,5Watt και για την ισχύ αυτή η θεωρητική απόσταση ανάγνωσης είναι από 0,2 έως 2 μέτρα. Στην πράξη όμως, η απόσταση ανάγνωσης εξαρτάται κυρίως από τις ιδιότητες της ετικέτας και από τις περιβαλλοντικές συνθήκες. Η πόλωσή της είναι κυκλική (δεξιόστροφη) γεγονός που καθιστά δυνατή την ανάγνωση tags ανεξαρτήτως γωνίας. Στον πίνακα 5.3 δίνονται τα βασικά χαρακτηριστικά της κεραίας που χρησιμοποιήθηκε. Σχήμα 5.10: Κεραία UHF RFID Mid Range Kathrein Πίνακας 5.3: Βασικά χαρακτηριστικά της κεραίας που χρησιμοποιήθηκε Βασικά χαρακτηριστικά της UHF RFID Mid Range Kathrein κεραίας Διαστάσεις 15,6 x 12,6 x 8,1 cm Βάρος 320 gr Θερμοκρασία λειτουργίας -20 ο C έως +55 ο C Συχνότητα λειτουργίας 865 έως 870 MHz Πόλωση Κυκλική (δεξιόστροφη) Κέρδος dbci στα 866 MHz Σύνθετη αντίσταση εισόδου 50 Ω

109 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος Υλοποίηση Μετά την καταγραφή των προδιαγραφών και των απαιτήσεων και τη σχεδίαση του συστήματος, ακολουθεί η υλοποίηση. Η υλοποίηση έγινε σε τρία στάδια. Στο πρώτο στάδιο αναπτύχθηκε η λειτουργικότητα του ανώτερου επιπέδου, του Query Application ενώ στο δεύτερο στάδιο αναπτύχθηκε η λειτουργικότητα του Capturing Application. Και στις δύο περιπτώσεις η λειτουργικότητα εξετάσθηκε ως προς την ορθότητά της με τη χρήση του περιβάλλοντος προσομοίωσης που παρέχει το Fosstrak. Στο τρίτο και τελευταίο στάδιο ενσωματώθηκε στο σύστημα ο πραγματικός RFID reader και αναπτύχθηκε το κατάλληλο interface του βάσει των προδιαγραφών που έχουν ήδη αναφερθεί. Η ορθότητά του εξετάσθηκε με χρήση πραγματικών RFID tags. Στη συνέχεια της παραγράφου αυτής δίνονται αναλυτικά οι κλάσεις που υλοποιήθηκαν και στα τρία στάδια ανάπτυξης του συστήματος Πακέτο κλάσεων devicelayer Το πακέτο αυτό διαθέτει ένα interface και την αντίστοιχη κλάση υλοποίησης, η οποία υλοποιεί το σύνολο της λειτουργικότητας του σεναρίου χρήσης Read Tags. Σχήμα 5.11: Διάγραμμα κλάσεων πακέτου devicelayer [109]

110 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Η εκτέλεση πραγματοποιείται από το thread VegaControllerImplementation το οποίο είναι η υλοποίηση του VegaControllerInterface. Αυτό με τη σειρά του κληρονομεί το interface HardwareAbstraction που παρέχεται από τη δομή του Fosstrak και περιλαμβάνει ένα σύνολο μεθόδων οι οποίες μπορούν να υλοποιήσουν τη λειτουργικότητα των περισσότερων φυσικών readers, αναλόγως κάθε φορά με τις απαιτήσεις του συστήματος. Στην προκειμένη περίπτωση οι μέθοδοι που υλοποιήθηκαν για τις ανάγκες του συστήματός μας, είναι αυτές που αναφέρονται στο σχήμα 5.8. Κατά τη διαδικασία παραμετροποίησης του ALE μέσω του ALE Web Client αρχικά ορίζεται ο λογικός reader ο οποίος θα αποτελεί τον συνδετικό κρίκο με το φυσικό reader στο επίπεδο συσκευής. Στην προκειμένη περίπτωση, ο λογικός reader είναι αυτός που υλοποιείται από την κλάση VegaControllerImplementation. Αμέσως μετά τον ορισμό του ακολουθεί η αρχικοποίηση του με κλήση της μεθόδου initialize(). Μέσα στη μέθοδο αυτή δημιουργείται και αρχικοποιείται το αντικείμενο τύπου Reader του Vega Reader API, myreader, το οποίο αντιπροσωπεύει τον φυσικό reader. Ο myreader συνδέεται στο σύστημα (connect()) και παραμετροποιείται κατάλληλα. Μετά τον ορισμό του λογικού reader και την ολοκλήρωση της παραπάνω διαδικασίας, ορίζεται ο κύκλος ανάγνωσης και ο subscriber στον οποίο θα αποστέλλονται τα δεδομένα ανάγνωσης. Με τον ορισμό του κύκλου ανάγνωσης ξεκινά και η διαδικασία ανάγνωσης (startreading()) από την πλευρά του reader. Για λόγους συμφωνίας με το Fosstrak, θεωρούμε ότι ο reader δεν υποστηρίζει ασύγχρονη μετάδοση δεδομένων (θέτοντας τη σημαία supportsasynchronousreading false). Με τον τρόπο αυτό ορίζουμε αυτόματα ότι τα δεδομένα θα περνούν μέσα από τη δομή που παρέχει το Fosstrak, και συγκεκριμένα μέσα από τη μέθοδο identify(string[]). Η μέθοδος identify(string[]) δέχεται τα δεδομένα ανάγνωσης RFID tags στη μορφή TagReadData του Vega Reader API και τα μετασχηματίζει στη μορφή που απαιτεί το Fosstrak ώστε να μπορεί να τα αποστείλει στον εκάστοτε subscriber μέσω του ALE. Στην περίπτωση που απαιτείται τερματισμός του συστήματος, τότε από τον ALE Web Client επιλέγεται η μέθοδος undefine(readername) με αποτέλεσμα να αποσυνδέεται ο reader και να καταστρέφεται το αντικείμενο myreader Πακέτο κλάσεων capturelayer Το πακέτο αυτό διαθέτει τέσσερις κλάσεις, οι οποίες υλοποιούν το σύνολο της λειτουργικότητας του σεναρίου χρήσης Capture Events.

111 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Σχήμα 5.12: Διάγραμμα κλάσεων πακέτου capturelayer Όπως έχει ήδη προαναφερθεί, η προώθηση των events προς το EPCIS είναι λειτουργία την οποία αναλαμβάνει το capturelayer. Η εκτέλεση πραγματοποιείται από το thread CapturingApplication το οποίο ανοίγει ένα socket εντός της μεθόδου run() ώστε να ακούει τα δεδομένα που αποστέλλονται από το ALE και αφορούν σε RFID tags που έχει διαβάσει ο reader του συστήματος. Στη συνέχεια, τα δεδομένα αυτά μετατρέπονται σε αναφορές (ECReports), ώστε να μπορούν να είναι διαχειρίσιμα από την κλάση ReportsHandler. Η κλάση αυτή ενσωματώνει όλη την ανώτερη λογική που απαιτεί το επίπεδο αυτό μέσω της μεθόδου handlereports(ecreports, CaptureClient) και της μεθόδου capturedagain(epclisttype, ECReports, XMLGregorianCalendar) η οποία καλείται εντός της πρώτης. Η μέθοδος handlereports(ecreports, CaptureClient) αρχικά εξάγει το όνομα του reader από τον οποίο προέρχονται τα δεδομένα, το όνομα της αναφοράς, τη χρονική στιγμή ανάγνωσης των tags που περιλαμβάνονται στην αναφορά και τους epc κωδικούς που αντιστοιχούν σε αυτά τα tags. Έχοντας διαχωρίσει αυτήν την πληροφορία στη συνέχεια, καλεί τη μέθοδο capturedagain(epclisttype, ECReports, XMLGregorianCalendar), η οποία πραγματοποιεί ένα ερώτημα στην EPCIS βάση δεδομένων ώστε να του επιστραφεί το τελευταίο event που είχε αποθηκευτεί στον προηγούμενο κύκλο. Το επιστρεφόμενο event συγκρίνεται με το τρέχον ως [111]

112 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα προς τα στοιχεία του (reader name, ECReport name, timestamp, epc value). Στην περίπτωση που αυτά είναι ίδια και επιπλέον υπάρχει μεταξύ των δύο events χρονική διαφορά ικανοποιητικά μικρή (<10sec), τότε το τρέχον event θεωρείται ότι είναι το ίδιο με το τελευταίο και απορρίπτεται ως επαναλαμβανόμενο. Τα επαναλαμβανόμενα events απορρίπτονται, καθώς θεωρείται ότι ο ασθενής είναι στάσιμος σε κάποιο σημείο και δεν κινείται. Η ίδια διαδικασία ακολουθείται μέχρις ότου βρεθεί κάποιο καινούριο event. Στην περίπτωση αυτή η μέθοδος capturedagain( ) επιστρέφει false στην handlereports( ) οπότε και ξεκινά η διαδικασία σύνταξης του EpcisDocument, του αντικειμένου εκείνου που προωθείται τελικά στην EPCIS βάση δεδομένων και περιέχει όλη την απαραίτητη πληροφορία του event Πακέτο κλάσεων processinglayer Το πακέτο αυτό διαθέτει πέντε κλάσεις, οι οποίες υλοποιούν το σύνολο της λειτουργικότητας του σεναρίου χρήσης Track Patient από την πλευρά του συστήματος. Στην παράγραφο αυτή, εξετάζεται παράλληλα και η αλληλεπίδραση του τελικού χρήστη με το σύστημα, μέσω του GUI. Αυτό γίνεται περισσότερο για λόγους κατανόησης του διαγράμματος κλάσεων και όχι γιατί αναιρείται ο προηγούμενος διαχωρισμός των κλάσεων σε πακέτα. Η διαδικασία tracking εκκινεί από τον τελικό χρήστη, ο οποίος μέσω του GUI δίνει την κατάλληλη εντολή. Η εντολή αυτή από την πλευρά του τελικού χρήστη είναι ο καθορισμός του χρονικού διαστήματος (start date/time, end date/time) μέσα στο οποίο εξετάζονται οι διαδρομές που έχει ακολουθήσει ο ασθενής και είναι ο απλούστερος τρόπος με τον οποίο αλληλεπιδρά με το σύστημα. Η είσοδος που δίνει ο χρήστης στο σύστημα περνά μέσα από την κλάση ελέγχου GUIControl η οποία δημιουργήθηκε για να διαχειρίζεται κατάλληλα τις εντολές, χωρίς να απαιτείται από το χρήστη η γνώση περεταίρω λεπτομερειών για τον τρόπο λειτουργίας του συστήματος. Λαμβάνοντας την εντολή εισόδου, αρχικοποιεί το αντικείμενο τύπου CalculatePath το οποίο θα εκτελέσει τον κατάλληλο αλγόριθμο εύρεσης διαδρομών στο χρονικό διάστημα που ζήτησε ο χρήστης. Η μέθοδος getevents(gregoriancalendar, GregorianCalendar, int) της κλάσης CalculatePath κάνει ένα ερώτημα στην EPCIS βάση δεδομένων, με το οποίο ζητά να επιστραφούν όλα τα events (QueryResults) που έχουν καταγραφεί στο δοσμένο χρονικό διάστημα, με χρονολογική σειρά από το παλαιότερο στο πιο πρόσφατο. Στη συνέχεια, η μέθοδος definepath(list<object>, QueryResults, int) εκτελεί τον αλγόριθμο σχηματισμού διαδρομών. Ο αλγόριθμος αυτός, ξεκινώντας από το παλαιότερο, συγκρίνει χρονολογικά τα επιστρεφόμενα events ανά ζεύγη. Εάν απέχουν μεταξύ τους κατά ένα χρονικό διάστημα μικρότερο από την ακέραια παράμετρο εισόδου, τότε κάθε ένα από τα δύο αυτά events μετατρέπεται σε σημείο (PatientPoint) το οποίο προστίθεται στη διαδρομή (PatientPath). Σε διαφορετική περίπτωση, ο αλγόριθμος συνεχίζει τον έλεγχο μέχρι και το τελευταίο event, οπότε και μπορεί να σχηματίσει περισσότερα του ενός PatientPaths.

113 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Σχήμα 5.13: Διάγραμμα κλάσεων πακέτου processinglayer Μόλις ολοκληρωθεί ο αλγόριθμος, η μέθοδος drawpath(list<object>, QueryResults, int) αναλαμβάνει τον σχηματισμό της διαδρομής αυτής, υπό την έννοια ότι αντιστοιχίζει σε κάθε epc των events μία φυσική διεύθυνση ώστε να μπορεί να απεικονισθεί στο χάρτη μέσω της κλάσης MapDisplay. Η αντιστοίχιση αυτή γίνεται με τη χρήση της εσωτερικής βάσης δεδομένων UsersDB, η οποία θα περιγραφεί στη συνέχεια. Παράλληλα, διαμορφώνεται κατάλληλα όλη η πληροφορία σε μορφή κειμένου, ώστε να εμφανιστεί στο GUI του τελικού χρήστη. Με την ολοκλήρωση της διαδικασίας, ο τελικός χρήστης λαμβάνει στην οθόνη του GUI ένα σύνολο από στατικές Google Maps εικόνες οι οποίες απεικονίζουν τις διαδρομές που έχει ακολουθήσει ο ασθενής. Κάθε εικόνα διαθέτει και την αντίστοιχη περιγραφή σε μορφή κειμένου σε φυσική γλώσσα. [113]

114 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Πακέτο κλάσεων administrationlayer Το πακέτο αυτό περιλαμβάνει ένα Interface και δύο κλάσεις, οι οποίες είναι κλάσεις διαχείρισης του συστήματος. Στις κλάσεις αυτές έχει πρόσβαση το σύστημα όταν απαιτούνται ενέργειες διαχείρισης, όπως είναι η δημιουργία ενός νέου χρήστη, η σύνδεση ενός υπάρχοντος χρήστη στο σύστημα, η καταχώρηση ενός ασθενούς και η ανάκτηση των διευθύνσεων που αντιστοιχούν σε δοθέντες epc κωδικούς. Η διαχείριση επιτυγχάνεται με την υποβολή ερωτημάτων στην εσωτερική βάση δεδομένων του συστήματος (UsersDB), η οποία περιέχει τα κατάλληλα δεδομένα, όπως φαίνεται και στο σχήμα Σχήμα 5.14: Διάγραμμα κλάσεων administrationlayer Πακέτο κλάσεων enduserlayer Το πακέτο αυτό περιλαμβάνει δύο κλάσεις οι οποίες είναι υπεύθυνες για την αλληλεπίδραση του τελικού χρήστη με το σύστημα. Η κλάση/interface MainGUI δίνει το γραφικό περιβάλλον ενώ η κλάση ελέγχου GUIControl διαχειρίζεται την εισερχόμενη πληροφορία στο σύστημα. Από το σχήμα 5.11 φαίνεται ότι μέσω της κλάσης ελέγχου, το πακέτο αυτό αλληλεπιδρά αρχικά με το πακέτο κλάσεων processinglayer και το πακέτο κλάσεων administrationlayer, όπως περιγράφηκε στις προηγούμενες παραγράφους. Κοιτώντας το σύστημα από μια πιο καθολική σκοπιά, μπορούμε να πούμε ότι το πακέτο αυτό βρίσκεται στην κορυφή της αρχιτεκτονικής του συστήματος, καθώς από το επίπεδο αυτό ξεκινά όλη η διαδικασία ανίχνευσης διαδρομών που έχει ακολουθήσει κάποιος ασθενής.

115 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Σχήμα 5.15: Διάγραμμα κλάσεων πακέτου enduserlayer Πακέτο κλάσεων utils Τελευταίο είναι το πακέτο κλάσεων utils το οποίο περιλαμβάνει τρεις βοηθητικές κλάσεις, για την μετατροπή των δεδομένων από έναν τύπο σε άλλο, ώστε να μπορούν να χρησιμοποιηθούν από αντικείμενα που διαχειρίζονται διαφορετικούς τύπους δεδομένων. Σχήμα 5.16: Διάγραμμα κλάσεων πακέτου utils [115]

116 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Βάση δεδομένων UsersDB Για τις ανάγκες διαχείρισης του συστήματος, πέρα από την EPCIS βάση δεδομένων στην οποία καταχωρούνται δεδομένα που αφορούν σε events, RIFD tags και RFID readers, χρειάστηκε και η σχεδίαση μίας εσωτερικής βάσης δεδομένων, της UsersDB. Στη βάση αυτή υπάρχουν οι πίνακες User, RFIDReader, Registration και Patient, στους οποίους καταχωρούνται τα δεδομένα των χρηστών και των ασθενών, ενώ υπάρχει και ο πίνακας Location ο οποίος σε κάθε καταχώρηση του πίνακα RFIDTag αντιστοιχίζει μία φυσική διεύθυνση, καθώς όπως έχει αναφερθεί, κάθε RFIDtag βρίσκεται σε ένα και μοναδικό σημείο. Σχήμα 5.17: Η βάση δεδομένων UsersDB Όπως φαίνεται και στο σχήμα 5.14, κάθε τελικός χρήστης (User) αντιστοιχίζεται σε μία εγγραφή (Registration) και η αντιστοίχιση αυτή γίνεται με τη χρήση του ξένου κλειδιού Username. Επίσης, κάθε τελικός χρήστης αντιστοιχίζεται σε έναν ασθενή (Patient) μέσω του ξένου κλειδιού PatientID και ο ασθενής με τη σειρά του αντιστοιχίζεται σε έναν και μοναδικό RFID reader μέσω του ξένου κλειδιού ReaderID. Αντίστοιχα, κάθε RFID tag αντιστοιχίζεται σε μία μοναδική φυσική διεύθυνση μέσω του ξένου κλειδιού LocationID.

117 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος Επίδειξη Στο υποκεφάλαιο αυτό θα γίνει η επίδειξη των σεναρίων χρήσης τα οποία εξετάσθηκαν στα προηγούμενα υποκεφάλαια ως προς τις απαιτήσεις και τις προδιαγραφές τους, τη σχεδίαση και την υλοποίησή τους Επίδειξη σεναρίου χρήσης Register User Στο σχήμα 5.15 παρουσιάζεται η αλληλουχία των ενεργειών που ακολουθεί ένας καινούριος χρήστης προκειμένου να εγγραφεί στο σύστημα. Ο χρήστης επιλέγει «Register» από την αρχική οθόνη και το σύστημα του εμφανίζει τη φόρμα εγγραφής. Ο χρήστης πρέπει να συμπληρώσει τα απαιτούμενα πεδία και στη συνέχεια να επιλέξει «Register» ώστε στη συνέχεια να συμπληρώσει τα προσωπικά του στοιχεία. Αφού ολοκληρωθεί η διαδικασία αυτή, ο χρήστης πρέπει να προχωρήσει στην καταχώρηση τω προσωπικών στοιχείων του ασθενούς του οποίου έχει την επίβλεψη (σχήμα 5.16). Ο χρήστης επιλέγει «Create New Patient Profile» και με τον τρόπο αυτό, σε κάθε χρήστη αντιστοιχίζεται ένας ασθενής. Τα δεδομένα που καταχωρεί ο χρήστης στην συγκεκριμένη περίπτωση, αποθηκεύονται στη βάση δεδομένων UsersDΒ στην οποία έχει πρόσβαση μόνο ο διαχειριστής του συστήματος. Σχήμα 5.18: Διαδικασία εγγραφής νέου χρήστη στο σύστημα Silver Alert [117]

118 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σχήμα 5.19: Διαδικασία εγγραφής νέου ασθενούς στο σύστημα Silver Alert Επίδειξη σεναρίου χρήσης User Login Στο σχήμα 5.17 παρουσιάζεται το παράθυρο διαλόγου μεταξύ του χρήστη και του συστήματος. Πριν από οποιαδήποτε αλληλεπίδραση του χρήστη με το σύστημα, είναι απαραίτητη η ταυτοποίησή του μέσω της γνωστής διαδικασίας Login. Ο χρήστης εισάγει Username και Password και επιλέγει «Login». Εάν τα στοιχεία που έχει δώσει είναι σωστά, ανοίγει το παράθυρο διερεύνησης διαδρομών. Σχήμα 5.20: Παράθυρο εισαγωγής του χρήστη στο σύστημα Silver Alert

119 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος Επίδειξη σεναρίου χρήσης Track Patient Στο σχήμα 5.18 παρουσιάζεται η διαδικασία εύρεσης των διαδρομών που έχει ακολουθήσει κάποιος ασθενής. Μόλις ο χρήστης εισαχθεί επιτυχώς στο σύστημα, του ζητείται να δώσει το ReaderID, το οποίο αντιστοιχεί στον reader που διαθέτει ο ασθενής του οποίου είναι επιβλέπων. Στη συνέχεια, εμφανίζεται η οθόνη επιλογής του χρονικού διαστήματος για το οποίο θα εκτελεστεί το σενάριο. Ο χρήστης δίνει τις ημερομηνίες και τις ώρες που τον ενδιαφέρουν (start date/time, end date/time) καθώς και το μέγιστο επιτρεπτό διάστημα που θα χωρίζει δύο events μεταξύ τους. Σχήμα 5.21: Διαδικασία εισαγωγής παραμέτρων για τον εντοπισμό των διαδρομών που έχει ακολουθήσει ο ασθενής Επιλέγοντας «TRACK» το σύστημα επιστρέφει στο χρήστη μία ή περισσότερες διαδρομές που έχουν βρεθεί εντός του καθορισμένου χρονικού διαστήματος, σε μορφή εικόνας Google Maps (σχήμα 5.19). Σε περίπτωση που δεν βρεθεί κάποια διαδρομή μέσα στο χρονικό διάστημα που έχει επιλέξει ο χρήστης, τότε το σύστημα επιστρέφει την τελευταία τοποθεσία στην οποία βρέθηκε ο ασθενής, και πάλι σε μορφή εικόνας Google Maps (σχήμα 5.20). [119]

120 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σχήμα 5.22: Απεικόνιση διαδρομής (SQ Start point, EQ End point) Σχήμα 5.23: Απεικόνιση τοποθεσίας

121 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος Επίδειξη σεναρίου χρήσης Read Tags και Capture Events Για τους λόγους της επίδειξης, επιλέγουμε το περιβάλλον προσομοίωσης του Fosstrak. Τα αποτελέσματα έχουν αποδειχθεί και πειραματικά, με χρήση του εργαστηριακού reader Vega της εταιρείας Thing Magic. Όπως έχει προαναφερθεί, για την εκκίνηση του reader και τη σύνδεσή του στο σύστημα, απαιτείται η κατάλληλη παραμετροποίηση του ALE μέσω του ALE Web Client. O τρόπος παραμετροποίησής του φαίνεται στα επόμενα σχήματα (σχήμα 5.21 σχήμα 5.26). Αρχικά πρέπει να γίνει ο καθορισμός του endpoint μέσω του οποίου θα γίνεται η κλήση των κατάλληλων Web Services. Αυτό γίνεται με την κλήση (invoke) της μεθόδου setendpoint(string endpointname) του LogicalReader API (ALELRServicePort). 5.24: Πρώτο βήμα: καθορισμός ALELR endpoint Στη συνέχεια ακολουθεί ο ορισμός του Logical Reader ο οποίος θα αποτελέσει το συνδετικό κρίκο μεταξύ φυσικού reader και ALE middleware. Αυτό γίνεται με την κλήση της μεθόδου define(string readername, LRSpec spec). Το LRSpec είναι το XML αρχείο που περιλαμβάνει όλη την πληροφορία σχετικά με το λογικό reader. Στην προκειμένη περίπτωση, δηλώνεται ως λογικός reader αυτός που αντιστοιχεί στο περιβάλλον προσομοίωσης. [121]

122 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σχήμα 5.25: Καθορισμός Logical Reader Αμέσως μετά τον καθορισμό του λογικού reader, ανοίγει το παράθυρο προσομοίωσης του φυσικού reader. Ο reader αυτός διαθέτει τέσσερις κεραίες. Σχήμα 5.26: Reader προσομοίωσης Ακολουθεί ο καθορισμός του endpoint από την πλευρά του Filtering and Collection API (ALEServicePort), μέσω του οποίου θα γίνονται οι κλήσεις των Web Services.

123 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Σχήμα 5.27: Καθορισμός ALE endpoint Απαραίτητο βήμα για να ξεκινήσει ο κύκλος ανάγνωσης, είναι ο καθορισμός του Event Cycle. Αυτό γίνεται με την κλήση της μεθόδου define(string specname, String specfilepath). Το ECSpec είναι το XML αρχείο που περιλαμβάνει όλη την πληροφορία σχετικά με τη διαδικασία ανάγνωσης, τη δημιουργία των events σε συγκεκριμένη μορφή και τον τύπο των επιστρεφόμενων RFID δεδομένων. Τελευταίο βήμα της διαδικασίας παραμετροποίησης είναι ο καθορισμός του subscriber στον οποίο θα αποστέλλονται τα αποτελέσματα μετά το τέλος κάθε κύκλου ανάγνωσης. Αυτό γίνεται με την κλήση της μεθόδου subscribe(string specname, String notificationuri). Για να λάβει δεδομένα ο subscriber, πρέπει να είναι ενεργός και να ακούει στο ίδιο URI με αυτό που έχει δηλωθεί στο ALE. Ο reader είναι έτοιμος τώρα να διαβάσει RFID tags, να αποστείλει τα δεδομένα αυτά στο ALE και αυτό με τη σειρά του, εφόσον τα έχει επεξεργαστεί κατάλληλα, στον subscriber. [123]

124 Σχεδίαση και Ανάπτυξη Υπηρεσιοστρεφών Αρχιτεκτονικών για RFID Συστήματα Σχήμα 5.28: Καθορισμός του Event Cycle Σχήμα 5.29: Καθορισμός του subscriber

125 Διπλωματική Εργασία της Μαρίνας Ειρήνης Σταματιάδου - Ιούνιος 2012 Από το παράθυρο της προσομοίωσης μπορούμε να επιλέξουμε Tag Add Tag και να προσθέσουμε ένα RFID tag, με epc κωδικό σε δεκαεξαδική μορφή. Σχήμα 5.30: Προσθήκη RFID tag με κωδικό της επιλογής του χρήστη, σε δεκαεξαδική μορφή Το tag αυτό δεν θα ανιχνευτεί από τον reader εάν δεν βρίσκεται εντός της εμβέλειάς του και για να γίνει αυτό, πρέπει να τοποθετηθεί επάνω σε κάποια κεραία του. Αυτό φαίνεται στις επόμενες εικόνες. Στην εικόνα 5.27 το RFID tag βρίσκεται εκτός εμβέλειας, οπότε ο subscriber (Capturing Application) επιστρέφει κενές αναφορές. Σχήμα 5.31: Ο subscriber αποστέλλει κενές αναφορές, καθώς το RFID tag βρίσκεται εκτός εμβέλειας του reader [125]