«Συνδυασμός τεχνολογιών Υπηρεσιών Διαδικτύου και Κινητών Πρακτόρων στο Σημασιολογικό ιστό»

Transcript

1 ΕΘΝΙΚΟ ΚΑΙ ΚΑΠΟΔΙΣΤΡΙΑΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΚΑΙ ΤΗΛΕΠΙΚΟΙΝΩΝΙΩΝ ΠΤΥΧΙΑΚΗ ΕΡΓΑΣΙΑ «Συνδυασμός τεχνολογιών Υπηρεσιών Διαδικτύου και Κινητών Πρακτόρων στο Σημασιολογικό ιστό» Web Services and Mobile Agents Integration; A Semantic Approach Ηλίας Ν. Ζαβιτσάνος Επιβλέπων: Ευστάθιος Χατζηευθυμιάδης, Καθηγητής ΕΚΠΑ

2 ΑΘΗΝΑ ΙΑΝΟΥΑΡΙΟΣ 2006 ΕΘΝΙΚΟ ΚΑΙ ΚΑΠΟΔΙΣΤΡΙΑΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΚΑΙ ΤΗΛΕΠΙΚΟΙΝΩΝΙΩΝ ΠΤΥΧΙΑΚΗ ΕΡΓΑΣΙΑ «Συνδυασμός τεχνολογιών Υπηρεσιών Διαδικτύου και Κινητών Πρακτόρων στο Σημασιολογικό ιστό» Web Services and Mobile Agents Integration; A Semantic Approach Ηλίας Ν. Ζαβιτσάνος 2

3 Επιβλέπων: Ευστάθιος Χατζηευθυμιάδης, Καθηγητής ΕΚΠΑ ΑΘΗΝΑ ΙΑΝΟΥΑΡΙΟΣ 2006 ΠΤΥΧΙΑΚΗ ΕΡΓΑΣΙΑ Συνδυασμός τεχνολογιών Υπηρεσιών Διαδικτύου και Κινητών Πρακτόρων στο Σημασιολογικό ιστό. Ηλίας Ν. Ζαβιτσάνος Α.Μ.: ΕΠΙΒΛΕΠΟΝΤΕΣ: Ευστάθιος Χατζηευθυμιάδης, Καθηγητής ΕΚΠΑ Βασίλειος Μπαούσης, Υποψήφιος Διδάκτορας ΕΚΠΑ 3

4 4

5 Ευχαριστίες Καταρχάς, θα θέλαμε να εκφράσουμε τις ευχαριστίες μας στον υποψήφιο διδάκτορα του τμήματός μας και επιβλέποντα της πτυχιακής μας εργασίας, κ. Βασίλειο Μπαούση, για τον καθοδηγητικό του ρόλο σε όλη τη διάρκεια της έρευνας, καθώς και της υλοποίησης, αφού συνέβαλε στα μέγιστα για την επιτυχή έκβαση της όλης προσπάθειας. Τέλος, ευχαριστούμε θερμά τον επιβλέποντα καθηγητή μας κ. Ευστάθιο Χατζηευθυμιάδη, ο οποίος πέρα από τις τελικές κατευθύνσεις για την ολοκλήρωση της εργασίας μας, μας έδωσε την ευκαιρία να εργασθούμε πάνω σε ένα θέμα με αρκετά μεγάλο ερευνητικό έδαφος και πολλές προοπτικές για περαιτέρω εκμετάλλευση. i

6 Πίνακας Περιεχομένων ΕΘΝΙΚΟ ΚΑΙ ΚΑΠΟΔΙΣΤΡΙΑΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ...1 ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ...1 ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΚΑΙ ΤΗΛΕΠΙΚΟΙΝΩΝΙΩΝ...1 ΕΘΝΙΚΟ ΚΑΙ ΚΑΠΟΔΙΣΤΡΙΑΚΟ ΠΑΝΕΠΙΣΤΗΜΙΟ ΑΘΗΝΩΝ...2 ΣΧΟΛΗ ΘΕΤΙΚΩΝ ΕΠΙΣΤΗΜΩΝ...2 ΤΜΗΜΑ ΠΛΗΡΟΦΟΡΙΚΗΣ ΚΑΙ ΤΗΛΕΠΙΚΟΙΝΩΝΙΩΝ...2 ΠΤΥΧΙΑΚΗ ΕΡΓΑΣΙΑ...3 Συνδυασμός τεχνολογιών Υπηρεσιών Διαδικτύου και Κινητών Πρακτόρων στο Σημασιολογικό ιστό...3 Ευχαριστίες...i Πίνακας Περιεχομένων...ii Πίνακας Σχημάτων...iv 1 Εισαγωγή Κεφάλαιο: Τεχνολογία Κινητών Πρακτόρων Εισαγωγή Πλατφόρμες Υποστήριξης Κινητών Πρακτόρων Grasshopper Agent Platform Κατανεμημένο Περιβάλλον Κινητών Πρακτόρων Επικοινωνία Διευθυνσιοδότηση Ασφάλεια Κεφάλαιο : Υπηρεσίες Διαδικτύου Εισαγωγή Υπηρεσιοκεντρική Αρχιτεκτονική (Service Oriented Architecture SOA) Service Oriented Architecture και «Υπηρεσίες Διαδικτύου» Πρωτόκολλο SOAP Γλώσσα Περιγραφής Υπηρεσιών Διαδικτύου WSDL Universal Description, Discovery and Integration (UDDI) Το μοντέλο χρήσης του UDDI Προγραμματιστική διεπαφή του UDDI Γενική περιγραφή Κεφάλαιο Σημασιολογικός Ιστός (Semantic Web) Εισαγωγή Παγκόσμιος ιστός και Σημασιολογικός Ιστός Σημασιολογικές Υπηρεσίες Διαδικτύου Γλώσσα Οντολογιών Ιστού (Web Ontology Language-OWL-S) Κεφάλαιο: Συνδυασμός Τεχνολογιών Κινητών Πρακτόρων και Υπηρεσιών Διαδικτύου Εισαγωγή Ερευνητικές Τάσεις Κεφάλαιο:Αρχιτεκτονική Πλατφόρμας Εισαγωγή Συστατικά Συστήματος Περιγραφή της Υπηρεσίας Περιγραφή Λειτουργικότητας Πλατφόρμας...71 ii

7 6.4.1 Αφαιρετικού Επιπέδου Επιπέδου Υλοποίησης Κεφάλαιο : Αξιολόγηση των Επιδόσεων της Πλατφόρμας Εισαγωγή Αξιολόγηση χρόνων Αξιολόγηση ανάλωσης πόρων Κεφάλαιο: Συμπεράσματα Μελλοντικές Εργασίες...98 A. Οδηγίες εγκατάστασης και εκτέλεσης Α.1 Οδηγίες εγκατάστασης Α.2 Οδηγίες εκτέλεσης B. Εργαλεία που χρησιμοποιήθηκαν B.1 Γλώσσα Προγραμματισμού Java B.2 Eclipse IDE B.3 Apache Tomcat B.4 Apache AXIS B.5 JUDDI B.7 Σχεσιακή βάση δεδομένων MySQL B.8 Σχεσιακή βάση δεδομένων HSQLDB B.9 Matchmaker B.10 JProfiler και OptimizeIt Γ. Αναφορές iii

8 Πίνακας Σχημάτων Σχήμα 1. Ιεραρχική Δομή Συστατικών...10 Σχήμα 2. Επικοινωνία δια μέσου πρωτοκόλλων...15 Σχήμα 3. Επικοινωνία ανεξάρτητη της τοποθεσίας...16 Σχήμα 4. Σύγχρονη επικοινωνία...17 Σχήμα 5. Ασύγχρονη επικοινωνία...18 Σχήμα 6. Παράλληλη επικοινωνία...19 Σχήμα 7. OR Termination...19 Σχήμα 8. AND Termination...20 Σχήμα 9. Incremental Termination...20 Σχήμα 10. Αρχιτεκτονική γύρω από την υπηρεσία...24 Σχήμα 11. Μοντέλο πληροφορίας του UDDI...38 Σχήμα 12. Αρχιτεκτονική του Σημασιολογικού Ιστού...43 Σχήμα 13. Φάσεις Ωριμότητας Υπηρεσιών Διαδικτύου...46 Σχήμα 14. Γενική Αρχιτεκτονική Πλατφόρμας...56 Σχήμα 15. Αρχική σελίδα διαδικτυακής εφαρμογής και επιλογή των πολιτικών του κινητού πράκτορα...57 Σχήμα 16. Δομή του κινητού πράκτορα...58 Σχήμα 17. Υπηρεσία διαχείρισης πολιτικών του κινητού πράκτορα Σχήμα 18. Διάγραμμα κλάσεων του Κινητού Πράκτορα (ΜΑ)...60 Σχήμα 19. Δομή αρχείου policies.xml...61 Σχήμα 20. Δομή και λογική του PSA...63 Σχήμα 21. Σημασιολογικός κατάλογος υπηρεσιών...65 Σχήμα 22. Διάγραμμα κλάσεων του Σημασιολογικού Καταλόγου Υπηρεσιών, με τον Στάσιμο Πράκτορα Καταλόγου...66 Σχήμα 23. Παροχέας των υπηρεσιών διαδικτύου...66 Σχήμα 24. Διάγραμμα κλάσεων του Παροχέα Υπηρεσιών...67 Σχήμα 25. Μέρος της OWL-S περιγραφής της υπηρεσίας διαδικτύου...69 Σχήμα 26. Μέρος της OWL-S περιγραφής της υπηρεσίας Είσοδοι/ Έξοδοι...69 Σχήμα 27. Μέρος της OWL-S περιγραφής της υπηρεσίας Λεκτική περιγραφή και πληροφορίες παροχέα...70 Σχήμα 28. Μέρος των οντολογιών της υπηρεσίας διαδικτύου...71 Σχήμα 29. Use case Σχήμα 30. Use case Σχήμα 31. Use case Σχήμα 32. Διάγραμμα Ακολουθίας tracemobileagent...75 Σχήμα 33. Διάγραμμα ακολουθίας cancelagentexecution...76 Σχήμα 34. Διάγραμμα Ακολουθίας getbackhome...76 Σχήμα 35. Διάγραμμα Ακολουθίας Απευθείας Κλήση Υπηρεσίας με RPC...77 Σχήμα 36. Διάγραμμα Ακολουθίας Κλήση Υπηρεσίας μέσω Στάσιμου Πράκτορα...78 Σχήμα 37. Διάγραμμα Ακολουθίας Αποστολή μηνύματος στον ΜΑ...79 iv

9 Σχήμα 38. Διάγραμμα Ακολουθίας Επερώτηση βάση Αλφαριθμητικού...80 Σχήμα 39. Διάγραμμα Ακολουθίας Επερώτηση βάση οντολογιών...81 Σχήμα 40. Διάγραμμα ακολουθίας Κλήση Υπηρεσίας μέσω Στάσιμου Πράκτορα...82 Σχήμα 41. Διάγραμμα ακολουθίας Απευθείας Κλήση Υπηρεσίας.82 Σχήμα 42. Τοπολογία δικτύου αξιολόγησης πλατφόρμας...85 Σχήμα 43. Μέσοι χρόνοι μετακίνησης 1ΚΒ υπηρεσία...87 Σχήμα 44. Μέσοι χρόνοι μετακίνησης 10ΚΒ υπηρεσία...87 Σχήμα 45. Μέσοι χρόνοι μετακίνησης 100ΚΒ υπηρεσία...88 Σχήμα 46. Μέσοι χρόνοι μετακίνησης 1ΜΒ υπηρεσία...88 Σχήμα 47. Μέσοι χρόνοι μετακίνησης συναρτήσει του όγκου των δεδομένων...89 Σχήμα 48. Μέσο ITSP υπηρεσίας 1ΜΒ...90 Σχήμα 49. Μέσο ITSP υπηρεσίας 100ΚΒ...91 Σχήμα 50. Μέσο ITSP υπηρεσίας 10ΚΒ...91 Σχήμα 51. Μέσο ITSP υπηρεσίας 1ΚΒ...92 Σχήμα 52. Μέσο ITSP υπηρεσιών...93 Σχήμα 53. Συνολικός χρόνος TST...94 Σχήμα 54. Πλήθος αντικειμένων στη μνήμη σε σύστημα SOAP/RPC...95 Σχήμα 55. Απαιτούμενη μνήμη για κλήση υπηρεσίας σε σύστημα SOAP/RPC...95 Σχήμα 56. Πλήθος αντικειμένων στη μνήμη για σύστημα με πράκτορες...96 Σχήμα 57. Σύγκριση των δύο συστημάτων...97 v

10

11 1Εισαγωγή Είναι γεγονός ότι τα τελευταία χρόνια έχει παρατηρηθεί μια τάση στον επιστημονικό χώρο της πληροφορικής και συγκεκριμένα στον τομέα των «Υπηρεσιών Διαδικτύου» (Web Services), για εμπλουτισμό της ήδη χρησιμοποιηθείσας αρχιτεκτονικής με επιπρόσθετες τεχνολογίες. Αυτές επικεντρώνονται κατά κύριο λόγο στην προσθήκη χαρακτηριστικών κινητικότητας, αυτονομίας και αντιπροσώπευσης του ήδη διαμορφωθέν μοντέλου των «Υπηρεσιών Διαδικτύου». Συγκεκριμένα στην εποχή μας η ικανότητα πρόσβασης σε υπηρεσίες και η ανάκτηση πληροφοριών οπουδήποτε και οποτεδήποτε, ανεξαρτήτως του δικτύου και του τερματικού μας, είναι επιτακτική ώστε να ικανοποιηθούν οι απαιτήσεις των χρηστών. Ωστόσο, οι περισσότερες από τις υπηρεσίες οι οποίες είναι διαθέσιμες στο δίκτυο είναι σχεδιασμένες για να είναι προσβάσιμες από επιτραπέζιους υπολογιστές, με μία σταθερή και απαλλαγμένη από λάθη σύνδεση στο δίκτυο. Η κύρια επιδίωξη των περισσότερων ερευνητών είναι η επέκταση των υπαρχόντων υπηρεσιών και εφαρμογών, οι οποίες είναι σχεδιασμένες για σταθερά δίκτυα σε κινητούς χρήστες με ένα διαφανή τρόπο. Αυτό το έργο είναι αρκετά δύσκολο αν λάβουμε υπόψιν μας τα προβλήματα τα οποία παρουσιάζονται όταν χρησιμοποιούμε μικρές συσκευές για να προσπελάσουμε τέτοιες υπηρεσίες. Σε ασύρματα περιβάλλοντα αυτού του είδους, παρουσιάζονται αρκετά προβλήματα όπως λιγοστό εύρος ζώνης, προσωρινές διακοπές της σύνδεσης στο δίκτυο, μεγάλη καθυστέρηση, λιγοστή διάρκεια της πηγής τροφοδοσίας και περιορισμένες δυνατότητες επεξεργασίας στην κινητή συσκευή είναι μερικές από αυτές. Οι υπηρεσίες ιστού είναι σχεδιασμένες για σταθερά δίκτυα. Παρέχουν μία δομή για την περιγραφή των υπηρεσιών, την ανακάλυψη και εκτέλεση τους. Στο παραδοσιακό μοντέλο των υπηρεσιών δικτύου, ο αιτών της υπηρεσίας βρίσκει την κατάλληλη υπηρεσία ζητώντας την από μία κατάλληλη οντότητα υπηρεσίας καταλόγου, συχνά υλοποιημένη με UDDI (Universal Description, Discovery and Integration), παίρνει τα αποτελέσματα δημόσιες διεπαφές των επιλεγμένων υπηρεσιών και τελικά στέλνει SOAP μηνύματα με τα κατάλληλα ορίσματα στους επιθυμητούς παρόχους της υπηρεσίας ιστού. Τα κύρια προβλήματα τα οποία συναντώνται σε αυτές τις δοσοληψίες είναι: Η ανακάλυψη των υπηρεσιών στο UDDI είναι κατά βάση σύμφωνα με το όνομα της υπηρεσίας, όχι με βάση των χαρακτηριστικών/ δυνατοτήτων της υπηρεσίας. 1

12 Η WSDL είναι μία γλώσσα βασισμένη στην ΧΜL η οποία χρησιμοποιείται για να καθορίσει τη διεπαφή μίας υπηρεσίας ιστού. Δυστυχώς όμως η WSDL δεν περιέχει καμία πληροφορία σχετικά με τις δυνατότητες των περιγραφέντων υπηρεσιών. Η απόδοση των SOAP μηνυμάτων είναι συχνά μεγαλύτερη από τις παραμέτρους/ αποτελέσματα τα οποία ανταλλάσσονται μεταξύ των επικοινωνούντων μερών. Πολλές προσπάθειες έχουν γίνει για την ενδυνάμωση της εκφραστικότητας της WSDL στα πλαίσια της σημασιολογικής περιγραφής το οποίο αφορά την ερευνητική περιοχή του σημασιολογικού δικτύου. Το τελευταίο είναι ένα όραμα στο οποίο οι δικτυακές σελίδες εμπλουτίζονται με πληροφορίες και δεδομένα τα οποία εκφράζονται με ένα σαφή τρόπο και μπορούν να κατανοηθούν και ερμηνευτούν από εφαρμογές που τρέχουν σε υπολογιστές με τον ίδιο τρόπο όπως και με το ανθρώπινο πρότυπο. Η OWL-S (Web Ontology Language) είναι μία σημασιολογική γλώσσα περιγραφής για τον καθορισμό και την δημιουργία δικτυακών Οντολογιών. Μία οντότητα ΟWL-S καθορίζει άμεσα τους τύπους των μηνυμάτων (σαν τύπους εισόδου/ εξόδου των διαδικασιών) στο πλαίσιο των OWL-S κλάσεων, οι οποίες επιτρέπουν ένα πλουσιότερο, ιεραρχημένο σύμφωνα με τις κλάσεις σημασιολογικό οικοδόμημα. Με την OWL-S οι υπηρεσίες δικτύου περιγράφονται με ένα σαφή τρόπο επιτρέποντας για ένα υποθετικό αιτών μίας υπηρεσίας να θέσει αναζητήσεις με βάση ικανότητες, στον κατάλογο υπηρεσίας, παρά να βασιστεί σε μία αναζήτηση σύμφωνα με λεξιλογικά κριτήρια (όπως γίνεται στο UDDI μοντέλο). Εν γένει, η επέκταση του κλασικού μοντέλου του διαδικτύου έγκειται στην προσπάθεια περιγραφής όλων των υπηρεσιών που παρέχονται σε αυτό με ένα πιο «σημασιολογικό» τρόπο, ο οποίος θα είναι κατανοητός από τις υπολογιστικές μηχανές. Το δίκτυο αυτό χαρακτηρίζεται ως «Σημασιολογικός Ιστός» (Semantic Web). Τέλος, ένας επιπλέον εκπρόσωπος αυτών των προσπαθειών για τη βελτίωση των αδυναμιών του παραδοσιακού επιχειρησιακού μοντέλου, αποτελεί η τεχνολογία των «Κινητών Πρακτόρων» (Mobile Agents). Οι κινητοί πράκτορες χαρακτηρίζονται από δυνατότητες κινητικότητας, αυτονομίας, αντιπροσώπευσης, κλπ, όπου σε συνδυασμό με το ήδη υπάρχον μοντέλο παρέχουν μία επέκταση με θετικά αποτελέσματα για τη μεριά του χρήστη. Σε αυτή την εργασία προτείνουμε την ολοκλήρωση της τεχνολογίας των κινητών πρακτόρων με την τεχνολογία των υπηρεσιών διαδικτύου, οι οποίες περιγράφονται σε OWL-S. Ένας κινητός πράκτορας έχει την μοναδική ικανότητα να μεταφέρεται από ένα 2

13 σύστημα σε ένα άλλο. Η ικανότητα μεταφοράς επιτρέπει σε έναν κινητό πράκτορα να μετακινείται σε ένα σύστημα το οποίο περιέχει μία οντότητα με την οποία ο πράκτορας επιθυμεί να αλληλεπιδράσει και έτσι επωφελείται από το να είναι στον ίδιο εξυπηρέτη ή δίκτυο όπως η συνεργαζόμενη οντότητα. Υπάρχουν πολλοί καλοί λόγοι για να χαρακτηρίσουμε την τεχνολογία των ΜΑ σαν μία από τις πιο πολλά υποσχόμενες τεχνολογίες για την επικοινωνία και την διαχείριση λειτουργικών συστατικών. Από την άλλη μεριά αρκετά μειονεκτήματα των ΜΑ, τα καθιστούν ως το ποίο αμφιλεγόμενο παράδειγμα κινητού κώδικα στο τομέα του κινητού υπολογισμού. Εντούτοις, οι πράκτορες δεν προσπαθούν να αντικαταστήσουν το κλασσικό τρόπο της επικοινωνίας αλλά να βελτιώσουν την λειτουργικότητα των κληθέντων οντοτήτων υπηρεσιών. Οι περισσότεροι ερευνητές συμφωνούν στο γεγονός ότι η τεχνολογία των ΜΑ δεν είναι πάντα η καλύτερη υιοθετηθείσα λύση και ένας συνδυασμός των ΜΑ, εξυπηρέτη-εξυπηρετούμενου και της απομακρυσμένης εκτέλεσης, παράγει τα καλύτερα αποτελέσματα. Προτού όμως αναλύσουμε διεξοδικά τον τρόπο με τον οποίο μπορούν όλα τα παραπάνω να συνδυαστούν αρμονικά για την παροχή χρήσιμων υπηρεσιών σε όλους τους τελικούς χρήστες, θα πρέπει να διατυπώσουμε τους ορισμούς των «Υπηρεσιών Διαδικτύου», «Κινητών Πρακτόρων» και «Σημασιολογικού Ιστού» και να αναλύσουμε τις τεχνολογίες αυτές. 3

14 2Κεφάλαιο: Τεχνολογία Κινητών Πρακτόρων 2.1Εισαγωγή Οι κινητοί πράκτορες (Mobile Agents) είναι μια τεχνολογία, η οποία αναπτύχθηκε τα τελευταία χρόνια βασιζόμενη στην ιδέα της κινητικότητας του κώδικα στο δίκτυο, και της αντιπροσώπευσης σε αυτό. Οι κινητοί πράκτορες χρησιμοποιούνται κυρίως σε κατανεμημένες εφαρμογές πάνω σε μεγάλης κλίμακας επισφαλή δίκτυα. Αυτό οφείλεται στο ότι επιτρέπουν την εξοικονόμηση του επικοινωνιακού κόστους, με το να μεταφέρουν τη λογική στα δεδομένα, αποτρέποντας τη μεταφορά τους στο δίκτυο. Ένας τυπικός ορισμός των κινητών πρακτόρων είναι ο ακόλουθος: «Ένας κινητός πράκτορας είναι μια οντότητα λογισμικού, η οποία εκτελεί κάποιες διεργασίες, εκ μέρους είτε του ιδιοκτήτη του, είτε του χρήστη του, είτε μιας άλλης οντότητας λογισμικού, η οποία τον έχει προγραμματίσει να πραγματοποιήσει αυτή τη δράση. Κύριο χαρακτηριστικό αυτής της οντότητας είναι η κινητικότητα διαμέσου του δικτύου, αλλά και ένας βαθμός αυτονομίας κατά την εκτέλεση του ανατιθέμενου σε εαυτή έργου. Μετά τη δημιουργία της σε ένα εκτελέσιμο περιβάλλον, μπορεί να μεταφέρει την κατάσταση εκτέλεσής της, όπως και τον κώδικα, μαζί της σε κάποιο άλλο περιβάλλον ή κόμβο του δικτύου και ξαναρχίζει από το σημείο που διέκοψε την εκτέλεσή της.» Τα κύρια χαρακτηριστικά, τα οποία διέπουν τους κινητούς πράκτορες είναι τα ακόλουθα: Αυτονομία Συνεργασία Ευελιξία Επικοινωνία Κινητικότητα Δυνατότητα μάθησης Εκπροσώπευση Επικέντρωση σε κάποιο σκοπό Σχεδιασμός Η τεχνολογία αυτή έχει πληθώρα πλεονεκτημάτων. Συγκεκριμένα: Ελάττωση του φόρτου του δικτύου. Ασύγχρονη και αυτόνομη εκτέλεση του έργου. Δυναμική προσαρμογή στο τρέχον περιβάλλον. Προσαρμογή σε τυχόν σφάλματα κατά τη διάρκεια ζωής του πράκτορα. Βελτιστοποίηση του φόρτου του δικτύου. 4

15 Ανεξαρτησία του πράκτορα από τον εκπρόσωπό του, αφού ο τελευταίος δεν είναι απαραίτητο να βρίσκεται εντός του δικτύου κατά τη διάρκεια εκτέλεσης της επιθυμίας του. Ταυτόχρονα όμως διέπεται και από μειονεκτήματα: Αρκετά προβλήματα ασφάλειας είναι ακόμα ανοιχτά. Ο χρόνος μετανάστευσης είναι μεγαλύτερος από αυτόν μιας απομακρυσμένης κλήσης. Δεν είναι εμπορικά διαδεδομένη τεχνολογία. Υπάρχουν πολλές πλατφόρμες που υλοποιούν τη λειτουργικότητα των κινητών πρακτόρων, οι οποίες δεν είναι συμβατές μεταξύ τους. Οι στρατηγικές οι οποίες χρησιμοποιούνται σε ότι αφορά στη «μετανάστευση» (migration) των κινητών πρακτόρων χωρίζονται σε δύο κατηγορίες: Την ισχυρή μετανάστευση (Strong migration) Την ασθενή μετανάστευση (Weak migration) Στη μεν ισχυρή μετανάστευση, ο πράκτορας μετακινείται σε κάποιον άλλο κόμβο του δικτύου μαζί με όλη την κατάσταση της εκτέλεσής του (execution state). Εν αντιθέσει, στην ασθενή μετανάστευση, ο πράκτορας μετακινείται από τη μία τοποθεσία στην άλλη διατηρώντας την κατάσταση συγκεκριμένων μεταβλητών του κώδικά του. Εκτός από τους «Κινητούς Πράκτορες», υπάρχει και άλλη μία κατηγορία Πρακτόρων με στατικό ρόλο, οι οποίοι ονομάζονται «Στάσιμοι Πράκτορες» (Stationary Agents). Οι «Στάσιμοι Πράκτορες» δε μετακινούνται από το σύστημα στο οποίο ξεκινά η εκτέλεση τους. Αν ο «Στάσιμος Πράκτορας» χρειάζεται πληροφορίες οι οποίες δεν παρέχονται από αυτό το σύστημα ή δημιουργείται η ανάγκη για επικοινωνία με ένα άλλο «Πράκτορα» ο οποίος βρίσκεται σε διαφορετικό σύστημα, συνήθως χρησιμοποιούνται μηχανισμοί επικοινωνίας όπως «Απομακρυσμένες Διαδικασίες Κλήσης» (Remote Procedure Calls RPC) ή «Απομακρυσμένες Μέθοδοι Κλήσης» (Remote Method Invocation RMI). 2.2 Πλατφόρμες Υποστήριξης Κινητών Πρακτόρων Όπως έχει αναφερθεί ήδη, ένας κινητός πράκτορας έχει τη δυνατότητα να μετακινείται από κόμβο σε κόμβο του δικτύου και να επιτελεί μια συγκεκριμένη εργασία. Προκειμένου να επιτευχθεί αυτό, είναι αναγκαίο να υπάρχει εγκατεστημένη μία πλατφόρμα σε κάθε τέτοιο κόμβο, που να μπορεί να δέχεται τον κινητό πράκτορα και να του παρέχει όλη την απαραίτητη λειτουργικότητα για την εκτέλεσή του. Πολλές πλατφόρμες έχουν αναπτυχθεί για το σκοπό 5

16 αυτό, από τις οποίες οι περισσότερες είναι υλοποιημένες σε γλώσσα προγραμματισμού Java. Είναι προφανές πως μεταξύ των διαφορετικών αυτών συστημάτων, υπάρχουν μεγάλες διαφορές τόσο στην αρχιτεκτονική όσο και στην υλοποίηση. Έτσι, προέκυψε η ανάγκη για τυποποίηση, ώστε να είναι δυνατή η επικοινωνία μεταξύ τους. Για την τεχνολογία των κινητών πρακτόρων υπάρχουν δύο κύριες προδιαγραφές: MASIF (OMG) Mobile Agent System Interoperability Facility. FIPA Foundation for Intelligent Physical Agents (με το FIPA 2000 να προσπαθεί να υλοποιήσει την αλληλεπίδραση μεταξύ FIPA και MASIF). Στην παράγραφο αυτή θα δούμε μερικές από τις γνωστότερες πλατφόρμες που έχουν αναπτυχθεί γύρω από την τεχνολογία των κινητών πρακτόρων. Aglets (IBM) Η πλατφόρμα αυτή είναι μία από τις πρώτες πλατφόρμες για κινητούς πράκτορες, η οποία είναι υλοποιημένη σε Java. Σκοπός της είναι η παροχή ενός μοντέλου για κινητούς πράκτορες παρόμοιο με αυτό των Java Applets (εξού και η ομοιότητα στο όνομα). Η πρώτη έκδοση της πλατφόρμας ήταν τον Ιούλιο του 1996, κάτι που οδηγεί στο συμπέρασμα ότι η ιδέα των κινητών πρακτόρων ξεκίνησε μερικά χρόνια πριν για να ωριμάσει λίγα χρόνια μετά και κυρίως στη σημερινή εποχή. ARA (University of Kaiserslautern) Η Ara είναι μια πολυγλωσσική πλατφόρμα κινητών πρακτόρων. Η αρχιτεκτονική της αποτελείται από ένα πυρήνα (ο οποίος αποτελεί το κυρίως σύστημα), μέσα στον οποίο μπορούν να περιέχονται διαφορετικοί μεταγλωττιστές γλωσσών προγραμματισμού. Με τον τρόπο αυτό είναι δυνατή η αλληλεπίδραση με πράκτορες υλοποιημένους σε διαφορετικές γλώσσες προγραμματισμού. Επιπρόσθετα, η πλατφόρμα παρέχει βασικές λειτουργίες ασφάλειας. Με τη βοήθεια γλωσσών προγραμματισμών χαμηλού επιπέδου, όπως η C, είναι δυνατή η ανάκτηση της κατάστασης εκτέλεσης (execution state) του πράκτορα, κάτι που καθιστά την πλατφόρμα ικανή να υποστηρίζει την «ισχυρή μετανάστευση» (strong migration). Concordia (Mitsubishi Electric ITA) Η συγκεκριμένη πλατφόρμα της Mitsubishi, δίνει έμφαση σε πέντε διαφορετικές οντότητες (modules) που αποτελούν και τη συνολική αρχιτεκτονική της πλατφόρμας. Οι οντότητες αυτές είναι: o Event Manager Αναλαμβάνει την καταχώρηση, την αποστολή και τα μηνύματα που αφορούν στους κινητούς πράκτορες. 6

17 o Persistence Manager Συντηρεί την κατάσταση των πρακτόρων πάνω στο δίκτυο και υποστηρίζει λειτουργίες όπως αποθήκευση και επανεκκίνηση των πρακτόρων. o Queue Manager Είναι υπεύθυνη τόσο για τον χρονοπρογραμματισμό όσο και για τη μετακίνηση των πρακτόρων μεταξύ των διάφορων συστημάτων. o Administration Manager Επιτρέπει τη διαχείριση όλων των λειτουργιών που παρέχει η πλατφόρμα, συμπεριλαμβανομένης και της διαχείρισης των υπόλοιπων οντοτήτων. Υποστηρίζει απομακρυσμένη διαχείριση και παρέχει γραφική διεπαφή στο χρήστη διαχειριστή. o Security Manager Είναι υπεύθυνη για την ταυτοποίηση των χρηστών, την πιστοποίηση των πρακτόρων, την προστασία των υπολογιστικών πόρων και την ακεραιότητα των πρακτόρων. Mole (University of Stuttgard) Το κυρίως σύστημα της Mole καλείται engine και παρέχει πολλαπλά μέρη, στα οποία μπορούν να μετακινηθούν οι πράκτορες, τα οποία καλούνται τοποθεσίες (locations). Η πλατφόρμα χρησιμοποιεί μια αρχιτεκτονική «κλειστών» προδιαγραφών της Sun υλοποιημένη σε Java, για τη μετακίνηση των πρακτόρων μεταξύ των διαφορετικών τοποθεσιών. Η τεκμηρίωση της πλατφόρμας είναι αρκετά περιορισμένη, κάτι που οδηγεί στο δύσκολο προγραμματισμό των πρακτόρων. Odyssey (General Magic) Η General Magic ήταν η πρώτη εταιρεία που επιχείρησε το «πάντρεμα» της πλατφόρμας των κινητών πρακτόρων με τη δικιά της scripting γλώσσα προγραμματισμού. Το όλο εγχείρημα απέτυχε λόγω της «κλειστής» φύσης της γλώσσας προγραμματισμού και της πολιτικής της εταιρείας. Οι τεχνολογίες που υποστηρίζονταν ήταν RMI, DCOM και IIOP. Voyager (ObjectSpace) Η εταιρεία αυτή ορίζει την πλατφόρμα της σαν Agent ORB (Object Request Broker), δηλαδή σαν αντικείμενο που αντιπροσωπεύει τον πράκτορα. Η όλη ιδέα βασίζεται στο να φαίνεται ο κινητός πράκτορας σαν ένα αυτόνομο κινητό αντικείμενο. Μοναδική είναι η αρχιτεκτονική που υποστηρίζει τη διαχείριση των μηνυμάτων και των γεγονότων γύρω από τους πράκτορες, η οποία καλείται Space και κατασκευάστηκε με τέτοιο τρόπο ώστε να υποστηρίζει υψηλή ανεκτικότητα σε λάθη όσον αφορά την προώθηση μηνυμάτων και τη διαχείριση των γεγονότων πάνω σε μεγάλης κλίμακας και υψηλών απαιτήσεων δίκτυο. ADK (Agent Development Kit) Η πλατφόρμα αυτή, όπως ισχυρίζονται οι συγγραφείς, επιτρέπει την αξιόπιστη ανάπτυξη εφαρμογών γύρω από τους κινητούς πράκτορες. Τα κύρια χαρακτηριστικά της είναι η υποστήριξη επικοινωνίας 7

18 βασισμένη σε μηνύματα XML, υπηρεσιών βασισμένων σε SOAP και η συμβατότητα με προδιαγραφές FIPA. Η γλώσσα προγραμματισμού της είναι η Java. AAP (April Agent Platform) Η AAP είναι μία FIPA-συμβατή πλατφόρμα για πράκτορες, η οποία σχεδιάστηκε για να παρέχει την ανάπτυξη συστημάτων γύρω από πράκτορες με λίγες υπολογιστικές απαιτήσεις. Το όνομά της σχετίζεται με τη γλώσσα προγραμματισμού που έχει χρησιμοποιηθεί για την ανάπτυξη της πλατφόρμας (April programming language). Σημαντικό πλεονέκτημα της πλατφόρμας είναι η άδεια χρήσης κάτω από την οποία διατίθεται (GPL). Comtec Agent Platform Άλλη μία πλατφόρμα βασισμένη στο ανοιχτό λογισμικό. Είναι FIPA συμβατή και διατίθεται με GPL άδεια. Grasshopper (IKV) Είναι μία πλατφόρμα υλοποιημένη εξολοκλήρου σε γλώσσα προγραμματισμού Java. Είναι συμβατή και με τις δύο διεθνείς προδιαγραφές, OMG MASIF και FIPA. JADE Η JADE είναι μία πλατφόρμα συμβατή με τη νεότερη FIPA 2000 προδιαγραφή και είναι υλοποιημένη σε Java. Προσφέρει διαχείριση των κινητών πρακτόρων μέσω γραφικής διεπαφής καθώς και επιπρόσθετες λειτουργίες που σχετίζονται με αυτούς, όπως απασφαλμάτωση (debugging). Η επικοινωνία μεταξύ των πρακτόρων γίνεται εξολοκλήρου σε ACL (Agent Common Language). Java Agent Services API (JAS) Ορίζει ένα περιβάλλον προγραμματισμού κινητών πρακτόρων που είναι συμβατό με τις προδιαγραφές FIPA. Παρέχει διεπαφές για δημιουργία μηνυμάτων, κωδικοποίηση μηνυμάτων, μεταφορά μηνυμάτων και υπηρεσίες καταλόγου. Είναι σχεδιασμένο έτσι ώστε να υποστηρίζει την τεχνολογία των κινητών πρακτόρων σε συνδυασμό με αυτή των υπηρεσιών διαδικτύου. Zeus (BT Labs) Είναι μια πλατφόρμα επίσης βασισμένη στο ανοιχτό λογισμικό και εξολοκλήρου υλοποιημένη σε Java. Υποστηρίζει λειτουργίες για το σχεδιασμό και χρονοπρογραμματισμό των κινητών πρακτόρων. Επιπλέον παρέχει λειτουργίες επικοινωνίας μεταξύ των πρακτόρων βασισμένες σε FIPA ACL και μηχανισμούς μεταφοράς των πρακτόρων βασισμένους στο πρωτόκολλο TCP/IP. Παρέχει γραφικό περιβάλλον για την ανάπτυξη των πρακτόρων και επιτρέπει τον έλεγχο των απαιτούμενων πόρων για τη σωστή λειτουργία των πρακτόρων. Hive Η πλατφόρμα αυτή είναι επίσης βασισμένη στη γλώσσα προγραμματισμού Java και σχεδιάστηκε κυρίως για την ανάπτυξη κατανεμημένων εφαρμογών. Οι προγραμματιστές μπορούν εύκολα να αναπτύξουν συστήματα που χρησιμοποιούν δεδομένα από όλο τον παγκόσμιο ιστό. 8

19 JATLite (Java Agent Template Lite) Είναι ένα σύνολο πακέτων, το οποίο επιτρέπει στους προγραμματιστές να αναπτύσσουν γρήγορα εφαρμογές βασισμένες σε κινητούς πράκτορες, οι οποίοι μπορούν να επικοινωνούν αξιόπιστα μέσω του διαδικτύου. Οι πράκτορες πέρα από τις λειτουργίες επικοινωνίας και μετακίνησης, έχουν τη δυνατότητα μεταφοράς αρχείων δια μέσου του δικτύου χρησιμοποιώντας πρωτόκολλα FTP. Γύρω από την τεχνολογία των κινητών πρακτόρων έχουν αναπτυχθεί πολλές πλατφόρμες με κυρίαρχες αυτές που είναι υλοποιημένες σε γλώσσα προγραμματισμού Java. Υπάρχει πληθώρα τέτοιων συστημάτων που η αναφορά σε όλες αυτές θα ήταν πέρα από τους σκοπούς της συγκεκριμένης παραγράφου. Ενδεικτικά ακολουθεί μια λίστα με αρκετές πλατφόρμες βασισμένες σε ξεχωριστές αρχιτεκτονικές και υλοποιήσεις: Active M3 AgentSpace (University de Tecnica de Lisboa) AgentSpace (University of Hull/ University of Sunderland) Agent TCL Agent X Ajanta Amase AMETAS Anima Kafka Kaariboga JIAK Jumping Beans Klaim DECAF KnowBots M0 Messengers Magenta MAgNET MAP MATS Mobile Agent Teams Milenio Excalibur FIPA-OS Tacoma Telescript Traveler WASP ARCA Autonomous Remote Cooperating Agents Bee-gent MIPLACE Bond MOA CBorg Mogent CyberAgents MonJa D Agents mucode Dejay Nomadic Pict Evolution Agent Nomads (OASIS) Societies (EAS) A-Match Agent Building Shell (ABS) Open Agent Architecture CMU software agents group JCAFE Jini Compositional Agent Framework for the Enterprise SOMA Swarm SeMoA Secure Mobile Agents 9

20 FarGo Gossip IMAJ James Pathfinder Planet Plangent Rmi64 JavaNetAgents JavaSeal SMASH Java-2-Go Η επιλογή της κατάλληλης πλατφόρμας είναι συνδυασμός των χαρακτηριστικών που προσφέρει, των πλεονεκτημάτων έναντι των μειονεκτημάτων που έχει, το επίπεδο τεκμηρίωσης και η ευκολία ανάπτυξης κώδικα, η γλώσσα προγραμματισμού που υποστηρίζει και η εύκολη δυνατότητα εκμάθησης. Η πλατφόρμα που επιλέχθηκε για την υλοποίηση της αρχιτεκτονικής είναι το Grasshopper και συγκεκριμένα η έκδοση 2.2.4, η οποία παρέχει αρκετή τεκμηρίωση, εύκολο περιβάλλον προγραμματισμού, συμβατότητα με τις διεθνείς προδιαγραφές και χαρακτηριστικά που θα αναλυθούν σε επόμενη παράγραφο. 2.3Grasshopper Agent Platform Όπως έχει ήδη αναφερθεί σε προηγούμενη παράγραφο, το Grasshopper είναι μία πλατφόρμα υποστήριξης κινητών πρακτόρων απ ό την εταιρεία IKV++. Η έκδοση που χρησιμοποιήθηκε είναι η και είναι εξολοκλήρου υλοποιημένη σε γλώσσα προγραμματισμού Java. Η υλοποίηση και η αρχιτεκτονική της πλατφόρμας είναι βασισμένες πάνω στην ιδέα του κατανεμημένου προγραμματισμού Κατανεμημένο Περιβάλλον Κινητών Πρακτόρων Το περιβάλλον του Grasshopper αποτελείται από περιοχές (Regions), μέρη (Places), πρακτορεία (Agencies) και από διάφορους τύπους πρακτόρων (Agents). Από εδώ και στο εξής θα αναφερόμαστε σε αυτά με τους αγγλικούς όρους. Το παρακάτω σχήμα απεικονίζει τη δομή του κατανεμημένου περιβάλλοντος της πλατφόρμας. Σχήμα 1. Ιεραρχική Δομή Συστατικών 10

21 Agents Γενικά δεν υπάρχει κάποιος συγκεκριμένος ορισμός για την οντότητα του πράκτορα, επομένως θα χρησιμοποιήσουμε τον ορισμό που δόθηκε στην παράγραφο 2.2. Η πλατφόρμα Grasshopper υποστηρίζει δύο διαφορετικούς τύπους πρακτόρων: τους κινητούς πράκτορες (mobile agents) και τους στατικούς πράκτορες (stationary agents). Οι κινητοί πράκτορες έχουν τη δυνατότητα να μετακινούνται από μια φυσική τοποθεσία σε μια άλλη. Με αυτό τον τρόπο μπορούν να θεωρηθούν μια εναλλακτική λύση του παραδοσιακού Client Server μοντέλου. Ενώ το ήδη υπάρχον μοντέλο βασίζεται σε απομακρυσμένες κλήσης διαδικασιών, οι κινητοί πράκτορες μπορούν να μεταναστεύουν στην επιθυμητή τοποθεσία και να πραγματοποιούν τοπικές συναλλαγές. Έτσι, πολλά πλεονεκτήματα μπορούν να επιτευχθούν, όπως η μείωση της κίνησης και του φόρτου του δικτύου. Συχνά η τεχνολογία των κινητών πρακτόρων θεωρείται σαν μια άλλη προσέγγιση αντί του παραδοσιακού μοντέλου. Με το περιβάλλον που παρέχει η πλατφόρμα είναι δυνατό μια υλοποίηση συνεργασίας και των δύο τεχνολογιών να επιτευχθεί. Στο σημείο αυτό είναι φρόνιμο να ξεκαθαρίσουμε τη διαφορά του κινητού πράκτορα (mobile agent) από τον κινητό κώδικα (mobile code). Στην πρώτη περίπτωση, έχουμε μια οντότητα η οποία ξεκινά την εκτέλεσή της και έχει τη δυνατότητα να μετακινείται κατά τη διάρκεια της εκτέλεσής της συνεχίζοντάς την στο σημείο που φτάνει μετά την μετακίνηση. Στη δεύτερη περίπτωση έχουμε ένα πρόγραμμα το οποίο αποστέλλεται σε μια απομακρυσμένη τοποθεσία προτού ξεκινήσει η εκτέλεσή του και ενεργοποιείται κατά την άφιξή του στη νέα τοποθεσία, όπου παραμένει εκεί για τον πλήρη κύκλο της ζωής του. Η διαφορά των στατικών πρακτόρων με τους κινητούς πράκτορες είναι το γεγονός ότι οι πρώτοι δεν έχουν τη δυνατότητα να μετακινούνται μεταξύ των διαφόρων κόμβων του δικτύου, αλλά είναι συσχετισμένοι μόνο με μία συγκεκριμένη τοποθεσία. Κατά τη διάρκεια του κύκλου ζωής του, ο πράκτορας μπορεί να βρίσκεται σε διάφορες καταστάσεις. Ένας πράκτορας του Grasshopper μπορεί να βρίσκεται σε μία από τις παρακάτω καταστάσεις: Ενεργός (Active) Ένας πράκτορας είναι ενεργός όταν εκτελεί κάποια εργασία. Ένας ενεργός πράκτορας μπορεί να ανασταλεί ή να απενεργοποιηθεί. Ανασταλμένος (Suspended) Ένας πράκτορας είναι ανασταλμένος αν η εργασία του έχει διακοπεί προσωρινά. Ο 11

22 πράκτορας παραμένει και συνεχίζει την εργασία του όταν ξανα-ενεργοποιηθεί. Ένας ανασταλμένος πράκτορας είναι αδύναμος να πραγματοποιήσει οποιουδήποτε είδους επικοινωνία με άλλες οντότητες. Καθαρισμένος (Flushed) Ένας πράκτορας στην κατάσταση αυτή δεν είναι πια ενεργός. Όλες οι σχετικές εσωτερικές πληροφορίες του όμως είναι αποθηκευμένες σε κάποιο μέσο μεταφοράς. Ένας τέτοιος πράκτορας μπορεί να ενεργοποιηθεί ξανά και το νέο στιγμιότυπό του θα εφοδιαστεί με όλες τις απαραίτητες πληροφορίες ώστε να συνεχίσει την εκτέλεσή του από το σημείο που διακόπηκε. Η διαφορά με τον ανασταλμένο πράκτορα είναι το γεγονός ότι στη συγκεκριμένη περίπτωση ο πράκτορας ενεργοποιείται ξανά αυτόματα αν υπάρξει κάποιο επικοινωνιακό ερέθισμα. Agencies Η agency είναι το πραγματικό περιβάλλον εκτέλεσης τόσο των κινητών, όσο και των στατικών πρακτόρων. Σε κάθε κόμβο πρέπει να υπάρχει τουλάχιστον μία agency ώστε να υποστηρίζει την εκτέλεση των πρακτόρων. Μια Grasshopper agency αποτελείται από δύο μέρη: την core agency και ένα ή περισσότερα places. Η core agency αναπαριστά την ελάχιστη λειτουργικότητα που χρειάζεται μια agency προκειμένου να υποστηρίξει την εκτέλεση των πρακτόρων και παρέχει τις ακόλουθες υπηρεσίες: Υπηρεσία Επικοινωνίας (Communication Service) Η υπηρεσία αυτή είναι υπεύθυνη για όλες τις απομακρυσμένες αλληλεπιδράσεις που γίνονται μεταξύ των συστατικών του Grasshopper. Τα πρωτόκολλα που υποστηρίζονται είναι CORBA, IIOP, Java RMI, RMI+SSL. Η εν λόγω υπηρεσία υποστηρίζει σύγχρονη και ασύγχρονη επικοινωνία καθώς και δυναμικές κλήσεις μεθόδων. Υπηρεσία Καταχώρησης (Registration Service) Κάθε agency πρέπει να είναι σε θέση να γνωρίζει όλες τις απαραίτητες πληροφορίες για τους πράκτορες που φιλοξενεί τόσο για σκοπούς εξωτερικής διαχείρισης, όσο για την παράδοση πληροφοριών σε αυτούς. Η υπηρεσία καταχώρησης έχει αναπτυχθεί για το σκοπό αυτό. Επιπλέον, η υπηρεσία καταχώρησης της κάθε agency είναι καταχωρημένη στον κατάλογο της region (region registry), στον οποίο συντηρούνται πληροφορίες σχετικές με πράκτορες, agencies και places. Υπηρεσία Διαχείρισης (Management Service) Η συγκεκριμένη υπηρεσία έχει αναπτυχθεί ώστε να επιτρέπει την παρακολούθηση και τον έλεγχο των πρακτόρων, και όχι μόνο, από το χρήστη. Οι κυριότερες λειτουργίες που προσφέρει είναι: o Δημιουργία πράκτορα. o Διαγραφή πράκτορα. 12

23 o o o o o Αναστολή πράκτορα. Δημιουργία place. Διαγραφή place. Παροχή πληροφοριών σχετικών με πράκτορες ή places. Παροχή λίστας όλων των πρακτόρων που φιλοξενούνται σε ένα place. o Παροχή λίστας όλων των places που υπάρχουν σε μία agency. Υπηρεσία Μετακίνησης (Transport Service) Αυτή η υπηρεσία καθιστά εφικτή την μετακίνηση των πρακτόρων από μία agency σε μια άλλη. Ρόλος της είναι ο συντονισμός της όλης μετακίνησης του πράκτορα και της αντίστοιχης πληροφορίας, που ουσιαστικά γίνεται από την υπηρεσία επικοινωνίας (communication service). Υπηρεσία Ασφάλειας (Security Service) Η πλατφόρμα υποστηρίζει δύο ειδών ασφάλεια: εξωτερική και εσωτερική. Η εξωτερική προστατεύει τις απομακρυσμένες αλληλεπιδράσεις μεταξύ των συστατικών της πλατφόρμας και έχει να κάνει με την εμπιστευτικότητα, τη μυστικότητα, την πιστοποίηση και την ακεραιότητα της πληροφορίας που μεταφέρεται. Για το λόγο αυτό πρωτόκολλα SSL χρησιμοποιούνται. Η εσωτερική ασφάλεια προστατεύει τους υπολογιστικούς πόρους από πιθανή μη εξουσιοδοτημένη πρόσβαση από πράκτορες. Η ασφάλεια αυτή βασίζεται κατά κύριο λόγω στην ασφάλεια που παρέχει η Java. Υπηρεσία Επιμονής (Persistence Service) η εν λόγω υπηρεσία επιτρέπει την αποθήκευση των πρακτόρων, και όχι μόνο, σε κάποιο μέσο μεταφοράς. Με τον τρόπο αυτό είναι δυνατή η ανάκαμψη κάποιου πράκτορα όταν είναι απαραίτητο. Υπάρχουν δύο είδη της υπηρεσίας αυτής. Στην πρώτη περίπτωση, τα places είναι δυνατό να παραμείνουν ακόμη κι αν η agency στην οποία βρίσκονται κλείσει και είναι διαθέσιμα και πάλι όταν η agency ξαναρχίσει. Η υπηρεσία αυτή δεν είναι ορατή από τους προγραμματιστές και ρυθμίζεται από το διαχειριστή. Στη δεύτερη περίπτωση, ο πράκτορας μπορεί να αποθηκεύεται περιοδικά χωρίς να διακόπτεται η εκτέλεσή του. Η συντήρηση αυτή παρέχεται αυτόματα από την υπηρεσία. Επιπλέον, ο πράκτορας μπορεί να ρυθμίζει την υπηρεσία να τερματίσει την εκτέλεσή του ύστερα από κάποιο χρόνο που θα παραμένει ανενεργός. Στην περίπτωση αυτή παραμένει καταχωρημένος στην agency σε περίπτωση επαναενεργοποίησης. Τέλος, ο πράκτορας μπορεί να αποθηκεύεται οποιαδήποτε στιγμή θέλει αυτός ή ο χρήστης που αντιπροσωπεύει. Places Ένα place παρέχει μια λογική κατηγοριοποίηση της λειτουργικότητας μέσα σε μία agency, δηλαδή μπορεί να υπάρχουν πολλά places μέσα σε μία agency, κάθε ένα από τα οποία να 13

24 εξυπηρετεί ένα συγκεκριμένο σκοπό. Το όνομα του place θα πρέπει να αναδεικνύει αυτό το σκοπό. Σε κάθε agency υπάρχει ένα place με το όνομα Information Desk. Αν κάποιος πράκτορας μετακινηθεί από μια agency σε μια άλλη και δεν αναφέρεται συγκεκριμένα σε ποιο place θα μεταφερθεί, τότε μεταφέρεται αυτόματα στο Information Desk της agency προορισμού. Regions Η ιδέα των regions προέκυψε για τη διαχείριση όλων των κατανεμημένων συστατικών του Grasshopper. Οι agencies, όπως και τα places, μπορούν να συσχετισθούν με μια συγκεκριμένη region με το να καταχωρηθούν σε έναν κατάλογο της region. Επομένως μια region περιέχει όλη την απαραίτητη πληροφορία για όλα τα συστατικά της πλατφόρμας που είναι καταχωρημένα σε αυτή. Η πληροφορία αυτή, όπως αναφέρθηκε και προηγουμένως, συντηρείται στο μητρώο της region (region registry). Όταν ένα νέο συστατικό δημιουργείται τότε αυτόματα ενημερώνεται και το μητρώο με τη νέα πληροφορία. Όταν οι agencies είναι καταχωρημένες στο μητρώο των εκάστοτε regions, τότε οι πράκτορες μπορούν να μετακινούνται από agency σε agency μεταξύ διαφορετικών regions. Η τρέχουσα τοποθεσία του πράκτορα ενημερώνεται στο αντίστοιχο μητρώο της region στην οποία φιλοξενείται. Άλλες οντότητες (εξωτερικές ή όχι) με το να συμβουλεύονται το μητρώο της region μπορούν ανά πάσα στιγμή να ανακτήσουν πληροφορία για την τρέχουσα τοποθεσία του πράκτορα ή να επικοινωνήσουν μεταξύ του. Παραδείγματος χάριν, αν ένας πράκτορας Α θέλει να επικοινωνήσει με ένα πράκτορα Β, τότε αρκεί ο Α να γνωρίζει το όνομα του Β. Η υπηρεσία επικοινωνίας της πλατφόρμας μέσω του μητρώου της region θα ανακτήσει την τοποθεσία του πράκτορα Β και θα εγκαθιδρύσει την σύνδεση μεταξύ των πρακτόρων Α και Β Επικοινωνία Η επικοινωνία των συστατικών του Grasshopper γίνεται με τη βοήθεια της υπηρεσίας επικοινωνίας (communication service). Η υπηρεσία αυτή επιτρέπει επικοινωνία μεταξύ των πρακτόρων χωρίς να απασχολεί τον προγραμματιστεί η τοποθεσία του κάθε πράκτορα. Η υπηρεσία επικοινωνίας επιτρέπει την επικοινωνία μέσω των εξής πρωτοκόλλων: CORBA Internet Inter-ORB Protocol (IIOP) Μπορεί να χρησιμοποιηθεί σε οποιαδήποτε περιβάλλοντα χρησιμοποιούν CORBA. Βασική προϋπόθεση είναι όλες οι οντότητες να εκτελούνται σε CORBA περιβάλλον. MAF IIOP Το πρωτόκολλο αυτό είναι μια ειδική έκδοση του CORBA IIOP, η οποία σχεδιάστηκε για επικοινωνία μεταξύ πρακτόρων. Είναι βασισμένο στη διεθνή προδιαγραφή MASIF 14

25 και επομένως δε χρησιμοποιεί την υπηρεσία επικοινωνίας του Grasshopper. Το εν λόγω πρωτόκολλο, σαν ειδίκευση του CORBA IIOP, έχει τις ίδιες απαιτήσεις με αυτό. Java s Remote Method Invocations (RMI) Οι απομακρυσμένες κλήσεις μεθόδων πρωτοεμφανίστηκαν στο JDK 1.1 και επιτρέπουν σε Java αντικείμενα να καλούν μεθόδους άλλων Java αντικειμένων, τα οποία τρέχουν σε διαφορετική εικονική μηχανή της Java (Java Virtual Machine). Όλες οι agencies του Grasshopper υποστηρίζουν αυτό το πρωτόκολλο απευθείας χωρίς να είναι απαραίτητη κάποια επιπρόσθετη εγκατάσταση. RMI + SSL Με τη χρήση αυτού του πρωτοκόλλου, ουσιαστικά εκτελείται το RMI πρωτόκολλο πάνω σε δικλείδες ασφαλείας που προσφέρει το πρωτόκολλο SSL, το οποίο προσφέρει ασφαλή μετάδοση όλων των δεδομένων. Προκειμένου να χρησιμοποιηθεί αυτό το πρωτόκολλο, πιθανόν επιπλέον πακέτα να είναι απαραίτητο να εγκατασταθούν. Plain Socket Connections Είναι ο γρηγορότερος τρόπος να επικοινωνήσουν δύο οντότητες μεταξύ τους μέσω μιας συγκεκριμένης «πόρτας». Το πρωτόκολλο αυτό μπορεί να λειτουργήσει σε οποιοδήποτε δικτυακό περιβάλλον και είναι το πρωτόκολλο που χρησιμοποιείται εξ ορισμού από τις agencies του Grasshopper. Plain Sockets + SSL Ακριβώς όμοιο πρωτόκολλο με τη διαφορά ότι υπάρχει η επιπρόσθετη προστασία που προσφέρει το πρωτόκολλο SSL. Στο σχήμα που ακολουθεί φαίνεται η επικοινωνία δύο συστατικών του Grasshopper δια μέσου πρωτοκόλλων. Σχήμα 2. Επικοινωνία δια μέσου πρωτοκόλλων Μέσα σε μια region, η πλατφόρμα είναι ικανή να αποφασίσει ποια πρωτόκολλα υποστηρίζονται από το κανάλι επικοινωνίας που έχει εγκαθιδρυθεί και να επιλέξει το καταλληλότερο. Οι πράκτορες έχουν τη δυνατότητα να χρησιμοποιήσουν την υπηρεσία επικοινωνίας για να καλέσουν μεθόδους άλλων πρακτόρων. Αυτό γίνεται ανεξάρτητα από την τοποθεσία που 15

26 βρίσκονται οι πράκτορες, δηλαδή όσον αφορά τον προγραμματισμό τους, οι απομακρυσμένες κλήσεις μεθόδων φαίνονται όπως και οι τοπικές κλήσεις μεθόδων αντικειμένων που βρίσκονται μέσα στην ίδια εικονική μηχανή. Αυτό επιτυγχάνεται μέσω αντικειμένων με ρόλο μεσολαβητή. Αυτά τα αντικείμενα καλούνται proxy objects και είναι απευθείας προσβάσιμα από τον πράκτορα ή την οντότητα που θέλει να καλέσει κάποια άλλη οντότητα ή πράκτορα. Το proxy αντικείμενο προωθεί την κλήση στην οντότητα που είναι ο στόχος. Το επόμενο σχήμα απεικονίζει αυτή τη λειτουργία. Σχήμα 3. Επικοινωνία ανεξάρτητη της τοποθεσίας Η χρήση του τοπικού proxy αντικειμένου προσφέρει στον προγραμματιστή ένα σύνολο μεθόδων για να επιτύχει την επικοινωνία που επιθυμεί αποκρύπτοντάς του τις εσωτερικές διαπραγματεύσεις και αιτήσεις που λαμβάνουν χώρα προκειμένου να επιτευχθεί η απομακρυσμένη κλήση. Η διάφανη αυτή προς το χρήστη επικοινωνία απαιτεί την ύπαρξη ενός μητρώου για τη region (region registry) και δύναται να δουλέψει μόνο μέσα στην ίδια region. Για επικοινωνία μεταξύ διαφορετικών regions απαιτείται ο πελάτης να γνωρίζει το URL του στόχου με τον οποίο επιθυμεί να επικοινωνήσει. Το Grasshopper προσφέρει τέσσερα διαφορετικά ήδη επικοινωνίας: Σύγχρονη επικοινωνία (synchronous communication) Ασύγχρονη επικοινωνία (asynchronous communication) Δυναμική Επικοινωνία (dynamic communication) Παράλληλη επικοινωνία (multicast communication) Αναλυτικότερα τα τέσσερα αυτά ήδη εξηγούνται παρακάτω. Σύγχρονη επικοινωνία 16

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

28 Σχήμα 5. Ασύγχρονη επικοινωνία Δυναμική επικοινωνία Ο μηχανισμός αυτός είναι χρήσιμος στην περίπτωση που ο πελάτης δεν έχει πρόσβαση σε κάποιο proxy αντικείμενο. Ο πελάτης είναι σε θέση να κατασκευάσει κάποιο μήνυμα κατά την ώρα εκτέλεσης προσδιορίζοντας την υπογραφή της μεθόδου που πρόκειται να κληθεί, η οποία ανήκει σε κάποιο απομακρυσμένο αντικείμενο. Η δυναμική επικοινωνία μπορεί να είναι είτε σύγχρονη, είτε ασύγχρονη. Παράλληλη επικοινωνία Το εν λόγω είδος επικοινωνίας επιτρέπει στους πελάτες να κάνουν χρήση της παραλληλίας όταν επικοινωνούν με proxy αντικείμενα. Με χρήση του μοντέλου αυτού, ο πελάτης μπορεί να καλέσει την ίδια μέθοδο παράλληλα σε διαφορετικά αντικείμενα. Για το λόγο αυτό χρησιμοποιούνται ομάδες proxy αντικειμένων, που ονομάζονται group proxies. Οι ομάδες αυτές ενσωματώνουν και υλοποιούν μηχανισμούς βασισμένους σε διαφορετικά νήματα, οι οποίοι είναι απαραίτητοι για να αντεπεξέλθουν σε ανάγκες παράλληλης επεξεργασίας. Το σχήμα που ακολουθεί απεικονίζει τη λειτουργία της παράλληλης επικοινωνίας. 18

29 Σχήμα 6. Παράλληλη επικοινωνία Για την ανάκτηση των πολλαπλών αποτελεσμάτων είναι αναγκαίος ο καθορισμός κάποιων πολιτικών πάνω στις οποίες θα βασίζεται η συμπεριφορά του συνόλου των proxy αντικειμένων. Τρεις είναι η βασικές πολιτικές που είναι δυνατόν να ακολουθηθούν και είναι οι εξής: OR Termination Στην περίπτωση αυτή ο πελάτης αναστέλλει τη λειτουργία μέχρις ότου οποιοδήποτε αποτέλεσμα του επιστραφεί πρώτο. Τα υπόλοιπα αποτελέσματα που θα φθάσουν στη συνέχεια αγνοούνται. Η λειτουργία της πολιτικής αυτής φαίνεται στο παρακάτω σχήμα. Σχήμα 7. OR Termination AND Termination Η περίπτωση αυτή, που και πάλι αφορά τη συμπεριφορά του πελάτη μέχρι να πάρει τα αποτελέσματα, έχει να κάνει με την αναστολή της εργασίας του μέχρι να του επιστραφούν όλα τα αποτελέσματα από τις κλήσεις που έκανε. Προκειμένου ο πελάτης να μην αναστείλει την εργασία του επ αόριστον, έχει οριστεί κάποιο όριο χρόνου που μπορεί να παραμείνει στην αναμονή. 19

30 Σχήμα 8. AND Termination Incremental Termination Η τελευταία περίπτωση σε αντίθεση με τις προηγούμενες δύο, επιτρέπει στον πελάτη να συνεχίσει κανονικά την εκτέλεσή του αμέσως μετά την τελευταία κλήση που έκανε. Όπως και στην ασύγχρονη επικοινωνία, ο πελάτης μπορεί να στέλνει μηνύματα ώστε να ελέγχει αν κάποια απομακρυσμένη μέθοδος που κάλεσε έχει τελειώσει για να ανακτήσει τα αποτελέσματα. Σχήμα 9. Incremental Termination 2.3.3Διευθυνσιοδότηση Εν γένει, μια τοποθεσία του Grasshopper περιγράφεται με τον ακόλουθο τρόπο, παρόμοιο με αυτόν των URLs. <protocol>://<host>:<port>/<agency>/<place> όπου: Protocol Είναι το ακρωνύμιο του επιθυμητού πρωτοκόλλου που θα χρησιμοποιηθεί. Host Είναι το όνομα ή η IP διεύθυνση του ξενιστή προορισμού (destination host). 20

31 Port Είναι ο αριθμός της πόρτας όσον αφορά τη μεριά του προορισμού. Agency Είναι το όνομα της agency προορισμού. Place Είναι το όνομα του place προορισμού. Το όνομα του place όπως επίσης και ο αριθμός της «πόρτας» είναι προαιρετικά. Αν δεν προσδιοριστεί επακριβώς το όνομα του place τότε χρησιμοποιείται το εξ ορισμού Information Desk, που υπάρχει σε κάθε agency. Οι προδιαγραφές που επεξηγήθηκαν παραπάνω προϋποθέτουν ότι ο πελάτης γνωρίζει ποια πρωτόκολλα χρησιμοποιούνται από το αντικείμενο με το οποίο επιθυμεί να επικοινωνήσει. Σε αντίθετη περίπτωση, η υπηρεσία επικοινωνίας επικοινωνεί με το μητρώο της region για να ανακτήσει πληροφορίες για τα πρωτόκολλα που υποστηρίζονται από τη μεριά του προορισμού. Όπως είναι προφανές, αυτές οι επιπρόσθετες αλληλεπιδράσεις καταναλώνουν περισσότερο χρόνο μέχρις ότου επιτευχθεί η επικοινωνία. Επομένως, καλό είναι να προσδιορίζεται εξαρχής το πρωτόκολλο που θα χρησιμοποιηθεί για την κάθε συναλλαγή Ασφάλεια Σε ανοιχτά κατανεμημένα περιβάλλοντα, όπως είναι το Grasshopper, σημαντικά προβλήματα ασφάλειας μπορούν να προκύψουν. Για την έγκαιρη αντιμετώπιση των προβλημάτων αυτών, η πλατφόρμα παρέχει τα εξής χαρακτηριστικά: Εμπιστευτικότητα Όταν κάποιος πράκτορας μεταφέρει εμπιστευτικά δεδομένα, τότε δεν πρέπει να είναι στη δικαιοδοσία κανενός, παρά μόνο των μελών που επικοινωνούν, η διαχείριση του πράκτορα. Εφόσον η μετάδοση γίνεται συνήθως μέσω κάποιου μέσου, το οποίο δεν παρέχει ασφάλεια, η κωδικοποίηση του πράκτορα είναι απαραίτητη κατά τη μεταφορά του. Ακεραιότητα Κατά την άφιξη του πράκτορα στον προορισμό, πρέπει να είναι προφανές εάν ο πράκτορας τροποποιήθηκε με οποιοδήποτε τρόπο κατά τη μεταφορά του. Κάποιος υποτιθέμενος εισβολέας δεν πρέπει να είναι σε θέση να τροποποιεί τον πράκτορα χωρίς να το αντιλαμβάνεται το σύστημα. Σε περίπτωση οποιασδήποτε αμφιβολίας όσον αφορά στην ακεραιότητα του πράκτορα, η μετάδοση πρέπει να επαναληφθεί. Πιστοποίηση Σε ένα σχήμα επικοινωνίας, η πιστοποίηση των συμμετεχόντων μελών είναι απαραίτητη ώστε να εξασφαλισθεί κατ επέκταση και η αυθεντικότητα των δεδομένων που μεταφέρονται. Η φύση των επικοινωνιακών δικτύων είναι τέτοια, που επιτρέπει εύκολα σε κάποιον εισβολέα να παριστάνει κάποιο μέλος της επικοινωνίας χωρίς να το γνωρίζουν τα πραγματικά μέλη της 21

32 επικοινωνίας. Η πιστοποίηση, λοιπόν, είναι μία από τις κυριότερες απαιτήσεις που πρέπει να έχει ένα σύστημα ώστε να είναι ασφαλές σε κατανεμημένο περιβάλλον. Έλεγχος πρόσβασης Ένα σύστημα γύρω από τους κινητούς πράκτορες, πρέπει να έχει πρόσβαση σε συγκεκριμένους υπολογιστικούς πόρους, όπως το σύστημα αρχείων, το δίκτυο, η επεξεργαστική ισχύς, η μνήμη, κλπ. Είναι προφανές ότι αυτοί οι πόροι πρέπει να είναι προστατευμένη από μη εξουσιοδοτημένη πρόσβαση. Συνήθως αυτό είναι εφικτό μέσω κάποιων πολιτικών που δίνεται πρόσβαση σε συγκεκριμένους πόρους ανάλογα με το επίπεδο εμπιστοσύνης που επιλέγεται. Αν κάποιος πράκτορας καταφέρει να έχει πρόσβαση σε πόρους πέραν της δικαιοδοσίας του, είναι δυνατόν να καταστραφούν δεδομένα, να αλλάξει η συμπεριφορά του συστήματος και γενικά να κλονιστεί η συνολική ασφάλεια του συστήματος. Καταγραφή Οι υπηρεσίες ασφάλειας οφείλουν να καταγράφουν τις ενέργειες των πρακτόρων ώστε να καταγράφονται περιστατικά προσπαθειών πρόσβασης σε απαγορευμένους πόρους ή γενικά περιστατικά που αφορούν στην ασφάλεια του συστήματος. Τα γεγονότα αυτά μετά την καταγραφή τους σε κάποιο αρχείο μπορούν να αναλυθούν και να προσφέρουν μια συνολική εικόνα γύρω από την ασφάλεια του συστήματος και τους πιθανούς κινδύνους που μπορεί να προέκυψαν. Εν γένει, για την ασφάλεια της πλατφόρμας πέραν της ασφάλειας που προσφέρει η Java, η κρυπτογραφία έχει καθοριστικό ρόλο. Συγκεκριμένα, χρησιμοποιούνται συμμετρικοί και ασύμμετροι αλγόριθμοι κρυπτογράφησης (symmetric and asymmetric cryptographic algorithms), μονόδρομες συναρτήσεις κατακερματισμού (one way hash functions) και σειρές πιστοποιητικών και προδιαγραφών που προσφέρει η ITU (Η ITU είναι ο διεθνής οργανισμός τυποποίησης για τις τηλεπικοινωνίες). 22

33 3Κεφάλαιο : Υπηρεσίες Διαδικτύου 3.1Εισαγωγή Τα τελευταία χρόνια πολλές ερευνητικές ομάδες στο χώρο του διαδικτύου έχουν επικεντρώσει τις προσπάθειές τους στην ανάπτυξη υπηρεσιών, οι οποίες θα δώσουν επιπρόσθετες δυνατότητες στους χρήστες για την εξυπηρέτηση των ολοένα αυξανόμενων αναγκών τους. Οι υπηρεσίες αυτές έχουν υιοθετηθεί από πολλούς κατασκευαστές λογισμικού, σαν μέσο για τον εμπλουτισμό των ιστοσελίδων και όχι μόνο, με δυναμικά στοιχεία, τα οποία βασίζονται σε συγκεκριμένες διεπαφές. Διάφοροι οργανισμοί εμπλέκονται στον καθορισμό προδιαγραφών για τις «Υπηρεσίες Διαδικτύου» με αποτέλεσμα αρκετοί ορισμοί να έχουν διατυπωθεί, με κυρίαρχο αυτόν της ερευνητικής ομάδας W3C Web Services Architecture Working Group «Μια υπηρεσία ιστού (web service), είναι μια εφαρμογή λογισμικού, η οποία προσδιορίζεται από ένα URI, της οποίας οι διεπαφές και οι συνδέσεις είναι δυνατόν να καθοριστούν, να περιγραφούν και να εντοπισθούν από τεχνουργήματα XML, και υποστηρίζουν απευθείας αλληλεπίδραση με άλλες εφαρμογές λογισμικού, χρησιμοποιώντας μηνύματα βασισμένα σε XML, διαμέσου πρωτοκόλλων βασισμένων στο διαδίκτυο.» Σύμφωνα με τον παραπάνω ορισμό, η «Υπηρεσία Διαδικτύου» καθορίζεται σαν ένας πόρος, όχι μόνο μέσα στον παγκόσμιο ιστό, αλλά και σε επίπεδο ενός τοπικού εσωτερικού δικτύου (intranet), ο οποίος παρέχεται από κάποιον οργανισμό. Σημαντικό είναι το γεγονός της ανεξαρτησίας ανάμεσα στις υπολογιστικές πλατφόρμες από τη μεριά του παροχέα της υπηρεσίας και του τελικού χρήστη αυτής (cross platform applications). Η «Υπηρεσία Διαδικτύου» είναι διαθέσιμη μέσω των δημοσιευθέντων διεπαφών της, στις οποίες είναι δυνατή η κλήση. Η σχέση αυτή είναι ανάλογη με αυτή του διαφυλλιστή διαδικτύου (web browser) και του παροχέα του δικτυακού τόπου (web application server). Ο διαφυλλιστής δεν επηρεάζεται από τον παροχέα της ιστοσελίδας ή το μηχανισμό που τον εξυπηρετεί, αρκεί το αποτέλεσμα να είναι εκφρασμένο σε γλώσσα HTML. Από τεχνικής πλευράς, μια «Υπηρεσία Διαδικτύου» είναι μια συλλογή από συσχετιζόμενες υπηρεσίες, που είναι προσβάσιμες μέσα από κάποιο δίκτυο και έχουν μια συγκεκριμένη περιγραφή. Σε αυτό το επίπεδο, η έννοια της «Υπηρεσίας Διαδικτύου» δεν είναι κάτι καινούργιο στην επιστήμη των υπολογιστών. Μέσω των 23

34 «Υπηρεσιών Διαδικτύου», η επιστήμη των υπολογιστών προσπαθεί να επιλύσει την πρωταρχική πρόκληση του κατανεμημένου υπολογισμού, την εύρεση και την πρόσβαση σε απομακρυσμένους πόρους. Η διαφορά αυτής της προσέγγισης είναι η χρήση ανοιχτών τεχνολογιών και προδιαγραφών (open standards), ελεγχόμενων από ευρείας συναίνεσης οργανισμούς, όπως ο OASIS και ο W3C. Βασική αρχή των «Υπηρεσιών Διαδικτύου» είναι η μη υλοποίησή τους σε αυστηρά συνεκτικά συνδεδεμένα εξαρτήματα και υπορουτίνες, που η γνώση τους θα είναι αναγκαία κατά τη φάση της ανάπτυξης της υπηρεσίας. Αντίθετα, επιλέχθηκε μια αρκετά πιο δυναμική προσέγγιση. Δόθηκε έμφαση στις διεπαφές, το σημείο επικοινωνίας μεταξύ της ίδιας της υπηρεσίας και του λογισμικού που την καλεί. Βέβαια, αυτό που είναι πρωτοποριακό, δεν είναι η χρήση διεπαφών, αλλά το γεγονός ότι μια «Υπηρεσία Διαδικτύου» είναι άθροισμα πολλών ανεξάρτητων οντοτήτων, μη αυστηρά συνδεδεμένων μεταξύ τους, που όμως επικοινωνούν με απλές ανοιχτές προδιαγραφές. 3.2Υπηρεσιοκεντρική Αρχιτεκτονική (Service Oriented Architecture SOA) Το μοντέλο που χρησιμοποιείται στις μέρες μας για την περιγραφή των «Υπηρεσιών Διαδικτύου» βασίζεται κυρίως στο κλασικό επιχειρησιακό μοντέλο, το οποίο έχουν υιοθετήσει οι διάφοροι ιδιωτικού οργανισμοί και απεικονίζεται στο Σχήμα 10. Σχήμα 10. Αρχιτεκτονική γύρω από την υπηρεσία Από το παραπάνω σχήμα μπορούμε να διακρίνουμε τις οντότητες που απαρτίζουν την τρέχουσα αρχιτεκτονική των υπηρεσιών διαδικτύου. Αυτές είναι η οντότητα που ζητάει την υπηρεσία (Service Requestor), η οντότητα που παρέχει την υπηρεσία (Service Provider) και τέλος η οντότητα του καταλόγου υπηρεσιών (Service Registry). Με περισσότερη λεπτομέρεια, κάθε μία οντότητα έχει τους ακόλουθους ρόλους: 24

35 Η οντότητα, η οποία ζητάει την υπηρεσία (Service Requestor), είναι στην ουσία ο «αιτούμενος» (Client) της υπηρεσίας και πυροδοτεί την έναρξη της όλης διαδικασίας. Αρχικά επιφορτίζεται με το έργο της αναζήτησης της κατάλληλης περιγραφής μιας υπηρεσίας τις καταχωρήσεις της υπηρεσίας καταλόγου. Στη συνέχεια, και ενώ έχει εντοπίσει τον επιθυμητό παροχέα, εγκαθιδρύει σύνδεση με αυτόν, καλεί την υπηρεσία και λαμβάνει τα αποτελέσματα. Η οντότητα που παρέχει την υπηρεσία (Service Provider), δημοσιοποιεί την περιγραφή της υπηρεσίας ιστού στην οντότητα του καταλόγου υπηρεσιών (Service Registry) και ουσιαστικά παρέχει την υπηρεσία στο διαδίκτυο. Επιπλέον, της ανατίθεται ο ρόλος της λήψης των μηνυμάτων κλήσης για την υπηρεσία από έναν ή περισσότερους αιτούμενους και της παροχής των απαραίτητων αποτελεσμάτων. Τέλος, η οντότητα του καταλόγου υπηρεσιών (Service Registry), περιέχει καταχωρήσεις με τις περιγραφές των ήδη δημοσιοποιηθέντων υπηρεσιών διαδικτύου. Για τις υπηρεσίες αυτές παρέχονται τρόποι αναζήτησης ανάμεσα στις διάφορες περιγραφές. Οι λειτουργίες που παρέχονται μέσω αυτής της αρχιτεκτονικής είναι οι ακόλουθες: Η καταχώρηση των απαραίτητων πληροφοριών για μια υπηρεσία από τη μεριά του παροχού (publishing), η οποία επιτυγχάνεται μέσω της χρήσης της γλώσσας περιγραφής WSDL. Η αναζήτηση και η εύρεση στους καταλόγους της κατάλληλης περιγραφής μιας «Υπηρεσίας Διαδικτύου» (finding). Η επικρατούσα τεχνολογία καταλόγου ονομάζεται UDDI. Τέλος, έχουμε την εγκαθίδρυση σύνδεσης μεταξύ αιτούμενου και παροχέα (binding), κλήση της κατάλληλης υπηρεσίας και αποστολή των αποτελεσμάτων. Όλα τα παραπάνω επιτυγχάνονται με την ανταλλαγή μηνυμάτων SOAP μεταξύ των τριών εμπλεκόμενων οντοτήτων, η οποία βασίζεται στη γλώσσα μεταδεδομένων XML. Το κλειδί της παραπάνω αρχιτεκτονικής είναι η περιγραφή της «Υπηρεσίας Διαδικτύου». Η περιγραφή είναι εκείνη που δημοσιοποιείται από τον παροχέα της υπηρεσίας στον κατάλογο υπηρεσιών. Η περιγραφή είναι το αποτέλεσμα της αναζήτησης του αιτούμενου στον κατάλογο υπηρεσιών. Η περιγραφή είναι εκείνη που λέει στον αιτούμενο όσα ακριβώς πρέπει να γνωρίζει προκειμένου να κάνει κλήση της υπηρεσίας που τον ενδιαφέρει. Τέλος, η περιγραφή της υπηρεσίας μπορεί να περιέχει πληροφορία για το τι είδους είναι το αποτέλεσμα που αναμένεται να επιστραφεί ύστερα από την κλήση της υπηρεσίας. 25

36 Με την παραπάνω αρχιτεκτονική ήδη υπάρχουσες εφαρμογές μπορούν εύκολα να μετασχηματισθούν σε υπηρεσίες που να εξυπηρετούν άλλες υπάρχουσες ή και νέες εφαρμογές. Πολλές υπηρεσίες μπορούν να συνδυαστούν και να συνεργασθούν για την παραγωγή ενός αποτελέσματος με τρόπο διαφανή προς τον τελικό χρήστη, στον οποίο δίνεται η αίσθηση ότι κλήθηκε μία και μόνο υπηρεσία. Επιπρόσθετα, οργανισμοί και επιχειρήσεις μπορούν ευκολότερα να κατασκευάσουν λογισμικό, που να αλληλεπιδρά με επιχειρησιακές διαδικασίες και να ανταποκρίνεται γρήγορα στις αλλαγές του επιχειρησιακού περιβάλλοντος. 3.3Service Oriented Architecture και «Υπηρεσίες Διαδικτύου» Παρόλο που η τεχνολογία των «Υπηρεσιών Διαδικτύου» και η προαναφερθείσα αρχιτεκτονική SOA συχνά συναντώνται μαζί ή σε κάποιο συνδυασμό, πρέπει να αναφερθεί ότι οι δύο αυτοί όροι είναι διαφορετικοί και πρέπει να ξεχωρίζουν. Η αρχιτεκτονική SOA είναι ένα σενάριο, ή μια προσέγγιση, για την οικοδόμηση συστημάτων, τα οποία επικεντρώνονται σε ένα σύνολο από συστατικά που μπορούν να συνεργασθούν δυναμικά. Οι «Υπηρεσίες Διαδικτύου» από την άλλη μεριά, είναι μια προσέγγιση για τον τρόπο που μπορεί να αναπτυχθεί μια αρχιτεκτονική SOA. Το μοντέλο των «Υπηρεσιών Διαδικτύου» παρέχει προδιαγραφές για ένα σύνολο από γλώσσες και τεχνολογίες βασισμένες σε XML, που μπορούν να χρησιμοποιηθούν για την οικοδόμηση συστημάτων με αρχιτεκτονική SOA. 3.4Πρωτόκολλο SOAP Στα τέλη της δεκαετίας του 90, και συγκεκριμένα το 1997, μεγάλες εταιρείες, όπως η Microsoft, άρχισαν να διερευνούν κατά πόσο ο κατανεμημένος υπολογισμός μπορεί να βασιστεί στη γλώσσα XML. Ο σκοπός της έρευνας αυτής ήταν να γίνει εφικτή η επικοινωνία μεταξύ των εφαρμογών μέσω απομακρυσμένων κλήσεων διαδικασιών (Remote Procedure Calls RPCs), χρησιμοποιώντας απλά πρωτόκολλα δικτύου, όπως το HTTP. Το 1999 έκανε την εμφάνισή του το SOAP, ένας RPC μηχανισμός βασισμένος σε XML. Το 2000 ο οργανισμός W3C ασχολείται με την ιδέα αυτή και ύστερα από αρκετές αλλαγές, βελτιώσεις και τροποποιήσεις 2 ολόκληρων χρόνων, το 2003 δηλαδή, το SOAP με την έκδοση 1.2 γίνεται η προτεινόμενη προδιαγραφή πρωτόκολλο για τις υπηρεσίες διαδικτύου. Στον πυρήνα του, το SOAP, είναι μια προδιαγραφή για ένα απλό αλλά ταυτόχρονα ευέλικτο XML πρωτόκολλο δεύτερης γενιάς. Το σημαντικό είναι ότι καθώς η έρευνα ξεκίνησε από τον κατανεμημένο υπολογισμό, το SOAP είναι το πλέον κατάλληλο 26

37 πρωτόκολλο αφού ειδικεύεται σε τέτοια περιβάλλοντα. Το SOAP παρέχει τα κάτωθι χαρακτηριστικά και μηχανισμούς: Μηχανισμός για τον ορισμό της πληροφορίας στην επικοινωνία Στο SOAP, όλη η πληροφορία είναι καταχωρημένη σε ένα ξεκάθαρο και ταυτοποιήσιμο SOAP μήνυμα (SOAP message). Αυτό γίνεται μέσω ενός SOAP φακέλου (SOAP envelope), που περικλείει όλες τις απαραίτητες πληροφορίες. Ένα μήνυμα SOAP, μπορεί να έχει σώμα (body), το οποίο περιέχει πληροφορία σε XML δομή. Επίσης, μπορεί να διαθέτει έναν αριθμό από επικεφαλίδες (headers), οι οποίες ενσωματώνουν επιπλέον πληροφορίες έξω από το σώμα του μηνύματος. Διεργασιακό μοντέλο Αυτό το μοντέλο ορίζει ένα σύνολο κανόνων βάσει των οποίων γίνονται οι διαπραγματεύσεις μεταξύ των SOAP μηνυμάτων και του λογισμικού. Διακρίνεται από την απλότητά του. Μηχανισμός για αντιμετώπιση σφαλμάτων Το SOAP παρέχει το μηχανισμό αυτό με τη μορφή των SOAP faults, τα οποία όταν χρησιμοποιούνται μπορεί να προσδιοριστεί η πηγή που προκάλεσε το σφάλμα. Επιπλέον, παρέχουν τη δυνατότητα ανταλλαγής διαγνωστικών πληροφοριών μεταξύ των μελών της επικοινωνίας. Μοντέλο επεκτασιμότητας Το μοντέλο αυτό χρησιμοποιεί SOAP επικεφαλίδες για την υλοποίηση προεκτάσεων πάνω στο SOAP. Οι επικεφαλίδες περιέχουν κομμάτια από δεδομένα με δυνατότητα επέκτασης, τα οποία ταξιδεύουν μαζί με το μήνυμα και μπορούν να γίνουν στόχος για επέκταση σε συγκεκριμένους κόμβους του δικτύου. Ευέλικτος μηχανισμός για αναπαράσταση δεδομένων Ο μηχανισμός αυτός επιτρέπει στα δεδομένα σε οποιαδήποτε σειριακή μορφή κι αν βρίσκονται να αναπαρασταθούν σε XML μορφή. Σύμβαση για αναπαράσταση των RPCs και των απαντήσεών τους σαν SOAP μηνύματα Οι απομακρυσμένες κλήσεις διαδικασιών είναι αρκετά διαδεδομένες στον κατανεμημένο προγραμματισμό/ υπολογισμό και μπορούν να αναπαρασταθούν καλά μέσω του μηχανισμού αυτού σαν SOAP μηνύματα. Πρωτόκολλο εγκαθίδρυσης σύνδεσης Το πρωτόκολλο αυτό ορίζει μια αρχιτεκτονική για την οικοδόμηση συνδέσεων επικοινωνίας ώστε να είναι εφικτή η ανταλλαγή SOAP μηνυμάτων πάνω σε μέσα μεταφοράς και επικοινωνιακά κανάλια. Χρησιμοποιείται το HTTP πρωτόκολλο, καθώς είναι το πιο διαδεδομένο και ευρέως χρησιμοποιούμενο στο διαδίκτυο. Όσον αφορά στα μηνύματα SOAP, εφόσον το πρωτόκολλο είναι βασισμένο στην XML, είναι αναμενόμενο τα μηνύματα να έχουν μια τέτοια μορφή και ουσιαστικά να μην είναι τίποτε άλλο, παρά 27

38 XML έγγραφα. Το στοιχείο-ρίζα του μηνύματος είναι το soapenv:envelope, το οποίο περικλείει το στοιχείο soapenv:body, που περιέχει πληροφορία σχετιζόμενη με το σκοπό του μηνύματος. Το στοιχείο soapenv:body με τη σειρά του μπορεί να περιέχει άλλα στοιχεία, τα οποία να σχετίζονται ή να αναπαριστούν την απομακρυσμένη κλήση διαδικασίας που πρόκειται να εκτελεστεί. Το όνομα της μεθόδου που θα κληθεί και το όνομα του στοιχείου αυτού περιέχονται μέσα στο σώμα του μηνύματος. Τα μηνύματα αυτά στέλνονται μέσω πρωτοκόλλου HTTP.με τη μέθοδο POST. Η απάντηση σε ένα τέτοιο μήνυμα, που και πάλι μεταφέρεται μέσω HTTP είναι και αυτή ένα SOAP μήνυμα. Το μήνυμα της απάντησης περικλείεται κι αυτό από το συστατικό soapenv:envelope, που περιέχει το soapenv:body, το οποίο ενσωματώνει και τη βασική πληροφορία του μηνύματος, στην οποία συγκαταλέγεται και μια κωδικοποιημένη αναπαράσταση του αποτελέσματος της απομακρυσμένης κλήσης που πραγματοποιήθηκε. Το SOAP παρέχει, όπως ήδη αναφέρθηκε, τη δυνατότητα σε ένα μήνυμα να συμπεριλαμβάνονται στοιχεία επικεφαλίδες. Ο ρόλος τους είναι και ο σημαντικότερος λόγος που χρησιμοποιούμε τα μηνύματα SOAP και όχι απλά XML έγγραφα. Τα στοιχεία αυτά (headers) έχουν την ιδιότητα να αναπαριστούν ένα επιπρόσθετο και επεκτάσιμο είδος πληροφορίας το οποίο μεταφέρεται μαζί με το υπόλοιπο μήνυμα, χωρίς να τροποποιείται ο κυρίως πυρήνας του μηνύματος. Για να γίνει κατανοητό αυτό ας δούμε ένα παράδειγμα της αληθινής ζωής ακριβώς αντίστοιχο με την ιδέα των SOAP μηνυμάτων. Ας υποθέσουμε ότι θέλουμε να στείλουμε ένα έγγραφο αλλά και κάποιες επιπρόσθετες πληροφορίες χωρίς όμως να θέλουμε να μαρκάρουμε το έγγραφο με αυτές. Τοποθετούμε, λοιπόν, το έγγραφο στο φάκελο και στη συνέχεια προσθέτουμε μία ή δύο σελίδες χαρτί, οι οποίες περιγράφουν την επιπλέον πληροφορία που θέλαμε να στείλουμε. Η αντιστοιχία του παραδείγματος αυτού με το πρωτόκολλο που περιγράφουμε είναι ότι ο φάκελος είναι το στοιχείο soapenv:envelope, το έγγραφο που θέλουμε να στείλουμε είναι το στοιχείο soapenv:body και οι σελίδες με την επιπλέον πληροφορία είναι τα στοιχεία επικεφαλίδες (headers). Η χρήση των επικεφαλίδων για την προσθήκη λειτουργικότητας σε ένα μήνυμα SOAP είναι γνωστή και σαν κατακόρυφη επέκταση, γιατί τα στοιχεία αυτά τοποθετούνται στην κορυφή του μηνύματος πριν το σώμα του. Για λόγους ασφάλειας σε περιπτώσεις επεκτασιμότητας χρησιμοποιώντας στοιχεία επικεφαλίδες, η προδιαγραφή του SOAP ορίζει τη μεταβλητή mustunderstand. Όταν η τιμή της είναι αληθής, τότε ο παραλήπτης του μηνύματος πρέπει να συμφωνήσει 28

39 ότι αποδέχεται όλους τους όρους της επικεφαλίδας του μηνύματος προκειμένου να συνεχιστεί η επεξεργασία του. Στην περίπτωση που η τιμή της μεταβλητής αυτή είναι ψευδής, τότε η επικεφαλίδα έχει προαιρετικό ρόλο και η επεξεργασία του μηνύματος μπορεί να γίνει και από παραλήπτες που αγνοούν τις προδιαγραφές που θέτει η επικεφαλίδα. Αντίστοιχα με την κατακόρυφη επεκτασιμότητα, υπάρχει και η οριζόντια, η οποία έχει να κάνει με την αντιστοίχηση διαφορετικών κομματιών του μηνύματος με διαφορετικούς παραλήπτες. Αυτό επιτυγχάνεται μέσω των μεσολαβητών SOAP (SOAP intermediaries). Αυτές οι εφαρμογές μπορούν να επεξεργάζονται μέρη του μηνύματος SOAP καθώς αυτό ταξιδεύει προς τον τελικό του προορισμό. Οι μεσολαβητές μπορούν να αποδέχονται και να προωθούν μηνύματα καθώς κάνουν και κάποιο είδος επεξεργασίας. Σε γενικές γραμμές, στον αληθινό κόσμο σπάνια ξεκινά ένα μήνυμα από κάποια τοποθεσία και φθάνει απευθείας στον προορισμό του. Για παράδειγμα ας πάρουμε το ηλεκτρονικό ταχυδρομείο. Όταν στέλνουμε ένα μήνυμα αυτό θα περάσει από διάφορους εξυπηρέτες και δρομολογητές προτού «εντοπίσει» τον προορισμό του. Αυτός είναι ένας από τους κυριότερους λόγους που χρειάζονται οι μεσολαβητές στα μηνύματα SOAP, καθώς επίσης χάρη σε αυτούς μπορούμε να έχουμε υπηρεσίες προστιθέμενης αξίας σε κατανεμημένα συστήματα. Έχοντας περιγράψει αρκετά το SOAP, φτάνουμε στα εξής βήματα που τελικά πρέπει να πραγματοποιηθούν από έναν παραλήπτη ή ένα μεσολαβητή κάποιου μηνύματος SOAP: Πρέπει να κατανοηθεί το σύνολο των κανόνων που περιέχει το μήνυμα που παραλείφθηκε. Τα στοιχεία επικεφαλίδες κυρίως μπορεί να περιέχουν τέτοιο πληροφορία. Πρέπει να προσδιοριστούν όλα τα σύνολα που ορίζουν τα στοιχεία επικεφαλίδες με προσοχή. Αν κάποιο σημείο δεν είναι κατανοητό και αυτό έχει να κάνει με τη μεταβλητή mustunderstand τότε πρέπει να συνταχθεί ένα μήνυμα λάθους (SOAP fault). Σε τέτοιο περίπτωση η περαιτέρω επεξεργασία του μηνύματος πρέπει να σταματήσει. Λάθη που έχουν να κάνουν με το σώμα του μηνύματος δεν εντοπίζονται σε αυτό το βήμα. Ακολουθεί επεξεργασία των επικεφαλίδων. Σε περίπτωση που το μήνυμα βρίσκεται στον τελικό παραλήπτη και όχι σε κάποιον ενδιάμεσο, τότε γίνεται και η επεξεργασία του σώματος του μηνύματος. Στην περίπτωση που το μήνυμα βρίσκεται σε κάποιον ενδιάμεσο μεσολαβητή και δεν υπάρχει κάποιο πρόβλημα με την έννοια ότι δεν υπήρξε ανάγκη να συνταχθεί κάποιο μήνυμα λάθους τότε η πορεία του μηνύματος συνεχίζεται με την προώθησή του στον επόμενο κόμβο, όπου ακολουθείται η ίδια διαδικασία. 29

40 Ουσιαστικά οι μεταβλητή mustunderstand έχει σα ρόλο να μας δίνει την ευκαιρία να ορίζουμε τι ακριβώς διαδικασίες θα γίνονται σε κάθε κόμβο από τον οποίο περνάει το μήνυμα μέχρι να φτάσει στον τελικό του προορισμό. Όσον αφορά στα μηνύματα λάθους, αυτά είναι απλά μηνύματα SOAP, τα οποία περιέχουν ένα απλό στοιχείο μέσα στο soapenv:body, το soapenv:fault. Η παρουσία αυτού του στοιχείου σηματοδοτεί ότι κάπου υπήρξε κάποιο λάθος. Το μήνυμα λάθους έχει κάποια συγκεκριμένη και καλά ορισμένη δομή ώστε να παρέχει πληροφορία σχετική με το λάθος που συνέβη. Το στοιχείο env:code περιέχει όλη την απαραίτητη κωδικοποιημένη πληροφορία για το σκοπό αυτό. Από τις πληροφορίες αυτές μπορούμε να διαπιστώσουμε εάν το λάθος προέκυψε λόγω λανθασμένης ή ελλιπούς πληροφορίας από τον αποστολέα, ή λόγω κάποιου λάθους που συνέβη κατά την επεξεργασία του από κάποιον παραλήπτη. Επίσης το λάθος μπορεί να σχετίζεται με την σχέση κάποιου μεσολαβητή με την τιμή της μεταβλητής mustunderstand. Τέλος, ο λόγος προελεύσεώς του μπορεί να είναι οι μη συμβατές εκδόσεις του πρωτοκόλλου που χρησιμοποιούνταν από κόμβο σε κόμβο. Τα μηνύματα λάθους, ως κανονικά SOAP μηνύματα που είναι, μπορούν να επεκτείνονται με την παρουσία στοιχείων επικεφαλίδων, τα οποία μπορεί να περιέχουν επιπλέον πληροφορία για την ανίχνευση του λάθους και να συμβάλλουν στη συντήρηση των υπηρεσιών πάνω στο δίκτυο. Ένα εργαλείο για την πραγματοποίηση SOAP συναλλαγών είναι ο Apache Axis, μια μηχανή SOAP ανοιχτού λογισμικού. 3.5Γλώσσα Περιγραφής Υπηρεσιών Διαδικτύου WSDL Μέχρι εδώ έχουμε μιλήσει για το SOAP. Έχουμε εξηγήσει ότι είναι βασισμένο στην XML και ότι μέσω αυτού του πρωτοκόλλου μπορούν να γίνουν αιτήσεις για απομακρυσμένες κλήσεις διαδικασιών από κάποιον πελάτη σε κάποιον εξυπηρέτη. Από τη μεριά του πελάτη όμως υπάρχουν δυσκολίες στη σύνταξη του μηνύματος SOAP, καθώς ο πελάτης δε μπορεί να ξέρει τι ακριβώς μήνυμα να στείλει. Το SOAP καθορίζει κάποιους κανόνες και προσφέρει μια συγκεκριμένη φόρμα για τα μηνύματα, αλλά πρέπει να βρεθεί κάποιος άλλος τρόπος ώστε ο πελάτης να είναι σε θέση να γνωρίζει τι μήνυμα να στείλει στον εξυπηρέτη του παροχέα της υπηρεσίας. Επίσης, ο πελάτης πρέπει να γνωρίζει αρκετές λεπτομέρειες προτού στείλει το μήνυμα. Πρέπει να γνωρίζει καταρχάς που ακριβώς να το στείλει, ή ποιες μεθόδους θέλει να καλέσει από την υπηρεσία, ή ποια πρωτόκολλα επικοινωνίας υποστηρίζονται από τον παροχέα της υπηρεσίας. 30

41 Προκειμένου να γνωρίζει ο πελάτης όλες τις απαραίτητες πληροφορίες για την κλήση μιας υπηρεσίας διαδικτύου, πρέπει να έχει στην κατοχή του μια περιγραφή αυτής. Για να γίνει η όλη διαδικασία ακόμη πιο εύκολη και πιο τυποποιημένη χρειάζεται ένας καθορισμένος μηχανισμός για την περιγραφή των υπηρεσιών διαδικτύου. Αυτός ο μηχανισμός θα παρέχει πληροφορίες για ακριβώς αυτά που χρειάζεται να ξέρει ο χρήστης που θέλει να καλέσει την υπηρεσία. Επιπρόσθετα, χάρη σε αυτόν το μηχανισμό είναι δυνατή η ανάπτυξη εφαρμογών που θα βοηθούν τους προγραμματιστές στην ανάπτυξη των υπηρεσιών μέσω των περιγραφών τους. Όπως έχει αναφερθεί και σε προηγούμενη ενότητα, ο ρόλος της υπηρεσίας καταλόγου (Service Registry) σε μια SOA αρχιτεκτονική είναι πολύ σημαντικός. Ο πελάτης, προκειμένου να ανακαλύψει την υπηρεσία που τον ενδιαφέρει, ψάχνει πρώτα στον κατάλογο αυτό. Το αποτέλεσμα της αναζήτησης δεν είναι τίποτε άλλο από την περιγραφή της υπηρεσίας που ζήτησε. Ο παροχέας της υπηρεσίας διαδικτύου, λοιπόν, δημοσιεύει την περιγραφή της υπηρεσίας του γι αυτό το λόγο. Για να ξέρει ο κάθε πιθανός πελάτης πώς να εγκαθιδρύσει επικοινωνιακή σύνδεση μαζί του και πως ακριβώς να καλέσει την υπηρεσία που του παρέχει. Μια καλή περιγραφή μιας υπηρεσίας διαδικτύου πρέπει να αποτελείται από δύο μέρη: Τη λειτουργική περιγραφή Η περιγραφή αυτή περιγράφει ποιες ακριβώς λειτουργίες είναι διαθέσιμες από την υπηρεσία διαδικτύου και ποια είναι η απαιτούμενη σύνταξη που θα πρέπει να έχει το SOAP μήνυμα προκειμένου να γίνει με επιτυχία η κλήση. Επίσης, πληροφορίες σχετικές με την τοποθεσία της υπηρεσίας είναι διαθέσιμες ώστε ο χρήστης να έχει το ακριβές URL στο οποίο θα γίνει η κλήση. Είναι χρέος της περιγραφής αυτής να δώσει όλες τις απαραίτητες πληροφορίες στον πελάτη ώστε να καλέσει την υπηρεσία. Τη μη-λειτουργική περιγραφή Η λειτουργική περιγραφή είναι πολύ σημαντική, αφού χωρίς αυτή δεν είναι δυνατόν να επιτευχθεί η κλήση της υπηρεσίας. Η μη-λειτουργική περιγραφή όμως είναι εξίσου σημαντική. Όπως υποδηλώνει και το όνομά της, προσφέρει πληροφορίες που σχετίζονται με μη λειτουργικές απαιτήσεις της υπηρεσίας. Τέτοιες πληροφορίες μπορεί να περιγράφουν το λόγο που κάποιος πελάτης να επιθυμεί να καλέσει την υπηρεσία. Επίσης, μπορεί να περιγράφουν τον παροχέα της υπηρεσίας με αρκετή λεπτομέρεια. Μπορεί να προσφέρουν προσωπικά του στοιχεία και τηλέφωνα επικοινωνίας. Τέλος, πληροφορίες για την ασφάλεια γύρω από την υπηρεσία και την πολιτική του παροχέα μπορεί να είναι διαθέσιμες μέσω της μη λειτουργικής περιγραφής της υπηρεσίας. 31

42 Η ευρέως χρησιμοποιούμενη και καθιερωμένη γλώσσα περιγραφής υπηρεσιών διαδικτύου είναι η WSDL (Web Services Description Language). Είναι μια γλώσσα βασισμένη στην XML και περιγράφει τρεις σημαντικές ιδιότητες της υπηρεσίας: Τι κάνει η υπηρεσία Εδώ περιγράφονται οι μέθοδοι της υπηρεσίας, οι παράμετροί της και τα αποτελέσματα που επιστρέφει. Πώς γίνεται η πρόσβαση στην υπηρεσία Εδώ παρέχονται όλες οι απαραίτητες πληροφορίες για τη σύνταξη των SOAP μηνυμάτων που θα ανταλλαγούν, καθώς και τα πρωτόκολλα που υποστηρίζονται από τον παροχέα. Που βρίσκεται η υπηρεσία Εδώ παρέχονται πληροφορίες για τη δικτυακή διεύθυνση της υπηρεσίας. Συνήθως είναι ένα URL. Όπως κάθε καλά ορισμένη γλώσσα βασισμένη σε XML, έτσι και η WSDL ορίζει κάποια βασικά στοιχεία που συναντώνται σε ένα WSDL έγγραφο. Τα κυριότερα από αυτά είναι: porttype Είναι ένας αφαιρετικός ορισμός της διασύνδεσης της υπηρεσίας διαδικτύου. Ουσιαστικά, σκοπός του είναι η περιγραφή αυτής της διασύνδεσης. Όπως γίνεται σε έναν κώδικα Java, που η διασύνδεση αποτελείται μόνο από τις υπογραφές των μεθόδων, έτσι κι εδώ ο ορισμός του porttype είναι η συλλογή των λειτουργιών που παρέχει η υπηρεσία διαδικτύου. Ένα τέτοιο στοιχείο μπορεί να έχει ένα απλό όνομα, το οποίο πιθανόν να σχετίζεται με τη λειτουργία που προσφέρει η υπηρεσία. Εάν ένα έγγραφο WSDL περιέχει πολλά τέτοια στοιχεία, τότε το κάθε ένα οφείλει να έχει διαφορετικό όνομα. Message Καθορίζει τη μορφή του μηνύματος, καθώς και το σύνολο των παραμέτρων που σχετίζονται με τις μεθόδους της υπηρεσίας. Το στοιχείο αυτό μπορεί να αποσυντεθεί σε πολλά μέρη, που ονομάζονται parts. Κάθε στοιχείο message μέσα σε ένα WSDL έγγραφο πρέπει να έχει ένα μοναδικό όνομα ώστε να ξεχωρίζει από τα υπόλοιπα. Ουσιαστικά, τα στοιχεία αυτά δεν παρουσιάζουν ιδιαίτερο ενδιαφέρον αφού δεν είναι τίποτε άλλο από μια συλλογή από parts και κάθε part έχει ένα όνομα, που συνήθως αντικατοπτρίζει την πληροφορία που περιέχεται στο part. Types Ορίζει τη συλλογή όλων των τύπων δεδομένων που χρησιμοποιούνται από την υπηρεσία διαδικτύου. Το εξ ορισμού σύστημα των τύπων δεδομένων στην WSDL είναι το XML σχήμα (XML Schema XSD). Το σχήμα αυτό μπορεί να χρησιμοποιηθεί για να περιγράψει όλους τους τύπους δεδομένων που μπορεί να χρησιμοποιηθούν στα διάφορα μηνύματα που ανταλλάσσονται για την κλήση της υπηρεσίας. Το στοιχείο types είναι ένα μέρος για το WSDL έγγραφο στο οποίο ο χρήστης ορίζει τύπους δεδομένων που θα χρησιμοποιηθούν σε άλλα στοιχεία του εγγράφου. 32

43 Binding Περιέχει λεπτομέρειες για το πώς τα στοιχεία σε μια αφαιρετική δομή (όπως το porttype) μπορούν να μετασχηματισθούν σε μια συμπαγή αναπαράσταση των δεδομένων και πρωτοκόλλων που θα χρησιμοποιηθούν για την επικοινωνία μεταξύ του πελάτη και της υπηρεσίας. Ουσιαστικά είναι το στοιχείο που θα πει στον πελάτη πώς ακριβώς να μορφοποιήσει το μήνυμα που θα στείλει για την κλήση της υπηρεσίας. Κάθε στοιχείο porttype μπορεί να έχει ένα ή περισσότερα στοιχεία binding συσχετισμένα με αυτό. Για ένα συγκεκριμένο στοιχείο porttype, ένα στοιχείο binding περιγράφει τον τρόπο που πρέπει να γίνει η κλήση των μεθόδων της υπηρεσίας χρησιμοποιώντας κάποιο καθορισμένο πρωτόκολλο, όπως το SOAP, πάνω σε κάποιο επίσης καθορισμένο πρωτόκολλο μεταφοράς, όπως το HTTP. Το όνομα του binding πρέπει να είναι μοναδικό καθώς πολλά τέτοια στοιχεία μπορεί να υπάρχουν σε ένα WSDL έγγραφο. Port Περιγράφει πως ακριβώς εκφράζεται ένα binding σε μια φυσική θύρα του δικτύου. Ο ρόλος της είναι πολύ απλός αφού δεν κάνει τίποτε άλλο από μια απλή αντιστοιχία. Τα στοιχεία αυτά, όπως και τα προηγούμενα, οφείλουν να φέρουν ένα όνομα, μοναδικό μέσα στο WSDL έγγραφο. Συνήθως, τα στοιχεία αυτά υποδεικνύουν το URL στο οποίο πρέπει να σταλούν τα μηνύματα SOAP ώστε να γίνει η κλήση της υπηρεσίας. Τα στοιχεία αυτά δε συναντούνται μόνα τους μέσα στο έγγραφο της περιγραφής της υπηρεσίας. Είναι στοιχεία παιδιά του συστατικού service. Service Ένα τέτοιο στοιχείο είναι μια συλλογή από ports. Το στοιχείο αυτό μπορεί να έχει ένα μοναδικό όνομα μέσα στο έγγραφο. Παρόλο που ο ρόλος του δεν έχει ιδιαίτερη σημασία, είναι καλό τα στοιχεία port να ομαδοποιούνται κάτω από ένα στοιχείο service. Συνήθως όμως ένα μόνο στοιχείο port συναντάται και έτσι καταλήγουμε στο να έχουμε ένα στοιχείο service, που να περιέχει ένα στοιχείο port. Το σχήμα που ακολουθεί απεικονίζει τις συσχετίσεις μεταξύ των συστατικών της WSDL. 33

44 Σχήμα 11. Το πληροφοριακό μοντέλο της WSDL Η δομή ενός WSDL εγγράφου ξεκινά με ένα στοιχείο ορισμών, το οποίο καλείται definitions. Το στοιχείο αυτό περιέχει όλα τα υπόλοιπα στοιχεία που μπορεί να συναντηθούν μέσα στο έγγραφο, δηλαδή μπορεί να περιέχει: Κανένα ή οσαδήποτε στοιχεία τεκμηρίωσης. Τα στοιχεία αυτά καλούνται documentation elements και χρησιμοποιούνται για να παρέχουν χρήσιμες πληροφορίες κατανοητές από τον άνθρωπο γύρω από την υπηρεσία διαδικτύου. Κανένα ή οσαδήποτε στοιχεία εισαγωγών. Τα στοιχεία αυτά καλούνται import elements. Τα στοιχεία δίνουν τη δυνατότητα επαναχρησιμοποίησης ήδη υπαρχόντων WSDL εγγράφων επιτρέποντας σε διάφορα στοιχεία να έχουν αναφορές σε άλλα ήδη υπάρχοντα που βρίσκονται σε διαφορετικό έγγραφο σε διαφορετικό αρχείο. Προαιρετικά ένα στοιχείο types. Κανένα ή οσαδήποτε στοιχεία message. Κανένα ή οσαδήποτε στοιχεία porttype. Συνήθως μόνο ένα συναντάται. Κανένα ή οσαδήποτε στοιχεία binding. Συνήθως μόνο ένα συναντάται, το οποίο έχει να κάνει με το στοιχείο porttype. Κανένα ή οσαδήποτε στοιχεία service. Και πάλι συνήθως μόνο ένα είναι αρκετό. Τέλος, η έκδοση που χρησιμοποιείται ευρέως είναι η 1.1 της WSDL. Σημαντικές βελτιώσεις αναμένονται στην έκδοση 2.0, στην οποία υπάρχει ο ισχυρισμός ότι θα υποστηρίζει κάποιου είδους σημασιολογικής πληροφορίας σε μικρό βαθμό. 34

45 3.6Universal Description, Discovery and Integration (UDDI) Στις αρχές του 2000, και καθώς η ιδέα των υπηρεσιών ιστού άρχισε να κερδίζει έδαφος μέσα στην κοινότητα, έγινε σαφές ότι η καταχώρηση σε καταλόγους των υπηρεσιών ιστού ήταν κάτι απαραίτητο για να μπορέσει να εφαρμοστεί πρακτικά η ιδέα. Επιπλέον, λόγο της γενικότερης στροφής προς τα ανοικτά πρότυπα, οτιδήποτε εκτός από έναν πρότυπο μηχανισμό αλληλεπίδρασης και αναζήτησης δε θα μπορούσε να γίνει αποδεκτό. Ένα τέτοιο πρότυπο καταλόγου, θα έπρεπε να υποστηριχθεί και από τις περισσότερες, αν όχι από όλες τις μεγάλες εταιρίες παροχής λογισμικού, και να υιοθετηθεί από τις διάφορες βιομηχανίες. Έτσι η πρωτοβουλία του UDDI, που ήταν το αποτέλεσμα πολλών μηνών συνεργασίας μεταξύ αντιπροσώπων από τις Ariba, IBM, και Microsoft, που ξεκίνησε την άνοιξη του 2000, γεννήθηκε και ανακοινώθηκε επίσημα στις 6 Σεπτεμβρίου Η υποστήριξη για το UDDI επεκτάθηκε και πέρα από τις τρεις εταιρίες που συμμετείχαν αρχικά και αυτή τη στιγμή, το έργο UDDI περιλαμβάνει μια κοινότητα που αριθμεί πάνω από 310 εταιρίες. Ο σκοπός του UDDI είναι να διευκολύνει την ανακάλυψη υπηρεσιών και κατά το χρόνο σχεδίασης, και δυναμικά κατά το χρόνο εκτέλεσης. Συνεπώς το UDDI λειτουργεί ως ένα κοινό άμεσα συνδεδεμένο κατάλογο (και των αντιστοίχων υπηρεσιών), το οποίο λειτούργησε για πρώτη φορά στις 2 Μαΐου Ο κατάλογος αυτός, συνήθως αναφέρεται ως κατάλογος επιχειρήσεων UDDI (UDDI Business Registry). Ο κατάλογος αυτός, στην πραγματικότητα αποτελείται από 2 πανομοιότυπους καταλόγους, που διατηρούνται αυτή τη στιγμή από δύο εταιρίες (IBM και Microsoft), οι οποίοι και αποκαλούνται οι διαχειριστές του UDDI. Για να γίνει κάποιος διαχειριστής ενός τέτοιου καταλόγου, πρέπει να ακολουθήσει αυστηρές συμφωνίες για την αντιγραφή των δεδομένων, το απόρρητο των δεδομένων και τις διάφορες πολιτικές. Από την οπτική μιας καταχωρημένης επιχείρησης αλλά και από την οπτική του απλού χρήστη, η απαίτηση είναι να μην υπάρχει διαφορά ανάμεσα στα διαφορετικά αντίγραφα του καταλόγου. Οι επιχειρήσεις μπορούν να κάνουν εγγραφή σε οποιονδήποτε διαχειριστή UDDI, και τα δεδομένα τους θα αντιγραφούν σε όλα τα άλλα αντίγραφα του καταλόγου στους άλλους διαχειριστές. Επομένως, οι χρήστες μπορούν να αναζητήσουν στον κατάλογο οποιουδήποτε διαχειριστή για να βρουν τις επιχειρήσεις που αναζητούν, άσχετα με το διαχειριστή που έχει επιλέξει η συγκεκριμένη επιχείρηση για να εγγραφεί. Υπάρχουν όμως κάποια λεπτά θέματα που έχουν σχέση με την απόφαση σχετικά με το ποιον διαχειριστή να χρησιμοποιήσει μια επιχείρηση για να εγγραφεί. Για παράδειγμα, κάποιοι διαχειριστές μπορεί να ζητούν επιπρόσθετες προαιρετικές πληροφορίες που δεν 35

46 απαιτούνται από το UDDI. Αυτή η πληροφορία δεν αντιγράφεται στα αντίγραφα του καταλόγου στους άλλους διαχειριστές. Επιπλέον, αυτό που πρέπει να σημειωθεί είναι ότι από τη στιγμή που μια επιχείρηση επιλέξει κάποιο διαχειριστή για να εγγραφεί, η οποιαδήποτε ενημέρωση και τροποποίηση των στοιχείων θα πρέπει να γίνει από τον ίδιο διαχειριστή. Αυτό πρέπει να γίνεται έτσι δεδομένου ότι ο κάθε διαχειριστής ακολουθεί διαφορετικές πολιτικές πιστοποίησης και ασφάλειας, και επομένως η πληροφορία πιστοποίησης δεν είναι εύκολο να αντιγραφεί στους άλλους διαχειριστές. Το UDDI είναι κάτι παραπάνω από ένα κατάλογο επιχειρήσεων και υπηρεσιών. Ορίζει ένα σύνολο από δομές δεδομένων και προδιαγραφές ΑΡΙ, για την προγραμματική αναζήτηση και καταχώρηση εταιριών, υπηρεσιών, δεσμών, και ειδών υπηρεσιών. Στα τυπικά σενάρια υπηρεσιών διαδικτύου, οι παροχείς υπηρεσιών διαδικτύου θα θελήσουν να δημοσιεύσουν τις περιγραφές των εταιριών και των υπηρεσιών τους σε ένα κατάλογο, και όσοι αναζητούν υπηρεσίες, είτε κατά τη σχεδίαση, είτε κατά την εκτέλεση, θα θελήσουν να αναζητήσουν στον κατάλογο περιγραφές υπηρεσιών. Οι προδιαγραφές ΑΡΙ του UDDI παρέχουν γι αυτό το λόγο ένα σύνολο από προγραμματιστικές διεπαφές (ΑΡΙ) δημοσίευσης για την καταχώρηση υπηρεσιών, και αντίστοιχες διεπαφές ερωτήσεων ΑΡΙ για την εύρεση υπηρεσιών. Επιπλέον από την παροχή μιας προγραμματιστικής διεπαφής, οι διαχειριστές του καταλόγου UDDI, παρέχουν ένα σύστημα αλληλεπίδρασης με το χρήστη, βασισμένο στο διαδίκτυο, για την καταχώρηση, διαχείριση, ανεύρεση εταιριών και υπηρεσιών μέσα στον κατάλογο Το μοντέλο χρήσης του UDDI Σε αυτήν την ενότητα θα εξεταστούν αρχικά οι τυπικές απαιτήσεις για ένα κατάλογο μεταδεδομένων, ορίζοντας κάποια τυπικά στοιχεία δεδομένων και κάποιες λειτουργίες. Τέλος, θα γίνει μια γενική περιγραφή των δομών δεδομένων και των ΑΡΙ του UDDI, συσχετίζοντάς τα με τις αρχικές απαιτήσεις Οι απαιτήσεις του καταλόγου UDDI Οι κατάλογοι γενικά, είτε είναι φτιαγμένα για στοιχεία λογισμικού, για υπηρεσίες, είτε για κάποιο άλλο σκοπό, έχουν κάποιες βασικές απαιτήσεις: Ένα σύνολο από προδιαγραφές δομών δεδομένων για τα μεταδεδομένα που θα αποθηκευθούν στον κατάλογο. Ένα σύνολο από προδιαγραφές λειτουργιών Δημιουργίας, Ανάγνωσης, Ενημέρωσης, Διαγραφής (CRUD Create, Read, Update, Delete) για την αποθήκευση, διαγραφή, και ερώτηση των δεδομένων του καταλόγου. Οι συνήθεις απαιτήσεις για τα μεταδεδομένα είναι: 36

47 Ιδιοκτησία και περιεχόμενο, δηλαδή ότι κάποιος πρέπει να είναι ο ιδιοκτήτης των δεδομένων που δημοσιεύει, καθώς και όλων των δεδομένων που περιέχονται σε αυτά, εκτός εάν δηλωθεί διαφορετικά. Κατηγοριοποίηση, δηλαδή τα δεδομένα μπορούν να είναι ταξινομημένα σε μια ή περισσότερες κατηγορίες, για να διευκολύνουν την οργάνωση και την αναζήτηση. Οι συνήθεις απαιτήσεις για τις λειτουργίες του καταλόγου είναι: Η πιστοποίηση για διαδικασίες που αλλάζουν δεδομένα και για δημόσιους καταλόγους. Η ελεύθερη πρόσβαση για λειτουργίες ερώτησης και ανάγνωσης. Το τμήμα του καταλόγου UDDI, διαθέτει ένα μοντέλο πληροφορίας που αντιπροσωπεύει τις προδιαγραφές των δομών δεδομένων, και μια προγραμματιστική διεπαφή για τις προδιαγραφές των λειτουργιών. Το μοντέλο πληροφοριών του UDDI σχεδιάστηκε με τέτοιο τρόπο ώστε να είναι ευέλικτο και επεκτάσιμο, επιτρέποντας έτσι και τη χρήση οποιουδήποτε μοντέλου περιγραφής υπηρεσιών που θα επιθυμούσε να ορίσει κάποιος χρήστης. Επειδή οι προδιαγραφές του UDDI είναι μια διαδικασία συνεχούς βελτίωσης και επέκτασης, στη συνέχεια θα περιγραφούν οι προδιαγραφές της έκδοσης 1.0 του UDDI. Οι μελλοντικές εκδόσεις το μόνο που θα κάνουν είναι να προσθέσουν περαιτέρω λειτουργικότητες πάνω στην τρέχουσα έκδοση, και να αντιμετωπίσουν προβλήματα που ανακύπτουν σε θέματα αντιγραφής, εκδόσεων και ασφάλειας Οι δομές δεδομένων του UDDΙ Γενική περιγραφή Οι προδιαγραφές της έκδοσης 1.0 του UDDI, επιτρέπουν σε οντότητες όπως εταιρίες και οργανισμοί να καταχωρούν δημόσια πληροφορία για αυτούς και πληροφορίες για τις υπηρεσίες που παρέχουν. Επιπλέον επιτρέπει σε οντότητες όπως επιχειρήσεις, ομάδες προτύπων, και ομάδες βιομηχανιών, να καταχωρούν πληροφορίες για τα είδη υπηρεσιών που έχουν ορίσει, περιγραφές προτύπων και εννοιών, και να αναφέρονται σε αυτά με αναγνωριστικά ονόματα που τους έχουν ορίσει. Κατά συνέπεια, το UDDI φαίνεται σαν να προσφέρει δυο διαφορετικούς καταλόγους: έναν επαγγελματικό, και ένα κατάλογο τύπου αναφοράς. Σε απόλυτη αντιστοιχία, το UDDI έχει στον πυρήνα του δυο βασικές ριζικές δομές δεδομένων, τις businessentity και tmodel. 37

48 Σχήμα 11. Μοντέλο πληροφορίας του UDDI Η δομή δεδομένων businessentity Η πληροφορία της οντότητας της επιχείρησης διαχωρίζεται θεμελιωδώς σε μέρη που είναι γνωστά με τους όρους Λευκές, Κίτρινες, και Πράσινες σελίδες: Οι Λευκές σελίδες περιέχουν γενικές πληροφορίες επικοινωνίας με την οντότητα. Οι Κίτρινες σελίδες περιέχουν πληροφορίες ταξινόμησης για τους τύπους και την τοποθεσία των υπηρεσιών που προσφέρει η οντότητα. ΟΙ Πράσινες σελίδες περιέχουν πληροφορίες για τις τον τρόπο με τον οποίο μπορεί κάποιος να έχει πρόσβαση στις υπηρεσίες που προσφέρονται. Είναι απαραίτητο να σημειωθεί ότι αυτό είναι απλά ένα θεμελιώδες μοντέλο, και πως το UDDI δεν καθορίζει κάποιο συγκεκριμένο μοντέλο αποθήκευσης. Μια καταχώρηση μιας οντότητας στις λευκές σελίδες θα περιέχει και πληροφορίες ταξινόμησης, που θα δείχνουν τη θέση της οντότητας αυτής στις κίτρινες σελίδες, και επίσης, μια καταχώρηση μιας υπηρεσίας κάποιας οντότητας θα περιέχει πληροφορίες υλοποίησης που θα δείχνουν τη θέση της οντότητας αυτής μέσα στις πράσινες σελίδες. Αυτό αντανακλάται στις λεπτομέρειες της δομής businessentity. Το στοιχείο businessentity, πέρα από κάποιες πληροφορίες επικοινωνίας, αναγνώρισης και ταξινόμησης, περιέχει ένα businessservices στοιχείο, που είναι ένα πεδίο για στοιχεία τύπου businessservice. Ένα στοιχείο businessservice με τη σειρά του, περιέχει ένα στοιχείο bindingtemplates, το οποίο είναι ένα πεδίο για στοιχεία τύπου bindingtemplate. Τέλος, οι καταχωρήσεις bindingtemplate δείχνουν σε καταχωρήσεις 38

49 tmodel. Οι συσχετίσεις απεικονίζονται στο. που περιγράφονται παραπάνω, Η δομή δεδομένων tmodel Η άλλη σημαντική δομή του μοντέλου πληροφορίας του UDDI, είναι το στοιχείο tmodel. Οι καταχωρήσεις στις πράσινες σελίδες, είναι στην ουσία εξειδικευμένες πληροφορίες κάθε επιχείρησης που συνδέουν πληροφορίες για τύπους υπηρεσιών και άλλες έννοιες που ορίζονται αλλού. Αυτές οι επαναχρησιμοποιήσιμες έννοιες αποκαλούνται μοντέλα τεχνολογίας, και η δομή δεδομένων του UDDI που αντιστοιχεί είναι το στοιχείο tmodel. Αυτό το στοιχείο δίνει τη δυνατότητα σε ομάδες βιομηχανιών, σε σώματα προτύπων αλλά και σε μεμονωμένες επιχειρήσεις να μπορούν να καθορίζουν επαναχρησιμοποιήσιμους εννοιολογικούς ορισμούς τύπων υπηρεσιών, οι οποίοι μπορούν να χρησιμοποιηθούν και να συνδυαστούν, σχηματίζοντας μια υπογραφή για μια υπηρεσία. Στο σχήμα αναγνώρισης του UDDI, σε κάθε στιγμιότυπο των τεσσάρων τύπων εγγραφών εκχωρείται ένα μοναδικό αναγνωριστικό από τον κόμβο του UDDI κατά την αρχική εγγραφή. Επιπρόσθετα, και ανάλογα με το σχήμα περιεχομένου του UDDI, κάθε στιγμιότυπο μιας περιεχόμενης δομής κρατάει μια αναφορά κλειδί προς την περιεχόμενη οντότητα, σε μια αυστηρή σχέση γονέα τέκνου. Αυτά τα αναγνωριστικά είναι UUIDs (Universal Unique IDentifiers), που ακολουθούν τις συμβάσεις του OSF για κατανεμημένο υπολογιστικό περιβάλλον (Distributed Computing Environment ), και ακολουθούν το σχήμα (για παράδειγμα F775A3A6-FF3E-4B85-B1DE-F0F99D0E2C6D). Θεωρήθηκε πολύ σημαντικό για την επεκτασιμότητα του μοντέλου, οι ιδιωτικοί κατάλογοι UDDI να έχουν την ικανότητα να επεκτείνουν τη δομή businessentity, έτσι ώστε να μπορεί να διατηρεί δεδομένα που χρειάζονται για τους δικούς τους σκοπούς. Γι αυτήν την περίπτωση δημιουργήθηκε η οντότητα businessentityext. Οι διαχειριστές των καταλόγων UDDI πάντως δεν θα παρέχουν τέτοιες επεκτάσεις στα δεδομένα των επιχειρήσεων που διατηρούν στις δημόσια προσβάσιμες βάσεις τους Προγραμματιστική διεπαφή του UDDI Γενική περιγραφή Εκτός από τον ορισμό των δομών δεδομένων που θα αποθηκεύονται στον κατάλογο, οι προδιαγραφές του UDDI παρέχουν και δύο βασικούς τύπους προγραμματιστικών διεπαφών: την προγραμματιστική διεπαφή δημοσίευσης και την προγραμματιστική διεπαφή ερώτησης. Αυτές οι δύο διεπαφές ορίζουν ένα σύνολο από 20 μηνύματα SOAP για το πρωτόκολλο HTTP ή για το HTTPS, τα οποία πρέπει να είναι κατανοητά από 39

50 οποιοδήποτε κατάλογο συμβατό με το UDDI πρότυπο. Το SOAP τμήμα του μηνύματος καθώς και οι απαντήσεις είναι δομές της XML που καθορίζονται στις προδιαγραφές του UDDI. Η προγραμματιστική διεπαφή δημοσίευσης ορίζει είναι ένα πιστοποιημένο σύνολο λειτουργιών που επιτρέπει στους οργανισμούς να δημοσιεύουν πληροφορία για εταιρίες, υπηρεσίες, υλοποιήσεις ή είδη υπηρεσιών στον κατάλογο UDDI. Το UDDI δεν καθορίζει κάποια μέθοδο πιστοποίησης, εκτός από την απαίτηση για ύπαρξη κουπονιού πιστοποίησης (authorization token), και τη χρήση του πρωτοκόλλου HTTPS κατά τις διαδικασίες πιστοποίησης. Έτσι ο κάθε διαχειριστής θα πρέπει να έχει το δικό του μηχανισμό πιστοποίησης. Η αντίστοιχη προγραμματιστική διεπαφή ερωτήσεων, αποτελείται από ένα σύνολο από λειτουργίες οι οποίες δεν απαιτούν πιστοποίηση και επιτρέπουν στους χρήστες να λαμβάνουν τις πληροφορίες που αναζητούν από τον κατάλογο UDDI. Τα ερωτήματα μπορούν να γίνονται με βάση δύο γενικά σχήματα: ένα σχήμα με τη χρήση επόπτη διαδικτύου (browser) για την εύρεση γενικών πληροφοριών, το οποίο και συνήθως ακολουθείται από ένα σχήμα αναζήτησης σε βάθος, με βάση το οποίο αναζητούνται συγκεκριμένες λεπτομερείς πληροφορίες. Το UDDI παρέχει 4 λειτουργίες αποθήκευσης (save_business, save_service, save_binding και save_tmodel), 4 λειτουργίες διαγραφής (delete_business, delete_service, delete_binding και delete_tmodel), 4 λειτουργίες αναζήτησης (find_business, find_service, find_binding και find_tmodel), και 4 λειτουργίες αναζήτησης λεπτομερειών (get_businessdetail, get_servicedetail, get_bindingdetail και get_tmodeldetail), για κάθε ένα από τους 4 τύπους δομών (businessentity, businessservice, bindingtemplate και tmodel) αντίστοιχα (Πίνακας 1). Save/Updat e Delete Find GetDetail Business Service Binding tmodel save_business save_service save_binding save_tmodel delete_business find_business get_businessdet ail delete_service find_service get_servicedet ail delete_binding find_binding get_bindingdet ail delete_tmodel find_tmodel get_tmodeldet ail Πίνακας 1: Μηνύματα των προγραμματιστικών διεπαφών που ορίζονται από τις προδιαγραφές του UDDI. Οι λειτουργίες αποθήκευσης μπορούν να χρησιμοποιηθούν για τη δημιουργία μιας καινούριας εγγραφής αλλά και για τη διόρθωση μιας υπάρχουσας. Κατά τη δημιουργία μιας καινούριας εγγραφής, η αναγνωριστική παράμετρος (κλειδί της εγγραφής) δεν καταχωρείται, αλλά εκχωρείται από το διαχειριστή και επιστρέφεται κατά την απάντηση του διαχειριστή. Για την 40

51 ενημέρωση μιας εγγραφής όμως χρειάζεται και η εισαγωγή του κλειδιού αυτού. Οι λειτουργίες διαγραφής δέχονται τα κλειδιά που εκχώρησαν οι διαχειριστές σαν παραμέτρους, και διαγράφουν τις αντίστοιχες εγγραφές από τον κατάλογο. Ειδική περίπτωση διαγραφής αποτελεί η λειτουργία delete_tmodel. Όταν ένας αυθεντικοποιημένος χρήστης, χρησιμοποιήσει την παραπάνω λειτουργία για την διαγραφή ενός tmodel, αυτό δεν διαγράφεται φυσικά από τον κατάλογο, αλλά σημειώνεται ως κρυφό. Με τον τρόπο αυτό, είναι ακόμα διαθέσιμο στον αυθεντικοποιημένο χρήστη, αλλά δεν επιστρέφεται ως αποτέλεσμα από τις λειτουργίες αναζήτησης. Ο χρήστης, μπορεί να επανεισάγει το tmodel, χρησιμοποιώντας τη λειτουργία save_tmodel περνώντας ως παράμετρο το κλειδί του αρχικού tmodel. Οι λειτουργίες αναζήτησης δέχονται ένα σύνολο από κριτήρια σαν είσοδο, και το αποτέλεσμά τους συνήθως είναι μια δομή λίστας η οποία περιέχει τις εγγραφές που ικανοποιούν τα κριτήρια που είχαν τεθεί. Οι λειτουργίες αναζήτησης λεπτομερειών δέχονται μια λίστα από κωδικούς αναγνώρισης και επιστρέφουν λεπτομερείς πληροφορίες σχετικά με τις καταχωρήσεις που αντιστοιχούν στους κωδικούς της εισόδου. Η προγραμματιστική διεπαφή, παρέχει και μια επιπρόσθετη λειτουργία αναζήτησης λεπτομερειών, την get_businessdetailext, η οποία χρησιμοποιείται για την ανάκτηση εκτεταμένων πληροφοριών για εταιρίες από κόμβους μη διαχειριστών, που διατηρούν αυτές τις πρόσθετες πληροφορίες. Επιπλέον, επειδή η προγραμματιστική διεπαφή δημοσίευσης είναι ένα σύνολο από πιστοποιημένες λειτουργίες, όπου η αναγνώριση ενός χρήστη βασίζεται στη χρήση κουπονιών, η διεπαφή αυτη παρέχει και δυο λειτουργίες πιστοποίησης, τις get_authtoken και discard_authtoken. Τέλος, η λειτουργία getregisteredinfo, είναι μια λειτουργία αυθεντικοποίησης, η οποία και επιστρέφει όλα τα κλειδιά businessentity και tmodel, που έχουν καταχωρηθεί από έναν εξουσιοδοτημένο χρήστη. Κλείνοντας την αναφορά στην προγραμματιστική διεπαφή του UDDI, θα πρέπει να τονιστεί, ότι όλες σχεδόν οι λειτουργίες των προγραμματιστικών διεπαφών δημοσίευσης και ερώτησης είναι δυνατόν να πραγματοποιηθούν και από τις ιστοσελίδες των μεμονωμένων διαχειριστών. Η προγραμματιστική διεπαφή όμως, εκτός από του ότι είναι και πολύ πιο πλήρης από το σύστημα αλληλεπίδρασης ενός επόπτη διαδικτύου, παρέχει επίσης τη δυνατότητα στις επιχειρήσεις να εκτελούν όλες τις λειτουργίες προγραμματιστικά, βοηθώντας στην δυναμική (κατά το χρόνο εκτέλεσης) ανεύρεση υπηρεσιών. 41

52 4Κεφάλαιο Σημασιολογικός Ιστός (Semantic Web) 4.1Εισαγωγή Ο Παγκόσμιος Ιστός (WWW), στην σημερινή μορφή του περιέχει πληροφορία που προορίζεται για τον άνθρωπο. Αποτελείται από σελίδες, τις οποίες οι χρήστες του διαβάζουν και αποκομίζουν καινούργιες γνώσεις. Σαν επέκταση των παραπάνω ο όρος «Σημασιολογικός Ιστός» εκφράζει το όραμα στο οποίο ο υπολογιστής λογισμικό, όπως και οι άνθρωποι, θα είναι ικανός να εντοπίζει, διαβάζει, κατανοεί και να χρησιμοποιεί τα δεδομένα του διαδικτύου, για να επιτύχει χρήσιμα αποτελέσματα για τους χρήστες του. Βέβαια, ήδη έχει κατασκευαστεί λογισμικό που προσφέρει χρήσιμες υπηρεσίες στο διαδίκτυο, όπως είναι οι μηχανές αναζήτησης. Όμως η διαφορά έγκειται στον τρόπο χρήσης της διαθέσιμης πληροφορίας στο διαδίκτυο. Οι χρήστες στον παγκόσμιο ιστό, αναζητούν νέες πληροφορίες, επιλέγοντας τον ένα σύνδεσμο μετά τον άλλο, με βάση την λογική τους. Θα ήταν πολύ πιο αποδοτικό αυτή η διαδικασία να συνεχιζόταν μόνη της, ίσως ενημερώνοντας τον χρήστη κατά διαστήματα για την τρέχουσα κατάσταση. Σκοπός των τεχνολογιών γύρω από τον «Σημασιολογικό Ιστό» είναι να κάνουν πραγματικότητα λειτουργίες όπως η προαναφερθείσα, με τον εμπλουτισμό της διαθέσιμης πληροφορίας στο διαδίκτυο με «σημασιολογικά στοιχεία» (Semantic Ontologies), τα οποία οι υπολογιστές, μέσω του λογισμικού τους, θα έχουν την δυνατότητα να κατανοούν, χωρίς ανθρώπινη ανάμιξη. Ένας τυπικός ορισμός ο οποίος διατυπώθηκε από τον Tim Berners Lee, στην δημοσίευση του "Weaving the Web", Harper San Francisco, 1999, περιέχει με σαφήνεια τι ακριβώς υποδηλώνει ο όρος: «Το πρώτο βήμα είναι να βάλουμε τα δεδομένα στο δίκτυο σε μια μορφή όπου οι μηχανές μπορούν αμοιβαία να κατανοήσουν, ή να τα μετατρέψουμε σε αυτή τη μορφή. Αυτό δημιουργεί κάτι το οποίο ονομάζω Σημασιολογικό Δίκτυο (Semantic Web) ένα δίκτυο από δεδομένα τα οποία μπορούν να επεξεργαστούν άμεσα ή έμμεσα από τις μηχανές.» Ο οργανισμός W3C (World Wide Web Consortium), ο οποίος αναπτύσσει καινούργιες τεχνολογίες για την βελτίωση του παγκόσμιου ιστού (www), προωθεί την ανάπτυξη του «Σημασιολογικού Ιστού», ενώ πολλές από τις θεμελιώδης τεχνολογίες του, όπως η RDF και η XML, έχουν αναπτυχθεί από 42

53 αυτόν. Σύμφωνα με τον Tim Berners Lee η αρχιτεκτονική του «Σημασιολογικού Ιστού» απεικονίζεται στο παρακάτω σχήμα: Σχήμα 12. Αρχιτεκτονική του Σημασιολογικού Ιστού XML extensible Markup Language. Η γλώσσα που από το 1998 αποτελεί το θεμέλιο λίθο για σχεδόν όλες τις γλώσσες αλληλεπίδρασης με δεδομένα που διατίθενται στο διαδίκτυο. XML Schema. Η γλώσσα που καθορίζει την δομή συγκεκριμένων γλωσσών βασισμένων στην XML. RDF Resource Description Framework. Μια ευέλικτη γλώσσα, ικανή να περιγράψει με σαφήνεια πληροφορία διαφόρων ειδών και μεταδεδομένα. RDF Schema. Η γλώσσα που περιέχει τα μέσα για τον ορισμό του λεξιλογίου γλωσσών βασισμένων στην RDF, για συγκεκριμένες εφαρμογές. Ontology. Γλώσσες που ορίζουν λεξιλόγια και την χρήση όρων στα πλαίσια ενός συγκεκριμένου λεξιλογίου. Η RDF χρησιμοποιείται γα την κατασκευή οντολογιών, η οποία με την σειρά της χρησιμοποιείται από πιο σύνθετες γλώσσες οντολογιών, όπως η OWL. Logic and Proof. Η λογική επαγωγή είναι βασικό κομμάτι της δημιουργίας συνεκτικότητας και ορθότητας στα δεδομένα και στην επαγωγή λογικών συμπερασμάτων. Trust. Το μέσο για την ταυτοποίηση της ταυτότητας και η απόδειξη ότι τα δεδομένα και οι υπηρεσίες προς χρήση είναι έγκυρα. 4.2Παγκόσμιος ιστός και Σημασιολογικός Ιστός Ο παγκόσμιος ιστός είναι σχεδιασμένος γύρω από διαθέσιμους πόρους, το μοναδικό τρόπο διευθυνσιοδότησης αυτών των πόρων και ένα σύνολο από εντολές. Είναι σχεδιασμένος να λειτουργεί πάνω σε μεγάλης κλίμακας και πολύπλοκα δίκτυα με κατανεμημένο τρόπο. Στην παράγραφο αυτή, όταν θα αναφερόμαστε στον όρο «πόρο» θα εννοούμε κάποιο πακέτο δεδομένων, το οποίο μπορεί να είναι κάποια έγγραφα, ιστοσελίδες ή οτιδήποτε άλλο δεδομένο. Στον παγκόσμιο ιστό αναφερόμαστε 43

54 στους πόρους αυτούς μέσω των URIs (Uniform Resource Indicators) γενικότερα, ενώ μέσω των URLs (Uniform Resource Locators) αναφερόμαστε σε πόρους που μπορούν να διευθυνσιοδοτηθούν και να ανακτηθούν απευθείας μέσω πρωτοκόλλων πέραν του HTTP, όπως FTP. Ο παγκόσμιος ιστός λειτουργεί πάνω από ένα τεράστιο δίκτυο υπολογιστών με ένα αστρονομικό αριθμό από ιστοσελίδες και ιστοχώρους και πρέπει να συνεχίσει να λειτουργεί καθώς τα μεγέθη αυτά αυξάνονται. Σε ένα τέτοιο κατανεμημένο δίκτυο που συνεχώς μεγαλώνει, οποιοσδήποτε διαθέτει υπολογιστή μπορεί με τη βοήθεια κάποιου εξυπηρέτη (server) να προσθέσει πόρους στο ήδη υπάρχον δίκτυο χωρίς να είναι αναγκασμένος να τις καταχωρήσει και σε κάποιο συγκεκριμένο μέρος ή κόμβο ή κατάλογο. Ο παγκόσμιος ιστός, λοιπόν, είναι ανοιχτός με την έννοια ότι νέες ιστοσελίδες, νέα δεδομένα και νέοι πόροι γενικότερα μπορούν να προστεθούν ελεύθερα από τον καθένα χωρίς κάποιο κεντρικό έλεγχο. Είναι κατανοητό, λοιπόν, ότι ο παγκόσμιος ιστός είναι πιθανό να είναι ημιτελής, με την έννοια ότι δεν παρέχει καμία εγγύηση ότι όλοι οι πιθανοί σύνδεσμοι θα λειτουργούν και ότι όλη η πιθανή πληροφορία θα είναι διαθέσιμη. Είναι προφανές πια, πως ο σημασιολογικός ιστός προκειμένου να συμβαδίζει με το τρέχον μοντέλο του παγκόσμιου ιστού πρέπει να ακολουθήσει «ιδέες» και προσεγγίσεις του τωρινού μοντέλου: Πρέπει να χρησιμοποιεί τρόπους διευθυνσιοδότησης μέσω URIs. Πρέπει να χρησιμοποιεί πρωτόκολλα με μικρό και κοινά κατανοητό σύνολο εντολών. Πρέπει να διατηρεί όσο το δυνατόν λιγότερο ή ακόμη και καθόλου ιστορικό των πληροφοριών του διαδικτύου. Πρέπει να είναι όσο το δυνατόν κατανεμημένο. Πρέπει να μπορεί να λειτουργεί πάνω σε μεγάλης κλίμακας δίκτυα. Πρέπει να επιτρέπει την τοπική αποθήκευση των πληροφοριών ώστε να επιταχύνει την πρόσβαση σε αυτές και να ελαττώνει το φόρτο του δικτύου. Τέλος, μα εξίσου σημαντικό, πρέπει να είναι σε θέση να αντεπεξέλθει σε οποιαδήποτε ασυνέπεια συνδέσμων ή ημιτελών πληροφοριών. 4.3Σημασιολογικές Υπηρεσίες Διαδικτύου Ο όρος «Σημασιολογικές Υπηρεσίες Διαδικτύου» (Semantic Web Services), αναφέρεται στον εμπλουτισμό του τρέχοντος μοντέλου «Υπηρεσιών Διαδικτύου» με σημασιολογική πληροφορία (semantic information). Σκοπός της παραπάνω ενέργειας είναι πληρέστερη 44

55 περιγραφή τους, με απώτερο στόχο την αρμονική ενσωμάτωση τους στο «Σημασιολογικό Ιστό». Με το τρόπο αυτό, η περιγραφή των υπηρεσιών θα είναι επαρκής για την αποδοτικότερη αναζήτηση τους, μέσα στο τεράστιο πλήθος των προσφερόμενων υπηρεσιών στο διαδίκτυο, αφού θα καθίστανται κατανοητές από αυτοματοποιημένο λογισμικό. Με την μοντελοποίηση σε οντολογίες αντικειμένων του πραγματικού κόσμου και όχι απλώς δεδομένων, με τον τρόπο που υλοποιούνται και στον «Σημασιολογικό Ιστό», μια «Υπηρεσία Διαδικτύου» π.χ. που προσφέρει πληροφορίες για αυτοκίνητα, θα μπορεί να συσχετίσει τον οδηγό με το αυτοκίνητο, χωρίς την ύπαρξη αναφοράς σε αυτοκίνητο ή ακόμα και την φωτογραφία ενός οδηγού με τον αριθμό άδειας κυκλοφορίας του, την φωτογραφία ενός αυτοκινήτου με τον αριθμό κυκλοφορίας του και την οδό κατοικίας του οδηγού. Τα παραπάνω επιτυγχάνονται με την περιγραφή του τι είναι αυτοκίνητο, οδηγός, τι είναι φωτογραφία και πως συσχετίζονται μεταξύ τους. Η «Σημασιολογική Υπηρεσία Διαδικτύου» θα αναλάβει να τα αναλύσει και να παράγει ένα εμπεριστατωμένο αποτέλεσμα, όπως το παραπάνω παράδειγμα. Προς αυτή την κατεύθυνση εργάζονται πολλές ερευνητικές ομάδες ανά τον κόσμο. Η DARPA Agent Markup Language Services (DAML-S) δημιούργησε μια γλώσσα περιγραφής «Σημασιολογικών Υπηρεσιών Διαδικτύου», η οποία βασίζεται στην RDF και στην RDF Schema. Η DAML-S προσφέρει τα εργαλεία για την περιγραφή των ιδιοτήτων και δυνατοτήτων των Υπηρεσιών Διαδικτύου, σε μορφή πλήρως κατανοητή από αυτοματοποιημένο λογισμικό. Παράλληλα, το 2002, η Semantic Web Enabled Web Services (SWWS) αναπτύχθηκε για την παροχή τόσο οντολογικής περιγραφής, αλλά και αναζήτησης. Τέλος, η OWL (Web Ontology Language) αποτελεί την μετεξέλιξη της DAML και μεγάλο μέρος της δουλειάς για αυτή έχει μεταφερθεί και στην OWL. 4.4Γλώσσα Οντολογιών Ιστού (Web Ontology Language-OWL-S) Εφόσον έχουμε περιγράψει τι είναι οι «Υπηρεσίες Διαδικτύου», καθώς και την αρχιτεκτονική με την οποία συνδυάζονται προς όφελος του τελικού χρήστη, φτάνουμε σε κάποια συμπεράσματα και κάποιες προβλέψεις για το μέλλον. Όπως φαίνεται στο Σχήμα 13, οι υπηρεσίες διαδικτύου έκαναν την εμφάνισή τους στο κοντινό παρελθόν. Αμέσως άρχισε η φάση της ανάπτυξής τους και σιγά-σιγά η φάση της υιοθέτησής τους από εταιρείες και οργανισμούς. Καθώς η τεχνολογία προχωρά, είναι αντιληπτό ότι η μαζική αποδοχή τους έχει ξεκινήσει ήδη και αναμένεται να συνεχιστεί και στα επόμενα χρόνια. 45

56 Σχήμα 13. Φάσεις Ωριμότητας Υπηρεσιών Διαδικτύου Ο σημασιολογικός ιστός έχει σα στόχο να ενισχύσει αυτή την αποδοχή προσφέροντας καλύτερη ποιότητα υπηρεσιών, ακριβέστερη αναζήτηση πάνω στον ήδη υπάρχον παγκόσμιο ιστό και καλύτερα αποτελέσματα. Η βάση για να επιτευχθούν όλα αυτά είναι η περιγραφή της ήδη υπάρχουσας πληροφορίας με επιπλέον πληροφορία κατανοητή τόσο από ανθρώπους, όσο και από υπολογιστικές μηχανές. Η περιγραφή αυτή μπορεί να γίνει με τη βοήθεια οντολογιών (ontologies), οι οποίες θα παρέχουν τις απαραίτητες πληροφορίες και τους συσχετισμούς μεταξύ των εννοιών και των αντικειμένων. Ας δώσουμε όμως έναν ορισμό για αυτές: «Η τοποθέτηση και κατηγοριοποίηση των ειδών, πραγμάτων και εννοιών σε τύπους και κατηγορίες με ένα καλά ορισμένο τρόπο λέγεται οντολογία. Η οντολογία μπορεί να έχει όνομα ώστε να είναι κατανοητή από ανθρώπους, καθιστώντας έτσι εφικτή και την κατηγοριοποίηση συγκεκριμένων οντολογιών.» Συνήθως, οι οντολογίες δεν περιέχουν μόνο πληροφορία για τα είδη ή τις έννοιες που περιγράφουν, αλλά παρέχουν επιπρόσθετες πληροφορίες για συσχετίσεις τους με άλλα είδη ή έννοιες. Σκοπός είναι να υπάρχει ένας καλά ορισμένος τρόπος για την περιγραφή των οντολογιών αυτών ή με άλλα λόγια, σκοπός είναι να υπάρχει μια καθιερωμένη γλώσσα για τον ορισμό και την περιγραφή των οντολογιών. Τα χαρακτηριστικά αυτής της γλώσσας θα πρέπει να επιτρέπουν στις νεο-ορισμένες οντολογίες να είναι ευέλικτες και εύκολα προσαρμοζόμενες σε νέου είδους χαρακτηριστικά ή πληροφορίες που μπορεί να προστίθενται δυναμικά στην έννοια που περιγράφουν. Θα πρέπει να επιτρέπουν την πρόσβαση σε αυτές μέσω του παγκόσμιου ιστού ώστε να είναι διαμοιραζόμενες και προσβάσιμες από όλους με απώτερο σκοπό την εξάπλωσή τους σε ολόκληρο το δίκτυο. Τέλος, η γλώσσα αυτή οφείλει να επιτρέπει τη σύγκριση μεταξύ των οντολογιών ή μεμονωμένων κομματιών μιας οντολογίας και μιας άλλης, καθώς επίσης την κατηγοριοποίηση οποιασδήποτε ιδέας ή πόρου ή σεναρίου είτε αυτό είναι προσβάσιμο μέσο του δικτύου, είτε όχι. 46

57 Γενικά, λοιπόν, μια τέτοια γλώσσα θα ορίζει κλάσεις ή κατηγορίες, όρους και συσχετίσεις. Θα ορίζει τύπους δεδομένων και κατ επέκταση περιορισμούς πάνω σε αυτούς. Τέλος, θα ορίζει κανόνες και θα παρέχει μια συγκεκριμένη σύνταξη για τον ορισμό των οντολογιών. Η βάση τέθηκε από την RDF (Resource Description Framework) μία γλώσσα για τον ορισμό των οντολογιών. Η γλώσσα αυτή σχεδιάστηκε για να κάνει δηλώσεις για συγκεκριμένους πόρους. Ένας πόρος μπορεί να αντιπροσωπεύει ένα σενάριο, μια ιδέα, μια έννοια ή δεδομένα και ταυτοποιείται από ένα URI. Η RDF είναι η βάση για την OWL (Web Ontology Language), η οποία σχεδιάστηκε για να δώσει μια αποδοτικότερη αρχιτεκτονική πάνω στις οντολογίες. Η OWL προέκυψε από την DAML+OIL, μια σχετική και αρκετά επιτυχημένη προσπάθεια της DARPA. Η γλώσσα αυτή χρησιμοποιεί κλάσεις και ιδιότητες της RDF, αλλά ταυτόχρονα τις επεκτείνει και ορίζει και νέες. Η OWL χωρίζεται σε τρεις «υπογλώσσες» ή εκδόσεις: την OWL Lite, την OWL DL και την OWL Full. Η τελευταία είναι ολόκληρη η γλώσσα. Οι άλλες δύο είναι υποσύνολα ή περιορισμοί αυτής. Ο λόγος που υπάρχουν οι τρεις αυτές εκδόσεις είναι το γεγονός ότι τα δύο υποσύνολα της OWL Full παρέχουν λιγότερη δύναμη, αλλά περιορίζουν σημαντικά το υπολογιστικό κόστος. Η OWL DL υποστηρίζει μια μορφή αυτού που λέμε περιγραφή της λογικής (Description Logic). Η OWL DL προσδίδει προσεκτικά επιλεγμένους περιορισμούς πάνω στο είδος των αντικειμένων που περιγράφει με σκοπό τη μείωση των απαραίτητων υπολογιστικών πόρων. Με αυτόν το τρόπο εγγυάται τον υπολογισμό των αποτελεσμάτων με χρήση των υπαρχόντων υπολογιστικών δυνατοτήτων. Η OWL Lite είναι ουσιαστικά η OWL DL, αλλά με περισσότερους περιορισμούς. Όσον αφορά στις υπηρεσίες διαδικτύου, η OWL έρχεται να ενισχύσει τους παροχούς των υπηρεσιών με ένα σύνολο από δεδομένα και μετασχηματισμούς για την πληρέστερη περιγραφή των δυνατοτήτων των υπηρεσιών με ένα τρόπο άμεσα κατανοητό και μεταγλωττίσσιμο από υπολογιστικές μηχανές. Παρέχει αυτόματη αναζήτηση των υπηρεσιών, ενισχύοντας έτσι το ρόλο της υπηρεσίας καταλόγου (Service Registry), καθώς και δυναμική αλληλεπίδραση μεταξύ των υπηρεσιών και σύνθεσή τους. Ουσιαστικά, η δύναμή της έγκειται στο σημασιολογικό ορισμό των εννοιών και των σεναρίων γύρω από την υπηρεσία διαδικτύου, κάτι που η WSDL αδυνατεί να υποστηρίξει και υστερεί στον τομέα αυτό. Με τον τρόπο αυτό, η OWL προσδίδοντας μεγαλύτερη δύναμη στην υπηρεσία καταλόγου, στους παροχείς και γενικά στους αντιπροσώπους των υπηρεσιών διαδικτύου στοχεύει στην αύξηση της ποιότητας της υπηρεσίας, της σταθερότητας και της εμπιστοσύνης γύρω από αυτή. 47

58 Κλείνοντας, η OWL είναι μια γλώσσα για οντολογίες η οποία: Είναι ικανή να αναφέρεται σε σενάρια, ιδέες, έννοιες, αντικείμενα και δεδομένα που είναι ορισμένα στον παγκόσμιο ιστό. Μπορεί να διαμοιράζεται πάνω στον ιστό. Είναι ικανή να συνεργάζεται με άλλες παρόμοιες γλώσσες, όπως η RDF. Μπορεί να συγχωνεύει πολλές οντολογίες ταυτόχρονα. Είναι ευρέως αποδεκτή. Είναι αρκετά εκφραστική. Όλα τα παραπάνω καθιστούν την OWL την κυρίαρχη γλώσσα πάνω στον παγκόσμιο ιστό για το σκοπό που περιγράφουμε και αναμφίβολα θα συνεχίσει να εξελίσσεται. 48

59 5Κεφάλαιο: Συνδυασμός Τεχνολογιών Κινητών Πρακτόρων και Υπηρεσιών Διαδικτύου 5.1Εισαγωγή Η τεχνολογία των Υπηρεσιών Διαδικτύου είναι πλέον ευρέως αποδεκτή από τον επιχειρησιακό κόσμο, με αποτέλεσμα ολοένα να εξαπλώνεται στο χώρο του διαδικτύου και ολοένα να εξελίσσεται. Από την άλλη, δεν είναι λίγα τα μειονεκτήματά της που την καθιστούν ακατάλληλη για πολλά συστήματα. Καταρχάς, οι αλληλεπιδράσεις μεταξύ του πελάτη και της επιθυμητής υπηρεσίας προς κλήση πρέπει να γίνονται όταν ο πελάτης είναι συνδεδεμένος στο δίκτυο. Σε περίπτωση αποσύνδεσης, τότε πρέπει να επαναληφθεί η διαδικασία εξ αρχής. Κάτι τέτοιο θα αποτελούσε εμπόδιο για την εφαρμογή της τεχνολογίας σε δίκτυα τρίτης γενιάς. Τα δίκτυα αυτά κυρίως είναι ασύρματα με περιορισμένους πόρους. Οι συνδέσεις είναι επισφαλείς και δεν υπάρχει καμιά εγγύηση για συνεχόμενη και αξιόπιστη επικοινωνία μεταξύ των μελών του δικτύου ή στην προκειμένη περίπτωση, μεταξύ του πελάτη και της υπηρεσίας. Επομένως, η απαίτηση της διαρκούς διασύνδεσης του πελάτη με το δίκτυο πιθανόν να μην ικανοποιείται πάντα. Επιπρόσθετα, οι υπηρεσίες διαδικτύου είναι περισσότερο κατανοητές από τους ανθρώπους και όχι από τις μηχανές. Δεν είναι λίγες οι φορές που προτού εξασφαλιστεί η επικοινωνία των εφαρμογών δύο εταιρειών, έχει προηγηθεί τηλεφωνική κλήση μεταξύ των αρμόδιων ώστε να θέσουν τις προδιαγραφές της επικοινωνίας. Η υπάρχουσα τεχνολογία δηλαδή των υπηρεσιών διαδικτύου δεν προσφέρει σημασιολογική πληροφορία που είναι κατανοητή τόσο από ανθρώπους όσο και από μηχανές. Το τελευταίο οφείλεται κυρίως στα πρωτόκολλα και τις προδιαγραφές που χρησιμοποιούνται. Το πρωτόκολλο SOAP για την ανταλλαγή των μηνυμάτων μεταξύ του πελάτη και της υπηρεσίας είναι κυρίως ανθρωποκεντρικό το ίδιο και η WSDL που είναι η υφιστάμενη γλώσσα περιγραφής των υπηρεσιών. Αυτό που κάνει ουσιαστικά είναι να περιγράφει την υπηρεσία σαν ένα σύνολο από τερματικά σημεία του δικτύου, πόρτες και διευθύνσεις. Η ίδια η υπηρεσία καταλόγου (Service Registry), που η πλέον γνωστότερη και ευρέως χρησιμοποιούμενη είναι το UDDI, δεν έχει τη δυνατότητα να προσφέρει σημασιολογική πληροφορία γύρω από την υπηρεσία, καθώς δεν έχει την ικανότητα να την 49

60 αποθηκεύσει και επομένως δεν προσφέρει τη δυνατότητα για τέτοιου είδους αναζήτηση. Ο συνδυασμός όμως όλων των παραπάνω τεχνολογιών που περιγράφηκαν σε προηγούμενες ενότητες θα μπορούσε να εκμεταλλευτεί όλα τα πλεονεκτήματα που προσφέρουν αυτές οι τεχνολογίες και ταυτόχρονα να ελαχιστοποιήσει ή και να εξαλείψει όλα τα μειονεκτήματά τους. Εάν ο χρήστης μπορούσε να αντιπροσωπευτεί από έναν κινητό πράκτορα μέσα στο δίκτυο, τότε δε θα ήταν αναγκασμένος να είναι συνεχώς συνδεδεμένος στο δίκτυο μέχρι να επιτευχθεί ο στόχος του. Αν μάλιστα ο στόχος του ήταν η κλήση μιας υπηρεσίας διαδικτύου, τότε ο συνδυασμός των υπηρεσιών διαδικτύου με την τεχνολογία των κινητών πρακτόρων θα αναδείκνυε νέες προοπτικές για το χρήστη. Εξάλλου, όπως έχει ήδη αναφερθεί, η νέα τεχνολογία των κινητών πρακτόρων δεν έρχεται απαραίτητα να αντικαταστήσει το υπάρχον μοντέλο του εξυπηρέτη εξυπηρετούμενου, αλλά να το ενισχύσει. Ο συνδυασμός τους σε κατανεμημένα περιβάλλοντα θα βελτιώσει την ποιότητα των υπηρεσιών και την αξιοπιστία του συστήματος. Επιπρόσθετα, εάν η υπηρεσία καταλόγου μπορούσε να εμπλουτιστεί με σημασιολογική πληροφορία, τότε ο χρήστης θα μπορούσε να ανακαλύπτει ακριβώς την υπηρεσία που επιθυμεί. Προγράμματα που τον αντιπροσωπεύουν, όπως οι κινητοί πράκτορες, θα μπορούσαν να συνεργαστούν με επιτυχία με την υπηρεσία καταλόγου, εφόσον η πληροφορία που θα παρέχει θα είναι κατανοητή και από μηχανές. Έτσι ο συνδυασμός των παραπάνω με τεχνολογίες σχετικές με τον σημασιολογικό ιστό, θα μπορούσε να ενισχύσει την αξιοπιστία των συστημάτων, την ποιότητα των υπηρεσιών, την ευκολία προς τους χρήστες και τη νοημοσύνη των εφαρμογών που τους αντιπροσωπεύουν. Όλα αυτά προϋποθέτουν, στην περίπτωση των υπηρεσιών διαδικτύου, ότι ο παροχέας έχει φροντίσει να περιγράψει την υπηρεσία με τέτοιο τρόπο ώστε να είναι δυνατή η διαθεσιμότητα σημασιολογικής πληροφορίας από την υπηρεσία καταλόγου. Όπως παρουσιάστηκε παραπάνω, η OWL είναι μια γλώσσα που μπορεί να χρησιμοποιηθεί για το σκοπό αυτό. Επομένως, ο συνδυασμός της τεχνολογίας των υπηρεσιών διαδικτύου με αυτή των κινητών πρακτόρων πάνω στο σημασιολογικό ιστό αναμένεται να χαράξει νέες προοπτικές πάνω στον κατανεμημένο υπολογισμό. 50

61 5.2Ερευνητικές Τάσεις Όλα τα παραπάνω, έχουν παρατηρηθεί από την επιστημονική κοινότητα, με αποτέλεσμα μια πληθώρα δημοσιεύσεων σε συνέδρια και περιοδικά, που πραγματεύονται την αλληλεπίδραση και συνέργια των τεχνολογιών των Κινητών Πρακτόρων, των Υπηρεσιών Διαδικτύου και του Σημασιολογικού Ιστού. Η παράγραφος αυτή αυτό αποτελεί μια περιήγηση στις σημαντικότερες από αυτές. Η αναφορά προτείνει μια πλατφόρμα που θα διασυνδέει πολλαπλούς χρήστες, με απώτερο σκοπό το αμοιβαίο όφελος όλων. Αυτό επιτυγχάνεται με την προσφορά υπολογιστικών πόρων που ο χρήστης δεν χρησιμοποιεί την τρέχουσα στιγμή. Κάθε ενέργεια που απαιτεί υπολογιστικούς πόρους αντιπροσωπεύεται από έναν κινητό πράκτορα, ο οποίος αναλαμβάνει την αναζήτηση των πόρων στους υπολογιστές των συνδεδεμένων χρηστών, μεταναστεύει εκεί, εκτελεί την ενέργεια και επιστρέφει με τα αποτελέσματα. Το βασικότερο κριτήριο της επιλογής του στόχου μετανάστευσης είναι η εύρεση μη χρησιμοποιούμενων υπολογιστικών πόρων. Η προτεινόμενη πλατφόρμα, αποτελείται από τέσσερα επίπεδα: (1) Μια συλλογή από κόμβους χρηστών και εξυπηρετών, συνδεδεμένοι στο δίκτυο. (2) Κινητοί Πράκτορες αντιπρόσωποι ενεργειών, που αναλαμβάνουν την εκτέλεση αυτών. (3) Java wrappers, κάθε ένας περιτυλίγει κάθε πρόγραμμα του κάθε χρήστη. (4) Προγράμματα χρηστών γραμμένα στις γλώσσες Java και C++. Στις αναφορές η γλώσσα BPEL (Business Process Execution Language) χρησιμοποιείται για τον καθορισμό απλών κανόνων που περιγράφουν την συμπεριφορά του Κινητού Πράκτορα, όπως η μετανάστευση και η κλωνοποίηση. Οι κανόνες αυτοί δεν σχετίζονται με την λογική αλληλεπίδρασης του πράκτορα, επιτρέποντας την αλλαγή ή και την προσθήκη καινούργιων κανόνων συμπεριφοράς, χωρίς την αλλαγή της BPEL περιγραφής. Συγκεκριμένα, ο Κινητός Πράκτορας αποτελείται από τα παρακάτω: I. Μια περιγραφή των διεργασιών του σε γλώσσα BPEL, που εκφράζουν την λογική αλληλεπίδρασης του με το περιβάλλον. II. Μια περιγραφή των κανόνων συμπεριφοράς του. III. Αποθηκευμένες Υπηρεσίες Διαδικτύου, που συνοδεύουν τον Πράκτορα στις μεταναστεύσεις του και είναι σε θέση να τις χρησιμοποιήσει τοπικά, κατά την διάρκεια των διεργασιών του. Στη συνέχεια, η αναφορά προχωράει σε μια τυπική περιγραφή της προαναφερθείσας περιγραφής της συμπεριφοράς του Κινητού Πράκτορα, με την χρήση Mobile Ambients, ένα μοντέλο περιγραφής ψευδοπαράλληλων υπολογισμών, παρόμοιο με το πcalculus. Ο διαχωρισμός της φυσικής συμπεριφοράς του Κινητού Πράκτορα, από την λογική αλληλεπίδρασης του με το περιβάλλον 51

62 του είναι εξαιρετικά χρήσιμη για την χρήση Πρακτόρων σε δυναμικά περιβάλλοντα Υπηρεσιών Διαδικτύου. Παρόλα αυτά, η συγκεκριμένη πλατφόρμα παρουσιάζει δυναμική συμπεριφορά μόνο σε προκαθορισμένα γεγονότα, όπως τα ακόλουθα: I. Αποτυχία μετανάστευσης Κινητού Πράκτορα. II. Κλωνοποίηση κινητού Πράκτορα. III. Κατανομή ενεργειών σε κλώνους του Κινητού Πράκτορα. Οι υλοποιημένοι κανόνες στην προτεινόμενη πλατφόρμα, δεν περιλαμβάνουν δυναμικά γεγονότα, που είναι πιθανό να παρουσιαστούν κατά την διάρκεια κλήσης της Υπηρεσίας Διαδικτύου και κατά τις πολλαπλές μεταναστεύσεις του Κινητού Πράκτορα. Επιπλέον, η πλατφόρμα προϋποθέτει την ύπαρξη των απαραίτητων πρωτοκόλλων πολλαπλής κλήσης. Τέλος, η υλοποίηση της πλατφόρμας δεν έχει παρουσιαστεί στην επιστημονική κοινότητα και ως λογικό επακόλουθο δεν υπάρχει αποτίμηση της απόδοσης της, σε σχέση με το κλασσικό μοντέλο των Υπηρεσιών Διαδικτύου που επικρατεί. Η αναφορά παρουσιάζει μια τεχνική ενσωμάτωσης στον Κινητό Πράκτορα, της δυνατότητας δυναμικής τροποποίησης των παραμέτρων του, οι οποίες είναι περιγραμμένες στην γλώσσα DAML-S. Η τελευταία χρησιμοποιείται στην περιγραφή ατομικών ή και ενορχηστρωμένων Υπηρεσιών Διαδικτύου. Σύμφωνα με την παραπάνω τεχνική, Κινητοί Πράκτορες υλοποιημένη σε LEAP, βρίσκονται σε ασύρματες κινητές συσκευές και αποκτούν την DAML-S περιγραφή της Υπηρεσίας Διαδικτύου που επιθυμούν να καταναλώσουν, από έναν εξυπηρέτη αποθήκη. Στη συνέχεια, οι παραπάνω περιγραφές προωθούνται στον εξυπηρέτη Home, όπου μετασχηματίζονται σε εκτελέσιμα προγράμματα και τα αποτελέσματα τους μεταφέρονται πίσω στον Κινητό Πράκτορα, με την χρήση του JXTA πρωτοκόλλου. Υπάρχουν αρκετές δημοσιεύσεις που χρησιμοποιούν την BPEL4WS (Business Process Execution Language for Web Services) ως μια γλώσσα προδιαγραφών, για την διατύπωση της κοινωνικής συμπεριφοράς πολυπρακτορικών συστημάτων και για την προσαρμογή τους στις δυναμικές περιβάλλοντες συνθήκες. Παραταύτα, δεν ασχολούνται με την σημασιολογική περιγραφή των Υπηρεσιών Διαδικτύου, που προσφέρονται από το σύστημα. Αντίθετα, σε άλλες δημοσιεύσεις, γίνεται μνεία για τέτοιου είδους περιγραφή και πραγματοποιείται με την χρήση της DAML-S. Με αυτόν τον τρόπο, παρέχεται η δυνατότητα σημασιολογικής αναζήτησης, που προσφέρει μέχρι στιγμής τα βέλτιστα δυνατά αποτελέσματα. Όμως, δεν γίνεται προσπάθεια συνδυασμού των δύο παραπάνω προσεγγίσεων. Οι αναφορές προτείνουν μια πλατφόρμα βασισμένη σε πολιτικές, για την ευέλικτη διαχείριση και δυναμική αλλαγή της 52

63 μεταναστευτικής συμπεριφοράς του Κινητού Πράκτορα, με σκοπό την μείωση των εμπλοκών κατά την διαδικασία αποδήμησης και την ενίσχυση της επικράτησης των κινητών εφαρμογών, στον τομέα των κατανεμημένων υπολογισμών. Οι παραπάνω πολιτικές ορίζουν πότε, που, πως και ποια μέρη του Κινητού Πράκτορα θα ασχοληθούν με μια συγκεκριμένη ενέργεια. Παραδείγματος χάριν, ποια συστατικά του Κινητού Πράκτορα θα φέρουν σε πέρας την μετανάστευση στον Παροχέα της Υπηρεσίας Διαδικτύου και ποια θα την καλέσουν και στη συνέχεια θα συλλέξουν τα αποτελέσματα. Στην αναφορά, παρουσιάζεται ένα πρωτότυπο για την υλοποίηση Υπηρεσιών Διαδικτύου, με την χρήση Κινητών Πρακτόρων. Οι Κινητοί Πράκτορες περιγράφουν την λειτουργικότητα τους με την χρήση της γλώσσας WSDL (δημόσια διεπαφή). Γίνεται χρήση του.νετ Remoting για την αντιστοίχηση των αιτήσεων προς τις Υπηρεσίες, που περιγράφονται με WSDL, με ένα συγκεκριμένο Κινητό Πράκτορα. Στη συνέχεια, οι Πράκτορες μεταναστεύουν από εξυπηρέτη σε εξυπηρέτη για να εφαρμόσουν την λειτουργικότητα της εκάστοτε Υπηρεσίας Διαδικτύου τοπικά και οι χρήστες που αντιπροσωπεύουν, καταναλίσκουν τα δεδομένα που επιστρέφουν οι Πράκτορες, σαν να ήταν κλασσικές στατικές Υπηρεσίες Διαδικτύου. Όλες οι παραπάνω Υπηρεσίες Διαδικτύου, δεν περιέχουν σημασιολογική πληροφορία, όπως ακριβώς συμβαίνει και στην δημοσίευση, που προτείνει ένα σύστημα πολυπρακτόρων σε συνδυασμό με χρήση Υπηρεσιών Διαδικτύου. Στην αναφορά, παρουσιάζεται ένα μοντέλο που παρέχει στον χρήστη Υπηρεσιών Διαδικτύου, πληροφορίες για την τρέχουσα κατάσταση εκτέλεσης τους. Με αυτόν τον τρόπο ο χρήστης είναι σε θέση να επιλέξει την εκτέλεση της Υπηρεσίας Διαδικτύου που επιθυμεί, με βάση πληθώρα στοιχειών, όπως ο φόρτος του Παροχέα, η συνολική ποιότητα της (QoS), ο χρόνος απόκρισης της και άλλα. Παρέχονται δύο παραδείγματα, από τα οποία αποκομίζονται οι ακόλουθες πληροφορίες: RPC (Remote Procedure Call) και οι Κινητοί Πράκτορες. Επιπρόσθετα, εισάγεται και η έννοια του κυκλικού Πράκτορα, ο οποίος ταξιδεύει περιοδικά στο δίκτυο και συλλέγει ανανεωμένη πληροφορία, ενώ είναι συνεχώς διαθέσιμος για τον χρήστη. Με τον τρόπο αυτό, επιτυγχάνονται καλύτερη χρόνοι απόκρισης και παρουσιάζεται καλύτερη συμπεριφορά των Υπηρεσιών Διαδικτύου σε ασύρματο περιβάλλον. Μια προσέγγιση βασισμένη σε Κινητούς Πράκτορες, που προορίζεται για ασύρματα δίκτυα, προτείνεται στην, όπου παρατίθενται τρεις μέθοδοι για την κλήση των Υπηρεσιών Διαδικτύου, συγκεκριμένα: Η παράλληλη, η σειριακή και ο συνδυασμός των δυο, που καλείται υβριδική μέθοδος. Το σενάριο που παρατίθεται περιλαμβάνει ένα χρήστη με μια φορητή συσκευή να καλεί μια Υπηρεσία Διαδικτύου. Αυτό έχει ως αποτέλεσμα, την 53

64 αποστολή ενός Κινητού Πράκτορα αντιπρόσωπου στην Υπηρεσία Καταλόγου, όπου εντοπίζει την επιθυμητή Υπηρεσία (περιγραμμένη σε WSDL) και τελικά την κλήση της από αυτόν. Η εκτέλεση της Υπηρεσίας Διαδικτύου πραγματοποιείται με μια από τις προαναφερθείσες μεθόδους, ανάλογα με την φύση της. Η προσέγγιση αυτή δεν περιλαμβάνει κανενός είδους σημασιολογική πληροφορία για την περιγραφή των Υπηρεσιών Διαδικτύου, ενώ η αναζήτηση πραγματοποιείται σε Υπηρεσία Καταλόγου τύπου UDDI. Επιπρόσθετα, δεν περιλαμβάνει εμπεριστατωμένο μηχανισμό για την επιλογή της μεθόδου κλήσης, αλλά απλά αν η Υπηρεσία Διαδικτύου αποτελεί ενορχήστρωση περισσοτέρων, επιλέγει την σειριακή μέθοδο, αλλιώς προχωράει σε παράλληλη μέθοδο. Μια προσέγγιση ίδιας φιλοσοφίας ακολουθείται και στην, με την διαφορά ότι χρησιμοποιούνται δύο είδη Κινητών Πρακτόρων για την δουλειά του ενός της προηγούμενης προσέγγισης. Ονομαστικά είναι οι Πράκτορας Υπηρεσίας και ο Προσωπικός Πράκτορας. Στις δημοσιεύσεις, προτείνονται οι Κινητές Υπηρεσίες Διαδικτύου, όπου οι ίδιες οι Υπηρεσίες μεταναστεύουν στον αιτούντα, αντίθετα με όλες τις προηγούμενες προσεγγίσεις. Όμως, οι Υπηρεσίες αυτές δεν περιγράφονται με σημασιολογικό τρόπο, αλλά περιορίζονται στην γλώσσα WSDL. Τέλος, θα πρέπει να τονιστεί ότι κοινός παρανομαστής όλων των προαναφερθέντων προτάσεων είναι η έλλειψη ποσοτικής αξιολόγησής τους, ενώ ταυτόχρονα δεν παρουσιάζονται ούτε υλοποιημένες πλατφόρμες. Λόγο των παραπάνω, δεν είναι δυνατή η ουσιαστική, πλήρης και εμπεριστατωμένη αντιπαράθεση τους με το κλασσικό μοντέλο των Υπηρεσιών Διαδικτύου. 54

65 6Κεφάλαιο:Αρχιτεκτονική Πλατφόρμας 6.1Εισαγωγή Μια γενική περιγραφή της αρχιτεκτονικής της πλατφόρμας απεικονίζεται στο παρακάτω σχήμα (Σχήμα 14). Ο Αιτών της Υπηρεσίας Διαδικτύου αντιπροσωπεύεται από ένα Κινητό Πράκτορα, ο οποίος μεταναστεύει στον προκαθορισμένο Κατάλογο Υπηρεσιών, με σκοπό την εξεύρεση της επιθυμητής Υπηρεσίας, εκ μέρους του χρήστη. Για τον σκοπό αυτό, ο Κατάλογος Υπηρεσιών είναι εμπλουτισμένος με σημασιολογική πληροφορία, με τέτοιο τρόπο που να επιτρέπει στον κινητό αντιπρόσωπο του χρήστη να επιτύχει το βέλτιστο ταίριασμα, ανάμεσα στα κριτήριά του και τις δημοσιευμένες Υπηρεσίες στον Κατάλογο. Στη συνέχεια, αφού ο Κινητός Πράκτορας αποκτήσει τις πλησιέστερες στα κριτήρια Υπηρεσίες Διαδικτύου, δηλαδή τις λειτουργίες τους, τις παραμέτρους που απαιτούν και τα URIs που προσφέρονται, μεταναστεύει σε κάθε ένα από τους Παροχείς. Όντας ο Κινητός Πράκτορας σε κάθε Παροχέα Υπηρεσιών, εκτελεί την Υπηρεσία και λαμβάνει τα αποτελέσματα της. Με αυτόν τον τρόπο ο Κινητός Πράκτορας, διατρέχει όλους τους Παροχείς και τέλος μεταναστεύει πίσω στον Αιτών της Υπηρεσίας για να τους προσφέρει τα αποτελέσματα. Η πορεία που θα ακολουθήσει ο κινητός Πράκτορας ποικίλει, ανάλογα με τα κριτήρια που του έχει θέσει ο Αιτών της Υπηρεσίας και την εκάστοτε τοπολογία του δικτύου. Επίσης, όπως αναφέρεται στην συνέχεια, ο χρήστης έχει την δυνατότητα να προγραμματίσει τον Κινητό Πράκτορα να στείλει κλώνους του εαυτού του σε κάθε Παροχέα Υπηρεσιών ταυτόχρονα, αντί να μεταναστεύσει σειριακά στον ένα μετά τον άλλο. 55

66 3. Agent executes the WS Published services Web Service provider Service Registry 2. Agent gets a list of Web services Web Service provider 4 Agent executes the WS Transport medium Users 5.Agent executes the WS Web Service provider Laptop 1. Agent creation 6.Agent executes the WS Web Service provider Service Requestor n.brings the service results Web Service provider 6 Agent executes the WS Web Service provider (n -1).Agent executes the WS Web Service provider Web Service provider 6.Agent executes the WS Σχήμα 14. Γενική Αρχιτεκτονική Πλατφόρμας 6.2Συστατικά Συστήματος Οι οντότητες που απαρτίζουν την παραπάνω αρχιτεκτονική είναι οι ακόλουθες: Αιτών της Υπηρεσίας (User Service Requestor - USR): Αντιπροσωπεύει τον χρήστη που επιθυμεί την εκτέλεση της Υπηρεσίας Διαδικτύου που ικανοποιεί τα κριτήρια που έχει θέσει, με σκοπό να συλλέξει τα αποτελέσματα της. Στην προτεινόμενη πλατφόρμα ο USR δεν απαιτείται να είναι συνδεδεμένος μέχρι και την παραλαβή των αποτελεσμάτων, αντίθετα ο Κινητός Πράκτορας αφού αποκτήσει τα αποτελέσματα, περιμένει τον USR να συνδεθεί στο σύστημα έτσι ώστε να του τα προσφέρει. Ο USR συνδέεται στην Διαδικτυακή Εφαρμογή (Client System), όπως φαίνεται στο ακόλουθο σχήμα, η οποία έχει απευθείας σύνδεση με την Πλατφόρμα των Κινητών Πρακτόρων, με χρήση του πρωτοκόλλου IIOP, έτσι ώστε να έχει την δυνατότητα να δημιουργήσει τον Κινητό Πράκτορα σύμφωνα με τις απαιτήσεις που έχει εισάγει ο χρήστης. Η Διαδικτυακή εφαρμογή είναι υλοποιημένη με χρήση της τεχνολογίας JSP/Servlet και προσφέρεται από τον εξυπηρέτη Apache Tomcat. Με αυτόν τον σχεδιασμό, δεν υπάρχει η απαίτηση στον υπολογιστή του χρήστη να υφίσταται η εικονική μηχανή της γλώσσας JAVA (JRE), ούτε και η πλατφόρμα των Κινητών Πρακτόρων (ΠΚΠ). Το μόνο απαιτούμενο είναι ένας διαφυλλιστής διαδικτύου, μέσω του οποίου προσφέρονται οι υπηρεσίες της πλατφόρμας. Ο Εξυπηρέτης χρησιμοποιεί την βάση δεδομένων HSQLDB, έτσι 56

67 ώστε να προσφέρει με επιτυχία τις υπηρεσίες της Διαδικτυακής Εφαρμογής (Client System). Συγκεκριμένα, η εφαρμογή προσφέρει τα ακόλουθα: o Δημιουργία καινούργιου λογαριασμού χρήστη. o Εγγραφή στην εφαρμογή και να διαγραφεί από αυτή. o Ορισμό των πολιτικών που θα ακολουθήσει ο Κινητός Πράκτορας κατά την λειτουργία του. o Προφίλ του χρήστη. o Αναφορά της τρέχουσας τοποθεσίας του Πράκτορα. o Διαγραφή του Πράκτορα. o Εντολή επιστροφής του Πράκτορα. o Πάνελ Ελέγχου για τον διαχειριστή. Ειδικά, αν ο χρήστης έχει δικαιώματα διαχειριστή μπορεί μέσω του Πάνελ Ελέγχου, να κάνει τις εξής ενέργειες: o Εισαγωγή νέων χρηστών. o Επέμβαση στις ιδιότητες των χρηστών. o Αναβάθμιση των δικαιωμάτων ενός χρήστη σε επίπεδο διαχειριστή. Η προαναφερθείσα λειτουργία, προφίλ του χρήστη, δίνει την δυνατότητα στην Διαδικτυακή Εφαρμογή, να απομνημονεύει τις πιο πρόσφατες προτιμήσεις του κάθε χρήστη, με το να σειριοποιεί και να αποθηκεύει στην βάση δεδομένων του εξυπηρέτη το αρχείο policies.xml, που περιέχει όλες τις απαραίτητες πληροφορίες, συσχετιζόμενο με τον αντίστοιχο χρήστη. Λεπτομέρειες για το αρχείο policies.xml παρατίθενται στην συνέχεια. Σχήμα 15. Αρχική σελίδα διαδικτυακής εφαρμογής και επιλογή των πολιτικών του κινητού πράκτορα. Κινητός Πράκτορας (Mobile Agent-MA): Αποτελεί τον αντιπρόσωπο του χρήστη, ο οποίος επιθυμεί την εκτέλεση της Υπηρεσίας Διαδικτύου της αρεσκείας του. Ο χρήστης επικοινωνεί μόνο με τον ΜΑ και θέτει τις πολιτικές που θα ακολουθήσει κατά την διάρκεια της λειτουργίας του. Με την σειρά του ο ΜΑ μεταναστεύει σε διάφορους προορισμούς είτε 57

68 για αναζήτηση υπηρεσιών είτε για να εκτελέσει Υπηρεσίες Διαδικτύου. Ο MA έχει την ικανότητα να δημιουργήσει κλώνους του εαυτού του με σκοπό να μειώσει τον συνολικό χρόνο κλήσεως των Υπηρεσιών, αφού κάθε κλώνος μεταναστεύει σε ένα συγκεκριμένο παροχέα, καλεί την Υπηρεσία που προσφέρει και επιστρέφει πίσω στον Αιτών με τα αποτελέσματα. Στην πλατφόρμα που έχει υλοποιηθεί, ο ΜΑ αποτελείται από τον συνδυασμό των: o Δεδομένων του o Του κώδικα του o Των πολιτικών μετανάστευσής και κλωνοποίησης o Τη μηχανή ταιριάσματος (Matching Engine) o Τη μηχανή διαχείρισης των πολιτικών (Policy Management Component) Το επόμενο σχήμα απεικονίζει αυτή την δομή. Σχήμα 16. Δομή του κινητού πράκτορα Τα δεδομένα αναπαριστούν την πληροφορία που διατηρεί ο ΜΑ ανάμεσα στις μεταναστεύσεις του, ενώ οι πολιτικές συγκεκριμενοποιούν την αυτόνομη συμπεριφορά του, με τέτοιο τρόπο που δεν έχει επίδραση στον κώδικα της υλοποίησης του. Η μηχανή διαχείρισης των πολιτικών είναι υπεύθυνη για την εξωτερική επικοινωνία του ΜΑ, καθώς και για την αρμονική αλλαγή των πολιτικών του, στην αποθήκη πολιτικών, κατά την διάρκεια της λειτουργίας του. Όπως φαίνεται στο σχήμα, η μηχανή διαχείρισης των πολιτικών αποτελείται από τέσσερα βασικά συστατικά: Την υπηρεσία επικοινωνίας Την υπηρεσία πυροδότησης Την υπηρεσία προδιαγραφών Την αποθήκη πολιτικών Με περισσότερη λεπτομέρεια, η υπηρεσία επικοινωνίας λειτουργεί σαν διασύνδεση (interface), ώστε ο ΜΑ να είναι σε θέση να αλληλεπιδρά με τον Αιτών της Υπηρεσίας και με άλλες οντότητες μέσα στο δίκτυο. Η προαναφερθείσα λειτουργικότητα είναι δυνατή χάρη στην υπηρεσία παρακολούθησης, η οποία ξεχωρίζει τα μηνύματα που προέρχονται από τον αιτών και μέσω της υπηρεσίας 58

69 γεγονότων, που αντιλαμβάνεται και συλλαμβάνει γεγονότα που αφορούν την αλλαγή πολιτικών του ΜΑ. Οι υπηρεσίες γεγονότων και παρακολούθησης απαρτίζουν την υπηρεσία επικοινωνίας, όπως απεικονίζει το επόμενο σχήμα (Σχήμα 17). Όταν μια επικοινωνία σαν την προηγούμενη λάβει χώρα, η υπηρεσία πυροδότησης ειδοποιείται για να ανανεώσει την αποθήκη πολιτικών, που πραγματοποιείται με την χρήση της υπηρεσία προδιαγραφών. Τέλος, η μηχανή ταιριάσματος του ΜΑ, είναι απαραίτητη για την μετά-επεξεργασία των αποτελεσμάτων του Καταλόγου Υπηρεσιών, παραδείγματος χάριν, την επιβεβαίωση της διαθεσιμότητας των Παροχών Υπηρεσιών, πριν πραγματοποιηθεί η μετανάστευση σε αυτούς. Σχήμα 17. Υπηρεσία διαχείρισης πολιτικών του κινητού πράκτορα. Αναλυτικά, σε επίπεδο υλοποίησης, η δομή του ΜΑ παρουσιάζεται στο διάγραμμα κλάσεων του (Σχήμα 17). Η βασική κλάση του διαγράμματος είναι η ClientMobileAgent, η οποία αντιπροσωπεύει τον ΜΑ και κληρονομεί την κλάση Agent της πλατφόρμας κινητών πρακτόρων Grasshopper. Επίσης, υλοποιεί τις μεθόδους trigerservice (υπηρεσία πυροδότησης), SpecificationService (υπηρεσία προδιαγραφών) και το αντικείμενο repository (αποθήκη πολιτικών). Στην συνέχεια, διακρίνονται οι κλάσεις EventService (υπηρεσία γεγονότων) και MonitoringService (υπηρεσία παρακολούθησης), που κληρονομούν τις IEventService και την IMonitoringService αντίστοιχα. Στο τέλος, και οι δύο παραπάνω κλάσεις κληρονομούν την γενική διεπαφή επικοινωνίας ICommunicationService (υπηρεσία επικοινωνίας), η οποία αποτελεί τον δίαυλο επικοινωνίας του ΜΑ με άλλες οντότητες. Ουσιαστικά, όλα τα συστατικά της αρχιτεκτονικής του ΜΑ, που παρουσιάστηκαν σαν δομικά στοιχεία σε υψηλό επίπεδο, αντιστοιχούνται σε μεθόδους ή κλάσεις σε επίπεδο υλοποίησης. Τέλος, η κλάση Document χρησιμοποιείται για την υλοποίηση της αποθήκης πολιτικών και συγκεκριμένα την κατανόηση και επεξεργασία του σε μορφή XML. Η ακριβής αλληλουχία των μεθόδων στις διάφορες ενέργειες του ΜΑ παρουσιάζονται στην περιγραφή λειτουργικότητας. 59

70 Σχήμα 18. Διάγραμμα κλάσεων του Κινητού Πράκτορα (ΜΑ) Όπως έχει αναφερθεί προηγουμένως, οι πολιτικές του ΜΑ ορίζουν την ακριβή συμπεριφορά του μέσα στο δίκτυο. Αναλυτικά, στο σχήμα που ακολουθεί, παρουσιάζονται όλες οι πολιτικές που υποστηρίζει ο ΜΑ, οι οποίες διαχωρίζονται σε δύο είδη, τις λογικές, όπου true υποδηλώνει ικανότητα και false ανικανότητα, και σε αριθμητικές, όπου ο αριθμός δηλώνει τον πληθάριθμο. Όλες αυτές οι πολιτικές φυλάσσονται στο αρχείο policies.xml και στην συνέχεια εισάγονται στην βάση δεδομένων της Διαδικτυακής Εφαρμογής, όπου συσχετίζονται με τον χρήστη που τις έχει θέσει. Με αυτόν τον τρόπο δημιουργείται ένα προσωπικό προφίλ του κάθε χρήστη της εφαρμογής, που περιέχει τις πιο πρόσφατες επιλογές του. 60

71 Σχήμα 19. Δομή αρχείου policies.xml Το όνομα κάθε μιας πολιτικής υποδηλώνει και τη χρησιμότητα της. Συγκεκριμένα, οι πολιτικές <migrating> και <cloning> αναφέρονται στις ικανότητες του ΜΑ να μεταναστεύει σε κάποιον άλλο υπολογιστή και να δημιουργεί ακριβή αντίγραφα του εαυτού του κατά βούληση, αντίστοιχα. Η πολιτική <clonetoserver>, δίνει την ικανότητα στον ΜΑ να αποφασίσει κατά πόσο θα στείλει παράλληλα κλώνους του εαυτού του στους Παροχείς που έχει εντοπίσει, ή θα μεταναστεύσει σειριακά ο ίδιος σε κάθε ένα από αυτούς. Στην πρώτη περίπτωση, ο κάθε κλώνος γυρνάει πίσω στο σύστημα και περιμένει έως ότου επιστρέψει και ο πατέρας ΜΑ, έτσι ώστε να του παραδώσει τα αποτελέσματα του. Στο τέλος αυτής της διαδικασίας ο πατέρας ΜΑ θα έχει στην κατοχή του τα αποτελέσματα από όλους τους Παροχείς και με την σειρά του θα περιμένει το χρήστη να εισέλθει στο σύστημα για να του τα παραδώσει. Όλοι οι κλώνοι με το που θα μεταφέρουν τα αποτελέσματα που έχουν συλλέξει διαγράφονται από το σύστημα, για την αποφυγή υπέρογκης χρήσης της μνήμης του συστήματος. Στη συνέχεια, η πολιτική <callthroughstationary>, υποδεικνύει αν ο ΜΑ θα χρησιμοποιήσει τον στάσιμο πράκτορα του κάθε Παροχέα για να καλέσει την εκάστοτε Υπηρεσία που παρέχει, ή θα πρέπει να φορτώσει τις δικές του απαραίτητες βιβλιοθήκες για αυτόν τον σκοπό. Η πολιτική <pingserver> δηλώνει ότι ο ΜΑ πριν μεταναστεύσει στον Παροχέα, θα πρέπει να επιβεβαιώσει ότι διαθέσιμος. Όταν ο ΜΑ έχει επιστρέψει στον Αιτών της Υπηρεσίας, θα πρέπει να γνωρίζει αν θα εισέλθει σε κατάσταση 61

72 ανενεργή, κάτι που <suspendwhenfinished>. ορίζεται με την πολιτική Η υλοποιηθείσα πλατφόρμα, υποστηρίζει το σενάριο κατά το οποίο ο ΜΑ δεν μεταναστεύει στον Παροχέα, αλλά καλεί την Υπηρεσία με την χρήση SOAP/RPC. Η πολιτική που ορίζει την παραπάνω λειτουργικότητα ονομάζεται <migratetoserver>. Η πολιτική <hitallservices>, καθορίζει ότι οτιδήποτε και αν είναι η πολιτική <maxnumberofhits>, ο ΜΑ είναι υποχρεωμένος να καλέσει όλες τις Υπηρεσίες που έχει εντοπίσει. Επιπρόσθετα, ο χρήστης έχει την δυνατότητα να εξέλθει από την Διαδικτυακή Εφαρμογή και στην συνέχεια να εισέλθει με σκοπό να παραλάβει τα αποτελέσματα της Υπηρεσίας που έχει επιλέξει, αν η πολιτική <userdisconntedoperation> είναι ενεργοποιημένη. Στην περίπτωση αυτή ο ΜΑ δεν εισέρχεται ποτέ σε ανενεργή κατάσταση, αγνοώντας την πολιτική <suspendwhenfinished>. Αυτό γίνεται γιατί ο ΜΑ θα πρέπει να περιμένει τον χρήστη να του παραδώσει τα αποτελέσματα. Εκτός από τις λογικές πολιτικές, ο ΜΑ υποστηρίζει και έξι αριθμητικές. Συγκεκριμένα, η πολιτική <maxnumberofhits> ορίζει τον μέγιστο αριθμό Υπηρεσιών που είναι δυνατόν ο ΜΑ να κάνει κλήση, ενώ η πολιτική <minnumberofresults> καθορίζει το ελάχιστο πλήθος Υπηρεσιών που πρέπει να βρεθούν στον Κατάλογο Υπηρεσιών. Η παραπάνω λειτουργικότητα είναι δυνατή χάρη στον βαθμό ταύτισης που επιστέφει ο Κατάλογος Υπηρεσιών και επιτρέπει στο σύστημα να επιστρέφει πάντα ένα συγκεκριμένο πλήθος από Υπηρεσίες. Βέβαια, από ένα σημείο και μετά οι Υπηρεσίες είναι σχεδόν σίγουρο ότι δεν θα ικανοποιούν τον χρήστη, αφού ο βαθμός ταύτισης αυξάνεται κατακόρυφα. Στην περίπτωση όπου μια Υπηρεσία δεν αποκρίνεται μέσα σε ένα προκαθορισμένο χρονικό διάστημα, η πολιτική <retrytimes> καθορίζει το μέγιστο πλήθος των επιπρόσθετων προσπαθειών, ενώ ο χρόνος ανάμεσα από αυτές τις προσπάθειες ορίζεται από την πολιτική <timebetweenreattempts>. Τελειώνοντας, ο Αιτών της Υπηρεσίας έχει την δυνατότητα να εισάγει στο σύστημα τις πολιτικές <expectedresposetime> και <expectedserviceinteractiontime>, κυρίως για την αποδοτική αξιολόγηση της πλατφόρμας. Στάσιμος Πράκτορας του Παροχέα Υπηρεσιών (Provider Stationary Agent PSA) Ο PSA αντιπροσωπεύει τον Παροχέα Υπηρεσιών στο δίκτυο. Ο ΜΑ συναντά και επικοινωνεί με τον PSA στην πλατφόρμα του Παροχέα. Ο PSA επικοινωνεί με τον Παροχέα με τα προκαθορισμένα πρωτόκολλα που χρησιμοποιούνται στις Υπηρεσίες Διαδικτύου. Λογικό επακόλουθο αυτών, είναι ο PSA να πρέπει να κατανοεί και να παράγει SOAP μηνύματα, γεγονός που 62

73 οδηγεί σε μια πιο απλή και ελαφριά υλοποίηση του ΜΑ. Τα παραπάνω απεικονίζονται στο Σχήμα 20. Συγκεκριμένα, ο PSA προσφέρει προς εξωτερική χρήση τις μεθόδους που προσφέρει ο Παροχέας που αντιπροσωπεύει, έτσι ώστε να είναι δυνατή η κλήση οποιασδήποτε μεθόδου του μέσω του PSA. Η ολοκλήρωση κάθε κλήσης γίνεται σε ξεχωριστό νήμα, με σκοπό την βελτιστοποίηση της απόκρισης του PSA. Τέλος, ο PSA αποτελείται από δύο βασικά συστατικά: o Τα δεδομένα του o Τον κώδικα που υλοποιεί την συμπεριφορά του Αναλυτικά, σε επίπεδο υλοποίησης, παρουσιάζεται ο πράκτορας στο Σχήμα 20. Σχήμα 20. Δομή και λογική του PSA Στάσιμος Πράκτορας του Καταλόγου υπηρεσιών (Registry Stationary Agent RSA) Ο στάσιμος αυτός πράκτορας ενεργεί ως ενδιάμεσο στρώμα ανάμεσα από τον ΜΑ και τον Κατάλογο Υπηρεσιών. Ο ρόλος του είναι να παρέχει μέρος της λειτουργικότητας του Καταλόγου Υπηρεσιών και να επικοινωνεί με τον ΜΑ, με σκοπό να εξυπηρετεί τις αιτήσεις του, κάθε μια σε ξεχωριστό νήμα. Η προσέγγιση αυτή οδηγεί σε μια πιο απλή και ελαφριά υλοποίηση του ΜΑ, αφού δεν είναι υποχρεωμένος ο ΜΑ να μεταφέρει μέσα στο δίκτυο τις βιβλιοθήκες για την επικοινωνία με τον Κατάλογο Υπηρεσιών. Αναλυτικά, σε επίπεδο υλοποίησης, παρουσιάζεται ο πράκτορας στο Σχήμα 21. Σημασιολογικός Κατάλογος Υπηρεσιών (Semantic Web Service Registry SWSR) Ο Κατάλογος, όπως παρουσιάζεται στο ακόλουθο σχήμα (Σχήμα 21), αποτελείται από: o Έναν RSA o Ένα εργαλείο ταιριάσματος o Ένα UDDI κατάλογο υπηρεσιών Το εργαλείο ταιριάσματος εμπλουτίζει τον UDDI κατάλογο με σημασιολογική πληροφορία, κάτι που στη συνέχεια προσφέρει αναβαθμισμένη αναζήτηση μέσω οντολογιών. Σε συνδυασμό με 63

74 τον RACER, επεξεργάζεται τις OWL οντολογίες αναζήτησης, καθώς και τις OWL περιγραφές των Υπηρεσιών Διαδικτύου. Οι δημοσιευμένες πληροφορίες πρώτα υφίστανται επεξεργασία από τον UDDI κατάλογο και στην συνέχεια εφόσον περιέχουν οντολογική πληροφορία, προωθούνται στο εργαλείο ταιριάσματος. Τελικά, το εργαλείο επεξεργάζεται την επερώτηση και επιστρέφει το αποτέλεσμα στον UDDI κατάλογο, ο οποίος με την σειρά του προωθεί το αποτέλεσμα στο χρήστη. Η επιλογή του παραπάνω εργαλείου για χρήση στην πλατφόρμα, πάρθηκε από το γεγονός ότι αποτελεί ουσιαστικά μια επέκταση του ήδη εδραιωμένου καταλόγου UDDI, κάνοντας χρήση της λειτουργικότητας του. Όσο αφορά τον UDDI κατάλογο, έγινε η εγκατάσταση του τοπικά στο δίκτυο και συγκεκριμένα χρησιμοποιήθηκε η υλοποίηση JUDDI. Το JUDDI είναι μια εφαρμογή διαδικτύου που εξυπηρετείται από τον Apache Tomcat και υποστηρίζει όλη την λειτουργικότητα του UDDI πρότυπου καταλόγου. Όλη οι πληροφορία για τις Υπηρεσίες Διαδικτύου αποθηκεύεται στη βάση δεδομένων MySQL, που επίσης είναι εγκατεστημένη τοπικά. Οι πίνακες που χρησιμοποιούνται από το juddi είναι οι εξής: o auth_token o binding_template o business_entity o business_category o business_name o business_service o business_identifier o contact o discovery_url o publisher o service_name o service_category o tmodel o tmodel_category Επίσης, η μηχανή ταιριάσματος είναι υπεύθυνη για τον μετασχηματισμό της οντολογικής πληροφορίας και την αποθήκευση του στους παραπάνω πίνακες. Ένα από τα σημαντικότερα πλεονεκτήματα της μηχανής ταιριάσματος είναι ότι πέραν του ότι χρησιμοποιεί το juddi, δεν απαιτεί σύνδεση με το διαδίκτυο κατά την φάση αναζήτησης. Όλες οι απαραίτητες πληροφορίες που είναι αποθηκευμένες στο διαδίκτυο και χρησιμοποιούνται κατά την φάση της δημοσίευσης, αποθηκεύονται τοπικά στην μηχανή. Έτσι, οδηγούμαστε σε αναζητήσεις με αυξημένη ταχύτητα. Η μηχανή ταιριάσματος έχει υλοποιηθεί και προσφέρεται ελεύθερα από το Robotics Institute, στο πανεπιστήμιο Carnegie Mellon, με πλήρες περιγραφή και παραδείγματα. 64

75 Σχήμα 21. Σημασιολογικός κατάλογος υπηρεσιών Αναλυτικά, σε επίπεδο υλοποίησης, η δομή του Σημασιολογικού Καταλόγου Υπηρεσιών απεικονίζεται στο Σχήμα 23. Βασική κλάση του διαγράμματος είναι η Registry, που αντιπροσωπεύει τον Κατάλογο και υλοποιεί τις απαραίτητες μεθόδους για αναζήτηση, δημοσίευση και διαγραφή μιας Υπηρεσίας σε αυτόν. Για να καταστεί δυνατή αυτή η λειτουργικότητα, χρησιμοποιούνται οι κλάσεις OWLSMatchmakerClient και CapabilitySearch, που στο Σχήμα 21 αντιπροσωπεύονται από το συστατικό Matchmaker Tool. Τέλος, ο στάσιμος πράκτορας του Καταλόγου υλοποιείται από την κλάση RegistryStationaryAgent, που κληρονομεί την βασική της λειτουργικότητα από την κλάση StationaryAgent. Στη συνέχεια, η κλάση RegistryStationaryAgent προσφέρει τις λειτουργίες της Registry στον έξω κόσμο, μέσω της διεπαφής IStationaryAgent. Η ακριβής αλληλουχία των μεθόδων στις διάφορες ενέργειες του Σημασιολογικού Καταλόγου Υπηρεσιών, παρουσιάζονται στην περιγραφή λειτουργικότητας. 65

76 Σχήμα 22. Διάγραμμα κλάσεων του Σημασιολογικού Καταλόγου Υπηρεσιών, με τον Στάσιμο Πράκτορα Καταλόγου Παροχέας Υπηρεσιών Διαδικτύου (Web Service Provider WSP) Αποτελεί τον παροχέα των Υπηρεσιών Διαδικτύου. Όπως έχει αναφερθεί παραπάνω μπορεί να αντιπροσωπεύεται από έναν PSA ή όχι. Περιέχει την υλοποίηση των υπηρεσιών, καθώς και τις περιγραφές τους σε WSDL και OWL-S. Το Σχήμα 23 απεικονίζει τον WSP και τις λειτουργίες που υποστηρίζει. Σχήμα 23. Παροχέας των υπηρεσιών διαδικτύου Στο παρακάτω σχήμα παρουσιάζεται η δομή του Παροχέα Υπηρεσιών σε επίπεδο υλοποίησης. Αποτελείται από δύο βασικές κλάσεις, την WebService, που κληρονομεί την διεπαφή IWebService και την WebServiceStationaryAgent, που 66

77 κληρονομεί την IWebServiceStationaryAgent. Η πρώτη υλοποιεί την λειτουργικότητα του Παροχέα Υπηρεσιών και η δεύτερη του στάσιμου πράκτορα. Συγκεκριμένα, η κλάση WebService υλοποιεί όλες τις μεθόδους που προσφέρει ο Παροχέας και ο στάσιμος πράκτορας τις καλεί, με την χρήση της κλάσης Call του πακέτου Axis. Ο πράκτορας πραγματοποιεί κλήση Υπηρεσίας, όταν μια οντότητα καλέσει την αντίστοιχη μέθοδο της διεπαφής του. Η ακριβής αλληλουχία των μεθόδων στις διάφορες ενέργειες του Παροχέα Υπηρεσιών και του Στάσιμου Πράκτορα που τον εκπροσωπεί, παρουσιάζονται στην περιγραφή λειτουργικότητας. Σχήμα 24. Διάγραμμα κλάσεων του Παροχέα Υπηρεσιών 6.3Περιγραφή της Υπηρεσίας Η πλατφόρμα, μέσω των πολιτικών του ΜΑ, υποστηρίζει και την απευθείας κλήση μιας Υπηρεσίας από αυτόν. Σε αυτό το σενάριο, ο πράκτορας θα πρέπει να κατανοεί και να παράγει SOAP μηνύματα, 67

78 γεγονός που αυξάνει το μέγεθος του κατά την μεταφορά στο δίκτυο. Επιπλέον, ο Παροχέας πληροφορεί τον ΜΑ για το αν προσφέρει στάσιμο πράκτορα ή όχι, κάτι που επιτυγχάνεται μέσω της OWL-S περιγραφής της Υπηρεσίας. Σαν αποτέλεσμα, ανεξάρτητα με το αν η πολιτική <callthroughstationary> είναι ενεργή, η κλήση πραγματοποιείται μέσω του στάσιμου πράκτορα, μόνο εάν πραγματικά προσφέρεται από τον Παροχέα. Αυτή η υβριδική δομή οδηγεί σε μια πιο ελαστική και προσαρμόσιμη πλατφόρμα, ενισχύοντας την διαδικασία αξιολόγησης της με πληθώρα επιπρόσθετων δεδομένων. Ο εμπλουτισμός της WSDL περιγραφής των Υπηρεσιών Διαδικτύου, στηρίζεται στο γεγονός ότι αυτή προσφέρει μόνο τεχνικές πληροφορίες, χωρίς να περιέχει οντότητες κατανοητές από αυτοματοποιημένο λογισμικό. Ορίζει μια Υπηρεσία ως μια λειτουργία που προσφέρεται σε ένα URI, με κάποιες παραμέτρους, χωρίς να περιέχει σημασιολογική-οντολογική πληροφορία. Αντίθετα, η OWL-S ενισχύει τους Παροχείς Υπηρεσιών με ένα σύνολο από αυστηρά ορισμένες δομές και συγκεκριμένους κανόνες, που επαρκούν για να περιγράψουν την Υπηρεσία στο σύνολο της με τρόπο κατανοητό από μηχανές. Με αυτόν τον τρόπο, είναι δυνατόν να αυτοματοποιηθεί η διαδικασία αναζήτησης, κλήσης και ενορχήστρωσης των Υπηρεσιών. Η OWL-S (Web Ontology Language) είναι βασισμένη στην γλώσσα RDF (που χρησιμοποιήθηκε πρώτη στην περιγραφή οντολογιών) και είναι αποτέλεσμα δουλειάς που πραγματοποιήθηκε από την W3C, με σκοπό να δημιουργήσει μια πιο ισχυρή γλώσσα περιγραφής οντολογιών. Επίσης, ο σχεδιασμός της ενισχύθηκε από αρκετές γενιές ιδίου τύπου γλωσσών και οδήγησε σε ένα θεωρητικά άρτιο αποτέλεσμα, ικανό να υποστηρίξει την υλοποίηση του Σημασιολογικού Ιστού. Με βάση τα παραπάνω, καταλήγουμε στο συμπέρασμα ότι η δύναμη της OWL-S, βρίσκεται εκεί που υστερεί η WSDL και κατά αυτή την έννοια οι δύο γλώσσες είναι συμπληρωματικές. Για αυτόν τον λόγο οι υπηρεσίες που προσφέρονται από την παρούσα πλατφόρμα έχουν περιγραφεί και σε WSDL, που ορίζει τις τεχνικές λεπτομέρειες, και σε OWL-S, που καθορίζει τις οντολογίες που αποτελούν είσοδο και έξοδο της Υπηρεσίας Διαδικτύου. Συγκεκριμένα, οι παραπάνω σημασιολογικές πληροφορίες που αφορούν την Υπηρεσία Διαδικτύου αποθηκεύονται σε ένα αρχείο που ονομάζεται <όνομα_υπηρεσίας>profile.owl (π.χ. MyServiceProfile.owl), και εν συνεχεία δημοσιεύονται στην SWSR. Όσο αφορά την σύνταξη και τις δυνατότητες της OWL-S, η SWSR υποστηρίζει την OWL-S Lite. Όταν εντοπισθεί η επιθυμητή Υπηρεσία από την SWSR, η WSDL περιγραφή χρησιμοποιείται για την εξεύρεση των απαραίτητων τεχνικών πληροφοριών σχετικά με την κλήση της. Με περισσότερη λεπτομέρεια τα OWL-S αρχεία, αρχικά καθορίζουν το URI της Υπηρεσίας Διαδικτύου, καθώς και τις οντολογίες που 68

79 θα χρησιμοποιηθούν και είναι ορισμένες στο διαδίκτυο, όπως φαίνεται στο παρακάτω σχήμα. Σχήμα 25. Μέρος της OWL-S περιγραφής της υπηρεσίας διαδικτύου Οι οντολογίες που χρησιμοποιεί η παραπάνω υπηρεσία με όνομα WebService, υλοποιούνται στο αρχείο BravoAirProfile.owl. Μετά την επιτυχή πρόσβαση των παραπάνω αρχείων, οι οντολογίες εισόδου και εξόδου καθορίζονται, όπως παρουσιάζεται στο επόμενο σχήμα. Αρχικά, η παράμετρος εξόδου ItineraryOut ορίζεται ότι είναι τύπου Itinerary, μια οντολογία που ορίστηκε στα προηγούμενα αρχεία. Στη συνέχεια, οι παράμετροι ArrivalAirport, OutboundDate, ItineraryIn and Usernam, ορίζονται ότι είναι τύπου Airport, anyuri, Itinerary και anyuri αντίστοιχα. Σχήμα 26. Μέρος της OWL-S περιγραφής της υπηρεσίας Είσοδοι/ Έξοδοι Προαιρετικά είναι δυνατόν να δοθεί μια λεκτική περιγραφή της Υπηρεσίας, καθώς και πληροφορίες σχετικά με τον Παροχέα της, όπως απεικονίζεται παρακάτω. 69

80 Σχήμα 27. Μέρος της OWL-S περιγραφής της υπηρεσίας Λεκτική περιγραφή και πληροφορίες παροχέα. Όπως αναφέρθηκε παραπάνω, ο Παροχέας της Υπηρεσίας είναι δυνατόν να προσφέρει για εξωτερική επικοινωνία με τον ΜΑ, έναν στάσιμο πράκτορα. Το γεγονός αυτό γίνεται γνωστό μέσω στης OWL-S περιγραφής της εκάστοτε υπηρεσίας. Συγκεκριμένα, όταν προσφέρεται στάσιμος πράκτορας περιέχεται το αλφαριθμητικό Stationary στην ιδιότητα ID, του <rdf:description>, το οποίο περικλείει όλη την περιγραφή της Υπηρεσίας Διαδικτύου. Σε περίπτωση που δεν περιέχεται, ο ΜΑ πληροφορείται ότι δεν υπάρχει στάσιμος πράκτορας και προχωράει σε απευθείας κλήση, φορτώνοντας όλες τις απαραίτητες βιβλιοθήκες. Με την παραπάνω προσέγγιση επιτυγχάνεται ένα υβριδικό σύστημα, όπου ένα προκαθορισμένο ποσοστό των παροχών αντιπροσωπεύεται από ένα στάσιμο πράκτορα, ενώ το υπόλοιπο όχι. Οι οντολογίες που χρησιμοποιήθηκαν στον ορισμό των εισόδωνεξόδων της OWL-S Υπηρεσίας, ορίζονται στο αρχείο BravoAirProfile.owl. Ένα μέρος του αρχείου αυτού παρουσιάζεται στο σχήμα που ακολουθεί, όπου φαίνονται οι οντολογίες σε μια αρχική μορφή τους. Αρχικά, δηλώνονται τα απαραίτητα namespaces, ώστε να χρησιμοποιηθούν αργότερα στο αρχείο και στη συνέχεια λαμβάνουν χώρα οι ορισμοί των οντολογιών. Η οντολογία Service είναι τύπου root, εφόσον κανένα άλλο χαρακτηριστικό δεν της προσδίδεται. Ουσιαστικά, το μόνο που είναι γνωστό για αυτήν την κλάση, δεν είναι τίποτα άλλο, παρά η ύπαρξη της. Στη συνέχεια, οι οντολογίες airport και itinerary κατασκευάζονται με την χρήση της δεσμευμένης λέξης subclass of, που αποτελεί τον βασικό ταξινομικό κατασκευαστή κλάσεων. Στην περίπτωση αυτή οι κλάσεις ορίζονται ως υποκλάσεις της κλάσης Thing, μια οντολογία ορισμένη στο URL Στην γλώσσα OWL όλες οι δυνατές κλάσεις, είναι υποκλάσεις της owl:thing, ενώ η owl:nothing είναι στο άλλο άκρο, όντας μια κλάση χωρίς ιδιότητες. Τέλος, η ιδιότητα airportcode ορίζεται με domain Airport και range string. Με αυτόν τον τρόπο συσχετίζονται 70

81 στιγμιότυπα της κλάσης Airport, με στιγμιότυπα της κλάσης string. Σχήμα 28. Μέρος των οντολογιών της υπηρεσίας διαδικτύου Η χρήση της OWL-S είναι απαραίτητη, για την δημιουργία πραγματικών οντολογικών Υπηρεσιών Διαδικτύου. Είναι μια γλώσσα που δεν περιορίζεται στο να ορίζει απλός ένα λεξιλόγιο και να θέτει κανόνες και περιορισμού σε αυτό, αλλά προχωράει παραπέρα και προσφέρει: Αναφορές σε αρχεία που παρέχονται στο διαδίκτυο Συνεργασία με διαφορετικές γλώσσες όπως η RDF Οτιδήποτε ορίζει είναι δυνατόν να διαμοιραστεί στο διαδίκτυο Συνδυασμό διαφορετικών οντολογιών για την δημιουργία καινούργιων Μια τυπική προσέγγιση με ευρεία αποδοχή Επαρκή δύναμη για ουσιαστική και χρήσιμη χρήση Υποστήριξη λογικών συμπερασμών επαρκών για την υλοποίηση πραγματικών οντολογικών Υπηρεσιών Διαδικτύου. Οι OWL-S Υπηρεσίες, που χρησιμοποιήσαμε και τροποποιήσαμε για να ικανοποιούν τις ανάγκες μας, διατίθενται από το Robotics Institute, στο πανεπιστήμιο Carnegie Mellon, με πλήρες περιγραφή και παραδείγματα ). 6.4Περιγραφή Λειτουργικότητας Πλατφόρμας 6.4.1Αφαιρετικού Επιπέδου Για την πλήρη περιγραφή της λειτουργικότητας της πλατφόρμας, παρατίθεται το παρακάτω σενάριο: 71

82 Όπως παρουσιάζεται στα use cases, ο USR επιθυμεί να εντοπίσει και καλέσει μια συγκεκριμένη Υπηρεσία Διαδικτύου. Αρχικά, από μία ασύρματη συσκευή, συνδέεται με την Εφαρμογή Διαδικτύου (Client System). Μετά από την επιτυχή εισαγωγή του, που απαιτεί την εισαγωγή ονόματος χρήστη και συνθηματικού, ο USR θέτει τα κριτήρια της Υπηρεσίας Διαδικτύου που αναζητεί, καθώς και τις πολιτικές που ορίζουν την αυτόνομη συμπεριφορά του MA που τον εκπροσωπεί. Στην συνέχεια, το σύστημα είναι υπεύθυνο για την δημιουργία του ΜΑ, ο οποίος πριν μεταναστεύσει στον Κατάλογο υπηρεσιών, αποθηκεύει το μοναδικό αναγνωριστικό του χρήστη και φορτώνει τις πολιτικές που επέλεξε ο χρήστης. Οι πολιτικές, όπως έχει ήδη αναφερθεί, αποθηκεύονται σε μορφή XML, και οι πολιτικές που περιέχει αποθηκεύονται στην Αποθήκη Πολιτικών του ΜΑ, όπου η υπηρεσία πυροδότησης είναι υπεύθυνη για την τροποποίηση τους ανάλογα με τα μηνύματα που συλλαμβάνει η υπηρεσία γεγονότων, όταν σταλεί κάποιο μήνυμα από τον ΜΑ. Σχήμα 29. Use case 1 Ο ρόλος του SWSR, όπως έχει αναφερθεί, είναι να δημοσιοποιεί τις Υπηρεσίες Διαδικτύου, έτσι ώστε ο ΜΑ να είναι σε θέση να τις αναζητήσει με σημασιολογικά κριτήρια και να αποκτήσει την λίστα των Υπηρεσιών που τα ικανοποιούν. Στο σενάριο αυτό ο Παροχέας έχει ήδη δημοσιεύσει τις Υπηρεσίες του και ο ΜΑ μόλις αποχωρεί από την Εφαρμογή Διαδικτύου και κατευθύνεται προς τον SWSR. Σχήμα 30. Use case 2 72

83 Με την άφιξη του στον SWSR ο ΜΑ, επικοινωνεί με τον RS, ο οποίος αναλαμβάνει να εκτελέσει οποιαδήποτε είδους επερώτηση και να παραδώσει τα αποτελέσματα της σε αυτόν. Οι επερωτήσεις μπορεί να βασίζονται σε οντολογίες ή να περιορίζονται σε ταυτοποίηση αλφαριθμητικών. Συγκεκριμένα, ο ΜΑ χρησιμοποιεί τις προδιαγραφές και τις οντολογίες ή αλφαριθμητικά που έχει εισάγει ο χρήστης και επιλέγει τις πλησιέστερες Υπηρεσίες Διαδικτύου που τα ικανοποιούν. Το αποτέλεσμα της παραπάνω αναζήτησης είναι μια λίστα από URI Παροχών, με τις λειτουργίες που προσφέρουν, καθώς και τις παραμέτρους τους. Στη συνέχεια ο ΜΑ, έχοντας στην κατοχή τους Παροχείς στόχους, ανάλογα με τις πολιτικές του, επιλέγει ανάμεσα από τις ακόλουθες ενέργειες: Ελέγχει αν πραγματικά την στιγμή πριν την μετανάστευση του, ο Παροχέας είναι διαθέσιμος και προσφέρει την Υπηρεσία που έχει δημοσιεύσει στον SWSR. Με αυτόν τον τρόπο, ο ΜΑ αποφεύγει την ατυχή περίπτωση μετανάστευσης σε ανενεργό Παροχέα και ελαχιστοποιεί την πιθανότητα άσκοπης μεταφοράς του. Γεγονός που έχει σαν αποτέλεσμα την γενική αύξηση της απόδοσης της πλατφόρμας. Προχωρεί σε απομακρυσμένη κλήση της Υπηρεσίας από τον SWSR, χωρίς να μεταναστεύσει στον παροχέα. Μια ενέργεια που επίσης καθορίζεται από τις πολιτικές του ΜΑ. Η λειτουργικότητα αυτή προστέθηκε στον ΜΑ, για λόγους αποδοτικής αξιολόγησης της πλατφόρμας. Συγκεκριμένα, ανάλογα με το μέγεθος του ΜΑ και την απόσταση του από τον Παροχέα, ίσως να είναι αποδοτικότερη μια απομακρυσμένη κλήση, από μια τοπική, που φυσικά προϋποθέτει αρχικά μια μετανάστευση. Μεταναστεύει στον WSP και επικοινωνεί μαζί του μέσω του PSA. Η ενέργεια αυτή προϋποθέτει ένα Παροχέα που αντιπροσωπεύεται από στάσιμο πράκτορα, γεγονός που γίνεται γνωστό στον ΜΑ μέσω της OWL-S περιγραφής της Υπηρεσίας Διαδικτύου, όπως αναλύθηκε παραπάνω. Ο λόγος που παρέχεται στάσιμος πράκτορας είναι να διερευνηθεί η διαφορά αποδοτικότητας, όταν ο ΜΑ διαθέτει τις δικές του βιβλιοθήκες κλήσης, σε αντίθεση όταν αυτές φορτώνονται από τον PSA για την εξυπηρέτηση του ιδίου. Στην τελευταία περίπτωση, ο ΜΑ απλός καλεί την Υπηρεσία μέσω του PSA και περιμένει να παραλάβει τα αποτελέσματα. Να μεταναστεύσει στο WSP, αλλά να καλέσει απευθείας την Υπηρεσία Διαδικτύου. Η επιλογή αυτή προϋποθέτει μια αρκετά λιγότερο πολύπλοκη υλοποίηση του ΜΑ, αλλά ταυτόχρονα μεγαλύτερη όγκο. Να στείλει κλώνους του εαυτού του, ένα σε κάθε WSP, αντί να μεταναστεύσει σειριακά ο ίδιος σε όλους. Με αυτή την ενέργεια επιτυγχάνεται παράλληλη κλήση των εντοπισθέντων Υπηρεσιών, με αποτέλεσμα την βελτίωση της απόδοσης όλης της πλατφόρμας. 73

84 Όλες οι παραπάνω συμπεριφορές του ΜΑ, καθορίζονται κατά την δημιουργία του και είναι δυνατόν να αλλάξουν σε όλη την διάρκεια της ζωής του. Σχήμα 31. Use case 3 Μετά την λήψη των αποτελεσμάτων, ανάλογα με τις πολιτικές που έχουν επιλεγεί από τον χρήστη υπάρχουν τα εξής σενάρια: Από την στιγμή που ο ΜΑ συλλέξει τα αποτελέσματα και από τον τελευταίο Παροχέα, μεταναστεύει πίσω στον Αιτούντα της Υπηρεσίας, όπου τον περιμένει να εισαχθεί στο σύστημα και να ζητήσει τα αποτελέσματα. Οι κλώνοι επιστρέφουν στον Αιτούντα της Υπηρεσίας και περιμένουν τον πατέρα τους να επιστρέψει. Με το που λάβει χώρα το παραπάνω, ο κάθε κλώνος παραδίδει τα αποτελέσματα του στον πατέρα ΜΑ και στη συνέχεια διαγράφεται από το σύστημα. Όταν ολοκληρωθεί η διαδικασία διαγραφής, ο πατέρας ΜΑ περιμένει να παραδώσει τα αποτελέσματα στον χρήστη. Οποιοδήποτε παραπάνω σενάριο μπορεί να επαναληφθεί, έχοντας πάντα ο χρήστης την δυνατότητα να αλλάξει τις πολιτικές του ΜΑ και φυσικά τα κριτήρια αναζήτησης. Επίσης, κατά την διάρκεια της όλης διαδικασίας αναζήτησης, εκτέλεσης και παράδοσης των αποτελεσμάτων είναι δυνατόν ο χρήστης να πληροφορηθεί την τρέχουσα θέση του ΜΑ, να τον ακυρώσει ή να τον αναγκάσει να επιστρέψει. Τέλος, ο κάθε χρήστης που έχει δικαιώματα διαχειριστή έχει πρόσβαση στο διαχειριστικό χρηστών της εφαρμογής, όπου παρέχονται τα παρακάτω: Διαγραφή χρήστη της εφαρμογής Αλλαγή του συνθηματικού και ονόματος χρήστη Δημιουργία καινούργιου χρήστη 74

85 Δημιουργία καινούργιου διαχειριστή Αναβάθμιση απλού χρήστη σε διαχειριστή Υποβάθμιση διαχειριστή σε απλό χρήστη Επιπέδου Υλοποίησης Στο υποκεφάλαιο αυτό θα περιγραφεί η αλληλουχία των μεθόδων που καλούνται για την επίτευξη της λειτουργικότητας της πλατφόρμας, όπως αυτή περιγράφτηκε στην προηγούμενη υποενότητα. Συγκεκριμένα, θα αναλυθούν τα τρία βασικά συστατικά της: Ο Κινητός Πράκτορας (ΜΑ) Ο Κατάλογος Σημασιολογικών Υπηρεσιών Ο Παροχέας Σημασιολογικών Υπηρεσιών Κινητός Πράκτορας Ο Κινητός Πράκτορας, που εκπροσωπεί τον χρήστη στο δίκτυο προσφέρει την παρακάτω λειτουργικότητα: Εντοπισμός της τρέχουσας θέσης του από τον χρήστη. Το όνομα της μεθόδου του ΜΑ που καλείται είναι tracemobileagent() και η αλληλουχία κλήσεων απεικονίζεται στο παρακάτω σχήμα. Σχήμα 32. Διάγραμμα Ακολουθίας tracemobileagent Ο χρήστης μέσω της Εφαρμογής Διαδικτύου, δημιουργεί ένα proxy στον ClientMobileAgent και στη συνέχεια καλεί την μέθοδο tracemobileagent() της διεπαφής του. Η κλήση αυτή 75

86 προωθείται, μέσω της διεπαφής IMonitoringService στην MonitoringService, η οποία αναλαμβάνει την εκτέλεση της αίτησης, καλώντας την μέθοδο tracemobileagent() που είναι υλοποιημένη στην κλάση ClientMobileAgent. Ακύρωση της λειτουργίας του. Το όνομα της μεθόδου του ΜΑ που εκτελείται είναι cancelagentexecution() και συγκεκριμένα η όλη διαδικασία παρουσιάζεται παρακάτω. Σχήμα 33. Διάγραμμα ακολουθίας cancelagentexecution Σε απόλυτη αντιστοιχία με την κλήση της tracemobileagent(), η cancelagentexecution() εκτελείται από την κλάση MonitoringService. Επιστροφή του στον χρήστη. Το όνομα της μεθόδου του ΜΑ που εκτελείται είναι getbackhome() και συγκεκριμένα η όλη διαδικασία παρουσιάζεται παρακάτω. Σχήμα 34. Διάγραμμα Ακολουθίας getbackhome 76

87 Όπως και σε κάθε επικοινωνία με τον ΜΑ, η Εφαρμογή Διαδικτύου δημιουργεί ένα proxy με αυτόν και στην συνέχεια επιλέγει την μέθοδο της διεπαφής ICommunicationService που επιθυμεί να εκτελέσει. Στην συνέχεια, η κλήση προωθείται στην κλάση MonitoringService, η οποία καλεί την getbackhome() από την ClientMobileAgent. Η τελευταία, καλεί την transferresultstobase(), η οποία καλεί την move() με τις κατάλληλες παραμέτρους, έτσι ώστε ο ΜΑ να επιστρέψει στον χρήστη. Κλήση Υπηρεσίας Διαδικτύου. Η κλήση αυτή είναι δυνατόν να γίνει με δύο τρόπους, μέσω του στάσιμου πράκτορα του Παροχέα, είτε απευθείας με χρήση RPC. Συγκεκριμένα, η όλη διαδικασία παρουσιάζεται στα δύο παρακάτω διαγράμματα ακολουθίας, με πρώτο αυτό της απευθείας κλήσης, όπου καλείται η μέθοδος invokationofwswithrpc() του ΜΑ. Στην συνέχεια δημιουργείται ένα αντικείμενο Call, με την κλήση της createcall() της κλάσης Service. Τέλος, η κλήση πραγματοποιείται με την εκτέλεση της invoke(), της κλάσης Call του πακέτου Axis. Σχήμα 35. Διάγραμμα Ακολουθίας Απευθείας Κλήση Υπηρεσίας με RPC Στην περίπτωση της κλήσης μέσω του στάσιμου πράκτορα που εκπροσωπείται ο Παροχέας της Υπηρεσίας, είναι απαραίτητη η δημιουργία ενός proxy με τον στάσιμο πράκτορα, ώστε να είναι δυνατή η κλήση υπηρεσίας, εκτελώντας την αντίστοιχη μέθοδο της διεπαφής του. Συγκεκριμένα, καλείται η invokationofwsthroughstationary(), η οποία δημιουργεί τον proxy και καλεί μέσω αυτού την μέθοδο getbyteresult() της διεπαφής του στάσιμου πράκτορα. Στην συνέχεια ο 77

88 πράκτορας αναλαμβάνει την πραγματική κλήση Υπηρεσίας ακριβώς όπως και στην πρώτη περίπτωση. της Σχήμα 36. Διάγραμμα Ακολουθίας Κλήση Υπηρεσίας μέσω Στάσιμου Πράκτορα Αποστολή μηνύματος. Το όνομα της μεθόδου του ΜΑ που εκτελείται είναι sendmessagetomobileagent() και συγκεκριμένα η όλη διαδικασία παρουσιάζεται στο σχήμα

89 Σχήμα 37. Διάγραμμα Ακολουθίας Αποστολή μηνύματος στον ΜΑ Η Εφαρμογή Διαδικτύου, μέσω του proxy αντικειμένου, καλεί την sendmessagetomobileagent() της διεπαφής ICommunicationService() του ΜΑ, όπως και στις προηγούμενες περιπτώσεις. Η κλήση αυτή προωθείται στην κλάση EventService που αναλαμβάνει την κατανόηση του περιεχομένου του μηνύματος, καλώντας την getmessagemeaning(). Για την κατανόηση, καλείται η μέθοδος newdocumentbuilder() της κλάσης Document, που με την σειρά της καλεί την μέθοδο getelementsbytagname(), μια φορά για κάθε πολιτική. Στην συνέχεια, καλείται η invoketrigerservice(), που με την σειρά της καλεί την trigerservice, η οποία αναλαμβάνει να διεκπεραιώσει την εντολή που περιέχει το μήνυμα, καλώντας την updatepolicyrepository(), για να ανανεωθούν τυχόν εντολές αλλαγής των πολιτικών και την specificationservice(), για να τεθούν οι αλλαγές αυτές σε ισχύ. Τέλος, καλείται και η μέθοδος που αντιστοιχεί στην εντολή που έχει σταλεί. 79

90 Κατάλογος Σημασιολογικών Υπηρεσιών Διαδικτύου Ο Κατάλογος Σημασιολογικών Υπηρεσιών Διαδικτύου, προσφέρει την παρακάτω λειτουργικότητα: Επερώτηση βάση Αλφαριθμητικού. Ελέγχεται η πλήρης ή μερική ταύτιση αυτού με την περιγραφή ή το όνομα των δημοσιευμένων υπηρεσιών. Αναλυτικά, παρουσιάζεται στο σχήμα 38, η αλληλουχία των μεθόδων που καλούνται. Σχήμα 38. Διάγραμμα Ακολουθίας Επερώτηση βάση Αλφαριθμητικού Η επικοινωνία του ΜΑ, με τον Κατάλογο γίνεται μέσω του στάσιμου πράκτορα του Καταλόγου. Ο ΜΑ δημιουργεί για τον σκοπό αυτό ένα αντικείμενο proxy και καλεί μέσω αυτού τις μεθόδους της διεπαφής του πράκτορα, ο οποίος αναλαμβάνει την πραγματική επικοινωνία με τον Κατάλογο και την επιστροφή των αποτελεσμάτων στον ΜΑ. Πιο αναλυτικά, καλείται η μέθοδος query() της διεπαφής IRegistryStationaryAgent, και προωθείται η κλήση στην κλάση Registry, η οποία καλεί τις enablelogging() και query(). Η πρώτη καλείται για να ενεργοποιηθεί η διαδικασία και η δεύτερη πραγματοποιεί την αναζήτηση και επιστρέφει τα αποτελέσματα. Οι δύο αυτές μέθοδοι ανήκουν στην κλάση OWLSMatchmakerClient(), που έχει υλοποιηθεί από το πανεπιστήμιο Carnegie Mellon. Επερώτηση βάση οντολογιών. Ελέγχεται η πλήρης ή μερική ταύτιση των επιλεγμένων οντολογιών από τον χρήστη, με αυτές που χαρακτηρίζουν τις δημοσιευθείσες Υπηρεσίες. Συγκεκριμένα, όπως απεικονίζεται στο σχήμα 39, καλείται η queryusingcapabilitysearch() της διεπαφής του στάσιμου πράκτορα του Καταλόγου. Με αυτόν τον τρόπο, εκτελείται η υλοποιημένη μέθοδος της κλάσης 80

91 RegistryStationaryAgent, η οποία προωθεί την κλήση στην Registry. Στη συνέχεια, εκτελούνται οι setowlsurl(), addimporturl(), addinput() και addoutput() της κλάσης CapabilitySearch. Αυτό γίνεται για την προσθήκη των συγκεκριμένων οντολογιών που διάλεξε ο χρήστης, στην επερώτηση. Τέλος, όπως και στην επερώτηση βάση αλφαριθμητικού εκτελούνται οι enablelogging() και query(), με την τελευταία να επιστρέφει τα αποτελέσματα. Σχήμα 39. Διάγραμμα Ακολουθίας Επερώτηση βάση οντολογιών Παροχέας Σημασιολογικών Υπηρεσιών Διαδικτύου Ο Παροχέας δίνει την δυνατότητα στους ΜΑ να καλούν τις Υπηρεσίες που προσφέρει και να συλλέγουν τα αποτελέσματα. Αυτό είναι δυνατό είτε μέσω του στάσιμου πράκτορα που τον αντιπροσωπεύει, είτε απευθείας. Στη συνέχεια, παρουσιάζονται και οι δύο περιπτώσεις, με πρώτη αυτή που χρησιμοποιείται στάσιμος πράκτορας. 81

92 Σχήμα 40. Διάγραμμα ακολουθίας Κλήση Υπηρεσίας μέσω Στάσιμου Πράκτορα Στο σχήμα 40, ο ΜΑ καλεί την Υπηρεσία που επιθυμεί, έστω ότι ονομάζεται getbytesresult(), από την διεπαφή του στάσιμου πράκτορα του Παροχέα. Με αυτό τον τρόπο εκτελείται η πραγματικά υλοποιημένη μέθοδος της κλάσης WebServiceStationaryAgent, η οποία καλεί την createcall της Service, για την δημιουργία ενός αντικειμένου Call. Πάνω σε αυτό, καλείται η πραγματική Υπηρεσία που προσφέρει ο Παροχέας και επιστρέφονται στον ΜΑ τα αποτελέσματα. Σχήμα 41. Διάγραμμα ακολουθίας Απευθείας Κλήση Υπηρεσίας Στο σχήμα 41, απεικονίζεται η περίπτωση απευθείας κλήσης της υπηρεσίας από τον ΜΑ. Έστω ότι ο χρήστης επιθυμεί την Υπηρεσία getintresult(). Ο ΜΑ, χωρίς να δημιουργήσει proxy, αφού δεν πραγματοποιείται επικοινωνία μεταξύ πρακτόρων, καλεί την Υπηρεσία getintresult(), ακριβώς όπως περιγράφτηκε στα τελευταία αντίστοιχα στάδια της προηγούμενης περίπτωσης. 82

93 83

94 7Κεφάλαιο : Αξιολόγηση των Επιδόσεων της Πλατφόρμας 7.1Εισαγωγή Σκοπός της παρούσης πλατφόρμας, δεν ήταν μόνο η σχεδίαση και υλοποίησή της, αλλά και η αξιολόγησή της. Η μέτρηση των επιδόσεων και οι ακριβείς χρόνοι των αλληλεπιδράσεων θα ήταν ένα σημαντικό αποδεικτικό στοιχείο όσον αφορά την αξιοποίηση της πλατφόρμας σε συγκεκριμένα περιβάλλοντα. Τέτοια περιβάλλοντα είναι εκείνα με περιορισμένους υπολογιστικούς πόρους ή με επισφαλείς συνδέσεις. Όπως θα δειχτεί παρακάτω με τη βοήθεια των διαγραμμάτων, σε περιβάλλοντα με υπηρεσίες μεγάλου όγκου δεδομένων είναι προτιμότερο να μετακινείται η υπολογιστική λογική στα δεδομένα και όχι τα δεδομένα στη υπολογιστική λογική. Η αξιολόγηση της πλατφόρμας και των παραλλαγών που υποστηρίζει έγινε σε σύγκριση με το παραδοσιακό μοντέλο των υπηρεσιών διαδικτύου. Για το σκοπό αυτό αναπτύχθηκαν και μετρήθηκαν οι επιδόσεις των εξής συστημάτων: Ένα σύστημα υλοποιημένο με βάση το παραδοσιακό μοντέλο εξυπηρέτη εξυπηρετούμενου. Το σύστημα αυτό είναι εξ ολοκλήρου βασισμένο στην ανταλλαγή SOAP/RPC μηνυμάτων απομακρυσμένων εφαρμογών. Ένα σύστημα βασισμένο στην πλατφόρμα που ήδη έχει περιγραφεί στο οποίο οι παροχείς των υπηρεσιών αντιπροσωπεύονται από στάσιμους πράκτορες (stationary agents), όπως και η υπηρεσία καταλόγου. Ένα σύστημα επίσης βασισμένο στην πλατφόρμα των κινητών πρακτόρων, στο οποίο δεν υπάρχουν στάσιμοι πράκτορες σε καμία οντότητα που συμμετέχει. Ένα υβριδικό σύστημα στο οποίο κάποιοι από τους παρόχους των υπηρεσιών αντιπροσωπεύονται από στάσιμους πράκτορες και κάποιοι όχι. Στο σχήμα που ακολουθεί απεικονίζεται η τοπολογία του δικτύου που χρησιμοποιήθηκε για την επίτευξη των μετρήσεων και της αξιολόγησης των συστημάτων. 84

95 Σχήμα 42. Τοπολογία δικτύου αξιολόγησης πλατφόρμας Όπως φαίνεται στο Σχήμα 42, το δίκτυο αποτελείται από 2 σταθερούς υπολογιστές και ένα φορητό, οι οποίοι έχουν όλοι πρόσβαση στο διαδίκτυο. Ο χρήστης μπορεί μέσω οποιασδήποτε κινητής συσκευής που υποστηρίζει κάποιον περιηγητή (browser), όπως ένα PDA, να συνδεθεί στο σύστημα δημιουργώντας νέο λογαριασμό και στο εξής να εκμεταλλευτεί τις δυνατότητες που του παρέχονται. Προκειμένου να επιτευχθεί όσο το δυνατό μεγαλύτερη ακρίβεια και λιγότερα σφάλματα στις μετρήσεις, τα ρολόγια των υπολογιστών που χρησιμοποιήθηκαν ήταν συγχρονισμένα με ακρίβεια χιλιοστών του δευτερολέπτου. Επίσης, οι υπηρεσίες που παρέχονταν από τους παροχείς που υπήρχαν στο δίκτυο, επέστρεφαν πάντοτε ένα συγκεκριμένο και καθορισμένο αριθμό από bytes ώστε να υπάρχει ένα μέτρο σύγκρισης όσον αφορά στη διάσταση ή τον όγκο των δεδομένων πάνω στο δίκτυο. Επομένως, οι μετρήσεις που έγιναν για όλα τα παραπάνω συστήματα πραγματοποιήθηκαν με υπηρεσίες που επέστρεφαν 1ΚΒ, 10ΚΒ, 100ΚΒ και 1ΜΒ δεδομένων κάθε φορά. 7.2Αξιολόγηση χρόνων Τα στοιχεία υπολογίστηκαν από τα παραπάνω συστήματα, που κάνουν χρήση κινητών πρακτόρων, ήταν η μέση τιμή των χρόνων που χρειαζόταν προκειμένου να γίνουν οι μετακινήσεις (migrations) των κινητών πρακτόρων από παροχέα σε παροχέα, όπως επίσης η μέση τιμή των χρόνων που χρειαζόταν για τις διάφορες αλληλεπιδράσεις των πρακτόρων με τους παροχείς των υπηρεσιών. Στην συνέχεια, υπολογίστηκε μέσω της εξίσωσης (1) ο συνολικός χρόνος από την στιγμή μετανάστευσης του κινητού πράκτορα από την Εφαρμογή Διαδικτύου, έως και την επιστροφή του με τα αποτελέσματα (Total Service Time - TSTMA). 85

96 N TSTMA = RIT+ (MSPT+ ITSP)i (1) i=1 Όπου, RIT (Registry Interaction Time), ο χρόνος αλληλεπίδρασης με τον Κατάλογο Υπηρεσιών, MSPT (Migration to i Service Provider) ο χρόνος μετανάστευσης στον i-στό Παροχέα Υπηρεσιών Διαδικτύου, ISTP (Integration Time with the i Service Provider) ο χρόνος ανταλλαγής δεδομένων με των i-στό Παροχέα Υπηρεσιών και Ν το πλήθος των Παροχέων που έχουν εντοπιστεί στον Κατάλογο Υπηρεσιών. Όσον αφορά στο παραδοσιακό μοντέλο των υπηρεσιών διαδικτύου, μετρήθηκαν οι μέσες τιμές χρόνων που χρειάστηκαν για αλληλεπιδράσεις με τους Παροχείς και τις κλήση των υπηρεσιών. Στην συνέχεια μέσω της εξίσωσης (2) υπολογίστηκε ο συνολικός χρόνος (Total Service Time - TSTWSBM) από την στιγμή κλήσης της υπηρεσίας έως και την παραλαβή του αποτελέσματος. N TSTWSBM = RIT+ ITSP (2) i i=1 Όπου, με RIT (Registry Interaction Time) συμβολίζεται ο χρόνος αλληλεπίδρασης με τον Κατάλογο Υπηρεσιών, όπως και στην περίπτωση των κινητών πρακτόρων, με ITSP ο χρόνος που μεσολαβεί ανάμεσα από την κλήση της Υπηρεσίας, έως και την παραλαβή των αποτελεσμάτων. Τέλος, μέσω του τύπου (3), υπολογίστηκε ο μέσος χρόνος (AST) για το κλασικό μοντέλο των Υπηρεσιών Διαδικτύου και για το προτεινόμενο. AST= TST N (3) Συγκεκριμένα, οι χρόνοι μετακίνησης του κινητού πράκτορα από τη διαδικτυακή εφαρμογή Client System, στην υπηρεσία καταλόγου και μετά σε κάθε ένα παροχέα της υπηρεσίας ξεχωριστά, οι μέσοι χρόνοι που μετρήθηκαν όταν η υπηρεσίες διαδικτύου επιστρέφουν δεδομένα μεγέθους 1ΚΒ έχουν ως εξής: 86

97 AVERAGE MIGRATION TIMES 600,00 500,00 400,00 300,00 200,00 100,00 0, WITH SA WITHOUT SA HYBRID Σχήμα 43. Μέσοι χρόνοι μετακίνησης 1ΚΒ υπηρεσία Τα συστήματα που λαμβάνουν μέρος στις μετρήσεις αυτές είναι με στάσιμους πράκτορες, χωρίς στάσιμους πράκτορες και το υβριδικό. Όπως φαίνεται στο σχήμα, το σύστημα με τους στάσιμους πράκτορες υπερισχύει σε αυτή την περίπτωση με μέσο όρο μετανάστευσης που αγγίζει τα 250 περίπου χιλιοστά του δευτερολέπτου. Στην περίπτωση που οι υπηρεσίες επιστρέφουν δεδομένα της τάξεως των 10ΚΒ, τα αντίστοιχα αποτελέσματα έχουν ως εξής: AVERAGE MIGRATION TIMES 600,00 500,00 400,00 300,00 200,00 100,00 0,00 1 WITH SA 2 WITHOUT SA 3 HYBRID Σχήμα 44. Μέσοι χρόνοι μετακίνησης 10ΚΒ υπηρεσία Στην περίπτωση αυτή το υβριδικό μοντέλο παρουσιάζει τους καλύτερους χρόνους με μέση τιμή αυτή των 310 χιλιοστών του δευτερολέπτου περίπου. Στο σημείο αυτό πρέπει να σημειωθεί ότι μια μικρή άνοδος του χρόνου ήταν αναμενόμενη, καθώς ο κινητός πράκτορας κατά την εκάστοτε μετακίνηση από παροχέα σε παροχέα έχει 10ΚΒ μαζί του επιπρόσθετο φόρτο από την τελευταία κλήση. Επομένως, όσο μεγαλώνει το μέγεθος της υπηρεσίας, 87

98 αναμένουμε να μεγαλώνουν και οι χρόνοι που απαιτούνται για τις μετακινήσεις του πράκτορα. Όταν οι υπηρεσίες επιστρέφουν δεδομένα με όγκο 100ΚΒ, οι χρόνοι μετανάστευσης έχουν την εξής μορφή: AVERAGE MIGRATION TIMES 500,00 480,00 460,00 440,00 420,00 400,00 380,00 360,00 1 WITH SA 2 3 WITHOUT SA HYBRID Σχήμα 45. Μέσοι χρόνοι μετακίνησης 100ΚΒ υπηρεσία Όπως και προηγουμένως, έτσι κι εδώ φαίνεται να υπερισχύει το υβριδικό μοντέλο με μέσο όρο για κάθε μετακίνηση τα 410 χιλιοστά του δευτερολέπτου περίπου. Στο σημείο αυτό, όμως, θα πρέπει να αναφερθεί ότι στις περιπτώσεις που οι υπηρεσίες επιστρέφουν μικρά μεγέθη δεδομένων, για παράδειγμα λιγότερα από 300ΚΒ, δεν είναι δυνατόν να έχουμε μια αντικειμενική άποψη των πραγμάτων. Σε τόσο μικρά δεδομένα οι διαφορές δεν είναι δυνατόν να φανούν εύκολα μεταξύ των συστημάτων, καθώς τόσο ο πράκτορας, όσο και τα δεδομένα έχουν το ίδιο μέγεθος περίπου. Η τελευταία περίπτωση που ακολουθεί με επιστρεφόμενο μέγεθος δεδομένων από τις υπηρεσίες 1ΜΒ φαίνεται στο ακόλουθο σχήμα: AVERAGE MIGRATION TIMES 800,00 750,00 700,00 650,00 600,00 550,00 1 WITH SA 2 WITHOUT SA 3 HYBRID Σχήμα 46. Μέσοι χρόνοι μετακίνησης 1ΜΒ υπηρεσία 88

99 Στην περίπτωση αυτή η διαφορά είναι εμφανής: Το σύστημα στο οποίο οι οντότητες εκπροσωπούνται από στάσιμους πράκτορες παρουσιάζει τα καλύτερα αποτελέσματα όσον αφορά στις μετακινήσεις, με μέσο όρο τα 640 χιλιοστά του δευτερολέπτου περίπου. Το παρακάτω διάγραμμα παρουσιάζει όλα τις παραπάνω περιπτώσεις και συγκεκριμένα παρουσιάζει τους μέσους χρόνους μετακίνησης συναρτήσει των μεγεθών που επιστρέφουν οι υπηρεσίες Average MSPT 500 WITH PSA 400 NO PSA HY BRID KB 10 KB 100 KB 1 MB Service result volume Σχήμα 47. Μέσοι χρόνοι μετακίνησης συναρτήσει του όγκου των δεδομένων Όπως έχει αναφερθεί και παραπάνω, όσο το μέγεθος των δεδομένων μεγαλώνει, τόσο αυξάνονται και οι χρόνοι μετανάστευσης. Από το παραπάνω σχήμα φαίνεται ξεκάθαρα ότι το σύστημα με στάσιμους πράκτορες ακολουθεί μια φυσικότερη συμπεριφορά σε σχέση με τα υπόλοιπα συστήματα, όπου οι χρόνοι αυξάνονται σχεδόν γραμμικά με την αύξηση των δεδομένων. Για υπηρεσίες που επιστρέφουν λιγότερο από 300 ΚΒ περίπου, όπως φαίνεται και στο σχήμα, δε μπορούμε να έχουμε μια ξεκάθαρη εικόνα. Από την τιμή αυτή όμως και καθώς τα δεδομένα αυξάνονται οι χρόνοι τείνουν να αυξηθούν απότομα με εξαίρεση το προαναφερθέν σύστημα που ακολουθεί μια πιο γραμμική συμπεριφορά. Το Σχήμα 48 απεικονίζει τον μέσο χρόνο σε ms που απαιτείται για την ολοκλήρωση μιας δοσοληψίας μεταξύ του κινητού πράκτορα 89

100 και του Παροχέα της Υπηρεσίας (average ITSP), σε σχέση με την εκάστοτε επιλεγμένη πολιτική, για μέγεθος επιστρεφόμενου αποτελέσματος 1ΜΒ. Τα αρχικά WSBM αντιπροσωπεύουν τις μέτρησης του κλασικού μοντέλου Υπηρεσιών Διαδικτύου, τα CL αντιπροσωπεύουν την περίπτωση που ο κινητός πράκτορας που εκπροσωπεί τον χρήστη στέλνει κλώνους του σε κάθε Παροχέα παράλληλα και τέλος τα PSA, υποδεικνύουν την περίπτωση που χρησιμοποιείται ο στάσιμος πράκτορας του Παροχέα. AVERAGE ITSP 16000, , , , ,00 AVERAGE 6000, , ,00 0, SA NO_SA WSBM 4 5 CL+SA CL+NO_SA 6 HYBRID 7 HYBRID+CLE Σχήμα 48. Μέσο ITSP υπηρεσίας 1ΜΒ Παρατηρείται, ότι τόσο στην περίπτωση που η πολιτική στάσιμου πράκτορα είναι ενεργοποιημένη ή όχι, όσο και σε αυτήν που το 50% των Παρόχων Υπηρεσίας προσφέρουν στάσιμο πράκτορα (Hybrid), ενώ οι υπόλοιποι όχι, ο μέσος χρόνος ολοκλήρωσης της δοσοληψίας είναι μικρότερος από αυτόν του κλασικού μοντέλου των Υπηρεσιών Διαδικτύου. Στις υπόλοιπες περιπτώσεις, δηλαδή όταν οι πολιτική της αποστολής κλώνων είναι ενεργοποιημένη, ο μέσος χρόνος είναι μεγαλύτερος. Αντίθετα, όσο το μέγεθος του αποτελέσματος της υπηρεσίας μικραίνει, το κλασικό μοντέλο των Υπηρεσιών Διαδικτύου αναδεικνύεται το επικρατέστερο. Το επόμενο διάγραμμα, αφορά ακριβώς τα ίδια μεγέθη, αλλά για Υπηρεσία Διαδικτύου με αποτέλεσμα 100ΚΒ. 90

101 AVERAGE ITSP 3500, , , ,00 AVERAGE 1500, ,00 500,00 0, SA 3 NO_SA 4 WSBM 5 6 CL+SA CL+NO_SA 7 HYBRID HYBRID+CLE Σχήμα 49. Μέσο ITSP υπηρεσίας 100ΚΒ Παρατηρείται, ότι το κλασικό μοντέλο Υπηρεσιών Διαδικτύου έχει υπερκεράσει όλα τα υπόλοιπα και μάλιστα με το πλησιέστερο του, να απαιτεί διπλάσιο χρόνο. Η τάση αυτή, συνεχίζεται καθώς τα αποτελέσματα που επιστρέφει η Υπηρεσία Διαδικτύου μικραίνουν. Για του λόγου το αληθές, παρατίθενται τα διαγράμματα για τις περιπτώσεις των 10ΚΒ και 1ΚΒ. AVERAGE ITSP 1800, , , , ,00 AVERAGE 800,00 600,00 400,00 200,00 0,00 1 SA 2 NO_SA 3 WSBM 4 5 CL+SA CL+NO_SA 6 HYBRID 7 HYBRID+CLE Σχήμα 50. Μέσο ITSP υπηρεσίας 10ΚΒ 91

102 AVERAGE ITSP 6000, , , ,00 AVERAGE 2000, ,00 0,00 1 SA 2 NO_SA 3 WSBM 4 5 CL+SA CL+NO_SA 6 HYBRID 7 HYBRID+CLE Σχήμα 51. Μέσο ITSP υπηρεσίας 1ΚΒ Συνολικά, το κλασικό μοντέλο παρουσιάζει μικρότερους χρόνους δοσοληψίας (average ITSP) όταν τα επιστρεφόμενα αποτελέσματα είναι μικρότερα των 300ΚΒ, ενώ η προσέγγιση με κινητούς πράκτορες, με ή χωρίς στάσιμους, και το υβριδικό μοντέλο, αποδεικνύονται αποδοτικότερα για αποτελέσματα μεγαλύτερα των 500ΚΒ. Επίσης, ο μέσος χρόνος ITSP είναι σχετικά μεγάλος όταν η πολιτική κλώνων είναι ενεργοποιημένη. Γεγονός που εξηγείται από το ότι χρησιμοποιήθηκαν μόνο έξι Παροχείς Υπηρεσιών Διαδικτύου. Με την παρουσία κλώνων στο δίκτυο, εμφανίζεται μεγάλη απορρόφηση πόρων στους υπολογιστές που παρέχουν τις Υπηρεσίες Διαδικτύου, με αποτέλεσμα την γενική μείωση της αποκρίσεις των Υπηρεσιών που προσφέρουν. Όλα τα παραπάνω απεικονίζονται συγκεντρωτικά στο επόμενο διάγραμμα, όπου παρουσιάζεται ο μέσος χρόνος ITSP, συναρτήσει του μεγέθους του επιστρεφόμενου αποτελέσματος, για κάθε μια από τις προαναφερθείσες προσεγγίσεις. 92

103 Average ITSP (msec) WITH PSA NO PSA WSBM 8000 HYBRID WITH PSA+CL NO PSA+CL 6000 HYBRID+CL KB 10 KB 100 KB 1 MB Service result volume Σχήμα 52. Μέσο ITSP υπηρεσιών Για την αξιολόγηση του συνολικού χρόνου από την στιγμή που ο κινητός πράκτορας μεταναστεύει από την Εφαρμογή Διαδικτύου, με προορισμό τον Κατάλογο Υπηρεσιών, έως και την παραλαβή των αποτελεσμάτων της κληθείσας υπηρεσίας από τον χρήστη, παρατίθεται το ακόλουθο διάγραμμα, που απεικονίζει τον συνολικό αυτό χρόνο συναρτήσει του μεγέθους του αποτελέσματος, για κάθε πιθανή πολιτική του κινητού πράκτορα και για το κλασικό μοντέλο των Υπηρεσιών Διαδικτύου. 93

104 45 40 Total Service Time (TST) in secs WITH PSA NO PSA WSBM HYBRID WITH PSA+CL NO PSA+CL HYBRID+CL KB 10 KB 100 KB 1 MB Service result volume Σχήμα 53. Συνολικός χρόνος TST Είναι φανερό, ότι για Υπηρεσίες Διαδικτύου με επιστρεφόμενο αποτέλεσμα 1ΜΒ, η αποδοτικότερη προσέγγιση είναι όταν σταλούν κλώνοι σε κάθε Παροχέα, για την παράλληλη κλήση τους και ταυτόχρονα να γίνεται χρήση του στάσιμου πράκτορα του Παροχέα. Αντίθετα, το κλασικό μοντέλο Υπηρεσιών υπερισχύει στις περιπτώσεις που το αποτέλεσμα είναι σχετικά μικρό, έως 100ΚΒ. Τα αποτελέσματα αυτά ήταν αναμενόμενα, αφού όταν το μέγεθος των δεδομένων είναι μεγάλο, είναι πιο αποδοτικό από πλευράς συνολικού χρόνου, να μεταφερθεί η λογική στα δεδομένα και όχι τα δεδομένα στην λογική. 7.3Αξιολόγηση ανάλωσης πόρων Προκειμένου να επιτευχθεί η αξιολόγηση των απαιτούμενων πόρων μνήμης, χρησιμοποιήθηκαν δύο εργαλεία ανάλογα με το σύστημα που αξιολογούταν. Τα συστήματα προς αξιολόγηση ήταν τα εξής: Ένα σύστημα εξ ολοκλήρου βασισμένο στο κλασικό μοντέλο εξυπηρέτη εξυπηρετούμενου στο οποίο όλες οι κλήσεις προς τις υπηρεσίες γίνονται μέσω ανταλλαγής SOAP μηνυμάτων. Ένα σύστημα βασισμένο στην προτεινόμενη αρχιτεκτονική που υλοποιήθηκε, κατά το οποίο οι παροχείς των υπηρεσιών αντιπροσωπεύονται από στάσιμους πράκτορες και μέσω αυτών γίνεται η κλήση προς τις υπηρεσίες διαδικτύου. Η τοπολογία του δικτύου που χρησιμοποιήθηκε είναι ακριβώς όπως παρουσιάστηκε στην προηγούμενη ενότητα. 94

105 Όσον αφορά στο παραδοσιακό μοντέλο των υπηρεσιών διαδικτύου, αυτό αξιολογήθηκε με τη βοήθεια του JProfiler. Η εφαρμογή μας παρείχε πληροφορίες σχετικά με την κατάσταση της μνήμης, δηλαδή πόσα στιγμιότυπα και ποιων αντικειμένων υπήρχαν, όπως επίσης για το μέγεθος που καταλάμβαναν. Το παρακάτω διάγραμμα παρουσιάζει τη συμπεριφορά του συστήματος για υπηρεσίες που επιστρέφουν δεδομένα έως και 6ΜΒ. INSTANCES 18000, , , , ,00 INSTANCES 8000, , , ,00 0, KB 10KB 100KB 1MB 5 6 3MB 6MB Σχήμα 54. Πλήθος αντικειμένων στη μνήμη σε σύστημα SOAP/RPC Όπως φαίνεται από το σχήμα, όσο το μέγεθος των δεδομένων αυξάνει, τόσο αυξάνει και το πλήθος των αντικειμένων στη μνήμη που απαιτούνται ώστε να κληθεί η υπηρεσία και να επιστραφούν τα αποτελέσματα. Το παρακάτω σχήμα απεικονίζει το μέγεθος μνήμης που καταλαμβάνουν αυτά τα αντικείμενα για τις παραπάνω υπηρεσίες. SIZE , , , ,00 SIZE , , ,00 0,00 1 1KB 2 10KB 3 100KB MB 3MB 6MB Σχήμα 55. Απαιτούμενη μνήμη για κλήση υπηρεσίας σε σύστημα SOAP/RPC Το μέγεθος μετράται σε bytes και όπως φαίνεται στο σχήμα, το διάγραμμα του μεγέθους μνήμης είναι σχεδόν πανομοιότυπο με το 95

106 προηγούμενο διάγραμμα μετατοπισμένο σε διαφορετικές τιμές του άξονα Y. Το γεγονός αυτό παραπέμπει στον ισχυρισμό πως το μέγεθος της απαιτούμενης μνήμης είναι ανάλογο με το πλήθος των αντικειμένων που δημιουργούνται. Στην περίπτωση του δεύτερου συστήματος με τους πράκτορες, για την αξιολόγηση χρησιμοποιήθηκε το Optimizeit της Borland. Το παρακάτω σχήμα απεικονίζει τη συμπεριφορά του συστήματος για μεγέθη υπηρεσιών έως και 6ΜΒ. INSTANCES 70000, , , ,00 INSTANCES 30000, , ,00 0, KB 10KB 3 100KB 4 1MB 5 6 3MB 6MB Σχήμα 56. Πλήθος αντικειμένων στη μνήμη για σύστημα με πράκτορες Όπως φαίνεται από το παραπάνω σχήμα, όσο αυξάνει το μέγεθος της υπηρεσίας, αυξάνουν και τα στιγμιότυπα των κλάσεων που χρησιμοποιούνται στη μνήμη. Παρατηρούμε ότι το διάγραμμα δεν ακολουθεί κάποια συγκεκριμένη μορφή, αλλά είναι προφανές πως η τάση είναι να αυξάνονται οι απαιτήσεις όσο αυξάνονται τα δεδομένα. Συγκρίνοντας τα δύο συστήματα προκύπτει το διάγραμμα που ακολουθεί. 96

107 OBJ ECT INSTANCES COMPARIZON 70000, , , ,00 AGENT INSTANCES 30000,00 WSBM INSTANCES 20000, ,00 0,00 1 1KB 2 10KB 3 100KB 4 1MB 5 6 3MB 6MB Σχήμα 57. Σύγκριση των δύο συστημάτων Στο σχήμα που προηγείται παρουσιάζονται τα πλήθη των αντικειμένων που δημιουργούνται στη μνήμη όταν γίνεται κλήση κάποιας υπηρεσίες και για τα δύο συστήματα. Όπως είναι προφανές, το σύστημα που δεν περιέχει πράκτορες και βασίζεται στην ανταλλαγή μηνυμάτων SOAP με RPC, υπερέχει σε σχέση με το άλλο σύστημα ιδίως στις περιπτώσεις των υπηρεσιών που επιστρέφουν μεγάλο όγκο δεδομένων. Επιπρόσθετα, φαίνεται να ακολουθεί μια σχετικά γραμμική ανοδική πορεία καθώς τα μεγέθη αυξάνονται. Το σύστημα με τους πράκτορες, από την άλλη μεριά, απαιτεί περισσότερους πόρους σε μνήμη, κάτι που ήταν αναμενόμενο, αφού οι πλατφόρμες των πρακτόρων είναι μια επιπρόσθετη επιβάρυνση στον παροχέα. Παραταύτα, για υπηρεσίες όπου τα δεδομένα δεν ξεπερνούν τα 10ΚΒ, φαίνεται να αποδίδει καλύτερα από το κλασικό επιχειρησιακό μοντέλο των Υπηρεσιών Ιστού. 97

108 8Κεφάλαιο: Συμπεράσματα Μελλοντικές Εργασίες Στο στάδιο της μελέτης και ανάπτυξης όλης της πλατφόρμας εμφανίστηκαν αρκετά προβλήματα, τα οποία και αντιμετωπίστηκαν ξεχωριστά. Η μελέτη και υιοθέτηση λύσεων που βασίστηκαν σε νέες τεχνολογίες (εταιριών όπως η Sun Microsystems, η IBM,η Microsoft, η Apache κτλ), αποτέλεσε σημαντικό παράγοντα επιτυχίας του όλου εγχειρήματος. Αυτό διότι οι προαναφερθείσες τεχνολογίες βασίζονται σε ανοιχτά πρωτόκολλα (όπως το SOAP, η XML, το HTTP κτλ), τα οποία προσέδωσαν σημαντικά πλεονεκτήματα στην ανάπτυξη της πλατφόρμας. Το πλαίσιο εργασίας το οποίο παρουσιάστηκε, δίνει λύσεις στα προβλήματα τα οποία παρουσιάζονται κυρίως σε ασύρματα περιβάλλοντα και συστήματα με περιορισμούς σε πόρους και με επισφαλείς συνδέσεις. Συγκεκριμένα, τα πλεονεκτήματα της δικιάς μας προσέγγισης είναι από την πλευρά των χρηστών τα ακόλουθα: Ο χρήστης μπορεί να καλέσει ένα σύνολο από υπηρεσίες με μόνο μία δοσοληψία με το εκάστοτε δίκτυο (αποστολή του αιτήματος και παραλαβή του αποτελέσματος). Ο χρήστης δεν είναι απαραίτητο να είναι συνδεδεμένος κατά την διάρκεια της ανακάλυψης και της επίκλησης της υπηρεσίας και τα αποτελέσματα είναι διαθέσιμα στην ασύρματη συσκευή του μόλις συνδεθεί στο δίκτυο. Επομένως ο χρήστης έχει τη δυνατότητα να μετακινείται, αρκεί να διαθέτει μια συσκευή με κάποιον περιηγητή (browser), ώστε να μπορεί να συνδεθεί οποτεδήποτε στο σύστημα. Από την μεριά του διαχειριστή του δικτύου έχουμε τα ακόλουθα πλεονεκτήματα: Οι κλήσεις των υπηρεσιών εκτελούνται τοπικά ή σύμφωνα με τις καθορισμένες πολιτικές του χρήστη και τα μη απαραίτητα δεδομένα δεν μεταδίδονται διαμέσου του δικτύου, το οποίο τελικά οδηγεί σε μία καλύτερα καθορισμένη χρήση του. Καλύτερη χρήση του εύρους μετάδοσης και λήψης στο ασύρματο τμήμα, το οποίο οδηγεί σε χαμηλότερα κόστη. Το πλαίσιο εργασίας εξασφαλίζει την παράδοση των αποτελεσμάτων της εκτέλεσης της υπηρεσίας στο χρήστη (από τη στιγμή που επαναμεταδίδει κάθε διακοπτόμενο αποτέλεσμα της υπηρεσίας), χωρίς να απαιτείται από το υπόλοιπο σύστημα (παρόχους της υπηρεσίας, υπηρεσία καταλόγου, κτλ) να αντιμετωπίζει σφάλματα στα ασύρματα κανάλια. 98

109 Η δυναμική συμπεριφορά του πράκτορα δίνει στο σύστημα ανεκτικότητα σε σφάλματα Νέες υπηρεσίες, πράκτορες και χρήστες μπορούν να προστεθούν στο πλαίσιο εργασίας χωρίς καμία αλλαγή, παρέχοντας ένα σταθερό και επεκτάσιμο σύστημα. Όσον αφορά στις επιδόσεις του δικτύου, αυτές μετρήθηκαν βάσει των ακόλουθων συστημάτων: Σύστημα με στάσιμους πράκτορες στους παρόχους των υπηρεσιών και στην υπηρεσία καταλόγου. Σύστημα χωρίς στάσιμους πράκτορες. Υβριδικό σύστημα με στάσιμους δηλαδή πράκτορες στους μισούς παροχείς υπηρεσιών. Σύστημα βασισμένο στο παραδοσιακό μοντέλο εξυπηρέτη εξυπηρετούμενου. Τα συμπεράσματα των μετρήσεων έδειξαν πως για μεγάλο όγκο ανακτόμενων δεδομένων μετά την κλήση της υπηρεσίας, το παραδοσιακό μοντέλο εξυπηρέτη εξυπηρετούμενου είναι λιγότερο αποδοτικό από την πλατφόρμα που υλοποιήθηκε, καθώς η τελευταία υποστηρίζει παραλλαγές και πολιτικές που με κατάλληλο συνδυασμό είναι δυνατό να επιτευχθεί ένα σύστημα που να αντεπεξέρχεται με επιτυχία στις απαιτήσεις του χρήστη και να κάνει καλύτερη χρήση του δικτύου. Τέλος, όσον αφορά στην αξιολόγηση των πόρων, αυτή έγινε για υπηρεσίες που επέστρεφαν έως και 6ΜΒ δεδομένων. Οι απαιτήσεις σε μνήμη για την πλατφόρμα μας ήταν περισσότερες εν συγκρίσει με το υπάρχον μοντέλο, αφού οι πλατφόρμες των κινητών πρακτόρων απαιτούσαν περισσότερους πόρους. Μελλοντικές εργασίες συμπεριλαμβάνουν την μελέτη της κινητικότητας της δομής του πράκτορα. Συγκεκριμένα, έχουμε ήδη αναπτύξει την δομή των κινητών πρακτόρων για περιπτώσεις στις οποίες δυναμικά γεγονότα δημιουργούνται κατά την διάρκεια της αποδήμησης του, τα οποία θα αναγκάσουν το κινητό πράκτορα να επεναπρογραμματίσει την περιήγησή του στο δίκτυο για να αντεπεξέλθει σε αυτά τα γεγονότα. Σε αυτή τη φάση, σχεδιάζουμε να ολοκληρώσουμε το πλαίσιο εργασίας μας με SNMP πράκτορες για την αναφορά των γεγονότων που καταγράφονται στο δίκτυο και την ανάπτυξη των συγκεκριμένων δομών για αυτούς τους πράκτορες. 99

110 A. Οδηγίες εγκατάστασης και εκτέλεσης Α.1 Οδηγίες εγκατάστασης Η παρούσα εφαρμογή έχει σχεδιαστεί έτσι ώστε να εκτελείται σε ένα σύνολο από υπολογιστές του δικτύου, αν και δύναται να λειτουργήσει και τοπικά. Υποθέτοντας, λοιπόν, ότι διαθέτουμε το ελάχιστο δυνατό σύνολο υπολογιστών, τότε ο πρώτος θα εκτελεί τη διαδικτυακή εφαρμογή ClientSystem, ο δεύτερος θα παρέχει την υπηρεσία καταλόγου (Semantic Web Services Registry) και ο τρίτος θα παρέχει την υπηρεσία (Service Provider). Είναι απαραίτητο η πλατφόρμα των κινητών πρακτόρων (Grasshopper) να εκτελείται σε όλους τους υπολογιστές, ώστε να είναι δυνατή η μετακίνηση των πρακτόρων στο δίκτυο. Ξεκινώντας από τον υπολογιστή που θα εκτελεί τη διαδικτυακή εφαρμογή ClientSystem, χρειαζόμαστε τα εξής: Apache Tomcat: Βρίσκεται στον κατάλογο Apache Tools του συνοδευτικού οπτικού δίσκου (CD). Η εγκατάστασή του προϋποθέτει ότι υπάρχει η Java εγκατεστημένη στο σύστημα. Μετά την εγκατάσταση αντικαθιστούμε το αρχείο server.xml που βρίσκεται στον κατάλογο conf του Tomcat με αυτό που βρίσκεται στον κατάλογο Apache Tomcat του καταλόγου Tools του CD. ClientSystem: Η εφαρμογή βρίσκεται στον κατάλογο Software του CD. Ως εφαρμογή του tomcat, για να εκτελεστεί σωστά, την αντιγράφουμε στον κατάλογο webapps του Tomcat. Η εφαρμογή χρησιμοποιεί ως βάση δεδομένων την HSQLDB, για την οποία δεν είναι αναγκαίο να γίνει κάποια ρύθμιση ή κάποια εγκατάσταση, αφού εμπεριέχεται στην εφαρμογή. Grasshopper: Η πλατφόρμα των κινητών πρακτόρων βρίσκεται επίσης στον κατάλογο Software και την αντιγράφουμε στον κατάλογο C:\java\ του τοπικού δίσκου του υπολογιστή. WebServicesMobileAgentsIntegration: Όλο το project της εργασίας βρίσκεται στον κατάλογο Software του CD και το αντιγράφουμε στον κατάλογο C:\ του δίσκου του υπολογιστή. Ο υπολογιστής ο οποίος θα παρέχει την υπηρεσία καταλόγου χρειάζεται τα εξής: Apache Tomcat: Ακολουθούνται οι ίδιες ενέργειες με παραπάνω. Βιβλιοθήκες Tomcat: Βρίσκονται στον κατάλογο Apache Tomcat\Common Libs του καταλόγου Tools του CD. Είναι απαραίτητες βιβλιοθήκες για την ομαλή λειτουργία και συνεργασία όλων των εφαρμογών. Αντιγράφουμε όλα τα.jar 100

111 αρχεία του καταλόγου στον κατάλογο common\lib του Tomcat. MySQL: Βρίσκεται στον κατάλογο Tools του CD. JUDDI: Βρίσκεται στον κατάλογο Tools του CD και προϋποθέτει ότι έχει ήδη εγκατασταθεί ο Tomcat και η MySQL. Για την εγκατάσταση αντιγράφουμε τον κατάλογο JUDDI στον κατάλογο webapps του Tomcat. Στον κατάλογο WEB-INF\classes του JUDDI υπάρχει, μεταξύ των άλλων, και το αρχείο juddi.proprties. Ενημερώνουμε κατάλληλα την τελευταία γραμμή του αρχείου με το σωστό μονοπάτι στο δίσκο όπου υπάρχει το αρχείο juddi.users. Το αρχείο αυτό είναι επίσης στον κατάλογο WEB-INF\classes του juddi. Στη συνέχεια δημιουργούμε τη βάση δεδομένων ως εξής: o Ξεκινάμε τον deamon της MySQL. Αρκεί να εκτελέσουμε το αρχείο mysqld.exe που βρίσκεται στον κατάλογο bin του καταλόγου εγκατάστασης της MySQL. Εν συνεχεία από τη γραμμή εντολών ξεκινάμε την sql με δικαιώματα root πληκτρολογώντας: mysql u root. Από τη διεπαφή πλέον της sql εκτελούμε το script αρχείο mysql.ddl το οποίο θα δημιουργήσει τη βάση. Το αρχείο αυτό βρίσκεται στον κατάλογο juddi και για την εκτέλεση πληκτρολογούμε source <τοποθεσία_αρχείου/mysql.ddl>. Επομένως, αν έχουμε εγκαταστήσει τον Tomcat στον κατάλογο C:\Tomcat, τότε αυτό που θα γράφαμε θα ήταν: source c:\tomcat\webapps\juddi\mysql.ddl Matchmaker tool: Δε χρειάζεται κάποια επιπρόσθετη ρύθμιση, αφού είναι όλα καθορισμένα εξ αρχής στον κατάλογο juddi στον οποίο περιέχεται. Racer: Βρίσκεται στον κατάλογο Tools του CD και δεν απαιτείται κάποια ρύθμιση. Τον αντιγράφουμε σε οποιοδήποτε σημείο του τοπικού δίσκου του υπολογιστή. WebServicesMobileAgentsIntegration: Ακολουθείται η ίδια διαδικασία με παραπάνω. Grasshopper Agent Platform: Ακολουθείται η ίδια διαδικασία με παραπάνω. Ο υπολογιστής, ο οποίος θα παρέχει την υπηρεσία διαδικτύου (Web Service) χρειάζεται τα εξής: Apache Tomcat: Ακολουθείται η ίδια διαδικασία με παραπάνω. Apache Axis: Βρίσκεται στον κατάλογο Tools του CD. Αντιγράφουμε τον κατάλογο axis στον κατάλογο webapps του Tomcat. Στον κατάλογο axis υπάρχουν όλες οι απαραίτητες βιβλιοθήκες, η υπηρεσία διαδικτύου, η περιγραφή της σε WSDL και σε OWL και δεν απαιτείται επομένως καμία επιπρόσθετη ρύθμιση. WebServicesMobileAgentsIntegration: Ακολουθείται η ίδια διαδικασία με παραπάνω. 101

112 Grasshopper Agent Platform: Ακολουθείται η ίδια διαδικασία με παραπάνω. Α.2 Οδηγίες εκτέλεσης Προκειμένου να εκτελεστεί σωστά η όλη εφαρμογή, απαιτείται να έχει ξεκινήσει μια Region Registry της πλατφόρμας των κινητών πρακτόρων στην οποία θα είναι καταχωρημένες όλες οι υπόλοιπες agencies που λαμβάνουν μέρος. Επίσης, στην περίπτωση όπου οι παροχείς αντιπροσωπεύονται από στάσιμους πράκτορες, θα πρέπει προτού δημοσιευθούν οι υπηρεσίες στη Service Registry, να ενημερωθούν στην περιγραφή της υπηρεσίας (αρχείο.owl) οι θύρες (ports) μέσω των οποίων θα γίνεται η επικοινωνία με το στάσιμο πράκτορα. Επομένως, ξεκινώντας με τη σειρά, θα δούμε σε κάθε μηχάνημα τις ενέργειες που πρέπει να γίνουν. Υπολογιστής που παρέχει την εφαρμογή ClientSystem: Αρχείο system.properties: Το αρχείο αυτό βρίσκεται στον κατάλογο ClientSystem των webapps του Tomcat και ο ρόλος του είναι να ενισχύει την επεκτασιμότητα της εφαρμογής. Στο αρχείο αυτό ορίζονται οι IP διευθύνσεις της RegionRegistry του ClientSystem (HomeAgency) και της υπηρεσίας καταλόγου (RegistryAgency). Επομένως προτού εκκινήσουμε τον Tomcat ενημερώνουμε τον αρχείο κατάλληλα. Τις IP διευθύνσεις των μηχανημάτων μπορούμε να τις ανακτήσουμε πληκτρολογώντας την εντολή ipconfig από τη γραμμή εντολών. Εκκίνηση του Tomcat: Από τον πίνακα ελέγχου του υπολογιστή επιλέγουμε τις ενέργειες διαχειριστή (administrative tools) και επιλέγουμε τις υπηρεσίες (services) ώστε να διαχειριστούμε τις διεργασίες του μηχανήματος. Στην υπηρεσία Apache Tomcat επιλέγουμε εκκίνηση (start). CLASSPATH: Προκειμένου να είναι δυνατός ο αυτόματος εντοπισμός των βιβλιοθηκών που χρησιμοποιούνται πρέπει να θέσουμε τη μεταβλητή περιβάλλοντος CLASSPATH. Η μεταβλητή αρχικοποιείται και τίθεται αυτόματα μέσω του batch αρχείου setclasspath.bat που βρίσκεται στον κατάλογο C:\WebServicesMobileAgentsIntegration\setClasspath.bat. Επομένως, από τη γραμμή εντολών πληκτρολογούμε c:\webservicesmobileagents\integration\setclasspath. Εκκίνηση της πλατφόρμας πρακτόρων: Στο σημείο αυτό πρέπει να ξεκινήσουμε μια RegionRegistry στην οποία θα είναι καταχωρημένες όλες οι υπόλοιπες agencies. Επομένως ακολουθούμε την εξής διαδικασία: o Εκτελούμε από τη γραμμή εντολών το batch αρχείο starthomeregistry.bat, το οποίο βρίσκεται στον κατάλογο C:\WebServicesMobileAgentsIntegration, 102

113 πληκτρολογώντας c:\webservicesmobileagentsintegration\starthomeregistry. o Στη συνέχεια ξεκινάμε την home agency από την οποία θα ξεκινήσει την εκτέλεσή του ο κινητός πράκτορας μετά τη δημιουργία του. Για να γίνει αυτό, πληκτρολογούμε από τη γραμμή εντολών: c:\webservicesmobileagentsintegration\starthomeagency <IPaddress>, όπου <IPaddress> είναι η διέθυνση του μηχανήματος στο οποίο εκτελείται η RegionRegistry, δηλαδή στην προκειμένη περίπτωση είναι η διεύθυνση του τρέχοντος υπολογιστή, την οποία έχουμε ανακτήσει μέσω της εντολής ipconfig. Όταν ξεκινήσει η home agency, μέσω της διεπαφής της, πληκτρολογώντας gui μπορούμε να τη διαχειριστούμε από τη γραφική διεπαφή που παρέχει. ClientSystem: Η διαδικτυακή εφαρμογή πλέον μπορεί να ξεκινήσει πληκτρολογώντας μέσω κάποιου περιηγητή (browser): Υπολογιστής που παρέχει την υπηρεσία καταλόγου (Service Registry): Εκκίνηση της MySQL: Προκειμένου να ξεκινήσει ο SQL server, πρέπει να εκτελέσουμε το deamon της MySQL. Αυτό γίνεται εκτελώντας το αρχείο mysql.exe, που βρίσκεται στον κατάλογο bin του καταλόγου εγκατάστασης της sql. Εκκίνηση του Racer: Το εργαλείο αυτό απαιτείται από το matchmaker προκειμένου να γίνει συντακτικός και ορθολογικός έλεγχος των οντολογιών που χρησιμοποιούνται. Επομένως κατά τη διαδικασία της δημοσιοποίησης των υπηρεσιών, ο υπολογιστής αυτός απαιτείται να είναι συνδεδεμένος στο διαδίκτυο. Η εκκίνηση του racer γίνεται εκτελώντας το αρχείο racer.exe από τη γραμμή εντολών ως εξής: racer t 8088 http Αυτό ορίζει ότι η θύρα για TCP/IP αιτήσεις θα είναι η 8088, ενώ η θύρα για http αιτήσεις θα είναι η 8089, ώστε να μην υπάρχει πρόβλημα με τη θύρα 8080, στην οποία δέχεται http αιτήσεις ο Tomcat. Εκκίνηση του Tomcat: Ο Tomcat πρέπει να ξεκινήσει αφού πρώτα έχει ξεκινήσει ο racer. Η διαδικασία για την εκκίνηση του Tomcat είναι όμοια με παραπάνω. Δημοσίευση των υπηρεσιών στην υπηρεσία καταλόγου: Πλέον μπορούμε να δημοσιεύσουμε τις «διαφημίσεις» των υπηρεσιών στην υπηρεσία καταλόγου, εκτελώντας την κλάση Publish2Matchmaker η οποία βρίσκεται στο package di.uoa.gr.registry του project WebServicesMobileAgentsIntegration. Αρκεί να τροποποιήσουμε τις μεθόδους register() που παρέχει η κλάση ενημερώνοντάς τις με τις σωστές IP διευθύνσεις των παρόχων των υπηρεσιών. Αυτό προϋποθέτει ότι οι πάροχοι είναι ήδη συνδεδεμένοι στο δίκτυο και λειτουργούν κανονικά. 103

114 Εκκίνηση της πλατφόρμας των κινητών πρακτόρων: Από τη γραμμή εντολών εκτελούμε c:\webservicesmobileagentsintegration\startregistryagency <IPaddress>, όπου <IPaddress> είναι η διεύθυνση του μηχανήματος στο οποίο εκτελείται η RegionRegistry και στην οποία θα καταχωρηθεί η πλατφόρμα που μόλις εκκινούμε. Δηλαδή η IPaddress είναι αυτή του μηχανήματος που εκτελεί και την εφαρμογή ClientSystem. Μετά την εκκίνηση, πληκτρολογώντας gui μπορούμε να ξεκινήσουμε και τη γραφική διεπαφή της πλατφόρμας. Ο στατικός πράκτορας που δημιουργείται αυτόματα περιμένει για αλληλεπιδράσεις με τον κινητό πράκτορα και την υπηρεσία καταλόγου που αντιπροσωπεύει. Υπολογιστής που παρέχει την υπηρεσία (Service Provider): Εκκίνηση του Tomcat: Η διαδικασία είναι όμοια με παραπάνω. Στην περίπτωση αυτή ο παροχέας πρέπει να εκτελεί τον Tomcat, ώστε μέσω αυτού να εκτελείται ο Axis που είναι αναγκαίος για την κλήση της υπηρεσίας που προσφέρεται. Εκκίνηση της πλατφόρμας: Από τη γραμμή εντολών εκτελούμε c:\webservicesmobileagentsintegration\startprovideragency <IPaddress>, όπου <IPaddress> είναι και πάλι η διεύθυνση του υπολογιστή στον οποίο εκτελείται η RegionRegistry. Με την εντολή gui ξεκινάμε τη γραφική διεπαφή της πλατφόρμας. Ο στάσιμος πράκτορας που ξεκινάει αυτόματα περιμένει για αλληλεπιδράσεις μεταξύ του κινητού πράκτορα και της υπηρεσίας που παρέχεται. Περίπτωση τοπικής εκτέλεσης σε έναν υπολογιστή: Στην περίπτωση αυτή η διαδικασία που ακολουθήθηκε ως εδώ δεν αλλάζει, απλώς είναι δυνατό να ξεκινήσουν όλες οι πλατφόρμες των κινητών πρακτόρων αυτόματα και με τη σωστή σειρά εκτελώντας το batch αρχείο startall.bat, το οποίο βρίσκεται επίσης στον κατάλογο WebServicesMobileAgentsIntegration. Δηλαδή, από τη γραμμή εντολών πληκτρολογούμε: c:\webservicesmobileagentsintegration\startall.+ B. Εργαλεία που χρησιμοποιήθηκαν 104

115 B.1 Γλώσσα Προγραμματισμού Java Για την υλοποίηση της όλης αρχιτεκτονικής ήταν απαραίτητο να επιλεγεί μια γλώσσα προγραμματισμού, η οποία θα ήταν ευρέως διαδεδομένη, και κυρίως στον παγκόσμιο ιστό, θα μπορούσε να συνεργαστεί με την πλατφόρμα των κινητών πρακτόρων και επίσης με το σύνολο των υπολοίπων τεχνολογιών που χρησιμοποιήθηκαν. Λαμβάνοντας υπόψη ότι η πλατφόρμα υποστήριξης των κινητών πρακτόρων είναι γραμμένη εξολοκλήρου σε Java, ήταν αναμενόμενο η γλώσσα που θα επιλεγόταν να ήταν αυτή. Επιπρόσθετα, τα πλεονεκτήματα που προσφέρει σε τέτοιου είδους διαδικτυακές εφαρμογές την καθιστούν μάλλον απαραίτητη επιλογή για το σκοπό αυτό. Καταρχάς είναι μια γλώσσα ανεξάρτητη της πλατφόρμας και του λειτουργικού συστήματος του κάθε συνδεδεμένου μηχανήματος. Επίσης, τα εργαλεία που σχετίζονται με τις τεχνολογίες των υπηρεσιών διαδικτύου και των κινητών πρακτόρων προσφέρουν εύχρηστες διεπαφές σε Java προς τον προγραμματιστή, ώστε να κάνουν τη συνεργασία τους με τη Java αρκετά εύχρηστη και αποδοτική. Τέλος, η Java παρέχει ασφάλεια πάνω σε διαδικτυακές εφαρμογές και μέρος της ασφάλειας της πλατφόρμας των κινητών πρακτόρων βασίζεται στη Java. B.2 Eclipse IDE Για την ανάπτυξη του κώδικα χρησιμοποιήθηκε το Eclipse, συγκεκριμένα η έκδοση Η πλατφόρμα αυτή από μόνη της δε έχει καμία δυνατότητα. Με την εγκατάσταση όμως διαφόρων προσθηκών ειδικά κατασκευασμένων για την εν λόγω πλατφόρμα, οι δυνατότητές της είναι άπειρες. Το Eclipse επιλέχθηκε για δύο κύριους λόγους: Πρώτον για τη δυνατότητα που έχει να επεκτείνεται συνεχώς με την εγκατάσταση επιπρόσθετων στοιχείων (plugins) σε αυτό, και δεύτερον για την απλότητα και την ευχρηστία που προσφέρει στον προγραμματιστή. Σαν επιπρόσθετο στοιχείο χρησιμοποιήθηκε το Nitro-X, το οποίο προσφέρει τη δυνατότητα ανάπτυξης κώδικα που σχετίζεται με τον εξυπηρέτη (server side code). Το plugin αυτό χρησιμοποιήθηκε για την ανάπτυξη της διαδικτυακής εφαρμογής Client System, το οποίο αποτελείται από κώδικα γραμμένο σε JSP και servlets. Για το Nitro-X χρησιμοποιήθηκε η δωρεάν έκδοσή του η οποία προσφέρει τις βασικές λειτουργίες κειμενογράφου ειδικού για JSP και servlets, ενώ δεν παρέχει τη δυνατότητα απασφαλμάτωσης (debugging) του κώδικα. Η έκδοση επί πληρωμής προσφέρει όλη την παραπάνω λειτουργικότητα αλλά επιπλέον και υποστήριξη νέων τεχνολογιών όπως Java Server Faces. 105

116 B.3 Apache Tomcat Ο Tomcat είναι η μηχανή JSP/Servlet που απαιτείται για τέτοιου είδους διαδικτυακές εφαρμογές. Ο Tomcat έχει το ρόλο του εξυπηρέτη (server) και είναι υπεύθυνος για τις απαντήσεις των HTTP αιτήσεων του πελάτη. Το εργαλείο αυτό χρησιμοποιήθηκε τόσο για την εξυπηρέτηση της εφαρμογής Client System, όσο και για τη λειτουργικότητα των παροχέων των υπηρεσιών διαδικτύου, αφού μέσω αυτού γινόταν η κλήση της υπηρεσίας. Ο Tomcat έρχεται με άδεια ανοιχτού λογισμικού από την Apache Software. Στον πυρήνα του προγράμματος είναι η μηχανή servlet (που ονομάζεται CATALINA), η οποία δρα σαν το κορυφαίο πάνω επίπεδο container όλων των στιγμιότυπων (instances) του Tomcat. Στο σχήμα που ακολουθεί φαίνεται η αρχιτεκτονική του σε μορφή XML. Εικόνα 1. Αρχιτεκτονική του Tomcat Servlets & JSPs Τα servlets είναι κομμάτια κώδικα γραμμένα για τη μεριά του εξυπηρέτη (server). Γενικός σκοπός είναι η συνεργασία τους για την επεξεργασία και απάντηση σε μια αίτηση κάποιου πελάτη προς τον εξυπηρέτη. Ο Tomcat λέγεται και servlet container επειδή δουλειά του είναι να εκτελεί servlets (και JSPs) προς απάντηση σε μια αίτηση. Ο Tomcat «ακούει» για τέτοιες αιτήσεις στην πόρτα (port) 8080 του συστήματος. Τα κύρια χαρακτηριστικά των servlets είναι τα ακόλουθα: Φορητότητα (Portability) Αποτελεσματικότητα (Efficiency) Ανθεκτικότητα (Persistence) Ο κύκλος ζωής ενός servlet ξεκινά όταν ο container (στην εν λόγω περίπτωση είναι ο Tomcat), φορτώσει τον κώδικα του servlet στη μνήμη του συστήματος. Συνήθως αυτό γίνεται προς απάντηση της πρώτης αίτησης προς το συγκεκριμένο servlet. Προκειμένου να 106

117 ανταποκριθεί το servlet στην πρώτη του αίτηση, ο Tomcat καλεί πρώτα τη μέθοδο init() του servlet. Αφού η init() ολοκληρώσει τη λειτουργία της, τότε μπορεί να απαντήσει το servlet στην αίτηση που του δόθηκε. Όλες οι αιτήσεις διαχειρίζονται από τη μέθοδο service του servlet, η οποία μπορεί να κληθεί πολλές φορές στη διάρκεια του κύκλου ζωής του servlet. Τέλος, όταν ο Tomcat τερματίσει το servlet, τότε καλείται και η μέθοδος destroy (του servlet), ώστε να απελευθερωθούν οι πόροι που είχαν δεσμευτεί. Τα JSP, από την άλλη μεριά, είναι κάτι σαν το ανάποδο από τα servlets. Ουσιαστικά είναι κώδικας HTML, στον οποίο εμπεριέχεται και κώδικας Java. Τα JSP και τα servlet συνεργάζονται αρμονικά προκειμένου να εξυπηρετηθεί μια αίτηση του πελάτη. Ένα JSP μπορεί να καλέσει ένα servlet, το οποίο με τη σειρά του να καλέσει ένα άλλο servlet το οποίο μπορεί να ανακατευθύνει το αποτέλεσμα της εργασίας του σε ένα νέο JSP. Δημιουργείται δηλαδή μια αλληλένδετη αλυσίδα μεταξύ JSP και servlet για την υλοποίηση μιας διαδικτυακής εφαρμογής στη μεριά του εξυπηρέτη. Εξάλλου η τεχνολογία των JSP ήρθε σαν επέκταση των servlets, επομένως ήταν αναμενόμενο πως η συνεργασία τους όχι μόνο θα ήταν εφικτή, αλλά και απαραίτητη για τον καλύτερο προγραμματισμό μια εφαρμογής τέτοιων σκοπών. Έτσι, τα JSP επιτρέπουν στους προγραμματιστές να επαναχρησιμοποιούν ήδη προκατασκευασμένα servlets για τη δημιουργία δυναμικού περιεχομένου σε ιστοσελίδες HTML και όχι μόνο. Επίσης, δίνουν τη δυνατότητα να κατασκευαστούν ειδικές βιβλιοθήκες (tag libraries) ώστε σχεδιαστές που μπορεί να μην έχουν γνώση προγραμματισμού Java να μπορούν να εμπλουτίζουν τις ιστοσελίδες τους με ισχυρό δυναμικό περιεχόμενο και ικανότητες επεξεργασίας δεδομένων. Γενικά η τεχνολογία τόσο των JSPs, όσο και των servlets έχει γίνει πια τόσο διάσημη και ευρέως χρησιμοποιούμενη που υποστηρίζεται από πληθώρα εξυπηρετητών, με γνωστότερο εκπρόσωπό τους τον Tomcat. Ο Tomcat σαν Server Όπως έχει γίνει προφανές, η λειτουργία του Tomcat είναι να βρίσκεται στο σύστημα του παροχέα κάποιας υπηρεσίας ή κάποιας δικτυακής εφαρμογής και να ανταποκρίνεται στις αιτήσεις των πελατών. Υπάρχουν δύο τρόποι ώστε το πρόγραμμα αυτό να λειτουργήσει σαν εξυπηρέτης (server): Μπορεί να λειτουργήσει σαν αυτόνομη εφαρμογή (standalone application) χωρίς τη βοήθεια κάποιου άλλου εξυπηρέτη. Στην περίπτωση αυτή, εξ ορισμού οι αιτήσεις μέσω HTTP πρωτοκόλλου θα εξυπηρετούνται από την πόρτα (port) 8080, στην οποία «ακούει» ο Tomcat. Μπορεί να εγκατασταθεί σαν επιπρόσθετο στοιχείο σε κάποιον ήδη υπάρχον εξυπηρέτη (web server), όπως για 107

118 παράδειγμα στον Apache. Στην περίπτωση αυτή, οι αιτήσεις θα διαχειρίζονται από τoν ήδη εγκατεστημένο web server και στην περίπτωση που κάποια αίτηση απευθύνεται στον Tomcat, τότε αυτή θα προωθείται από τον web server στον servlet & JSP container (Tomcat). Η περίπτωση αυτή είναι χρήσιμη σε περιπτώσεις όπου έχει ήδη εγκατασταθεί ένας server σε κάποια εταιρεία, η οποία θέλει να εμπλουτίσει τις δικτυακές τις εφαρμογές με κάποιες υλοποιημένες σε Java. Τότε μπορεί να εγκαταστήσει τον Tomcat σαν plugin ώστε οι αιτήσεις για τις νέες εφαρμογές να αναλαμβάνονται από αυτόν. Το παρακάτω σχήμα απεικονίζει την περίπτωση αυτή. Εικόνα 2. Ο Tomcat σαν plugin σε υπάρχον web server Προκειμένου να λειτουργήσει σωστά ο Tomcat θα πρέπει να είναι εγκατεστημένη η Java στο σύστημα. Τα servlets για να εκτελεστούν από τον container θα πρέπει να είναι ήδη μεταγλωττισμένα, ενώ τα JSP μεταγλωττίζονται κατά την εκτέλεσή τους από τον Tomcat. Επίσης, θα πρέπει να είναι ορισμένη η μεταβλητή περιβάλλοντος JAVA_HOME, της οποίας η τιμή θα είναι το μονοπάτι των καταλόγων που είναι εγκατεστημένη η Java. Τέλος, η δεύτερη μεταβλητή περιβάλλοντος που θα πρέπει να είναι ορισμένη είναι η CATALINA_HOME, της οποίας η τιμή θα είναι το μονοπάτι των καταλόγων που είναι εγκατεστημένος ο Tomcat. Το όνομα της μεταβλητής προέρχεται από τη μηχανή επεξεργασίας των servlets του Tomcat, που ονομάζεται Catalina. Η εκκίνηση του Tomcat γίνεται από τον κατάλογο CATALINA_HOME/bin με την εκτέλεση του startup αρχείου. Κατά αντιστοιχία, τερματισμός του γίνεται με την εκτέλεση του shutdown αρχείου από τον ίδιο κατάλογο. Οι σημαντικότεροι κατάλογοι του Tomcat, οι οποίοι είναι υποκατάλογοι του CATALINA_HOME είναι οι εξής: /bin Περιέχει όλα τα αρχεία εκκίνησης και τερματισμού του Tomcat τόσο για περιβάλλον windows, όσο και για περιβάλλοντα UNIX. /conf Περιέχει αρχεία σχετιζόμενα με τις ρυθμίσεις του Tomcat που απαιτούνται για τη σωστή διαμόρφωσή του. Το 108

119 σημαντικότερο αρχείο από αυτά είναι το server.xml, που είναι και το κυρίως αρχείο διαμόρφωσης του Tomcat. /log Ο κατάλογος αυτός περιέχει εξ ορισμού αρχεία που σχετίζονται με αναφορές του Tomcat (logs). Μέσω των αρχείων αυτών μπορούν να διαπιστωθούν και να λυθούν προβλήματα που σχετίζονται με την εσφαλμένη λειτουργία κάποιας δικτυακής εφαρμογής που εκτελείται από τον container. /webapps Είναι ο κατάλογος που περιέχει τις διαδικτυακές εφαρμογές που έχουν αναπτυχθεί. Στην ουσία, μια τέτοια διαδικτυακή εφαρμογή αποτελείται από αρχεία κώδικα Java, που πιθανόν θα ορίζουν κάποια servlets, αρχεία JSP, αρχεία HTML και XML. Ο Tomcat ορίζει μια συγκεκριμένη δομή που πρέπει βάσει αυτής να αποθηκεύονται τα αρχεία κάτω από τον κατάλογο webapps ώστε να λειτουργεί σωστά η εφαρμογή. Η δομή αυτή απεικονίζεται στο παρακάτω σχήμα. Εικόνα 3. Δομή καταλόγων της διαδικτυακής εφαρμογής Σημαντικό ρόλο για τη δικτυακή εφαρμογή παίζει το αρχείο web.xml στο οποίο ορίζονται όλες οι σημαντικές παράμετροι της εφαρμογής, καθώς και τα ονόματα των servlets που θα χρησιμοποιηθούν. Παράμετροι που μπορεί να ορίζονται στο αρχείο αυτό είναι για παράδειγμα το URL της βάσης δεδομένων που πιθανόν να χρησιμοποιείται, το συνθηματικό του διαχειριστή της βάσης, κλπ. Αυτοί οι παράμετροι διαβάζονται κατά την εκκίνηση του Tomcat από το SetupServlet της εφαρμογής, το οποίο καταστρέφεται όταν σταματήσει η λειτουργία του Tomcat. Ο κύκλος ζωής δηλαδή του συγκεκριμένου servlet είναι ίσος με τη συνολική δραστηριότητα του Tomcat. Τέλος, το αρχείο αυτό μπορεί να διαμορφώνει συνθήκες ασφάλειας και αυθεντικοποίησης, να περιέχει ρυθμίσεις για τον καθορισμό των συνόδων (session configuration) ή ακόμη να ορίζει ΜΙΜΕ τύπους. 109

120 B.4 Apache AXIS Σαν επιπρόσθετο στοιχείο στον Tomcat εγκαθίσταται ο Axis, ο οποίος είναι μια μηχανή μέσω της οποίας οι υπηρεσίες ιστού αναπτύσσονται και εκ των υστέρων καλούνται από τους διάφορους πελάτες. Πιο αναλυτικά μπορούμε να προσδιορίσουμε τον Axis ως μια μηχανή SOAP μηνυμάτων, η οποία προκειμένου να εξυπηρετήσει την λειτουργικότητά της εγκαθίσταται πάνω στον Tomcat. Ο Axis δεν είναι μόνο μια μηχανή SOAP μηνυμάτων, αλλά ένας ολόκληρος server, ο οποίος υποστηρίζει εκτενώς τη γλώσσα περιγραφής των υπηρεσιών διαδικτύου WSDL. Επιπλέον, περιλαμβάνει εργαλεία, τα οποία παράγουν κλάσεις Java από την περιγραφή της υπηρεσίας ιστού, δίνοντας έτσι στον προγραμματιστή ευχρηστία και σημαντική ώθηση στο χρόνο της ανάπτυξης της υπηρεσίας. Τέλος, περιλαμβάνει εργαλεία για την παρακολούθηση (monitoring) και καταγραφή των πακέτων TCP/IP, που ανταλλάσσονται στο δίκτυο. Εγκατάσταση Ο Axis ουσιαστικά είναι μια δικτυακή εφαρμογή του Tomcat. Επομένως η εγκατάστασή του είναι αρκετά απλή. Όπως έχει αναφερθεί στην προηγούμενη ενότητα, ο Tomcat περιέχει τον κατάλογο webapps, μέσα στον οποίο εμπεριέχονται οι δικτυακές εφαρμογές. Αρκεί, λοιπόν, η αντιγραφή του axis μέσα στον κατάλογο αυτό για την εγκατάστασή του. Επίσης, επιθυμητή είναι και η εγκατάσταση κάποιου κατατμητή (parser), ο οποίος συνήθως είναι ο Xerces, που παρέχεται δωρεάν από την Apache.org. Η εγκατάστασή του είναι απλή καθώς ουσιαστικά είναι μια βιβλιοθήκη που πρέπει να αντιγραφεί στον κατάλογο libs μαζί με τις υπόλοιπες βιβλιοθήκες της εφαρμογής. Μέσω του Tomcat και ενός περιηγητή, δίνοντας το URL: localhost:8080/axis, επικοινωνούμε με την εφαρμογή. Ακολουθώντας το σύνδεσμο validate μπορούμε να βεβαιωθούμε για τη σωστή εγκατάσταση και λειτουργία της εφαρμογής. Τα κύρια χαρακτηριστικά του Axis είναι τα εξής: Ταχύτητα (speed) Ευελιξία (flexibility) Σταθερότητα (stability) Εύκολη ανάπτυξη των υπηρεσιών Υποστήριξη της WSDL Παροχή επιπλέον προγραμμάτων προς προγραμματιστή όφελος του Αρχιτεκτονική του Axis 110

121 Ο Axis αποτελείται από αρκετά υποσυστήματα που συνεργάζονται αρμονικά μεταξύ τους. Τα βασικότερα σημεία για την κατανόηση του πυρήνα της μηχανής του Axis είναι: Οι χειριστές (handlers) και το μονοπάτι μηνύματος (message path): Όταν η κεντρική λογική επεξεργασίας του Axis λειτουργεί, τότε μια σειρά από handlers καλούνται στη σειρά. Η συγκεκριμένη σειρά που γίνεται αυτό καθορίζεται από δύο παράγοντες. Από τις ρυθμίσεις της ανάπτυξης και από το εάν η μηχανή είναι ένας πελάτης (client) ή εξυπηρέτης (server). Το αντικείμενο, το οποίο περνάει σε κάθε κλήση (invocation) του handler είναι ένα περιεχόμενο μηνύματος. Το περιεχόμενο μηνύματος είναι μια δομή η οποία περιέχει αρκετά σημαντικά μέρη: o Ένα μήνυμα αίτησης (request message) o Ένα μήνυμα απάντησης (response message) o Ένα σύνολο από ιδιότητες (bag of properties) Γενικά, υπάρχουν δύο τρόποι που ο Axis μπορεί να κληθεί: o Σαν εξυπηρέτης (server) Στην περίπτωση αυτή ένας ακροατής μεταφοράς (transport listener) θα καλέσει το πλαίσιο επεξεργασίας του Axis. o Σαν πελάτης (client) Στην περίπτωση αυτή, ο κώδικας της εφαρμογής θα παράγει ένα περιεχόμενο μηνύματος και θα καλέσει το πλαίσιο επεξεργασίας του Axis. Το μονοπάτι μηνύματος στον εξυπηρέτη: Το μονοπάτι του μηνύματος από την πλευρά του εξυπηρέτη απεικονίζεται στο ακόλουθο σχήμα. Εικόνα 4. Μονοπάτι μηνύματος στον εξυπηρέτη Οι μικροί κύλινδροι αντιπροσωπεύουν τους χειριστές και οι μεγαλύτεροι εσώκλειστοι κύλινδροι αντιπροσωπεύουν αλυσίδες (chains), οι οποίες είναι διατεταγμένες συλλογές από χειριστές. Ένα μήνυμα φτάνει στον ακροατή μεταφοράς με ένα τρόπο ο οποίος καθορίζεται από κάποιο πρωτόκολλο. Σε αυτή την περίπτωση, υποθέτουμε ότι ο ακροατής (Listener) είναι ένα HTTP servlet. Είναι αρμοδιότητα του ακροατή να συνοψίσει 111

122 τα δεδομένα, τα οποία αφορούν στο πρωτόκολλο, σε ένα αντικείμενο μηνύματος (Μessage), και να τοποθετήσει το μήνυμα μέσα σε ένα περιεχόμενο μηνύματος. Το περιεχόμενο μηνύματος φορτώνεται επίσης με ποικίλες ιδιότητες από τον ακροατή. Ο ακροατής μεταφοράς επιπροσθέτως, ρυθμίζει το όνομα μεταφοράς (ΤransportName), ένα αλφαριθμητικό (String), στο περιεχόμενο μηνύματος. Aπό τη στιγμή την οποία το περιεχόμενο μηνύματος είναι έτοιμο να φύγει, ο ακροατής το παραδίδει στην μηχανή του Axis (AxisEngine). H πρώτη δουλειά της μηχανής Axis, είναι να κοιτάξει την μεταφορά με βάση το όνομα. Η μεταφορά είναι ένα αντικείμενο το οποίο περιέχει μία αίτηση αλυσίδας (request Chain), μία απόκριση αλυσίδας (response Chain) ή ίσως και τα δύο. Εάν μία αίτηση αλυσίδας προϋπάρχει, αυτή θα κληθεί περνώντας το περιεχόμενο μηνύματος διαμέσου της μεθόδου επίκλησης. Αυτό θα καταλήξει στο να κληθούν όλοι οι χειριστές, που είναι καθορισμένοι στην διαμόρφωση της αλυσίδας αίτησης. Mετά την αίτηση για μεταφορά διαμέσου του χειριστή, η μηχανή εντοπίζει μία καθολική αλυσίδα αίτησης (εάν έχει καθοριστεί), και μετά επικαλείται κάθε χειριστή, ο οποίος έχει καθοριστεί εκεί. Μονοπάτι μηνύματος στον πελάτη: Το μονοπάτι μηνύματος στον πελάτη είναι παρόμοιο με αυτό του εξυπηρέτη, εκτός από την σειρά της ροής, η οποία όπως παρουσιάζεται και στο σχήμα που ακολουθεί, είναι ανεστραμμένη. Εικόνα 5. Μονοπάτι μηνύματος στον πελάτη Ο χειριστής της υπηρεσίας (service handler), εάν υπάρχει, καλείται πρώτα. Από τη μεριά του πελάτη, δεν υπάρχει παροχέας (provider) από τη στιγμή την οποία η υπηρεσία παρέχεται από έναν απομακρυσμένο κόμβο, χωρίς όμως να αποκλείεται η περίπτωση των αιτήσεων και αποκρίσεων αλυσίδων (request, response Chains). Oι αλυσίδες απόκρισης και αίτησης της υπηρεσίας διατελούν κάθε επεξεργασία γύρω από την υπηρεσία του μηνύματος αίτησης κατά την προώθησή του έξω από το σύστημα, όπως 112

123 επίσης και του μηνύματος απόκρισης κατά την προώθησή του πίσω στον καλόν (caller). Mετά από την αλυσίδα της ζήτησης (request) της υπηρεσίας, η καθολική αλυσίδα αίτησης, εάν υπάρχει, καλείται, ακολουθούμενη από τη μεταφορά. Ο αποστολέας μεταφοράς (Transport Sender), είναι ένας ξεχωριστός χειριστής που καλείται αυτή τη φορά. Δουλειά του είναι η εκτέλεση οποιασδήποτε διεργασίας βασισμένης σε πρωτόκολλο SOAP. Στη συγκεκριμένη περίπτωση καλείται για την αποστολή του μηνύματος. Η απόκριση σε αυτό το μήνυμα (εάν υπάρχει) τοποθετείται μέσα στο πεδίο μηνύματος απόκρισης (responsemessage) του περιεχόμενου μηνύματος, και το περιεχόμενο μηνύματος με τη σειρά του μεταδίδεται διαμέσου της αλυσίδας απόκρισης (response Chain) πρώτα το μεταφορικό (transport), μετά το καθολικό, και τελικά η υπηρεσία. Η υπηρεσία που δημιουργήθηκε για τους σκοπούς της πλατφόρμας που παρουσιάστηκε παραπάνω, είναι μια απλή κλάση η οποία επιστρέφει μετά από κάθε κλήση της ένα συγκεκριμένο, ώστε να είναι μετρήσιμος, αριθμό από bytes. Το αρχείο κώδικα.java μετονομάζεται σε.jws και αντιγράφεται στον κατάλογο του Axis. Με αυτόν τον τρόπο δίνοντας το URL που βρίσκεται το αρχείο σε κάποιον περιηγητή, ο Axis το μεταγλωττίζει (και το αντίστοιχο class αρχείο τοποθετείται αυτόματα στον κατάλογο classes της εφαρμογής του Axis) και δίνει τη δυνατότητα για αυτόματη παραγωγή του WSDL αρχείου απευθείας μέσω του περιηγητή. B.5 JUDDI Το JUDDI (προφέρεται τζούντι), είναι μια web εφαρμογή του Tomcat, η οποία προσφέρει τη λειτουργικότητα της γνωστής υπηρεσίας καταλόγου UDDI, στον τοπικό υπολογιστή που είναι εγκατεστημένη. Με τον τρόπο αυτό ήταν δυνατό η πλατφόρμα που παρουσιάστηκε να μην απαιτεί τη σύνδεση με το διαδίκτυο και να μπορεί να εξομοιωθεί όλη η λειτουργικότητα σε ένα τοπικό δίκτυο (Ethernet) όπου και οι μετρήσεις θα μπορούσαν να γίνουν με μεγάλη ακρίβεια. Το JUDDI διέπεται από αρκετά χαρακτηριστικά: Είναι μια υπηρεσία καταλόγου ανοιχτού λογισμικού. Είναι ανεξάρτητη του λειτουργικού συστήματος των μηχανημάτων. Υποστηρίζει και παρέχει συμβατότητα με την έκδοση 2.0 του UDDI. Χρησιμοποιείται με κάθε σχεσιακή βάση δεδομένων, η οποία υποστηρίζει τα δεδομένα της ANSI SQL. 113

124 Εγκαθίσταται στον Tomcat, που ήταν ο server που χρησιμοποιήθηκε για την πλατφόρμα, καθώς είναι μια διαδικτυακή εφαρμογή του. Προσφέρει αυθεντικοποίηση και ασφάλεια των δεδομένων, αν και αυτό έχει να κάνει ως ένα βαθμό με τη βάση δεδομένων που χρησιμοποιείται. Όπως έχει αναφερθεί, το JUDDI είναι μια υλοποίηση του κλασικού UDDI, επομένως αναμένουμε να μην έχει τη δυνατότητα υποστήριξης σημασιολογικής πληροφορίας, περιγραφής και αναζήτησης των υπηρεσιών. Παραταύτα, ο συνδυασμός του με το εργαλείο matchmaker και με τη βοήθεια του racer ήταν ικανός να προσδώσει όλο τον απαραίτητο εμπλουτισμό με σημασιολογική πληροφορία στην υπηρεσία καταλόγου, ενισχύοντας παράλληλα και τις ικανότητές της. Αυτό που πρέπει να τονιστεί είναι ότι το UDDI, και κατ επέκταση το JUDDI, δεν είναι αποθήκη δεδομένων. Οι εγγραφές που βρίσκονται στη βάση δεδομένων του περιέχουν αναφορές σε άλλα δεδομένα, όπως η WSDL περιγραφή της υπηρεσίας. Δομές δεδομένων του UDDI Οι προδιαγραφές του UDDI, επιτρέπουν σε οντότητες όπως εταιρίες και οργανισμοί να καταχωρούν δημόσια πληροφορία για αυτούς και πληροφορίες για τις υπηρεσίες που παρέχουν. Επιπλέον επιτρέπει σε οντότητες όπως επιχειρήσεις, ομάδες προτύπων και ομάδες βιομηχανιών, να καταχωρούν πληροφορίες για τα είδη υπηρεσιών που έχουν ορίσει, περιγραφές προτύπων και εννοιών, και να αναφέρονται σε αυτά με αναγνωριστικά ονόματα που τους έχουν ορίσει. Κατά συνέπεια, το UDDI φαίνεται σαν να προσφέρει δυο διαφορετικούς καταλόγους: έναν επαγγελματικό, και ένα κατάλογο τύπου αναφοράς. Σε απόλυτη αντιστοιχία, το UDDI έχει στον πυρήνα του δυο βασικές ριζικές δομές δεδομένων, τις businessentity και tmodel. 114

125 Εικόνα 6. Μοντέλο πληροφορίας του UDDI Δομή δεδομένων BusinessEntity Η δομή αυτή αποτελεί και το στοιχείο του υψηλότερου επιπέδου στο μοντέλο πληροφορίας του UDDI. Χρησιμοποιείται για την αναπαράσταση πληροφορίας σχετιζόμενης με την οντότητα ή την επιχείρηση που προσφέρει κάποια υπηρεσία. Επίσης, χρησιμοποιείται ως container για τα στοιχεία της υπηρεσίας καθώς και πληροφορίας σχετικά με την εγκαθίδρυση της επικοινωνίας με αυτή, όπως φαίνεται και στο παραπάνω σχήμα. Η πληροφορία της οντότητας της επιχείρησης διαχωρίζεται θεμελιωδώς σε μέρη που είναι γνωστά με τους όρους Λευκές, Κίτρινες, και Πράσινες σελίδες: Οι Λευκές σελίδες περιέχουν γενικές πληροφορίες επικοινωνίας με την οντότητα. Παραδείγματος χάριν, πληροφορίες σχετικές με το όνομα, τη διεύθυνση τηλέφωνα και τρόποι επικοινωνίας με την εταιρεία, τοποθετούνται εδώ. Οι Κίτρινες σελίδες περιέχουν πληροφορίες ταξινόμησης για τους τύπους και την τοποθεσία των υπηρεσιών που προσφέρει η οντότητα. Για παράδειγμα, για μια κατασκευαστική εταιρεία, πληροφορίες σχετικά με το είδος των κατασκευών της θα μπορούσαν να ήταν εδώ. ΟΙ Πράσινες σελίδες περιέχουν πληροφορίες για τον τρόπο με τον οποίο μπορεί κάποιος να έχει πρόσβαση στις υπηρεσίες που προσφέρονται. Συνήθως κάποιο URL αναφέρεται εδώ, ώστε ο πελάτης να ξέρει πού θα καλέσει την υπηρεσία. Είναι απαραίτητο να σημειωθεί ότι αυτό είναι απλά ένα θεμελιώδες μοντέλο, και πως το UDDI δεν καθορίζει κάποιο συγκεκριμένο μοντέλο αποθήκευσης. Μια καταχώρηση μιας οντότητας στις λευκές σελίδες θα περιέχει και πληροφορίες 115