ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΑΤΡΩΝ. Τμήμα Μηχανικών Ηλεκτρονικών Υπολογιστών & Πληροφορικής ΔΙΔΑΚΤΟΡΙΚΗ ΔΙΑΤΡΙΒΗ

Transcript

1 ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΑΤΡΩΝ Τμήμα Μηχανικών Ηλεκτρονικών Υπολογιστών & Πληροφορικής ΔΙΔΑΚΤΟΡΙΚΗ ΔΙΑΤΡΙΒΗ Προς το Web 3.0: Διαδικασία Ανάπτυξης και Αρχιτεκτονική Υποστήριξης εφαρμογών Παγκόσμιου Ιστού που συνδυάζουν τεχνολογίες Web 2.0 και Semantic Web. ΤΖΑΝΕΤΟΣ ΠΟΜΟΝΗΣ ΕΠΙΒΛΕΠΩΝ ΚΑΘΗΓΗΤΗΣ Θεόδωρος Σ. Παπαθεοδώρου Εργαστήριο Πληροφοριακών Συστημάτων Υψηλών Επιδόσεων Πάτρα, 2010

2 ΠΑΝΕΠΙΣΤΗΜΙΟ ΠΑΤΡΩΝ Τμήμα Μηχανικών Ηλεκτρονικών Υπολογιστών & Πληροφορικής ΔΙΔΑΚΤΟΡΙΚΗ ΔΙΑΤΡΙΒΗ Προς το Web 3.0: Διαδικασία Ανάπτυξης και Αρχιτεκτονική Υποστήριξης εφαρμογών Παγκόσμιου Ιστού που συνδυάζουν τεχνολογίες Web 2.0 και Semantic Web. ΤΖΑΝΕΤΟΣ ΠΟΜΟΝΗΣ ΕΠΙΒΛΕΠΩΝ: Θεόδωρος Σ. Παπαθεοδώρου, Καθηγητής ΤΡΙΜΕΛΗΣ ΣΥΜΒΟΥΛΕΥΤΙΚΗ ΕΠΙΤΡΟΠΗ: Σπυρίδων Λυκοθανάσης, Καθηγητής Χρήστος Μπούρας, Καθηγητής Θεόδωρος Σ. Παπαθεοδώρου, Καθηγητής ΕΠΤΑΜΕΛΗΣ ΕΞΕΤΑΣΤΙΚΗ ΕΠΙΤΡΟΠΗ: Ιωάννης Γαροφαλάκης, Αν. Καθηγητής Σπυρίδων Λυκοθανάσης, Καθηγητής Χρήστος Μπούρας, Καθηγητής Θεόδωρος Σ. Παπαθεοδώρου, Καθηγητής Εμμανουήλ Τζαγκαράκης, Λέκτορας Παναγιώτης Τριανταφύλλου, Καθηγητής Αθανάσιος Τσακαλίδης, Καθηγητής Πάτρα, 2010

3 Στους γονείς μου Θοδωρή και Ειρήνη iii

4 Ευχαριστίες Κατά τη διάρκεια της συγγραφής της μεταπτυχιακής διπλωματικής εργασίας μου με βοήθησαν με διαφορετικό τρόπο αρκετά άτομα. Έτσι θα ήθελα να ευχαριστήσω τον επιβλέποντα καθηγητή μου Θεόδωρο Σ. Παπαθεοδώρου, ο οποίος με καθοδήγησε κατά την εκπόνηση της ερευνητικής εργασίας και μου παρείχε την υποδομή του Εργαστηρίου Πληροφοριακών Συστημάτων Υψηλών Επιδόσεων, αλλά κυρίως τις ευκαιρίες να ασχοληθώ με το θέμα της διατριβής, τα υπόλοιπα μέλη της τριμελούς συμβουλευτικής επιτροπής καθηγητές Σπυρίδωνα Λυκοθανάση και Χρήστο Μπούρα για τη συμβολή τους, καθώς και τα μέλη της επταμελούς εξεταστικής επιτροπής καθηγητές Ιωάννη Γαροφαλάκη, Εμμανουήλ Τζαγκαράκη, Παναγιώτη Τριανταφύλλου και Αθανάσιο Τσακαλίδη που δέχθηκαν πρόθυμα να αξιολογήσουν την παρούσα διατριβή, όλους τους επί σειρά ετών συνεργάτες και συναδέλφους μου στο Εργαστήριο Πληροφοριακών Συστημάτων Υψηλών Επιδόσεων, τον πολύ καλό φίλο και συμπαίκτη μου, αλλά και άμεσο συνεργάτη μου στην παρούσα διατριβή, Σωτήρη Χριστοδούλου, ο οποίος με την τεκμηριωμένη κριτική του με καθοδήγησε σε όλα τα στάδια της ερευνητικής μου δραστηριότητας και μου προσέφερε σημαντικές και πολύτιμες συμβουλές για την εκπόνηση της διατριβής μου, και την οικογένειά μου για τη συμπαράσταση και στήριξη της όλα αυτά τα χρόνια. Χωρίς αυτούς δε θα γραφόταν τίποτα απ' όλα ετούτα... iv

5 Πίνακας Περιεχομένων 1.Εισαγωγή Περί Web Semantic Web Ορισμός Αρχιτεκτονική και Τεχνολογίες Web Ορισμός Αντιρρήσεις για τον όρο Web Τεχνολογίες του Web Web Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web Αρχιτεκτονικές Υποστήριξης Εφαρμογών Παγκόσμιου Ιστού Client-Server Αρχιτεκτονική Model-View-Controller Αρχιτεκτονική tier Αρχιτεκτονική XRX Αρχιτεκτονική tier Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web Λειτουργικά Χαρακτηριστικά Θέματα Υλοποίησης Απομακρυσμένη Διασύνδεση σε Μηχανισμούς Συλλογισμού Server Εφαρμογή Client Εφαρμογή Πειραματικές Μετρήσεις Διαδικασία Ανάπτυξης Εφαρμογών του Web Διαδικασίες Ανάπτυξης Εφαρμογών Παγκόσμιου Ιστού Διαδικασία Ανάπτυξης Εφαρμογών του Web Διαδικασία Ανάπτυξης Εφαρμογών του Semantic Web Ενοποιημένη Διαδικασία Ανάπτυξης Εφαρμογών του Web Διαχείριση Ομάδας Ανάπτυξης Εφαρμογών του Web v

6 5.Πιλοτική Εφαρμογή 5.1 Επισκόπηση Τεχνολογιών Η εφαρμογή Βαθμίδα Διαχείρισης Γνώσης Βαθμίδα Λογικής της Εφαρμογής Βαθμίδα Διεπαφής της Εφαρμογής Συμπεράσματα και Μελλοντική Εργασία...95 Βιβλιογραφία...97 vi

7 Κατάλογος Εικόνων Εικόνα 2.1: Οι Τέσσερις Εκδοχές της Αρχιτεκτονικής του Semantic Web...9 Εικόνα 2.2: Σχεδιαστική Απεικόνιση του Web Εικόνα 3.1: Η Client-Server Αρχιτεκτονική...22 Εικόνα 3.2: Η MVC Αρχιτεκτονική...26 Εικόνα 3.3: MVC Passive Model...27 Εικόνα 3.4: MVC Active Model...28 Εικόνα 3.5: Η Λειτουργία του Observer στην MVC...29 Εικόνα 3.6: Η 3-tier Αρχιτεκτονική...32 Εικόνα 3.7: Η Προτεινόμενη 3-tier Αρχιτεκτονική...40 Εικόνα 3.8: Server Εφαρμογή...48 Εικόνα 3.9: Πολυνηματικός Server...49 Εικόνα 3.10: Client Εφαρμογή...50 Εικόνα 4.1: Παραδοσιακές Διαδικασίες Ανάπτυξης Λογισμικού...59 Εικόνα 4.2: Διαδικασία Ανάπτυξης Εφαρμογών του Web Εικόνα 4.3: Διαδικασία Ανάπτυξης Οντολογιών...65 Εικόνα 4.4: Διαδικασία Ανάπτυξης Εφαρμογών του Web Εικόνα 4.5: Απαιτήσεις Έργου για Εφαρμογές του Web Εικόνα 4.6: Διάγραμμα Έργου Web Εικόνα 5.1: Η Αρχιτεκτονική της Εφαρμογής Εικόνα 5.2: Η Οντολογία BookShop...75 Εικόνα 5.3: Σύνολα Βιβλίων...82 Εικόνα 5.4: Τμήμα του Αρχείου XML με τα Αποτελέσματα Αναζήτησης...89 Εικόνα 5.5: Σχεδιάγραμμα της Επικοινωνίας με τα Web APIs...91 Εικόνα 5.6: Φόρμα Αναζήτησης Βιβλίων...91 Εικόνα 5.7: Σελίδα Παρουσίασης των Αποτελεσμάτων της Αναζήτησης...92 Εικόνα 5.8: Προβολή των Στοιχείων ενός Βιβλίου...93 Εικόνα 5.9: Αλλαγή των Προτιμήσεων του Χρήστη...94 vii

8 Κατάλογος Πινάκων Πίνακας 3.1: Μετρήσεις Τοπικής Εγκατάστασης με Διάφορες Συνθέσεις Υποδομής...53 Πίνακας 3.2: Μετρήσεις Με και Χωρίς Απομακρυσμένη Επικοινωνία...54 Πίνακας 3.3: Μετρήσεις σε Διαφορετικά Είδη Δικτυακής Σύνδεσης...55 Πίνακας 3.4: Μετρήσεις για Επικοινωνία μέσω Java Serialization και URI...56 Πίνακας 5.1: Η Κλάση Book...76 Πίνακας 5.2: Η Κλάση Offer...77 Πίνακας 5.3: Η Κλάση User...77 Πίνακας 5.4: Ιδιότητες Αντικειμένων της Οντολογίας BookShop...77 Πίνακας 5.5: Τα ResponseGroups σε κάθε Request προς το Amazon API...86 viii

9 1. Εισαγωγή Έως σήμερα, αρκετοί οργανισμοί έχουν επιτυχώς αναπτύξει μεγάλης κλίμακας και υψηλής ποιότητας ιστότοπους, αλλά περισσότεροι είναι εκείνοι που έχουν αποτύχει, ή αντιμετωπίζουν το ενδεχόμενο της αποτυχίας στο άμεσο μέλλον, καθώς αδυνατούν να παρακολουθήσουν τις εξελίξεις στον Παγκόσμιο Ιστό. Η βασική αιτία αποτυχίας είναι η ανεπαρκής διαδικασία σχεδιασμού, ανάπτυξης και συντήρησης, καθώς και η έλλειψη επαρκούς συνεχιζόμενης ενημέρωσης για τις τεχνολογικές δυνατότητες. Ο τρόπος που πρέπει να εξεταστούν και να ξεπεραστούν αυτά τα προβλήματα είναι κρίσιμος για την πραγματοποίηση του βασικού στόχου του W3 Consortium: Leading the Web to Its Full Potential.... Καθώς μάλιστα η καθημερινή χρήση των εφαρμογών Ιστού αυξάνει δραματικά, και τα πληροφοριακά συστήματα που υποστηρίζουν αυτές τις εφαρμογές γίνονται ολοένα και πιο πολύπλοκα, υπάρχει μια αυξανόμενη ανησυχία για την ποιότητα, την ακεραιότητα και τη συντηρησιμότητά τους, χαρακτηριστικά που έχουν άμεση σχέση με τον τρόπο που αναπτύσσονται οι εφαρμογές και τα συστήματα Ιστού. Τα τελευταία χρόνια, αυτή η διαφαινόμενη κρίση του Παγκόσμιου Ιστού, όπως αποκλήθηκε, συνετέλεσε στην ανάπτυξη της Επιστήμης Τεχνολογίας Παγκόσμιου Ιστού (Web Engineering) σαν ξεχωριστό πεδίο έρευνας, το οποίο ορίσθηκε από πεπειραμένους ερευνητές (Deshpande et al., 2002) ως: Η εφαρμογή συστηματικών, πειθαρχημένων και ποσοτικά προσδιορίσιμων προσεγγίσεων στην ανάπτυξη, τη λειτουργία, και τη συντήρηση Πληροφοριακών Συστημάτων για τον Παγκόσμιο Ιστό. Είναι τόσο μια δυναμική προσέγγιση όσο και μια αυξανόμενη συλλογή θεωρητικής και εμπειρικής έρευνας στην ανάπτυξη εφαρμογών Παγκόσμιου Ιστού. Η ανάγκη για μια ξεχωριστή ερευνητική περιοχή ειδικά για τον Παγκόσμιο Ιστό, είχε 1

10 Εισαγωγή γίνει επιτακτική, λόγω και των πολλών ιδιαίτερων χαρακτηριστικών του. Ως πλατφόρμα ανάπτυξης περιεχομένου και εφαρμογών, ο Παγκόσμιος Ιστός μετατρέπεται σε ένα πολυδιάστατο πεδίο, όπου συναντώνται τεχνολογίες και μοντέλα ανάπτυξης από πολλά άλλα πεδία όπως Υπερμέσα, Πολυμέσα, Βάσεις Δεδομένων, Τεχνολογία Λογισμικού, Τεχνολογίες Δικτύων, Αλληλεπίδραση Ανθρώπου-Υπολογιστή, Κατανεμημένα Συστήματα, κτλ. Το πρόβλημα γίνεται ακόμα πιο σύνθετο αν αναλογισθεί κανείς την ταχύτητα με την οποία εξελίσσονται οι τεχνολογίες του Παγκόσμιου Ιστού που συνεχώς διευρύνουν το φάσμα των εφικτών εφαρμογών, προκαλώντας όμως μεγαλύτερη πολυπλοκότητα στον κύκλο ζωής. Η παρούσα διατριβή έχει ως στόχο να συνεισφέρει στον τομέα του Web Engineering εισάγοντας τρόπους αντιμετώπισης αυτών των προβλημάτων που αντιμετωπίζουν οι Μηχανικοί Παγκόσμιου Ιστού κατά τη διάρκεια του κύκλου ζωής των Εφαρμογών και των Πληροφοριακών Συστημάτων Παγκόσμιου Ιστού επόμενης γενιάς, και ειδικότερα κατά το σχεδιασμό, την ανάπτυξη και συντήρησή τους. Ειδικά τα τελευταία χρόνια, η εξέλιξη των εφαρμογών Παγκόσμιου Ιστού στηρίζεται, κατά κύριο λόγο, σε δυο τεχνολογικούς πυλώνες : στις βασικές αρχές και τεχνολογίες του Web 2.0 (O Reilly, 2005) και στο Semantic Web (Berners-Lee et al., 2001). Είναι ισχυρή η πεποίθηση πως αυτές οι δύο διαφορετικές σχολές στην εξέλιξη του Παγκόσμιου Ιστού δε βρίσκονται σε σύγκρουση μεταξύ τους, αλλά μπορούν να συνδυαστούν κατάλληλα ώστε να ξεπεράσουν τις όποιες εγγενείς αδυναμίες τους. Κατ' αυτόν τον τρόπο, οι εφαρμογές Παγκόσμιου Ιστού της επόμενης γενιάς θα είναι σε θέση να συνδυάζουν τις αρχές του Web 2.0, κυρίως αυτές που στοχεύουν στην ευχρηστία των εφαρμογών και στη συνεργατική ανάπτυξη, με το ισχυρό τεχνολογικό υπόβαθρο του Semantic Web που διευκολύνει σε μεγάλο βαθμό την ανταλλαγή και το διαμοιρασμό πληροφορίας μεταξύ των εφαρμογών Παγκόσμιου Ιστού. Προσφάτως, έχει αρχίσει να χρησιμοποιείται ευρέως ο όρος Web 3.0 για να περιγράψει τη μελλοντική κατεύθυνση που τείνουν να ακολουθήσουν οι εφαρμογές Παγκόσμιου Ιστού (Lassila & Hendler, 2007; Hendler, 2008). Το Web 3.0 προβλέπεται σαφώς να περιλαμβάνει τις αρχές του Semantic Web και του Web 2.0, αλλά οι ερευνητές πιστεύουν πως θα 2

11 Εισαγωγή περιλαμβάνει επίσης και κάποια πιο εξειδικευμένα πεδία όπως η Τεχνητή Νοημοσύνη στον Παγκόσμιο Ιστό (Web AI) (Tenenbaum, 2006). Σε κάθε περίπτωση πάντως, δεν έχει καταστεί ξεκάθαρο, όχι μόνο το ποια θα είναι τα πλήρη χαρακτηριστικά του Web 3.0, αλλά και το ποιες θα είναι οι κατάλληλες διαδικασίες και τεχνολογίες, με βάση τις οποίες θα μπορούν να δομηθούν και να αναπτυχθούν οι αντίστοιχες εφαρμογές επόμενης γενιάς, με αποτέλεσμα η πορεία προς το Web 3.0 να γίνεται προς το παρόν με αυθαίρετο και άναρχο τρόπο. Σε αυτή την κατεύθυνση, αρχικά, στο Κεφάλαιο 2, μελετάται η παρούσα κατάσταση σχετικά με την υποστήριξη των εφαρμογών του Παγκόσμιου Ιστού, ιδιαίτερα σε ό,τι αφορά τις δύο σημαντικότερες τάσεις του Παγκόσμιου Ιστού, το Semantic Web και το Web 2.0, και τη σχέση τους με το Web 3.0. Στη συνέχεια γίνονται συγκεκριμένες προτάσεις για τη βελτίωση της υφιστάμενης κατάστασης, συμπεριλαμβάνοντας ανάπτυξη μεθοδολογιών, σχεδιασμό αρχιτεκτονικών και συγκεκριμένες υλοποιήσεις. Σαν πρώτο βήμα, στο Κεφάλαιο 3, προτείνεται μια αρχιτεκτονική τριών επιπέδων (3tier), η οποία αφενός, στο χαμηλότερο επίπεδο, περιλαμβάνει μια ισχυρή υποδομή σημασιακής βάσης γνώσης που μπορεί να υποστηρίξει το συνδυασμό πολλαπλών διάσπαρτων πηγών δεδομένων χωρίς να απαιτεί ένα ισχυρό προϋπάρχον σημασιακό υπόβαθρο, και αφετέρου, στα ψηλότερα επίπεδα, προσφέρει μεγάλη ευελιξία στο χρήστη κατά την αλληλεπίδραση με την εφαρμογή Παγκόσμιου Ιστού αλλά και με το υποκείμενο μοντέλο οντολογιών, και μπορεί να υποστηρίξει αποδοτικά την ανάπτυξη και λειτουργία των εφαρμογών Παγκόσμιου Ιστού επόμενης γενιάς. Επίσης, ένα από τα σημαντικότερα τμήματα της παρούσας διατριβής, στο Κεφάλαιο 4, είναι η πρόταση για μια συγκεκριμένη διαδικασία ανάπτυξης και ένα μοντέλο κύκλου ζωής των εφαρμογών του Web 3.0, όπου, λαμβάνοντας υπόψη τα ιδιαίτερα στοιχεία και τον διττό χαρακτήρα των εν λόγω εφαρμογών, δίνονται εμπεριστατωμένα βήματα για το πως μπορούν ξεπεραστούν τα όποια εμπόδια και να υπάρξει η μέγιστη δυνατή απόδοση κατά το σχεδιασμό και την ανάπτυξη των εφαρμογών Παγκόσμιου Ιστού επόμενης γενιάς. 3

12 Εισαγωγή Με βάση τα παραπάνω, στο Κεφάλαιο 5, δίνεται η δυνατότητα για την ανάπτυξη κάποιων ενδεικτικών εφαρμογών Παγκόσμιου Ιστού, οι οποίες συνδυάζουν τη φιλοσοφία του Web 2.0 και το ισχυρό τεχνολογικό υπόβαθρο του Semantic Web. Τέλος, στο Κεφάλαιο 6, παρουσιάζονται τα συμπεράσματα που προκύπτουν από τη συγκεκριμένη διατριβή, και παρουσιάζονται κάποιες σκέψεις για μελλοντικά βήματα και πιθανές επεκτάσεις της. Σε κάθε περίπτωση, λαμβάνοντας υπόψη την υπό εξέλιξη φύση του Παγκόσμιου Ιστού και των προβλημάτων που προκύπτουν στον κύκλο ζωής εφαρμογών και πληροφοριακών συστημάτων για αυτόν, ιδιαίτερη έμφαση δίνεται ώστε τα αποτελέσματα της διατριβής να έχουν τα παρακάτω χαρακτηριστικά: Να λαμβάνουν υπόψη και να βασίζονται σε τεχνολογίες και διεθνή πρότυπα του πυρήνα του Παγκόσμιου Ιστού που έχουν μεγαλύτερο μέσο όρο ζωής. Να σχεδιαστούν και να υλοποιηθούν ευέλικτα, ώστε να μπορούν, σε μεγάλο βαθμό, να επεκταθούν και να προσαρμοσθούν στις εξελίξεις. Να περιέχουν επαρκή αφαιρετικά στοιχεία, ώστε η προσέγγιση που εισάγεται να έχει γενικότερη εφαρμοσιμότητα και να μπορεί να αποτελέσει τη βάση για την αντιμετώπιση και άλλων συναφών ζητημάτων που παρουσιάζουν παρόμοια λογική και πολυπλοκότητα. Να υποστηρίζουν έμμεσα ή άμεσα την ταχεία και αποδοτική ανάπτυξη εφαρμογών και συστημάτων Παγκόσμιου Ιστού, την εύκολη συντήρηση τους, την επαναχρησιμοποίηση τμημάτων τους και τη διαλειτουργικότητά τους με άλλες εφαρμογές και συστήματα. Αυτά τα χαρακτηριστικά δύνανται να καταστήσουν τα αποτελέσματα αυτά εφαρμόσιμα σήμερα αλλά και στο μεσοπρόθεσμο μέλλον, είτε με μικρές προσαρμογές είτε αποτελώντας ένα οδηγό και ένα πυρήνα βάσει του οποίου θα αντιμετωπισθούν προβλήματα του Παγκόσμιου Ιστού της επόμενης γενιάς. 4

13 2. Περί Web Μέσα σε σχεδόν δυο δεκαετίες ζωής, ο Παγκόσμιος Ιστός (World Wide Web) γνώρισε μια πραγματικά εκρηκτική ανάπτυξη που επιδεικνύεται από την έκταση χρήσης του, την εμβέλεια των πεδίων εφαρμογών του και το πλήθος των πληροφοριακών του συστημάτων. Ενώ αρχικά σχεδιάστηκε και υλοποιήθηκε σαν ένα περιβάλλον για εύκολη και εύχρηστη ανταλλαγή πληροφοριών, κυρίως υπό τη μορφή εγγράφων, τα πεδία εφαρμογών του σήμερα περιορίζονται μόνο από τη φαντασία. Το αρχικό απλό και εύχρηστο εγγραφο-κεντρικό (document-centric) μοντέλο του Παγκόσμιου Ιστού που όμως περιόριζε τη δυναμική του, έχει εξελιχθεί σημαντικά την τελευταία δεκαετία και επεκτείνεται συνεχώς με νέες ιδέες και τεχνολογίες, με σημαντικότερες το Semantic Web και το Web 2.0, για να μπορεί να υποστηρίζει εξελιγμένες και πιο ευφυείς εφαρμογές. Ο ρόλος του πλέον έχει επεκταθεί και επηρεάζει καθοριστικά τον τρόπο λειτουργίας των επιχειρήσεων, της οικονομίας, της βιομηχανίας, των τραπεζών, της εκπαίδευσης, των κυβερνήσεων, των μέσων μαζικής ενημέρωσης, καθώς και τον καθημερινό τρόπο ζωής, δουλειάς και διασκέδασης της πλειονότητας των ανθρώπων. 2.1 Semantic Web Ο Tim Berners-Lee, μετά την ιδέα για τη δημιουργία του Παγκόσμιου Ιστού, είχε ένα καινούριο όραμα. Το Web να γίνει ένα καθολικό μέσο για ανταλλαγή δεδομένων, γνώσης και πληροφορίας. Με βάση αυτό το όραμα τέθηκαν τα θεμέλια για τη δημιουργία του Semantic Web (Berners-Lee et al., 2001). Σε αυτό το πλαίσιο, το W3C (World Wide Web Consortium), η κοινοπραξία που καθορίζει και εξελίσσει τα πρότυπα του Web, οδηγεί τις δράσεις για την ανάπτυξη του Semantic Web. Το Semantic Web φιλοδοξεί να επιτρέψει στην πληροφορία να είναι κατανοητή και από 5

14 Περί Web υπολογιστές, καθιστώντας τους ικανούς να αυτοματοποιήσουν σε μεγάλο βαθμό την επεξεργασία της πληροφορίας που υπάρχει στο Web. Έτσι, σε μια ιστοσελίδα, οι άνθρωποι θα μπορούν να διαβάσουν την πληροφορία που περιέχει, αλλά και οι υπολογιστές να κατανοήσουν σημαντικό τμήμα του περιεχόμενού της και να προβούν σε συγκεκριμένες ενέργειες που έχει ορίσει ο χρήστης Ορισμός Το Semantic Web είναι μία προσπάθεια να γίνουν οι πόροι του Παγκόσμιου Ιστού προσιτοί σε αυτοματοποιημένες διεργασίες προσθέτοντας πληροφορίες που επεξηγούν ή ορίζουν το περιεχόμενό τους, φιλοδοξώντας να αποτελέσει ένα παγκόσμιο μέσο για ανταλλαγή πληροφοριών. Η λέξη Semantic έχει ρίζα τις ελληνικές λέξεις σημάδι, σημαίνω και σημαντικός και σήμερα αναφέρεται στο νόημα, συχνά σε επίπεδο γλώσσας. Πολλοί υποστηρίζουν ότι το Semantic Web αποτελεί το μεγαλύτερο, σε παγκόσμιο επίπεδο, έργο έξυπνης ενσωμάτωσης συστημάτων, ώστε να συνεργάζονται δια-λειτουργικά. Ο Tim Berners-Lee, ο εμπνευστής του Παγκόσμιου Ιστού, υπήρξε δημιουργός και καθοδηγητής και του Semantic Web, ορίζοντας το ως εξής (Berners-Lee et al., 2001): Το Semantic Web δεν είναι ένα ξεχωριστό Web, αλλά μία επέκταση του Παγκόσμιου Ιστού, όπου η πληροφορία έχει καλά καθορισμένο νόημα, καθιστώντας τη συνεργασία μεταξύ ανθρώπων και υπολογιστών πιο αποτελεσματική. Ένα άλλο σημαντικό μέλος του W3C, ο Daniel Dardailler, ερμηνεύει τον όρο Semantic Web σε συνέντευξή του ως εξής: Η λέξη semantics έχει λίγο-πολύ διαφορετική σημασία στα διάφορα επιστημονικά και τεχνικά πεδία. Στην έκφραση Semantic Web χρησιμοποιείται για να προσδιορίσει έναν Παγκόσμιο Ιστό, όπου η δομή της πληροφορίας μεταδίδει και τη σημασία της. Αντίθετα, στο σημερινό Web, η πλειοψηφία του περιεχομένου έχει δομηθεί έτσι ώστε να δείχνει ωραία για 6

15 Περί Web ανθρώπινη κατανάλωση. Το Semantic Web είναι μία επέκταση του σημερινού Web, η οποία θα μας επιτρέπει να βρίσκουμε, να διαμοιραζόμαστε και να συνδυάζουμε την πληροφορία πιο εύκολα. Είναι σχεδιασμένο με τρόπο ώστε να αποτελεί ένα καθολικό μέσο για την ανταλλαγή δεδομένων και επιτρέπει τον ορισμό και την επαναχρησιμοποίηση λεξικολογικών όρων από οποιοδήποτε πρόσωπο ή κοινότητα χρηστών. Έτσι, καθίσταται περισσότερο αποδοτική η καταγραφή και η διαμοίραση της γνώσης με άλλους. Με βάση αυτό το σκεπτικό, το Semantic Web δεν αποτελεί κάτι εντελώς νέο, αλλά μια επέκταση του υπάρχοντος Παγκόσμιου Ιστού, στην οποία η πληροφορία που παρουσιάζεται στο χρήστη ορίζεται με τέτοιο τρόπο ώστε να είναι κατανοητή όχι μόνο από τους ανθρώπους, αλλά και από τους πράκτορες λογισμικού (software agents). Με αυτό τον τρόπο διευκολύνεται η διαλειτουργικότητα της επεξεργασίας των πληροφοριών μεταξύ των πρακτόρων λογισμικού, αλλά επίσης ενισχύεται και η ευχρηστία του Web για τους ανθρώπους με τη βοήθεια των τελευταίων. Και αυτό γιατί το Semantic Web βασίζεται στην ιδέα της οργάνωσης και διασύνδεσης της πληροφορίας που υπάρχει στο διαδίκτυο, ώστε να μπορεί να χρησιμοποιηθεί πιο αποτελεσματικά για την ανακάλυψη, αυτοματοποίηση, ομαδοποίηση και επαναχρησιμοποίηση της από διαφορετικές μεταξύ τους διαδικτυακές εφαρμογές. Το Semantic Web φιλοδοξεί να παρέχει στο μέλλον την υποδομή που απαιτείται για τη δημιουργία και την αξιοποίηση του συνόλου των πληροφοριών από ένα πλήθος διαδικτυακών εφαρμογών που θα περιλαμβάνουν, εκτός από τις απλές ιστοσελίδες, τις εταιρικές βάσεις δεδομένων, τις διαδικτυακές ηλεκτρονικές υπηρεσίες, τους πράκτορες λογισμικού, ακόμη και τις οικιακές συσκευές. Με το νέο αυτό τρόπο οργάνωσης των δεδομένων, οι ευφυείς πράκτορες λογισμικού που μετά από αίτηση κάποιου χρήστη αναζητούν πληροφορίες ή παρεχόμενες υπηρεσίες στο διαδίκτυο, θα έχουν τη δυνατότητα να φιλτράρουν καλύτερα τα δεδομένα που συλλέγουν. Έτσι αυτά θα ανταποκρίνονται πραγματικά στις ανάγκες του χρήστη και θα παρουσιάζονται με κατανοητή μορφή. Σε αυτό το πλαίσιο, το όραμα του Semantic Web συνεχώς ενδυναμώνεται με τη γέννηση 7

16 Περί Web μιας νέας γενιάς τεχνολογιών και εργαλείων. Συγκεκριμένα, δημιουργούνται νέες γλώσσες, όπως οι XML, RDF, OWL, που αναπαριστούν την πληροφορία σε μορφή εύκολα κατανοητή και επεξεργάσιμη από τους πράκτορες. Βέβαια, το Semantic Web δεν είναι ακόμα υπαρκτό, αλλά υπάρχει μια εξαιρετικά σημαντική κινητικότητα ερευνητών και εταιριών οι οποίες αναπτύσσουν τις συγκεκριμένες τεχνολογίες καθώς και κάποιες (όχι ακόμα αρκετές) εφαρμογές οι οποίες βασίζονται πάνω στις τεχνολογίες αυτές. Παρόλα αυτά το όραμα του Semantic Web ίσως να μην είναι και τόσο μακρινό αν γίνει ένας παραλληλισμός με τη διάδοση του ίδιου του διαδικτύου. Το 1989, όταν δηλαδή ο Παγκόσμιος Ιστός έκανε τα πρώτα βήματα για την παγκόσμια καθιέρωσή του, η ανακάλυψη και ανάκτηση πληροφοριών από απομακρυσμένα συστήματα ήταν κάτι που μόνο ένας ειδικός μπορούσε να κάνει. Το διαδίκτυο ως τεχνολογικό υπόβαθρο υπήρχε και θεωρητικά έδινε δυνατότητα πρόσβασης σε αυτά τα συστήματα, υπήρχαν όμως σημαντικά προβλήματα ευχρηστίας εξαιτίας των διαφορετικών πρωτοκόλλων πρόσβασης, ακόμη και μέσα στο ίδιο σύστημα. Με την ανάπτυξη του Παγκόσμιου Ιστού, η διασύνδεση των διαφόρων πηγών πληροφοριών έγινε πολύ εύκολη υπόθεση, χωρίς να λαμβάνονται υπόψη ποια πρωτόκολλα χρησιμοποιούνται, καθώς η ανάπτυξη των διασυνδέσεων Ιστού είναι προσανατολισμένη προς τον άνθρωπο-χρήστη. Το αποτέλεσμα όμως των παραπάνω ήταν πως, ακόμη και αν οι πληροφορίες αυτές αντλούνται από μια καλά οργανωμένη βάση δεδομένων, η δομή αυτή δεν είναι ευδιάκριτη για έναν ευφυή πράκτορα λογισμικού που αναζητά στοιχεία, με αποτέλεσμα να μην είναι εύκολη η αυτοματοποίηση κάποιων χρονοβόρων και επίπονων εργασιών στο διαδίκτυο από πράκτορες λογισμικού, πρόβλημα που αναμένεται να ξεπεραστεί με την καθιέρωση του Semantic Web Αρχιτεκτονική και Τεχνολογίες Για να επιτευχθεί αυτή η εξέλιξη, το Semantic Web είναι οργανωμένο σε μία σειρά επιπέδων. Τα επίπεδα αυτά δεν ανταποκρίνονται αυστηρά στην έννοια της αρχιτεκτονικής 8

17 Περί Web λογισμικού, αλλά αποτελούν περισσότερο τεχνολογικά επίπεδα λειτουργικότητας. Οι τέσσερις διαφορετικές εκδοχές της διαστρωμάτωσης των τεχνολογιών στις οποίες βασίζεται η εξέλιξη του Semantic Web (Gerber et al., 2008), όπως προκύπτουν με την εξέλιξη του όρου του Semantic Web από την πρώτη του εμφάνιση, παρουσιάζονται στην Εικόνα 2.1. Εικόνα 2.1: Οι Τέσσερις Εκδοχές της Αρχιτεκτονικής του Semantic Web Η ανάπτυξη του Semantic Web ακολουθεί ένα ιεραρχικό σύστημα επιπέδων όπου το καθένα βρίσκεται πάνω από ένα άλλο, επεκτείνοντάς το. Κάθε επίπεδο αφορά έναν περιορισμένο τομέα του συνόλου των δραστηριοτήτων του Semantic Web, καθιστώντας έτσι παραγωγική τη συνεργασία ανάμεσα στις εκάστοτε επιστημονικές ομάδες. Αν το Semantic Web δεν ακολουθούσε αυτή την αρχιτεκτονική και αντιμετωπιζόταν ως ένα ενιαίο και ευρύ ερευνητικό πεδίο, θα ήταν πολύ πιθανό να υπάρχουν πολλές αποκλίσεις ανάμεσα στις απόψεις των επιστημόνων που συμμετέχουν στην προσπάθεια δημιουργίας των απαραίτητων 9

18 Περί Web προτύπων. Στην αρχιτεκτονική επιπέδων του Semantic Web ακολουθούνται δύο βασικές αρχές: Συμβατότητα προς τα κατώτερα επίπεδα. Οι πράκτορες λογισμικού και οι διαδικτυακές εφαρμογές που αντιλαμβάνονται πλήρως ένα επίπεδο θα πρέπει να είναι αυτομάτως σε θέση να χρησιμοποιήσουν και τις πληροφορίες των κατώτερων επιπέδων. Αποσπασματική κατανόηση των ανώτερων επιπέδων. Οι πράκτορες λογισμικού που αντιλαμβάνονται πλήρως ένα επίπεδο θα πρέπει να έχουν τη δυνατότητα να χρησιμοποιήσουν κάποιο μέρος από τις πληροφορίες των ανώτερων επιπέδων. Όπως φαίνεται το Semantic Web θεμελιώνεται πάνω στην ήδη υπάρχουσα υποδομή του Παγκόσμιου Ιστού: στο πρωτόκολλο HTTP για τη μεταφορά δεδομένων, στα URIs για την ονοματολογία, στην κωδικοποίηση Unicode για καθολική προσπέλαση και στην XML ως κοινή συντακτική μορφή. Πάνω στις τεχνολογίες αυτές το Semantic Web προσθέτει συνολικά πέντε επίπεδα, ορισμένα από τα οποία έχουν ήδη υλοποιηθεί: Μία κοινή αναπαράσταση για ημιδομημένα δεδομένα και μεταδεδομένα, το RDF. Μία κοινή αναπαράσταση για τις οντολογίες, που επιτρέπουν στους όρους που χρησιμοποιούνται στο επίπεδο δεδομένων να ορίζονται και να συσχετίζονται μεταξύ τους (RDFS, DAML+OIL, OWL). Το επίπεδο της λογικής (logic), που παρέχει το υπόβαθρο για τη δυνατότητα αυτοματοποιημένου συλλογισμού και εξαγωγής συμπερασμάτων βάσει των πληροφοριών που δομούνται σε μία οντολογία. Το επίπεδο αυτό επιπλέον καθιστά δυνατή, και ισχυροποιεί με τη χρήση τυπικών κανόνων βάσει των οποίων γίνεται εφικτή, τη (ψευδο-)ευφυή διαδικασία λήψης αποφάσεων από τις υπολογιστικές 10

19 Περί Web μηχανές. Το επίπεδο της απόδειξης (proof), ώστε τα αποτελέσματα που συμπεραίνονται από δεδομένα στο Semantic Web να μπορούν να οδηγήσουν πίσω στις υποθέσεις που τα προκάλεσαν. Το επίπεδο της εμπιστοσύνης (trust), όπου σε συνδυασμό με την τεχνολογία των ψηφιακών υπογραφών (digital signatures), θα εξασφαλίζει, με αυτοματοποιημένο τρόπο, το βαθμό στον οποίο οι πληροφορίες που διακινούνται, επεξεργάζονται και συμπεραίνονται στο Semantic Web είναι αξιόπιστες. 2.2 Web 2.0 Αντίθετα με το Semantic Web, το Web 2.0 είναι μια φράση που εφευρέθηκε από τον Tim O'Reilly της O'Reilly Media (O'Reilly, 2005), και αναφέρεται σε μια υποτιθέμενη ή προτεινόμενη δεύτερη γενιά υπηρεσιών βασισμένων στο Διαδίκτυο, όπως οι ιστότοποι κοινωνικής δικτύωσης (social networking sites), τα wiki, τα εργαλεία επικοινωνίας και οι folksonomies, που δίνουν έμφαση στην ηλεκτρονική συνεργασία και ανταλλαγή μεταξύ των χρηστών. Αρχικά, η O'Reilly Media, σε συνεργασία με την MediaLive International, χρησιμοποίησε αυτήν τη φράση σαν τίτλο για μια σειρά από συνέδρια, όμως στη συνέχεια αρκετοί προγραμματιστές και διαφημιστές την υιοθέτησαν πλήρως. Το ακριβές νόημά της παραμένει ανοιχτό προς αντιπαράθεση, και μερικοί ειδικοί, συμπεριλαμβανομένου και του Tim Berners-Lee, έχουν αμφισβητήσει εάν ο όρος έχει κάποιο πραγματικό νόημα. Σύμφωνα με τους θιασώτες του όρου, το Web αλλάζει επειδή αλλάζει η νοοτροπία των δημιουργών των ιστότοπων, των προγραμματιστών αλλά και των απλών χρηστών. Το Web 2.0 είναι περισσότερο δημοκρατικό, καθώς ο ρόλος των ισχυρών, παραδοσιακών δημιουργών και εκδοτών περιεχομένου αποδυναμώνεται. Η αλληλεπίδραση των χρηστών με το 11

20 Περί Web περιεχόμενο και άλλους χρήστες εντείνεται, ενώ η νέα χρήση των ήδη υπαρχουσών τεχνολογιών και εργαλείων δίνει καινούριες διαστάσεις και προστιθέμενη αξία στο περιεχόμενο. Τέλος οι λέξεις υλικό και λογισμικό περνάνε σε δεύτερη μοίρα ενώ αναδεικνύεται το Web ως μια νέα, καθολική πλατφόρμα. Ο νέος Παγκόσμιος Ιστός που ακούει στο όνομα Web 2.0 ενθαρρύνει τη συμμετοχή των χρηστών και την παραγωγή ενός πλουσιότερου, πιο σύγχρονου και δυναμικότερου περιεχομένου, προσφέροντας σε όλους τους χρήστες του το ρόλο του δημιουργού και του εκδότη αφού ταυτόχρονα με τους προγραμματιστές, και οι απλοί χρήστες είναι σε θέση να δημιουργούν χρησιμοποιώντας τη θέληση και τη φαντασία τους. Παράλληλα με τη διαμόρφωση του, διαφόρων μορφών, περιεχομένου, όπως κείμενο, ήχος, εικόνα, βίντεο, στους χρήστες επαφίεται και η κατηγοριοποίηση, η αξιολόγηση και η κατάταξή του, όπως, για παράδειγμα, ποια θεωρείται από αυτούς ως η περισσότερο σημαντική πληροφορία μέσα από ένα τεράστιο πλήθος πληροφοριών. Επιπρόσθετα, το Web 2.0 αναφέρεται σε ένα σύνολο νέων δικτυακών υπηρεσιών, οι οποίες επιτρέπουν στους χρήστες να συνεργάζονται και να ανταλλάζουν δεδομένα online, με πιο αποδοτικό τρόπο σε σχέση με αυτόν που προσέφεραν οι παλιότερες υπηρεσίες. Η ειδοποιός διαφορά είναι ότι οι νέες υπηρεσίες παρέχουν στο χρήστη μια εμπειρία που πλησιάζει περισσότερο σε αυτή που έχει όταν εργάζεται στον προσωπικό του υπολογιστή. Με άλλα λόγια, οι εφαρμογές του Web 2.0 μοιάζουν με τις αυτοτελείς εφαρμογές υπολογιστών (stand-alone desktop applications), ενώ οι νέοι δικτυακοί τόποι είναι κατά κανόνα δυναμικοί και περισσότερο αλληλεπιδραστικοί, διαφέροντας από το στατικό κλασσικό Web. Επιπλέον, το Web 2.0 είναι συμβατό με οποιοδήποτε λειτουργικό σύστημα χρησιμοποιεί ο εκάστοτε χρήστης, καθώς ένας οποιοσδήποτε web browser αρκεί για να του δώσει τη δυνατότητα να συμμετέχει στο νέο, πιο ζωντανό και διαδραστικό Web. Αυτό έχει σαν αποτέλεσμα, το Web 2.0 να είναι εκτός από πλούσιο και ελαφρύ, από τη στιγμή που πολλές από τις εφαρμογές του έχουν σχεδιαστεί για να τρέχουν γρήγορα, χωρίς να καταχρώνται τους πόρους του συστήματος. Τέλος, το λογισμικό και το υλικό δεν απασχολούν πλέον τους 12

21 Περί Web προγραμματιστές στον ίδιο βαθμό με το παρελθόν, αφού το ενδιαφέρον τους επικεντρώνεται σε θέματα όπως το περιεχόμενο, η διαμόρφωση και η αξιοποίησή του Ορισμός Ο τελευταίος ορισμός του Web 2.0, σύμφωνα με τον Tim O'Reilly είναι: Το Web 2.0 είναι η εταιρική επανάσταση στη βιομηχανία των υπολογιστών που προκαλείται από τη μετεξέλιξη στο Web σαν πλατφόρμα (Web as a Platform) και από την απόπειρα να καταλάβουμε τους κανόνες της επιτυχίας σε αυτήν τη νέα πλατφόρμα. Βασικός κανόνας είναι ο εξής: Ανάπτυξη εφαρμογών που επωφελούνται από τις επιδράσεις της δικτύωσης και καλυτερεύουν όσο περισσότερο τις χρησιμοποιούν οι άνθρωποι. Αν και ο όρος Web 2.0 δίνει την αίσθηση ότι αποτελεί μία νέα έκδοση του Παγκόσμιου Ιστού, ουσιαστικά δεν πρόκειται για κάποιο καινούργιο πρωτόκολλό του, αλλά για αλλαγές στον τρόπο που χρησιμοποιούνται ήδη υπάρχουσες τεχνολογίες και στον τρόπο που οι σχεδιαστές πληροφοριακών συστημάτων και οι χρήστες χρησιμοποιούν το διαδίκτυο. Η κυρίαρχη τάση είναι να χρησιμοποιείται ως το μέσο (πλατφόρμα) πάνω στο οποίο θα τρέχουν εφαρμογές και υπηρεσίες, πολλές από τις οποίες μέχρι τώρα έτρεχαν τοπικά στους οικιακούς υπολογιστές. Το Web 2.0 είναι το Web ως πλατφόρμα, που εκτείνεται σε όλες τις συνδεδεμένες συσκευές, ενώ οι εφαρμογές του μεγιστοποιούν τα εγγενή πλεονεκτήματα της εν λόγω πλατφόρμας: παραγωγή λογισμικού ως υπηρεσία (Software as a Service - SaaS), συνεχής ενημέρωση που γίνεται καλύτερη όσο περισσότεροι τη χρησιμοποιούν, χρησιμοποίηση δεδομένων από πολλαπλές πηγές συμπεριλαμβανομένων και των μεμονωμένων χρηστών, παροχή υπηρεσιών δεδομένων σε μορφή που επιτρέπει τη χρήση από άλλους, καθώς και δημιουργία μιας αρχιτεκτονικής της συμμετοχής, πάνω και πέρα από την μεταφορά μιας ιστοσελίδας προκειμένου να παραδώσει πλούσιες εμπειρίες στους χρήστες (Εικόνα 2.2). 13

22 Περί Web Εικόνα 2.2: Σχεδιαστική Απεικόνιση του Web 2.0 Από τη στιγμή που το Web 2.0 ξεπερνά τα όρια της περιορισμένης πλατφόρμας ενός υπολογιστή, ο χρήστης θα μπορεί να δρα στον Παγκόσμιο Ιστό όπως δρούσε μέχρι τώρα στον υπολογιστή του. Οι πιο ειδικοί μιλούν για ένα νέο τρόπο σχεδίασης των ιστοσελίδων ο οποίος θα βασίζεται στην αλληλεπίδραση με το χρήστη, καθώς θα του επιτρέπει να αλλάξει τόσο το περιβάλλον της σελίδας όσο και να παρέμβει στο περιεχόμενό της. Συνοπτικά, όπως προκύπτει και από τα παραπάνω, τα κύρια χαρακτηριστικά του Web 2.0 είναι: Ο Παγκόσμιος Ιστός και όλες οι συσκευές που είναι συνδεδεμένες σε αυτόν, αποτελούν μια παγκόσμια πλατφόρμα επαναχρησιμοποιήσιμων υπηρεσιών και δεδομένων, τα οποία προέρχονται κυρίως από τους ίδιους τους χρήστες και στις περισσότερες περιπτώσεις διακινούνται ελεύθερα. 14

23 Περί Web Αρκεί ένας browser, ώστε να χρησιμοποιείται σαν απλή διεπαφή του χρήστη με αυτήν την πλατφόρμα, η οποία λειτουργεί ανεξαρτήτως συσκευής πρόσβασης (Η/Υ, PDA, κινητό τηλέφωνο) και λειτουργικού συστήματος. Μόνη προϋπόθεση είναι η ύπαρξη σύνδεσης στο διαδίκτυο. Λογισμικό, περιεχόμενο και εφαρμογές παρέχονται στην πλειοψηφία τους ελεύθερα ή σαν ανοιχτού κώδικα (open source). Γίνεται χρήση κυρίως ελαφριάς τεχνολογίας σε ότι αφορά τα πρωτόκολλα, τις γλώσσες προγραμματισμού και τις διεπαφές, ενώ διαπιστώνεται και μια τάση για απλότητα στον προγραμματιστικό σχεδιασμό τους. Παρέχονται πλούσιες και διαδραστικές διεπαφές χρήστη (Rich Internet ApplicationsRIA), δυναμικό περιεχόμενο και ιστοσελίδες που ανανεώνουν μόνο όποιο περιεχόμενό τους αλλάζει με χρήση της τεχνικής AJAX. Υπάρχει συνεχής και άμεση ανανέωση των δεδομένων και του λογισμικού. Προωθείται ο δημοκρατικός χαρακτήρας του διαδικτύου, με τους χρήστες να έχουν τον πρωταγωνιστικό ρόλο. Υιοθετείται η τάση για αποκέντρωση των δεδομένων, των υπηρεσιών και των προτύπων. Δίνεται η δυνατότητα κατηγοριοποίησης του περιεχομένου από το χρήστη με σημασιακές έννοιες για ευκολότερη αναζήτηση της πληροφορίας. Δίνεται η δυνατότητα για ανοιχτή επικοινωνία, ανάδραση, διάχυση πληροφοριών, άμεση συγκέντρωση και εκμετάλλευση της γνώσης των χρηστών για διάφορα 15

24 Περί Web ζητήματα. Διευκολύνεται η αμφίδρομη επικοινωνία του χρήστη με επιχειρήσεις ή οργανισμούς, γεγονός που μπορεί να έχει σαν αποτέλεσμα την επίδρασή του στην υιοθέτηση κατευθύνσεων και στη λήψη συγκεκριμένων αποφάσεων Αντιρρήσεις για τον όρο Web 2.0 Ενώ το Web 2.0 αντιμετωπίζεται από πολλούς ως μία από τις πιο ελπιδοφόρες προόδους που έχουν παρουσιαστεί στον Παγκόσμιο Ιστό, δεν παύει να υπάρχει μεγάλη σύγχυση γύρω από αυτό. Πολλοί εμπειρογνώμονες του Web 2.0 είναι μπερδεμένοι σχετικά με τη φύση αυτής της νέας γενιάς του Web και οι απόψεις διίστανται όσον αφορά τον ακριβή ορισμό της. Πολλά άτομα θεωρούν ότι το Web 2.0 δεν είναι διαφορετικό από το κλασσικό Web, αλλά είναι η θεώρηση των πραγμάτων από μία καθαρά τεχνολογική σκοπιά, όπως υποστηρίζει και ο πατέρας του Παγκόσμιου Ιστού Tim Berners-Lee σε μια συνέντευξη του επιχειρηματολογώντας πως το Web 2.0 δεν είναι κάτι νέο καθώς το Web αποτελούσε πάντα ένα μέσο διασύνδεσης των ανθρώπων, καθώς και ότι δεν περιέχει τεχνολογικά τίποτα νέο ή επαναστατικό, αφού στηρίζεται στην τεχνολογία του Web 1.0. Ο διαδικτυακός κριτικός, Paul Graham, τονίζει επίσης ότι: Η προοπτική του Web 2.0 αναφέρεται στον καλύτερο τρόπο χρήσης του Web, μέσω πραγματικής σύνδεσης μεταξύ των χρηστών και υψηλότερων επιπέδων αλληλεπίδρασης, και όχι στην τεχνολογική εξέλιξη του Παγκόσμιου Ιστού. Την άποψη ότι δεν υφίσταται η έννοια Web 2.0 ενισχύουν ακόμη περισσότερο κάποιοι οι οποίοι πιστεύουν ότι ο όρος ήταν εργαλείο του μάρκετινγκ, όπως ο Russell Shaw που υποστηρίζει πως ο όρος Web 2.0 δεν ήταν παρά ένα σλόγκαν του μάρκετινγκ, ο οποίος είναι πολύ ευρύς, ενώ τα επιμέρους στοιχεία του Web 2.0 που όντως υπάρχουν, δεν μπορούν να 16

25 Περί Web ομαδοποιηθούν μέσα σε έναν όρο. Την άποψη αυτή συμμερίζεται και ο Jay Fienberg, ο οποίος γράφει ότι: Πρόκειται για ένα κόλπο του μάρκετινγκ, εφόσον πολλές επιχειρήσεις έχουν υιοθετήσει τον όρο ώστε να θεωρηθούν καινοτόμες Τεχνολογίες του Web 2.0 Κάποιες από τις σημαντικότερες τεχνολογίες που χρησιμοποιούνται από το Web 2.0 και το διαφοροποιούν ως προς τον τρόπο λειτουργίας και παρουσίασης των ιστοσελίδων σε σχέση με το παραδοσιακό Web μπορούν να θεωρηθούν: Οι πλούσιες και διαδραστικές διεπαφές χρηστών που χρησιμοποιούν τεχνολογία Javascript, Flash κλπ, καθώς και την τεχνική AJAX, που αντιπροσωπεύει την τάση του Web 2.0 για όσο το δυνατόν καλύτερη εκμετάλλευση του δικτύου, από τη στιγμή που αντί να φορτώνεται ολόκληρη η σελίδα, ανανεώνονται μόνο τα δεδομένα που αλλάζουν όσο ο χρήστης βρίσκεται ή επανέρχεται σε αυτή. Η εκτεταμένη χρήση CSS (Cascading Style Sheets) για να διαχωρίζονται τα δεδομένα καθαρής πληροφορίας από τα δεδομένα μορφοποίησης σε μια ιστοσελίδα. Αυτό, πέρα από την οικονομία στο εύρος ζώνης του δικτύου, προσφέρει και ευελιξία στον τρόπο παρουσίασης των δεδομένων, αφού ο χρήστης βλέπει τα δεδομένα ανάλογα με το CSS που ο ίδιος έχει, καθώς τα ίδια δεδομένα ανάλογα με το CSS μπορούν να παρουσιαστούν διαφορετικά σε μια οθόνη υπολογιστή, από ότι κατευθείαν σε έναν εκτυπωτή, σε μορφή ανάγνωσης για τυφλούς ή και να μετατραπούν σε φωνή με χρήση κατάλληλου λογισμικού. Η χρήση σημασιακών δεδομένων και microformats για να περιγράφεται η σημασία των δεδομένων που περιέχουν οι ιστοσελίδες. Έτσι, αυτά κατηγοριοποιούνται και η 17

26 Περί Web αναζήτησή τους γίνεται ευκολότερη και πιο αποδοτική. Η χρήση RSS ή Atom feeds με τα πλεονεκτήματα που αυτά προσφέρουν στην άμεση ενημέρωση των τελικών χρηστών. Η εκτεταμένη χρήση ανοικτού λογισμικού στις εφαρμογές του Web 2.0, όπως για παράδειγμα η χρήση Linux για λειτουργικό σύστημα, Apache για Web server, MySQL για βάση δεδομένων και PHP, Pearl, ή Python, για γλώσσες ανάπτυξης εφαρμογών. Η υιοθέτηση των ελαφρών διαδικτυακών πρωτοκόλλων REST και SOAP που χρησιμοποιούν απλές εντολές ΗΤΤΡ (get, post, put) για ανάκτηση δεδομένων. Η υποστήριξη αρχιτεκτονικών SOA (Service Oriented Architecture) που επιτρέπουν το διαμοιρασμό και την επαναχρησιμοποίηση υπηρεσιών-εφαρμογών από διαφορετικά προγράμματα λογισμικού, καθώς και SaaS (Software as a Service) όπου οι εφαρμογές είναι εγκατεστημένες σε κάποιον κεντρικό διαδικτυακό server και οι χρήστες τις χρησιμοποιούν μέσω ενός browser ανεξαρτήτως υπολογιστικού υποβάθρου, τόπου και χρονικής στιγμής. Σε κάθε περίπτωση, και ενώ η κοινότητα της τεχνολογίας και του Παγκόσμιου Ιστού συνεχίζει να διχάζεται για το αν το Web 2.0 είναι κάτι νέο τεχνολογικά ή είναι απλά ένα άλλο μέσο του μάρκετινγκ, σε γενικές γραμμές ο όρος έχει πλέον καταστεί ως η κοινά παραδεκτή έννοια μιας νέας γενιάς διαδικτυακών υπηρεσιών και εφαρμογών, οι οποίες προσφέρουν μεγάλη ώθηση στις συνεργατικές συνθήκες στον Παγκόσμιο Ιστό, αλλά όμως δεν αποτελούν μια τεχνολογική πλατφόρμα που μπορεί να οδηγήσει τον Παγκόσμιο Ιστό στο μέλλον που του αρμόζει. 18

27 Περί Web 2.3 Web 3.0 Όπως προκύπτει από τις προηγούμενες ενότητες, το Semantic Web και το Web 2.0 είναι οι δυο κυριότερες τάσεις στην ανάπτυξη εφαρμογών Παγκόσμιου Ιστού κατά τα τελευταία χρόνια, αλλά παρουσιάζονται ως εντελώς ανταγωνιστικές σε ό,τι αφορά την τεχνολογική υποδομή και την προσέγγιση των αντίστοιχων εφαρμογών τους. Αποτελεί όμως ισχυρή μας πεποίθηση πως το Semantic Web και το Web 2.0 δεν αποτελούν στην πραγματικότητα δυο ανταγωνιστικά οράματα για τις εφαρμογές Παγκόσμιου Ιστού, αλλά μπορούν να λειτουργήσουν από κοινού και συμπληρωματικά, προκειμένου να παράσχουν περισσότερες λύσεις στο σχεδιασμό και την ανάπτυξή τους. Πράγματι, μπορούν να αλληλοσυμπληρωθούν και να αλληλοβοηθηθούν προκειμένου να ξεπεράσουν τα μειονεκτήματά τους, δίνοντας τη δυνατότητα στις επικείμενες εφαρμογές Παγκόσμιου Ιστού να συνδυάσουν τις αρχές του Web 2.0, ιδιαίτερα αυτές που επικεντρώνονται στην ευχρηστία, την ευελιξία και τη συνεργατικότητα, με το πλούσιο και ισχυρό τεχνολογικό υπόβαθρο του Semantic Web, το οποίο διευκολύνει το διαμοιρασμό πληροφοριών και δεδομένων μεταξύ των διάφορων εφαρμογών Παγκόσμιου Ιστού. Συνεπώς, οι αρχές του Semantic Web και του Web 2.0 μπορούν να συνδυαστούν σα συμπληρωματικές προσεγγίσεις, οδηγώντας σε πιο ισχυρές, πιο λειτουργικές και πιο αποδοτικές εφαρμογές Παγκόσμιου Ιστού. Τέτοιου είδους εφαρμογές μπορούν να θεωρηθούν ως μέρος του Παγκόσμιου Ιστού επόμενης γενιάς, ο οποίος αρχίζει να γίνεται γνωστός υπό τον όρο Web 3.0 (Lassila & Hendler, 2007; Hendler, 2008). Σε αυτό το πλαίσιο, έχουν ήδη υπάρξει αρκετές αρχικές προσεγγίσεις, από την ανάπτυξη εργαλείων AJAX για το Semantic Web (Oren, 2006) και τη μελέτη του συνδυασμού οντολογιών και κοινωνικών δικτύων (social networks) (Mika, 2005), έως την πρόταση εξελιγμένων υβριδικών εφαρμογών που συνδυάζουν και τα δυο αυτά είδη τεχνολογιών (Ankolekar et al., 2007; Leblanc & Abel, 2009). 19

28 Περί Web Όλα τα παραπάνω μπορούν να αποτελέσουν πολύ χρήσιμες λύσεις για κάθε εφαρμογή Παγκόσμιου Ιστού που δίνει έμφαση στα δεδομένα, καθώς και οπουδήποτε υπάρχει ανάγκη για ένα σύστημα γνώσης (knowledge system). Πόσο μάλλον για τα συστήματα γνώσης επόμενης γενιάς, τα οποία, πέραν της Τεχνητής Νοημοσύνης στον Παγκόσμιο Ιστό (Web AI), προσπαθούν να επωφεληθούν και από τις τάσεις του Web 2.0 και τη συνεργατική ανάπτυξη (collaborative development), προκειμένου να καταφέρουν να δομήσουν συστήματα γνώσης πραγματικά μεγάλης κλίμακας, ακόμα και διαδικτυακής τάξης μεγέθους (Tenenbaum, 2006). 20

29 3. Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 Ο όρος Αρχιτεκτονική στον Παγκόσμιο Ιστό συχνά συγχέεται με το σχεδιασμό και την ανάπτυξη των εφαρμογών Παγκόσμιου Ιστού, όμως στην πραγματικότητα αναφέρεται στην υποδομή υποστήριξης της λειτουργίας των εφαρμογών και των πληροφοριακών συστημάτων Παγκόσμιου Ιστού. Χρησιμοποιείται για να περιγράψει το μοντέλο λειτουργίας, επικοινωνίας και διασύνδεσης των διάφορων συστατικών στοιχείων μιας εφαρμογής Παγκόσμιου Ιστού, και κατά συνέπεια επηρεάζει όλα τα στάδια του κύκλου ζωής των εφαρμογών Παγκόσμιου Ιστού. 3.1 Αρχιτεκτονικές Υποστήριξης Εφαρμογών Παγκόσμιου Ιστού Παράλληλα με την ανάπτυξη των εφαρμογών Παγκόσμιου Ιστού άρχισαν να εμφανίζονται στο προσκήνιο διάφορες προτάσεις για τις κατάλληλες αρχιτεκτονικές υποστήριξής τους. Οι περισσότερες βασίζονταν σε αντίστοιχες λύσεις του Software Engineering, όμως με την πάροδο του χρόνου απέκτησαν τα δικά τους χαρακτηριστικά και κατέληξαν να αποτελούν αντιπροσωπευτικά δείγματα του χώρου. Οι δημοφιλέστερες αρχιτεκτονικές που χρησιμοποιούνται σήμερα για την υποστήριξη των εφαρμογών Παγκόσμιου Ιστού είναι οι Client-Server, Model-View-Controller (MVC), 3tier και XRX Client-Server Αρχιτεκτονική Αποτελεί μια δομή κατανεμημένων εφαρμογών, όπου οι διεργασίες και ο φόρτος κατανέμονται ανάμεσα σε παρόχους υπηρεσιών (servers) και χρήστες υπηρεσιών (clients) 21

30 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 (Reese, 2000). Αποτελείται στην ουσία από δυο πλευρές που αλληλεπιδρούν με μια λογική αιτήματος-απάντησης, καθώς ο client κάνει αίτηση για μια ενέργεια ή μια υπηρεσία από το server και αναμένει τη σχετική απάντησή του. Η αρχιτεκτονική αυτή απεικονίζει τη σχέση μεταξύ δυο υπολογιστικών προγραμμάτων, στην οποία το ένα πρόγραμμα, το client πρόγραμμα, ζητάει υπηρεσίες από το άλλο πρόγραμμα, το server πρόγραμμα. Βασικές δικτυακές λειτουργίες όπως η ανταλλαγή δεδομένων, η πρόσβαση στο Web και η πρόσβαση σε βάσεις δεδομένων, στηρίζονται στο client-server μοντέλο. Το ίδιο ισχύει και για τα κύρια πρωτόκολλα εφαρμογών στο Internet, δηλαδή το HTTP, το SMTP, το Telnet, το DNS κλπ. Παρόλο που σχετική ιδέα μπορεί να εφαρμοστεί με πολλούς διαφορετικούς τρόπους σε πολλές διαφορετικές εφαρμογές, η αρχιτεκτονική αυτή παραμένει (στη θεμελιώδη της λειτουργία) η ίδια. Αυτός ο τύπος αρχιτεκτονικής αναφέρεται μερικές φορές ως two-tier, θεωρώντας πως ο client δρα ως το ένα tier και η εφαρμογή σε συνδυασμό με το server δρα ως το άλλο tier. Στη σημερινή εποχή ως client θεωρούνται οι Web browsers. Μια απλή απεικόνιση της client-server αρχιτεκτονικής φαίνεται στην Εικόνα 3.1: Εικόνα 3.1: Η Client-Server Αρχιτεκτονική 22

31 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 Υλοποίηση Υπάρχουν διαφορετικά λειτουργικά μοντέλα στην client-server αρχιτεκτονική ανάλογα με την εφαρμογή που καλείται να υλοποιηθεί. Αρχικά, υπάρχει το μοντέλο που εφαρμόζεται για στατικές HTML σελίδες. Ο client κάνει ένα αίτημα για μια HTML σελίδα δίνοντας στο browser το URL μιας σελίδας που βρίσκεται σε κάποιο server. Ο browser τοποθετεί το URL μέσα σε μια HTTP αίτηση και τη στέλνει στο server. Ο server εντοπίζει τη σελίδα, τη στέλνει στον client και κλείνει τη σύνδεση με τον client. Ένα δεύτερο μοντέλο για την client-server αρχιτεκτονική είναι αυτό που υπάρχει στις CGI εφαρμογές Παγκόσμιου Ιστού. Στις εφαρμογές αυτές ο server δε στέλνει απλά μια σελίδα στον client αλλά κάθε φορά που δέχεται μια αίτηση (ένα URL μαζί με δεδομένα μέσω μιας μεθόδου POST) την αναλύει, την επεξεργάζεται και στέλνει πίσω μια απάντηση, καταναλώνοντας την αντίστοιχη υπολογιστική ισχύ. Παράδειγμα χρήσης των CGI εφαρμογών αποτελούν σελίδες που κάνουν αναζήτηση σε εφαρμογές Παγκόσμιου Ιστού. Ο server δέχεται μια λέξη προς αναζήτηση, εντοπίζει τη CGI εφαρμογή, της μεταφέρει τα δεδομένα, αυτή τα επεξεργάζεται και στέλνει τα αποτελέσματα στον client σε μορφή HTML, καθώς η CGI εφαρμογή παράγει δυναμικές HTML σελίδες, των οποίων το περιεχόμενο εξαρτάται από τα ερωτήματα του client στη CGI εφαρμογή. Ένα άλλο μοντέλο της αρχιτεκτονικής αυτής εφαρμόζεται σε server-side τεχνολογίες, όπου η απάντηση στον client παράγεται δυναμικά. Οι πιο διαδεδομένες server-side τεχνολογίες που υπάρχουν σήμερα είναι οι Hypertext Preprocessor (PHP), Java Server Pages (JSP), Active Server Pages (ASP), Server Side Includes (SSI). Σε αυτές τις τεχνολογίες ο προγραμματιστής πρέπει να εισάγει σχετικό κώδικα μέσα σε server-side σελίδες. Αυτός ο server-side κώδικας μεταφράζεται και εκτελείται στο server παράγοντας ένα αποτέλεσμα που αποστέλλεται σαν μια HTML σελίδα στον client, ενώ ο αρχικός κώδικας δεν εμφανίζεται στην πλευρά του client. Για παράδειγμα όταν ένας client κάνει αίτηση για μια PHP σελίδα, αυτή μεταφέρεται σε έναν PHP μεταφραστή, ο οποίος εκτελεί τον αντίστοιχο κώδικα και παράγει μια δυναμική HTML σελίδα. Ο client δε γνωρίζει τι λειτουργίες εκτελεί ο server, 23

32 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 απλά παραλαμβάνει δυναμικές HTML σελίδες, τις οποίες εμφανίζει κατάλληλα μορφοποιημένες στον υπολογιστή του τελικού χρήστη. Πλεονεκτήματα Στις περισσότερες περιπτώσεις, μια client-server αρχιτεκτονική επιτρέπει στα διάφορα μέρη ενός υπολογιστικού συστήματος να επιτελούν τους ρόλους τους κατανεμημένα, επικοινωνώντας μόνο μέσω δικτύου. Αυτό δημιουργεί ένα επιπλέον πλεονέκτημα στην αρχιτεκτονική: μεγαλύτερη ευκολία στη συντήρηση. Για παράδειγμα, είναι δυνατό να αντικατασταθεί, να διορθωθεί, να αναβαθμιστεί, ή ακόμα και να τοποθετηθεί κάπου αλλού ο server, ενώ οι clients δε γνωρίζουν ούτε επηρεάζονται από αυτήν την αλλαγή. Όλα τα δεδομένα σε μια client-server αρχιτεκτονική αποθηκεύονται στους servers, οι οποίοι παρέχουν μεγαλύτερη ασφάλεια σε σχέση με τους απλούς clients. Οι servers μπορούν να ελέγχουν την πρόσβαση και τη διάθεση των πόρων του δικτύου, για να διασφαλίσουν ότι μόνο οι clients με τα κατάλληλα δικαιώματα πρόσβασης θα αποκτήσουν πρόσβαση στα δεδομένα ή θα μπορέσουν να τα τροποποιήσουν. Από τη στιγμή που τα δεδομένα αποθηκεύονται κάπου κεντρικοποιημένα, η ενημέρωσή (update) τους είναι πολύ πιο εύκολα διαχειρίσιμη. Επίσης, όταν ένας client εισάγει νέα δεδομένα, όλοι οι υπόλοιποι clients του δικτύου μπορούν να τα έχουν στη διάθεσή τους, την ίδια σχεδόν στιγμή. Η client-server αρχιτεκτονική μπορεί να υποστηρίξει πολλαπλούς διαφορετικούς clients με διαφορετικές δυνατότητες για τον καθένα. Τέλος, είναι διαθέσιμες και χρησιμοποιούνται σήμερα πολλές ώριμες client-server τεχνολογίες που σχεδιάστηκαν για να διασφαλίζουν την ασφάλεια της εφαρμογής, τη φιλικότητα της διεπαφής χρήστη (user interface) και την ευκολία χρήσης. Μειονεκτήματα Η ύπαρξη μεγάλου όγκου δεδομένων πάνω στο δίκτυο αποτελούσε πρόβλημα από την αρχή της υιοθέτησης της client-server αρχιτεκτονικής. Όσο ο αριθμός των ταυτόχρονων client αιτήσεων σε ένα server αυξάνει, τόσο ο τελευταίος μπορεί να 24

33 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 υπερφορτωθεί σημαντικά. Ένα ακόμα πρόβλημα αποτελεί το γεγονός ότι η client-server αρχιτεκτονική δεν έχει πολύ καλή ευρωστία (robustness). Στο πλαίσιο της λειτουργίας μιας εφαρμογής, αν ο server καταρρεύσει (fail), οι αιτήσεις των clients δε θα μπορέσουν να λάβουν απαντήσεις (δηλαδή να εκπληρωθούν) Model-View-Controller Αρχιτεκτονική Σκοπός των περισσότερων υπολογιστικών συστημάτων είναι να ανακτούν δεδομένα από μια πηγή και να τα εμφανίζουν στο χρήστη. Όταν ο χρήστη εισάγει δεδομένα στο σύστημα, αυτό ενημερώνει την πηγή με τα νέα δεδομένα. Αφού, η ανταλλαγή πληροφορίας στο σύστημα γίνεται ανάμεσα στην πηγή δεδομένων και στη διεπαφή χρήστη, το λογικό θα ήταν να συνδεθούν τα δυο αυτά τμήματα, ώστε να μειωθεί το μέγεθος του κώδικα του συστήματος αλλά και για να αυξηθεί η απόδοση της εφαρμογής. Βέβαια, αυτή η προσέγγιση παρουσιάζει κάποια προβλήματα στην πράξη. Ένα πρόβλημα είναι ότι η διεπαφή χρήστη έχει την τάση να αλλάζει περισσότερες φορές σε σχέση με το σύστημα αποθήκευσης δεδομένων. Ένα άλλο πρόβλημα της σύνδεσης της διεπαφής χρήστη με την πηγή δεδομένων είναι ότι οι εφαρμογές έχουν την τάση να ενσωματώνουν τη λογική του συστήματος (application/business logic), και ειδικά στις εφαρμογές Παγκόσμιου Ιστού, η διεπαφή χρήστη αλλάζει πιο συχνά από τη λογική. Για παράδειγμα, μπορεί να προστεθούν νέες σελίδες στη διεπαφή ή να τροποποιηθούν ήδη υπάρχοντα στυλ απεικόνισης μιας εφαρμογής. Αν η διεπαφή χρήστη και η λογική είναι συνδεδεμένες σε ένα ενιαίο τμήμα/αντικείμενο της εφαρμογής πρέπει, κάθε φορά που απαιτείται μια αλλαγή στη διεπαφή χρήστη, να τροποποιείται και όλο το τμήμα που περιέχει τη λογική. Αυτό είναι πιθανό να εισάγει λάθη στην εφαρμογή και απαιτεί κάθε φορά επανέλεγχο όλου του τμήματος της λογικής μετά από κάθε, έστω και μικρή, αλλαγή της διεπαφής χρήστη. H Model-View-Controller (MVC) (Reenskaug, 1979; Reenskaug, 2003) αρχιτεκτονική λύνει το παραπάνω πρόβλημα διαχωρίζοντας την απεικόνιση των δεδομένων, τις λειτουργίες 25

34 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 της εφαρμογής που βασίζονται στην είσοδο δεδομένων από το χρήστη και τον τρόπο αποθήκευσης των δεδομένων σε τρία διακριτά τμήματα/αντικείμενα. Πιο συγκεκριμένα, το αντικείμενο Controller μεταφράζει την είσοδο που δέχεται από το χρήστη (συνήθως κλικ ποντικιού ή πληκτρολόγηση), και ενημερώνει το αντικείμενο Model ή/και το αντικείμενο View για να τροποποιηθούν κατάλληλα. Το View διαχειρίζεται την απεικόνιση των δεδομένων, ενώ το Model κρατά τη δομή των δεδομένων, απαντά στα αιτήματα για ενημέρωση των δεδομένων που δέχεται από το Controller, ενώ δέχεται και αιτήματα για ανάκτηση δεδομένων, συνήθως από το View. Η Εικόνα 3.2 απεικονίζει τη σχέση ανάμεσα σε αυτά τα τρία τμήματα/αντικείμενα: Εικόνα 3.2: Η MVC Αρχιτεκτονική Πρέπει να σημειωθεί ότι τα αντικείμενα View και Controller εξαρτώνται από το Model, ενώ το Model δεν εξαρτάται ούτε από το View ούτε από το Controller. Αυτό είναι ένα από τα βασικά πλεονεκτήματα όταν διαχωρίζονται οι κύριες λειτουργίες μιας εφαρμογής. Ο διαχωρισμός αυτός επιτρέπει στο Model να αναπτυχθεί και να ελεγχθεί ανεξάρτητα από τα υπόλοιπα, χωρίς δηλαδή να είναι απαραίτητη η ανάπτυξη λειτουργίας που θα απεικονίζει τα δεδομένα (View). Στις εφαρμογές Παγκόσμιου Ιστού, ο διαχωρισμός ανάμεσα στο View (browser) και στο Controller (τα server-side τμήματα που χειρίζονται τα HTTP αιτήματα) είναι συνήθως πολύ καλά ορισμένος, με αποτέλεσμα η MVC αρχιτεκτονική να είναι πολύ δημοφιλής σε εφαρμογές που απαιτείται διαχωρισμός της διεπαφής χρήστη από τη λογική της εφαρμογής. Βέβαια, η συχνή χρήση της αρχιτεκτονικής έχει προκαλέσει κάποιες 26

35 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 παρανοήσεις ως προς τον ακριβή διαχωρισμό και τις έννοιες των τριών τμημάτων/αντικειμένων. Υλοποίηση Για την MVC υπάρχουν δυο διαφοροποιήσεις (Burbeck, 1992): το passive model και το active model, που μπορούν να χρησιμοποιηθούν ανάλογα με τις απαιτήσεις της εκάστοτε εφαρμογής Παγκόσμιου Ιστού. Το passive model χρησιμοποιείται όταν ένα Controller χειρίζεται το Model αποκλειστικά. Το Controller τροποποιεί το Model και μετά ενημερώνει το View ότι το Model έχει τροποποιηθεί, οπότε πρέπει ανανεωθεί (refresh) και το View (Εικόνα 3.3). Εικόνα 3.3: MVC Passive Model Το Model σε αυτήν την εκδοχή είναι τελείως ανεξάρτητο από το View και το Controller, το οποίο σημαίνει ότι δεν υπάρχει τρόπος το Model να ενημερώσει τα υπόλοιπα τμήματα/αντικείμενα για αλλαγές που μπορεί να συμβούν στο ίδιο, καθώς δεν υπάρχει κάποιος απλός τρόπος ώστε ένας browser να λαμβάνει ασύγχρονες ενημερώσεις (asynchronous updates) από το server. O browser εμφανίζει στην οθόνη το View και 27

36 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 αποκρίνεται στην είσοδο του χρήστη, αλλά δε μπορεί να ανιχνεύσει αλλαγές που πιθανόν συμβαίνουν στα δεδομένα στο server. Μόνο όταν ο χρήστης κάνει ένα αίτημα (request) για ανανέωση δεδομένων, διερευνάται αν ο server έχει υποστεί αλλαγές. Το active model αυτής της αρχιτεκτονικής χρησιμοποιείται όταν το Model αλλάζει την κατάστασή του χωρίς την ανάμιξη του Controller. Αυτό μπορεί να συμβεί όταν άλλες πηγές προκαλούν αλλαγές στα δεδομένα και αυτές οι αλλαγές πρέπει να απεικονιστούν στο View. Καθώς μόνο το Model μπορεί να αντιληφθεί τις αλλαγές στα δεδομένα όταν αυτές συμβούν, πρέπει το ίδιο να ειδοποιήσει το View για να ανανεωθούν τα δεδομένα στην οθόνη του χρήστη. Βέβαια, ένα από τα κύρια χαρακτηριστικά της MVC αρχιτεκτονικής είναι πως το Model θα πρέπει να είναι ανεξάρτητο από το View. Αν το Model έπρεπε να ειδοποιήσει το View για τις όποιες αλλαγές, τότε θα υπήρχε μεταξύ τους εξάρτηση, πράγμα που είναι επιθυμητό να αποφευχθεί. Σε αυτή την περίπτωση χρησιμοποιείται ένα επιπλέον τμήμα ή διεπαφή (interface), το Observer, το οποίο διατηρεί μια λίστα εξαρτώμενων αντικειμένων από ένα κύριο αντικείμενο, και ειδοποιεί τα περιεχόμενα στη λίστα αντικείμενα αυτόματα αν η κατάσταση του κύριου αντικειμένου αλλάξει, καλώντας μια από τις μεθόδους τους. Με αυτόν τον τρόπο εξαλείφεται η ανάγκη της αλληλεπίδρασης του Model με το View (Εικόνα 3.4). Εικόνα 3.4: MVC Active Model Κάθε View υλοποιεί ένα μηχανισμό Observer που αλληλεπιδρά με το Model και παρατηρεί αλλαγές. Όταν ένα Model δέχεται αλλαγές, τότε ενημερώνει τα κατάλληλα 28

37 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 Observer για τις αλλαγές. Με αυτή τη μέθοδο, το Model δε χρειάζεται πληροφορίες για το View ώστε να ενημερώσει τα Observer. Για την ακρίβεια, στις περιπτώσεις όπου το Controller πρέπει να ενημερωθεί για αλλαγές που έγιναν στο Model (για παράδειγμα, να ενεργοποιηθούν ή να απενεργοποιηθούν κάποιες επιλογές στο μενού της εφαρμογής), το Controller πρέπει να υλοποιήσει ένα Observer και να δεχθεί τις αλλαγές που έχουν γίνει στο Model. Στις περιπτώσεις όπου υπάρχουν περισσότερα από ένα View, μπορεί κάθε ένα από αυτά να παραμετροποιηθεί ώστε να δέχεται μόνο ορισμένου τύπου αλλαγές. Η Εικόνα 3.5 απεικονίζει πως το Observer ενημερώνει το View όταν το Model αλλάζει: Εικόνα 3.5: Η Λειτουργία του Observer στην MVC Ένα άλλο χαρακτηριστικό της Model-View-Controller αρχιτεκτονικής είναι πως η χρήση της αυξάνει σημαντικά τη δυνατότητα για έλεγχο (testing) της εφαρμογής. Ο έλεγχος των συστατικών μερών (components) μιας εφαρμογής γίνεται δύσκολος όταν αυτά διασυνδέονται μεταξύ τους, ειδικότερα όταν αυτή η διασύνδεση εμπλέκει και συστατικά διεπαφής χρήστη, καθώς τα τελευταία συχνά απαιτούν ένα σύνθετο μηχανισμό ελέγχου, ακόμα και για τον έλεγχο μιας απλής συνάρτησης. Ακόμα χειρότερα, όταν εμφανίζεται ένα λάθος είναι δύσκολο να απομονωθεί το πρόβλημα σε ένα συγκεκριμένο συστατικό. Αυτός είναι και ο λόγος που ο διαχωρισμός των τμημάτων/αντικειμένων είναι πολύ σημαντικός στο σχεδιασμό των αρχιτεκτονικών, και σε αυτό βοηθάει η MVC διαχωρίζοντας τις έννοιες της αποθήκευσης, 29

38 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 της εμφάνισης και της ενημέρωσης των δεδομένων σε τρία συστατικά στοιχεία που μπορούν να ελεγχθούν ανεξάρτητα. Πρέπει να σημειωθεί πως, εκτός από τα προβλήματα αλληλεξάρτησης ανάμεσα στα συστατικά στοιχεία μιας εφαρμογής, οι διεπαφές χρήστη είναι δύσκολο από τη φύση τους να ελεγχθούν. Η διαδικασία ελέγχου στις διεπαφές χρήστη απαιτεί χειροκίνητους (manual) και error-prone ελέγχους, ή ειδικά scripts ελέγχου που προσομοιώνουν τις κινήσεις των χρηστών, τα οποία απαιτούν πολύ χρόνο για να αναπτυχθούν και για να σταθεροποιηθούν. Σε κάθε περίπτωση, η MVC δεν εξαλείφει την ανάγκη για έλεγχο της διεπαφής χρήστη, αλλά ο διαχωρισμός του Model από το View τους επιτρέπει να ελεγχθούν ανεξάρτητα και να μειωθεί ο αριθμός των περιπτώσεων (test-cases) για τις οποίες πρέπει να ελεγχθεί η διεπαφή χρήστη. Πλεονεκτήματα Επειδή το View είναι διαχωρισμένο από το Model και δεν υπάρχει άμεση εξάρτηση μεταξύ τους, η διεπαφή χρήστη μπορεί να απεικονίζει πολλαπλά View των ίδιων δεδομένων την ίδια στιγμή. Για παράδειγμα, πολλαπλές σελίδες σε μια εφαρμογή Παγκόσμιου Ιστού μπορεί να χρησιμοποιούν τα ίδια Model. Ένα άλλο παράδειγμα είναι, μια εφαρμογή που επιτρέπει στο χρήστη να αλλάζει την εμφάνιση μιας σελίδας. Αυτές οι σελίδες απεικονίζουν τα ίδια δεδομένα μέσω ενός κοινού μοντέλου, αλλά το εμφανίζουν στην οθόνη με διαφορετικό τρόπο. Οι απαιτήσεις μιας διεπαφής χρήστη έχουν την τάση να αλλάζουν πιο συχνά από ότι η λογική της εφαρμογής. Οι χρήστες μπορεί να προτιμούν διαφορετικά χρώματα, μεγέθη, γραμματοσειρές, καθώς και να χρησιμοποιούν εναλλακτικές συσκευές απεικόνισης όπως κινητά ή PDA. Επειδή το Model δεν εξαρτάται από τα View, η προσθήκη νέων τύπων View στο σύστημα δεν επηρεάζει το Model. Η χρήση της MVC διευκολύνει σε μεγάλο βαθμό τις διαδικασίες ελέγχου της τελικής εφαρμογής, λόγω της εγγενούς ανεξαρτησίας των συστατικών μερών της. Μειονεκτήματα Επειδή υπάρχουν διακριτά τμήματα/αντικείμενα στην αρχιτεκτονική αυτή, αυξάνεται η πολυπλοκότητα της τελικής εφαρμογής. Η μη εξάρτηση του Model από το View δε 30

39 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 σημαίνει ότι οι προγραμματιστές πρέπει να αγνοήσουν τον τρόπο που έχουν αναπτυχθεί και λειτουργούν τα View. Για παράδειγμα, αν το Model υφίσταται συχνές αλλαγές μπορεί το View να κατακλυστεί από αιτήματα για ενημέρωση και καθώς κάποια View, όπως γραφικές απεικονίσεις, συνήθως απαιτούν κάποιο χρόνο για να εμφανιστούν, μπορεί να αργήσουν να δεχτούν κάποια αιτήματα ενημέρωσης από το Model. Οπότε είναι σημαντικό να λαμβάνεται υπόψη το View όταν αναπτύσσεται ο κώδικας tier Αρχιτεκτονική Στο Software Engineering, η 3-tier αρχιτεκτονική είναι μια client-server αρχιτεκτονική, στην οποία η απεικόνιση (presentation), η διαχείριση των δεδομένων (data management) και η επεξεργασία (processing) είναι διακριτές διαδικασίες (Eckerson, 1995). Για παράδειγμα, μια εφαρμογή η οποία χρησιμοποιεί μια ενδιάμεση βαθμίδα (tier) για να ικανοποιήσει αιτήματα για δεδομένα (data requests) ανάμεσα σε ένα χρήστη και μια βάση δεδομένων μπορεί να θεωρηθεί πως έχει σχεδιαστεί με βάση μια πολυεπίπεδη (multitier) αρχιτεκτονική. Σε ότι αφορά την ορολογία, συχνά ο όρος multitier αρχιτεκτονική αναφέρεται αποκλειστικά στη 3-tier αρχιτεκτονική, ενώ αντί για τον όρο tier χρησιμοποιείται συχνά ο όρος layer με την ίδια σημασία, παρότι υπάρχει μια σημαντική διαφορά μεταξύ τους. Ένα layer είναι ένας λογικά δομημένος μηχανισμός από στοιχεία που απαρτίζουν μια οντότητα λογισμικού (software solution), ενώ ένα tier είναι ένας φυσικά δομημένος μηχανισμός για την υποδομή του συστήματος. Σε κάθε περίπτωση, η 3-tier είναι μια client-server αρχιτεκτονική στην οποία η διεπαφή χρήστη, οι διεργασίες που αποτελούν τη λογική της εφαρμογής και η αποθήκη δεδομένων αναπτύσσονται και διατηρούνται σαν ανεξάρτητα τμήματα (modules), τις περισσότερες φορές σε διαφορετικές πλατφόρμες (Εικόνα 3.6). 31

40 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 Εικόνα 3.6: Η 3-tier Αρχιτεκτονική H 3-tier αρχιτεκτονική αποτελείται από τις ακόλουθες τρεις βαθμίδες (tiers): Presentation tier: αποτελεί την υψηλότερη βαθμίδα στην εφαρμογή. Από άποψη ευχρηστίας είναι η πιο σημαντική βαθμίδα της εφαρμογής επειδή είναι αυτή την οποία βλέπουν και χρησιμοποιούν οι χρήστες. Ακόμη και με καλά δομημένα τις άλλες βαθμίδες, αν η Presentation βαθμίδα δεν έχει σχεδιαστεί σωστά, θα δώσει στους χρήστες περιορισμένες δυνατότητες στο σύστημα. Application Logic tier: είναι διαχωρισμένη από την Presentation βαθμίδα και λειτουργεί ως διακριτό κομμάτι της εφαρμογής. Παρόλο που μια εφαρμογή Παγκόσμιου Ιστού θα μπορούσε να επικοινωνήσει άμεσα με τα δεδομένα της, προτείνεται να γίνεται η επικοινωνία μέσω της συγκεκριμένης βαθμίδας, με αποτέλεσμα να ανάγεται σε ζωτικής σημασίας βαθμίδα, καθώς κάνει έλεγχο στα δεδομένα που καταχωρούνται πριν καλέσει μια μέθοδο από το Data tier. Αυτό 32

41 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 διασφαλίζει ότι τα δεδομένα που θα εισαχθούν στο σύστημα είναι σωστά, ενώ μπορεί πολύ συχνά να διασφαλίσει ότι και η έξοδος του συστήματος είναι σωστή. Αυτή η επαλήθευση (validation) στα δεδομένα είναι μέρος της λογικής της εφαρμογής, δηλαδή κάποιων κανόνων που εφαρμόζονται σε υπολογισμούς ή ενέργειες που γίνονται στη συγκεκριμένη βαθμίδα, για να παρθούν αποφάσεις για τα δεδομένα. Επιπλέον, η ενσωμάτωση της λογικής της εφαρμογής στη συγκεκριμένη βαθμίδα, της δίνει την δυνατότητα να είναι επαναχρησιμοποιήσιμη μέσα στην εφαρμογή, γεγονός το οποίο είναι ιδιαίτερα χρήσιμο σε πολλές εφαρμογές που ξεκινούν με μικρό μέγεθος και στη συνέχεια αναπτύσσονται σε λειτουργικότητα. Η μεσαία βαθμίδα μπορεί να είναι η ίδια πολυεπίπεδη (multi-tier), οπότε στην περίπτωση αυτή η αρχιτεκτονική καλείται n-tier. Data tier: συνήθως αποτελείται από database servers, στους οποίους αποθηκεύονται τα δεδομένα της εφαρμογής, ανεξάρτητα από τους application servers και τη λογική της εφαρμογής. Καθώς τα δεδομένα είναι το βασικό στοιχείο των περισσότερων εφαρμογών, η Data βαθμίδα είναι ένα διακριτό τμήμα της εφαρμογής, μοναδικός σκοπός του οποίου είναι να εξάγει αποθηκευμένα δεδομένα από τη βάση δεδομένων και να εισάγει νέα σε αυτήν. Μέσω αυτής της προσέγγισης τα δεδομένα μπορούν εύκολα να επαναχρησιμοποιηθούν, κάνοντας την εφαρμογή πιο εύκολο να συντηρηθεί (maintain). Επιπλέον η ύπαρξη μιας διακριτής βαθμίδας για τα δεδομένα βελτιώνει την απόδοση και το scalability. Υλοποίηση Στο πεδίο του Παγκόσμιου Ιστού, η 3-tier αρχιτεκτονική χρησιμοποιείται σε εφαρμογές και ιστότοπους, τα οποία αναπτύσσονται και λειτουργούν χρησιμοποιώντας τρεις διακριτές βαθμίδες: 1. Έναν τρόπο για την εμφάνιση στατικού περιεχομένου, και πιθανόν και κάποιου αποθηκευμένου (cached) δυναμικού περιεχομένου, στον browser του τελικού χρήστη. 2. Έναν ενδιάμεσο application server που επεξεργάζεται και παράγει δυναμικό περιεχόμενο, για παράδειγμα μια πλατφόρμα Java EE, ASP.NET, ή PHP. 3. Μια back-end βάση δεδομένων, που συνδυάζει και τα δεδομένα και ένα σύστημα 33

42 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 διαχείρισης βάσεων δεδομένων, ή ένα πλήρες RDBMS λογισμικό που διαχειρίζεται και παρέχει πρόσβαση στα δεδομένα. Η μεταφορά των δεδομένων μεταξύ των βαθμίδων είναι και αυτή μέρος της αρχιτεκτονικής. Κάποια από τα πρωτόκολλα που μπορεί να χρησιμοποιηθούν είναι τα SNMP, CORBA, Java RMI,.NET Remoting, Windows Communication Foundation, sockets, UDP, web services, κτλ. Αρκετά συχνά μπορεί να χρησιμοποιηθεί και κάποιο είδος ενδιάμεσου λογισμικού (middleware) για τη διασύνδεση των διαφορετικών βαθμίδων, τα οποία μπορεί να φιλοξενούνται σε φυσικά διακριτούς servers, ενώ κάθε βαθμίδα μπορεί να φιλοξενείται σε ένα cluster. Πλεονεκτήματα Ο τελικός κώδικας κάθε βαθμίδας μπορεί να επαναχρησιμοποιηθεί και σε άλλες βαθμίδες ή τελείως διαφορετικές εφαρμογές που εκτελούν ίδιες λειτουργίες. Κάθε βαθμίδα είναι σχετικά εύκολο να υλοποιηθεί, οπότε είναι καλύτερο να υπάρχουν τρία απλά τμήματα σε μια εφαρμογή παρά ένα πολύπλοκο. Σε κάθε βαθμίδα μπορεί να εμπλακεί διαφορετική ομάδα ειδικών που θα συμβάλλουν με τις εξειδικευμένες γνώσεις τους στην ανάπτυξή της με βέλτιστο τρόπο. Για παράδειγμα, σχεδιαστές GUI μπορούν να αναπτύξουν τη διεπαφή χρήστη, Java προγραμματιστές να ασχοληθούν με τη λογική της εφαρμογής και σχεδιαστές RDBMS να υλοποιήσουν το σχήμα της βάσης δεδομένων. Εκτός από τα συνήθη πλεονεκτήματα του σπονδυλωτού λογισμικού (modular software), η 3-tier αρχιτεκτονική έχει την τάση να επιτρέπει σε οποιοδήποτε από τις τρεις βαθμίδες να αναβαθμιστεί ή να αντικατασταθεί ανεξάρτητα από τις υπόλοιπες καθώς οι απαιτήσεις και η τεχνολογία αλλάζουν. Για παράδειγμα, μια αλλαγή του λειτουργικού συστήματος στην Presentation βαθμίδα θα επηρέαζε μόνο τον κώδικα της διεπαφής χρήστη. Μειονεκτήματα Απαιτείται περισσότερος χρόνος για να αναπτυχθούν οι εφαρμογές σε μια 3-tier αρχιτεκτονική όπου όλη η λογική βρίσκεται στην Application Logic βαθμίδα. Αυτό 34

43 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 συμβαίνει γιατί απαιτείται η ανάπτυξη περισσότερων αντικειμένων για τη Data βαθμίδα και τους μηχανισμούς πρόσβασης στα δεδομένα, επιπλέον των λογικών διεργασιών. Η λογική του συστήματος είναι άμεσα εκτεθειμένη στην Presentation βαθμίδα, και επομένως στους τελικούς χρήστες, γεγονός που αποτελεί σημαντικό θέμα ασφάλειας στις εφαρμογές Παγκόσμιου Ιστού. H ταυτόχρονη παρουσία της λογικής της εφαρμογής (application server) και της παραγωγής του δυναμικού περιεχομένου (web server) στην Application βαθμίδα, μπορεί να προκαλέσει πρόβλημα σε ενδεχόμενες επεκτάσεις της εφαρμογής. Για το λόγο αυτό συνήθως προτείνεται η μετακίνηση του web server στην Presentation βαθμίδα, ή η γενικότερη υιοθέτηση n-tier λύσεων XRX Αρχιτεκτονική Η XRX είναι μια αρχιτεκτονική εφαρμογών Παγκόσμιου Ιστού που βασίζεται στις XForms (εξέλιξη των HTML forms), στην REST (REpresentational State Transfer, μια αρχιτεκτονική λογισμικού για συστήματα κατανεμημένων υπερμέσων), και στην XQuery (μια συναρτησιακή γλώσσα προγραμματισμού που έχει σχεδιαστεί για την εκτέλεση ερωτημάτων σε συλλογές XML δεδομένων) (McCreary, 2008). Κύριο χαρακτηριστικό των XRX εφαρμογών είναι πως αποθηκεύουν δεδομένα τόσο στον client όσο και στο server σε XML μορφή και δεν απαιτούν μετάφραση ανάμεσα σε διαφορετικές μορφές δεδομένων, οπότε εξαιτίας του ελάχιστου αριθμού μεταφράσεων που απαιτούνται για να μετακινηθούν δεδομένα από το server στον client, η XRX θεωρείται μια λιτή και κομψή αρχιτεκτονική εφαρμογών. Είναι μια zero translation αρχιτεκτονική που χρησιμοποιεί XML για να αποθηκεύσει δεδομένα στο browser του client, στον application server και στο database server. Καθώς σε κάθε ένα από αυτά τα επίπεδα χρησιμοποιείται η XML ως δομικό μοντέλο για τα δεδομένα, οι XRX εφαρμογές δε χρειάζεται να μεταφράσουν τις δομές των δεδομένων τους από και προς αντικείμενα και σχεσιακές δομές δεδομένων. Κατά συνέπεια η XRX αρχιτεκτονική επιτρέπει στους προγραμματιστές να εστιάσουν στην 35

44 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 ανάπτυξη της λογικής της εφαρμογής και όχι στο πρόβλημα μετάφρασης των δεδομένων. Επίσης η XRX χρησιμοποιεί αρκετά από τα πρότυπα του W3C (CSS, XHTML 2.0, XPath, XML Schema) προκειμένου να διασφαλίσει ότι οι εφαρμογές που την υιοθετούν θα είναι λειτουργικές και στο μέλλον. Επειδή οι XRX εφαρμογές χρησιμοποιούν μοντέρνες εκφραστικές (declarative) γλώσσες προγραμματισμού στον client και συναρτησιακές (functional) γλώσσες προγραμματισμού στο server, μπορούν να γίνουν κατανοητές από μηπρογραμματιστές, δηλαδή από άτομα που δε γνωρίζουν από διαδικαστικές (procedural) γλώσσες όπως JavaScript, Java, ή.νετ. Η XRX επωφελείται από διάφορα επιτεύγματα και εξελίξεις στην τεχνολογία λογισμικού: Σε επίπεδο client αρχιτεκτονικής: i. η αρχιτεκτονική διαχωρίζει το Model (αποθηκευμένο σε XML) από τα View σε μια εφαρμογή, ii. χρησιμοποιείται ένα μοναδικό element (xf:submission) για όλες τις καταχωρήσεις του server. Αυτό αντικαθιστά αρκετό από τον JavaScript κώδικα που απαιτείται στις περισσότερες AJAX εφαρμογές, iii. υπάρχει ένας εξαρτημένος γράφος για την αποθήκευση της δομής εξάρτησης των client Controller. Αυτό απελευθερώνει τον προγραμματιστή από το να πρέπει να ενημερώνει είτε το Model είτε τα View όταν τα δεδομένα τροποποιούνται στην εφαρμογή. Έτσι, μπορούν να δημιουργηθούν με πολύ μικρή προσπάθεια αρκετά σύνθετες εφαρμογές στον client, i. υποστηρίζεται ένας εκφραστικός (declarative) τρόπο προγραμματισμού που επιτρέπει στις περισσότερες client εφαρμογές που βασίζονται σε XForms, να δημιουργηθούν χρησιμοποιώντας ένα μικρό αριθμό από elements (περίπου 20). Αυτό δίνει τη δυνατότητα επιτρέπει να δημιουργηθούν πλούσιες και διαδραστικές εφαρμογές χωρίς ιδιαίτερες γνώσεις JavaScript ή άλλων διαδικαστικών scripting γλωσσών, iv. υιοθετείται ένα εύκολα επεκτάσιμο σύστημα για τη δημιουργία νέων στοιχείων 36

45 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 ελέγχου στη διεπαφή χρήστη με χρήση της EXtensible Bindings Language. Αυτό επιτρέπει στους προγραμματιστές να προσθέτουν νέα στοιχεία ελέγχου οποιαδήποτε στιγμή, χωρίς να υπάρχει πρόβλημα ασυμβατότητας με τα πρότυπα του W3C. Σε επίπεδο server αρχιτεκτονικής: i. πολλές XML βάσεις δεδομένων έχουν ενσωματωμένες διεπαφές REST, γεγονός που κάνει κάθε XQuery να εγγενώς ένα RESTful web service, ii. υποστηρίζεται ένα συναρτησιακό προγραμματιστικό μοντέλο που οδηγεί στην ανάπτυξη καθαρών συστημάτων, διευκολύνοντας το debugging τους και την εκτέλεσή τους σε πολυεπεξεργαστικά συστήματα, iii. δομείται ένα εύκολα επεκτάσιμο σύστημα κάνοντας χρήση της XQuery. Με αυτόν τον τρόπο η XRX αποτελεί μια αρχιτεκτονική που όχι μόνο απλοποιεί πολλές από τις σύνθετες διαδικασίες (ιδιαίτερα όσες σχετίζονται με το χειρισμό των δεδομένων) κατά την ανάπτυξη εφαρμογών Παγκόσμιου Ιστού με την επιμονή της στα πρότυπα της W3C, αλλά επίσης, παρόλο που εξαρτάται σε μεγάλο βαθμό από τις XForms και την XQuery, δεν αποκλείει και τη χρήση άλλων τεχνολογιών για εγγενή χειρισμό της XML, όπως οι XSLT, XProc, και XSL-FO tier Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 Σε ό,τι αφορά τις εφαρμογές Παγκόσμιου Ιστού επόμενης γενιάς (Web 3.0), και ενώ έχουν αναλυθεί σε σημαντικό βαθμό οι θεωρητικές δυνατότητες και τα χαρακτηριστικά τους, δεν υπάρχει μια ξεκάθαρη επιλογή σχετικά με την κατάλληλη αρχιτεκτονική υποδομής που θα μπορούσε να υποστηρίξει βέλτιστα τις εν λόγω εφαρμογές. Προσπαθώντας να καλύψουμε αυτό το κενό, προτείνουμε μια αρχιτεκτονική υποστήριξης εφαρμογών Παγκόσμιου Ιστού (Pomonis et al., 2009), η οποία παρέχει στους 37

46 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 προγραμματιστές τη δυνατότητα να δομήσουν σύνθετες εφαρμογές Παγκόσμιου Ιστού, που θα συνδυάζουν το όραμα του Web 2.0 και το πλούσιο τεχνολογικό υπόβαθρο του Semantic Web. Τέτοιες εφαρμογές θα μπορούσαν να είναι κάποια σημασιακά wiki επόμενης γενιάς, ευφυή σημασιακά mash-up, σημασιακά portals και γενικά κάθε είδους εφαρμογή με ιδιαίτερες απαιτήσεις χειρισμού δεδομένων που έχει σα στόχο την παροχή σημασιακά δομημένης πληροφορίας, συνδυασμένης με προηγμένες δυνατότητες ευφυούς αναζήτησης. Σε τέτοιου είδους εφαρμογές, η πληροφορία μπορεί να παραδοθεί με δυο βασικούς τρόπους: i. Άμεσα στο browser του τελικού χρήστη, μέσω μιας διεπαφής χρήστη υψηλής διαδραστικότητας. ii. Σαν είσοδος σε άλλα προγράμματα ή υπηρεσίες που λειτουργούν σαν ενδιάμεσοι για τρίτες εφαρμογές Παγκόσμιου Ιστού, μέσω ενός κατάλληλα ορισμένου API, προκειμένου να εξαχθεί και τελικά να χρησιμοποιηθεί το επιθυμητό τμήμα πληροφορίας από την αρχική εφαρμογή. Μια τέτοια αρχιτεκτονική μπορεί να βασιστεί στο κλασσικό 3-tier μοντέλο, το οποίο φαίνεται να είναι μια αρκετά καλή επιλογή για τις εφαρμογές του Web 3.0 (Hendler, 2008). Επίσης, αυτό το μοντέλο αρχιτεκτονικής έχει το πλεονέκτημα πως μπορεί να παρέχει τον επιθυμητό βαθμό ανεξαρτησίας, τόσο σε φυσική όσο και σε λογική κλίμακα, μεταξύ των διακριτών τμημάτων που φιλοξενούν τις τεχνολογίες του Web 2.0 (διεπαφή χρήστη) και του Semantic Web (υποδομή γνώσης), καθώς αντιπροσωπεύονται από διαφορετικές βαθμίδες της αρχιτεκτονικής. Επιπρόσθετα, μια τέτοια λύση μπορεί να αποδειχθεί ιδιαίτερα χρήσιμη στην υποστήριξη μελλοντικών επεκτάσεων της αντίστοιχης εφαρμογής Παγκόσμιου Ιστού, καθώς χαρακτηρίζεται από μεγάλο βαθμό ευελιξίας, με αποτέλεσμα να επιτρέπει την περαιτέρω υιοθέτηση λύσεων κατανεμημένης ή/και παράλληλης λογικής, κυρίως σε ό,τι αφορά τα τμήματά της που ασχολούνται με τη διαχείριση γνώσης. Βέβαια, χρειάζονται να γίνουν κάποιες σημαντικές διαφοροποιήσεις σε σχέση με το παραδοσιακό 3-tier μοντέλο, προκειμένου να εξασφαλιστεί η δυνατότητα υποστήριξης των εφαρμογών του Web 3.0: 38

47 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 i. Αντί για ένα τυπικό σύστημα βάσης δεδομένων, χρησιμοποιούμε ένα σύστημα βάσης γνώσης (knowledge base system), καθώς τα παραδοσιακά DBMS δε διαθέτουν τις απαραίτητες λειτουργίες και χαρακτηριστικά για τη διαχείριση και τη χρησιμοποίηση οντολογικής γνώσης. ii. Σε αντίθεση με την παραδοσιακή αντίληψη για μια front-end (ή presentation) βαθμίδα (tier) που περιλαμβάνει μόνο τη διεπαφή χρήστη, χρησιμοποιούμε ένα web server που φιλοξενεί μια πλήρη εφαρμογή, η οποία αναλαμβάνει όλες τις διεργασίες που αφορούν την επικοινωνία με τους τελικούς χρήστες, και επιπλέον φροντίζει για την τεχνολογική υποστήριξη και υλοποίηση της Web 2.0 συνιστώσας. iii. Η μεσαία βαθμίδα (application logic) λειτουργεί σαν ενδιάμεσο της front-end εφαρμογής και της βάσης γνώσης, καθώς είναι υπεύθυνη για την κατάλληλη μετάφραση των ερωτημάτων των χρηστών και την ανάκτηση της σχετικής πληροφορίας. Στην πραγματικότητα, από την οπτική γωνία του σχεδιαστή εφαρμογών Παγκόσμιου Ιστού, η εν λόγω αρχιτεκτονική μπορεί να οδηγήσει σε κατανεμημένα αποτελέσματα με τουλάχιστον δυο τρόπους: i. Λόγω της φύσης της αρχιτεκτονικής, οι τρεις βαθμίδες της (front-end, application logic, knowledge management) μπορούν να διακριθούν και σε λογική αλλά και σε φυσική κλίμακα, φιλοξενούμενα σε διαφορετικά υπολογιστικά συστήματα. ii. Οι σημασιακές βάσεις γνώσης από τις οποίες εξάγονται τα δεδομένα, μπορούν να είναι συγχρόνως λογικά και φυσικά κατανεμημένες (στην περίπτωση που χρησιμοποιείται η OWL, αυτό μπορεί να επιτευχθεί με τη χρήση της παραμέτρου owl:import), χρησιμοποιώντας ένα ενδιάμεσο σύστημα για την ενσωμάτωσή τους σε μια ενιαία εφαρμογή. Αυτό κρίνεται σκόπιμο από τη στιγμή που οι οντολογίες Παγκόσμιου Ιστού απαντώνται και τείνουν να αναπτύσσονται τμηματικά και κατακερματισμένα, καθώς κάθε μια ασχολείται με μια συγκεκριμένη πλευρά της γνώσης. Οπότε ο συνδυασμός τους και η κατάλληλη ενοποίησή τους μπορούν να οδηγήσουν στην παροχή πλουσιότερων περιγραφών και στην εξαγωγή ισχυρότερων συμπερασμάτων. 39

48 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 Η προτεινόμενη 3-tier αρχιτεκτονική, παρουσιάζεται αναλυτικά στην Εικόνα 3.7. Εικόνα 3.7: Η Προτεινόμενη 3-tier Αρχιτεκτονική Η χαμηλότερη βαθμίδα της προτεινόμενης 3-tier αρχιτεκτονικής είναι η βαθμίδα διαχείρισης γνώσης (knowledge management), η οποία είναι υπεύθυνη για την ενοποίηση και 40

49 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 τη διαχείριση πηγών δεδομένων πιθανώς και ανόμοιας φύσης: οντολογικά έγγραφα, μεταδεδομένα, feeds και κάθε είδους πληροφορία με υποκείμενη σημασιακή δομή ποικίλης πυκνότητας, από σημασιακά δεδομένα έως απλό κείμενο (μηδενική πυκνότητα). Σαν αποτέλεσμα, αυτή η βαθμίδα λειτουργεί σαν ένα σημασιακό mash-up που ενοποιεί την πληροφορία σε μια κοινή διαμεσολαβητική οντολογία. Την ίδια στιγμή επιτελεί τις χαμηλού επιπέδου reasoning λειτουργίες που απαιτούνται για την εξαγωγή της συνεπαγόμενης πληροφορίας. Μια τέτοια υλοποίηση μπορεί να φορτώσει σημασιακές βάσεις γνώσης (έγγραφα OWL) που βρίσκονται είτε στο τοπικό σύστημα αρχείων είτε στο Διαδίκτυο, δημιουργώντας τοπικά ένα προσωρινό αντίγραφο κάθε εγγράφου και, φορτώνοντάς το σε ένα μηχανισμό συλλογισμού (reasoner), να δημιουργήσει και να αποθηκεύσει στη μνήμη ένα εσωτερικό μοντέλο για κάθε μια οντολογία που ταξινομεί. Προφανώς η ταξινόμηση γίνεται μια φορά για κάθε μια οντολογία, κατά το αρχικό της φόρτωμα. Τα αιτήματα των χρηστών, τα ερωτήματα, οι προσθήκες και η κάθε είδους αλληλεπίδραση με το οντολογικό μοντέλο, διεκπεραιώνονται μέσω της βαθμίδας της λογικής της εφαρμογής (application logic). Αυτή η βαθμίδα είναι υπεύθυνη για το φόρτωμα της πληροφορίας στην οντολογία, την κατάλληλη απεικόνισή της στο χρήστη και τη διάσπαση των αιτημάτων του χρήστη σε κατάλληλες, χαμηλού επιπέδου μεθόδους του συστήματος διαχείρισης γνώσης. Τα οντολογικά δεδομένα και τα αποτελέσματα της διαδικασίας συλλογισμού (reasoning) ανακτώνται μέσω της αλληλεπίδρασης με τη βαθμίδα διαχείρισης γνώσης, με χρήση κατάλληλων πρωτοκόλλων επικοινωνίας. Οι ανεξάρτητοι χρήστες ή οι κοινότητες χρηστών μπορούν να αλληλεπιδράσουν με την υποκείμενη βάση γνώσης μέσω της βαθμίδας διεπαφής (front-end) σε μια βάση αμοιβαιότητας. Αυτό σημαίνει ότι δεν περιορίζονται μόνο στην απλή εισαγωγή κάποιων δεδομένων, αλλά τους δίνεται η δυνατότητα της πλήρους αλληλεπίδρασης με αυτά, προσθέτοντας, σχολιάζοντας, ακόμα και επαυξάνοντας το υποκείμενο οντολογικό μοντέλο δεδομένων. Στην περίπτωση μιας αυτοδύναμης εφαρμογής Παγκόσμιου Ιστού, αυτό μπορεί να επιτευχθεί μέσω δυναμικών ιστοσελίδων που συνθέτουν μια πλούσια διεπαφή χρήστη με χρήση ειδικών προγραμματιστικών τεχνικών όπως η AJAX. Εκτός αυτού, στην παρούσα 41

50 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 βαθμίδα, δίνεται η δυνατότητα σε web services, εξωτερικά προγράμματα, scripts και διάφορες διεπαφές διαλειτουργικότητας να συνδεθούν ως χρήστες και να αλληλεπιδράσουν με τη δεδομένη εφαρμογή Παγκόσμιου Ιστού Λειτουργικά Χαρακτηριστικά Σημασιακό Mash-up Μια εφαρμογή βασισμένη στην προτεινόμενη αρχιτεκτονική, θα έχει τη δυνατότητα να χειριστεί πληροφορία που μπορεί να προέρχεται από διάφορες διάσπαρτες πηγές και να χαρακτηρίζεται από διαφορετικό βαθμό σημασιακής πυκνότητας, όπου ως σημασιακή πυκνότητα της πληροφορίας μπορεί να οριστεί ο βαθμός κάλυψης του δεδομένου εννοιολογικού πεδίου από το παραγόμενο οντολογικό μοντέλο. Μάλιστα αυτός ο ορισμός είναι συνεπής με τον ορισμό της οντολογίας, όπως εισάγεται από το Guarino (1998). Σε γενικές γραμμές, μπορεί κανείς να διακρίνει τρεις τύπους τέτοιας πληροφορίας: i. Πληροφορία που περιγράφεται ήδη επαρκώς και τα σημασιακά της χαρακτηριστικά είναι εκφρασμένα σε μορφή εύκολα αναγνώσιμη από τα σχετικά προγράμματα (machine readable). Στην ιδανική περίπτωση, αυτού του είδους η πληροφορία έχει περιγραφεί με κάποια γλώσσα οντολογιών Παγκόσμιου Ιστού, όπως η OWL, ή μπορεί να μετατραπεί με μηδαμινό κόπο. ii. Πληροφορία που είναι οργανωμένη σαν ένα επίπεδο σύνολο σχολίων, όπως συμβαίνει συνήθως με τα σχήματα μεταδεδομένων. Ένα τέτοιο σχήμα μπορεί να υποδηλώνει ένα υποκείμενο σημασιακό μοντέλο, χωρίς να γίνεται επαρκώς κατανοητό. Βέβαια κάθε ένα σχόλιο έχει ξεχωριστή σημασιακή αντιστοίχιση, διευκολύνοντας την τελική δημιουργία ενός πλήρους οντολογικού μοντέλου. iii. Πληροφορία που δίνεται σαν απλό, ανοργάνωτο κείμενο, στη μορφή φυσικής γλώσσας, με αποτέλεσμα να μη δηλώνονται με κανένα τρόπο πιθανά κρυφά σημασιακά χαρακτηριστικά. Στις πρώτες δυο περιπτώσεις μπορεί να εφαρμοστεί η τεχνική του semantic profiling 42

51 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 (Koutsomitropoulos et al., 2007) ώστε να ενισχυθεί η σημασιακή πυκνότητα της πληροφορίας. Με αυτόν τον τρόπο θα αυξηθεί η εκφραστικότητα των περιγραφών οδηγώντας στη δυνατότητα επεξεργασίας και απάντησης σε ερωτήματα συλλογισμού αυξημένης πολυπλοκότητας. Ακόμα και στην περίπτωση που τα σχόλια είναι επίπεδα οργανωμένα σα στοιχεία μεταδεδομένων, μπορεί να κατασκευαστεί από αυτά ένα πλήρως δομημένο οντολογικό μοντέλο, εμπλουτισμένο με νέες δομές σε σχέση με την τελική εφαρμογή, ή με δομές που υλοποιούν σχέσεις που ήδη δηλώνονται στο σχήμα μεταδεδομένων. Έτσι, μπορεί στη συνέχεια να ενσωματωθούν οι διαθέσιμες περιγραφές στη νέα οντολογία, χρησιμοποιώντας μια αυτόματη διαδικασία μετάφρασης (για παράδειγμα βασισμένη σε XSLT), χωρίς να απαιτείται ανθρώπινη μεσολάβηση. Η τρίτη περίπτωση είναι και η πιο πολύπλοκη, καθώς δεν προσφέρει κάποιο συγκεκριμένο εφαλτήριο. Σε αυτή την περίπτωση, απαιτείται κάποιο είδος επεξεργασίας φυσικής γλώσσας (NLP) (Alani et al., 2003) προκειμένου να προσδιοριστούν, για παράδειγμα, πιθανές λέξεις-κλειδιά που μπορεί να αποκαλύπτουν την υποκείμενη ταξινόμηση της κειμενικής περιγραφής. Αυτές οι λέξεις-κλειδιά μπορούν στη συνέχεια να αντιστοιχιστούν σε μια υπάρχουσα οντολογία, όπως η WordNet ( προκειμένου να εξαχθούν σημασιακές σχέσεις μεταξύ τους και να μπορέσουν να προστεθούν στην κεντρική οντολογία της εφαρμογής. Υψηλή Διαδραστικότητα Η βαθμίδα διεπαφής (front-end) της προτεινόμενης αρχιτεκτονικής, μπορεί να υποστηρίξει αυτόνομες εφαρμογές Παγκόσμιου Ιστού που παρέχουν μια ενισχυμένη εμπειρία χρήστη (user experience), η οποία επιτυγχάνεται μέσω πλούσιων διεπαφών. Προκειμένου να υλοποιηθεί μια Rich Internet Application (RIA) (Loosley, 2006), όπου μια εφαρμογή Παγκόσμιου Ιστού διαθέτει τα χαρακτηριστικά και τη λειτουργικότητα των παραδοσιακών εφαρμογών υπολογιστή, μπορούν να χρησιμοποιηθούν προηγμένες προσεγγίσεις του Web 2.0, όπως η τεχνική AJAX, όπου η απαραίτητη επεξεργαστική διαδικασία για τη διεπαφή χρήστη τυπικά μεταφέρεται στο web client, αλλά το κύριο μέρος των δεδομένων διατηρείται στο web server. 43

52 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 Προηγμένα Χαρακτηριστικά Διασυνδεσιμότητας Επιπρόσθετα, υπάρχει πρόβλεψη για επιπρόσθετες δυνατότητες διασυνδεσιμότητας, καθώς ποικίλες διεπαφές διαλειτουργικότητας μπορούν να διασυνδεθούν σα χρήστες με τη βαθμίδα διεπαφής. Για παράδειγμα, μια κατάλληλη εφαρμογή Παγκόσμιου Ιστού μπορεί να διευκολύνει τρίτους προγραμματιστές στο να ενσωματώσουν την ελεύθερα διαμοιραζόμενη σημασιακή πληροφορία στις εφαρμογές τους, παρέχοντας άμεση, υψηλού επιπέδου πρόσβαση στα δεδομένα της μέσω του κατάλληλου API της. Με αυτόν τον τρόπο επιτυγχάνεται η διασύνδεση με τρίτες εφαρμογές Παγκόσμιου Ιστού, κυρίως με χρήση συγκεκριμένων τεχνικών και web services, όπως η επικοινωνία με χρήση XML μηνυμάτων που ακολουθούν το πρότυπο SOAP. Τέλος, μια τέτοια εφαρμογή Παγκόσμιου Ιστού βασισμένη σε ανοιχτά αρχιτεκτονικά πρότυπα, που το περιεχόμενό της και κυρίως το υποκείμενο οντολογικό μοντέλο δεδομένων της είναι ελεύθερα διαθέσιμα, μπορεί να λειτουργήσει σα μια εφαρμογή διαμεσολάβησης (proxy) σε ό,τι αφορά την παροχή σημασιακά δομημένων δεδομένων. Συνεργατική Ανάπτυξη Ουσιώδη χαρακτηριστικά της προτεινόμενης αρχιτεκτονικής αποτελούν οι δυνατότητες και οι διευκολύνσεις συνεργατικής ανάπτυξης, καθώς, προκειμένου να επιτευχθούν καλύτερα αποτελέσματα κατά την ανάπτυξη και υποστήριξη μιας αντίστοιχης εφαρμογής Παγκόσμιου Ιστού, οι χρήστες θα πρέπει να έχουν τη δυνατότητα να συνεισφέρουν σε προσπάθεια και δεδομένα. Με αυτόν τον τρόπο, οι χρήστες μπορούν να συμβάλλουν αποφασιστικά στον εμπλουτισμό της βάσης γνώσης της εφαρμογής, όμως μπορεί να υπάρχουν και περιπτώσεις όπου είναι επιθυμητή και η μεταβολή του ίδιου του οντολογικού σχήματος της εφαρμογής. Σε μια τέτοια περίπτωση, μια ειδική κατηγορία χρηστών θα πρέπει να έχει τη δυνατότητα να ορίσει νέες κλάσεις ή ιδιότητες, οι οποίες θα ενσωματωθούν ή θα εισαχθούν στην κεντρική οντολογία της εφαρμογής. Βέβαια τέτοιου είδους επεμβάσεις θα πρέπει να γίνονται αποκλειστικά με προσθετικό 44

53 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 τρόπο, καθώς η γνώση στο Semantic Web είναι εγγενώς αυξανόμενη. Επιπλέον, αυτές οι προσθήκες θα πρέπει να γίνονται με μεγάλη προσοχή, για να αποφευχθούν φαινόμενα πλεονασμού, για παράδειγμα πολλαπλές ισοδύναμες επαναλαμβανόμενες περιγραφές. Γι' αυτόν το λόγο, προτείνεται να γίνεται συχνή ταξινόμηση, αλλά και έλεγχοι συνέπειας στην οντολογία, καθώς οι πανομοιότυπες περιγραφές μπορούν να ανιχνευθούν μέσω του reasoning Θέματα Υλοποίησης Ένα από τα σημαντικότερα θέματα σε κάθε αρχιτεκτονική υποστήριξης εφαρμογών Παγκόσμιου Ιστού, αλλά και παράλληλα ένας από τους βασικότερους λόγους για την υιοθέτησή της, αποτελεί η ύπαρξη ποιοτικών, ώριμων και δοκιμασμένων τεχνολογικών λύσεων, τόσο για την υλοποίηση των επιμέρους τμημάτων και βαθμίδων της, όσο κυρίως και για την πλήρως λειτουργική και αποδοτική διασύνδεση των ίδιων των βαθμίδων της μεταξύ τους. Στη χαμηλότερη βαθμίδα της αρχιτεκτονικής, και προκειμένου να υλοποιηθεί ένα πλήρως λειτουργικό σύστημα διαχείρισης γνώσης (knowledge management system), μπορεί να χρησιμοποιηθεί ως knowledge base server ένας μηχανισμός εξαγωγής συμπερασμάτων (inference engine), όπως για παράδειγμα κάποιος από τους δημοφιλείς Pellet ( ή FaCT++ ( οι οποίοι υποστηρίζουν πλήρως την OWL 2. Η λογική της εφαρμογής (application logic) μπορεί να υλοποιηθεί αναπτύσσοντας κατάλληλα τμήματα σε γλώσσα προγραμματισμού Java, κάνοντας χρήση κάποιων από τις τεχνολογίες JSP, JavaBeans και Java Servlets, οπότε θα πρέπει να χρησιμοποιηθεί σαν application server ο Tomcat ή κάποιος αντίστοιχός του (π.χ. JBOSS Application Server). Το περιβάλλον διεπαφής (front-end), καθώς είναι πλήρως ανεξάρτητο από τις άλλες βαθμίδες της αρχιτεκτονικής, μπορεί να υλοποιηθεί είτε εξ' αρχής με χρήση μιας δημοφιλούς 45

54 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 τεχνολογίας ανάπτυξης εφαρμογών Παγκόσμιου Ιστού, όπως PHP, JSP, ASP.NET κτλ, είτε υιοθετώντας και παραμετροποιώντας μια έτοιμη λύση, όπως Drupal, Joomla, Plone κτλ. Η επικοινωνία του περιβάλλοντος διεπαφής (front-end) με τη λογική της εφαρμογής (application logic) μπορεί να διεξαχθεί είτε με χρήση φορμών μέσω του πρωτοκόλλου HTTP, είτε με την υιοθέτηση κάποιων κατάλληλων web services βασισμένων σε XML. Ειδικά στην περίπτωση που επιλεγούν οι δημοφιλέστερες τεχνολογίες για την υλοποίηση των επιμέρους βαθμίδων (PHP για τη διεπαφή και Java για τη λογική της εφαρμογής), τότε μπορεί να χρησιμοποιηθούν ακόμα και ειδικά δικτυακά πρωτόκολλα βασισμένα σε XML, όπως το PHP/Java Bridge ( Σε ότι αφορά την επικοινωνία της λογικής της εφαρμογής (application logic) με το σύστημα διαχείρισης γνώσης (knowledge management system), θα μπορούσε να πραγματοποιηθεί είτε με χρήση του πρωτοκόλλου DIG 1.1 ( το οποίο προσφέρεται για απομακρυσμένη διασύνδεση, αλλά δεν υποστηρίζει πλήρως την απαιτούμενη OWL 2 εκφραστικότητα (ούτε καν OWL DL), είτε με χρήση του OWL API ( το οποίο υποστηρίζει πλήρως την OWL 2, αλλά η δυνατότητα διασύνδεσης περιορίζεται σε υλοποιήσεις στο ίδιο υπολογιστικό σύστημα (direct in-memory implementation). Τον τελευταίο χρόνο (Νοέμβριος 2009) παρουσιάστηκε η εξέλιξη του πρωτοκόλλου DIG 1.1, το OWLlink ( το οποίο όμως έχει κάποιες ελλείψεις και χρειάζεται εμπλουτισμό των προδιαγραφών του σε σχέση με την επιθυμητή λειτουργικότητα. Επίσης με ενδιαφέρον αναμένεται (Ιούλιος 2010) η τελική έκδοση του αντίστοιχου OWLlink API ( Από τη στιγμή που οι μόνες διαθέσιμες προτάσεις δεν ικανοποιούσαν τις απαιτήσεις που είχαμε θέσει για μια ολοκληρωμένη μέθοδο διασύνδεσης, αποφασίσαμε να δώσουμε λύση στο δεδομένο πρόβλημα αναπτύσσοντας τη δική μας εφαρμογή διασύνδεσης, βασιζόμενοι στο ήδη δοκιμασμένο OWL API. 46

55 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web Απομακρυσμένη Διασύνδεση σε Μηχανισμούς Συλλογισμού Επιδιώκοντας να αποφύγουμε καταστάσεις που θα περιόριζαν τη λειτουργικότητα της τελικής εφαρμογής και παράλληλα να έχουμε τη δυνατότητα υποστήριξης μιας πλήρως κατανεμημένης αρχιτεκτονικής λύσης, σχεδιάσαμε και αναπτύξαμε μια παραλλαγή του OWL API (v. 2), η οποία, επιπλέον των δυνατοτήτων του πρωτότυπου, μπορεί να υποστηρίξει τη δυνατότητα εξ' αποστάσεως επικοινωνίας με μηχανισμούς συλλογισμού (Koutsomitropoulos et al., 2010). Σαν αποτέλεσμα, αυτή η προσέγγιση μπορεί να συνεργαστεί με οποιονδήποτε μηχανισμό συλλογισμού που υποστηρίζεται από το OWL API, όπως για παράδειγμα ο FaCT++ ή ο Pellet. Στόχος μας είναι να έχουμε έναν κεντρικό server που θα φιλοξενεί το μηχανισμό συλλογισμού, και ο οποίος θα μπορεί να εξυπηρετήσει, μέσω του πρωτοκόλλου TCP/IP, μία ή περισσότερες client εφαρμογές, οι οποίες θα πρέπει να έχουν τη δυνατότητα να κάνουν ερωτήματα και να παίρνουν απαντήσεις από τη βάση γνώσης, ακριβώς όπως αν χρησιμοποιούσαν το πρωτότυπο OWL API. Για να το πετύχουμε αυτό, αναπτύξαμε μια client-server διεπαφή σε Java, χρησιμοποιώντας απομακρυσμένα αντικείμενα (remote objects). Ο μηχανισμός συλλογισμού φιλοξενείται σε ένα server μαζί με το OWL API και με τη server εφαρμογή μας, η οποία ακούει σε ένα συγκεκριμένο port περιμένοντας κάποια σύνδεση. Η client εφαρμογή μας, μια παραλλαγή του OWL API, βρίσκεται σε διαφορετικό φυσικό υπολογιστικό σύστημα και, προκειμένου να χρησιμοποιήσει το μηχανισμό συλλογισμού, χρειάζεται να συνδεθεί στη server εφαρμογή. Αμέσως μετά τη σύνδεση, η server εφαρμογή αρχικοποιεί ένα αντικείμενο Reasoner, φορτώνει τις παραμέτρους από την client εφαρμογή, καλεί την αντίστοιχη μέθοδο του μηχανισμού συλλογισμού και στέλνει πίσω στην client εφαρμογή τα αποτελέσματα. Η όλη client-server επικοινωνία και η ανταλλαγή των μηνυμάτων γίνεται μέσω του πρωτοκόλλου TCP/IP. 47

56 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web Server Εφαρμογή Στη server εφαρμογή μας (Εικόνα 3.8), φτιάξαμε μια κλάση myserver που, αμέσως μετά την αρχικοποίηση της εφαρμογής, δημιουργεί ένα TCP/IP ServerSocket σε ένα καθορισμένο port και περιμένει συνδέσεις. Μετά τη σύνδεση καλείται η μέθοδος WorkerRunnable() που αρχικοποιεί ένα αντικείμενο OWLOntologyManager και ένα αντικείμενο Reasoner, και διαβάζει τις παραμέτρους της client εφαρμογής, οι οποίες γίνονται deserialized με χρήση της εντολής readobject(). Μετά την επεξεργασία των αιτημάτων της client, η server του στέλνει τα αποτελέσματα κάνοντας χρήση της μεθόδου writeobject(). Εικόνα 3.8: Server Εφαρμογή Πολυνηματική Προσέγγιση Προκειμένου να επεκτείνουμε περαιτέρω τα χαρακτηριστικά κατανεμημένης εφαρμογής της προσέγγισής μας, αναπτύξαμε και μια άλλη έκδοση της server εφαρμογής μας, η οποία χρησιμοποιεί νήματα (Εικόνα 3.9). Σε αυτήν την πολυνηματική έκδοση, η βασική διαφορά 48

57 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 είναι πως, αντί για την κλήση της μεθόδου WorkerRunnable(), δημιουργείται ένα νέο νήμα της κλάσης WorkerRunnable. Έτσι, κάθε client που συνδέεται στη server εξυπηρετείται από ένα διαφορετικό στιγμιότυπο της WorkerRunnable, δηλαδή από ένα διαφορετικό στιγμιότυπο της κλάσης Reasoner. Με αυτόν τον τρόπο, τα αιτήματα των client εξυπηρετούνται παράλληλα, αντί να υπάρχει αναμονή για σειριακή εξυπηρέτηση. Το μόνο θέμα αυτής της πολυνηματικής προσέγγισης είναι πως δε μπορεί να συνδυαστεί με το FaCT++, καθώς αυτός κάνει χρήση του JNI (Java Native Interface), το οποίο δεν υποστηρίζει πολυνηματικότητα. Εικόνα 3.9: Πολυνηματικός Server Client Εφαρμογή Για να έχουμε μια πλήρως λειτουργική client εφαρμογή (Εικόνα 3.10), αρχικά δημιουργήσαμε μια κλάση myreasoner. Ο δημιουργός της δέχεται τρία ορίσματα: ένα 49

58 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 αντικείμενο OWLOntologyManager, την IP διεύθυνση της server εφαρμογής, και αντίστοιχο το port. Όταν κατασκευάζεται ένα αντικείμενο myreasoner, δημιουργεί ένα TCP/IP Java Socket, μαζί με τα αντίστοιχα ObjectOutputStream και ObjectInputStream που απαιτούνται για την client-server επικοινωνία. Εικόνα 3.10: Client Εφαρμογή Επιπρόσθετα, η κλάση myreasoner περιέχει όλες τις σχετικές μεθόδους που ορίζονται στις διεπαφές του πρωτότυπου OWL API. Αυτές οι μέθοδοι είναι ακριβή αντίγραφα των πρωτότυπων, προκειμένου να υπάρξει μια υλοποίηση που θα μπορεί να χρησιμοποιηθεί αντί για το πρωτότυπο OWL API, με ελάχιστες τροποποιήσεις στον κώδικα μιας εφαρμογής. Έτσι, μια τυπική εφαρμογή που βασίζεται στο OWL API απλώς χρειάζεται να χρησιμοποιήσει τη δική μας κλάση myreasoner, αντί για την αντίστοιχη πρωτότυπη: myreasoner reasoner = new myreasoner (manager, address, port); Από εδώ και πέρα κάθε μέθοδος μπορεί να χρησιμοποιηθεί ακριβώς όπως στο πρωτότυπο 50

59 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 OWL API, για παράδειγμα: reasoner.classify(); Οι παράμετροι αυτών των μεθόδων μπορούν να είναι είτε πρωτογενή αντικείμενα Java (String, Boolean κτλ) ή αντικείμενα OWL API (OWLClass, OWLIndividual, OWLObjectProperty κτλ), οπότε, προκειμένου να καταστεί δυνατό για τις μεθόδους μας να στέλνουν τις παραμέτρους τους μέσω του TCP/IP, χρησιμοποιήσαμε Java Serialization. Χρησιμοποιούμε τις μεθόδους writeobject() και readobject() για τη μετατροπή ενός αντικειμένου Java σε bytes και το στέλνουμε στη server εφαρμογή μέσω του TCP/IP Socket και αντίστροφα. Ένα παράδειγμα μιας τέτοιες μεθόδου της κλάσης myreasoner είναι: public boolean hasobjectpropertyrelationship (OWLIndividual individual1, OWLObjectPropertyExpression expression, OWLIndividual individual2) throws IOException { out.writeint(hasobjectpropertyrelationship); out.writeobject(individual1); out.writeobject(expression); out.writeobject(individual2); out.flush(); boolean result = in.readboolean(); return result; } Προσέγγιση Βασισμένη σε URI Χρησιμοποιώντας το Java Serialization πρωτόκολλο στην υλοποίηση μας, παρατηρήσαμε πως η μεταφορά των Java αντικειμένων σε byte μορφή, έχει την τάση να αυξάνει αρκετά το φόρτο επικοινωνίας, εξ' αιτίας της πολύπλοκης δομής των OWL API αντικειμένων, καθώς κάθε στιγμιότυπο της κλάσης OWL API κληρονομεί από πολλές διαφορετικές κλάσεις και διεπαφές, με αποτέλεσμα τη μεγέθυνση των αντίστοιχων αντικειμένων. Προκειμένου να ξεπεράσουμε αυτό το μειονέκτημα, αποφασίσαμε να τροποποιήσουμε 51

60 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 την υλοποίησή μας, ώστε τα OWL API αντικείμενα, αντί να στέλνονται αυτούσια με χρήση του Java Serialization, να αντικαθιστώνται από τα URI τους, όπου είναι εφικτό, όπως για παράδειγμα στις κλάσεις OWLClass, OWLIndividual και OWLDataProperty. Με αυτόν τον τρόπο πετύχαμε να μικρύνουμε το φόρτο της client-server επικοινωνίας σε αρκετές περιπτώσεις. Έτσι, η μέθοδος της κλάσης myreasoner από το προηγούμενο παράδειγμα, με χρήση των URI μετατρέπεται ως εξής: public boolean hasobjectpropertyrelationship (OWLIndividual individual1, OWLObjectPropertyExpression expression, OWLIndividual individual2) throws IOException { out.writeint(hasobjectpropertyrelationship); URI uri1 = individual1.geturi(); out.writeobject(uri1); out.writeobject(expression); URI uri2 = individual2.geturi(); out.writeobject(uri2); out.flush(); boolean result = in.readboolean(); return result; } Πειραματικές Μετρήσεις Η εν λόγω εφαρμογή δοκιμάστηκε με δυο διαφορετικούς μηχανισμούς συλλογισμού που υποστηρίζουν το OWL API, και συγκεκριμένα με τους FaCT++ (v. 1.3) και Pellet (v. 2.0), δίνοντας αισιόδοξα αποτελέσματα, ακόμα και στην περίπτωση πολύ απλών οντολογιών. Προκειμένου να αντιληφθούμε τις δυνατότητες της υλοποίησής μας, εκτελέσαμε διάφορες πειραματικές δοκιμές και μετρήσεις βασισμένοι στο πολύ γνωστό Παράδειγμα 8 της τεκμηρίωσης του OWL API, κάνοντας χρήση είτε της οντολογίας pizza.owl ( είτε της Finance.owl ( οι οποίες και οι δυο ανήκουν στη διάλεκτο OWL DL. Για τα πειράματά μας χρησιμοποιήσαμε δυο διαφορετικά υπολογιστικά 52

61 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 συστήματα: ένα client με επεξεργαστή Intel Atom 1.6 GHz και 2 GB RAM, και ένα server με επεξεργαστή Intel Core 2 Duo 2.66 GHz και 2 GB RAM. Κατά τη διάρκεια διάφορων πειραμάτων, μετρήσαμε το χρόνο (σε ms) που καταναλώνουν κάποιες μέθοδοι, όπως και το συνολικό χρόνο εξαγωγής συμπεράσματος (reasoning) σε κάθε περίπτωση. Ο συνολικός χρόνος εξαγωγής συμπεράσματος αναφέρεται στο χρόνο χρειάζεται για να ολοκληρωθεί η εκτέλεση του σχετικού προγράμματος του παραδείγματος. Οι άλλες μετρικές αναφέρονται σε διάφορες διεργασίες και μεθόδους της διαδικασίας εξαγωγής συμπεράσματος και συνεισφέρουν στο συνολικό χρόνο, με την classify() να αποδεικνύεται η δυσκολότερη από πλευράς πολυπλοκότητας. Επίδραση Υποδομής Για αρχή, δοκιμάσαμε την απόδοση των FaCT++ και Pellet, με βάση μια τοπική εγκατάσταση του πρωτότυπου OWL API, χρησιμοποιώντας είτε το server είτε το client σύστημα, παρατηρώντας παράλληλα και την επίδραση του αντίστοιχου υπολογιστικού συστήματος. Τα αποτελέσματα συνοψίζονται στον Πίνακα 3.1. Πίνακας 3.1: Μετρήσεις Τοπικής Εγκατάστασης με Διάφορες Συνθέσεις Υποδομής Total reasoning time loadontologies() classify() isconsistent() getinconsistentclasses() getdescedantclasses() Server, FaCT++, pizza Server, Pellet, pizza Server, FaCT++, Finance Server, Pellet, Finance Client, FaCT++, pizza Παρατηρούμε πως, στην περίπτωση που χρησιμοποιείται ο FaCT++ σε μια τοπική εγκατάσταση, η μόνη χρονοβόρα μέθοδος είναι η classify(). Αντιθέτως, όταν χρησιμοποιείται ο Pellet, παρατηρούμε μια σημαντική αύξηση στους επιμέρους χρόνους αλλά και στο συνολικό χρόνο σε σχέση με το FaCT++, λόγω των διαφορετικών τους υλοποιήσεων, καθώς και λόγω της εξάρτησης του Pellet από το JVM (Java Virtual Machine). Αυτός είναι και ο λόγος που επιλέξαμε να συνεχίσουμε τα πειράματα μόνο με το FaCT++. 53

62 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 Επιπρόσθετα, φαίνεται πως ο συνολικός χρόνος εξαγωγής συμπεράσματος σχετίζεται άμεσα με το μέγεθος και την πολυπλοκότητα της οντολογίας. Καθώς η οντολογία Finance.owl είναι μεγαλύτερη και πιο πολύπλοκη από την pizza.owl, είναι επόμενο πως οι διεργασίες της εξαγωγής συμπεράσματος θα χρειαστούν περισσότερο χρόνο για την ολοκλήρωσή τους. Τέλος, συγκρίνοντας την πρώτη με την τελευταία στήλη, παρατηρούμε πως η διαδικασία εξαγωγής συμπεράσματος εξαρτάται σε μεγάλο βαθμό από τους διαθέσιμους υπολογιστικούς πόρους: ένα πραγματικά ισχυρό υπολογιστικό σύστημα μπορεί να επιταχύνει σημαντικά την απόδοση της όλης διαδικασίας. Επίδραση Απομακρυσμένης Επικοινωνίας Στη συνέχεια, δοκιμάσαμε όλες τους πιθανούς τοπολογικούς συνδυασμούς: τοπική εγκατάσταση στο client σύστημα (χωρίς απομακρυσμένη επικοινωνία) και client-server εγκατάσταση, χρησιμοποιώντας κάθε μια οντολογία. Αυτά τα αποτελέσματα συνοψίζονται στον Πίνακα 3.2. Πίνακας 3.2: Μετρήσεις Με και Χωρίς Απομακρυσμένη Επικοινωνία Total reasoning time loadontologies() classify() isconsistent() getinconsistentclasses() getdescedantclasses() local, pizza client-server, pizza local, Finance client-server, Finance Παρατηρούμε πως υπάρχει μια σημαντική χρονική καθυστέρηση σε σχεδόν όλες τις περιπτώσεις, εξαιτίας της απομακρυσμένης επικοινωνίας μέσω του πρωτοκόλλου TCP/IP και του Java Serialization, όπως αναμενόταν. Τουναντίον, η ύπαρξη ενός ισχυρού υπολογιστικού συστήματος αποκλειστικά για τις διαδικασίες εξαγωγής συμπεράσματος, μπορεί να επιταχύνει σημαντικά τις μεθόδους εκείνες που υψηλές απαιτήσεις σε υπολογιστική ισχύ (όπως η classify()), μειώνοντας αρκετά την επίδραση της καθυστέρησης λόγω απομακρυσμένης επικοινωνίας. Για παράδειγμα, η οντολογία Finance.owl ταξινομείται 54

63 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 περίπου 75% ταχύτερα όταν η σχετική διεργασία ανατίθεται σε ένα δυνατότερο σύστημα διαμέσου της εφαρμογής μας. Επίδραση Εύρους Ζώνης Σαν ένα τρίτο βήμα, δοκιμάσαμε να μετρήσουμε την επίδραση του είδους της δικτυακής σύνδεσης (σε ό,τι αφορά το εύρος ζώνης) ανάμεσα στα δύο υπολογιστικά συστήματα. Δοκιμάσαμε την υλοποίησή μας χρησιμοποιώντας μια σύνδεση οπτικής ίνας και μια σύνδεση DSL (2 Mbps / 256 Kbps), όπως φαίνεται στον Πίνακα 3.3. Πίνακας 3.3: Μετρήσεις σε Διαφορετικά Είδη Δικτυακής Σύνδεσης Total reasoning time loadontologies() classify() isconsistent() getinconsistentclasses() getdescedantclasses() pizza, fiber pizza, DSL Finance, fiber Finance, DSL Τα αποτελέσματα επιβεβαιώνουν πως η απόδοση της υλοποίησής μας, όπως άλλωστε και οποιασδήποτε κατανεμημένης εφαρμογής, εξαρτάται σημαντικά από το είδος της δικτυακής σύνδεσης ανάμεσα στα δύο υπολογιστικά συστήματα, ιδιαίτερα για τη μέθοδο loadontologies(). Παρατηρούμε πως στην περίπτωση ευμεγέθων οντολογιών, μια πολύ γρήγορη δικτυακή σύνδεση μπορεί να δώσει πολύ καλά χρονικά αποτελέσματα, θεωρητικά πλησιάζοντας την περίπτωση της τοπικής εγκατάστασης. Επίδραση Πρωτοκόλλου Επικοινωνίας Στην καθυστέρηση λόγω δικτυακής επικοινωνίας, φαίνεται να έχει σημαντική συνεισφορά και η επίδραση του Java Serialization πρωτοκόλλου, εξαιτίας της πολύπλοκης δομής των OWL API αντικειμένων που πρέπει να μεταφερθούν κατά την client-server επικοινωνία. Με αυτό το σκεπτικό, πειραματιστήκαμε και με μια παραλλαγή της υλοποίησής μας, η οποία χρησιμοποιεί και ανταλλάσσει μόνο τα URI των αντικειμένων, αντί για τα ίδια τα serialized αντικείμενα. Με αυτόν τον τρόπο ο φόρτος της επικοινωνίας μεταξύ client και server μπορεί να μειωθεί σημαντικά σε αρκετές περιπτώσεις, ακόμα και στην απλούστερη 55

64 Αρχιτεκτονική Υποστήριξης Εφαρμογών του Web 3.0 περίπτωση της οντολογίας pizza.owl, όπως φαίνεται και στον Πίνακα 3.4. Πίνακας 3.4: Μετρήσεις για Επικοινωνία μέσω Java Serialization και URI local, pizza Total reasoning time loadontologies() classify() isconsistent() getinconsistentclasses() getdescedantclasses() client-server (Serialize), pizza client-server (URI), pizza Συζήτηση Ένα άμεσο συμπέρασμα από τα παραπάνω είναι το ότι όσο δυσκολότερη είναι μια οντολογία, τόσο καλύτερα αποδίδει η υλοποίησή μας, καθώς μικραίνει αναλογικά η επίδραση του σχετικής καθυστέρησης λόγω δικτύου. Επομένως, αφού στην πραγματικότητα οι οντολογίες έχουν την τάση να διογκώνονται και να εξελίσσονται με το χρόνο, καθιστώντας ιδιαίτερα δύσκολη την αποθήκευση (cache) των αποτελεσμάτων της ταξινόμησής τους, τα οφέλη της χρησιμοποίησης ενός ισχυρού υπολογιστικού συστήματος αποκλειστικά για τις διαδικασίες εξαγωγής συμπερασμάτων τελικά θα ξεπεράσει της επίδραση της δικτυακής επικοινωνίας, καθιστώντας δυνατή τη χρήση υποδεέστερων υπολογιστικών συστημάτων για την διεκπεραίωση όλων των υπόλοιπων (εκτός της διαδικασίας συλλογισμού) διαδικασιών μιας οποιαδήποτε σημασιακής εφαρμογής που χρησιμοποιεί οντολογίες. 56

65 4. Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 Ένας από τους σημαντικότερους κλάδους του Web Engineering, έχοντας άμεση συσχέτιση και με τον αντίστοιχο του Software Engineering, του οποίου άλλωστε αποτελεί απευθείας απόγονο, είναι η διαδικασία ανάπτυξης (development process) των εφαρμογών του Παγκόσμιου Ιστού. Συγκεκριμένα, ο όρος διαδικασία ανάπτυξης αναφέρεται στη μελέτη, θεωρητική και πρακτική, στην εφαρμογή και στη συνεχή βελτίωση της μεθοδολογίας σχεδιασμού και υλοποίησης μιας εφαρμογής Παγκόσμιου Ιστού καθόλα τα στάδια του κύκλου ζωή της, από την αρχική σύλληψή της έως την τακτική συντήρηση και εξέλιξή της. Σαν επακόλουθο, η διαδικασία ανάπτυξης εφαρμογών Παγκόσμιου Ιστού αποτελεί την ουσιαστική σύνθεση διαφορετικών φάσεων του κύκλου ζωής της εφαρμογής, όπως άλλωστε συμβαίνει σε αντίστοιχο βαθμό και κατά την παραδοσιακή διαδικασία ανάπτυξης λογισμικού: Ανάλυση Απαιτήσεων (Requirements Analysis): Αρχικά, γίνεται μελέτη και ανάλυση των χαρακτηριστικών που αποτελούν ακριβείς απαιτήσεις για την τελική εφαρμογή. Η ανάλυση πρέπει να καλύπτει τις ανάγκες και τις απαιτήσεις όλων των εμπλεκομένων πλευρών, συμπεριλαμβανομένων των τελικών χρηστών της εφαρμογής. Σχεδιασμός (Design): Αυτή η φάση καλύπτει τις δραστηριότητες που αφορούν στην αρχιτεκτονική του συστήματος και τα λειτουργικά διαγράμματα ροής, σε συνδυασμό με τη λεπτομερή περιγραφή της τελικής εφαρμογής. Σε αυτή τη φάση μπορεί να υπάρχουν πολλές προτάσεις και παρατηρήσεις από τους εμπλεκόμενους φορείς, οι οποίες θα πρέπει να καταγραφούν και να συζητηθούν πριν τη μετακίνηση στην επόμενη φάση. Πολλές φορές μπορεί να περιλαμβάνει ένα μικρό πρωτότυπο ή ένα μικρό λειτουργικό μοντέλο της προς ανάπτυξη εφαρμογής. Υλοποίηση (Implementation): Η συγκεκριμένη φάση μετατρέπει το λεπτομερές 57

66 Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 σχέδιο και την αναλυτική περιγραφή στο πραγματικό τελικό προϊόν. Περιλαμβάνει την ενσωμάτωση του πηγαίου κώδικα, των αρχείων και του περιεχομένου της βάσης δεδομένων σε μια ενιαία οντότητα. Έλεγχος ή Επικύρωση (Testing or Validation): Σε αυτή τη φάση δοκιμάζεται η εφαρμογή ή τα τμήματά της μέσω ποικίλων διαδικασιών έλεγχου, όπως έλεγχος απόδοσης (performance testing), φόρτου (load and stress testing), συμβατότητας (cross-browser compatibility testing), προσβασιμότητας (accessibility testing), ευχρηστίας (usability testing), ανάλυσης (resolution testing) και ολοκλήρωσης (integration testing). Απώτερος σκοπός είναι η πρόληψη ελαττωμάτων ή δυσλειτουργιών. Συντήρηση (Maintenance): Η συντήρηση είναι μια από τις σημαντικότερες φάσεις της συνολικής διαδικασίας. Περιλαμβάνει τη συχνή ενημέρωση της εφαρμογής ώστε να διατηρείται επίκαιρη. Επίσης διορθώνονται ελαττώματα και τυχόν λάθη που προκύπτουν κατά τη λειτουργία της. Πρέπει να σημειωθεί πως τα παραπάνω βήματα δεν είναι αυστηρώς καθορισμένα και συγκεκριμένα για τη διαδικασία ανάπτυξης μίας εφαρμογής Παγκόσμιου Ιστού, αλλά μπορεί να διαφοροποιηθούν σύμφωνα με τις απαιτήσεις και τη στρατηγική της ομάδας ανάπτυξης και των υπόλοιπων εμπλεκόμενων φορέων. 4.1 Διαδικασίες Ανάπτυξης Εφαρμογών Παγκόσμιου Ιστού Πολλές από τις πρώτες προσπάθειες για τον καθορισμό μιας διαδικασίας ανάπτυξης εφαρμογών Παγκόσμιου Ιστού αποτελούσαν ελαφρές παραλλαγές των παραδοσιακών διαδικασιών ανάπτυξης λογισμικού, καθώς οι εφαρμογές Παγκόσμιου Ιστού δε θεωρούνταν τίποτα περισσότερο από ένα τυπικό προϊόν λογισμικού. Όταν όμως το Web Engineering προτάθηκε και άρχισε να αντιμετωπίζεται ως ένα ξεχωριστό πεδίο, και όχι ως υποσύνολο του παραδοσιακού Software Engineering (Murugesan et al., 1999), οι προτάσεις για τη διαδικασία ανάπτυξης των εφαρμογών Παγκόσμιου Ιστού άρχισαν να προσεγγίζουν πιο συγκεκριμένα το γενικότερο πλαίσιο του Παγκόσμιου Ιστού, με αποτέλεσμα οι περισσότερες 58

67 Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 από τις σημερινές διαδικασίες ανάπτυξης εφαρμογών Παγκόσμιου Ιστού να αποτελούν σημαντική εξέλιξη και επέκταση των παραδοσιακών διαδικασιών ανάπτυξης λογισμικού (Εικόνα 4.1). Εικόνα 4.1: Παραδοσιακές Διαδικασίες Ανάπτυξης Λογισμικού Καθώς η ανάπτυξη μιας εφαρμογής Παγκόσμιου Ιστού είναι μια κυρίως επαναληπτική διαδικασία, οι περισσότερες σημερινές προσεγγίσεις βασίζονται σε αντίστοιχες επαναληπτικές διαδικασίες ανάπτυξης λογισμικού. Αρχικά, η πιο προφανής προσέγγιση ήταν η υιοθέτηση του τροποποιημένου μοντέλου καταρράκτη (modified waterfall model) (Powell et al., 1998), το οποίο αποτελείται από τα ίδια στάδια του παραδοσιακού μοντέλου καταρράκτη, όπου όμως τα δυο πρώτα σχεδιαστικά στάδια επαναλαμβάνονται μερικές φορές, σχηματίζοντας δίνες (whirlpools), προκειμένου να υπάρξει καλύτερη κατανόηση των απαιτήσεων των χρηστών. 59

68 Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 Στη συνέχεια, και αφού το επαναληπτικό μοντέλο καταρράκτη θεωρήθηκε υπερβολικά άκαμπτο, στις περισσότερες των περιπτώσεων, για τις ανάγκες της ανάπτυξης εφαρμογών Παγκόσμιου Ιστού (Pressman, 2005), άρχισε να προτιμάται η σπειροειδής διαδικασία (spiral process) (Boehm & Hansen, 2001). Αλλά ακόμα και η ενδεικτική υιοθέτηση αυτής της διαδικασίας, εξαιτίας της ιδιαίτερης φύσης του Παγκόσμιου Ιστού, συναντά αρκετές δυσκολίες, όπως η ασάφεια στον ακριβή καθορισμό των συγκεκριμένων βημάτων σε κάθε κύκλο και η απουσία μιας κοινής μετρικής για τον προσδιορισμό της ολοκλήρωσης ενός κύκλου. Μια διαφορετική σχολή προτείνει μια αντικειμενοστραφή προσέγγιση βασισμένη στη UML, όπως συμβαίνει στην περίπτωση αρκετών διαδικασιών ανάπτυξης από τις βασισμένες στο περιβάλλον.net (Clark, 2004) έως τη Model Driven Design (Mellor & Balcer, 2002). Ακόμα και η Rational Unified Process (Schach, 2005), η οποία είναι συγχρόνως επαναληπτική και αντικειμενοστραφής, κάνει εκτεταμένη χρήση της UML. Το πρόβλημα με όλες αυτές τις προσεγγίσεις που βασίζονται στη UML είναι πως είναι δύσκολο να εφαρμοστούν στην πράξη, καθώς αποδεικνύονται αρκετά πολύπλοκες και χρονοβόρες εξαιτίας του ότι απαιτούν ένα σημαντικό αριθμό σχεδιαστικών διαγραμμάτων και εγγράφων, ενώ συνήθως οι εφαρμογές Παγκόσμιου Ιστού έχουν την απαίτηση για γρήγορη ανάπτυξη. Αυτή η ανάγκη για τη γρήγορη ανάπτυξη των εφαρμογών Παγκόσμιου Ιστού, φαίνεται να προκρίνει την υιοθέτηση του Extreme Programming (XP), που φαντάζει ως η πιο κατάλληλη επιλογή για την ανάπτυξη εφαρμογών Παγκόσμιου Ιστού, καθώς δίνει έμφαση στον ελάχιστο σχεδιασμό, στη γρήγορα ανάπτυξη πρωτοτύπων και στον έλεγχο αποδοχής (acceptance testing) (Beck & Fowler, 2001). Στο ίδιο πλαίσιο κινούνται και οι πιο γενικές Agile τεχνικές που βασίζονται στη μείωση του σχεδιαστικού φόρτου κατά την ανάπτυξη του έργου και στη δυνατότητα για διενέργεια επεμβάσεων και αλλαγών στο πλάνο ανάπτυξης του έργου (project development plan) (Aoyama, 1998). Βέβαια, πρέπει να σημειωθεί πως υπάρχουν και κάποια γενικά χαρακτηριστικά, κοινά για όλες τις εφαρμογές Παγκόσμιου Ιστού (Subramanian & Whitson, 2008): 60

69 Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 Μια εφαρμογή Παγκόσμιου Ιστού περιέχει πολύ πληροφοριακό περιεχόμενο, και η ανάπτυξή της εμπεριέχει σημαντικό βαθμό ενασχόλησης για τη δημοσίευση αυτού του περιεχομένου. Η διαδικασία ανάπτυξης μιας εφαρμογής Παγκόσμιου Ιστού περιλαμβάνει σχεδιασμό διαχείρισης πληροφορίας και όχι απλό σχεδιασμό διαχείρισης βάσης δεδομένων. Ενώ η αρχιτεκτονική του συστήματος είναι σημαντική, όπως και σε όλες τις διαδικασίες του Software Engineering, εξίσου σημαντικό είναι και το σύστημα πλοήγησης (navigational system), το οποίο συχνά είναι στενά συσχετισμένο με την αρχιτεκτονική του συστήματος. Η διαδικασία ανάπτυξης μιας εφαρμογής Παγκόσμιου Ιστού τείνει να είναι σπειροειδής, agile (αν όχι extreme) και μικρής διάρκειας. Παρόλο που υπάρχουν αρκετές διαφορετικές προσεγγίσεις για τη διαδικασία ανάπτυξης εφαρμογών Παγκόσμιου Ιστού, καμιά τους δε φαίνεται να είναι ικανή για να εφαρμοστεί καθολικά. Ένα χαρακτηριστικό που όλες οι παραπάνω διαδικασίες έχουν κοινό, είναι πως προσπαθούν να προτείνουν μια λύση που θα μπορεί να εφαρμοστεί σε όλες τις περιπτώσεις εφαρμογών Παγκόσμιου Ιστού, χωρίς να λαμβάνουν υπόψη τις ιδιαίτερες απαιτήσεις που μπορεί να έχουν πολλές διακριτές κατηγορίες εφαρμογών. Αυτή η ιδιαιτερότητα γίνεται ιδιαίτερη έντονη στην περίπτωση των εφαρμογών του Web 2.0 και του Semantic Web, τα οποία αποτελούν τα δυο σημαντικότερα πεδία ενδιαφέροντος στον Παγκόσμιο Ιστό κατά την τελευταία δεκαετία Διαδικασία Ανάπτυξης Εφαρμογών του Web 2.0 Οι βασικές αρχές ανάπτυξης εφαρμογών για το Web 2.0 (Musser & O Reilly, 2007) δηλώνουν ρητά την ανάγκη για μια σχετικά ελαφριά και ταχεία διαδικασία ανάπτυξης. Σύμφωνα με αυτές τις αρχές, η ολοκληρωμένη εφαρμογή Παγκόσμιου Ιστού πρέπει να προσφέρεται στον τελικό χρήστη σα λογισμικό-υπηρεσία (Software as a Service - SaaS), δηλαδή σα μια ολοκληρωμένη εφαρμογή που τρέχει σε ένα web server αντί να 61

70 Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 εγκαθίσταται στον υπολογιστή του χρήστη. Με αυτό τον τρόπο, ο τελικός χρήστης δεν ενδιαφέρεται για τις λεπτομέρειες και τα συγκεκριμένα τεχνικά χαρακτηριστικά της σχετικής εφαρμογής Παγκόσμιου Ιστού, αλλά μόνο για τις δυνατότητες που του προσφέρει, την ευκολία και τον τρόπο χρήσης της. Επιπρόσθετα, αυτού του είδους το λογισμικό-υπηρεσία προσφέρει ευκολία πρόσβασης κάτω από οποιεσδήποτε συνθήκες, απλώς και μόνο μέσω ενός κοινού browser, καθώς και δυνατότητα άμεσης ενημέρωσης και αναβάθμισης λόγω του ότι οποιαδήποτε αλλαγή στο web server αντανακλάται άμεσα σε κάθε χρήστη, με αποτέλεσμα να γίνει μια αρκετά δημοφιλής τάση στις εφαρμογές Παγκόσμιου Ιστού. Επιπρόσθετα, στο Web 2.0 επιχειρείται μια αποστασιοποίηση από τον παραδοσιακό κύκλο ανάπτυξης και κυκλοφορίας (release cycle) λογισμικού. Προτείνεται πως οι σχετικές εφαρμογές Παγκόσμιου Ιστού θα πρέπει να θεωρούνται πως βρίσκονται σε ένα συνεχές δοκιμαστικό (Perpetual Beta) στάδιο. Οι προγραμματιστές αποθαρρύνονται από το να πακετάρουν τα νέα χαρακτηριστικά των εφαρμογών σε ενιαίες, μονολιθικές εκδόσεις, αλλά αντίθετα να τα ενσωματώνουν σε τακτά διαστήματα στην ίδια την εφαρμογή, σαν αναβάθμιση της υπηρεσίας που προσφέρεται στους χρήστες. Τέλος, προωθείται η εμπλοκή των τελικών χρηστών στη διαδικασία ελέγχου σε πραγματικό χρόνο της εφαρμογής, καθώς και η ύπαρξη σχετικής διαδικασίας ανατροφοδότησης προκειμένου να μπορεί να μελετηθεί ο τρόπος χρήσης της αντίστοιχης υπηρεσίας και να σχεδιαστούν νέες βελτιώσεις. Κάνοντας χρήση των παραπάνω αρχών, είχαμε τη δυνατότητα να αναπτύξουμε αρκετές εφαρμογές του Web 2.0, καταλήγοντας στη διαδικασία ανάπτυξης που φαίνεται στην Εικόνα

71 Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 Εικόνα 4.2: Διαδικασία Ανάπτυξης Εφαρμογών του Web 2.0 Η προσέγγισή μας βασίζεται στην πεποίθηση πως οι εφαρμογές του Web 2.0 πρέπει να αναπτυχθούν γρήγορα, έχοντας τα ελάχιστα δυνατά αρχικά στάδια σχεδιασμού, και πως η τελική εφαρμογή θα πρέπει να έχει τη δυνατότητα συνεχούς αναβάθμισης. Σε αυτό το πλαίσιο, τα πρώτα δυο βήματα της συγκεκριμένης διαδικασίας ανάπτυξης, η Ανάλυση Απαιτήσεων και ο Σχεδιασμός, θέτονται σε περιορισμένο χρονικό πλαίσιο, προκειμένου να οριοθετηθούν τα επιθυμητά χαρακτηριστικά της σχετικής εφαρμογής και να αρχίσει άμεσα η φάση ανάπτυξής της. Στη συνέχεια, υπάρχει μια αέναη επαναληπτική προσέγγιση για τα επόμενα βήματα, την Υλοποίηση, τον Έλεγχο και τη Συντήρηση, καθώς δεν αναμένεται ένα τελικό προϊόν, αλλά αντίθετα, η παρεχόμενη υπηρεσία μπορεί να θεωρηθεί ως η προβολή αυτών των τριών φάσεων στον τελικό χρήστη. Την ίδια στιγμή, κατά τη λειτουργία της εφαρμογής μπορούν να γίνουν διάφοροι πειραματισμοί και αλλαγές, προκειμένου να βελτιωθεί η λειτουργικότητα και η ευχρηστία της. Τέλος, όταν υπάρξει ανάγκη για την επέκταση της τρέχουσας εφαρμογής προκειμένου να συμπεριληφθούν κάποιες μη αναμενόμενες και ρηξικέλευθες λειτουργίες, θεωρούμε ως καλύτερη λύση τον ολικό ανασχεδιασμό της εφαρμογής και την επανέναρξη της όλης διαδικασίας ανάπτυξης από την αρχική φάση της Ανάλυσης Απαιτήσεων Διαδικασία Ανάπτυξης Εφαρμογών του Semantic Web Μια εφαρμογή του Semantic Web βασίζεται κατά κύριο λόγο σε δυο πολύ σημαντικά 63

72 Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 τμήματα, στις Οντολογίες και στη Διαδικασία Εξαγωγής Συμπερασμάτων (Reasoning). Άλλωστε, στον πυρήνα της αρχιτεκτονικής του Semantic Web (Berners-Lee et al., 2001), περιλαμβάνεται η διαδικασία εξαγωγής συμπερασμάτων, το κύριο συστατικό για την παραγωγή δεδομένων που δεν εκφράζονται ρητά σε μια οντολογία. Το γεγονός πως αυτά τα βασικά τμήματα μιας εφαρμογής του Semantic Web αποτελούν το σημαντικό διαφοροποιητικό στοιχείο σε σχέση με τις παραδοσιακές εφαρμογές Παγκόσμιου Ιστού, καθώς και η σημαντική επιρροή της βασικής διαδικασίας σχεδιασμού, ανάπτυξης και υποστήριξης μιας ολοκληρωμένης βάσης γνώσης (knowledge base) στη διαδικασία ανάπτυξης μιας εφαρμογής του Semantic Web, οδηγούν στο συμπέρασμα πως μια τέτοια εφαρμογή μπορεί να θεωρηθεί ότι αποτελείται από δυο βασικά μέρη: έναν οντολογικό πυρήνα, που περιλαμβάνει τη βάση γνώσης και το μηχανισμό εξαγωγής συμπερασμάτων, και ο οποίος μπορεί να αντιμετωπιστεί ως μια τυπική, αυτοδύναμη (stand-alone) εφαρμογή, και μια διεπαφή χρήστη, η οποία μπορεί να είναι οπουδήποτε είδους, καθώς δεν υπάρχουν σχετικές υποχρεωτικές προδιαγραφές. Από τα παραπάνω προκύπτει πως η ιδιαιτερότητα της ανάπτυξης μιας εφαρμογής του Semantic Web έγκειται κυρίως στην ανάπτυξη του κεντρικού οντολογικού τμήματος της. Σε ό,τι αφορά την ανάπτυξης οντολογιών, υπάρχουν αρκετές προσεγγίσεις, από τυπικές και ολοκληρωμένες μεθοδολογίες ανάπτυξης (Corcho et al., 2003) (TOVE, KACTUS, METHONTOLOGY, On-To-Knowledge, etc.), έως μια πιο απλή και διαισθητική (και αρκετά δημοφιλή) προσέγγιση (Noy & McGuinness, 2001), η οποία παρουσιάζει την όλη διαδικασία σα μια επαναληπτική προσέγγιση, που ξεκινάει με ένα πρόχειρο πέρασμα της οντολογίας και συνεχίζει αναθεωρώντας και φιλτράροντας την εξελισσόμενη οντολογία, συμπληρώνοντας παράλληλα τις σχετικές λεπτομέρειες. Με βάση όλα τα παραπάνω οδηγηθήκαμε σε μια ολοκληρωμένη διαδικασία ανάπτυξης οντολογιών, η οποία παρουσιάζεται στην Εικόνα

73 Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 Εικόνα 4.3: Διαδικασία Ανάπτυξης Οντολογιών Σε αυτήν την προσέγγιση, χειριζόμαστε την οντολογία σαν ένα αυτοδύναμο (stand-alone) προϊόν λογισμικού. Μια μέσης πολυπλοκότητας φάση Ανάλυσης Απαιτήσεων ακολουθείται από μια πολύ σημαντική φάση Σχεδιασμού, καθώς, εξαιτίας της ιδιαίτερης φύσης και πολυπλοκότητάς της, μια οντολογία απαιτεί την κατανάλωση πολύ χρόνου στη φάση Σχεδιασμού, κάνοντάς την την πιο απαιτητική φάση της όλης διαδικασίας. Στη συνέχεια, η φάση Υλοποίησης μπορεί να ολοκληρωθεί πολύ γρήγορα, εξαιτίας του ενδελεχή σχεδιασμού. Τέλος, στη φάση Ελέγχου/Συντήρησης, πιθανές μικροελλείψεις στην οντολογία μπορούν να οδηγήσουν τη διαδικασία πίσω στη φάση Σχεδιασμού, ενώ σημαντικότερα προβλήματα θα πρέπει να αντιμετωπιστούν με επανεκκίνηση της όλης διαδικασίας. 4.2 Ενοποιημένη Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 Παρότι οι προηγούμενες διαδικασίες ανάπτυξης εφαρμογών του Web 2.0 και του Semantic Web φαίνονται να προσεγγίζουν με διαφορετικό τρόπο την όλη διαδικασία, στην πραγματικότητα, λόγω και της αλληλοσυμπληρούμενης φύσης των βασικών χαρακτηριστικών τους, μπορούν να συνδυαστούν σε μεγάλο βαθμό προκειμένου να δώσουν λύσεις για τη διαδικασία ανάπτυξης των εφαρμογών του Web 3.0. Σε ό,τι αφορά την ανάπτυξη εφαρμογών για το Web 3.0, πρέπει να σημειωθεί πως δεν υπάρχει πρότερη καταγεγραμμένη εμπειρία και μεθοδολογία για την ολική αντιμετώπιση της 65

74 Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 όλης διαδικασίας, παρότι οι τεχνολογίες και οι μεθοδολογίες για τα επιμέρους συστατικά στοιχεία που προέρχονται από το Web 2.0 και το Semantic Web θεωρούνται αρκετά ώριμες και ολοκληρωμένες. Με βάση αυτό το σκεπτικό, αποφασίσαμε να κάνουμε χρήση της 3-tier αρχιτεκτονικής που περιγράφτηκε στο προηγούμενο κεφάλαιο, και να βασιστούμε στο υψηλό επίπεδο ανεξαρτησίας των βαθμίδων της, αντιμετωπίζοντας σε μεγάλο βαθμό κάθε συστατικό/βαθμίδα σα μια διακριτή εφαρμογή, σε ό,τι αφορά τη διαδικασία ανάπτυξής τους (Εικόνα 4.4). Εικόνα 4.4: Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 Η πρώτη φάση αυτής της προσέγγισης είναι μια κοινή φάση Ανάλυσης Απαιτήσεων, όπου καθορίζονται οι συγκεκριμένοι στόχοι και τα χαρακτηριστικά της τελικής εφαρμογής. Στη συνέχεια, στη φάση Σχεδιασμού Εφαρμογής, πραγματοποιείται ο αρχικός και θεμελιώδης σχεδιασμός της πλήρους εφαρμογής, όπου λαμβάνονται οι αποφάσεις για τη 66

75 Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 φυσική κατανομή των σχετικών τριών βαθμίδων της εφαρμογής, αλλά κυρίως για τα συγκεκριμένα πρωτόκολλα και εργαλεία που θα χρησιμοποιηθούν για τη διασύνδεσή τους. Μια βολική προσέγγιση είναι η χρήση της παραλλαγμένης, κατανεμημένης έκδοσης του OWL API, που παρουσιάστηκε στο προηγούμενο κεφάλαιο, για την επικοινωνία της χαμηλότερης με τη μεσαία βαθμίδα, και κάποιο δικτυακό πρωτόκολλο βασισμένο σε XML, όπως το PHP/Java Bridge, για την επικοινωνία της μεσαίας με την υψηλότερη βαθμίδα. Επιπρόσθετα, σε αυτή τη φάση παίρνονται οι αποφάσεις σχετικά με τα χαρακτηριστικά του Web 2.0 που μπορεί να επηρεάσουν όλες τις βαθμίδες της εφαρμογής, όπως η υιοθέτηση τεχνολογιών mash-up ή παροχή της δυνατότητας στους τελικούς χρήστες να επεμβαίνουν, όχι μόνο στην αποθηκευμένη πληροφορία, αλλά και στο ίδιο το οντολογικό σχήμα. Ακολούθως, η διαδικασία χωρίζεται σε τρεις κλάδους που εξυπηρετούν το σκοπό της ανάπτυξης των διακριτών τμημάτων της εφαρμογής που προορίζονται για κάθε βαθμίδα της, και μάλιστα, εξαιτίας αυτής της διακριτότητας, μπορούν να διεκπεραιωθούν σχεδόν παράλληλα: Για την ανάπτυξη του τμήματος της διεπαφής χρήστη: a) ανάλογα με τα αποτελέσματα της φάσης Σχεδιασμού Εφαρμογής, ο Σχεδιασμός Βαθμίδας περιλαμβάνει τις αποφάσεις για τα χαρακτηριστικά της διεπαφής χρήστη της εφαρμογής, όπως για παράδειγμα τη χρήση συγκεκριμένων προγραμματιστικών τεχνικών στην περίπτωση των mash-up, ή την ανάγκη για ανάπτυξη ειδικής διεπαφής προκειμένου να υλοποιηθεί ο επιθυμητός βαθμός αλληλεπίδρασης των τελικών χρηστών με την εφαρμογή, b) κατά τη φάση Υλοποίησης πραγματοποιείται η ανάπτυξη μιας πλούσιας διεπαφής χρήστη (πιθανόν σε AJAX) για την εφαρμογή, συνήθως με χρήση PHP ή JSP, και c) η επαναληπτική διαδικασία μεταξύ της τελευταίας φάσης και της φάσης Ελέγχου Βαθμίδας εξασφαλίζει πως έχουν εκπληρωθεί όλα τα προαπαιτούμενα για το συγκεκριμένο τμήμα της εφαρμογής, καθώς και ότι όλη η επικοινωνία με τη μεσαία βαθμίδα θα πραγματοποιείται μέσω του προαποφασισμένου πρωτοκόλλου διασύνδεσής τους. 67

76 Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 Προκειμένου να σχεδιαστεί και να υλοποιηθεί το σύστημα διαχείρισης της βάσης γνώσης της εφαρμογής: a) υπάρχει μια μάλλον χρονοβόρα φάση Σχεδιασμού Βαθμίδας, όπου σχεδιάζεται το κατάλληλο οντολογικό σχήμα για την εφαρμογή και το περιεχόμενό της, μια διαδικασία που από μόνη της μπορεί να είναι επαναληπτική σε υψηλό βαθμό, καθώς η παραγόμενη οντολογία θα αποτελέσει το θεμελιώδες στοιχείο όλης της βάσης γνώσης, b) η φάση Υλοποίησης ουσιαστικά περιλαμβάνει τη δόμηση και το γέμισμα της οντολογίας. Στην περίπτωση που η αντίστοιχη οντολογία έχει φτιαχτεί κατά την προηγούμενη φάση με χρήση κάποιου σχετικού εργαλείου όπως ο Protege Ontology Editor ( το μόνο που μένει για τη φάση Υλοποίησης είναι το γέμισμα της οντολογίας με δεδομένα και η τροφοδότησή της σε κάποιο συγκεκριμένο μηχανισμό εξαγωγής συμπερασμάτων, όπως για παράδειγμα ο Pellet ή ο FaCT++, και c) κατά τη φάση Ελέγχου Βαθμίδας βεβαιώνεται πως μπορεί να υπάρχει απρόσκοπτη συνεργασία με το εργαλείο διασύνδεσης που επιλέχθηκε κατά τη φάση Σχεδιασμού Εφαρμογής. Όσο για τη μεσαία βαθμίδα, οι διαδοχικές φάσεις Σχεδιασμού Βαθμίδας, Υλοποίησης και Ελέγχου Βαθμίδας ασχολούνται με την ανάπτυξη των συγκεκριμένων προγραμματιστικών τμημάτων (συνήθως σε Java) που θα υποστηρίζουν τα χαρακτηριστικά της λογικής της εφαρμογής, προσέχοντας να ικανοποιούν τις απαιτήσεις διασύνδεσης των βαθμίδων. Τέλος, η ολοκληρωμένη τελική εφαρμογή δοκιμάζεται στη φάση Ελέγχου Εφαρμογής/Συντήρησης με βάση συγκεκριμένα σενάρια ελέγχου και ενδεικτικά παραδείγματα χρήσης, κάνοντας πιθανές προσαρμογές όπου απαιτείται, προκειμένου να παραδοθεί στους τελικούς χρήστες ένα πιο ολοκληρωμένο και αξιόπιστο τελικό προϊόν. Πρέπει να σημειωθεί πως στην περίπτωση που εντοπιστεί κάποια κρίσιμη έλλειψη ή σφάλμα της εφαρμογής κατά τη διάρκεια των φάσεων ελέγχου, η διαδικασία είτε επιστρέφει 68

77 Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 στην αντίστοιχη φάση Σχεδιασμού Βαθμίδας, αν το πρόβλημα παρατηρηθεί σε κάποια φάση Ελέγχου Βαθμίδας, είτε οδηγείται σε επανεκκίνηση, αν το πρόβλημα παρατηρηθεί στην τελική φάση Ελέγχου Εφαρμογής/Συντήρησης. 4.3 Διαχείριση Ομάδας Ανάπτυξης Εφαρμογών του Web 3.0 Ένα μεγάλο πλεονέκτημα της παραπάνω μεθοδολογίας ανάπτυξης, κυρίως λόγω της παράλληλης ανάπτυξης των τμημάτων της εφαρμογής που αντιστοιχούν στις ξεχωριστές βαθμίδες της, αφορά σε θέματα διαχείρισης ομάδας ανάπτυξης έργου που αφορά εφαρμογές του Web 3.0. Παρατηρήσαμε πως τα διάφορα τμήματα/βαθμίδες είχαν διαφορετικές απαιτήσεις σε χρόνο και εμπλεκόμενα άτομα, σε κάθε φάση τους. Ενώ η επιμέρους διαδικασία ανάπτυξης της διεπαφής χρήστη περιλαμβάνει μια μικρού φόρτου φάση Σχεδιασμού Βαθμίδας και έναν απαιτητικό κύκλο φάσεων Υλοποίησης και Ελέγχου Βαθμίδας, η αντίστοιχη διαδικασία ανάπτυξης του συστήματος βάσης γνώσης αποτελείται από μια χρονοβόρα και απαιτητική φάση Σχεδιασμού Βαθμίδας και δυο τετριμμένες και μικρού φόρτου φάσεις Υλοποίησης και Ελέγχου Βαθμίδας. Επιπρόσθετα, το τμήμα της λογικής της εφαρμογής έχει πολύ μικρές απαιτήσεις στις φάσεις Σχεδιασμού Βαθμίδας και Ελέγχου Βαθμίδας, καθώς παρατηρείται υψηλός βαθμός συσχέτισης και αλληλοκάλυψης με τις αντίστοιχες φάσης της πλήρους εφαρμογής, και κάπως περισσότερες, αλλά επίσης λίγες σε σχέση με άλλες φάσεις, απαιτήσεις στη φάση Υλοποίησης. Όλα τα παραπάνω, για ένα γενικό έργο Web 3.0, συνοψίζονται προσεγγιστικά στην Εικόνα 4.5, όπου πρέπει να σημειωθεί πως τα μεγέθη είναι ενδεικτικά δεν αντιπροσωπεύουν απόλυτες τιμές, αλλά παρουσιάζονται αναλογικά με το συνολικό μέγεθος του σχετικού έργου. 69

78 Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 Εικόνα 4.5: Απαιτήσεις Έργου για Εφαρμογές του Web 3.0 Σαν αποτέλεσμα, με κατάλληλο χρονοπρογραμματισμό και κατανομή των μελών της ομάδας έργου (Εικόνα 4.6), η εφαρμογή της συγκεκριμένης μεθοδολογίας μπορεί να οδηγήσει σε μείωση του συνολικού χρόνου, των απαιτούμενων ανθρωπομηνών και επομένως και του συνολικού κόστους ενός τέτοιου έργου. 70

79 Διαδικασία Ανάπτυξης Εφαρμογών του Web 3.0 Εικόνα 4.6: Διάγραμμα Έργου Web 3.0 Εφαρμόζοντάς τη συγκεκριμένη μεθοδολογία σε ένα πλήθος έργων μικρής έως μεσαίας κλίμακας (μέχρι 25 μέλη ομάδας), παρατηρήσαμε μια μείωση του συνολικού απαιτούμενου χρόνου που έφτανε το 10% καθώς και μικρότερες απαιτήσεις για μέγεθος ομάδας έργου κατά 25%, σε σύγκριση πάντα με τους αρχικούς υπολογισμούς μας. 71