Ατοµική ιπλωµατική Εργασία ΣΥΣΤΗΜΑ ΠΑΡΟΧΗΣ ΠΛΗΡΟΦΟΡΙΩΝ ΙΑ ΙΚΤΥΟΥ ΜΕΣΩ ΚΙΝΗΤΩΝ ΚΑΙ ΕΥΕΛΙΚΤΩΝ ΠΡΑΚΤΟΡΩΝ ΙΑ ΙΚΤΥΟΥ. ηµήτρης Ζεϊναλιπούρ

Transcript

1 Ατοµική ιπλωµατική Εργασία ΣΥΣΤΗΜΑ ΠΑΡΟΧΗΣ ΠΛΗΡΟΦΟΡΙΩΝ ΙΑ ΙΚΤΥΟΥ ΜΕΣΩ ΚΙΝΗΤΩΝ ΚΑΙ ΕΥΕΛΙΚΤΩΝ ΠΡΑΚΤΟΡΩΝ ΙΑ ΙΚΤΥΟΥ ηµήτρης Ζεϊναλιπούρ ΠΑΝΕΠΙΣΤΗΜΙΟ ΚΥΠΡΟΥ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ Ιούνιος 2000

2 ΠΑΝΕΠΙΣΤΗΜΙΟ ΚΥΠΡΟΥ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ Σύστηµα Παροχής Πληροφοριών ιαδικτύουμέσω Κινητών Ευέλικτων Πρακτόρων ιαδικτύου ηµήτρης Ζεϊναλιπούρ Επιβλέπων Καθηγητής Μάριος. ικαιάκος Η Ατοµική ιπλωµατική Εργασία υποβλήθηκε προς µερική εκπλήρωση των απαιτήσεων απόκτησης του πτυχίου Πληροφορικής του Τµήµατος Πληροφορικής του Πανεπιστηµίου Κύπρου Ιούνιος 2000

3 ΕΥΧΑΡΙΣΤΙΕΣ Ευχαριστώ τον επιβλέποντα καθηγητή της διπλωµατικής αυτής εργασίας ρ. Μάριο ικαιάκο, για την καθοδήγηση, το πλούσιο υλικό που µου έδωσε και την πολύµορφη βοήθεια που µου πρόσφερε κατά τη διάρκεια της χρονιάς. Τον ευχαριστώ πολύ για την υποµονή και κυρίως την κατανόηση που επέδειξε σε όσες στιγµές τον χρειάστηκα. Τον ευχαριστώ επίσης για την εµπιστοσύνη που έδειξε στο άτοµό µου και την πάντα πρόθυµη διάθεσή του για συζήτηση. Ευχαριστώ όλους τους φίλους και συµφοιτητές, που µε το δικό τους τρόπο, άµεσο ή έµµεσο, βοήθησαν στην αποπεράτωση αυτής της εργασίας. Ευχαριστώ τον Ανδρέα Λιβέρδο που µου παρείχε το υλικό της διπλωµατικής του εργασίας και πάνω στο οποίο µπόρεσα να δοµήσω την δική µου διπλωµατική εργασία. Ευχαριστώ τον Nazmul Idris για το πλούσιο υλικό που µου παρείχε για την εκµάθηση του XML Parser for Java (XMLP4J), τον Stefan Rauch από το Πανεπιστήµιο Osnabrueck της Γερµανίας µε τον οποίο είχα πολύ εποικοδοµητικές συζητήσεις σε θέµατα που αφορούσαν την Java και την XML, τις ηλεκτρονικές ταχυδροµικές λίστες XML-DEV και XML-L που µου παρείχαν χρήσιµες πληροφορίες και ενηµέρωση για την εξέλιξη της τεχνολογίας XML. Ευχαριστώ επίσης όλα τα µέλη του ΙΒΜ AlphaWorks XMLP4J Discussion Group που πάντα ήταν πρόθυµα να επιλύσουν απορίες που είχα. Ευχαριστώ τέλος την οικογένειά µου, για την κατανόηση που έδειξαν στις πολυήµερες απουσίες µου από κοντά τους. I

4 ΠΕΡΙΛΗΨΗ Η σύγκλιση των τεχνολογιών της Πληροφορικής και των τηλεπικοινωνιών ωθεί τις σύγχρονες ανθρώπινες κοινωνίες προς την αποκαλούµενη Κοινωνία της Πληροφορίας. Στην κοινωνία αυτή οι δραστηριότητες του µέσου ανθρώπου επεκτείνονται σε ολοένα και περισσότερα θέµατα, απαιτώντας εκ µέρους του µεγαλύτερη προσπάθεια για συγκέντρωση και επεξεργασία πληροφοριών. Μία από τις δραστηριότητες αυτές είναι η έγκυρη ενηµέρωση του χρήστη µε πληροφορίες που περιλαµβάνονται στα ενδιαφέροντα του. Το Παγκόσµιο Πλέγµα Πληροφοριών (WWW), αποτελεί την σηµαντικότερη πηγή πληροφόρησης για ένα ευρύ φάσµα θεµάτων. Οι υπάρχουσες όµως τεχνολογίες δεν επαρκούν για να καλύψουν τη διαδικασία συλλογής και αξιολόγησης των πληροφοριών που υπάρχουν. Επίσης λόγω της αλµατώδους ανάπτυξης του ιαδικτύου παρουσιάζονται φαινόµενα πληροφοριακής υπερφόρτωσης, αποπροσανατολισµού του χρήστη, αλλάκαι δυσκολία ανάκτησης της πληροφορίας αφού ένας χρήστης αναγκάζεται να χρησιµοποιήσει διαφορετικάεργαλεία για διαφορετικές πηγές πληροφοριών Την ανεπάρκεια αυτή έρχονται να καλύψουν νέες τεχνολογίες που προκύπτουν από ερευνητικές προσπάθειες µε αντικείµενο τη δηµιουργία συστηµάτων συλλογής, φιλτραρίσµατος και φύλαξης πληροφοριών. Στην κατεύθυνση αυτή, κεντρικό ρόλο έχουν η γλώσσα προγραµµατισµού Java η τεχνολογία των Κινητών Πρακτόρων και η τεχνολογία περιγραφής δεδοµένων XML. Στόχος του συστήµατος που θα προτείνουµε είναι η δηµιουργία ενός πρότυπου συστήµατος συλλογής και αξιολόγησης των πληροφοριών που υπάρχουν στο Παγκόσµιο Πλέγµα Πληροφοριών (ΠΠΠ) και η παροχή µέσω ευφυών συστηµάτων διαπροσωπείας, ενός ολοκληρωµένου περιβάλλοντος (integrated environment) ενηµέρωσης. Με αυτό τον τρόπο ο χρήστης θα βλέπει µια ενιαία και ολοκληρωµένη όψη όλων των πληροφοριών που συλλέγονται για αυτόν, µέσα σε µια κοινή και οικεία αλληγορία αλληλεπίδρασης II

5 Πιο συγκεκριµένα το σύστηµα που θα προτείνουµε θα κάνει χρήση µιας σειράς νέων τεχνολογιών και προσεγγίσεων για την υπερπήδηση των προβληµάτων που προαναφέρθηκαν, µε σκοπό την µετάβαση Από συστήµατα προσανατολισµένα στις διάφορες υπηρεσίες και πρωτόκολλα του ιαδικτύου (π.χ newsgroups, ing lists, WWW) σε συστήµατα ανθρωποκεντρικάκαι πληροφορικό-κεντρικάδηλαδή προσανατολισµένα στις πληροφοριακές ανάγκες των χρηστών Από αρχιτεκτονικές βασισµένες στο µοντέλο της ανάκτησης πληροφοριών µε αιτήσεις (information pull) σε αρχιτεκτονικές εκποµπής πληροφοριών (information push) µε την χρήση ευφυών πρακτόρων. Με αυτό τον τρόπο µετακινούµε το κλασσικό τρόπο ανάκτησης πληροφοριών από το ιαδίκτυο, όπου δεν έχουµε τον χρήστη να ανατρέχει προς την πληροφορία αλλάη πληροφορία προς αυτόν Από την υποστήριξη χρηστών µε διασυνδετικότητα σταθερού δικτύου (fixed network connection), στην δυνατότητα ευέλικτης προσαρµογής σε διαφορετικές διασυνδετικότητες χρηστών ( σταθερού δικτύου και κινητές mobile connectivity) Από συστήµατα που υλοποιούν την κωδικοποίηση δεδοµένων µε χρήση διαφορετικών τεχνολογιών (π.χ διαφορετικά databases µε διαφορετικά drivers σε διαφορετικές πλατφόρµες ή text files µε ειδικές δοµές) σε συστήµατα µε ενιαίο τρόπο περιγραφής των δεδοµένων που µπορεί εύκολα να γίνει αντιληπτός από τους κινητούς πράκτορες. Πιο συγκεκριµένα θα γίνει χρήση της τεχνολογίας περιγραφής δεδοµένων XML Στην παρούσα διπλωµατική εργασία, εξετάζουµε το πρόβληµα της συλλογής και αξιολόγησης πληροφοριών από το ιαδικτύου, και οι οποίες πληροφορίες µπορεί να προέρχονται οµάδες συζήτησης (newsgroups), το ηλεκτρονικό ταχυδροµείο ( ) ή τον γενικότερο χώρο του ΠΠΠ και προτείνουµε ένα σύστηµα το οποίο ονοµάζουµε «erace (extensible Retrieval Annotation Caching Engine» για την επίλυση του προβλήµατος. Το erace είναι βασισµένο στη γλώσσα Java την τεχνολογία Κινητών Πρακτόρων Concordia της Mitsubishi Electric ITA και την τεχνολογία περιγραφής III

6 δεδοµένων XML µε την υλοποίηση του XMLP4J IBM. Υλοποιούµε στη συνέχεια ένα πρωτότυπο αυτού του συστήµατος. Η δοµή της εργασίας έχει ως εξής. Στο Κεφάλαιο 1 γίνεται µια εισαγωγική αναφορά στα θέµατα που θα µας απασχολήσουν. Στο Κεφάλαιο 2 δίνουµε µια αναλυτική περιγραφή της τεχνολογίας περιγραφής δεδοµένων XML. Στα Κεφάλαια 3 και 4 εξετάζουµε τα πακέτα της IBM XMLP4J και το σύστηµα Κινητών Πρακτόρων Concordia αντίστοιχα. Στο Κεφάλαιο 5 περιγράφουµε την τεχνολογία των Java Servlets. Στο Κεφαλαίο 6 περιγράφουµε την αρχιτεκτονική του erace. Στο Κεφαλαίο 7 περιγράφουµε τον Εξυπηρετητή χρηστών, το Κατάστιχο Ενδιαφερόντων και τον Χρονοδροµολογητή. Στο Κεφάλαιο 8, 9 και 10 περιγράφουµε τις αρχιτεκτονικές και τις υλοποιήσεις των διαµεσολαβητών POP3, HTTP και NTTP αντίστοιχα. Στο Κεφαλαίο 11 περιγράφουµε τον Σχολιασµό της Κρυφής Μνήµης και τον µηχανισµό υλοποίησης του. Στο Κεφαλαίο 12 περιγράφουµε τους διάφορους τρόπους ενηµέρωσης του χρήστη και την αρχιτεκτονική και υλοποίηση του Εξυπηρετητή Ενηµέρωσης. Ολοκληρώνουµε στο Κεφάλαιο 13 µε τα συµπεράσµατα από τις εµπειρίες µας. IV

7 Περιεχόµενα Κεφάλαιο 1: Εισαγωγή Παρακίνηση Η Γλώσσα Προγραµµατισµού JAVA Η Τεχνολογία Κινητών Πρακτόρων H Τεχνολογία Περιγραφής εδοµένων XML Τεχνικές Ανάκτησης και Φιλτραρίσµατος Πληροφοριών. 4 Κεφάλαιο 2: H XML (extensible Markup Language Εισαγωγή ιαφορές της ΧΜL µε γλώσσες προγραµµατισµού ιαφορές της ΧΜL µε την ΗΤΜL Περιγραφή τεχνικών όρων της XML Μορφοποίηση XML µε CSS και XSL Τι είναι ένας Parser Τι είναι το DOM και το DOM API Τι είναι το SAX και το SAX API Επιλογή µεταξύ SAX και DOM Κριτήρια επιλογής κατάλληλου Parser. 22 Κεφάλαιο 3: To σύνολο Πακέτων XMLP4J Εισαγωγή Τα Πακέτα του XMLP4J Η βιβλιοθήκη XMLUtils. 35 Κεφάλαιο 4: Το Σύνολο Πακέτων CONCORDIA Εισαγωγή Αρχιτεκτονική Τα Πακέτα του CONCORDIA. 43 V

8 Κεφάλαιο 5: Τα Java Servlets Εισαγωγή Η διαφορές και οι οµοιότητες των Servlets και των CGIs ιαφορετικοί τρόποι γραφής ενός Servlet Το Servlet API Παραδείγµατα επεξεργασίας Φόρµας. 55 Κεφάλαιο 6: Αρχιτεκτονική Συστήµατος Το πρόβληµα Προτεινόµενη Λύση Οι Σχεδιαστική Στόχοι του Συστήµατος Αρχιτεκτονική Συστήµατος. 63 Κεφάλαιο 7: Εξυπηρετητής Χρηστών - Κατάστιχο Ενδιαφερόντων Χρονοδροµολογητής Ο Εξυπηρετητής Χρηστών. 66 a. Εισαγωγή. 66 b. Περιγραφή XML καταλόγου χρηστών Το Κατάστιχο Ενδιαφερόντων. 68 a. Προσωπικές Πληροφορίες. 69 b. Πληροφορίες Ενηµέρωσης του Χρήστη. 69 c. Πληροφορίες σχετικάµε την πηγή της πληροφορίας. 70 d. Tι είναι το URD (Unified Resource Description). 71 e. Tο URD ΑPI (API Application Protocol Interface) Υλοποίηση του Χρονοδροµολογητή. 75 Κεφάλαιο 8: Περιγραφή ιαµεσολαβητή POP Εισαγωγή H Αρχιτεκτονική του ιαµεσολαβητή. 80 a. Περιγραφή Ευρετηρίου Αποµνηµόνευσης. 81 b. Περιγραφή Λειτουργίας. 82 VI

9 8.3 Υλοποίηση του ιαµεσολαβητή. 84 a. Ενδο-επικοινωνία εδοµένων. 85 b. Τρόπος Μεταγωγής εδοµένων στις εξωτερικές οντότητες Αλγόριθµοι ανάκτησης και τοποθέτησης δεδοµένων στη Cache. 86 Κεφάλαιο 9: Περιγραφή ιαµεσολαβητή HTTP Εισαγωγή H Αρχιτεκτονική του ιαµεσολαβητή. 89 a. Περιγραφή Ευρετηρίου Αποµνηµόνευσης. 89 b. Περιγραφή Λειτουργίας Υλοποίηση του ιαµεσολαβητή. 95 a. Eνδο-επικοινωνία εδοµένων. 97 b. Μεταγωγή εδοµένων στις εξωτερικές οντότητες. 97 c. Αλγόριθµοι ανάκτησης και τοποθέτησης δεδοµένων. 97 Κεφάλαιο 10: Περιγραφή ιαµεσολαβητή NNTP Εισαγωγή H Αρχιτεκτονική του ιαµεσολαβητή 100 a. Περιγραφή Ευρετηρίου Αποµνηµόνευσης 103 b. Περιγραφή Λειτουργίας Υλοποίηση του ιαµεσολαβητή. 105 a. Eνδο-επικοινωνία εδοµένων. 106 b. Μεταγωγή εδοµένων στις εξωτερικές οντότητες. 107 c. Αλγόριθµοι ανάκτησης και τοποθέτησης δεδοµένων. 107 Κεφάλαιο 11: Περιγραφή Σχολιασµού Κρυφής Μνήµης Εισαγωγή Απαιτήσεις της Σχολιασµού Κρυφής Μνήµης Το ACI Definition for Gathered Information. 112 a. Γενική Περιγραφή. 112 b. Πως αντικατοπτρίζει τις Απαιτήσεις. 113 VII

10 c. O ορισµός του ACI Definition for Gathered Information. 114 d. Elements Vs Attributes. 114 e. Η συσχέτιση του ACI µε το URD. 115 f. Η συσχέτιση του ACI µε τους Proxy Servers. 116 g. Πως χρησιµεύει το ACI Definition στο σύστηµα. 117 h. Το ACI ΑPI (API Application Protocol Interface) Υλοποίηση της Annotation Cache. 119 a. Περιγραφή Λειτουργικότητας. 119 b. Ενδο-επικοινωνία εδοµένων. 120 c. Μεταγωγή εδοµένων στις εξωτερικές οντότητες. 121 d. Αλγόριθµοι ανάκτησης και τοποθέτησης δεδοµένων. 121 Κεφάλαιο 12: Ενηµέρωση του Χρήστη Εξυπηρετητής Ενηµέρωσης Εισαγωγή Η ενηµέρωση µέσω της Ιστοσελίδας Η ενηµέρωση µε µηνύµατα SMS Η ενηµέρωση µέσω Ηλεκτρονικού Ταχυδροµείου Eξυπηρετητής Ενηµέρωσης (Alerter). 137 Κεφάλαιο 13: Συµπεράσµατα Προβλήµατα Συµπεράσµατα Μελλοντική Έρευνα 142 Βιβλιογραφία Παράρτηµα Α: Γραµµατικές στην XML... Α-1 Παράρτηµα B: Κώδικας Πρωτοτύπου... Α-2 VIII

11 Κεφάλαιο 1 Εισαγωγή 1.1 Παρακίνηση H Γλώσσα Προγραµµατισµού Java H Τεχνολογία Κινητών Πρακτόρων H Τεχνολογία Περιγραφής εδοµένων XML Τεχνικές Ανάκτησης και Φιλτραρίσµατος Πληροφοριών Παρακίνηση Το Παγκόσµιο Πλέγµα Πληροφοριών (ΠΠΠ - WWW), είναι µια σηµαντική πηγή υπηρεσιών και πληροφοριών για µια µεγάλη κλίµακα θεµάτων. Όµως, η τεράστια, αδόµητη, ποικιλόµορφη και δυναµική φύση του ΠΠΠ καθώς επίσης η αδυναµία της γλώσσας HTML (HyperText Markup Language) να εκφράσει σηµασιολογικές πληροφορίες των περιεχοµένων ενός υπερκειµένου [GRRS], δηµιουργούν προβλήµατα στη διαδικασία συλλογής και εκτίµησης τέτοιων πληροφοριών. Η τεχνολογία των έξυπνων κινητών πρακτόρων [WP98] διαφαίνεται ότι προσφέρει τη δυνατότητα ανάπτυξης συστηµάτων χαµηλού κόστους για την αποδοτική συλλογή και ευφυή επεξεργασία πληροφοριών που υπάρχουν στο ιαδικτύου. Περαιτέρω η γλώσσα περιρραφής δεδοµένων XML µας δίδει την ευκαιρία να κωδικοποιήσουµε σηµασιολογικά τις διάφορες πηγές πληροφοριών. Αυτή την δυνατότητα θέλουµε να διερευνήσουµε. -1-

12 1.2 Η Γλώσσα Προγραµµατισµού Java. Η γλώσσα προγραµµατισµού Java [GM00] αναπτύχθηκε από την Sun Microsystems Inc. δόθηκε για χρήση από το ΗίδιαηSun χαρακτηρίζει την Java ως απλή, αντικειµενοστρεφή, κατανεµηµένη, µεταφραζόµενη, ανθεκτική, ασφαλή, ανεξάρτητη αρχιτεκτονικής υπολογιστών, µεταφερόµενη, υψηλής απόδοσης, πολυνηµατική και δυναµική γλώσσα [SunOv00]. Η επιτυχία της Java οφείλεται σε πολλά πλεονεκτήµατα που την διακρίνουν και ιδιαιτέρως σε αυτό της φορητότητας [FM00]. ηλαδή κώδικας σε Java γραµµένος σε µια συγκεκριµένη αρχιτεκτονική ή λειτουργικό σύστηµα µπορεί να εκτελεστεί χωρίς καµία αλλαγή σε οποιαδήποτε άλλη µηχανή. Αυτό γίνεται εφικτό µε τη χρήση της Εικονικής Μηχανής Java (Java Virtual Machine - JVM). Η JVM είναι ένα πρόγραµµα που εκτελείται σε κάποιο υπολογιστή και είναι γραµµένο για τη συγκεκριµένη αρχιτεκτονική και λειτουργικό σύστηµα του υπολογιστή αυτού. Το πρόγραµµα αυτό προσοµοιώνει µια ιδεατή µηχανή που τρέχει σε γλώσσα Java [Σχήµα 1.1]. Η διαδικασία για το τρέξιµο ενός προγράµµατος σε Java έχει ως εξής. Αρχικά ο κώδικας µεταγλωττίζεται και µετατρέπεται σε µορφή bytecode αντί σε γλώσσα µηχανής. To bytecode είναι κώδικας σε δυαδική µορφή και είναι ανεξάρτητος πλατφόρµας [Web96]. Το bytecode ενός προγράµµατος φορτώνεται στη συνέχεια στην ιδεατή µηχανή η οποία το µεταφράζει στην γλώσσα µηχανής του ηλεκτρονικού υπολογιστή στην οποία είναι εγκατεστηµένη και ο κώδικας εκτελείται [Σχήµα 1.2]. Αυτή η διαδικασία βέβαια συνεπάγεται κάποια καθυστέρηση. ίνει όµως το πλεονέκτηµα της εκτέλεσης προγραµµάτων ακόµη και σε µικρές φορητές µηχανές που τρέχουν λειτουργικό σύστηµα βασισµένο στη Java [Com98]. Άλλα πλεονεκτήµατα της Java είναι η δυνατότητα ανάπτυξης µικρών προγραµµάτων που τρέχουν µέσα από το περιβάλλον ενός φυλλοµετρητή. Τα προγράµµατα αυτά ονοµάζονται Applets. -2-

13 Java Applications Java Virtual Machine Java Code Java Compiler Solaris Windows MacOS JavaOS Java Bytecode Java Interpreter on a Java Virtual Machine SPARC/ Intel Intel/ Others PowerPC Thin Clients Machine Language Σχήµα 1.1: Η Πλατφόρµα της Java Σχήµα 1.2 : ιαδικασία εκτέλεσης ενός Java προγράµµατος 1.4 H Τεχνολογία Κινητών Πρακτόρων. Οι Πράκτορες (Agents) είναι ένα νέο υπολογιστικό παράδειγµα (paradigm) για την ανάπτυξη κατανεµηµένων συστηµάτων [Hor98]. Πρόκειται για ανεξάρτητα λογισµικά προγράµµατα που βρίσκονται σε κάποιο κόµβο του ιαδικτύου και εκτελούν κάποια εργασία εκ µέρους του χρήστη, χωρίς να υπάρχει άµεση αλληλεπίδραση µε αυτόν [CH98]. Οι Κινητοί Πράκτορες (Mobile Agents) είναι εξειδικευµένη µορφή πρακτόρων οι οποίοι έχουν τη δυνατότητα να ταξιδεύουν σε διάφορα σηµεία του δικτύου για να εκτελέσουν τον κώδικά τους ή να βρουν πληροφορίες εκ µέρους του χρήστη [Hor98]. Συστήµατα κινητών πρακτόρων έχουν τα εξής βασικά πλεονεκτήµατα [Hor98]: Συντείνουν στη δηµιουργία προγραµµάτων υψηλής ποιότητας, υψηλής απόδοσης και χαµηλού κόστους. Επιτρέπουν τη χρησιµοποίηση φορητών, προσωπικών συσκευών επικοινωνίας [Com98]. Επιτρέπουν την ασφαλή επικοινωνία σε δηµόσια δίκτυα ( ιαδίκτυο). Χρησιµοποιούν αποδοτικά και οικονοµικά δίκτυα µικρού εύρου ζώνης, υψηλής χρονικής καθυστέρησης, και κακών γραµµών επικοινωνίας -3-

14 Σήµερα υπάρχουν διάφορα πακέτα ανάπτυξης συστηµάτων κινητών πρακτόρων. Τα πακέτα αυτά έχουν αρκετές οµοιότητες και κοινά χαρακτηριστικά, αλλά συνήθως διαφέρουν στον τρόπο υλοποίησής τους, παρόλο που αρκετά έχουν σαν βάση τους τη γλώσσα Java [KZ97]. Στην εργασία αυτή θα χρησιµοποιήσουµε το πακέτο κινητών πρακτόρων της Mitsubishi Electric ITA, το οποίο ονοµάζεται Concordia [WPW97]. Αναλυτική περιγραφή της τεχνολογίας αυτής ακολουθεί στο κεφάλαιο 4 Concordia. 1.4 Η τεχνολογία περιγραφής δεδοµένων XML H XML [BPS98] είναι µια µέτα-γλώσσα σήµανσης που δηµιουργήθηκε για να εξυπηρετήσει τις ανάγκες του ιαδίκτυο. εν είναι µια προκαθορισµένη γλώσσα σήµανσης όπως είναι η HTML (Hypertext Markup Language). Αντίθετα είναι µια γλώσσα µε την οποία µπορούµε να ορίσουµε άλλες γλώσσες σήµανσης [Brad98]. Η XML δίνει νέες δυνατότητες στην ανάπτυξη αυτοµατοποιηµένων συστηµάτων πρακτόρων, αφού η πληροφορία κωδικοποιείται σηµασιολογικά και όχι µορφολογικά [TM99] και συνεπώς γίνεται αντιληπτή από τους πράκτορες. Το γεγονός αυτό δηµιουργεί νέες προοπτικές στην ανάπτυξη αυτοµατοποιηµένων συστηµάτων ανταλλαγής πληροφοριών [Biz99]. Αναλυτική περιγραφή της τεχνολογίας αυτής ακολουθεί στο κεφάλαιο 2 XML. 1.5 Τεχνικές Ανάκτησης και Φιλτραρίσµατος Πληροφοριών Το ΠΠΠ είναι µια απέραντη πηγή πληροφοριών. Για την εύρεση πληροφοριών σχετικά µε ένα συγκεκριµένο θέµα, ο χρήστης θα πρέπει να περιηγηθεί στον κυβερνοχώρο, µέχρι να βρεί τέτοιες πληροφορίες, να τις αξιολογήσει ανάλογα µε το περιεχόµενο τους και να τις φυλάξει είτε σε ηλεκτρονική µορφή είτε να τις εκτυπώσει σε χαρτί. Η διαδικασία αυτή έχει πολλούς περιορισµούς [YA95] : Υπάρχει ανεπαρκής υποστήριξη µοντελοποίησης του πληροφοριακού χώρου. Η διαδικασιακή αναζήτησης των πληροφοριών είναι σειριακή και χειρωνακτική και άρα πολύ χρονοβόρα. Ο συνδυασµός των πληροφοριών είναι πολύ δύσκολος. -4-

15 Υπάρχει ανεπαρκής υποστήριξη αρχειοθέτησης των ανευρεθέντων πληροφοριών. Εξάλλου το ΠΠΠ είναι τεράστιο και αδόµητο και είναι αδύνατο να περιηγηθεί κανείς σε όλες τις πληροφορίες που προσφέρει. Επιπλέον, πολλές πληροφορίες που υπάρχουν σε αυτό είναι επαναλαµβανόµενες, συχνά λανθασµένες και χαµηλής ποιότητας [Li98]. Για την αντιµετώπιση των πιο πάνω περιορισµών εµφανίστηκαν διάφορες µηχανές αναζήτησης [Liv98], ο οποίες χρησιµοποιούν λογισµικά προγράµµατα γνωστά σαν Crawlers, Spiders, Robots ή Agents, που επισκέπτονται σελίδες του ιαδικτύου, αναλύουν το περιεχόµενό τους και κατασκευάζουν ένα πίνακα δεικτοδότησης (indexing) ή ένα σύστηµα εκτίµησης της σχετικότητάς µε τις λέξεις που το αποτελούν. Και πάλι όµως τα συστήµατα αυτά έχουν προβλήµατα όπως [GRRS]: Πολλά άσχετα κείµενα εµφανίζονται ως αποτέλεσµα µιας αναζήτησης. εν καλύπτεται ολόκληρο το σύνολο πληροφοριών του ΠΠΠ. Οι εκφράσεις αναζήτησης που δηλώνει ο χρήστης είναι βασισµένες µόνο σε αναζητήσεις βάσει συγκεκριµένων λέξεων, πράγµα που δεν προσφέρει ευελιξία και δυνατότητα για πιο περίπλοκες αναζητήσεις. Υπάρχει περιορισµένη προσαρµογή στα εξειδικευµένα ενδιαφέροντα του χρήστη. Χρειάζεται έτσι η δηµιουργία συστηµάτων που να προσαρµόζονται στις εξειδικευµένες ανάγκες των χρηστών και να προσφέρουν αυτοµατοποιηµένες διαδικασίες αναζήτησης, ανάληψης, φιλτραρίσµατος και αποθήκευσης των πληροφοριών, ακόµη και όταν ο χρήστης δεν είναι ενωµένος µε αυτά τα συστήµατα τα οποία να είναι σε θέση να οµαδοποιούν τις πληροφορίες που καταφθάνουν στο χρήστη και να τον διευκολύνουν στη διαδικασία φύλαξής τους [KRW96]. Συστήµατα µε δυναµικές εκφράσεις αναζήτησης [YA95] και δυναµική ενηµέρωση του χρήστη για νέες πληροφορίες στον κυβερνοχώρο [YGM95]. -5-

16 Για την επίτευξη των πιο πάνω στόχων, ο σχεδιαστής συστηµάτων αυτής της µορφής πρέπει να ασχοληθεί µε αρκετά θέµατα. Πρώτο θέµα είναι αυτό της δηµιουργίας ενός Profile µε τα ενδιαφέροντα του χρήστη. Υπάρχουν πολλοί τρόποι και πολλές µορφές µε τις οποίες µπορεί να κατασκευαστεί ένα Profile [HMSC97, CFG99, YGM95, KRW96]. Η πιο απλή µορφή είναι η διανυσµατική παρουσίαση των ενδιαφερόντων ενός χρήστη στην οποία ένα Profile εκφράζεται ως ένα διάνυσµα D = <(t i,w i ),, (t k,w k )> (πχ <(mobile,40), (agents,60)>) όπου t i είναι µία λέξη κλειδί και w i το βάρος που της ορίζει ο χρήστης. εύτερο θέµα είναι αυτό της ευφυούς ανάκτησης και φιλτραρίσµατος των πληροφοριών [YGM95, PS98, Sund98]. Αυτό γίνεται µε βάση το Profile των χρηστών, έτσι όσο πιο εκφραστικό είναι αυτό, τόσο πιο ακριβή είναι τα αποτελέσµατα. Η τεχνολογία των κινητών πρακτόρων προσφέρει αυξηµένη ευελιξία πάνω σε αυτά τα θέµατα µε πολλές δυνατότητες και πλεονεκτήµατα, όπως τη δυνατότητα συνεργασίας µεταξύ πρακτόρων για καλύτερο συνδυασµό των πληροφοριών [CKPW98, WP98]. Τέλος, σηµαντικό είναι το θέµα της αποθήκευσης των πληροφοριών. Οι πληροφορίες που µαζεύονται φυλάγονται συνήθως σε µια προσωρινή δευτερεύουσα µνήµη [YA95, KRW96, YGM95]. Στη συνέχεια παρουσιάζονται στο χρήστη και αυτός αποφασίζει για τον τρόπο και την ακριβή τοποθεσία της φύλαξής τους. -6-

17 Κεφάλαιο 2 H XML (extensible Markup Language) 2.1 Τι είναι η ΧΜL ιαφορές της ΧΜL µε γλώσσες προγραµµατισµού ιαφορές της ΧΜL µε την ΗΤΜL Περιγραφή τεχνικών όρων της XML Μορφοποίηση XML µε CSS και XSL Τι είναι ένας Parser Τι είναι το DOM και το DOM API Τι είναι το SAX και το SAX API Επιλογή µεταξύ SAX και DOM Κριτήρια επιλογής κατάλληλου Parser Τι είναι η XML XML είναι η extensible Markup Language, και είναι προϊόν της οµάδας εργασίας, του WWW Consortium, για την ανάπτυξη της SGML ΙSO8879 (Standard Generalized Markup Language). H SGML προσφέρει ένα ευρύ σύνολο χαρακτηριστικών µε το οποίο µπορούµε να περιγράψουµε οποιοδήποτε γραµµατική σήµανσης (markup). HSGMLείναι το διεθνές πρότυπο για τον ορισµό των περιγράφων των δοµών δεδοµένων και του περιεχοµένου διαφορετικού τύπου ηλεκτρονικών έγγραφων. Η δυσκολία ανάπτυξης γραµµατικών στην SGML λόγω της πολυπλοκότητας της οδήγησε το SGML Working Group στον ορισµό της ΧΜL Η XML είναι ένα απλοποιηµένο υποσύνολο της SGML, το οποίο έχει σχεδιαστεί αποκλειστικά για εφαρµογές ΠΠΠ. ιατηρεί τα στοιχεία της επεκτασιµότητας, της -7-

18 δοµής και της επικυροσιµότητας της SGML της, ενώ ταυτόχρονα είναι πιο εύκολη στην χρήση και στην εκµάθηση απ ότι η SGML. HXMLδεν είναι µια προκαθορισµένη γλώσσα σήµανσης όπως είναι η HTML (Hypertext Markup Language), αλλά µια µέτα-γλώσσα σήµανσης. ηλαδή είναι µια γλώσσα µε την οποία µπορούµε να ορίσουµε και να επεκτείνουµε άλλες γλώσσες σήµανσης. Για αυτό ακριβώς τον λόγω χαρακτηρίζεται επεκτάσιµη. Με την XML ορίζονται σήµερα πολλές γλώσσες σήµανσης οι οποίες χρησιµοποιούνται ή αναµένεται να χρησιµοποιηθούν σε ευρεία κλίµακα. Παραδείγµατα αποτελούν η SMIL [Ηos98] (Synchronized Multimedia Integration Language), η οποία χρησιµοποιείται για την σήµανση εφαρµογών πολυµέσων στο ιαδίκτυου, η XHTML [Xhtml00] (extensible Hypertext Markup Language), η οποία αναµένεται να αντικαταστήσει τον ρόλο της HTML, για την µορφοποίηση ηλεκτρονικών εγγράφων, και η οποία εκτός των αυστηρών περιορισµών στην επικυροσιµότητα (validation) και ορθότητα (well form ness) ενός υπερκείµενου προσφέρει και την επεκτασιµότητα (extensibility) των υπάρχουσων σηµαντήρων µε νέα ιδιοχαρακτηριστικά καθώς επίσης την εισαγωγή νέων σηµαντήρων. 2.2 ιαφορές της ΧΜL µε γλώσσες προγραµµατισµού Στις γλώσσες προγραµµατισµού όπως είναι για παράδειγµα η C, C++, Java, Pascal, Basic προσφέρονται εντολές και µεθόδοι για τον καθορισµό διάφορων υπολογιστικών διαδικασιών, ενεργειών και αποφάσεων. Για παράδειγµα στο σχήµα 1 δείχνουµε µε ψευδό-κώδικα κάποιο παράδειγµα γλώσσας προγραµµατισµού. Μια γλώσσα προγραµµατισµού µας προσφέρει διάφορες µεθόδους (π.χ Array,variables,loops) για την επεξεργασία δεδοµένων Array X; X[0]:= Christos ; Y[0]:= Cyprus X[1]:= Marios ; Y[1]:= US Print_on_screen ( Students of Universities: ) For (I=0; I < X.length(); I++) Print_on_screen( Student : + I + X[I] +, University: + Y[I]) Figure 1: Παράδειγµα γλώσσας Προγραµµατισµού -8-

19 Σε αντίθεση µε τις γλώσσες προγραµµατισµού η XML ήηsgml είναι γλώσσες ορισµού σήµανσης (markup specification languages), µε τις οποίες µπορεί κάποιος να περιγράψει τα δεδοµένα. Οι περιγραφές αυτές µπορεί να χρησιµοποιηθούν για αποθήκευση, µετάδοση ή επεξεργασία των δεδοµένων από κάποιο πρόγραµµα. Στο σχήµα 2 φαίνεται ένα απλό παράδειγµα XML αρχείου. Το αρχείο αυτό δεν κάνει τίποτα από µόνο του, αλλά θα µπορούσε να χρησιµοποιηθεί από κάποιο πρόγραµµα (π.χ φυλλοµετρητή, επεξεργαστή δεδοµένων ή άλλο) για να κάνει κάτι µε αυτά τα δεδοµένα. <?xml version= 1.0?> <students type= students title= Students of Universities > <singlename> <name>christos</name> <university>cyprus</university> </singlename> <singlename> <name>marios</name> <university> US </university> </singlename> </ students> Figure 2: Απλό Παράδειγµα αρχείου ΧΜL 2.3 ιαφορές της ΧΜL µε την HTML Η HTML (HyperText Markup Language), είναι µια µορφολογική γλώσσα, η οποία έχει σχεδιαστεί µε τρείς βασικούς σκοπούς [Dik99]. 1. Τη στοιχειοθέτηση (µορφοποίηση-formatting) ηλεκτρονικών κειµένων. 2. Την αναµετάδοση τους στο ιαδίκτυου 3. Την αναπαράσταση των κειµένων σε διαφορετικές οθόνες. Περαιτέρω η πληροφορία η οποία µεταδίδεται µε την HTML είναι format-oriented, κάνοντας την έτσι κατανοητή από το ανθρώπινο µάτι. [TM99]. Με αυτό τον τρόπο προγράµµατα πρακτόρων (software agents) και µηχανές αναζήτησης (search engines), έχουν δυσκολία αναγνώρισης της πληροφορίας γιατί αυτή δεν είναι κωδικοποιηµένη σηµασιολογικά αλλά µορφολογικά. <HTML> -9-

20 <BODY> <H1>Students of Universities</H1> <P>Student 1 : Christos, University : Cyprus</P> <P>Student 2 : Marios, University : US </P> </BODY> </HTML> Figure 3: Απλό Παράδειγµα αρχείου HTML Σε αντίθεση η XML (σχήµα 2) επικεντρώνεται στην σηµασιολογική κωδικοποίηση των δεδοµένων. Η XML προσφέρει επίσης, σε αντίθεση µε την HTML [Dik99]: 1. Επεκτασιµότητα (extensibility). Οι χρήστες της HTML δεν µπορούν να καθορίζουν σηµαντήρες ή ιδιοστοιχεία σηµαντήρων της αρεσκείας τους, ώστε να παραµετροποιούν ή να περιγράφουν την σηµασιολογία των δεδοµένων τους. 2. οµή (structure). Η HTML δεν υποστηρίζει τον καθορισµό βαθέων ιεραρχικών δοµών που απαιτούνται στην αναπαράσταση σχηµάτων Βάσεων εδοµένων ή Αντικειµενοστρεφών ιεραρχιών 3. Επικυροσιµότητας (validation). Η HTML δεν υποστηρίζει την ύπαρξη γλωσσικών ορισµών (language specifications), οι οποίοι να επιτρέπουν σε εφαρµογές που δέχονται στην είσοδο τους HTML τον έλεγχο της δοµικής εγκυρότητας των δεδοµένων 2.4 Περιγραφή τεχνικών όρων της XML Τα κείµενα XML έχουν αυστηρή ιεραρχική δοµή. Κάθε αρχικός σηµαντήρας πρέπει να συνοδεύεται από τον αντίστοιχο καταληκτικό σηµαντήρα. Τα ζεύγη αρχικών και καταληκτικών σηµαντήρων αποκαλούνται στοιχεία Elements (σχήµα 4). <name>christos</name> Figure 4: Παράδειγµα ενός Element Ιδιοχαρακτηριστικό (Attribute), ενός στοιχείου χαρακτηρίζεται συνήθως η πληροφορία η οποία χαρακτηρίζει µια άλλη πληροφορία. Για παράδειγµα στο σχήµα 5-10-

21 η πληροφορία φοιτητής χαρακτηρίζεται από ένα όνοµα (name) και ένα επίθετο (surname). Αυτή η πληροφορία λέγεται αλλιώς meta-data [Brad98]. <student name= Christos surname= Christou >787748</student> Figure 5: Παράδειγµα ιδιοχαρακτηριστικών (Attribute) Κόµβος (Node), αποκαλείται οποιονδήποτε µέρος του XML αρχείου περιέχει δεδοµένα. Στην πιο γενική περίπτωση, κόµβος µπορεί να ονοµαστεί ολόκληρη η XML δοµή δεδοµένων. Τα Elements και τα Attributes αποτελούν επίσης Nodes. Ετσι τα Nodes είναι υπερσύνολο των Elements και των Attributes. Στο σχήµα 6 φαίνεται µε έντονους χαρακτήρες τρείς διάφοροι τύποι κόµβων Nodes. 1. <student name= Christos surname= Christou >787748</student> 2. <student name= Christos surname= Christou >787748</student> 3. <student> <name>christos</name> <surname>christou</surname> </student> Figure 6: Παράδειγµα κόµβων (Nodes) DTD (Document Type Definition), αποτελεί την γραµµατική που περιγράφει τους σηµαντήρες και τα ιδιοχαρακτηριστικά, τα οποία επιτρέπεται να χρησιµοποιηθούν σε ένα κείµενο XML, όπως επίσης τα συµφραζόµενα στα οποία επιτρέπεται η χρήση τους [Dik99]. Ένα DTD µπορεί να είναι εσωτερικό (δηλαδή να συνυπάρχει µε τα XML δεδοµένα στο ίδιο αρχείο), εξωτερικό να είναι σε διαφορετικό αρχείο από τα XML δεδοµένα ή τέλος µπορεί να παραληφθεί εντελώς. Πιο κάτω (σχήµα 7) φαίνεται (µε έντονα γράµµατα) ένα παράδειγµα ενός εσωτερικού DTD. Εξωτερικά DTD είναι καλά να χρησιµοποιούνται όταν έχουµε πολλά XML αρχεία που ακολουθούν το ίδιο DTD. -11-

22 <?xml version='1.0'?> <!DOCTYPE student [ <!ELEMENT student (singlename)*> <!ELEMENT singlename (name,university)> <!ELEMENT name (#PCDATA)> <!ELEMENT university (#PCDATA)> ]> <student> <singlename> <name>christos</name> <university>cyprus</university> </singlename> </student> Figure 7: Παράδειγµα εσωτερικού DTD Συντακτική ορθότητα και Επικυροσιµότητα Ένα οποιανδήποτε XML αρχείο µπορεί να θεωρηθεί σαν συντακτικά ορθό (wellformed) αν ακολουθεί όλους τους συντακτικούς κανόνες όπως αυτοί ορίζονται από την XML. Μερικοί συντακτικοί κανόνες της XML είναι 1. Στα XML αρχεία επιτρέπεται µόνο ένα στοιχείο ρίζας (root element) 2. Οι σηµαντήρες της XML είναι ευαίσθητοι στην χρήση κεφαλαίων-µικρών γραµµάτων (case-sensitive) 3. Οι τιµές των ιδιοχαρακτηριστικών της XML πρέπει να συµπεριλαµβάνονται µεταξύ απλών ή διπλών εισαγωγικών. 4. Οι σηµαντήρες της XML δεν µπορούν να τέµνονται. Για παράδειγµα δεν επιτρέπεται να γράψουµε <name><surname></name></surname> Όλοι οι συντακτικοί κανόνες της XML µπορούν να βρεθούν στο ορισµό (specification) της XML [BSP98] Ένα XML αρχείο µπορεί να θεωρηθεί σαν έγκυρο (valid) αν ακολουθεί όλους τους γραµµατικούς κανόνες όπως αυτοί ορίζονται µέσα στο DTD. Ετσι για παράδειγµα η πιο κάτω γραµµατική (σχήµα 8) είναι συντακτικά ορθή αλλά όχι και έγκυρη γιατί έγινε παράληψη του σηµαντήρα name. -12-

23 <?xml version='1.0'?> <!DOCTYPE student [ <!ELEMENT student (singlename)*> <!ELEMENT singlename (name,university)> <!ELEMENT name (#PCDATA)> <!ELEMENT university (#PCDATA)> ]> <student> <singlename> <university>cyprus</university> </singlename> </student> Figure 8: Παράδειγµα well-formed αλλά όχι valid XML αρχείου Well-Formed Valid 2.5 Μορφοποίηση XML µε CSS και XSL Σηµαντικό είναι να αναφέρουµε ότι η XML άρχισε σήµερα να χρησιµοποιείται σε ευρεία κλίµακα για την µετάδοση ηλεκτρονικών αρχείων µέσω του ιαδικτύου. Βέβαια για να µπορέσει κάποιος φυλλοµετρητή να µορφοποιήσει τα XML δεδοµένα τα οποία δέχεται χρειάζεται διάφορες πληροφορίες για να γνωρίζει πως διατάξει τα δεδοµένα αυτά στην οθόνη. Για αυτό τον σκοπό υπάρχουν σήµερα διάφορες τεχνολογίες. Μέσα στις τεχνολογίες αυτές περιλαµβάνονται η χρήση των CSS (Cascading Style Sheets) [WB96] και η χρήση της XSL (extensible Stylesheet Language) [Adl00]. ιάφοροι εµπορικοί φυλλοµετρητές όπως για παράδειγµα: 1. Microsoft Internet Explorer v5.0 [ MIE99] 2. AOL Netscape Navigator PR1 v6.0 [NN00] 3. Opera v4.0 beta 4 [Oper00] 4. Citec DocZilla v1.0 [Cit99] υλοποιούνε σήµερα, άλλοι περισσότερο και άλλοι λιγότερο, τις συστάσεις της W3C [W3C], αναφορικά µε την χρήση των τεχνολογιών αυτών. Στο σχήµα 10 ορίζουµε ένα CSS, το οποίο θα χαρακτηρίζει µορφολογικά την XML γραµµατική του σχήµατος 9. Με αυτό το CSS ο φυλλοµετρητής να µπορεί να µορφοποιήσει το XML αρχείο. students.xml -13-

24 <?xml version='1.0'?> <?xml:stylesheet type="text/css" href="students.css"?> <students type="students" title=" Students of Universities "> <singlename> <name>christos</name> <university>cyprus</university> </singlename> <singlename> <name>marios</name> <university> US </university> </singlename> </ students > Figure 9: Παράδειγµα του XML αρχείου που κάνει χρήση του students.css students.css name { font-family: verdana, arial; font-size: 15pt; font-weight:bold; display: block; margin-bottom: 5pt; } university { font-family: verdana, arial; font-size: 12pt; font-weight:bold; color:green; display:block; margin-bottom: 20pt; margin-top: 40pt; } Figure 10: Παράδειγµα του CSS αρχείου To πιο πάνω παράδειγµα θα παρουσιάσει στον φυλλοµετρητή στην πιο κάτω µορφή Christos Cyprus Marios US Figure 11: Παρουσίαση στον Φυλλοµετρητή (IΕ5.0, Netscape 6.0, DocZilla 1.0) Το µειονέκτηµα µε τα CSS είναι ότι δεν µπορούµε να κάνουµε περίπλοκες µορφοποιήσεις αφού το µόνο που µπορούµε να κάνουµε είναι να δίνουµε χαρακτηριστικά (π.χ χρώµα, γραµµατοσειρά, µέγεθος) στους σηµαντήρες. Ετσι δεν µπορούµε να παρουσιάσουµε µε διαφορετική σειρά τα XML δεδοµένα στην οθόνη -14-

25 αλλά ούτε και να κάνουµε επιλεκτικές παρουσιάσεις των δεδοµένων (π.χ να παρουσιάσουµε όλους τους φοιτητές από την χώρα US ). Για τον σκοπό αυτό µπορεί να γίνει χρήση της XSL που είναι µια γλώσσα µορφοποίησης XML δεδοµένων. Πιο κάτω παρουσιάζεται το παράδειγµα που είχαµε χρησιµοποιήσει πιο πάνω µε τους φοιτητές students.xml <?xml version='1.0'?> <?xml:stylesheet type="text/xsl" href="students.xsl"?> <students type="students" title=" Students of Universities "> <singlename> <name>christos</name> <university>cyprus</university> </singlename> <singlename> <name>marios</name> <university> US </university> </singlename> </ students > Figure 12 : Παράδειγµα του XML αρχείου που κάνει χρήση του students.xsl students.xsl <?xml version='1.0'?> <xsl:stylesheet xmlns:xsl= xmlns= result-ns=""> <!-- default rule --> <xsl:template><xsl:apply-templates/></xsl:template> <!-- root rule --> <xsl:template match="/"> <!-- Build the HTML page --> <html> <head><title>students of Universities</title></head> <body> <H3>Students</H3> <!-- This template selects all the name elements --> <xsl:apply-templates select="/allnames/singlename/name"/> <H3>Universities</H3> <!-- This template selects all the university elements --> <xsl:apply-templates select="/allnames/singlename/university"/> </body> </html> </xsl:template> <! Give formatting Attributes to name Elements --> <xsl:template match="name"> <font face="vernada" size="12"> <xsl:value-of/> <!-- insert the element content --> </font><br/> </xsl:template> <! Give formatting Attributes to university Elements --> <xsl:template match="university"> <font face="arial" size="10" color="green"> -15-

26 <xsl:value-of/> <!-- insert the element content --> </font><br/> </xsl:template> </xsl:stylesheet> Figure 3 : Το XSL students.xsl Figure 3 : Παρουσίαση στον Φυλλοµετρητή ( Internet Explorer 5) Για να µπορέσουµε να δούµε τα πιο πάνω δεδοµένα σε οποιονδήποτε φυλλοµετρητή, πρέπει να τα µετατρέπουµε στον εξυπηρετητή τα δεδοµένα σε HTML (server site). Στην υλοποίηση αυτής της ιπλωµατικής εργασίας δεν έγινε ωστόσο χρήση καµίας από τις πιο πάνω τεχνολογίες (CSS, XSL) γιατί κρίθηκε ότι δεν θα µας παρείχαν τις δυνατότητες, τις οποίες επιθυµούσαµε. Για παράδειγµα θα ήταν δύσκολο να επεξεργαστούµε και να µορφοποιήσουµε ταυτόχρονα XML δεδοµένα από 2 διαφορετικά XML αρχεία µε την χρήση CSS ή XSL. Επίσης αυτές οι 2 τεχνολογίες δεν είναι αρκετά εξαπλωµένες και ώριµες και για αυτό δεν είναι και συµβατές µε τους περισσότερους φυλλοµετρητές. Στην υλοποίηση του συστήµατος, έχουµε χρησιµοποιήσει την τεχνολογία των Servlets µε την οποία µορφοποιούµε τα δεδοµένα σε HTML σελίδες στον εξυπηρετητή ΠΠΠ. -16-

27 2.6 Τι είναι ένας XML Parser XML parser είναι ένα κοµµάτι λογισµικού το οποίο µας δίδει πρόσβαση σε ένα XML αρχείο. Ετσι αν για παράδειγµα έχουµε ένα XML αρχείο και θέλουµε να διαβάσουµε τα περιεχόµενα αυτού του αρχείου, θα µπορούσαµε να γράψουµε ένα αναγνώστη του text αρχείου (text file reader), ο οποίος διερµηνεύει (interprets) τις πληροφορίες τις οποίες βρίσκει µέσα στο XML αρχείο κατα τέτοιο τρόπο που να είναι χρήσιµα στο πρόγραµµα µας. ηλαδή µπορεί να τοποθετεί τα XML δεδοµένα σε δοµές δεδοµένων ή µεταβλητές που να προσβάσιµα από το πρόγραµµα µας. Ωστόσο η διαδικασία αυτή είναι πολύ χρονοβόρα αφού πρέπει κάθε φορά που ορίζουµε ένα XML αρχείο να ορίζουµε επίσης ένα δικό µας parser. Για αυτό τον σκοπό η W3C [W3C] δηµιούργησε ένα πρότυπο πάνω στο οποίο θα µπορούσαν διάφοροι κατασκευαστές να αναπτύξουν υλοποιήσεις των parsers τους. Υλοποιήσεις των parsers υπάρχουν σχεδόν για όλες τις πλατφόρµες και σχεδόν για κάθε γλώσσα προγραµµατισµού [Par00]. Ενδεικτικά αναφέρουµε µερικούς Java XML Parsers: 1. XML Parser της SUN (Sun Project X TR1) 2. XML Parser της IBM (IBM XMLP4J) 3. XML Parser της Datachannel / Microsoft (XJParser) Υπάρχουν 2 ειδών XML Parsers. 1. DOM (Document Object Model) Parsers 2. SAX (Simple API for XML) Parsers 2.7 Τι είναι το DOM (Document Object Model) και το DOM API To DOM API έχει οριστεί από την W3C τον Οκτώβριο του Τότε είχε οριστεί σαν DOM Level 1 Specification [DOM198]. Τώρα βρίσκεται σε εξέλιξη η προτυποποίηση του στο DOM Level 3 Specification [DOM300]. Το DOM2 και DOM3 προσφέρουν ένα πιο πλούσιο σύνολο µεθόδων για ανάκτηση και προθήκη πληροφοριών -17-

28 από και σε ένα XML αρχείο, από το DOM1, αλλά δεν έχουν υλοποιηθεί ακόµα σε ευρεία κλίµακα από τους κατασκευαστές των XML Parsers. Σε αντίθεση το DOM Level 1 είναι υλοποιηµένο σχεδόν από όλους τους XML Parsers. Το DOM ΑPI ορίζει ένα βασικό σύνολο µεθόδων που είναι ανεξάρτητο από γλώσσα προγραµµατισµού και πλατφόρµα (language and platform independent) και µε αυτό µας επιτρέπει να έχουµε ιεραρχική πρόσβαση στην πληροφορία που είναι αποθηκευµένη σε ένα XML αρχείο. Ένας XML Parser µετατρέπει την πληροφορία που βρίσκει σε ένα XML αρχείο σε ένα δέντρο από κόµβους. Αυτό συµβαίνει αφού ο Parser κάνει τους κατάλληλους έλεγχους για ορθότητα (well-form ness) και τους κατάλληλους έλεγχους για επικυροσιµότητα (validation). To DOM API στην συνέχεια µας δίδει τις κατάλληλες µεθόδους για να έχουµε πρόσβαση στους κόµβους του δηµιουργηµένου δέντρου. Στο σχήµα 15 φαίνονται γραφικά τα στάδια από τα οποια περνά ένα ΧΜL αρχείο για να µπορέσει να χρησιµοποιηθεί από ένα πρόγραµµα και στην συνεχεία να γραφτεί πίσω στον σκληρό δίσκο αλλαγµένο ή όχι. Όπως φαίνεται στην διαδικασία γραφής του XML DOM πίσω στην δευτερεύουσα µνήµη µπορεί να χρησιµοποιηθεί µια µέθοδος της προγραµµατιστικής γλώσσας που χρησιµοποιούµε (πχ textwriter). Στο DOM Level 1 δεν υπάρχουν ορισµένοι από την W3C µεθοδοι, οι οποίοι µας επιτρέπουν µε µια εντολή να γράψουµε το DOM δέντρο στην δευτερεύουσα µνήµη. Για αυτό τον σκοπό οι διάφοροι κατασκευαστές υλοποίησαν δικές τους (proprietary) µεθόδους. Source XML Parser Application IN XML Document + Check Well Formness + Check Validty + Creating DOM Tree DOM API DOM Tree OUT XML Document Text Writer Creating manually output file Proprietary DOM Writers Creating Automaticly output file Program Source Code methods (e.g) + tree.getdocumentroot() + root.getchild() + node.getnextsibling()... +savedom Figure 15: H λειτουργία ανάγνωσης και εγγραφής ενός XML αρχείου µε το DOM. -18-

29 Τέλος βλέπουµε ότι µέσα στο πρόγραµµα µπορούµε µε τις µεθόδους του DOM API να διαβάσουµε, να αλλάξουµε και να σβήσουµε στοιχεία του XML δέντρου. Περισσότερα στοιχεία για το DOM API υπάρχουν στο επόµενο κεφάλαιο του XML Parser for Java. 2.8 Τι είναι το SAX (Simple API for XML) και το SAX API To SAX (Simple API for XML) 1.0 [Meg98] είναι ακόµα ένα πρότυπο διασύνδεσης (standard interface) µε ένα XML αρχείο, το οποίο δηµιουργήθηκε τον Μάιο του 1998 από τα µέλη της ηλεκτρονικής ταχυδροµικής λίστας XML-DEV [xmldev]. Τώρα έχει εκδοθεί το SAX2 Pre release, και το οποίο βρίσκεται σε εξέλιξη για προτυποποίηση. Ωστόσο δεν υπάρχουν ακόµα εµπορικοί ή µη SAX2 parsers, εκτός από µια beta έκδοση του David Megisson. To SAX χαρακτηρίζεται σαν ένα standard interface for event-based parsing. Πιο κάτω θα εξηγήσουµε πως δουλεύει το SAX και γιατί χαρακτηρίζεται ετσι. Το SAX δεν ορίζει ένα προκαθορισµένο τρόπο αναπαράστασης της πληροφορίας που είναι αποθηκευµένη σε ένα XML αρχείο. ηλαδή δεν ορίζει ένα Object Model, όπως αυτό γίνεται στο DOM όπου έχουµε το προκαθορισµένο Document Object Model, αλλά πρέπει να ορίσουµε την δική µας δοµή δεδοµένων, µέσα στο πρόγραµµα, η οποία θα κρατά αυτές τις πληροφορίες. Αυτή η δοµή µπορεί να µην περιλαµβάνει όλα τα στοιχεία ενός XML αρχείου αλλά µόνο αυτά τα οποία θέλουµε να επεξεργαστούµε την δεδοµένη στιγµή. Ετσι για παράδειγµα αν έχουµε σε ένα XML αρχείο φυλαγµένα όλα τα στοιχεία για κάθε άτοµο (βλέπε σχήµα 16), και θέλουµε µόνο να διαβάσουµε τις ηλεκτρονικές διευθύνσεις των ατόµων αυτών ( ), τότε θα ήταν αχρείαστο να δηµιουργήσουµε ολόκληρο το DOM δέντρο και µετά να εξάγουµε τα s. Σε αντίθεση θα µπορούσαµε να δηµιουργήσουµε την δική µας δοµή µέσα στην οποία θα αποθηκεύσουµε τις πληροφορίες που ζητάµε. Στην προκείµενη περίπτωση θα µπορούσαµε να δηµιουργήσουµε ένα µονοδιάστατο πίνακα όπου κάθε θέση του πίνακα αντιπροσωπεύει µια ηλεκτρονική διεύθυνση (σχήµα 17). -19-

30 <?xml version='1.0'?> <students type="students" title=" Students of Universities "> <singlename> <name>christos</name> <surname>christoforou</surname> <phone> </phone> <address>street 1</address> </singlename> <singlename> <name>marios</name> <surname>charalambus</surname> <phone> </phone> <address>street 1</address> </singlename> </students> Figure 16: To Αρχείο εισόδου σε ένα SAX parser Table n Figure 17: H δική µας δοµή που θα αποθηκεύσει τα δεδοµένα εισόδου Το SAX χαρακτηρίζεται σαν standard interface for event-based parsing, γιατί καθώς ο SAX Parser διαβάζει το XML αρχείο σηµαντήρα σηµαντήρα από πάνω προς τα κάτω εκκινούν διάφορα συµβάντα (events) καθώς αυτός βρίσκει σηµαντήρες (αρχικούς <element>,καταληκτικούς </element>) CDATA, PCDATA στοιχεία, λάθη και άλλα. Τα συµβάντα τα οποία εκκινούν µπορούµε να λάβουµε (handle) και να τα χειριστούµε χρησιµοποιώντας ένα από τους ακόλουθους τρόπους διασύνδεσης (interfaces) του SAX API : 1. DocumentHandler 2. EntityResolver 3. DTDHandler 4. ErrorHandler. Κάθε interface συµπεριφέρεται σαν ένας Listener στα διάφορα events που τον αφορούν. Ετσι πρέπει να καταχωρήσουµε (register) τα interfaces τα οποία θέλουµε να χρησιµοποιήσουµε στην εφαρµογή µας κατα την εκκίνηση του προγράµµατος µας. -20-

31 Κάθε interface περιέχει ένα σύνολο µεθόδων τις οποίες µεθόδους µπορούµε να υπερκαλύψουµε (override) µε την λειτουργικότητα την οποία επιθυµούµε. Τα πιο συνηθισµένα interfaces που χρησιµοποιούµε είναι το DocumentHandler και το ErrorHandler. Στο επόµενο κεφαλαίο XMLP4J δίνονται ενδεικτικά παραδείγµατα χρήσης του SAXParser. 2.9 Επιλογή µεταξύ DOM και SAX Στην εφαρµογή µας χρησιµοποιήθηκαν και οι δυο τρόποι διασύνδεσης µε ένα XML αρχείο. Η επιλογή του µοντέλου που χρησιµοποιήθηκε στην κάθε περίπτωση έγινε µε βάση τα πιο κάτω κριτήρια. 1. Το SAX χρησιµοποιήθηκε όταν ήταν αναγκαίο να εξάγουµε ΜΕΡΙΚΑ από τα στοιχεία που είναι αποθηκευµένα σε ένα XML αρχείο. Αυτές τις πληροφορίες θα µπορούσαµε να τις φανταστούµε σαν το αποτέλεσµα µιας αναζήτησης (Query). Αυτό είναι φυσικό διότι δεν θέλουµε ολόκληρο το DOM δέντρο µέσα στην µνήµη αλλά µονάχα τις πληροφορίες που αφορούν το αποτέλεσµα του συγκεκριµένου query. Το µειονέκτηµα βέβαια είναι ότι πρέπει να ορίζουµε κάθε φορά τις δοµές δεδοµένων που θα αποθηκεύσουν αυτές τις πληροφορίες, ενώ στο DOM θα είχαµε την default DOM δοµή. 2. Το DOM χρησιµοποιήθηκε όταν θέλαµε να διαβάσουµε ΟΛΑ τα στοιχεία από ένα XML αρχείο και να τα αφήσουµε µετά στην κυρίως µνήµη για να τύψουν περαιτέρω επεξεργασία. Σαν παράδειγµα θα µπορούσαµε να φανταστούµε το ευρετήριο (Index) ενός διαµεσολαβητή, το οποίο αρχικοποιείται (initialize) κάθε φορά που ξεκινά την λειτουργία του o διαµεσολαβητή, µε τα δεδοµένα της προηγούµενης εκτέλεσης του, και τα οποία βρίσκονται σε ένα XML αρχείο. Μετά την αρχικοποίηση του διαµεσολαβητή, θέλουµε το ευρετήριο του να παραµείνει στην κύρια µνήµη για να εξυπηρετήσει αιτήσεις διάφορων άλλων κοµµατιών του συστήµατος. Με αυτό τον τρόπο θα αποφευχθούν πολλές προσβάσεις στην δευτερεύουσα µνήµη (I/O). -21-

32 2.10 Κριτήρια Επιλογής Κατάλληλου Parser Στην επιλογή του κατάλληλου XML Parser ορίσαµε τα κριτήρια που έπρεπε να πλήρει ο Parser τον οποίο θα επιλέγαµε. Αυτά τα κριτήρια ήταν: 1. Συµβατότητα µε τις συστάσεις της W3C σχετικά µε τον ορισµό της ΧΜL (XML Specification v1.0) [BSP98]. Σηµαντικό είναι να αναφέρουµε ότι κανένας εµπορικός parser δεν εκπληρώνει πλήρως τις συστάσεις της XML σχετικά µε το XML Spec v1.0. Για τον σκοπό αυτό χρησιµοποιήθηκε η µελέτη συµβατότητας του Nazmul Idris [Ikj99]. Η συµβατότητα ενός XML parser µε τις συστάσεις της W3C θα µας έδινε την ευελιξία να κάνουµε αλλαγή του parser µας αν σε κάποια φάση αυτό κρινόταν αναγκαίο. Αν ο Parser της επιλογής µας έκανε χρήση µη-συµβατών (proprietary) λειτουργιών κάποιου κατασκευαστή, τότε θα ήταν δύσκολη η διαδικασία συντήρησης του λογισµικού µας αφού θα µέναµε δεµένοι σε κάποιο κατασκευαστή. 2. Κριτήρια απόδοσης. Σηµαντικός παράγοντας στην διαδικασία επιλογής ήταν και οι λόγοι απόδοσης του XML Parser. Πολλοί Parser (ειδικά οι DOM) παρουσίαζαν προβλήµατα λειτουργίας σε µεγάλες ποσότητες δεδοµένων ή σε πολύπλοκες δοµές δεδοµένων (δέντρα), λόγω του ότι κατασκεύαζαν µη αποδοτικά τα DOM δέντρα µέσα στην κύρια µνήµη. Στην µελέτη απόδοσης [Ikf99] φαίνεται πως 2Parsersσυµπεριφέρονται υπό διάφορους όγκους ενός XML αρχείου. Στο Κεφαλαίο της αρχιτεκτονικής θα αναφερθεί πως επιλύθηκε αυτό το πρόβληµα. 3. Υποστήριξη του DOM και του SAX. Σηµαντικός παράγοντας ήταν επίσης να προσφέρει ο Parser υποστήριξη και στα δυο µοντέλα (DOM, SAX) ανάκτησης πληροφοριών από XML δοµές δεδοµένων, γιατί θα ήταν αναγκαίο να χρησιµοποιήσουµε και τα 2 µοντέλα. -22-

33 4. Τεκµηρίωση & ωρεάν Χρήση. Άλλος παράγοντας, ήταν ο Parser να προσφέρει καλή τεκµηρίωση και ενδεικτικά παραδείγµατα για ανάπτυξη. Αυτό ήταν πολύ σηµαντικό γιατί την περίοδο που αρχίσαµε να ασχολούµαστε µε την επιλογή του κατάλληλου Parser, δεν υπήρχαν αρκετές πήγες στο ιαδίκτυου, ούτε αρκετά Βιβλία, που θα µας χρησίµευαν στην ανάπτυξη της XML. Το κριτήριο της ωρεάν χρήσης ήταν επίσης σηµαντικό γιατί δεν έπρεπε να επιβαρύνει µε κόστη την εφαρµογή µας η χρήση του XML Parser. Αναφέρουµε ότι όλοι οι Java XML Parsers διατίθενται δωρεάν µέχρι στιγµής. 5. Υλοποίηση του Parser σε Java. Λόγω του ότι η υπόλοιπη εφαρµογή θα ήταν υλοποιηµένη σε Java (π.χ Java-based Mobile Agents), θα έπρεπε και ο XML Parser να ήταν υλοποιηµένος σε Java. Τελικά επιλέχθηκε ο XML Parser for Java της IBM (XMLP4J),έκδοση [Xmlp4j]. Ο Parser αυτός βρίσκεται τώρα στην έκδοση 3.0 (Απρίλιος 2000). O Parser αυτός πληρούσε σε µεγαλύτερα ποσοστά τις ανάγκες µας σε σχέση µε τους άλλους ηλαδή ήταν σε µεγάλο βαθµό συµβατός µε τις συστάσεις της W3C (βλέπε [Ikj99]). Είναι ο δεύτερος πιο αποδοτικός DOM Parser µετα τον Sun Parser (βλέπε σχήµα 18). XML file size (in KB) Sun Parser (in seconds) IBM Parser (in seconds) 100 KB KB MB MB MB MB MB 23.7 OutOfMemory exception 10 MB 30.0 "" 15 MB 54.0 "" 20 MB OutOfMemory exception "" -23-

34 Figure 18: Σύγκριση Απόδοσης του Sun Parser µε τον ΙΒΜ XML Parser for Java Ωστόσο δεν χρησιµοποιήθηκε ο Parser της Sun γιατί αυτός δεν χρησιµοποιείται σε τόσο ευρεία κλίµακα όσο αυτός της IBM. Συνεπώς δεν µας παρείχε τόσο καλή υποστήριξη µέσα από οµάδες συζήτησης και άλλες πηγές από το ιαδίκτυο. Ο XML Parser της ΙΒΜ προσφέρει επίσης οµάδα συζήτησης (Discussion Group) [Xmlp4j-disc], στην οποία βρήκαµε λύσεις σε αρκετά προβλήµατα σχετικά µε την λειτουργία του Parser. O XMLP4J υποστηρίζει επίσης to DOM Level 1 και το SAX 1.0, και διατίθεται δωρεάν. Tέλος παρέχει καλή τεκµηρίωση και πολλά παραδείγµατα, που έκαναν την χρήση του πιο εύκολη σε µας. Αναλυτική περιγραφή της λειτουργίας του υπάρχει στο επόµενο Κεφάλαιο. -24-

35 Κεφάλαιο 3 Το Σύνολο Πακέτων XMLP4J (XML Parser for Java) 3.1 Εισαγωγή Τα Πακέτα του XMLP4J Η βιβλιοθήκη XMLUtils Εισαγωγή Το σύνολο των πακέτων της ΙΒΜ - XML Parser for Java [Xmlp4j] προσφέρει ένα πλαίσιο εργασίας για την ανάπτυξη εφαρµογών µε την γλώσσα περιγραφής δεδοµένων XML [BSP98] και την γλώσσα προγραµµατισµού Java [SunOv00], O XMLP4J v επιλέχθηκε να χρησιµοποιηθεί για την υλοποίηση του συστήµατος µετά από σχετική έρευνα για την επιλογή του κατάλληλου Parser (βλέπε κεφάλαιο XML). O XMLP4J είναι γραµµένος εξ ολοκλήρου στη γλώσσα προγραµµατισµού Java, πράγµα που τον καθιστά ανεξάρτητο από πλατφόρµα (platform independent). O XMLP4J υποστηρίζει το DOM Level 1 και το SAX 1.0, και διατίθεται δωρεάν. Παρέχει επίσης καλή τεκµηρίωση και πολλά παραδείγµατα. Ο XMLP4J βρίσκεται αυτή την στιγµή (Απρίλιος 2000) στην έκδοση 3 XMLP4J v3.0 προσφέροντας επίσης µερική υποστήριξη στα XML Schemas [Sch00]. Στόχος της σχεδιαστικής οµάδας του XMLP4J είναι η ανάπτυξη ενός εργαλείου που να προσφέρει [XmlP4j]: δυνατότητα ανάπτυξης εφαρµογών µε την XML συµβατότητα µε τις συστάσεις της W3C σχετικά µε το DOM Level 1 και το SAX

36 Η υψηλή απόδοση (high performance), η συναρµολογισιµότητα (modularity) και η δυνατότητα επέκτασης (scalability) H ευρωστία (robustness) στην χρήση του Η ευκολία χρήσης 3.2 Τα πακέτα του XMLP4J Ο XMLP4J αυτή τη στιγµή προσφέρει πέντε πακέτα Java για την ανάπτυξη εφαρµογών µε την XML: 1 package com.ibm.xml.parsers 2 package org.w3c.dom 3 package com.ibm.xml.dom 4 package org.xml.sax 5 package org.xml.sax.helpers Κάθε ένα από αυτά τα πακέτα προσφέρει σειρά κλάσεων για τη δηµιουργία αντικειµένων που µπορούν να χρησιµοποιηθούν από µια εφαρµογή στην Java για να µπορέσει η εφαρµογή αυτή να χρησιµοποιήσει την XML. Ακολουθεί η περιγραφή των πακέτων και ενδεικτικά παραδείγµατα χρήσης. -26-

37 Package com.ibm.xml.parsers Το πακέτο com.ibm.xml.parsers περικλείει όλες τις υλοποιήσεις των Parsers που παρέχει η IBM. Αυτοί οι parsers είναιοιεξής: 1 DOMParser 2 NonValidatingDOMParser 3 NonValidatingParser 4 NonValidatingTXDOMParser 5 RevalidatingDOMParser 6 SAXParser 7 TXDOMParser 8 TXRevalidatingDOMParser 9 ValidatingParser 10 ValidatingSAXParser Όπως υποδηλώνουν και τα ονόµατα των parsers, µερικοί είναι DOM parsers και άλλοι SAX parsers. Περαιτέρω µερικοί parsers έχουν την δυνατότητα να κάνουν έλεγχο εγκυρότητας µόνο κατα την διάρκεια της ανάγνωσης του αρχείου (Validating Parsers) άλλοι και κατά την διάρκεια της ανάγνωσης και οποιαδήποτε άλλη στιγµή (Revalidating Parsers) και άλλοι να την αποφεύγουν (NonValidating Parsers), (δηλαδή αγνοούν εντελώς το DTD). Οι Parsers που αποφεύγουν τον έλεγχο της εγκυρότητας είναι πιο γρήγοροι αφού αποφεύγουν όλους τους έλεγχους. Στην εφαρµογή µας χρησιµοποιήθηκε ο RevalidatingDOMParser, ο οποίος µας έδινε το µέγιστο τον δυνατοτήτων (έλεγχους και επανέλεγχους εγκυρότητας), αλλά ταυτόχρονα ήταν και ο πιο αργός. Η µεταγωγή από ένα DOM Parser σε ένα άλλο DOM Parser ή από ένα SAX parser σε ένα άλλο SAX parser µπορεί να γίνει µε την αλλαγή µερικών γραµµών κώδικα, ειδικά αν πρόκειται για parsers του ίδιου κατασκευαστή (βλέπε παράδειγµα 2). Οι TX parsers (όσοι έχουν TX στο όνοµα τους), είναι ειδικοί (proprietary) parsers, οι οποίοι από την µια έχουν ένα υπερσύνολο δυνατοτήτων αλλά από την άλλη δεν είναι συµβατοί µε τις συστάσεις της W3C σχετικά µε το DOM API. Στην έκδοση 3 του XMLP4J έχουν καταργηθεί οι TX parsers. -27-

38 Ο DOMParser και ο SAXParser, που δεν έχουν µέσα τους µια από τις λέξεις (Validating, NonValidating ή Revalidating) είναι υποκλάσεις των NonValidating Parsers, και τετριµµένα δεν κάνουν έλεγχο εγκυρότητας. Ακολουθεί ενδεικτικό παράδειγµα χρήσης του Revalidating DOM Parser import org.w3c.dom.* import com.ibm.xml.parsers.revalidatingdomparser; //creates & returns the DOM of an XML file which is located at uri public static Document createdom(string uri) { Document doc = null; try { RevalidatingDOMParser parser = new RevalidatingDOMParser(); parser.parse(uri); doc = parser.getdocument(); } catch (Exception e) { System.out.println ("Unable to parse: " + uri + "!"); System.err.println("Sorry, an error occurred: " + e); } return doc; } Figure 1: Μέθοδος ανάγνωσης του XML αρχείου και η δηµιουργία του DOM δέντρου Όπως φαίνεται στον πιο πάνω κώδικα σαρώνουµε ένα XML αρχείο, και δηµιουργούµε στην µνήµη το DOM δέντρο, το οποίο αντιπροσωπεύει τα XML δεδοµένα. Τα Document (doc), στην συνέχεια επιστρέφεται στο κυρίως πρόγραµµα, το οποίο µπορεί να διαβάσει, να αλλάξει και να σβήσει στοιχεία του XML δέντρου. import org.w3c.dom.* import com.ibm.xml.parsers.revalidatingdomparser; //creates & returns the DOM of an XML file which is located at uri public Document createdom(string uri) { Document doc = null; try { // RevalidatingDOMParser parser = new RevalidatingDOMParser(); NonValidatingDOMParser parser = new NonValidatingDOMParser(); parser.parse(uri); doc = parser.getdocument(); } catch (Exception e) { System.out.println ("Unable to parse: " + uri + "!"); System.err.println("Sorry, an error occurred: " + e); } -28-

39 return doc; } Figure 2: Αλλαγή τουvalidatingdomparser XML Parser µε ένα NonValidatingDOMParser Package org.w3c.dom Το πακέτο org.w3c.dom προσφέρει ολόκληρο το DOM Level 1 API όπως αυτό έχει υλοποιηθεί από την οµάδα ανάπτυξης του XMLP4J. H υλοποίηση του DOM Level δεν είναι εντελώς συµβατή µε τις συστάσεις της W3C (βλέπε [Ikj99]). Περιέχει τις abstract κλάσεις Document, Element, Node, Attributes, Nodelist και άλλες µε τις οποίες µπορούµε να χειρισθούµε DOM δεδοµένα σε µια Java εφαρµογή. Με την διασύνδεση (interface) αυτή µπορούµε να αξιοποιήσουµε τα δεδοµένα τα οποία µπήκαν από ένα Parser σε µια Document δοµή (όπως το προηγούµενο παράδειγµα). Ακολουθούν ορισµένα παραδείγµατα που δείχνουν πως µπορούµε να διαβάσουµε στοιχεία ενός XML δέντρου (σχήµα 4), αφού αυτό έχει πρώτα δηµιουργηθεί από τον parser του προηγούµενο παραδείγµατος. <?xml version='1.0'?> <!DOCTYPE student [ <!ELEMENT student (singlename)*> <!ELEMENT singlename (name,university)> <!ELEMENT name (#PCDATA)> <!ELEMENT university (#PCDATA)> ]> <student location= cyprus > <singlename> <name>christos</name> <university>cyprus</university> </singlename> </student> Figure 3: Παράδειγµα XML αρχείου εισόδου import org.w3c.dom.* // IN : A XML document (DOM tree) // OUT: Prints on system out the Header public void printheader(document doc) { Element root = doc.getdocumentelement(); System.out.println( These students were located in : + root.getattribute( location ) +! ); root.setattribute( location, US ); System.out.println( Now they are located in : + root.getattribute( location ) +! ); } -29-

40 Figure 4: Μέθοδος ανάγνωσης και αλλαγής (µόνο στην µνήµη) ενός Attribute του XML δέντρου import org.w3c.dom.* // IN : A XML document (DOM tree) // OUT: Prints on system out all the name element //Return the Element given a Document, tag name, index public static Element getelement(document doc, String tagname,int index) { NodeList rows = doc.getdocumentelement().getelementsbytagname(tagname); return (Element)rows.item(index); } //Returns the number of tagname in document public static int getsize(document doc, String tagname) { NodeList rows = doc.getdocumentelement().getelementsbytagname(tagname); return rows.getlength(); } public static String getvalue(element e, String tagname) {Strings; try { NodeList elements = e.getelementsbytagname( tagname ); Node node = elements.item(0); NodeList nodes = node.getchildnodes(); //find a value whose value is non-whitespace for (int i=0; i<nodes.getlength(); i++) { s = ((Node)nodes.item( i )).getnodevalue().trim(); if ( s.equals("") s.equals("\r")) { continue; } else { return s; } } } catch (Exception ex) { System.out.println("Unable to get the value of :" + tagname); System.out.println(" Actual error : " + ex); } return null; } public void printname(document doc) { Element root = doc.getdocumentelement(); for (int i=0; i< getsize(doc, "name"); i++) { Element namee = Xml1Utils.getElement(doc, "name", i); System.out.println(getvalue(nameE, "name") } } Figure 5: Μέθοδος ανάγνωσης και γραφής όλων των Element name του XML δέντρου -30-

41 Όπως φαίνεται από τα πιο πάνω παραδείγµατα η χρήση Attributes έναντι Elements είναι πολύ πιο εύκολη αφού δεν εκτελούνται τόσες εντολές. Στην εφαρµογή µας χρησιµοποιήθηκαν και οι δυο τρόποι µε περισσότερη προτίµηση στα Attributes. Package com.ibm.xml.dom Το πακέτο com.ibm.xml.dom περιέχει κλάσεις για να εµπλουτίσει το DOM DOM Level 1 API. Όπως είχαµε περιγράψει πριν στο org.w3c.dom υπαρχει υλοποίηση του DOM Level 1, όπως αυτό έχει προταθεί από την W3C. Στο πακέτο αυτό (com.ibm.xml.dom) υπάρχει υλοποίηση µιας επέκτασης του DOM API, το οποίο από την µια έχει ένα υπερσύνολο µεθόδων για χειρισµό των XML DOM δέντρων, αλλά από την άλλη δεν είναι συµβατό µε τις συστάσεις της W3C. Για αυτό τον λόγω δεν έχει χρησιµοποιηθεί στην εφαρµογή µας. Στην εφαρµογή µας χρησιµοποιήθηκε µόνο το πακέτο org.w3c.dom. Package org.xml.sax Το πακέτο org.xml.sax προσφέρει υλοποίηση του SAX API 1.0 όπως αυτό έχει υλοποιηθεί από την οµάδα ανάπτυξης του XMLP4J. Η υλοποίηση αυτή περιέχει τις αφαιρετικές κλάσεις (interfaces): 1 DocumentHandler 2 EntityResolver 3 DTDHandler 4 ErrorHandler. Κάθε interface συµπεριφέρεται σαν ένας Listener στα διάφορα events που τον αφορούν. Έτσι πρέπει να καταχωρήσουµε (register) τα interfaces τα οποία θέλουµε να χρησιµοποιήσουµε στην εφαρµογή µας κατά την εκκίνηση του προγράµµατος µας. Κάθε interface περιέχει ένα σύνολο µεθόδων τις οποίες µεθόδους µπορούµε να υπερκαλύψουµε (override) µε την λειτουργικότητα την οποία επιθυµούµε. Τα πιο συνηθισµένα interfaces που χρησιµοποιούµε είναι το DocumentHandler και το ErrorHandler. -31-

42 Ακολουθεί ένα ενδεικτικό παράδειγµα χρήσης, κατά το οποίο διερµηνεύουµε (parse) ένα XML αρχείο µε τον SAX Parser, και κατά την διάρκεια της διερµήνευσης µετρούµε µε την χρήση του DocumentHandler τον αριθµό τον αρχικών σηµαντήρων (<element>) τον αριθµό των τελικών σηµαντήρων (</element>), τον αριθµό των δεδοµένων που περιέχονται ανάµεσα στους σηµαντήρες, µε την χρήση του ErrorHandler τον αριθµό των προειδοποιήσεων (warnings) και τελος τον αριθµό των συντακτικών λαθών στο XML αρχείο (errors) του σχήµατος 6. Όλα αυτά τα στοιχεία παρουσιάζονται στο output µαζί µε τον ολικό αριθµό των συµβάντων (events) και τον ολικό χρόνο σάρωσης σχήµα 8. <?xml version="1.0"?> <!DOCTYPE sonnet SYSTEM "sonnet.dtd"> <sonnet type="shakespearean"> <author> <last-name>shakespeare</last-name> <first-name>william</first-name> <nationality>british</nationality> <year-of-birth>1564</year-of-birth> <year-of-death>1616</year-of-death> </author> <title>sonnet 130</title> <lines> <line>my mistress' eyes are nothing like the sun,</line> <line>coral is far more red than her lips red.</line> <line>if snow be white, why then her breasts are dun,</line> <line>if hairs be wires, black wires grow on her head.</line> </lines> </sonnet> Figure 6: Αρχείο εισόδου για τον SAX Parser public class saxcounter extends HandlerBase { //This variables will collect information gathered from within the document during parsing int startelementevents = 0; int endelementevents = 0; int characterevents = 0; int warningevents = 0; int errorevents = 0; long starttime,longtime; -32-

43 public void parseuri(string uri) { // αρχή χρόνου Date time = new Date(); long starttime = time.gettime(); SAXParser parser = new SAXParser(); // ηµιουργία SAX Parser parser.setdocumenthandler(this); // Καταχώρηση ενδιαφέροντος για DocumentHandler Events parser.seterrorhandler(this); // Καταχώρηση ενδιαφέροντος για errorhandler Events // διερµήνευση (parsing) του αρχείου εισόδου try { parser.parse(uri); } catch (Exception e) { System.err.println(e); } // τέλος χρόνου time = new Date(); long endtime = time.gettime(); // εκτύπωση αποτελεσµάτων PrintStatistics(); // override the startelement method (belongs to DocumentHandler) public void startelement(string name, AttributeList attrs) { startelementevents++; } // override the characters method (belongs to DocumentHandler) public void characters(char ch[], int start, int length) { characterevents++; } // override the endelement method (belongs to DocumentHandler) public void endelement(string name) { endelementevents++; } Συνέχεια στην επόµενη σελίδα... // override the warning method (belongs to ErrorHandler) public void warning(saxparseexception ex) { warningevents++; } // override the error method (belongs to ErrorHandler) public void error(saxparseexception ex) { errorevents++; } -33-

44 Public void PrintStatistics() { System.out.println("Document Statistics for " + uri + ":"); System.out.println("===================================="); System.out.println("DocumentHandler Events:"); System.out.println(" startelement " + startelementevents); System.out.println(" endelement " + endelementevents); System.out.println(" Data in Elements " + characterevents); System.out.println("ErrorHandler Events:"); System.out.println(" warning " + warningevents); System.out.println(" error " + errorevents); System.out.println(" "); int totalevents = startelementevents + endelementevents + characterevents + warningevents + errorevents ; System.out.println("Total: " + totalevents + " Events"); System.out.println("Total Parsing Time: " + (end-start) + " milliseconds"); } } Figure 7: Ο κώδικας σε Java της κλάσης που διερµηνεύει το αρχείο εισόδου Document Statistics for file:///c:/sonnet.xml: ==================================== DocumentHandler Events: startelement 13 endelement 13 Data in Elements 10 ErrorHandler Events: warning 0 error Total: 36 Events Total Parsing Time: 91 milliseconds Figure 6: Τα αποτελέσµατα της εκτέλεσης του προγράµµατος Package org.xml.sax.helpers Το πακέτο org.xml.sax.helpers περιέχει κλάσεις για να εµπλουτίσει το SAX 1.0 API. Όπως είχαµε περιγράψει πριν στο org.xml.sax υπάρχει υλοποίηση του SAX 1.0 API, όπως αυτό έχει προταθεί από τον David Meggison [Meg98]. Στο πακέτο αυτό υπάρχει υλοποίηση µιας επέκτασης του SAX API, το οποίο από την µια έχει ένα -34-

45 υπερσύνολο µεθόδων για χειρισµό των XML αρχείων, αλλά από την άλλη δεν είναι συµβατό µε τις συστάσεις του SAX Specification. Για αυτό τον λόγω δεν έχει χρησιµοποιηθεί στην εφαρµογή µας. Στην εφαρµογή µας χρησιµοποιήθηκε µόνο το πακέτο org.xml.sax. a. H βιβλιοθήκη XMLUtils Όπως φάνηκε από το παράδειγµα 5,πολλές εντολές (υπό-ενότητες κώδικα) χρησιµοποιούνται σχεδόν κάθε φορά που ανατρέχουµε το XML δέντρο (π.χ (getvalue, getsize, getelement). Για να κάνουµε την δοµή του κώδικα µας πιο αρθρωτή έχουµε ορίσει και υλοποιήσει στην Java ένα βασικό σύνολο µεθόδων, οι οποίες αποτελούν βασικές µεθόδους πρόσβασης στις XML δοµές δεδοµένων. Αυτό το σύνολο των µεθόδων ονοµάστηκε XMLUtils. Η βιβλιοθήκη XMLUtils κάνει χρήση του XML API για να ορίσει υπό µορφή µακρόεντολών (macros) διεργασίες που εκτελούνται ξανά και ξανά. Η βιβλιοθήκη αυτή χρησιµοποιείται από όλα τα δοµικά στοιχεία του συστήµατος µας που κάνουν χρήση της XML. Μέσα στην βιβλιοθήκη αυτή µπορούµε επίσης να κάνουµε κεντρική διαχείριση για το είδος του parser που θα χρησιµοποιηθεί. Μερικές από τις βασικότερες µεθόδους της βιβλιοθήκης XMLUtils είναιοιεξής: 1 public static Document createdom(string uri) Κατασκευή του DOM του XML αρχείου που βρίσκεται στην τοποθεσία uri µε την χρήση του Revalidating DOM Parser. 2 public static Document createdomimpl() Κατασκευή του DOMImpl DOM µε την χρήση του Revalidating DOM Parser. To DOMImpl πρέπει να χρησιµοποιηθεί όταν θέλουµε να κατασκευάσουµε ένα DOM κατά την διάρκεια εκτέλεσης ενός προγράµµατος ΧΩΡΙΣ πρώτα να διαβάσουµε ένα XML αρχείο. Αυτή η µέθοδος χρησιµοποιείται όταν θέλουµε να κατασκευάσουµε το DOM από την αρχή. -35-

46 3 public static boolean validatedom(document doc) Με αυτή την µέθοδο µπορούµε να κάνουµε έλεγχο επικυροσιµότητας κατά την διάρκεια εκτέλεσης του προγράµµατος. Αυτή η µέθοδος χρησιµοποιείται µόνο όταν το Document doc έχει διερµηνευθεί (parsed) µε τον RevalidatingDOMParser. Μπορεί να χρησιµοποιηθεί για παράδειγµα µετα την προσθήκη κάποιων στοιχείων στην XML δοµή. 4 public static int getsize(document doc, String tagname) Μας δίδει τον αριθµό των φορών που το Element tagname παρουσιάζεται µέσα στο Document doc 5 public static Element getelement(document doc, String tagname, int index) Μας δίδει το Element που είναι τύπου tagname στην index εµφάνιση του. Για παράδειγµα αν έχουµε <names> <name>christos</name> <name>marios</name> </names> και καλέσουµε getelement(doc, name,1) θα πάρουµε το Element <name>marios</name> 6 public static String getvalue(element e, String tagname) Μας δίδει την τιµή του υπό-element tagname, που περιέχει ένα Element e. Για παράδειγµα αν έχουµε το Element e του προηγούµενου παραδείγµατος <names> <name>christos</name> <name>marios</name> </names> και καλέσουµε getvalue(e, name ) θα πάρουµε την τιµή σε String Marios 7 public static void setvalue(element e, String tagname, String value) Το αντίστροφο της getvalue. ηλαδή µας δίδει την δυνατότητα να τοποθετήσουµε µια τιµή σε ένα Element. Για παράδειγµα µπορούµε να αλλάξουµε το Element του παραδείγµατος της µεθόδου getelement από Marios σε Antonis 8 public static String getsubvalueattr( Element e,string tagname,int index ) Αυτή η µέθοδος µας δίδει την δυνατότητα να πάρουµε σε µορφή String όλο το Element µαζί µε τα Attributes του. Για παράδειγµα αν έχουµε ένα Element -36-

47 <person name= Christos sex= Male age= 12 height= 1.85 weight= 80kg /> τότε µπορούµε να πάρουµε όλο Element σαν String. Αυτή η διαδικασία κάνει την δουλεία που κάνει η µέθοδος tostring() στην Java. -37-

48 Κεφάλαιο 4 Το Σύνολο Πακέτων CONCORDIA 4.1 Εισαγωγή Αρχιτεκτονική Τα Πακέτα του Concordia Εισαγωγή Το σύνολο των πακέτων Concordia προσφέρει ένα πλαίσιο εργασίας για την ανάπτυξη, την εκτέλεση και τον έλεγχο προγραµµάτων κινητών πρακτόρων. Το Concordia είναι γραµµένο εξ ολοκλήρου στη γλώσσα προγραµµατισµού Java [GM00]. Στόχος της σχεδιαστικής οµάδας του Concordia είναι η ανάπτυξη ενός εργαλείου που να προσφέρει [WPW97]: δυνατότητα προγραµµατισµού κινητών, ευέλικτων πρακτόρων στη Java, υποστήριξη της συνεργασίας µεταξύ τους, αξιόπιστη αποστολή, κατακράτηση της κατάστασής τους για σκοπούς ανάκτησης σε περίπτωση κατάρρευσης κάποιου κόµβου ασφάλεια της δοµής και των δεδοµένων των κινητών πρακτόρων και των κόµβων που αυτοί επισκέπτονται (agent security). -38-

49 4.2 Αρχιτεκτονική Η αρχιτεκτονική του Concordia είναι η εξής: Σχήµα 3.1 :Η Αρχιτεκτονική του Concordia Concordia Server Ο Concordia Server είναι το όνοµα που δίνεται στο σύνολο των στοιχείων που το αποτελούν και τα οποία τρέχουν σε έναν ηλεκτρονικό υπολογιστή πάνω από την Εικονική Μηχανή Java (Java Virtual Machine - JVM). Τα στοιχεία αυτά είναι: Agent Manager Ο Agent Manager παρέχει την υποδοµή για την αποστολή και την παραλαβή κινητών πρακτόρων από και προς κάποιο κόµβο στο δίκτυο καθώς επίσης και τον έλεγχο του κύκλου ζωής τους. Προσφέρει ένα αφαιρετικό επίπεδο στο πρόβληµα της δικτυακής διεπαφής (network interface) ώστε ο προγραµµατιστής να µην χρειάζεται να γνωρίζει τη δοµή και τα πρωτόκολλα κάθε δικτύου µέσα από τα οποία θα ταξιδέψει ο κινητός πράκτορας. Ο προγραµµατιστής πρέπει να δώσει µόνο τις διευθύνσεις των -39-

50 κόµβων στις οποίες θα ταξιδέψει ο κινητός πράκτορας και τις µεθόδους που θα εκτελεστούν σε κάθε του σταθµό. Η αποστολή και η παραλαβή πρακτόρων του Concordia [Mit98] γίνεται εφικτή µέσο του Conduit Server που είναι µέρος του Agent Manager. Ένας κινητός πράκτορας ξεκινά την διαδικασία αποστολής του µε το να καλέσει µεθόδους του Conduit Server. Η εκτέλεση του κώδικα του κινητού πράκτορα σταµατά προσωρινά και δηµιουργείται ένα αντίγραφο του για λόγους επαναφοράς της κατάστασής του σε περίπτωση που η διαδικασία αποστολής αποτύχει. O Conduit Server ελέγχει τον προορισµό του και αποστέλλει το αντίγραφό του στον Conduit Server του Concordia Server της µηχανής που προορίζεται. Εκεί η κατάσταση του πράκτορα φυλάγεται και πάλι πριν σταλεί η επιβεβαίωση παραλαβής του. Το Concordia χρησιµοποιεί το πρωτόκολλο TCP/IP για την επικοινωνία µεταξύ των Concordia Servers. Queue Manager Ο Queue Manager είναι υπεύθυνος για τον χρονοπρογραµµατισµό (και τις διαδοχικές προσπάθειες) της αποστολής κινητών πρακτόρων µεταξύ συστηµάτων Concordia. Κατακρατεί τους κινητούς πράκτορες καθώς αυτοί περιµένουν τη σειρά τους να εκτελέσουν τις µεθόδους τους καθώς επίσης και την κατάστασή τους όταν έρχονται ή φεύγουν από το σύστηµα. Επιπλέον, δοκιµάζει, µε την απαιτούµενη συχνότητα, την αποστολή ενός πράκτορα όταν κάποιο σύστηµα έχει αποσυνδεθεί από το δίκτυο. Ο Queue Manager διαχειρίζεται ουρές εισόδου και εξόδου για την ασφαλή αποστολή κινητών πρακτόρων µέσω του δικτύου. Ο Queue Manager επικοινωνεί µε τον τοπικό Conduit Server µέσω του οποίου κάνει χειραψία µε αποµακρυσµένους Queue Managers για την ασφαλή αποστολή τους. Η αποστολή πρακτόρων στηρίζεται στο Remote Method Invocation (RMI) System [Sun00, WW00] της Java που επιτρέπει σε ένα αντικείµενο που τρέχει σε ένα περιβάλλον Java Virtual Machine (JVM) να καλέσει µεθόδους ενός αντικειµένου που -40-

51 τρέχει σε ένα άλλο JVM. Μία από τις κύριες δυνατότητες του RMI είναι η ικανότητά του να µεταφέρει τον κώδικα (bytecode) ενός αντικειµένου εκ του µακρόθεν, εφόσον αυτός δεν υπάρχει στην τοπική εικονική µηχανή. Η δυνατότητα αποστολής του κώδικα ενός αντικειµένου µέσω RMI γίνεται δυνατή χάρη στην τεχνολογία Object Serialization της Java. Administrator ( εν υπάρχει πλήρης υλοποίησή του στο evaluation kit v1.1.4) Ο Administration Manager αναλαµβάνει τον έλεγχο και τη διαχείριση όλων των υπηρεσιών που υπάρχουν σε διάφορους Concordia Servers. ηλαδή ένας Administration Manager είναι αρκετός για τον έλεγχο και τη διαχείριση πολλών Concordia Servers. Επιτρέπει το σταµάτηµα, το ξεκίνηµα, την αναστολή και την επανεκκίνηση κάποιου Concordia Server, την παρακολούθηση, τον τερµατισµό, την αναστολή και την επανεκκίνηση κινητών πρακτόρων, την εγκαθίδρυση και απεγκαθίδρυση υπηρεσιών κτλ. Στην πλήρη έκδοση προσφέρεται σύστηµα γραφικής διεπαφής για τη χρήση του Administration Manager. Security Manager ( εν υπάρχει στο evaluation kit v1.1.4) Ο Security Manager είναι υπεύθυνος για την αναγνώριση των χρηστών, την εξακρίβωση της αυθεντικότητας των κινητών πρακτόρων που αυτοί στέλνουν, την προστασία των πόρων του εξυπηρετητή και την διασφάλιση της ασφάλειας και ακεραιότητας των πρακτόρων και των δεδοµένων τους καθώς ταξιδεύουν. Το Concordia χρησιµοποιεί το πρωτόκολλο SSLv3 (Secure Socket Layer) [SSL3] για την κρυπτογραφηµένη αποστολή πληροφοριών για κινητούς πράκτορες από ένα σύστηµα σε κάποιο άλλο. Persistence Manager ( εν υπάρχει στο evaluation kit v1.1.4) Ο Persistence Manager διατηρεί την κατάσταση των πρακτόρων καθώς αυτοί ταξιδεύουν στο δίκτυο. Έτσι καθίσταται δυνατή η αυτόµατη επαναδηµιουργία και συνέχιση του έργου των πρακτόρων στην περίπτωση που το σύστηµα καταρρεύσει. -41-

52 Όπως και στην περίπτωση του Agent Manager οι εργασίες του Persistence Manager είναι αυτοµατοποιηµένες. Event Manager Ο Event Manager χειρίζεται την καταγραφή, την έκδοση, την αποστολή και την παραλαβή των Events. Αντικείµενα που θέλουν να παραλαµβάνουν συγκεκριµένα Εvents πρέπει να συνδεθούν µε τον Event Manager. Αντικείµενα που θέλουν να στέλνουν Events σε άλλα αντικείµενα πρέπει να τα αποστέλλουν στον Event Manager, ο οποίος τα φιλτράρει και τα στέλνει µόνο στα αντικείµενα που ζήτησαν να παραλαµβάνουν τα συγκεκριµένα Events. O Event Manager στέλνειταεvents στον κάθε πράκτορα στην τοποθεσία που βρίσκεται ανά πάσα στιγµή έστω κι αν ο πράκτορα έχει ταξιδέψει σε µια άλλη τοποθεσία µετά την καταγραφή του σε κάποιο Event Manager. Αν ο πράκτορας ταξιδεύει τη στιγµή που έγινε στέλνεται ένα Εvent στον Event Manager, τότε αυτόµατα το Εvent µπαίνει σε µια ουρά για αποστολή προς τον πράκτορα µετά την άφιξή του στον προορισµό του. Έτσι κανένα Εvent δεν χάνεται όταν οι πράκτορες ταξιδεύουν. Directory Manager Ο Directory Manager παρέχει υπηρεσίες ονοµατολογίας των υπηρεσιών (services) που υπάρχουν σε Concordia Servers. Μια υπηρεσία δηλώνει την ύπαρξή της σε ένα ή περισσότερα Directory Managers σε κόµβους του δικτύου, ώστε ένας πράκτορας που ζητεί την παροχή µιας υπηρεσίας να µην χρειάζεται να γνωρίζει την διεύθυνση του κόµβου στον οποίο βρίσκεται η υπηρεσία, παρά µόνο την ύπαρξη του Directory Manager. Ο Directory Manager θα αναλάβει να στείλει την αίτηση του πράκτορα στην υπηρεσία ή να µεταβιβάσει την αίτηση σε κάποιο άλλο Directory Manager. -42-

53 4.3 Τα πακέτα της Concordia Το Concordia αυτή τη στιγµή προσφέρει τέσσερα πακέτα Java για την ανάπτυξη κατανεµηµένων συστηµάτων: package COM.meitca.concordia package COM.meitca.concordia.collaborate package COM.meitca.concordia.event package COM.meitca.concordia.service Κάθε ένα από αυτά τα πακέτα προσφέρει σειρά κλάσεων για τη δηµιουργία αντικειµένων που µπορούν να χρησιµοποιηθούν σε ένα σύστηµα κινητών πρακτόρων. Ακολουθεί η περιγραφή των πακέτων. Package COM.meitca.concordia Το πακέτο COM.meitca.concordia προσφέρει τις βασικές κλάσεις για την ανάπτυξη κινητών πρακτόρων. Περιέχει τις abstract κλάσεις Agent και CollaboratorAgent καθώς επίσης και τις κλάσεις Destination και Itinerary, µέσω των οποίων ορίζει κάποιος το δροµολόγιο ενός πράκτορα. To Itinerary είναι ένα σύνολο από Destinations. Ένα Destination αποτελείται από το όνοµα της µηχανής στην οποία θα ταξιδέψει ο Agent και τη µέθοδο που θα κληθεί όταν αυτός φτάσει εκεί. Παράδειγµα: Host Name Method Name Destination 1 cs20.cs.ucy.ac.cy getserverdata Destination 2 cs68.cs.ucy.ac.cy reportserverinfo Πίνακας 3.1: Τα περιεχόµενα ενός αντικειµένουitinerary Ο κώδικας για την δηµιουργία και την αποστολή ενός κινητού πράκτορα του Concordia είναι ο πιο κάτω: -43-

54 public void sendagent() { // Create the agent TestAgent testagent = new TestAgent (); // Set its Itinerary Itinerary itinerary = new Itinerary(); itinerary.adddestination(new Destination("destination1", "method1")); itinerary.adddestination(new Destination("destination2", "method2")); } // Set its codebase String codebase = C:/COM/meitca/concordia/test/"; try { // Last, we actually launch the agent testagent.sethomecodebaseurl(codebase); testagent.setitinerary(itinerary); testagent.launch(); } catch (LaunchException le) { System.out.prinln( Error launching testagent : \n\t + le); } Package COM.meitca.concordia.event To Concordia προσφέρει επίσης µια υποδοµή για την επικοινωνία µεταξύ κινητών ή σταθερών αντικειµένων. Πρόκειται για τα Distributed Events, ή απλά Events ή µηνύµατα. Τα Εvents επιτρέπουν την σύγχρονη ή ασύγχρονη επικοινωνία δύο ή περισσοτέρων αντικειµένων. Πρόκειται για µορφή µηνυµάτων, τα οποία όµως µπορούν να περιέχουν (και να µεταφέρουν) κάποιες πληροφορίες που καθορίζει ο προγραµµατιστής. Τα Events είναι αντικείµενα Java, πολύ όµως ελαφρότερα από ένα κινητό πράκτορα. Τυπικό µέγεθος ενός πράκτορα που µεταφέρει µία πληροφορία (πχ. το ID του) είναι 693 bytes ενώ ένα Event που µεταφέρει την ίδια πληροφορία έχει µέγεθος 286 bytes. Για να µπορέσει ένα αντικείµενο να ανταλλάξει µηνύµατα, πρέπει να έχει δηµιουργήσει πρώτα µια σύνδεση µε τον Event Manager κάποιου Concordia Server, είτε αυτός βρίσκεται στην τοπική µηχανή είτε όχι. Κατά τη διάρκεια της σύνδεσης το αντικείµενο δηλώνει ποιά µηνύµατα ενδιαφέρεται να παραλαµβάνει. Ένα αντικείµενο -44-

55 που δηµιουργεί ένα Event δεν χρειάζεται να γνωρίζει την ύπαρξη ή την τοποθεσία των αντικειµένων που ενδιαφέρονται να παραλάβουν το Event που δηµιουργεί. Αντίστροφα, ένα αντικείµενο που θέλει να παραλαµβάνει ένα Event δεν χρειάζεται να γνωρίζει την τοποθεσία του αποστολέα του Event. Την λειτουργικότητα της εύρεσης των παραληπτών και της αποστολής ενός Event προσφέρει ο Event Manager. Ο κώδικας για την σύνδεση ενός µη κινητού αντικειµένου µε ένα Event Manager είναι ο εξής: public void makeeventmanagerconnection() { try { // The object s event queue EventPost eventqueue= (EventPost)new EventQueueImpl(this); // A connection to an event manager EventManagerConnection eventmanagerconnection = new EventManagerConnection(); // The list of events this object is interested in receiving Class eventclass[] = {DBResultsEvent.class}; // The URL of the Event Manager String RemoteEventManagerURL = EventManagerConnection.EventManagerURL( cs68.cs.ucy.ac.cy ); // The connection process eventmanagerconnection.makeconnection(remoteeventmanagerurl,false); eventmanagerconnection.registerevent(eventclass,eventqueue); } catch (Exception e) { System.out.println("Error connecting to Event Manager: \n\t" + e); } } Ο κώδικας για την ένωση ενός κινητού πράκτορα µε έναν Event Manager είναι πιο απλός γιατί το abstract class Agent προσφέρει ήδη κάποια λειτουργικότητα για αυτό το σκοπό: -45-

56 public void makeeventmanagerconnection() { try { // The agents s event handler makeeventhandler(false); // The list of events this object is interested in receiving Class eventclass[] = {DBResultsEvent.class}; // The URL of the Event Manager String RemoteEventManagerURL = EventManagerConnection.EventManagerURL( cs68.cs.ucy.ac.cy ); // The connection process makeeventmanagerconnection(remoteeventmanagerurl,false); registerevents(eventclass); } catch (Exception e) { System.out.println("Error connecting to Event Manager: \n\t" + e); } } H εντολή για την αποστολή ενός Event είναι αντίστοιχα : και eventmanagerconnection.postevent(new testevent()); postevent(new testevent()); Package COM.meitca.concordia.service Το Concordia προσφέρει ακόµα µεγαλύτερη ευελιξία και δυνατότητα στους κινητούς του πράκτορες επιτρέποντας την αλληλεπίδρασή τους µε στατικά προγράµµατα γραµµένα σε Java, τα οποία προηγουµένως έχουν εγκατασταθεί σε κάποιο Concordia Server µέσω µιας υπηρεσίας ονοµατολογίας. Κάθε ένα από αυτά τα στατικά προγράµµατα φέρει δηλαδή το δικό της όνοµα βάσει του οποίου ένας πράκτορας το αναζητεί. Ο πράκτορας µπορεί στη συνέχεια να καλέσει µεθόδους αυτού του προγράµµατος το οποίο εκτελεί κώδικα (και επιστρέφει αποτελέσµατα αν χρειαστεί) εκ µέρους του πράκτορα όπως για παράδειγµα πρόσβαση σε τοπικά αρχεία. Το Concordia ονοµάζει τα προγράµµατα αυτά Service Bridges, αφού αποτελούν µια γέφυρα επικοινωνίας µεταξύ κάποιου κινητού πράκτορα και των υπηρεσιών ή/και πόρων που µπορεί να προσφέρει µια µηχανή στην οποία τρέχει ένας Concordia Server. -46-

57 package COM.meitca.concordia.collaborate Το Concordia προσφέρει και άλλες δυνατότητες όπως για παράδειγµα σύγχρονη ή ασύγχρονη συνεργασία µεταξύ κινητών πρακτόρων. Για να γίνει αυτό πρέπει πρώτα να δηµιουργηθεί ένα AgentGroupImpl αντικείµενο και στην συνέχεια να προσθέσουµε σε αυτή την οµάδα διάφορους CollaboratorAgents. Οι CollaboratorAgents µπορούν στη συνέχεια να ταξιδέψουν σε διαφορετικούς προορισµούς, να εκτελέσουν τον κώδικά τους και να καλέσουν τη µέθοδο collaborate η οποία θα στείλει τα αποτελέσµατα της εκτέλεσης στον AgentGroupImpl. Όταν ο τελευταίος παραλάβει τα αποτελέσµατα από ένα CollaboratorAgents, αναστέλλει τη λειτουργία του πράκτορα µέχρι να κάνει τους ανάλογους υπολογισµούς και να στείλει πίσω τα δικά του αποτελέσµατα. Όταν η συνεργασία γίνεται ασύγχρονα, τότε η λειτουργία ενός πράκτορα αναστέλλεται µέχρι να παραληφθούν τα αποτελέσµατα από όλους τους CollaboratorAgents της ίδιας οµάδας. Ο συνδυασµός των αποτελεσµάτων γίνεται στη µέθοδο analyzeresults του AgentGroupImpl, η οποία στέλνει το ίδιο αποτέλεσµα σε όλους τους CollaboratorAgents της οµάδας. -47-

58 Κεφάλαιο 5 Java Servlets 5.1 Εισαγωγή Η διαφορές και οι οµοιότητες των Servlets και των CGIs ιαφορετικοί τρόποι γραφής ενός Servlet Το Servlet API Παραδείγµατα επεξεργασίας Φόρµας Εισαγωγή Servlet είναι ενότητες κώδικα Java (bytecode), που τρέχουν σε διαθέτες που λειτουργούν µε το πρωτόκολλο HTTP (Web Server), και τους επεκτείνουν µε νέα λειτουργικότητα. Τα Servlets χρησιµοποιούνται σε εφαρµογές όπου απαιτείται προεπεξεργασία πριν την αποστολή της απόκρισης στον αιτητή. Τα Servlets είναι λειτουργούν όπως όλα τα άλλα είδη CGIs (Common Gateway Interface) [Rob95] όπως για παράδειγµα Unix Shell scripts, ΑSP (Active Server Pages) [ASP] µε την βασική διάφορα ότι τα Servlets κληρονοµούν όλα τα πλεονεκτήµατα που προσφέρει η γλώσσα προγραµµατισµού Java. Τα Servlets αποτελούν το Server-site πρόσωπο της Java σε αντίθεση µε τα Applets που αποτελούν το Client site πρόσωπο της Java. Αυτό σηµαίνει ότι ο φυλλοµετρητής του πελάτη-αιτητή, δεν πρέπει να είναι κατ ανάγκη εφοδιασµένος µε το JVM (Java Virtual Machine), αφού δεν παραλαµβάνει κατ ανάγκη bytecode. Τα Servlets άρχισαν να χρησιµοποιούνται στους ιαθέτες διαδικτύου από το Οι διαφορές και οι οµοιότητες των CGIs και των Servlets -48-

59 CGI (Common Gateway Interface) [Rob95] είναι µια διασύνδεση (ανεξάρτητη από γλώσσα προγραµµατισµού, που επιτρέπει σε ένα εξυπηρετητή να ξεκινά µια εσωτερική διεργασία το οποίο δέχεται παραµέτρους µέσω µεταβλητών περιβάλλοντος (environment variables) και µέσω του command line και να γράφει τα δεδοµένα εξόδου στο Standard Output. Σχεδόν όλες οι γλώσσες υλοποιούν το Common Gateway Interface. Παραδείγµατα τέτοιων γλωσσών είναι η Perl, τα Microsoft ASP, Unix Shell Scripts αλλά και γλώσσες όπως την C και την C++. Το µειονέκτηµα των περισσότερων γλωσσών που υλοποιούν το CGI είναι ότι είναι γλώσσες Scripting. Στις scripting γλώσσες είναι πολύ πιο δύσκολη η οργάνωση και άρθρωση του κώδικα από ότι είναι στις κανονικές γλώσσες. ύσκολη είναι επίσης η αποσφαλµάτωση του κώδικα αφού ο κώδικας δεν περνά από κάποιο µεταγλωττιστή (compiler). Figure 1: Η λειτουργία του Common Gateway Interface Servlet είναι ενότητες κώδικα Java [Zeig99]. Αυτό δίνει στα Servlets πολλά πλεονεκτήµατα. Τα πλεονεκτήµατα είναι [HC98] : Tα Servlets έχουν την δυνατότητα πλήρης αξιοποίησης των JAVA API του RMI (remote method invocation), της Corba, των Java API για διασυνδετικότητας µε βάσεις δεδοµένων και άλλων τόσων πακέτων που προσφέρει η Java. Αυτό σηµαίνει ότι µπορούµε να κάνουµε οτιδήποτε µπορούµε να κάνουµε µέσα από µια εφαρµογή Java, όπως για παράδειγµα διαχείριση λαθών του προγράµµατος (exception -49-

60 handling), να γράψουµε αντικειµενόστρεφή κώδικα (object oriented code) και να χρησιµοποιήσουµε κληρονοµικότητα (inheritance) όπου χρειαζόµαστε. Τα Servlets κληρονοµούν από την Java την δυνατότητα της ανεξαρτησίας από πλατφόρµα (platform independence). Με αυτό τον τρόπο µας παρέχεται ευελιξία στην επιλογή της πλατφόρµας πρίν και µετά την ανάπτυξη της εφαρµογής µας. Figure 2: Η λειτουργία του Servlet 5.3 ιαφορετικοί τρόποι γραφής ενός Servlet Υπάρχουν τρεις τρόποι να γράψουµε και να καλέσουµε ένα servlet. Αυτοί οι τρόποι είναι [HC98]: Με απευθείας αίτηση της Κλάσης Με την χρήση ενός SSI (Server Site Include) Με την χρήση των Java Server Pages (JSP) Πιο κάτω περιγράφουµε τον καθένα από τους πιο πάνω τρόπους και δίδουµε ενδεικτικά παραδείγµατα χρήσης. Με απευθείαν αίτηση της Κλάσης Ο πρώτος τρόπος που είναι και ο πιο συνηθισµένος, είναι µε το απευθείας κάλεσµα της κλάσης (class file). Στο σχήµα 3 φαίνεται διαγραµµατικά αυτή η -50-

61 διαδικασία. Ετσι ένας αιτητής θα καλούσε στον φυλλοµετρητή του µια διεύθυνση της φύσης τότε θα εµφανιστεί στον φυλλοµετρητή του το µήνυµα Hello Client. To 8000 υποδηλώνει την πύλη την οποία εξυπηρετά η Servlet µηχανή (servlet engine) και η οποια είναι συνήθως διαφορετική από την τετριµµένη πύλη 80, την οποια χρησιµοποιούν οι διαθέτες ιαδικτύου (Web Servers) Figure 3: Απευθείας εκτέλεση του class Με την χρήση ενός SSI (Server Site Include) Ο δεύτερος τρόπος είναι µε την χρήση ενός Server Site Include. Με αυτό τον τρόπο ο χρήστης καλεί µια σελίδα τύπου shtml

62 Ο διαµεσολαβητής κατά την διάρκεια απόκρισης στην αίτηση του χρήστη ανταλλάζει όλα τους σηµαντήρες <SERVLET> µε το αποτέλεσµα εκτέλεσης του servlet που βρίσκεται στο ιδιοχαρακτηριστικό CODEBASE του σηµαντήρα <SERVLET>. Στο σχήµα 4 φαίνεται διαγραµµατικά αυτή η διαδικασία. Figure 4: Εκτέλεση του Servlet µε Server Site Include Με την χρήση των Java Server Pages (JSP) Ο τρίτος τρόπος είναι µε την χρήση των Java Server Pages. O τρόπος αυτός είναι όµοιος µε την χρήση των Microsoft Active Server Pages (ASP) [Αsp] ή των GNU Server Pages (GSP) [Gsp]. Με αυτό τον τρόπο ο χρήστης καλεί µια σελίδα τύπου jsp. Ο διαµεσολαβητής κατα την διάρκεια απόκρισης στην αίτηση του χρήστη ανταλλάζει όλα τα snippets του JSP κώδικα µε το αποτέλεσµα της εκτέλεσης του σχετικού κώδικα. Στο σχήµα 5 φαίνεται διαγραµµατικά αυτή η διαδικασία. -52-

63 Figure 5: Εκτέλεση της JSP σελίδας Το µειονέκτηµα των JSP σελίδων είναι ότι δεν γράφουµε καθαρό κώδικα Java αλλά ένα υβριδικό κώδικα όπου γίνεται ταυτόχρονη χρήση της HTML και της Java. Με αυτό τον τρόπο δεν υπαρχει καλή οργάνωση στις σελίδες µας. Τα JSP ωστόσο χρησιµοποιούνται πολλές φορές γιατί είναι πολύ απλά στην ανάπτυξη τους. Στην υλοποίηση µας χρησιµοποιήσαµε τον πρώτο τρόπο δηλαδή την απευθείας εκτέλεση των κλάσεων γιατί είναι ο πιο δοµηµένος και εύχρηστος τρόπος συγγραφής ενός Servlet. 5.4 Το Servlet API (Application Protocol Interface) Όλα τα Servlets υλοποιούν την διασύνδεση τους µε τον διαµεσολαβητή µέσω δυο πακέτων. Αυτά τα πακέτα είναι τα εξής: GenericServlet (Package javax.servlet package) HttpServlet (Package javax.servlet.http) -53-

64 Αυτά τα δυο πακέτα βρίσκονται στο JSDK [JSDK2]. Με τo πακέτο GenericServlet µπορούµε να γράψουµε Servlets ανεξάρτητα πρωτοκόλλου ενώ µε το πακέτο HttpServlet µπορούµε να γράψουµε HTTP Servlets. To GenericServlet χρησιµοποιείται η µέθοδος service() ενώ στο HttpServlet οι µεθόδοι doget(), dopost(), dodelete(). Figure 6: To GenericServlet Figure 7: To HttpServlet Όταν ένα servlet δέχεται ένα κάλεσµα από τον πελάτη (client), λαµβάνει δύο αντικείµενα (objects): Ένα ServletRequest, που εξασφαλίζει την επικοινωνία από τον πελάτη πρός τον server. Ένα ServletResponse, που εξασφαλίζει την επικοινωνία από το servlet πίσω στον πελάτη. -54-

65 Τα ServletRequest και ServletResponse είναι interfaces ορισµένα στο javax.servlet package. 5.5 Παράδειγµα επεξεργασίας φόρµας Πιο κάτω ακολουθεί ένα ολοκληρωµένο παράδειγµα χρήσης ενός Servlet. Στο παράδειγµα αυτό ο χρήστης-αιτητής αποστέλλει σε ένα servlet το όνοµα του (σαν παράµετρο) από µια HTML σελίδα, και λαµβάνει σε µια άλλη HTML σελίδα το µήνυµα Hello το_όνοµα_του_χρήστη Κώδικας HTML σελίδας <head> <title>new Page 1</title> </head> <body> <form method="get" action=" <p>if you don't mind me asking, what is your name? <input type="text" name="name"> </p> <p><input type="submit"> <input type="reset"> </p> </form> </body> </html> Εµφάνιση στον φυλλοµετρητή -55-

66 Κώδικας Servlet Helloclient.java import java.io.*; import javax.servlet.*; import javax.servlet.http.*; public class Helloclient extends HttpServlet { public void doget(httpservletrequest req, HttpServletResponse resp) throws ServletException, IOException { resp.setcontenttype("text/html"); PrintWriter out = resp.getwriter(); String name = req.getparameter("name"); out.println("<html>"); out.println("<head><title>hello, " + name + "</TITLE></HEAD>"); out.println("<body>"); out.println("hello, " + name); out.println("</body>"); out.println("</html>"); out.close(); } } Εµφανιση στον Φυλλοµετρητή -56-

67 Κεφάλαιο 6 Αρχιτεκτονική erace 6.1 Το Πρόβληµα Προτεινόµενη Λύση Οι Σχεδιαστική Στόχοι του erace Αρχιτεκτονική erace Το πρόβληµα Η ψηφιακή σύγκλιση των τεχνολογιών τηςπληροφορικήςκαι των τηλεπικοινωνιών έχει προκαλέσει µια πληροφοριακή έκρηξη, η οποια καθίσταται προφανήςαπό το τεράστιο πλήθοςτων πληροφοριών που είναι διαθέσιµεςλόγω του ιαδικτυου [CKPW98, SZD98]. Πρόσβαση προςτιςπληροφορίεςαυτέςπαρέχεται µέσω πολλών και διαφορετικών δικτυακών εργαλείων και υπηρεσιών λογισµικού, τα οποια έχουν σχεδιαστεί για δηµοσίευση, παραλαβή, αναζήτηση, φυλλοµέτρηση (browsing) και ολοκλήρωση (integration) πληροφοριών: Usenet News, Wide-Area Information Servers (WAIS), World Wide Web (WWW), lists. Η πληθώρα των πληροφοριών σε ψηφιακή µορφή καταπνίγει τιςδιεθνείςδικτυακέςυποδοµέςκαι επηρεάζει δυσµενώς την αλληλεπίδραση των ανθρώπων µε τα πληροφοριακά δίκτυα. Πιο συγκεκριµένα η πληροφοριακή έκρηξη θέτει επιπλέον δυσκολίεςσε όλουςόσοι χρησιµοποιούν τις δικτυακέςυποδοµέςκαι υπηρεσίεςγια αναζήτηση χρήσιµων πληροφοριών, λόγω φαινοµένων όπωςη πληροφοριακή υπερφόρτωση (information overloading και ο δικτυακόςαποπροσανατολισµός(network disorientation) [Dika99]. Προκύπτει έτσι η ανάγκη εξελιγµένων εργαλείων και υπηρεσιών αναζήτησης, φιλτραρίσµατος, -57-

68 ταξινόµησηςολοκλήρωσηςκαι ανάλυσηςπληροφοριών [Witt96, YGM95, KRW96, DH97, EB00] Όπωςείναι γνωστό, υπηρεσίες ιαδικτύου όπωςτο WWW, λίστες ηλεκτρονικού ταχυδροµείου, newsgroups, χρησιµοποιούνται ευρύτατα για την ενηµέρωση των χρηστών διάµεσου µιαςσυνεχούςπαροχήςπληροφοριών σχετικών µε τα ενδιαφέροντα τους. Οι ανάγκεςαυτέςκαθίστανται εντονότερες, όταν ο χρήστης χρησιµοποιεί κινητέςσυσκευέςυπολογισµού όπωςγια παράδειγµα φορητό υπολογιστή ή κινητό τηλέφωνο, οπότε χρειάζεται να τιςέχει κατάλληλα διαρρυθµισµένεςγια να µπορεί να έχει γρήγορη πρόσβαση στιςδιαθέσιµεςπηγέςκαι µέσα που µπορεί να λειτουργούν µε διαφορετικά πρωτόκολλα. Η σύνδεση µε το ιαδίκτυο, µε τη χρήση φορητού τηλεφώνου, είναι επίσηςπολύ αργή και αναξιόπιστη λόγω του µικρού εύρου ζώνης, και έχει µεγάλο κόστος. Αυτό δεν δίνει την δυνατότητα σε ένα χρήστη να χάνει άσκοπα την ώρα του αναζητώνταςπληροφορίεςπου τον ενδιαφέρουν. Τα προβλήµατα αυτά µπορούν να περιγραφούν παραστατικά, µε ένα απλό σενάριο. Ας παρακολουθήσουµε λοιπόν τι κάνει ένας σύγχρονος χρήστηςτου διαδικτύου, που χρησιµοποιεί το ιαδίκτυο για να αξιολογεί και να αναλύει διάφορα δεδοµένα από το ιαδίκτυο που τον βοηθάνε στην διεκπεραίωση τηςεργασίαςτου. Ο Α αρχίζει την µέρα του µαθαίνονταςτι έχει συµβεί. Σηµαντικό είναι να αναφέρουµε ότι ο Α γνωρίζει τι αναζητεί αλλά δεν ξέρει σε ποια µηνύµατα θα το βρεί. Για παράδειγµα ξέρει ότι από µια ταχυδροµική λίστα που έχει σχέση µε την XML θα βρει θέµατα σχετικά µε την XML. Αυτόςάλλωστε είναι και ο λόγοςπου αυτόςο χρήστηςεγγράφεται σε αυτή την ταχυδροµική λίστα. Ωστόσο ο χρήστηςδεν γνωρίζει πότε τα µηνύµατα αυτήςτης ταχυδροµικήςλίσταςθα περιέχουν θέµατα σχετικά µε τα ενδιαφέροντα του. Για αυτό τον λόγο αναγκάζεται να διαβάσει ένα ένα τα µηνύµατα και να σβήσει αυτά που δεν τον ενδιαφέρουν. Στην συνέχεια χρησιµοποιεί τον φυλλοµετρητή (WWW browser) για να πλοηγηθεί σε διάφορουςκόµβουςwww, που παρέχουν ειδήσεις, ανακοινώσειςκαι άλλα θέµατα που τον ενδιαφέρουν. Ο χρήστηςκάνει την πιο πάνω διαδικασία χρησιµοποιώνταςείτε διευθύνσειςπου έχει αποµνηµονεύσει (URLs) µε την χρήση καταχωρηµένων σελιδοδεικτών (Bookmarks) είτε µε την χρήση κάποιαςµηχανής αναζήτησης. Και πάλι βλέπουµε ότι ο χρήστηςδιεξάγει µια µηχανική σειρά κινήσεων. Επίσηςβλέπουµε και πάλι ότι ο χρήστηςξέρει καλά τι γυρεύει αλλά δεν -58-

69 ξέρει σε πιο ή σε ποια σηµεία, από αυτά που γυρεύει, θα το βρει. Τελικά ο Α χρησιµοποιεί πρόγραµµα ανάγνωσης USENET Newsgroups για να διαβάσει άρθρα σχετικά µε τα ενδιαφέροντα το. Στην πιο πάνω προσπάθεια ανεύρεσηςπληροφοριών ο Α είναι αναγκασµένοςνα χρησιµοποιήσει διαφορετικά εργαλεία λογισµικού µε διαφορετικέςαλληλεπιδραστικές αλληγορίες (metaphors), πράγµα που αυξάνει τον γνωστικό φόρτο του (cognitive load). Επιπλέον όσο αναζητά και διαβάζει τιςπληροφορίεςπου συλλέχθηκαν µέσω ηλεκτρονικού ταχυδροµείου, πλοήγησηςστο WWW, µηχανών αναζήτησηςκτλ, οα εύκολα αποπροσανατολίζεται και χάνεται στον Κυβερνόχωρο. Αυτό βέβαια το φαινόµενο µπορεί να είναι κάποτε βοηθητικό. ηλαδή σε πολλούςχρηστέςαρέσει να «χάνονται» στον Κυβερνόχωρο για να βρίσκουν διάφορεςπληροφορίεςπου δεν ήξεραν αρχικά ότι τους ενδιέφεραν αλλά το ανακαλύπτουν αφού µελετήσουν το δεδοµένο κείµενο. Αυτό ισχύει γενικά για χρηστέςπου δεν ξέρουν τι ακριβώςγυρεύουν αλλά όχι και για τον A όπου προτεραιότητα έχουν οι πληροφορίεςπου σίγουρα ξέρει ότι τον ενδιαφέρουν. Τα προβλήµατα αυτά διογκώνονται όταν ο A µετακινείται συχνά. Ευρισκόµενοςµακριά από την βάση του, ο Α δεν έχει πρόσβαση στο επιτραπέζιο υπολογιστικό του περιβάλλον, όπου διατηρεί το προσωπικό του πληροφοριακό οδηγό (personal information roadmap), δηλαδή τα εργαλεία ανάκτησηςτων πληροφοριών. Ετσι, αναζητεί τιςπληροφορίεςπου τον ενδιαφέρουν χωρίςτον πληροφοριακό του οδηγό, µε κάποια συσκευή κινητού υπολογισµού (personal digital assistant) ή κάποιο φορητό υπολογιστή, διάµεσου µιαςαργήςσύνδεσηςµε το ιαδίκτυο. 6.2 Προτεινόµενη Λύση Όλα αυτά τα προβλήµατα θα µπορούσαν να ξεπεραστούν αν υπήρχε τρόποςνα δηµιουργήσουµε ένα αυτοµατοποιηµένο σύστηµα συλλογής, κοσκινίσµατος, αποθήκευσηςκαι διαχείρισηςτων πληροφοριών που συγκεντρώνει ο επενδυτήςαπό τις διάφορεςπηγέςπου είναι διαθέσιµεςστο ΠΠΠ. Το σύστηµα αυτό θα πρέπει να δουλεύει ακόµα κι όταν ο χρήστηςδεν είναι ενωµένοςστο ιαδίκτυο. Θα πρέπει να γνωρίζει τα ενδιαφέροντά του και ανάλογα να συλλέγει και να επεξεργάζεται πληροφορίεςαπό το ΠΠΠ. Θα µπορεί να διαβάζει όλα τα µηνύµατα του χρήστη από -59-

70 ηλεκτρονικό ταχυδροµείο και newsgroups και αυτόµατα να φυλάγει όσα θα ενδιαφέρουν, αγνοώνταςτα υπόλοιπα. Θα ήταν ακόµη επιθυµητό το σύστηµα να κατατάσσει όλεςτιςπληροφορίεςανάλογα µε τη βαρύτητα, το βαθµό του ενδιαφέροντοςπου παρουσιάζουν στο χρήστη, το επείγον τηςπληροφορίαςκαι άλλα. Χρειάζεται δηλαδή µια µετατόπιση πρότυπου (paradigm shift) από τα τρέχοντα δικτυακά συστήµατα και τον Παγκόσµιο Ιστό (WWW) προςδικτυακά συστήµατα επόµενηςγενεάς. Συγκεκριµένα, προβλέπεται ανάγκη µετάβασης: Από συστήµατα προσανατολισµένα στιςδιάφορεςυπηρεσίεςκαι πρωτόκολλα του ιαδικτύου (π.χ newsgroups, ing lists, WWW) σε συστήµατα ανθρωποκεντρικά και πληροφοριό-κεντρικά δηλαδή προσανατολισµένα στιςπληροφοριακέςανάγκεςτων χρηστών Από αρχιτεκτονικέςβασισµένεςστο µοντέλο τηςανάκτησηςπληροφοριών µε αιτήσεις (information pull) σε αρχιτεκτονικέςεκποµπήςπληροφοριών (information push) µε την χρήση ευφυών πρακτόρων. Με αυτό τον τροπο µετακινούµε το κλασσικό τροπο ανάκτησηςπληροφοριών από το διαδικτύου, όπου δεν έχουµε τον χρήστη να ανατρέχει προςτην πληροφορία αλλά η πληροφορία προςαυτόν Από την υποστήριξη χρηστών µε διασυνδετικότητα σταθερού δικτύου (fixed network connection), στην δυνατότητα ευέλικτηςπροσαρµογήςσε διαφορετικέςδιασυνδετικοτητέςχρηστών ( σταθερού δικτύου και κινητές mobile connectivity Από συστήµατα που υλοποιούν την κωδικοποίηση δεδοµένων µε χρήση διαφορετικών τεχνολογιών (π.χ διαφορετικά databases µε διαφορετικά drivers σε διαφορετικέςπλατφόρµεςή text files µε ειδικέςδοµές) σε συστήµατα µε ενιαίο τροπο περιγραφήςτων δεδοµένων που µπορεί εύκολα να γινει αντιληπτόςαπό τουςκινητούςπράκτορες. -60-

71 Έχονταςένα τέτοιο σύστηµα, θα ήταν αρκετό για το χρήστη να έχει µια απλή πρόσβαση σε αυτό, µέσω τηςοποίαςνα παίρνει όλα τα δεδοµένα που έχει µαζέψει για αυτόν το σύστηµα. Η ενηµέρωση αυτή θα είναι γρήγορη και φθηνή γιατί οι πληροφορίεςθα είναι ήδη συγκεντρωµένεςκαι η ανάγκη σε εύροςζώνηςγια την µετάδοσή τουςµικρή. Θα ήταν επίσηςεπιθυµητό η υποδοµή που θα χρειαζόταν για µια τέτοια σύνδεση να µην απαιτεί ειδική διαρρύθµιση κάποιαςσυγκεκριµένηςµηχανής (που να πρέπει να την έχει πάντα µαζί του ο χρήστης). Θα πρέπει µε µια απλή πρόσβαση στο ιαδίκτυο και τη χρησιµοποίηση ίσωςενόςφυλλοµετρητή, να µπορεί να έχει αυτή τη σύνδεση στο σύστηµα. Η σχεδίαση και η υλοποίηση µιαςτέτοιαςλύσηςπαρουσιάζει ερευνητικό ενδιαφέρον διότι [Witt96] : Υπάρχει πληθώρα συνεχώςµεταβαλλόµενων και γενικά ανοργάνωτων πηγών πληροφοριών. Υπάρχουν πολλά ήδη πληροφοριών (τιµέςµετοχών, χρηµατιστηριακά νέα, περιοδικέςαναφορέςεταιριών κτλ) και σε διαφορετικέςµορφές(βάση δεδοµένων, HTML, XML, s, Ticker-tapes κτλ). Η επικαιρότητα των πληροφοριών είναι πολύ σηµαντική και πολλέςφορές διαφέρει ανάλογα µε τα ενδιαφέροντα των χρηστών. Η ευκολία πρόσβασηςσε πληροφορίεςδεν είναι πάντα ελεύθερη και δωρεάν. Ένα σύστηµα κινητών πρακτόρων µπορεί να προσφέρει πολλά πλεονεκτήµατα στη δηµιουργία ενόςσυστήµατοςσυλλογήςκαι διαχείρισηςπληροφοριών. Ένα σύστηµα πρακτόρων χαρακτηρίζεται ωςενεργό, αυτόνοµο και αρθρωτό (modularized) [WP98]. Ενεργό µε την έννοια ότι παράγει πληροφορίεςκαι αυτόνοµο µε την έννοια ότι έχει ανθρωπόµορφη συµπεριφορά. Κάθε πράκτοραςέχει ξεκάθαρο ρόλο στη δοµή του όλου συστήµατοςπράγµα που διευκολύνει την όλη διαδικασία ανάπτυξηςτου, από την ανάλυση και το σχεδιασµό µέχρι την υλοποίηση και την µελλοντική επέκταση του (σε αντίθεση µε κατανεµηµένα συστήµατα τύπου Πελάτη-Εξυπηρετητή) και γιατί το κόστοςανάπτυξηςενόςσυστήµατοςκινητών πρακτόρων (οικονοµικό, χρονικό, υλικό) -61-

72 είναι χαµηλό. Άλλα πλεονεκτήµατα απορρέουν από τιςδυνατότητεςσυνεργασίαςτων πρακτόρων, τηςεκµετάλλευσηςτου ιαδικτύου, τηςενσωµάτωσηςευφυίαςστον κώδικά τουςκαι άλλα. Παρόλο που οποιοδήποτε σύστηµα κινητών πρακτόρων µπορεί να προσφέρει τα πιο πάνω πλεονεκτήµατα, κρίνουµε ότι το σύνολο πακέτων Concordia είναι σε θέση να προσφέρει ακόµη µερικά. Η συνεργασία µεταξύ πρακτόρων είναι σε µεγάλο βαθµό αυτοµατοποιηµένη. Το Concordia παρέχει ένα ευέλικτο και δυναµικό σύστηµα επικοινωνίαςµεταξύ όλων των µερών ενόςσυστήµατος, προσφέρει ασφάλεια των δεδοµένων και τηςµηχανής, αυτόµατη ανάκτηση τηςπροηγούµενηςκατάστασηςµετά από κατάρρευση του συστήµατοςκαι την ευχέρεια δηµιουργίαςπρογραµµάτων Service Bridges. 6.3 Οι σχεδιαστικοί στόχοι του erace Στη συγκεκριµένη διπλωµατική εργασία, θέλουµε να διερευνήσουµε και να επεκτείνουµε την αρχιτεκτονική που έχει προταθεί στο [DG99] και στην συνέχεια να την προσαρµόσουµε στο σύστηµα Concordia και να υλοποιήσουµε ένα πρωτότυπο µε χρήση κινητών πρακτόρων Concordia που θα υλοποιούν χάρτεςτηςµετά-πληροφορίας (DOM document object model), µέσα στιςµεθόδουςτους, και οι οποίοι χάρτεςθα τουςτροφοδοτούν µε τιςκατάλληλεςπληροφορίεςγια να διεκπεραιώσουν κάποιες διεργασίες.toσύστηµα που προτείνουµε ονοµάζεται erace (extensible Retrieval Annotation Caching Engine). Το πρωτότυπο έχει τη βασική λειτουργικότητα του συστήµατοςη οποία είναι: Καταχώρηση στο σύστηµα (User Registration) και δηµιουργία του Profile. Login στο σύστηµα Ευφυή Χρονοπρογραµµατισµό και χρονοδροµολόγηση των διεργασιών µετά την επεξεργασία των profiles των χρηστών του συστήµατος, µε βάση τους διαθέσιµουςπόρουςκαι µε βάση την ζήτηση των πόρων (πχ πολλαπλές αιτήσειςθα εξυπηρετούνται µε µια διεργασία). Η διεργασίεςαυτέςθα είναι σε µορφή αιτήσεων προςτουςproxy Servers (Information Proxies) που -62-

73 µπορεί να είναι τοπικοί αλλά και αποµακρυσµένοι και οποίοι έχουν και τον ρόλο τηςεπεξεργασίας(information brokers) [BDH95] και αποθήκευσηςτων δεδοµένων στην cache. Αποµνηµόνευση στην φυσική κρυφή µνήµη των δεδοµένων που θεωρούνται ότι αφορούν καποιο χρήστη και την µέτα-περιγραφή αυτών των δεδοµένων. Η µέτα-πληροφορία αναπαραστά το περιεχόµενο τηςπραγµατικήςcache, και αυτή θα βρίσκεται στην µνήµη για εξυπηρέτηση πολλαπλών πρακτόρων που ζητάνε πληροφορίεςαπό την cache για να επιτελέσουν το έργο τους Υλοποίηση τριών βασικών υπηρεσιών: 1. Τηςπρόσβασηςκαι ανάληψη τιµών µετοχών βάση του Profile των χρηστών από µια αποµακρυσµένη Βάση εδοµένων στο υαδίκτυο, διακινώνταςχμl δοµέςδεδοµένων των αποτελεσµάτων (DOMs) 2. Τηςαναζήτησης, συλλογής, φιλτραρίσµατοςκαι αποθήκευσης πληροφοριών από το ΠΠΠ, Usenet s, ing lists. 3. Του συνδυασµού των πιο πάνω σε συγκεκριµένα σενάρια. ιαδικασία ένωσηςτου χρήστη µε το σύστηµα και ενηµέρωσήςτου, µε την χρήση ευφυών πρακτόρων που θα ενηµερώνουν τον χρήστη µε πληροφορίες σχετικά µε τα ενδιαφέροντα του. Σηµαντικό ρόλο στη σχεδίαση παίζει και η παράµετροςτηςεπεκτασιµότητας., και για αυτό έχει επιλεγεί η γλώσσα περιγραφήςτων δεδοµένων ΧΜL. Με τον όρο επεκτασιµότητα εννοούµε την ευκολία πρόσθεσηςνέων υπηρεσιών στο σύστηµά µας µε το ελάχιστο δυνατό κόστοςαπό προγραµµατιστικήςπλευράςκαι βαθµό επέµβασης στον υπάρχοντα κώδικα. Θέλουµε επίσηςη προσθήκη νέων υπηρεσιών να µην επιβαρύνει την λειτουργικότητα του συστήµατοςή τον χρήστη καθ οποιονδήποτε τρόπο. 5.4 Αρχιτεκτονική erace Το σύστηµα erace είναι βασισµένο σε µια αρχιτεκτονική δύο επιπέδων. Το πρώτο επίπεδο αφορά στην αλληλεπίδραση µε το χρήστη και το δεύτερο επίπεδο µε τη -63-

74 συλλογή και αποθήκευση των πληροφοριών. Πιο συγκεκριµένα, το πρώτο επίπεδο διαχειρίζεται το Profile των χρηστών, τη διαδικασία πρόσβασηςστο σύστηµα και την ενηµέρωση του χρήστη. Στο δεύτερο επίπεδο υπάρχουν οι διαδικασίες χρονοπρογραµµατισµού των διεργασιών, και τηςσυλλογής, επιλογήςκαι αποθήκευσης των πληροφοριών. SMS WebPhone WAP Personal PC CLIENTS erace Server 1st Tier (PUSH AGENTS) +SMS Alerter +SMTPAlerter Web Server (PULL AGENTS) Personal WorkSpace PIR Personal Information RoadMap Servlet Library Users List Manager Service Bridge RESOURCES ACI ACI Profiles in XML URD DB User List XML File 2nd Tier FTP SCHEDULER URDs URDs HTTP PROXY SERVER Information Broker NNTP URDs ACI POP3 PROXY SERVER Information Broker HTTP Proxies Annotation ACI CACHE ANNOTATED CACHE MANAGER URDs ACI ACI ACI NNTP PROXY SERVER Information Broker DATABASE PROXY SERVER Information Broker Gopher POP3 Figure 1: H Αρχιτεκτονική του erace Τα µέρη του πρώτου επιπέδου είναι: 1. Ο PIR (Personal Information Roadmap) [Login, Registration, Personal Workspace] 2. Ο Users List Manager 3. Ο Alerter (SMTP,SMS) Το δεύτερο επίπεδο αποτελείται από -64-

75 1. Τον Scheduler 2. Τους Proxy Servers 3. Τον Annotation Cache Manager και την ACI XML Cache. Η αλληλεπίδραση των συστατικών αυτών µερών φαίνεται στο σχήµα που ακολουθεί: Στα επόµενα κεφάλαια αναλύουµε αναλυτικά την αρχιτεκτονική, λειτουργία και υλοποίηση του κάθε συστατικού µέρους της αρχιτεκτονικής µας. -65-

76 Κεφάλαιο 7 Εξυπηρετητής Χρηστών - Κατάστιχο Ενδιαφερόντων - Χρονοδροµολογητής 7.1 Ο Εξυπηρετητής Χρηστών 66 a. Εισαγωγή 66 b. Περιγραφή XML καταλόγου χρηστών Το Κατάστιχο Ενδιαφερόντων 68 a. Προσωπικές Πληροφορίες 69 b. Πληροφορίες Ενηµέρωσης του Χρήστη 69 c. Πληροφορίες σχετικά µε την πηγή της πληροφορίας 70 d. Τι είναι το URD (Unified Resource Description) 71 e. Tο URD ΑPI (API Application Protocol Interface) Υλοποίηση του Χρονοδροµολογητή Εξυπηρετητής Χρηστών a. Εισαγωγή Ο εξυπηρετητής χρηστών είναι ένα Concordia Service Bridge το οποίο έχει την αρµοδιότητα να διαχειρίζεται την λίστα των χρηστών που είναι εγγεγραµµένοι στο σύστηµα. Hλίστα αυτή είναι ένα XML αρχείο Accounts.xml (βλέπε σχήµα 2). Ο εξυπηρετητής αυτός τροφοδοτείτον Scheduler µε την νέα ανανεωµένη λίστα των χρηστών του συστήµατος, µετά από αίτηση του Scheduler. Ο Εξυπηρετητής Χρηστών λαµβάνει επίσης αιτήσεις από τo registration servlet (servletregister) µε τις οποίες αιτήσεις καλείται να καταχωρήσει ένα νέο χρήστη µέσα στο Accounts.xml. Στο σχήµα 1 φαίνονται µε έντονες γραµµές ο διαχειριστής χρηστών των -66-

77 συστήµατος, η XML βάση δεδοµένων των προφίλ των χρηστών και ο Χρονοδροµολογητής. SMS WebPhone WAP Personal PC CLIENTS erace Server 1st Tier (PUSH AGENTS) +SMS Alerter +SMTPAlerter Web Server (PULL AGENTS) Personal WorkSpace PIR Personal Information RoadMap Servlet Library Users List Manager Service Bridge RESOURCES ACI ACI Profiles in XML URD DB User List XML File 2nd Tier FTP SCHEDULER URDs URDs HTTP PROXY SERVER Information Broker NNTP URDs ACI POP3 PROXY SERVER Information Broker HTTP Proxies Annotation ACI CACHE ANNOTATED CACHE MANAGER URDs ACI ACI ACI NNTP PROXY SERVER Information Broker DATABASE PROXY SERVER Information Broker Gopher POP3 Figure 1: Η Αρχιτεκτονική του συστήµατος σε 2 επίπεδα b. Περιγραφή XML Καταλόγου Χρηστών Ο κατάλογος χρηστών (User List) περιγράφει πληροφορίες σχετικά µε την τοποθεσία του erace server καθώς πληροφορίες για τον αριθµό των χρηστών στο σύστηµα και πληροφορίες για την τοποθεσία των προφίλ των χρηστών. Accounts Meta Description <!ELEMENT Accounts (Account*)> <!ATTLIST Accounts id ID #REQUIRED location CDATA #REQUIRED maxaccounts CDATA #REQUIRED locked (false true) "false"> <!ELEMENT Account EMPTY> <!ATTLIST Account id ID #REQUIRED state (false true) "true" docbase CDATA #REQUIRED> Figure 2: Η γραµµατική του Accounts.xml -67-

78 <?xml version= "1.0" encoding ="ISO "?> <!-- Import Cache.dtd --> <!DOCTYPE Accounts SYSTEM "accounts.dtd"> <Accounts id="account_on_ada" location=" maxaccounts="1000" locked="false"> <Account id="csyiazt1" state="true" docbase="/accounts" connected="false" rmi="rmi://unix/myagent2"/> <Account id="csmarinos" state="true" docbase="/accounts" connected="true" rmi=""/> <Account id="csa" state="false" docbase="/accounts" connected="false" rmi="rmi://unix/myagent2"/> <Account id=" csb " state="true" docbase="/accounts" connected="true" rmi=""/> <Account id=" csd " state="true" docbase="/accounts" connected="false" rmi="rmi://unix/myagent2"/> <Account id=" cse " state="true" docbase="/accounts" connected="true" rmi=""/> </Accounts> Figure 2: XML παράδειγµα του αρχείου Accounts.xml Το ιδιοχαρακτηριστικό id αποθηκεύει τον κωδικό πρόσβασης του χρήστη στο σύστηµα. Το συνθηµατικό αυτό είναι κλειδί (key) για την αναγνώριση του προφίλ του χρήστη στο σύστηµα (π.χ για id= csyiazt1 το προφίλ του θα λέγεται csyiazt1.xml). To state υποδηλώνει ποιοι χρήστες είναι ενεργοί. Οι χρήστες που αποχώρησαν (unregistered) από το σύστηµα έχουν µαρκαριστεί µε false στο πεδίο state. To ιδιοχαρακτηριστικό docbase δείχνει το ευρετήριο (directory) στο οποίο βρίσκεται το προφίλ του χρήστη. Τα τελευταία δύο ιδιοχαρακτηριστικά (connected,rmi), χρησιµοποιούνται αν ο χρήστης ενωθεί µε Concordia Applets στο σύστηµα, οπόταν η µεταγωγή δεδοµένων δεν γίνεται µε το πρωτόκολλο HTTP αλλά µε το πρωτόκολλο RMI. 7.2 Κατάστιχο Ενδιαφερόντων (profile) To κατάστιχο ενδιαφερόντων (user profile), αποτελεί βασικό συστατικό συστηµάτων φιλτραρίσµατος και προώθησης της πληροφορίας. To προφίλ του χρήστη, το οποίο είναι κωδικοποιηµένο µε την γλώσσα περιγραφής δεδοµένων ΧΜL, περιλαµβάνει 3 ειδών πληροφορίες a. Προσωπικές Πληροφορίες για τον χρήστη Personal Data b. Πληροφορίες για το τρόπο ενηµέρωσης του χρήστη - Notification Options. c. Πληροφορίες σχετικά µε την πηγή της πληροφορίας - Sources -68-

79 a. Προσωπικές Πληροφορίες Personal Data Εδώ κωδικοποιούµε τις πληροφορίες που καταχωρεί κάποιος χρήστης κατά την διάρκεια εγγραφής (registration) στο σύστηµα, ή κατά την διάρκεια ενηµέρωσης του προφίλ του. Η πληροφορίες αυτές έχουν την ακόλουθη XML σύνταξη. DTD γραµµατική <!ELEMENT personal (name,surname, ,phone?,fax?,mobile?)> <!ELEMENT name (#PCDATA)> <!ELEMENT surname (#PCDATA)> <!ELEMENT (#PCDATA)> <!ELEMENT phone (#PCDATA)> <!ELEMENT fax (#PCDATA)> <!ELEMENT mobile (#PCDATA)> XML δεδοµένα <personal> <name>demetris</name> <surname>zeinalipour</surname> <phone> </phone> <mobile> </mobile> </personal> b. Πληροφορίες για τον τρόπο ενηµέρωσης του χρήστη - Notification Options. H ενηµέρωση του χρήστη από το σύστηµα πρέπει να γίνεται µε κάποιο ευφυή τρόπο, και µε βάση τα χαρακτηριστικά τα οποία µπορεί να προκαθορίσει ένας χρήστης. Η ενηµέρωση του χρήστη καθορίζεται από τις παρακάτω παραµέτρους: 1. Την εκάστοτε συνδετικότητα του χρήστη - Connection Modality 2. Προτιµήσεις στο Σύστηµα ιαπροσωπείας του χρήστη σχετικά µε την διαθεσιµότητα του User Availability (Attention) 3. To επείγον της πληροφορίας Urgency of Information 4. Τον βαθµό συγγένειας της πληροφορίας µε τα ενδιαφέροντα του χρήστη - Relevance of Information Οι πρώτες δύο από τις παραπάνω παραµέτρους καθορίζονται µέσα στο προφίλ και αυτές οι επιλογές αφορούν όλες τις πληροφορίες. Με τις επόµενες δυο παραµέτρους -69-

80 χαρακτηρίζονται και διαβαθµίζονται οι πήγες πληροφοριών που ενδιαφέρουν τον χρήστη. Notification = ƒ (Connection Modality, User Availability, Urgency, Information Relevance) Ο τρόπος ενηµέρωσης του χρήστη από το σύστηµα είναι ένας από τους βασικούς παράγοντες που θα επηρεάσουν την αρχιτεκτονική και υλοποίηση του συστήµατος. Το Connection Modality που προσδιορίζει το διαθέσιµο προς τον χρήστη εύρος ζώνης που µε βάση τις προτιµήσεις του χρήστη καθορίζει την ποσότητα των πληροφοριών που θα του αποστέλλεται µε βάση την εκάστοτε σύνδεση του. Έτσι θα µπορεί να δοθεί µια καθαρή εικόνα στον User Notifier για το πως ο χρήστης µπορεί να λάβει τα µηνύµατα, και τις πληροφορίες. Το connection modality ορίζει την µορφή διασυνδετικότητας. Ορίζει δηλαδή τον τρόπο σύνδεσης του χρήστη µε το σύστηµα καθώς επίσης τα χαρακτηριστικά σύνδεσης του χρήστη (εύρος ζώνης και πρωτόκολλα) Το User Availability ορίζει ποτέ ένας χρήστης είναι ενωµένος µε το σύστηµα, και µε βάση τις προτιµήσεις του στο προφίλ, το σύστηµα θα µπορεί να γνωρίζει αν ένας χρήστης είναι διαθέσιµος να λάβει πληροφορίες. Ο χρήστης ορίζει για κάθε διαφορετικό τρόπο που ενηµερώνεται, τις προτιµήσεις του. Το Urgency καθορίζει πόσο επείγουσα είναι πληροφορία για ένα χρηστή Ο πιο σηµαντικός ίσως παράγοντας στην ενηµέρωση των χρηστών είναι επίσης o βαθµός συγγένειας της συλλεγόµενης πληροφορίας µε τα ενδιαφέροντα του χρήστη Relevance of Information. Η συγγένεια αυτή εκφράζεται ως το minimum similarity score το οποίο πρέπει να έχει µια πληροφορία η οποία συλλέγεται από τους proxy servers για να παραδοθεί στον χρήστη [YGM95]. Με αυτό τον τρόπο θα αποφύγουµε καταστάσεις όπου παρουσιάζεται είτε low recall, δηλαδή όταν το σύστηµα βρίσκει πολλές πληροφορίες που µας αφορούν να χάνουν οι χρήστες ορισµένες πληροφορίες, είτε low precision, δηλαδή όταν έχουµε λίγες πληροφορίες που αφορούν ένα χρήστη, να παραδίδεται στον χρήστη πληροφορία που δεν είναι πολύ σηµαντική.[cfg99] c. Πληροφορίες σχετικά µε την πηγή της πληροφορίας - Sources -70-

81 Οι πληροφορίες στο ιαδίκτυο βρίσκονται σε διαθέτες που εξυπηρετούν µε διαφορετικά πρωτόκολλα (WWW servers, NNTP servers, POP3 servers, βάσεις δεδοµένων) και διαφορετικά formats (π.χ Plain-Τext, Html, Xml, binary). Από την σκοπιά του χρήστη όλες οι πήγες είναι απλώς κόµβοι πληροφορίας. Βλέπουµε λοιπόν να υπάρχει µια άµεση ανάγκη για ολοκλήρωση (integration) όλων αυτών των διαφορετικών πηγών πληροφορίας. Για τον σκοπό αυτό έχουµε ορίσει µε XML µια γενικευµένη περιγραφή της πληροφορίας. Αυτή την περιγραφή την οποία ονοµάζουµε URD (Unified Resource Description), χαρακτηρίζει µια οποιαδήποτε πηγή πληροφορίας λαµβάνοντας επίσης υπόψη τα ιδιαίτερα χαρακτηριστικά των συστηµάτων φιλτραρίσµατος και προώθησης της πληροφορίας. Τι είναι το URD (Unified Resource Description); Όπως προαναφέραµε, στο profile του κάθε χρήστη θα ορίζονται οι διάφορες πηγές πληροφοριών που τον ενδιαφέρουν. Το URD δίνει την µετά-περιγραφή µιας πηγής πληροφορίας που ενδιαφέρει ένα χρήστη. Το URD είναι κωδικοποιηµένο σε ΧΜL, και κωδικοποιεί 3 ειδών πληροφορίες. Αυτές οι πληροφορίες είναι απαραίτητες για να περιγράψουν µια πηγή πληροφορίας που ενδιαφέρει τον χρήστη. Τα βασικά συστατικά του URD είναι: Πληροφορίες για την Πηγή Source Information Πληροφορίες για τι είδους επεξεργασίας πρέπει να τύχει µια πηγή - Processing Information Πληροφορίες για το επείγον παράδοσης της πληροφορίας - Urgency Ιnformation Τα τρία βασικά συστατικά του URD είναι ικανά να χαρακτηρίσουν όλες τις διαφορετικές πηγές πληροφορίας. Πιο κάτω δίδουµε τον ορισµό της γραµµατικής του URD και στην συνέχεια περιγράφουµε αναλυτικά κάθε στοιχείο του. -71-

82 URD Definition <!ELEMENT source (uri, type, keywords?, depth?, urgency)> <!-- Source (destination,extra information,processing type,retrieval method,filtering options --> <!ELEMENT uri (#PCDATA)> <!ATTLIST uri group CDATA #IMPLIED login CDATA #IMPLIED password CDATA #IMPLIED port CDATA #REQUIRED timing CDATA #REQUIRED lastcheck CDATA #REQUIRED> <!ELEMENT type EMPTY> <!ATTLIST type protocol (http pop3 nntp rmi) "http" method (push pull) "pull" processtype (filter nonfilter) "filter"> <!-- Processing - Filtering Info --> <!-- Urgency --> <!ELEMENT keywords (keyword+)> <!ELEMENT keyword EMPTY> <!ATTLIST keyword key CDATA #REQUIRED weight ( )"3"> <!ELEMENT depth EMPTY> <!ATTLIST depth level (1 2 3) "1"> <!ELEMENT urgency EMPTY> <!ATTLIST urgency urgent (1 2 3) "2"> URD sample 1) <source> <uri timing="2000" lastcheck = "10000" port= 80 > </uri> <type protocol="http" method="pull" processtype="filter" /> <keywords> <keyword key="ibmcorporation" weight="3"/> <keyword key="universitity" weight="4"/> </keywords> <depth level="1"/> <urgency urgent="1"/> </source> Το Source Information καθορίζει τα ιδιαίτερα χαρακτηριστικά κάθε πηγής, και ορίζεται µε ένα συνδυασµό των ιδιοχαρακτηριστικών του σηµαντήρα uri. Η περιγραφή του κάθε ιδιουχαρακτηριστικού είναι η εξής: login (#IMPLIED-προαιρετικό). Αν η δεδοµένη πηγή απαιτεί κωδικό πρόσβασης (π.χ ) τότε αυτός ο κωδικός µπορεί να καταχωρηθεί σε αυτό το ιδιοχαρακτηριστικό. -72-

83 password (#IMPLIED-προαιρετικό). Αν η δεδοµένη πηγή απαιτεί συνθηµατικό πρόσβασης (π.χ ) τότε αυτό το συνθηµατικό µπορεί να καταχωρηθεί σε αυτό το ιδιοχαρακτηριστικό. port (#REQUIRED-υποχρεωτικό). Η πύλη του εξυπηρετητή από την οποια θα εξυπηρετηθεί η URD αίτηση. Οι τετριµµένες τιµές για αυτό το πεδίο είναι (ΗΤΤP:80, POP3:110, NNTP:119) timing (#REQUIRED-υποχρεωτικό). Την συχνότητα εκτέλεσης αυτής της URD αίτησης. Η συχνότητα αυτή ορίζεται σε milliseconds και είναι το χρονικό διάστηµα που θα µεσολαβήσει µέχρι την επόµενη εκτέλεση αυτής της URD αίτησης, από την χρονική στιγµή lastcheck. lastcheck (#REQUIRED-υποχρεωτικό). Η τελευταία χρονική στιγµή εκτέλεσης αυτής της URD αίτησης. Η τιµή αυτή ορίζεται σε milliseconds και υποδεικνύει στο σύστηµα πότε εκτελέστηκε για τελευταία φορά αυτή η URD αίτηση. Το Processing Information, καθορίζει τις απαιτήσεις του χρήστη σχετικά µε την συγγένεια που πρέπει να έχει η πληροφορία µε τα ενδιαφέροντα του. To Processing Information αναπαρίσταται µε µια απλή διανυσµατική παρουσίαση των ενδιαφερόντων ενός χρήστη ή γενικότερα κάποιο query D = <(t i,w i ),,(t k,w k )> (πχ <(mobile,40), (agents,60)>) όπου t i είναι µία λέξη κλειδί και w i το βάρος που της ορίζει ο χρήστης. Τρίτο στοιχείο είναι το Urgency Ιnformation, που ορίζει τα ενδιαφέροντα ενός χρήστη συναρτήσει του χρόνου. ) Τo URD ΑPI (Unified Resource Description Application Protocol Interface) Τα URD ΑPI (Unified Resource Description Application Protocol Interface) είναι ένα σύνολο µεθόδων µε τις οποίες µπορούµε να αντλήσουµε και να -73-

84 εισάγουµε µε ένα διαφανή (transparent) τρόπο πληροφορίες µέσα από ένα URD Element και κατ επέκταση µέσα στο DOM [DOM198] ενός προφίλ (1 προφίλ περιέχει πολλά URD Elements). Μπορεί να χαρακτηριστεί σαν ένα σύνολο από µεθόδους για να κάνουµε queries πάνω στην XML δοµή δεδοµένων URD. Τo URD- API χρησιµοποιείται από όλες τις οντότητες του συστήµατος που διαχειρίζονται URD Elements Το URD-API είναι υλοποιηµένο στην Java, και κάνει χρήση διαδικασιών και συναρτήσεων µιας βοηθητικής και γενικότερης βιβλιοθήκης η οποία ονοµάζεται XMLUtils. Σε αυτή την βιβλιοθήκη έχουµε ορίσει ενότητες κώδικα οι οποίες µας βοηθούν να κάνουµε γενικότερες XML διαδικασίες Πιο κάτω φαίνονται µερικές από τις Μεθόδους του URD-ΑPI. public class URDUtils { public static String geturi_location(element urde) { NodeList urinl = urde.getelementsbytagname("uri"); Element uri = (Element)uriNL.item(0); return uri.getattribute("location"); } public static String geturi_port(element urde) { NodeList urinl = urde.getelementsbytagname("uri"); Element uri = (Element)uriNL.item(0); return uri.getattribute("port"); } public static String gettype_protocol(element urde) { NodeList typenl = urde.getelementsbytagname("type"); Element type = (Element)typeNL.item(0); return type.getattribute("protocol"); } public static Vector getkeywords(element urde) { Vector keywords = new Vector(); NodeList keywordsnl = urde.getelementsbytagname("keywords"); Element e = (Element)keywordsNL.item(0); for (int z=0; z < Xml1Utils.getElementSize(e, "keyword"); z++) { keywords.addelement(xml1utils.returnsubvalueattr(e,"keyword",z,"key")); } return keywords; } Figure 9: Υποσύνολο των µεθόδων του URD ΑPI -74-

85 7.3 Υλοποίηση Χρονοπρογραµµατιστή Ο Χρονοπρογραµµατιστή είναι υπεύθυνος να ανατρέχει περιοδικά τα προφίλ των χρηστών και να εκτελεί όσα URD elements χρειάζονται ανανέωση. Ο Scheduler είναι υλοποιηµένος σαν ένα Concordia Service Bridge (Scheduler Service) που µε την χρήση ενός Java Thread ξυπνά κάθε ορισµένο διάστηµα και εκτελεί την διαδικασία που φαίνεται στο σχήµα 10. Σχεδιάσαµε δύο προσεγγίσεις για την επίλυση του θέµατος του χρονοπρογραµµατισµού: 1. User Oriented Scheduling 2. Resource-Oriented Scheduling User Oriented Scheduling Η πρώτη προσέγγιση προβλέπει µια διεργασία (Thread), η οποία παίρνει συνεχώς τη λίστα των κωδικών από τον Users List Manager και ανατρέχει σειριακά τα προφίλ αυτών των χρηστών. Για κάθε χρήστη, διαβάζει το Profile του και στέλνει τις ανάλογες URD αιτήσεις προς τους διαµεσολαβητές. Σε αυτή την προσέγγιση ο Χρονοδροµολογητής βρίσκει από το προφίλ του χρήστη τις πηγές που πρέπει να ανανεωθούν. Το κριτήριο για την επιλογή αυτών των URDs είναι ιδιοχαρακτηριστικό lastcheck, του κάθε URD. O τρόπος πρόσβασης στα προφίλ είναι υλοποιηµένος µε το DOM αλλά υπολογίζεται σε µελλοντική έρευνα να αντικατασταθεί από το SAX γιατί ετσι θα είναι αποδοτικότερη η διαδικασία αυτή. Πλεονέκτηµα αυτής της µεθόδου είναι ότι το γεγονός ότι είναι απλή, αφού δεν χρειάζεται να κάνουµε περίπλοκα queries για να βρούµε και να συγκεντρώσουµε τις πηγές που χρειάζονται ανανέωση. Το µειονέκτηµα ωστόσο είναι ότι έχουµε άσκοπη µεταγωγή µηνυµάτων. Για παράδειγµα αν 2 χρήστες ζητάνε την ίδια ιστοσελίδα την ίδια χρονική στιγµή, θα δηµιουργηθούν 2 URD αιτήσεις. Παρόλο αυτά πρέπει να αναφέρουµε ότι το αντικείµενο θα ανακτηθεί µόνο µια φορά από το ιαδικτυο, λόγω της αρχιτεκτονικής των διαµεσολαβητών. Πιο κάτω φαίνεται µε την χρήστη ενός διαγράµµατος ροής η διαδικασία εκτέλεσης του User-Oriented Scheduling -75-

86 User Oriented Scheduling STARTING SERVICE Initialization 1) Connect to bridge 2) Posting Event 3) Event Listener + Users DOM + Username Vector [FIGI Login Service] Event Retrieve Users Traversing Sequentially Profiles Create Account Profile DOM Profiles.xml NO RETRIEVE URD source from Profile DOM if (Current Time) > (lastcheck+timing) YES NEXT URD Post NNTP EVENT if required URD Request [FIGI NNTP Service] Event Retrieve NNTP news NEXT ACCOUNT Post POP3 EVENT if required URD Request [FIGI POP3 Service] Event Retrieve POP3 s Post HTTP EVENT if required URD Request [FIGI Cache Service] Event Exist URL Save Account I/O TimeStamping URD source Saving Account Figure 10: ιάγραµµα Ρoής του User Oriented Scheduling Resource-Oriented Scheduling Η δεύτερη προσέγγιση έχει σκοπό να λύσει τα προβλήµατα τις πρώτης. Βασική ιδέα είναι να µαζέψει ο χρονοδροµολογητής σε κάποια χρονική στιγµή Α πρώτα όλες τις HTTP αιτήσεις µετά όλες τις NNTP και τέλος όλες τις POP3. Αυτές οι αιτήσεις θα είναι σε µορφή µιας URD λίστας. Στην συνέχεια θα φιλτράρει αυτή την λίστα για να µην υπάρχουν διπλές αιτήσεις, και θα προωθήσει ολόκληρη την λίστα προς τον Proxy Server. Με αυτό τον τρόπο θα µειώσουµε σηµαντικά την µεταγωγή µηνυµάτων (Events). Μειονέκτηµα αυτής της µεθόδου είναι ότι θα δηµιουργήσουµε απότοµο φόρτο στον διαµεσολαβητή που θα λάβει την ίδια χρονική στιγµή πολλές -76-

87 αιτήσεις. Άλλο µειονέκτηµα είναι ότι πρέπει να ανατρέχουµε όλα τα προφίλ τρεις φορές (1 για ΗΤΤP, 1 για ΝΝΤP, 1 για POP3) παρά 1 φορά όπως την πρώτη περίπτωση. Στο πρωτότυπο δεν υλοποιήσαµε την δεύτερη µέθοδο παρά µόνο την πρώτη λόγω έλλειψης χρόνου. Προβλέπεται ωστόσο σε µελλοντική έρευνα να γίνει πειραµατική ανάλυση των δυο µεθόδων για να εξαχθεί η καλύτερη µέθοδος. -77-

88 Κεφάλαιο 8 Περιγραφή ιαµεσολαβητή POP3 8.1 Εισαγωγή H Αρχιτεκτονική του ιαµεσολαβητή. 80 a. Περιγραφή Ευρετηρίου Αποµνηµόνευσης. 80 b. Περιγραφή Λειτουργίας Υλοποίηση του ιαµεσολαβητή. 84 a. Ενδο-επικοινωνία εδοµένων. 85 b. Τρόπος Μεταγωγής εδοµένων στις εξωτερικές οντότητες. 86 c. Αλγόριθµοι ανάκτησης και τοποθέτησης δεδοµένων στο Index Εισαγωγή H ιαµεσολαβητής POP3 είναι το δοµικό στοιχείο της υπηρεσίας Ηλεκτρονικού Ταχυδροµείου που προσφέρει το σύστηµα. Ο ιαµεσολαβητής POP3 [Ros91] (RFC Post Office Protocol version 3) είναι υπεύθυνος να εξυπηρετεί όλες τις URD αιτήσεις που έχουν σχέση µε το πρωτόκολλο POP3. Ο ιαµεσολαβητής αυτός αναλαµβάνει να κάνει την πιο κάτω σειρά ενεργειών: Να ανακτήσει πληροφορίες από λογαριασµούς ηλεκτρονικού ταχυδροµείο ( accounts). Να επεξεργαστεί τις ανακτηµένες πληροφορίες βάση της αίτησης URD και αν ενδιαφέρουν τον χρήστη να τις φυλάξει στον τοπικό δίσκο του διαµεσολαβητή (caching). Να δηµιουργήσει µια µέτα-περιγραφή της συλλεγόµενης πληροφορίας (ACI Element) και να ενηµερώσει την Annotation Cache. -78-

89 Να δηµιουργήσει ένα ιστορικό αποµνηµόνευσης της ως τώρα εργασίας του (index). Αυτό πρέπει να γίνεται για να θυµάται oδιαµεσολαβητής τι έχει διαβάσει και επεξεργασθεί από τον κάθε λογαριασµό µε τον οποίο επικοινώνησε στο παρελθόν. Τέλος πρέπει να προσφέρει µηχανισµούς για συλλογή και αχρήστευση παλιών πληροφοριών από την δευτερεύουσα του µνήµη (Data Store) και από το ευρετήριο του (index). Στο πιο κάτω σχήµα (σχήµα 1) φαίνεται που ανήκει, στα πλαίσια της ευρύτερης αρχιτεκτονικής, ο διαµεσολαβητής POP3. Στο σχήµα αυτό φαίνονται επίσης τα δοµικά στοιχεία του διαµεσολαβητή αυτού. SCHEDULER URDs URDs HTTP PROXY SERVER PROXY MANAGER PROFILES XML DB ANNOTATED CACHE URDs ACI Filtering DATA Garbage INDEX Processor STORE Collector POP3 PROXY SERVER PROXY MANAGER CACHE MANAGER ACI INDEX URDs ACI Filtering DATA Garbage INDEX Processor STORE Collector NNTP PROXY SERVER WEB PROXY MANAGER ALERTER ACI Filtering DATA Garbage INDEX Processor STORE Collector DATABASE PROXY SERVER PROXY MANAGER Filtering DATA Garbage INDEX Processor STORE Collector Figure 1: Η λογική θέση του POP3 Proxy στην γενικότερη Αρχιτεκτονική Όπως φαίνεται από το σχήµα τα δοµικά στοιχεία του διαµεσολαβητή POP3 είναι τα ίδια µε των άλλων διαµεσολαβητών (HTTP,NNTP) γιατί έχουν την ίδια λογική αρχιτεκτονική. Ωστόσο η υλοποίηση των δοµικών συστατικών του κάθε συστήµατος διαφέρει, και αυτό διότι κάθε πρωτόκολλο δουλεύει µε τον δικό του τρόπο και παρουσιάζει τις δικές του ιδιαιτερότητες. Τα δοµικά στοιχεία του κάθε διαµεσολαβητή είναι εξαρτώµενα από το ανάλογο πρωτόκολλο (protocol specific). -79-

90 8.2 Αρχιτεκτονική του ιαµεσολαβητή POP3 Πιο κάτω περιγράφεται αναλυτικά η αρχιτεκτονική του ιαµεσολαβητή POP3. Στο σχήµα 2 φαίνεται η ροή των URD αιτήσεων προς τον ιαµεσολαβητή POP3, η διαδικασία επεξεργασίας και αποθήκευσης του ανακτηµένου αντικειµένου καθώς και το αποτέλεσµα της όλης διαδικασίας, που είναι η αποστολή της µέταπληροφορίας ACI προς τον Annotation Cache Manager και τον Alerter. Scheduler Alerter Annotation Cache Manager URD ACI Garbage Collect POP3 PROXY PROXY MANAGER Garbage Collector INDEX (DOM) Filering Processor [ URD, Last State ] [ URD, New State, Document ] Thread POP3 Search POP3 Requests POP3 messages POP3 Log File PROXY INDEX XML FILE DATA STORE Figure 2: Η Αρχιτεκτονική του ιαµεσολαβητή POP3 a. Περιγραφή Ευρετηρίου Αποµνηµόνευσης (Index) Το Index του ιαµεσολαβητή αποτελείται από µια XML περιγραφή, όπως αυτή φαίνεται στο σχήµα 3 και 4. Kάθε POP3 πηγή αναγνωρίζεται µοναδικά µε την χρήση των στοιχείων uri, login. Για κάθε τέτοια πηγή το σύστηµα αποθηκεύει ένα ή περισσότερα UID (Unique ID) Element. Το UID Element αναφέρεται σε ένα µήνυµα το οποίο ανακτήθηκε από ένα εξυπηρετητή POP3 (uri) µε την χρήση του κωδικού (login). Το UID Element περιέχει 3 πληροφορίες 1. Το µοναδικό αριθµό του µηνύµατος που ανακτήθηκε (retrieved_as) 2. Με τι όνοµα έχει φυλαχτεί το µήνυµα στην Data Store (stored_as) -80-

91 3. Πόσα ACI Element από τις Annotation Cache αναφέρονται σε αυτό το αντικείµενο (0 ή 1) (reference_bit) <?xml version="1.0" encoding="iso "?> <!ELEMENT pop3 (uri)*> <!ATTLIST pop3 counter CDATA #REQUIRED> <!ELEMENT uri (uid*)> <!ATTLIST uri server CDATA #REQUIRED username CDATA #REQUIRED> <!ELEMENT uid EMPTY> <!ATTLIST uid retrieved_as CDATA #REQUIRED stored_as CDATA #REQUIRED reference_bit CDATA #REQUIRED> Figure 3: Η Γραµµατική του ευρετηρίου (Index) του ιαµεσολαβητή POP3 <?xml version= "1.0" encoding ="ISO "?> <!DOCTYPE pop3 SYSTEM "pop3.dtd"> <pop3 counter="10"> <uri server="nicosia.ccs.ucy.ac.cy" username="csyiazti"> <uid retrieved_as="2d25bae f36f87689b183a206" stored_as="1.eml" reference_bit= 0 /> </uri> <uri server="turing.cs.ucy.ac.cy" username="csyiazt1"> <uid retrieved_as="38c266bd b" stored_as="2.eml" reference_bit= 1 /> <uid retrieved_as="38c266bd c" stored_as="3.eml" reference_bit= 1 /> </uri> </pop3> Figure 4: Παράδειγµα XML αρχείου του ευρετηρίου Index Ο µοναδικός αριθµός του µηνύµατος είναι ένας αριθµός που αποτελείται από ψηφία και χαρακτήρες και ο οποίος ανατίθεται στο µήνυµα από τον εξυπηρετητή στον οποίο βρίσκεται το µήνυµα. Με βάση αυτόν τον αριθµό µπορούµε να αποφασίσουµε αν θέλουµε να λάβουµε το µήνυµα ή όχι. Στο σχήµα 5 φαίνεται η διαδικασία επικοινωνίας µε ένα POP3 Server. Όπως φαίνεται ο διαθέτης αυτός έχει 2 µηνύµατα. Τα µηνύµατα αυτά επιστρέφονται από τον διαθέτη σαν 2 µοναδικοί αριθµοί (Unique Ids). Στην συνέχεια έχουµε την ευκαιρία να ζητήσουµε ένα από τα δυο µηνύµατα. Στο παράδειγµα καλούµε τον εξυπηρετητή να µας δώσει το δεύτερο (RETR2). --> +OK QPOP (version 2.52) at nicosia.ccs.ucy.ac.cy starting. <-- USER csyiazti --> +OK Password required for csyiazti. <-- PASS ******** --> +OK csyiazti has 3 messages (12639 octets). <-- STAT -81-

92 --> +OK <-- LIST --> +OK 3 messages (12639 octets) --> > <-- UIDL --> +OK uidl command accepted. --> 1 2d25bae f36f87689b183a206 --> 2 212a94d3fd7cb81711f93ef <-- RETR 2 --> +OK 5458 octets Figure 5: Η επικοινωνία µε ένα POP3 Server b. Περιγραφή Λειτουργίας Όταν ο ιαµεσολαβητής λάβει µια αίτηση URD µε ένα EventMail Event, το οποίο προέρχεται από τον Scheduler, τότε ψάχνει µέσα στο Index του για να βρεί την προηγούµενη κατάσταση ανάκτησης. Αυτή η κατάσταση όπως φαίνεται στο σχήµα 4 είναι ένα URI Element. Αυτό γίνεται για να γνωρίζει το thread ThreadPOP3Search ποιά µηνύµατα να ανακτήσει, ώστε να µην ανακτηθούν µηνύµατα που ήδη ανακτήθηκαν. Ετσι η URD αίτηση προωθείται µαζί µε το URI Element προς το ThreadPOP3Search, το οποίο στην συνεχεία επικοινωνεί µε τον POP3 Server (βλέπε σχήµα 5). Το ThreadPOP3Search καλεί τον POP3 Server να του παραδώσει όλα τα µηνύµατα ( documents) τα οποία δεν περιέχονται µέσα στο URI Element. Αυτά τα µηνύµατα τα συσκευάζει µέσα σε ένα EventStorePOP3Document Event. Το Εvent αυτό παραλαµβάνεται από τον διαµεσολαβητή POP3 που παίρνει το µήνυµα και το αναλύει µε τον επεξεργαστή φιλτραρίσµατος (filtering processor) όπως το σχήµα 6. Το αποτέλεσµα της επεξεργασίας είναι ένα ACI Element. Αν από την επεξεργασία διαφανεί ότι το κείµενο δεν ενδιαφέρει τον χρήστη τότε διαγράφεται το µήνυµα από το Data Store. Αν διαφανεί το αντίθετο, τότε το ACI Element εντάσσεται στην Annotation Cache του δεδοµένου χρήστη µε την χρήση του EventaddtoCache Event. -82-

93 Document URD FILTERING PROCESSOR ACI Figure 6: Η λειτουργία του επεξεργαστή φιλτραρίσµατος Ο Μηχανισµός για συλλογή άχρηστων και παλιών πληροφοριών από την δευτερεύουσα του µνήµη (Data Store) και από το ευρετήριο του (index) (Garbage Collection Mechanism), είναι υπεύθυνος να καθαρίζει όλες τις πληροφορίες κατα τέτοιο τροπο ώστε να διασφαλίζεται πάντοτε το ACCC (Annotation Cache Coherence Constrain). Πρέπει δηλαδή να αχρηστέψει µόνο όσες πληροφορίες δεν είναι αναγκαίες πλέον στους χρήστες Ο Μηχανισµός αυτός λειτουργεί µε την χρήση 2 Events. To πρώτο Event (EventGarbageCollection) είναι υπεύθυνο να µειώνει τα reference_bit και το Event (EventSychronizeIndex) να καθαρίζει το Index. Πιο κάτω αναφέρουµε 2 διαφορετικές περιπτώσεις λειτουργίας του µηχανισµού: «Ο χρήστης έχει διαβάσει µια ανακτηµένη πληροφορία και µετά την έχει αχρηστέψει (πετάξει)». Σε αυτό το σενάριο θα φτάσει ένα Event από τον Annotation Cache Manager (EventGarbageCollection) και θα θέσει το reference_bit του συγκεκριµένου αντικειµένου στο index του proxy ίσο µε 0. Επίσης θα σβηστεί η πραγµατική πληροφορία από το Data Store του Proxy. Ωστόσο δεν θα διαγραφτεί το UID Element (π.χ<uid retrieved_as="2d25bae f36f87689b183a206" stored_as="1.eml" reference_bit= 0 />),διότι πολύ πιθανό να υπαρχει αυτό το µήνυµα στον POP3 Server από τον οποίο ανακτήθηκε αρχικά. Αν σβήσουµε το UID Element τότε θα το ξανακατεβάσει ο Proxy Server µε το επόµενο τρέξιµο του Scheduler αφού o POP3 Proxy θα νοµίζει ότι δεν το κατέβασε ποτέ. Τα UID s διαγράφονται µόνο µετα από την άφιξη ενός EventSychronizeIndex, και το οποίο αποστέλλεται από το ThreadPOP3Search κατα την διάρκεια ένωσης µε τον δεδοµένο POP3 Server. Στο Event αυτό περιέχεται µια λίστα µε τα νέα UIDs. Ετσι ο διαµεσολαβητής POP3 µπορεί να γνωρίζει ποια UIDs µπορεί να µετακινήσει από το index του. -83-

94 «Ο χρήστης έχει διαβάσει µια ανακτηµένη πληροφορία αλλά δεν την έχει αχρηστέψει (πετάξει)». Σε αυτό το σενάριο δεν θα σβηστεί η πραγµατική πληροφορία από το Data Store του Proxy για να διατηρηθεί το ACCC (Annotation Cache Coherence Constrain) (βλέπε κεφαλαίο Annotation Cache). Τα UIDs που πρέπει να διαγραφτούν θα διαγράφουν όπως και στην προηγούµενη περίπτωση, µόνο κατα την διάρκεια του EventSychronizeIndex Event. Τέλος να αναφέρουµε ότι ο διαµεσολαβητής κρατά επίσης κατάστιχο µε την ιστορία της λειτουργίας του (log file - /logs/pop3.log) για να είναι δυνατή η αποσφαλµάτωση του διαµεσολαβητή σε τυχόν λάθη που θα προκύψουν κατα την διάρκεια λειτουργίας του. 8.3 Υλοποίηση ιαµεσολαβητή POP3 Ο διαµεσολαβητής POP3 (POP3 Proxy Service Manager) είναι υλοποιηµένoς σαν ένα Concordia Service Bridge [Mit98]. Αυτό σηµαίνει ότι διαµεσολαβητής POP3 µπορεί να είναι εγκαταστηµένος σε µια µηχανή µέσα στο IP δίκτυο και να δέχεται εκκλήσεις από τον χρονοδροµολογητή, που µπορεί να βρίσκεται σε διαφορετικές IP διευθύνσεις κάνοντας έτσι εφικτή την κατανοµή του ολικού φόρτου του συστήµατος σε πολλαπλές µηχανές. Εφόσον ο διαχειριστής είναι υλοποιηµένος σαν Service Bridge, σηµαίνει ότι αυτός θα αρχίζει την λειτουργία του µε την εκκίνηση της µηχανής. Κατά την διάρκεια της εκκίνησης του Proxy, αυτός αρχικοποιεί το ευρετήριο του (Proxy DOM), από ένα αρχείο XML (/xml/proxies/pop3.xml). Στο αρχείο αυτό έχει φυλάξει τις πληροφορίες που κρατούσε το Proxy-DOM κατα την διάρκεια του τελευταίου τρεξίµατος του διαµεσολαβητή. Στην συνέχεια το Proxy DOM παραµένει στην κυρίως µνήµη. Κατα την διάρκεια της εκκίνησης του συστήµατος ο Proxy Manager (σχήµα 7) ενώνεται επίσης µε το Concordia Event Manager, ο οποίος βρίσκεται εγκατεστηµένος σε µια µηχανή µέσα στο ΙP δίκτυο και συντονίζει την µεταγωγή µηνυµάτων, και του δηλώνει ποια είδη Events ενδιαφέρεται να ακούσει. Στην συνεχεία παραµένει σε αδράνεια και περιµένει να εξυπηρετήσει διάφορα Events τα οποια καταφθάνουν σε αυτόν και τα οποια είναι: -84-

95 EventMail από τον Scheduler EventGarbageCollect από τον Annotation Cache Manager EventStorePOP3Document από το ThreadPOP3Search EventSychronizeIndex από το ThreadPOP3Search Η υλοποίηση του ThreadPOP3Search έγινε µε την βοήθεια έτοιµων βιβλιοθηκών. Οι βιβλιοθήκες αυτές ονοµάζονται Jgmail [Mes99]. Με τα πακέτα αυτά ήταν ευκολότερη η υλοποίηση της επικοινωνίας και ανάληψης µηνυµάτων από ένα εξυπηρετητή POP3. Figure 7: Παράδειγµα εκκίνησης του POP3 Proxy (από την Κονσόλα Λειτουργίας) a. Εσωτερική Επικοινωνία εδοµένων (Ενδοεπικοινωνία εδοµένων) Όπως προαναφέραµε, ο διαχειριστής του διαµεσολαβητή POP3 αναλαµβάνει να εξυπηρετήσει αιτήσεις που γίνονται σε αυτών. Όταν φτάσει µια αίτηση (event) στον διαχειριστή της κρυφής µνήµης, αυτός αναλαµβάνει να διεκπεραιώσει αυτήν την -85-

96 αίτηση, κάνοντας την σχετική εργασία. Ο τρόπος µεταγωγής δεδοµένων στο εσωτερικό της κρυφής µνήµης γίνεται εφικτός µε την χρήση των ACI Elements ή των URD Εlements, τα οποια είναι αυτό-περιγραφικά και ανεξάρτητα λόγω της δοµής τους. b. Τρόπος Μεταγωγής εδοµένων στις εξωτερικές οντότητες. Ο τρόπος µεταγωγής µηνυµάτων προς τις εξωτερικές οντότητες-διαχειριστές, γίνεται µε την χρήση Concordia Events, στα οποία πακετάρουµε τα ACI Elements τα οποια θέλουµε να τους µεταφέρουµε. Με αυτό τον τρόπο γίνονται καθαρές οι επικοινωνίες αφού ο παραλήπτης (Αnnotation Cache) γνωρίζει ακριβώς την δοµή δεδοµένων που θα παραλάβει. Επίσης τυχόν αλλαγές στις δυο περιγραφές (ACI, URD) δεν θα επηρεάσουν καθόλου τις επικοινωνίες, αφού αυτές γίνονται βάση Elements και όχι βάση επί µέρους στοιχείων. c. Αλγόριθµοι ανάκτησης και τοποθέτησης δεδοµένων στo Index του Proxy Όλοι οι αλγόριθµοι ανάκτησης ή διαγραφής πληροφοριών από το Index του Proxy Server υλοποιούνται µε σειριακές αναζητήσεις µέσα στο DOM δέντρο του ευρετηρίου του διαµεσολαβητή αυτού. Το δέντρο αυτό βρίσκεται στην µνήµη σαν ένα αντικείµενο και για αυτό δεν θέτονται θέµατα ταυτοχρονίας και συγχρονισµού. Οι αλγόριθµος τοποθέτησης πληροφοριών υλοποιείται απλά µε την προσθήκη του URI Element στο τέλος του DOM δέντρου του διαµεσολαβητή. -86-

97 Κεφάλαιο 9 Περιγραφή ιαµεσολαβητή HTTP 9.1 Εισαγωγή H Αρχιτεκτονική του ιαµεσολαβητή. 89 a. Περιγραφή Ευρετηρίου Αποµνηµόνευσης. 89 b. Περιγραφή Λειτουργίας Υλοποίηση του ιαµεσολαβητή 95 a. Ενδο-επικοινωνία εδοµένων. 97 b. Τρόπος Μεταγωγής εδοµένων στις εξωτερικές οντότητες. 97 c. Αλγόριθµοι ανάκτησης και τοποθέτησης δεδοµένων στo Index Εισαγωγή H ιαµεσολαβητής HTTP είναι το δοµικό στοιχείο της υπηρεσίας ανάκτησης πληροφοριών διαδικτύου (ΠΠΠ) που προσφέρει το σύστηµα. Ο ιαµεσολαβητής HTTP [LFF96] είναι υπεύθυνος να εξυπηρετεί όλες τις URD αιτήσεις που έχουν σχέση µε το πρωτόκολλο HTTP. Ο ιαµεσολαβητής αυτός αναλαµβάνει να κάνει την πιο κάτω σειρά ενεργειών: Να ανακτήσει πληροφορίες από διάφορους εξυπηρετητές διαδικτύου (Web Servers). Οι ανακτηµένες πληροφορίες µπορεί να είναι ο,τιδήποτε χαρακτηρίζεται από µια URL διεύθυνση (π.χ static HTML, αποτελέσµατα εκτέλεσης κάποιου script) Να επεξεργαστεί τις ανακτηµένες πληροφορίες βάση της αίτησης URD και αν ενδιαφέρουν τον χρήστη να τα φυλάξει στον τοπικό δίσκο του διαµεσολαβητή (caching). -87-

98 Να δηµιουργήσει µια µέτα-περιγραφή της συλλεγόµενης πληροφορίας (ACI Element) και να ενηµερώσει την Annotation Cache. Να δηµιουργήσει και να ανανεώνει ένα index, το οποίο θα του παρέχει µετα-πληροφορίες για τις πηγές που έχει αποθηκευµένες στην κρυφή του µνήµη (Data Store). Να προσφέρει µηχανισµούς για να διασφαλίζει την συνοχή (consistency) και συνάφεια (coherence) µεταξύ της κρυφής του µνήµης και των πηγών από τις οποίες ανακτήθηκαν οι αποθηκευµένες του πληροφορίες. Τέλος πρέπει να προσφέρει µηχανισµούς για συλλογή άχρηστων και παλιών πληροφοριών από την δευτερεύουσα του µνήµη (Data Store) και από το ευρετήριο του (index) διασφαλίζοντας παράλληλα το ACCC (Annotation Cache Coherence Constrain). Στο πιο κάτω σχήµα (σχήµα 1) παρουσιάζεται ο διαµεσολαβητής ΗΤΤP. Στο σχήµα αυτό φαίνονται επίσης τα δοµικά στοιχεία του διαµεσολαβητή αυτού. SCHEDULER URDs URDs HTTP PROXY SERVER PROXY MANAGER PROFILES XML DB ANNOTATED CACHE URDs ACI Filtering DATA Garbage INDEX Processor STORE Collector POP3 PROXY SERVER PROXY MANAGER CACHE MANAGER ACI INDEX URDs ACI Filtering DATA Garbage INDEX Processor STORE Collector NNTP PROXY SERVER WEB PROXY MANAGER ALERTER ACI Filtering DATA Garbage INDEX Processor STORE Collector DATABASE PROXY SERVER PROXY MANAGER Filtering DATA Garbage INDEX Processor STORE Collector Figure 1: Η λογική θέση του HTTP Proxy στην γενικότερη Αρχιτεκτονική Τα δοµικά στοιχεία του διαµεσολαβητή HTTP όπως και των άλλων είναι εξαρτώµενα από το ανάλογο πρωτόκολλο (protocol specific). -88-

99 9.2 Αρχιτεκτονική του ιαµεσολαβητή HTTP Πιο κάτω περιγράφεται αναλυτικά η αρχιτεκτονική του ιαµεσολαβητή HTTP. Στο σχήµα 2 φαίνεται η ροή των URD αιτήσεων προς τον ιαµεσολαβητή HTTP, η διαδικασία επεξεργασίας και αποθήκευσης του ανακτηµένου αντικειµένου καθώς και το αποτέλεσµα της όλης διαδικασίας, που είναι η αποστολή της µέταπληροφορίας ACI προς τον Annotation Cache Manager και τον Alerter. Στο σχήµα φαίνονται επίσης µε µικρά γράµµατα τα µηνύµατα επικοινωνίας (events) που κυκλοφορούν από και προς τον διαµεσολαβητή. Scheduler Alerter Annotation Cache Manager URD ACI Garbage Collect HTTP PROXY PROXY MANAGER Garbage Collector INDEX (DOM) Filering Processor [ URD,Last Check] [URD,Document, LastModified] Thread HTTP Search HTTP Requests HTTP responses HTTP Log File PROXY INDEX XML FILE DATA STORE Figure 2: Η Αρχιτεκτονική του ιαµεσολαβητή HTTP a. Περιγραφή Ευρετηρίου Αποµνηµόνευσης (Index) Το Index του ιαµεσολαβητή αποτελείται από µια XML περιγραφή, όπως αυτή φαίνεται στο σχήµα 3 και 4. Όπως φαίνεται, για κάθε µοναδική πηγή (uri, lastaccess) το σύστηµα αποθηκεύει ένα URI Element. Το URI Element αναφέρεται σε µια πηγή πληροφορίας που διακοµίστηκε στον δίσκο (Data Store) του διαµεσολαβητή και η οποία ήταν τοποθετηµένη στον δίσκο του ιαθέτη server από την χρονική στιγµή lastaccess. Πιο συγκεκριµένα αναφέρουµε ότι το URI Element περιέχει 3 ειδών πληροφορίες: -89-

100 1. Την διεύθυνση από την οποια ανακτήθηκε η δεδοµένη πληροφορία - (server) 2. Την χρονική στιγµή κατά την οποία τοποθετήθηκε αυτή η πληροφορία στον διαθέτη αυτό - (lastaccess). Η πληροφορία lastaccess λαµβάνεται κατά την διάρκεια ένωσης µε ένα διαθέτη HTTP, ο οποίος στην απόκριση του περιλαµβάνει το πεδίο: Last-Modified: Thu, 04 May :33:38 GMT 3. Με τι όνοµα έχει φυλαχτεί το ανακτηµένο αντικείµενο στην Data Store - (stored_as) του διαµεσολαβητή. 4. Πόσα ACI Elements από τις Annotation Cache αναφέρονται σε αυτό το αντικείµενο (0 ή περισσότερα)(reference_bit) <?xml version="1.0" encoding="iso "?> <!ELEMENT http (uri)*> <!ATTLIST http unique_filename_counter CDATA #REQUIRED> <!ELEMENT uri EMPTY> <!ATTLIST uri server CDATA #REQUIRED lastaccess CDATA #REQUIRED stored_as CDATA #REQUIRED> reference_bit CDATA #REQUIRED> Figure 3: Η Γραµµατική του ευρετηρίου (Index) του ιαµεσολαβητή ΗΤΤP <?xml version= "1.0" encoding ="ISO "?> <!-- Import http.dtd --> <!DOCTYPE http SYSTEM "http.dtd"> <http unique_filename_counter=" "> <uri server=" " lastaccess=" " stored_as="21.html" reference_bit="1"/> <uri server=" " lastaccess=" " stored_as="32.htm" reference_bit="90"/> <uri server=" " lastaccess=" " stored_as="3.jpg" reference_bit="0"/> <uri server=" " lastaccess=" " stored_as="3432.html" reference_bit="10"/> </http> Figure 4: Παράδειγµα XML αρχείου του ευρετηρίου Index Πιο κάτω θα εξηγήσουµε πως συµβάλει το κάθε στοιχείο στην λειτουργία του διαµεσολαβητή HTTP. b. Περιγραφή Λειτουργίας Όταν ο ιαµεσολαβητής λάβει µια αίτηση URD µε ένα EventHTTP Event, το οποίο προέρχεται από τον Scheduler, τότε ψάχνει µέσα στο Index του για να βρεί αν έχει αυτή την πηγή αποθηκευµένη στην τοπική του κρυφή µνήµη. Αν την έχει τότε -90-

101 παίρνει την τιµή του ιδιοχαρακτηριστικού lastcheck (που παριστά την χρονική στιγµή που η πληροφορία αυτή τοποθετήθηκε στον διαθέτη από τον οποίο διακοµίστηκε. Η τιµή του πεδίου αυτού είναι ένας long αριθµός (π.χ ). Στην συνέχεια όπως µπορεί να φανεί στο σχήµα 2 προωθείται η URD αίτηση και το lastcheck προς ένα ThreadHTTPSearch. ThreadHTTPSearch To ThreadHTTPSearch (βλεπε σχηµα 5) είναι υπεύθυνο να κάνει µια σειρά βηµάτων για να ανακτήσει την πηγή που περιλαµβάνεται µέσα στην URD αίτηση. To ThreadHTTPSearch δεν κάνει ουδεµία ανάλυση του αντικειµένου που λαµβάνει βάση των ενδιαφερόντων του χρήστη. Πιο συγκεκριµένα αναφέρουµε ότι το ThreadHTTPSearch Κάνει µια HTTP αίτηση προς τον ιαθέτη που κατέχει την πληροφορία µε την χρήση του if-modified-since Λαµβάνει το αντικείµενο που θέλει να ανακτήσει αν έχει αλλάξει από την ηµεροµηνία lastcheck Επεξεργάζεται το αντικείµενο αφαιρώντας τα HTTP headers και αντικαθιστώντας όλες τις σχετικές διευθύνσεις µε ολικές διευθύνσεις ηµιουργεί και αποστέλλει ένα EventStoreHTTPDocument Event (αν πράγµατι βρει ένα ανανεωµένο ή νέο αντικείµενο), στο οποίο επισυνάπτει τo URD Element, την πραγµατική πληροφορία (document) και το πεδίο Last-modified. Τερµατίζει την λειτουργία του -91-

102 Figure 5: Παράδειγµα ανάκτησης ιστοσελίδας από το ThreadHTTPSearch Η διαδικασία ανάκτησης της πηγής από το ThreadHTTPSearch, γίνεται µε την χρήση του if-modified-since. Πιο κάτω ακολουθεί ο κώδικας Java, που κάνει χρήση Java Sockets για να επιτύχει την επικοινωνία µε τον HTTP Server. Εδώ αξίζει να αναφέρουµε ότι οι έτοιµες κλάσεις του Java-API java.net.url δεν µας παρείχαν την δυνατότητα να υλοποιήσουµε το if-modified-since και για αυτό έγινε χρήση των Java Sockets. try { Socket socket = new Socket( 80 ); PrintWriter prnt = new PrintWriter(new BufferedWriter(new OutputStreamWriter(socket.getOutputStream())),true); prnt.println("get index.html HTTP/1.0"); prnt.println("if-modified-since: Thu, 04 May :33:38 GMT ); prnt.println(""); instream = new BufferedReader (new InputStreamReader(socket.getInputStream())); return instream; } catch (Exception e) -92-

103 { System.out.println("Exception: " + e.tostring()); } Σκοπός του if-modified-since είναι να µην µας επιστρέψει ο διαθέτης όλο το κείµενο αν δεν τροποποιήθηκε από την ηµεροµηνία που του στέλνουµε. υστυχώς ορισµένοι διαθέτες (π.χ Netscape FastTrack 2.x) αγνοούν το if-modified-since. Αυτό σηµαίνει ότι πάντα επιστρέφουν το δεδοµένο αντικείµενο. Πιο κάτω φαίνονται µε παραδείγµατα πως το if-modified-since δουλεύει για δυο διαθέτες (Netscape FastTrack/2.01 και Unix Apache v1.3.0). O Πρώτος διαθέτης δεν αναγνωρίζει το if-modified-since και µας επιστρέφει πάντα ολόκληρο το αντικείµενο ενώ ο δεύτερος το αναγνωρίζει και µας επιστρέφει µόνο το Header. Επίσης αναφέρουµε ότι σε κανένα από τους δυο εξυπηρετητές δεν άλλαξε το index.html αρχείο από την ηµεροµηνία Thu, 04 May :33:38 GMT. GET /index.html HTTP/1.0 If-modified-since: Thu, 04 May :33:38 GMT <empty line> H Αίτηση προς τον HTTP server που αγνοεί το if-modified-since HTTP/ OK Server: Netscape-FastTrack/2.01 Date: Wed, 10 May :10:21 GMT Accept-ranges: bytes Last-modified: Fri, 05 May :25:10 GMT Content-length: Content-type: text/html <THE BODY OF THE MESSAGE> H Απόκριση του HTTP server που αγνοεί το if-modified-since GET /index.html HTTP/1.0 If-modified-since: Thu, 04 May :33:38 GMT <empty line> H Αίτηση προς τον HTTP server που αναγνωρίζει το if-modified-since HTTP/ Not Modified Server: Apache/1.3.0 (Unix) -93-

104 Date: Wed, 10 May :10:21 GMT <EMPTY BODY> H Απόκριση του HTTP server που αναγνωρίζει το if-modified-since To πιο πάνω φαινόµενο δηµιούργησε αρχικά µεγάλα προβλήµατα αφού µέσα στο Data Store και το Index του ιαµεσολαβητή µπορεί να υπάρχουν 0 ή περισσότερα αντικείµενα από το ίδιο URL για να διατηρηθεί το ACCC (Annotation Cache Coherence Constrain) (βλέπε κεφαλαίο Annotation Cache). Ετσι κάθε φορά που κάναµε µια αίτηση σε έναν από αυτούς τους διαθέτες το ανακτηµένο αντικείµενο προτίθετο στην cache δηµιουργώντας ετσι πολλαπλά αντίτυπα του Ι ΙΟΥ αντικειµένου. Για να λύσουµε αυτό το πρόβληµα αναγκαστήκαµε να κάνουµε ένα επιπρόσθετο έλεγχο πριν να προσθέσουµε αντικείµενα µέσα στο Data Store και το Index του διαµεσολαβητή. Αυτός ο έλεγχος λαµβάνει το Last-modified πεδίο που βρίσκεται ΠΑΝΤΑ στο header της απόκρισης του διαµεσολαβητή. Στην συνεχεία το µετατρέπουµε σε ένα long αριθµό. Thu, 04 May :33:38 GMT ======> Πριν να προσθέσουµε το αντικείµενο µέσα στο Index ελέγχουµε αν ξανά-υπάρχει αυτός ο αριθµός σε ένα από τα URI Εlements (που αναφέρονται στο ίδιο url). Αν όχι τότε γίνεται η προσθήκη και φυλάγεται επίσης η πραγµατική πληροφορία µέσα στo Data Store. Στην αντίθετη περίπτωση καταστρέφεται η ανακτηµένη πληροφορία και το URD Element εξυπηρετείται από την Κρυφή µνήµη µε την χρήση του επεξεργαστή φιλτραρίσµατος Document URD FILTERING PROCESSOR ACI Figure 6: Η λειτουργία του επεξεργαστή φιλτραρίσµατος -94-

105 Αν από την επεξεργασία διαφανεί ότι το κείµενο δεν ενδιαφέρει τον χρήστη τότε δεν προωθείται το ACI Element προς την Annotation Cache. Αν διαφανεί το αντίθετο, τότε το ACI Element προωθείται µε το EventaddtoCache Event προς την Annotation Cache και τον Alerter. Garbage Collection Ο Μηχανισµός για συλλογή άχρηστων και παλιών πληροφοριών από την δευτερεύουσα του µνήµη (Data Store) και από το ευρετήριο του (index) (Garbage Collection Mechanism), λειτουργεί µε την χρήση 1 Event. Το Event (EventGarbageCollection) είναι υπεύθυνο να µειώνει τα reference_bit κατα ένα κάθε φορά που κάποιος χρήστης αχρηστέψει-πετάξει µια πληροφορία. Αν το reference-bit γινει ίσο µε 0 και αν δεν υπάρχει νεότερο URI Element µέσα στο index του ιαµεσολαβητή τότε καταστρέφεται και το δεδοµένο URI Element Log File Τέλος να αναφέρουµε ότι ο διαµεσολαβητής κρατά επίσης κατάστιχο µε την ιστορία της λειτουργίας του (log file - /logs/http.log) για να είναι δυνατή η αποσφαλµάτωση του διαµεσολαβητή σε τυχόν λάθη που θα προκύψουν κατα την διάρκεια λειτουργίας του. 9.3 Υλοποίηση ιαµεσολαβητή HTTP Ο διαµεσολαβητής HTTP (HTTP Proxy Service Manager) είναι υλοποιηµένoς σαν ένα Concordia Service Bridge [Mit98]. Αυτό σηµαίνει ότι διαµεσολαβητής HTTP µπορεί να είναι εγκαταστηµένος σε µια µηχανή µέσα στο IP δίκτυο και να δέχεται εκκλήσεις από τον χρονοδροµολογητή, που µπορεί να βρίσκεται σε διαφορετικές IP διεύθυνση κάνοντας έτσι εφικτή την κατανοµή του ολικού φόρτου του συστήµατος σε πολλαπλές µηχανές. Εφόσον ο διαχειριστής είναι υλοποιηµένος σαν Service Bridge, σηµαίνει ότι αυτός θα αρχίζει την λειτουργία του µε την εκκίνηση της µηχανής. Κατά την διάρκεια της εκκίνησης του Proxy, αυτός αρχικοποιεί το ACI DOM, από ένα αρχείο XML (/xml/proxies/http.xml). Στο αρχείο -95-

106 αυτό έχει φυλάξει τις πληροφορίες που κρατούσε το ACI-DOM κατα την διάρκεια του τελευταίου τρεξίµατος του διαµεσολαβητή. Στην συνέχεια το ACI DOM παραµένει στην κυρίως µνήµη. Κατά την διάρκεια της εκκίνησης του συστήµατος ο Proxy Manager ενώνεται επίσης µε το Concordia Event Manager, ο οποίος βρίσκεται εγκατεστηµένος σε µια µηχανή µέσα στο ΙP δίκτυο και συντονίζει την µεταγωγή µηνυµάτων, και του δηλώνει ποια είδη Events ενδιαφέρεται να ακούσει. Στην συνεχεία παραµένει σε αδράνεια και περιµένει να εξυπηρετήσει διάφορα Events τα οποία καταφθάνουν σε αυτόν και τα οποία είναι: EventHTTP από τον Scheduler EventGarbageCollect από τον Annotation Cache Manager EventStoreHTTPDocument από το ThreadHTTPSearch Figure 7: Παράδειγµα εκκίνησης του HTTP Proxy (από την Κονσόλα Λειτουργίας) -96-

107 a. Εσωτερική Επικοινωνία εδοµένων (Ενδοεπικοινωνία εδοµένων) Όπως προαναφέραµε, ο διαχειριστής του διαµεσολαβητή HTTP αναλαµβάνει να εξυπηρετήσει αιτήσεις που γίνονται σε αυτών. Όταν φτάσει µια αίτηση (event) στον διαχειριστή της κρυφής µνήµης, αυτός αναλαµβάνει να διεκπεραιώσει αυτήν την αίτηση, κάνοντας την σχετική εργασία. Ο τρόπος µεταγωγής δεδοµένων στο εσωτερικό της κρυφής µνήµης γίνεται εφικτός µε την χρήση των ACI Elements ή των URD Εlements, τα οποια είναι αυτό-περιγραφικά και ανεξάρτητα λόγω της δοµής τους. b. Τρόπος Μεταγωγής εδοµένων στις εξωτερικές οντότητες. Ο τρόπος µεταγωγής µηνυµάτων προς τις εξωτερικές οντότητες-διαχειριστές, γίνεται µε την χρήση Concordia Events, στα οποία πακετάρουµε τα ACI Elements τα οποια θέλουµε να τους µεταφέρουµε. Με αυτό τον τρόπο γίνονται καθαρές οι επικοινωνίες αφού ο παραλήπτης (Annotation Cache) γνωρίζει ακριβώς την δοµή δεδοµένων που θα παραλάβει. Επίσης τυχόν αλλαγές στις δυο περιγραφές (ACI, URD) δεν θα επηρεάσουν καθόλου τις επικοινωνίες, αφού αυτές γίνονται βάση Elements και όχι βάση επί µέρους στοιχείων. c. Αλγόριθµοι ανάκτησης και τοποθέτησης δεδοµένων στο Index του Proxy Όλοι οι αλγόριθµοι ανάκτησης ή διαγραφής πληροφοριών από το Index του Proxy Server υλοποιούνται µε σειριακές αναζητήσεις µέσα στο DOM δέντρο του ευρετηρίου του διαµεσολαβητή αυτού. Το δέντρο αυτό βρίσκεται στην µνήµη σαν ένα αντικείµενο και για αυτό δεν θέτονται θέµατα ταυτοχρονίας και συγχρονισµού. Οι αλγόριθµος τοποθέτησης πληροφοριών υλοποιείται απλά µε την προσθήκη του URI Element στο τέλος του DOM δέντρου του διαµεσολαβητή. -97-

108 Κεφάλαιο 10 Περιγραφή ιαµεσολαβητή NNTP 10.1 Εισαγωγή H Αρχιτεκτονική του ιαµεσολαβητή 100 a. Περιγραφή Ευρετηρίου Αποµνηµόνευσης 100 b. Περιγραφή Λειτουργίας Υλοποίηση του ιαµεσολαβητή 105 a. Ενδο-επικοινωνία εδοµένων. 106 b. Τρόπος Μεταγωγής εδοµένων στις εξωτερικές οντότητες. 107 c. Αλγόριθµοι ανάκτησης και τοποθέτησης δεδοµένων στο Ιndex Εισαγωγή H ιαµεσολαβητής NNTP είναι το δοµικό στοιχείο της υπηρεσίας Ηλεκτρονικών Οµάδων συζήτησης Newsgroups [KL86] (RFC977 - Network News Transfer Protocol) που προσφέρει το σύστηµα. Ο ιαµεσολαβητής NNTP είναι υπεύθυνος να εξυπηρετεί όλες τις URD αιτήσεις που έχουν σχέση µε το πρωτόκολλο NNTP. Ο ιαµεσολαβητής αυτός αναλαµβάνει να κάνει την πιο κάτω σειρά ενεργειών: Να ανακτήσει πληροφορίες από διαθέτες NNTP. Να επεξεργαστεί τις ανακτηµένες πληροφορίες βάση της αίτησης URD, και να φυλάξει τις ανακτηµένες πληροφορίες στον τοπικό δίσκο του διαµεσολαβητή (caching). Να δηµιουργήσει µια µέτα-περιγραφή της συλλεγόµενης πληροφορίας (ACI Element) και να ενηµερώσει την Annotation Cache. -98-

109 Να δηµιουργήσει ένα ιστορικό αποµνηµόνευσης της ως τώρα εργασίας του (index). Αυτό πρέπει να γίνεται για να θυµάται oδιαµεσολαβητής τι έχει διαβάσει και επεξεργασθεί για τον κάθε χρήστη που ενδιαφέρεται για µια οµάδα συζήτησης. Τέλος πρέπει να προσφέρει µηχανισµούς για συλλογή άχρηστων και παλιών πληροφοριών από την δευτερεύουσα του µνήµη (Data Store) και από το ευρετήριο του (index) διασφαλίζοντας παράλληλα το ACCC (Annotation Cache Coherence Constrain). Στο πιο κάτω σχήµα (σχήµα 1) φαίνεται που ανήκει, στα πλαίσια της ευρύτερης αρχιτεκτονικής, ο διαµεσολαβητής ΝΝΤP. Στο σχήµα αυτό φαίνονται επίσης τα δοµικά στοιχεία του διαµεσολαβητή αυτού. SCHEDULER URDs URDs HTTP PROXY SERVER PROXY MANAGER PROFILES XML DB ANNOTATED CACHE URDs ACI Filtering DATA Garbage INDEX Processor STORE Collector POP3 PROXY SERVER PROXY MANAGER CACHE MANAGER ACI INDEX URDs ACI Filtering DATA Garbage INDEX Processor STORE Collector NNTP PROXY SERVER WEB PROXY MANAGER ALERTER ACI Filtering DATA Garbage INDEX Processor STORE Collector DATABASE PROXY SERVER PROXY MANAGER Filtering DATA Garbage INDEX Processor STORE Collector Figure 1: Η λογική θέση του NNTP Proxy στην γενικότερη Αρχιτεκτονική Τα δοµικά στοιχεία του διαµεσολαβητή NNTP είναι εξαρτώµενα από το ανάλογο πρωτόκολλο (protocol specific). -99-

110 10.2 Αρχιτεκτονική του ιαµεσολαβητή NNTP Πιο κάτω περιγράφεται αναλυτικά η αρχιτεκτονική του ιαµεσολαβητή NNTP. Στο σχήµα 2 φαίνεται η ροή των URD αιτήσεων προς τον ιαµεσολαβητή αυτόν, η διαδικασία επεξεργασίας και αποθήκευσης του ανακτηµένου αντικειµένου καθώς και το αποτέλεσµα της όλης διαδικασίας, που είναι η αποστολή της µέταπληροφορίας ACI προς τον Annotation Cache Manager και τον Alerter. Scheduler Alerter Annotation Cache Manager URD ACI Garbage Collect NNTP PROXY PROXY MANAGER Garbage Collector INDEX (DOM) Filering Processor [ URD,Last State] [URD,Document, New State] Thread NNTP Search NNTP Requests NNTP messages NNTP Log File PROXY INDEX XML FILE DATA STORE Figure 2: Η Αρχιτεκτονική του ιαµεσολαβητή NNTP a. Περιγραφή Ευρετηρίου Αποµνηµόνευσης (Index) Το Index του ιαµεσολαβητή αποτελείται από µια XML περιγραφή, όπως αυτή φαίνεται στο σχήµα 3 και 4. Για κάθε µοναδική πηγή (server, group) το σύστηµα αποθηκεύει ένα URI Element. Το URI Element αναφέρεται στα µηνύµατα µιας συγκεκριµένης οµάδας (group) ενός εξυπηρετητή NTTP (server). Το uri Element περιέχει 4 πληροφορίες 1. Τον εξυπηρετητή NNTP από τον οποίο διακοµίστηκαν κάποιες πληροφορίες (server) 2. Το όνοµα της οµάδας συζήτησης του εξυπηρετητή server από τις οποίες ανακτήθηκαν οι φυλαγµένες πληροφορίες (group) -100-

111 3. Ο µοναδικός αριθµός (όπως αυτός ορίζεται από τον εξυπηρετητή NNTP) του τελευταίου µηνύµατος που διακοµίστηκε. (lastmessage) 4. Πόσα ACI Elements από τις Annotation Cache αναφέρονται σε αυτό το αντικείµενο (0 ή περισσότερα) (reference_bit) Κάθε URI έχει 1 ή περισσότερα USER Elements. Κάθε User Element αναφέρεται στην κατάσταση επεξεργασίας κάποιου χρήστη. Το user element περιέχει 2 πληροφορίες 1. Το κωδικό κάποιου χρήστη που ενδιαφέρεται για ένα newsgroup ιδιοχαρακτηριστικό userid. 2. Μέχρι ποιο article έχει φθάσει η επεξεργασία για τον δεδοµένο χρήστη - ιδιοχαρακτηριστικο until. Το στοιχείο αυτό υπάρχει γιατί µπορεί για παράδειγµα µια αίτηση ενός χρήστη A να ανακτήσει και να επεξεργαστεί για τον εαυτό του µέχρι το Article X. Ο φθάσει η αίτηση του χρήστη B, τότε αυτός πρέπει να ανακτήσει τα articles X+n (n={0,1, } ) ενώ τα articles [(X-until)..X] να τα λάβει και να τα επεξεργαστεί από το Data Store. <?xml version="1.0" encoding="iso "?> <!ELEMENT nntp (uri)*> <!ELEMENT uri (user*)> <!ATTLIST uri server CDATA #REQUIRED username CDATA #REQUIRED group CDATA #REQUIRED lastmessage CDATA #REQUIRED> <!ELEMENT user EMPTY> <!ATTLIST user userid CDATA #REQUIRED Figure 3: Η Γραµµατική του ευρετηρίου (Index) του ιαµεσολαβητή NNTP <?xml version= "1.0" encoding ="ISO "?> <!DOCTYPE nntp SYSTEM "nntp.dtd"> <nntp> <uri server="winnt-1.cs.ucy.ac.cy" group="server.figi4" lastmessage="10"> <user userid="csyiazt1" until="4"/> <user userid="mdd" until="8"/> <user userid="csyiazti" until="10"/> </uri> <uri server="msnews.microsoft.com" group="microsoft.public.xml" lastmessage="2013"> <user userid="csyiazt1" until="15"/> <user userid="mdd" until="2013"/> </uri> </nntp> Figure 4: Παράδειγµα XML αρχείου του ευρετηρίου Index -101-

112 Ο µοναδικός αριθµός lastmessage υποδηλώνει στον erace διαµεσολαβητή NNTP µέχρι πιο article έχει φθάσει στον δεδοµένο εξυπηρετητή NNTP. Στο σχήµα 5 φαίνεται η διαδικασία επικοινωνίας µε ένα εξυπηρετητή NTTP και η λειτουργία των βασικών εντολών του NNTP πρωτοκόλλου [KL86] (π.χ LIST, GROUP, STAT, HEAD, BODY). Όπως φαίνεται ο διαθέτης αυτός έχει 2 οµάδες συζήτησης. Κάθε µήνυµα στον διαθέτη αναγνωρίζεται µοναδικά µε ένα µοναδικό αριθµό (unique id). Τα µηνύµατα µπορεί να ζητηθούν από τον εξυπηρετητή NNTP βάση του µοναδικού τους αριθµού. S: Server (εξυπηρετητής NNTP) C: Client (erace διαµεσολαβητής NNTP) 1) /* ΕΝΩΣΗ ΜΕ ΤΟΝ ΕΞΥΠΗΡΕΤΗΤΗ */ S: (listens at TCP port 119) C: (requests connection on TCP port 119) S: 200 wombatvax news server ready - posting ok 2) /* ΕΥΡΕΣΗ ΤΩΝ ΟΜΑ ΩΝ ΣΥΖΗΤΗΣΗΣ ΕΝΟΣ ΝΝTP SERVER */ C: LIST (client asks for a current newsgroup list) S: 215 list of newsgroups follows S: net.wombats y ο εξυπηρετητής wombatvax περιέχει µια οµάδα (group) net.wombats. Η οµάδα αυτή περιέχει µηνύµατα από το ως το Το αξιοποιείται από το erace διαµεσολαβητή ως το lastmessage. S: net.unix-wizards y y ο εξυπηρετητής wombatvax περιέχει επίσης το group net.wombats. S:. 3) /* ΕΠΙΛΟΓΗ ΜΙΑΣ ΟΜΑ ΩΝ ΣΥΖΗΤΗΣΗΣ ΤΟΥ Ε ΟΜΕΝΟΥ ΝΝTP SERVER */ C: GROUP net.unix-wizards Επιλογή Group S: net.unix-wizards group selected (υπάρχουν 104 articles σε αυτό το group, και τα οποια έχουν αριθµούς από ως 10125) 4) /* ΕΠΙΛΟΓΗ ΕΝΟΣ ARTICLE ΤOY Ε ΟΜΕΝΟΥ GROUP */ C: STAT Το Article έχει επιλεγεί από τον erace διαµεσολαβητή S: <23445@sdcsvax.ARPA> article retrieved - statistics only (article selected, its message-id is <23445@sdcsvax.ARPA>) 5) /* ΕΠΙΛΟΓΗ ΑΝΑΓΝΩΣΗΣ TOY HEADER ΕΝΟΣ ARTICLE ΤOY Ε ΟΜΕΝΟΥ GROUP */ C: HEAD Εντολή ανάκτησης του Header του επιλεγµένου Article (10110) S: <23445@sdcsvax.ARPA> article retrieved - head follows (text of the header appears here) S:

113 6) /* ΕΠΙΛΟΓΗ ΑΝΑΓΝΩΣΗΣ TOY ΒODY ΕΝΟΣ ARTICLE ΤOY Ε ΟΜΕΝΟΥ GROUP */ C: BODY Εντολή ανάκτησης του Body (MIME) του επιλεγµένου Article (10110) S: article retrieved - body follows (body text here) S:. Figure 5: Η επικοινωνία µε ένα NNTP Server Στην υλοποίηση του συστήµατος µας ο διαµεσολαβητής erace ζητά από το εξυπηρετητή NTTP να του παραδώσει όλα τα µηνύµατα που έχουν µεγαλύτερο αριθµό από το lastmessage. c. Περιγραφή Λειτουργίας Όταν ο ιαµεσολαβητής λάβει µια αίτηση URD µε ένα EventΝΝΤP Event, το οποίο προέρχεται από τον Scheduler, τότε ψάχνει µέσα στο Index του για να βρει την προηγούµενη κατάσταση ανάκτησης. Αυτή η κατάσταση όπως µπορεί να φανεί στο σχήµα 4 είναι ένα URI Element. Αυτό γίνεται για να γνωρίζει το thread ThreadNNTPSearch ποια µηνύµατα να ανακτήσει (να µην ανακτηθούν µηνύµατα που ήδη ανακτήθηκαν). Ετσι η URD αίτηση προωθείται µαζί µε το URI Element προς το ThreadNNTPSearch, το οποίο στην συνεχεία επικοινωνεί µε τον NNTP Server (βλέπε σχήµα 5). Το ThreadNNTPSearch καλεί τον NNTP Server να του παραδώσει όλα τα µηνύµατα (newsgroup articles) τα οποία έχουν µεγαλύτερο αριθµό από το lastmessage. Αυτά τα µηνύµατα τα συσκευάζει ένα ένα µέσα σε ένα EventStoreΝΝΤPDocument Event

114 Figure 6: Παράδειγµα εκτέλεσης ενός ThreadNNTPSearch ΤοΕvent αυτό παραλαµβάνεται από τον διαµεσολαβητή NNTP που παίρνει το article και το αναλύει µε τον επεξεργαστή φιλτραρίσµατος (filtering processor) όπως το σχήµα 6. Το αποτέλεσµα της επεξεργασίας είναι ένα ACI Element. Αν από την επεξεργασία διαφανεί ότι το κείµενο ενδιαφέρει τον χρήστη τότε το ACI Element προωθείται µε το EventaddtoCache Event προς την Annotation Cache και τον Alerter. Document URD FILTERING PROCESSOR ACI Figure 7: Η λειτουργία του επεξεργαστή φιλτραρίσµατος Ο Μηχανισµός για συλλογή άχρηστων και παλιών πληροφοριών από την δευτερεύουσα του µνήµη (Data Store) και από το ευρετήριο του (index) (Garbage Collection Mechanism), είναι υπεύθυνος να καθαρίζει όλες τις πληροφορίες κατα τέτοιο τροπο ώστε να διασφαλίζεται πάντοτε το ACCC (Annotation Cache Coherence -104-

115 Constrain). Πρέπει δηλαδή να αχρηστέψει µόνο όσες πληροφορίες δεν είναι αναγκαίες πλέον στους χρήστες. Ο Μηχανισµός αυτός λειτουργεί µε την χρήση 2 Events. To πρώτο Event (EventGarbageCollection) είναι υπεύθυνο να µειώνει τα reference_bit του σηµαντήρα uri και το Event (EventSychronizeIndex) να καθαρίζει το Index και το Data Store αν δεν υπάρχουν αναφορές από τις Annotation Cache των χρηστών στα article του δεδοµένου group. Πιο κάτω αναφέρουµε 2 διαφορετικές περιπτώσεις λειτουργίας του µηχανισµού: Τέλος να αναφέρουµε ότι ο διαµεσολαβητής κρατά επίσης κατάστιχο µε την ιστορία της λειτουργίας του (log file - /logs/nntp.log) για να είναι δυνατή η αποσφαλµάτωση του διαµεσολαβητή σε τυχόν λάθη που θα προκύψουν κατα την διάρκεια λειτουργίας του Υλοποίηση ιαµεσολαβητή NNTP Ο διαµεσολαβητής NNTP (NNTP Proxy Service Manager) είναι υλοποιηµένoς σαν ένα Concordia Service Bridge [Mit98]. Αυτό σηµαίνει ότι διαµεσολαβητής NNTP µπορεί να είναι εγκαταστηµένος σε µια µηχανή µέσα στο IP δίκτυο και να δέχεται εκκλήσεις από τον χρονοδροµολογητή, που µπορεί να βρίσκεται σε διαφορετικές IP διεύθυνση κάνοντας έτσι εφικτή την κατανοµή του ολικού φόρτου του συστήµατος σε πολλαπλές µηχανές. Εφόσον ο διαχειριστής είναι υλοποιηµένος σαν Service Bridge, σηµαίνει ότι αυτός θα αρχίζει την λειτουργία του µε την εκκίνηση της µηχανής. Κατά την διάρκεια της εκκίνησης του Proxy, αυτός αρχικοποιεί το Proxy DOM, από ένα αρχείο XML (/xml/proxies/nntp). Στο αρχείο αυτό έχει φυλάξει τις πληροφορίες που κρατούσε το Proxy-DOM κατα την διάρκεια του τελευταίου τρεξίµατος του διαµεσολαβητή. Στην συνέχεια το Proxy-DOM παραµένει στην κυρίως µνήµη. Κατά την διάρκεια της εκκίνησης του συστήµατος ο Cache Manager ενώνεται επίσης µε το Concordia Event Manager, ο οποίος βρίσκεται εγκατεστηµένος σε µια µηχανή µέσα στο ΙP δίκτυο και συντονίζει την µεταγωγή µηνυµάτων, και του δηλώνει ποια είδη Events ενδιαφέρεται να ακούσει. Στην συνεχεία παραµένει σε αδράνεια και περιµένει να εξυπηρετήσει διάφορα Events τα οποια καταφθάνουν σε αυτόν και τα οποια είναι: EventNNTP από τον Scheduler -105-

116 EventGarbageCollect από τον Annotation Cache Manager EventStoreNNTPDocument από το ThreadNNTPSearch EventSychronizeIndex από το ThreadNNTPSearch Η υλοποίηση του ThreadNNTPSearch έγινε µε την βοήθεια έτοιµων βιβλιοθηκών. Οι βιβλιοθήκες αυτές ονοµάζονται NetComponents [Oro99]. Με τα πακέτα αυτά ήταν ευκολότερη η υλοποίηση της επικοινωνίας και ανάληψης µηνυµάτων από ένα εξυπηρετητή NNTP. Figure 8: Παράδειγµα εκκίνησης του NNTP Proxy (από την Κονσόλα Λειτουργίας) a. Εσωτερική Επικοινωνία εδοµένων (Ενδοεπικοινωνία εδοµένων) Όπως προαναφέραµε, ο διαχειριστής του διαµεσολαβητή NNTP αναλαµβάνει να εξυπηρετήσει αιτήσεις που γίνονται σε αυτών. Όταν φτάσει µια αίτηση (event) στον διαχειριστή της κρυφής µνήµης, αυτός αναλαµβάνει να διεκπεραιώσει αυτήν την αίτηση, κάνοντας την σχετική εργασία. Ο τρόπος µεταγωγής δεδοµένων στο -106-