Μελέτη Μεθοδολογιών ικτυακής Επικοινωνίας Αρθρωµάτων Λογισµικού

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

ΙΑΤΡΙΒΗ για την απόκτηση διδακτορικού διπλώµατος του Τµήµατος Μηχανικών Πληροφοριακών και Επικοινωνιακών Συστηµάτων του Πανεπιστηµίου Αιγαίου Κωνσταντίνος Ράπτης Μελέτη Μεθοδολογιών ικτυακής Επικοινωνίας Αρθρωµάτων Λογισµικού Συµβουλευτική επιτροπή: Επιβλέπων: Σωκράτης Κάτσικας Καθηγητής Πανεπιστηµίου Αιγαίου Μέλη: ιοµήδης Σπινέλλης Επίκουρος Καθηγητής Οικονοµικού Πανεπιστηµίου Αθηνών ηµήτριος Χριστοδουλάκης Καθηγητής Πανεπιστηµίου Πατρών

Περίληψη Στόχος των µεθοδολογιών δικτυακής επικοινωνίας, ή αλλιώς των µοντέλων αποµακρυσµένης επίκλησης, αρθρωµάτων και αντικειµένων λογισµικού είναι να καταστεί δυνατή η µεταξύ τους επικοινωνία σε ένα κατανεµηµένο και ετερογενές υπολογιστικό περιβάλλον. Η ανάγκη για ανάπτυξη λογισµικού µε χρήση υπάρχοντα κώδικα και όχι από το µηδέν και η ανάγκη για εξάπλωση του διαθέσιµου κώδικα σε ένα δίκτυο υπολογιστών, πιθανόν διαφορετικών, προκειµένου να υπάρχει εκµετάλλευση τόσο της υπολογιστικής ισχύς όσο και των αποθηκευτικών µέσων αυτών, οδήγησαν στην ανάπτυξη µοντέλων που θα επέτρεπαν την σύνδεση και επικοινωνία αντικειµένων και εξαρτηµάτων λογισµικού τα οποία θα δύναται να προέρχονται από διαφορετικές πηγές, να βασίζονται σε διαφορετικές γλώσσες προγραµµατισµού και να λειτουργούν σε διαφορετικές υπολογιστικές πλατφόρµες. Οι OMG CORBA, Microsoft COM/DCOM και Sun Java RMI αποτελούν τα βασικότερα µοντέλα αρχιτεκτονικές σκοπός των οποίων είναι η επίτευξη της σύνδεσης και επικοινωνίας διαφορετικών εξαρτηµάτων και αντικειµένων λογισµικού. Η χρήση των παραπάνω τεχνολογιών οδήγησε στην ανάπτυξη εφαρµογών αλλά και στην σχεδίαση πληροφοριακών συστηµάτων βασιζόµενων στην αρχιτεκτονική που προτείνεται από τις υποκείµενες τεχνολογίες. Αν και η χρήση των µοντέλων αποµακρυσµένης επίκλησης βοήθησε στην επίτευξη των πρωταρχικών στόχων, γέννησε νέα προβλήµατα τα οποία σχετίζονταν µε τις δυνατότητες επικοινωνίας κα συνεργασίας εξαρτηµάτων και αντικειµένων λογισµικού τα οποία βασίζονταν σε διαφορετικές τεχνολογίες. Με την παρούσα έρευνα, παρουσιάζουµε την αρχιτεκτονική κατασκευής αντικειµένων λογισµικού, γεφυρών των εµπλεκοµένων τεχνολογιών, τα οποία δίνουν την δυνατότητα σε αντικείµενα, εξυπηρετητές, µίας τεχνολογίας να εκθέτουν τις υπηρεσίες τους σε αντικείµενα,πελάτες, διαφορετικών τεχνολογιών. Η ιδέα της αρχιτεκτονικής που προτείνουµε βασίζεται στην ανάπτυξη ενός απλού και εύχρηστου αντικειµένου το οποίο θα λειτουργεί ως εικονικός εξυπηρετητής συµβατός µε την τεχνολογία του πραγµατικού πελάτη και το οποίο θα προωθεί την κλήση του πελάτη, προς το πραγµατικό αντικείµενο εξυπηρετητής λειτουργώντας ως ένας εικονικός πελάτης συµβατός µε την τεχνολογία του εξυπηρετητή. Εφαρµόζοντας την παραπάνω αρχιτεκτονική αναπτύξαµε τέσσερα αντικείµενα γέφυρες που επιτρέπουν την σύνδεση αντικειµένων πελατών και εξυπηρετητών ανεξάρτητα από τις τεχνολογίες στις οποίες βασίζονται. Πιο συγκεκριµένα, τα τέσσερα αντικείµενα-γέφυρες που υλοποιήσαµε αφορούν τις συνδέσεις: 1. εξυπηρετητής τεχνολογίας CORBA πελάτης τεχνολογίας Java RMI, 2. εξυπηρετητής τεχνολογίας Java RMI πελάτης τεχνολογίας CORBA, i

3. εξυπηρετητής τεχνολογίας COM/DCOM πελάτης τεχνολογίας CORBA και 4. εξυπηρετητής τεχνολογίας Java RMI πελάτης τεχνολογίας COM/DCOM. Οι υλοποιήσεις των αντικειµένων-γεφυρών των παραπάνω περιπτώσεων, επιτρέπουν τόσο την άµεση σύνδεση αντικειµένων πελατών και εξυπηρετητών δύο διαφορετικών τεχνολογιών όσο και την σύνδεση αυτών µε την διαµεσολάβηση τρίτης τεχνολογίας σε συνδυασµό µε την χρήση δύο αντικειµένων-γεφυρών. Σε κάθε περίπτωση οι υλοποιήσεις ακολουθούν την προτεινόµενη αρχιτεκτονική της χρησιµοποίησης της δοµής ενός αντικειµένου εξυπηρετητής, συµβατού µε την τεχνολογία του πραγµατικού αντικειµένου πελάτης και την ενσωµάτωση όλων των απαραίτητων χαρακτηριστικών ενός αντικειµένου πελάτης, συµβατού µε την τεχνολογία του πραγµατικού αντικειµένου εξυπηρετητή, χωρίς να µεταβάλλονται και να τροποποιούνται τα φυσικά χαρακτηριστικά των υπό σύνδεση τεχνολογιών. ii

Ευχαριστίες Ένας σηµαντικός αριθµός ατόµων συνέβαλαν, άµεσα ή έµµεσα, στην ολοκλήρωση της παρούσας ερευνητικής προσπάθειας. Πρώτους από όλους, θα ήθελα να ευχαριστήσω τους γονείς µου και την σύζυγό µου Έφη γιατί πρώτοι αυτοί πίστεψαν σε εµένα και µε ενθάρρυναν καθ όλη την διάρκεια της έρευνας µου. Επιπλέον θα ήθελα να ευχαριστήσω: Τον Καθηγητή, του Πανεπιστηµίου Αιγαίου, Σωκράτη Κάτσικα για την εµπιστοσύνη που έδειξε στο πρόσωπό µου αναλαµβάνοντας την ευθύνη της έρευνας ως επιβλέπων και για καθοδήγησή του καθ όλη την διάρκειά της. Τον Επίκουρο Καθηγητή, του Οικονοµικού Πανεπιστηµίου Αθηνών, ιοµήδη Σπινέλλη, για την καθοδήγηση, την συνεργασία και προπάντων την υποµονή που έδειξε, ως µέλος της τριµελούς συµβουλευτικής επιτροπής, κατά την διάρκεια της έρευνας αλλά και κατά την συγγραφή της παρούσας διατριβής. Τον Καθηγητή, του Πανεπιστηµίου Πατρών, ηµήτριο Χριστοδουλάκη για την συµπαράσταση και κατανόησή του ως µέλος της τριµελούς συµβουλευτικής επιτροπής. Τον Πρόεδρο του Τµήµατος Πληροφοριακών και Επικοινωνιακών Συστηµάτων του Πανεπιστηµίου Αιγαίου, Αναπληρωτή Καθηγητή Γεώργιο Βούρο, για την υποστήριξη και την συνεργασία του όλα αυτά τα χρόνια παρουσίας µου στο Τµήµα ως υποψήφιος διδάκτορας. Τον συνάδελφο υποψήφιο διδάκτορα Ευάγγελο Κουράκο-Μαυροµιχάλη για την συµπαράστασή του και τις χρήσιµες συζητήσεις που είχαµε. Του εύχοµαι σύντοµα να φέρει σε πέρας και την δική του ερευνητική προσπάθεια. Τέλος, θα ήθελα να ευχαριστήσω όλο το προσωπικό του Τµήµατος Μηχανικών Πληροφοριακών και Επικοινωνιακών Συστηµάτων, διδακτικό και διοικητικό, για την βοήθειά τους κατά την παρουσία µου στο Τµήµα. Την παρούσα εργασία την αφιερώνω στην σύζυγό µου Έφη και στο νέο µέλος της οικογένειάς µας που περιµένουµε να έρθει. Κωνσταντίνος Ράπτης Ιούλιος 2002 iii

Πίνακας περιεχοµένων Περίληψη...i Ευχαριστίες... iii Πίνακας περιεχοµένων...iv Σχήµατα... viii Πίνακες...x Γραφήµατα...xi 1 Εισαγωγή...1 1.1 Αντικείµενο Στόχοι...1 1.2 Τεχνολογίες Ενδιαµέσων...1 1.2.1 OMG CORBA...2 1.2.2 Microsoft COM/DCOM...3 1.2.3 Sun Java RMI...4 1.3 Ασυµβατότητα Αντικειµένων Λογισµικού...4 1.3.1 ιαφορετικές προσεγγίσεις και υλοποιήσεις των διεπαφών...5 1.3.2 ιαφορετικές µέθοδοι αναφοράς σε αντικείµενα και φύλαξης αυτών...5 1.3.3 Χρήση διαφορετικών πρωτοκόλλων...5 1.4 Γεφυρώνοντας το Χάσµα...5 1.5 Οργάνωση της διατριβής...6 2 Αντικείµενα και τεχνολογίες ενδιαµέσων...8 2.1 Εισαγωγή...8 2.2 Μοντέλα ενδιαµέσων...9 2.2.1 OMG CORBA...11 2.2.1.1 ORB... 13 2.2.1.1.1 Στην πλευρά του πελάτη... 14 2.2.1.1.2 Στην πλευρά του εξυπηρετητή... 15 2.2.1.1.3 Αναφορές προς αντικείµενα... 15 2.2.1.2 Μοντέλο επικοινωνίας... 16 2.2.1.3 Γλώσσα ορισµού διεπαφών... 16 2.2.1.4 Μέθοδος στατικής επίκλησης... 18 2.2.1.5 Μέθοδος δυναµικής επίκλησης... 19 2.2.1.5.1 ιεπαφή δυναµικής επίκλησης... 19 2.2.1.5.2 ιεπαφή δυναµικού skeleton... 19 2.2.1.6 Object Adapter... 20 2.2.2 Microsoft COM/DCOM...20 2.2.2.1 ιεπαφές... 22 2.2.2.2 Μοντέλο επικοινωνίας... 24 2.2.2.3 Γλώσσα ορισµού διεπαφών της Microsoft... 24 2.2.2.4 υαδικό πρότυπο και απεικονίσεις προς διαφορετικές γλώσσες... 25 2.2.2.5 Λειτουργία της COM/DCOM... 26 2.2.3 Sun Java RMI...27 2.2.3.1 Λειτουργία του συστήµατος Java RMI... 28 2.2.3.2 Μοντέλο επικοινωνίας... 29 iv

2.3 ιαλειτουργικότητα αντικειµένων...29 2.3.1 Ασυµβατότητα αντικειµένων λογισµικού...30 2.3.1.1 ιαφορετικές προσεγγίσεις και υλοποιήσεις των διεπαφών... 31 2.3.1.2 ιαφορετικές µέθοδοι αναφοράς σε αντικείµενα και φύλαξης αυτών... 31 2.3.1.3 Χρήση διαφορετικών πρωτοκόλλων... 33 2.3.2 Γεφυρώνοντας το χάσµα...34 2.3.2.1 Γεφύρωση µεταξύ CORBA-COM/DCOM... 35 2.3.2.2 Γεφύρωση µεταξύ CORBA-Java RMI... 36 2.3.2.3 Γεφύρωση µεταξύ COM/DCOM-Java RMI... 37 2.4 Σύνοψη...38 3 Εφαρµογές CORBA, Java RMI & COM/DCOM...39 3.1 Εισαγωγή...39 3.2 Κατασκευή εφαρµογών πελάτη-εξυπηρετητή µε χρήση των CORBA, Java RMI και COM/DCOM...40 3.2.1 Κατασκευή εφαρµογής πελάτη-εξυπηρετητή µε CORBA...40 3.2.1.1 Κατασκευή της διεπαφής... 43 3.2.1.2 Μετάφραση της διεπαφής... 44 3.2.1.3 Κατασκευή του εξυπηρετητή... 45 3.2.1.4 Μετάφραση του εξυπηρετητή... 47 3.2.1.5 Κατασκευή του πελάτη... 47 3.2.1.6 Μετάφραση του πελάτη... 49 3.2.1.7 Εκτέλεση της εφαρµογής... 49 3.2.2 Κατασκευή εφαρµογής πελάτη-εξυπηρετητή µε Java RMI...50 3.2.2.1 Κατασκευή της διεπαφής... 51 3.2.2.2 Κατασκευή του εξυπηρετητή... 53 3.2.2.3 Κατασκευή του πελάτη... 56 3.2.2.4 Εκτέλεση της εφαρµογής... 57 3.2.3 Κατασκευή εφαρµογής πελάτη-εξυπηρετητή µε COM/DCOM 58 3.2.3.1 Κατασκευή της διεπαφής... 60 3.2.3.2 Εξαγωγή της βιβλιοθήκης τύπων... 61 3.2.3.3 Κατασκευή κλάσης υλοποίησης... 62 3.2.3.4 Καταχώρηση της κλάσης υλοποίησης... 63 3.2.3.5 Κατασκευή του πελάτη... 63 3.2.3.6 Εκτέλεση της εφαρµογής... 64 3.2.4 Μοντέλο συνένωσης Java/COM...65 3.2.4.1 Ανάπτυξη εξυπηρετητή COM µε την χρήση της Java... 66 3.2.4.2 Κατασκευή πελάτη COM µε την χρήση της Java... 67 3.2.4.3 Χρήση εξαρτήµατος COM ως Java... 68 3.3 Γενίκευση στόχου...69 3.3.1 Αρχιτεκτονική...70 3.3.2 Απαιτήσεις...73 3.4 Σύνοψη...73 4 Σχεδίαση υλοποίησης...75 4.1 Εισαγωγή...75 4.2 Μετασχηµατισµός εφαρµογών διαφορετικών τεχνολογιών...76 4.3 Βήµατα ανάπτυξης µετασχηµατισµένης εφαρµογής...78 4.4 Σύνοψη...83 v

5 Υλοποίηση...84 5.1 Εισαγωγή...84 5.2 Εφαρµογή πελάτη Java RMI και εξυπηρετητή CORBA...85 5.2.1 Ανάπτυξη διεπαφής τεχνολογίας Java RMI...87 5.2.2 Ανάπτυξη βοηθητικών αρχείων πελάτη τεχνολογίας CORBA..88 5.2.3 Ανάπτυξη αντικειµένου-γέφυρα...89 5.2.4 Ανάπτυξη βοηθητικών αρχείων πελάτη και εξυπηρετητή τεχνολογίας Java RMI...92 5.2.5 Ανάπτυξη πελάτη τεχνολογίας Java RMI...92 5.2.6 Εκτέλεση...93 5.3 Εφαρµογή πελάτη CORBA και εξυπηρετητή Java RMI...96 5.3.1 Ανάπτυξη διεπαφής τεχνολογίας CORBA...97 5.3.2 Εξαγωγή stub πελάτη τεχνολογίας Java RMI...99 5.3.3 Ανάπτυξη βοηθητικών αρχείων πελάτη και εξυπηρετητή τεχνολογίας CORBA...99 5.3.4 Ανάπτυξη αντικειµένου-γέφυρα...100 5.3.5 Ανάπτυξη πελάτη τεχνολογίας CORBA...103 5.3.6 Εκτέλεση...104 5.4 Εφαρµογή πελάτη CORBA και εξυπηρετητή COM...108 5.4.1 Ανάπτυξη διεπαφής τεχνολογίας CORBA...110 5.4.2 Ανάπτυξη βοηθητικών αρχείων πελάτη και εξυπηρετητή τεχνολογίας CORBA...112 5.4.3 Ανάπτυξη αντικειµένου-γέφυρα...112 5.4.4 Ανάπτυξη πελάτη τεχνολογίας CORBA...115 5.4.5 Μετάφραση και εκτέλεση...116 5.5 Εφαρµογή πελάτη COM και εξυπηρετητή Java RMI...119 5.5.1 Εξαγωγή stub πελάτη τεχνολογίας Java RMI...120 5.5.2 Ανάπτυξη αντικειµένου-γέφυρα...120 5.5.3 Ανάπτυξη πελάτη τεχνολογίας COM...123 5.5.4 Eκτέλεση...123 5.6 Εφαρµογή σύνδεσης πελάτη Java RMI και εξυπηρετητή COM µέσω της τεχνολογίας CORBA...126 5.7 Σύνοψη...131 6 Αξιολόγηση...132 6.1 Εισαγωγή...132 6.2 Συνεισφορά στην διαλειτουργικότητα των αντικειµένων...133 6.3 Παραδοχές...135 6.4 Αξιολόγηση αντικειµένου-γέφυρα ως λογισµικό...136 6.4.1 Συµµόρφωση µε τα πρότυπα...136 6.4.2 Περιορισµοί από το υλικό...136 6.4.3 ιαθεσιµότητα...137 6.4.4 Ασφάλεια...137 vi

6.4.5 Συντηρησιµότητα...139 6.4.6 Μεταφερσιµότητα...139 6.4.7 Επιδόσεις...140 6.5 Συµπεράσµατα...147 6.6 Σύνοψη...148 7 Μελλοντική εργασία...149 7.1 Εισαγωγή...149 7.2 Εφαρµογή της αρχιτεκτονικής στα πλαίσια πραγµατικού έργου...149 7.3 Λειτουργία δυναµικής επίκλησης...150 7.4 Ανάπτυξη εργαλείου κατασκευής αντικειµένων-γεφυρών...151 7.5 Συνδυασµός µε εργαλεία διαλειτουργικότητας CORBA/COM...151 7.6 Υποστήριξη XML και SOAP...152 7.7 Σύνοψη...152 8 Σύνοψη...154 Βιβλιογραφικές αναφορές & πηγές...156 ηµοσιευµένα άρθρα - Παρουσιάσεις...156 Τεχνικά δελτία - Προδιαγραφές...160 Βιβλία...163 Πίνακας Ακρώνυµων...164 Παράρτηµα Α...166 Α.1 Αντικείµενο-γέφυρα σύνδεσης πελάτη Java RMI εξυπηρετητή CORBA...166 Α.2 Αντικείµενο-γέφυρα σύνδεσης πελάτη CORBA εξυπηρετητή Java RMI...168 Α.3 Αντικείµενο-γέφυρα σύνδεσης πελάτη CORBA εξυπηρετητή COM 170 Α.4 Αντικείµενο-γέφυρα σύνδεσης πελάτη COM εξυπηρετητή Java RMI...172 Παράρτηµα Β...173 Β.1 Χρήση εξαρτήµατος COM από πελάτη τεχνολογίας CORBA...173 vii

Σχήµατα Σχήµα 2.1: Η αρχιτεκτονική της OMA...11 Σχήµα 2.2: Η διαµεσολάβηση του ORB µεταξύ πελάτη & εξυπηρετητή...13 Σχήµα 2.3: Η αρχιτεκτονική της CORBA...14 Σχήµα 2.4: ράση πελάτη-εξυπηρετητή µέσω COM/DCOM...22 Σχήµα 2.5: Επικοινωνία πελάτη-εξυπηρετητή µέσω διεπαφής...23 Σχήµα 2.6: Αρχιτεκτονική συστήµατος Java RMI...28 Σχήµα 2.7: ροµολόγηση αιτήσεων-αποκρίσεων στο σύστηµα Java RMI...28 Σχήµα 3.1: Ανάπτυξη εφαρµογής CORBA...42 Σχήµα 3.2: Τα παραγόµενα αρχεία από την διεπαφή SumInt µέσω του µεταφραστή jidl...45 Σχήµα 3.3: Ανάπτυξη εφαρµογής Java RMI...51 Σχήµα 3.4: Ανάπτυξη εφαρµογής COM/DCOM...59 Σχήµα 3.5: Μοντέλο συνένωσης Java/COM...66 Σχήµα 3.6: Χρήση εξαρτήµατος COM ως Java...69 Σχήµα 3.7: ιάγραµµα κλάσεων αλληλεπίδρασης αντικειµένων Α και Β...72 Σχήµα 3.8: ιάγραµµα δράσεων αλληλεπίδρασης αντικειµένων Α και Β...72 Σχήµα 4.1: Το τρίγωνο συνδέσεως των τεχνολογιών CORBA, COM/DCOM και Java RMI...76 Σχήµα 4.2: Μετασχηµατισµός δύο όµοιων εφαρµογών διαφορετικών τεχνολογιών...77 Σχήµα 4.3: Μετασχηµατισµός µε την χρήση και της τρίτης τεχνολογίας ως γέφυρα επικοινωνίας...78 Σχήµα 4.4: Βήµατα ανάπτυξης µετασχηµατισµένης εφαρµογής...80 Σχήµα 4.5: Μετασχηµατισµένη εφαρµογή πελάτη-εξυπηρετητή δύο διαφορετικών τεχνολογιών ενδιαµέσων...81 Σχήµα 4.6: οµή του αντικειµένου-γέφυρα...82 Σχήµα 5.1: Εξελιγµένο τρίγωνο συνδέσεως των τεχνολογιών CORBA, COM/DCOM και Java RMI...85 Σχήµα 5.2: Γενική µορφή µετασχηµατισµένης εφαρµογής πελάτη Java RMI και εξυπηρετητή CORBA...86 Σχήµα 5.3: Βήµατα ανάπτυξης µετασχηµατισµένης εφαρµογής πελάτη Java RMI εξυπηρετητή CORBA...94 Σχήµα 5.4: Μετασχηµατισµένη εφαρµογή πελάτη τεχνολογίας Java RMI και εξυπηρετητή τεχνολογίας CORBA...95 Σχήµα 5.5: Γενική µορφή µετασχηµατισµένης εφαρµογής πελάτη CORBA και εξυπηρετητή Java RMI...96 viii

Σχήµα 5.6: Τα παραγόµενα αρχεία από την διεπαφή SumIntBr.idl µέσω του µεταφραστή jidl...99 Σχήµα 5.7: Βήµατα ανάπτυξης µετασχηµατισµένης εφαρµογής πελάτη CORBA εξυπηρετητή Java RMI...106 Σχήµα 5.8: Μετασχηµατισµένη εφαρµογή πελάτη τεχνολογίας CORBA και εξυπηρετητή τεχνολογίας Java RMI...107 Σχήµα 5.9: Γενική µορφή µετασχηµατισµένης εφαρµογής πελάτη CORBA και εξυπηρετητή COM...108 Σχήµα 5.10: Τα παραγόµενα αρχεία από την διεπαφή SumInt.idl µέσω του µεταφραστή jidl...112 Σχήµα 5.11: Βήµατα ανάπτυξης µετασχηµατισµένης εφαρµογής πελάτη CORBA εξυπηρετητή COM...117 Σχήµα 5.12: Μετασχηµατισµένη εφαρµογή πελάτη τεχνολογίας CORBA και εξυπηρετητή τεχνολογίας COM...118 Σχήµα 5.13: Γενική µορφή µετασχηµατισµένης εφαρµογής πελάτη COM και εξυπηρετητή Java RMI...119 Σχήµα 5.14: Βήµατα ανάπτυξης µετασχηµατισµένης εφαρµογής πελάτη COM και εξυπηρετητή Java RMI...124 Σχήµα 5.15: Μετασχηµατισµένη εφαρµογή πελάτη τεχνολογίας COM και εξυπηρετητή τεχνολογίας Java RMI...125 Σχήµα 5.16: Μετασχηµατισµός µε την χρήση της τεχνολογίας CORBA ως γέφυρα επικοινωνίας µεταξύ πελάτη Java RMI και εξυπηρετητή COM.126 Σχήµα 5.17: Σύνθεση εφαρµογής πελάτη Java RMI και εξυπηρετητή COM..128 Σχήµα 5.18: Μετασχηµατισµένη εφαρµογή πελάτη τεχνολογίας Java RMI και εξυπηρετητή τεχνολογίας COM...130 ix

Πίνακες Πίνακας 2.1: Απεικονίσεις βασικών τύπων CORBA IDL/Java [Orfali et al 98]...17 Πίνακας 2.2: Απεικονίσεις κατασκ. τύπων CORBA IDL/Java [Orfali et al 98]18 Πίνακας 2.3: Απεικονίσεις βασικών τύπων Microsoft IDL/Java [Orfali et al 98]...25 Πίνακας 2.4: Βασικές διαφορές µεταξύ CORBA/DCOM/RMI...34 Πίνακας 3.1: Επεκτάσεις αρχείων τα οποία δύναται να εµπεριέχουν βιβλιοθήκες τύπων...62 Πίνακας 5.1: Αντιστοίχιση διεπαφών τεχνολογιών Java RMI και CORBA...88 Πίνακας 5.2: Εφαρµογές εξυπηρετητή Java RMI και πελάτη CORBA...91 Πίνακας 5.3: Πελάτης τεχνολογίας Java RMI...93 Πίνακας 5.4: Αντιστοίχιση διεπαφών τεχνολογιών CORBA και Java RMI...98 Πίνακας 5.5: Εφαρµογές εξυπηρετητή CORBA και πελάτη Java RMI...102 Πίνακας 5.6: Πελάτης τεχνολογίας CORBA...104 Πίνακας 5.7: Κώδικας κλάσης τεχνολογίας COM, παράγωγο του εργαλείου JActiveX...110 Πίνακας 5.8: Κώδικας διεπαφής τεχνολογίας COM, παράγωγο του εργαλείου JActiveX...110 Πίνακας 5.9: ιεπαφή IDL τεχνολογίας CORBA...111 Πίνακας 5.10: Εφαρµογές εξυπηρετητή CORBA και πελάτη COM...114 Πίνακας 5.11: Πελάτης τεχνολογίας CORBA...115 Πίνακας 5.12: Εφαρµογές εξυπηρετητή COM και πελάτη Java RMI...121 Πίνακας 5.13: Πελάτης τεχνολογίας COM...123 Πίνακας 6.1: Πλατφόρµες και τεχνολογίες ενδιαµέσων...136 Πίνακας 6.2: Υπηρεσίες ασφάλειας των CORBA, COM/DCOM και Java RMI...138 Πίνακας Β.1: ιεπαφή Java, περίβληµα τεχνολογίας COM...174 Πίνακας Β.2: ιεπαφή IDL τεχνολογίας CORBA...175 Πίνακας Β.3: Αντικείµενο-γέφυρα σύνδεσης πελάτη CORBA εξαρτήµατος COM...176 Πίνακας Β.4: Πελάτης τεχνολογίας CORBA...177 x

Γραφήµατα Γράφηµα 6.1: Εφαρµογές πελάτη-εξυπηρετητή...142 Γράφηµα 6.2: Εφαρµογές πελάτη-εξυπηρετητή...143 Γράφηµα 6.3: Μετασχηµατισµένες εφαρµογές πελάτη-γέφυρας-εξυπηρετητή (τοπικές κλήσεις)...143 Γράφηµα 6.4: Μετασχηµατισµένες εφαρµογές πελάτη-γέφυρας-εξυπηρετητή (πελάτης-γέφυρα αποµακρυσµένα, γέφυρα-εξυπηρετητής τοπικά)...144 Γράφηµα 6.5: Μετασχηµατισµένες εφαρµογές πελάτη-γέφυρας-εξυπηρετητή (πελάτης-γέφυρα τοπικά, γέφυρα-εξυπηρετητής αποµακρυσµένα)...144 Γράφηµα 6.6: Εφαρµογές πελάτη-εξυπηρετητή...146 Γράφηµα 6.7: Μετασχηµατισµένες εφαρµογές πελάτη-γέφυρας-εξυπηρετητή...147 xi

Κεφάλαιο 1 : Εισαγωγή 1 Εισαγωγή 1.1 Αντικείµενο Στόχοι Η ανάγκη για αλληλεπίδραση (interaction) µεταξύ εξαρτηµάτων λογισµικού (software components) από διαφορετικούς κατασκευαστές, τα οποία τρέχουν σε διαφορετικά µηχανήµατα και πάνω από διαφορετικά λειτουργικά συστήµατα, οδήγησε στον προσδιορισµό των µοντέλων ενδιαµέσων για αποµακρυσµένη επικοινωνία (Middleware Remoting Models). Η Common Object Request Broker Architecture (CORBA) της Object Management Group (OMG) [OMG 95, OMG 98, OMG 99, Vinosky 93, Vinosky 97], η Component Object Model / Distributed Component Object Model (COM/DCOM) της Microsoft [Microsoft 95, Microsoft 96, Microsoft 98, Wallace 99] και η Java Remote Method Invocation (RMI) της Sun [Sun 96a, Sun 96b, Sun 96c, Sun 98, Sutherland 98], είναι τρία µοντέλα που επιτρέπουν σε εξαρτήµατα λογισµικού µε διαφορετική προέλευση να δουλεύουν µαζί. Για να µπορούν τα εξαρτήµατα λογισµικού να επικοινωνούν αλληλεπιδρούν µεταξύ τους θα πρέπει να συµµορφώνονται µε τους κανόνες της υποκείµενης τεχνολογίας ενδιαµέσου (underlying middleware technology). Όµως, είναι δύσκολο, εάν όχι αδύνατο, για δύο εξαρτήµατα τα οποία βασίζονται σε διαφορετικές τεχνολογίες να επικοινωνήσουν µεταξύ τους. Τα προβλήµατα συµβατότητας πηγάζουν από τις διαφορές των υποκείµενων µοντέλων και από τον τρόπο που αυτά παρουσιάζουν και χρησιµοποιούν τα εξαρτήµατα λογισµικού. Όταν υπάρχει η ανάγκη για διαλειτουργικότητα (interoperation) µεταξύ δύο ή περισσοτέρων εξαρτηµάτων, βασισµένων σε διαφορετικές τεχνολογίες, ο βασικός στόχος είναι µην γίνεται αντιληπτό από τα εξαρτήµατα το γεγονός ότι τα άλλα εξαρτήµατα λειτουργούν κάτω από µία διαφορετική τεχνολογία χωρίς βέβαια αυτό να επηρεάζει τα χαρακτηριστικά και την συµπεριφορά τους. Ο σκοπός της παρούσας ερευνητικής εργασίας και διδακτορικής διατριβής αφορά µε την αξιοποίηση της γλώσσας προγραµµατισµού Java ως ένα εργαλείο για την ανάπτυξη µίας αρχιτεκτονικής και τη δηµιουργία ενός µηχανισµού ο οποίος θα γεφυρώνει τις τρεις πιο διαδεδοµένες τεχνολογίες ενδιαµέσων γα αποµακρυσµένη επικοινωνία: CORBA, COM/DCOM και Java RMI. Χρησιµοποιήσουµε, δηλαδή, την Java ως µία κόλλα γενικής χρήσης. Στόχος µας είναι να επιτρέπουµε σε ένα αντικείµενο εξυπηρετητή (server object), το οποίο µπορεί να ακολουθεί µία από τις παραπάνω τεχνολογίες, να προσφέρει τις µεθόδους και γενικότερα τις υπηρεσίες του σε έναν πελάτη (client object) ασχέτως µε την τεχνολογία που και αυτός ακολουθεί. 1.2 Τεχνολογίες Ενδιαµέσων Η ικανότητα να κατασκευάζονται εφαρµογές χρησιµοποιώντας αντικείµενα λογισµικού από διαφορετικές αρχιτεκτονικές, τα οποία τρέχουν σε διαφορετικά µηχανήµατα και βασιζόµενα σε διαφορετικά λειτουργικά συστήµατα, δεν είναι κάτι το εύκολο. Η ανάγκη για αλληλεπίδραση µεταξύ των αντικειµένων αυτών οδήγησε στον προσδιορισµό των µοντέλων ενδιαµέσων [Martin 93, Plasil et al 1

Κεφάλαιο 1 : Εισαγωγή 98]. Όπως προαναφέραµε τα µοντέλα των CORBA, COM/DCOM και Java RMI, είναι τα τρία βασικότερα για την διεκπεραίωση µίας τέτοιας επικοινωνίας. Γενικά, ένας ενδιάµεσος µπορούµε να πούµε ότι περιγράφει, ουσιαστικά, ένα σύνολο από υπηρεσίες και πρωτόκολλα τα οποία υπάρχουν ακριβώς κάτω από τις εφαρµογές και παρέχουν ένα σύνολο από υπηρεσίες για τις εφαρµογές αυτές [Clark96]. Μεταφέροντας την γενική αυτή ερµηνεία στην περίπτωση της επικοινωνίας των αντικειµένων λογισµικού, ένα µοντέλο ενδιάµεσου προσφέρει τις κατάλληλες εκείνες διεπαφές, υπηρεσίες και πρωτόκολλα έτσι ώστε να είναι δυνατή η επικοινωνία µεταξύ αυτών των αντικειµένων. Τα τρία µοντέλα-τεχνολογίες που προαναφέραµε και µε τα οποία ασχολούµαστε στην παρούσα διατριβή, εφαρµόζονται στις περιπτώσεις κατανεµηµένων αντικειµένων. Αντικειµένων, δηλαδή, τα οποία βρίσκονται σε περισσότερους από έναν υπολογιστές και πιθανώς διασκορπισµένα σ ένα δίκτυο και σε διαφορετικά λειτουργικά συστήµατα. 1.2.1 OMG CORBA Η OMG ιδρύθηκε τον Απρίλιο του 1989 από έντεκα εταιρίες, µεταξύ των οποίων οι 3Com Corporation, American Airlines, Canon Inc., Data General, Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems και Unisys Corporation. Σκοπός τους ήταν να συζητάνε τις σκέψεις τους για το µέλλον της τεχνολογίας των αντικειµένων. Σήµερα, η οµάδα αυτή αποτελείται από περισσότερες από 800 εταιρίες και οι δραστηριότητές της έχουν επικεντρωθεί στην τεχνολογία των κατανεµηµένων αντικειµένων και στην CORBA. Η CORBA δεν αποτελεί ένα εκτελέσιµο προϊόν αλλά ένας γνώµονας που πρέπει να ακολουθείται από κάποιον ο οποίος θέλει να κατασκευάσει έναν Object Request Broker (ORB). Ο στόχος που προσπαθεί να επιτευχθεί είναι οι εφαρµογές να µπορούν να επικοινωνούν µεταξύ τους ανεξάρτητα µε το που βρίσκονται και από ποιον έχουν κατασκευαστεί. Η OMG δηµιούργησε µία ευρύτερη αρχιτεκτονική, την Object Management Architecture (OMA) [OMG 96, Martin 93, Vinoski 97], της οποίας η CORBA αποτελεί το κοµµάτι εκείνο που είναι υπεύθυνο για την λειτουργικότητα του ORB και περιλαµβάνει διάφορες υπηρεσίες, διεπαφές και αντικείµενα εφαρµογών. Ο ρόλος της CORBA στην OMA είναι να προσδιορίζει το πώς θα πρέπει να υλοποιείται ένας ORB. Η πρώτη έκδοση της CORBA (CORBA 1.0) έγινε δεκτή τον εκέµβριο του 1990 και στις αρχές του 1991 παρουσιάστηκε η CORBA 1.1. Με την έκδοση αυτή προσδιορίστηκαν: η γλώσσα προσδιορισµού των διεπαφών (Interface Definition Language IDL) και η διεπαφή προγραµµατισµού εφαρµογής (Applicaton Programming Interface API). Με τα παραπάνω έγινε εφικτή η επικοινωνία, µε τη χρήση συγκεκριµένων υλοποιήσεων ORB, αντικειµένων τα οποία βασίζονταν σε διαφορετικές αρχιτεκτονικές και έτρεχαν σε διαφορετικά µηχανήµατα. Η CORBA 2.0 [OMG 95] έγινε δεκτή ως πρότυπο τον εκέµβριο του 1994. Με την έκδοση αυτή έγινε εφικτή η επικοινωνία µεταξύ ORB διαφορετικής 2

Κεφάλαιο 1 : Εισαγωγή προελεύσεως, δηλαδή µεταξύ ORB διαφορετικών κατασκευαστών. Αυτό έγινε εφικτό µε την παρουσίαση του πρωτοκόλλου IIOP (Internet Inter-ORB Protocol). Κάθε κατασκευαστής ο οποίος θα ήθελε να δηµιουργήσει έναν ORB συµβατό µε το πρότυπο της CORBA 2.0 θα έπρεπε να υποστηρίζει το πρωτόκολλο αυτό. Θα πρέπει να τονίσουµε ότι το πρωτόκολλο IIOP ορίζεται για δίκτυα που στηρίζονται στο πρωτόκολλο TCP/IP. Κατά καιρούς ακολούθησαν και άλλες εκδόσεις του προτύπου της CORBA, οι οποίες αποτελούσαν ενηµερώσεις των προηγουµένων και υπήρχαν και επιµέρους προσθήκες. Η τελευταία έκδοση της CORBA είναι η 3.0 ενισχύει τις προηγούµενες εκδόσεις µε τρία νέα χαρακτηριστικά: την ολοκλήρωση της CORBA µε την Java και το διαδίκτυο (Internet), την ποιότητα του ελέγχου των υπηρεσιών και την αρχιτεκτονική για εξαρτήµατα βασιζόµενα στην CORBA [Siegel99]. Υπάρχουν αρκετές υλοποιήσεις του προτύπου της CORBA, ορισµένες εµπορικές και άλλες ελεύθερες. Οι διαφορές που υπάρχουν µεταξύ των υλοποιήσεων αυτών αφορούν την συµµόρφωσή τους σε διαφορετικές εκδόσεις και υποστήριξη των υπηρεσιών του προτύπου της CORBA. 1.2.2 Microsoft COM/DCOM Η COM (Component Object Model) [Microsoft 95] ορίζει ένα πρότυπο βάσει του οποίου αντικείµενα παρέχουν διάφορες υπηρεσίες το ένα στο άλλο. Το πρότυπο αυτό σχεδιάστηκε από την Microsoft µε σκοπό να εφοδιάσει τους προγραµµατιστές µε προδιαγραφές για αντικείµενα σε παραθυρικό περιβάλλον, τα γνωστά µας Windows. Όταν η Microsoft ανέπτυξε το λειτουργικό σύστηµα Windows 3.0 µε γραφικό περιβάλλον, αντελήφθησαν ότι θα πρέπει να βρουν νέες µεθόδους παρουσίασης του λογισµικού της. Επίσης αντελήφθησαν ότι οι χρήστες ήθελαν να έχουν την δυνατότητα να ανταλλάζουν δεδοµένα µεταξύ διαφόρων εφαρµογών και το clipboard µε τις λειτουργίες της αποκοπής, της αντιγραφής και της επικόλλησης αποτελούσε ένα βήµα προς αυτήν την κατεύθυνση. Όταν συνενώθηκαν κάποιες εφαρµογές υπό την σκέπη του Microsoft Office, τότε έγινε αντιληπτό ότι θα ήταν ιδιαίτερα χρήσιµο για τους χρήστες να έχουν την δυνατότητα να περιλαµβάνουν γραφήµατα, που δηµιούργησαν σε κάποιο φύλλο εργασίας, σε ένα έγγραφο του κειµενογράφου Word. Με την προοπτική αυτή δηµιουργήθηκε το 1992 το πρότυπο OLE (Object Linking and Embedding) έτσι ώστε να είναι δυνατή η υποστήριξη, από εφαρµογές, αντικειµένων που έχουν δηµιουργηθεί από άλλες εφαρµογές [Geraghty et al 99]. Το πρότυπο αυτό εφαρµόστηκε στην έκδοση 3.1 του λειτουργικού Windows. Όµως µε το OLE δηµιουργήθηκε η ανάγκη για ένα πρότυπο το οποίο θα προσδιόριζε το πώς θα µπορούσαν οι υπηρεσίες µίας εφαρµογής να αξιοποιούνται από κάποια άλλη εφαρµογή. Εάν δηλαδή χρειαζόµαστε κάποια λειτουργικά στοιχεία από µία µεγάλη εφαρµογή και όχι ολόκληρη τότε οι σχεδιαστές της εφαρµογής αυτής θα πρέπει να το γνωρίζουν έτσι ώστε να την σχεδιάσουν ανάλογα. Το µοντέλο COM γεννήθηκε για να λύσει ακριβώς αυτό το πρόβληµα. Οι προγραµµατιστές χρησιµοποιώντας το µοντέλο αυτό έχουν την δυνατότητα να αναπτύσσουν εφαρµογές οι οποίες να αποτελούνται από COM-αντικείµενα. Όταν µία εφαρµογή αποτελείται από διάφορα αντικείµενα λογισµικού τότε κάποιος τρίτος θα µπορούσε να 3

Κεφάλαιο 1 : Εισαγωγή χρησιµοποιήσει µόνο αυτά που επιθυµεί. Μία άλλη δυνατότητα είναι η επαναχρησιµοποίηση των αντικειµένων για το χτίσιµο µίας νέας εφαρµογής. Το πρόβληµα µε τα COM-αντικείµενα είναι ότι αυτά πρέπει να βρίσκονται στο ίδιο µηχάνηµα. Για την επίλυση του προβλήµατος η Microsoft επέκτεινε το COM µοντέλο σε µορφή κατανεµηµένου µοντέλου (Distributed COM DCOM) [Microsoft 98] βάσει του οποίου επιτρέπεται σε αντικείµενα να βρίσκονται σε διαφορετικά µηχανήµατα και να µπορούν να επικοινωνούν µεταξύ τους. 1.2.3 Sun Java RMI Η Java RMI (Remote Method Invocation) [Sun 98] αποτελεί άλλο ένα µοντέλο αντικειµενοστρεφούς σχεδιασµού µε σκοπό να προάγει την διαλειτουργικότητα µεταξύ Java αντικειµένων σε ένα κατανεµηµένο και ετερογενές περιβάλλον. Αναπτύχθηκε από την Sun και συµπεριλήφθηκε στην έκδοση 1.1 του εργαλείου ανάπτυξης της Java (Java Development Kit). Η RMI αποτελεί ένα µηχανισµό που επιτρέπει τις κλήσεις µεταξύ αντικειµένων σε διαφορετικά εικονικά µηχανήµατα Java. Από τη στιγµή που αποκτηθεί µία αναφορά σε ένα αποµακρυσµένο αντικείµενο τότε αυτό µπορεί να χρησιµοποιηθεί σαν να ήταν τοπικό. Η RMI εκτελεί όλες τις απαραίτητες διαδικασίες, που αφορούν το αποµακρυσµένο αντικείµενο, χωρίς αυτές να γίνονται αντιληπτές από τον προγραµµατιστή. Με τον τρόπο αυτό η ανάπτυξη κατανεµηµένων εφαρµογών Java αποτελεί ιδιαίτερα εύκολη υπόθεση. 1.3 Ασυµβατότητα Αντικειµένων Λογισµικού Όπως έχουµε αναφέρει, η ραγδαία ανάπτυξη των εξαρτηµάτων λογισµικού και τα πλεονεκτήµατα των εφαρµογών που βασίζονται σε εξαρτήµατα, έναντι των µονολιθικών εφαρµογών, οδήγησαν πολλές επιχειρήσεις να αναπτύξουν τις εφαρµογές των δικτύων τους βασιζόµενες στα εξαρτήµατα. Η χρήση τους όµως, παρόλο που ανοίγει νέες κατευθύνσεις, δηµιουργεί αναπόφευκτα και νέα προβλήµατα. Όπως είδαµε, τα εξαρτήµατα θα πρέπει να συµµορφώνονται µε συγκεκριµένες τεχνολογίες και αρχιτεκτονικές ενδιάµεσων (middleware architectures). Η εξάρτηση αυτή, όπως είναι φυσικό, δηµιουργεί προβλήµατα συµβατότητας µεταξύ εξαρτηµάτων τα οποία στηρίζονται πάνω σε διαφορετικές αρχιτεκτονικές ενδιαµέσων. Αυτά τα προβλήµατα γίνονται ιδιαίτερα κρίσιµα σε ευµετάβλητα πληροφοριακά συστήµατα εταιριών λόγω εξαγορών ή συγχωνεύσεων µε άλλες εταιρίες ή ακόµα και λόγω αναβάθµισης της υπάρχουσας υποδοµής των [Charles99]. Σε αυτό το σηµείο θα πρέπει να τονίσουµε ότι καθώς τα εξαρτήµατα λογισµικού αποτελούν παραδείγµατα των αντικειµένων λογισµικού, κάθε τι που εφαρµόζεται στα αντικείµενα έχει και άµεση επίπτωση στα εξαρτήµατα. Για το λόγο αυτό κάθε αναφορά σε αντικείµενα λογισµικού έχει κατά συνέπεια ανάλογη εφαρµογή και στα εξαρτήµατα. Για να είναι δυνατή η επικοινωνία των αντικειµένων θα πρέπει να συµµορφώνονται µε ένα µοντέλο ενδιαµέσου. Όµως είναι δύσκολο, εάν όχι ακατόρθωτο, για δύο αντικείµενα τα οποία στηρίζονται σε διαφορετικές υποκείµενες τεχνολογίες, να καταφέρουν να επικοινωνήσουν. Τα αίτια της 4

Κεφάλαιο 1 : Εισαγωγή ασυµβατότητας πηγάζουν από τις διαφορές των αρχιτεκτονικών ενδιαµέσων, στις οποία στηρίζονται, καθώς επίσης και στους διαφορετικούς τρόπους που αυτές παρουσιάζουν τα αντικείµενα αυτά. 1.3.1 ιαφορετικές προσεγγίσεις και υλοποιήσεις των διεπαφών Ένα από τα βασικά στοιχεία ενός αντικειµένου είναι οι διεπαφές του. Μέσω των διεπαφών τα αντικείµενα εκθέτουν την λειτουργικότητά τους. Μία διεπαφή αποτελείται από την περιγραφή µίας οµάδας λειτουργιών τις οποίες ένας πελάτης µπορεί να ζητήσει από ένα αντικείµενο. Ένας πελάτης επικοινωνεί µε την διεπαφή ενός αντικειµένου και ποτέ µε το ίδιο το αντικείµενο. Οι διεπαφές επιτρέπουν στα αντικείµενα να εµφανίζονται ως µαύρα κουτιά. ιαφορετικές προσεγγίσεις και υλοποιήσεις των διεπαφών κάνει τα αντικείµενα αόρατα από πελάτες διαφορετικής τεχνολογίας. 1.3.2 ιαφορετικές µέθοδοι αναφοράς σε αντικείµενα και φύλαξης αυτών Όταν ένας πελάτης επιθυµεί να επικοινωνήσει µε ένα αντικείµενο θα πρέπει πρώτα να αποκτήσει τις απαιτούµενες πληροφορίες για την διεπαφή του αντικειµένου. Ο πελάτης, µέσω της υποκείµενης τεχνολογίας του, θα πρέπει να είναι ικανός να αναγνωρίσει το όνοµα του αντικειµένου, να ξέρει που να ψάξει και πώς να ανακτήσει τις απαιτούµενες πληροφορίες αυτού. Θα πρέπει δηλαδή να ξέρει πως η υποκείµενη τεχνολογία του επιθυµητού αντικειµένου αποθηκεύει και διαδίδει τις πληροφορίες αυτές. Εάν η υποκείµενη τεχνολογία ενός πελάτη δεν έχει την δυνατότητα αυτή τότε είναι αδύνατο να βρεθούν οι απαραίτητες πληροφορίες του επιθυµητού αντικειµένου. 1.3.3 Χρήση διαφορετικών πρωτοκόλλων Ένα άλλο βασικό στοιχείο στην επικοινωνία µεταξύ κατανεµηµένων αντικείµενων είναι το πρωτόκολλο που χρησιµοποιείται για την µετάδοση των δεδοµένων. Στην περίπτωσή µας, το πρωτόκολλο µεταφοράς δεν αφορά µόνο στο κατώτερο πρωτόκολλο που χρησιµοποιείται στο επίπεδο µεταφοράς ενός δικτύου (Transport Layer) αλλά περιλαµβάνει και τα πρωτόκολλα που χρησιµοποιούνται και στα ανώτερα επίπεδα του δικτύου και συγκεκριµένα στα επίπεδα Presentation και Session, τα οποία υποστηρίζονται από τους εκάστοτε Request Brokers (RBs). 1.4 Γεφυρώνοντας το Χάσµα Από την πλευρά του κατασκευαστή λογισµικού, κάθε αντικείµενο λογισµικού κατασκευάζεται ακολουθώντας τους κανόνες της υποκείµενης γλώσσας προγραµµατισµού και της υποκείµενης τεχνολογίας στην οποία συµµορφώνονται. Τα βασικά στοιχεία τα οποία κάνουν τα αντικείµενα να υπόκεινται σε µία τεχνολογία είναι οι διεπαφές τους, η ονοµασία τους, ο τρόπος που αποθηκεύονται και ο τρόπος που αναφερόµαστε σε αυτά. Όταν απαιτείται αλληλεπίδραση µεταξύ δύο ή περισσοτέρων αντικειµένων, τα οποία βασίζονται σε διαφορετικές τεχνολογίες, ο βασικός στόχος είναι να µην γίνεται αντιληπτό από τα αντικείµενα το γεγονός ότι τα άλλα αντικείµενα 5

Κεφάλαιο 1 : Εισαγωγή λειτουργούν κάτω από µία διαφορετική τεχνολογία χωρίς βέβαια αυτό να επηρεάζει τα χαρακτηριστικά και την συµπεριφορά τους. Όταν ένα αντικείµενο επιθυµεί να επικοινωνήσει µε ένα άλλο θα πρέπει να είναι ικανό να βλέπει, να καταλαβαίνει και να δουλεύει µε την διεπαφή του άλλου προκειµένου να αιτηθεί τις απαιτούµενες µεθόδους. Κάθε τεχνολογία έχει τον δικό της τρόπο να δηµιουργεί τις διεπαφές των αντικειµένων χρησιµοποιώντας την δικιά της IDL. Για το λόγο αυτό, δύο τεχνολογίες για να επικοινωνήσουν θα πρέπει η µία να κατανοεί την IDL της άλλης. Προκειµένου να επιτευχθεί ο παραπάνω στόχος, θα πρέπει µεταξύ των διαφορετικών RBs να µεσολαβεί, κατά κάποιον τρόπο, ένας µηχανισµός ο οποίος θα είναι υπεύθυνος για την µετάφραση των αιτήσεων και των αποκρίσεων των διαφορετικών αντικειµένων έτσι ώστε να είναι κατανοητές από τα διαφορετικά άκρα χωρίς όµως να µεταβάλλει τα χαρακτηριστικά και την συµπεριφορά των επιµέρους αντικειµένων. Επίσης ο διαµεσολαβητής πρέπει να εφοδιάζεται µε τα χαρακτηριστικά εκείνα που θα του επιτρέπουν να εµφανίζεται στις επιµέρους τεχνολογίες ως ένα συµβατό αντικείµενο ώστε να είναι δυνατή η επικοινωνία µαζί του. Ουσιαστικά, ο διαµεσολαβητής θα πρέπει να υποστηρίζει έναν διπλό ρόλο, ως εξυπηρετητής ίδιας τεχνολογίας µε αυτήν του πραγµατικού πελάτη και οµοίως ως πελάτης της αυτής υποκείµενης τεχνολογίας του πραγµατικού εξυπηρετητή. Για να επιτευχθεί αυτός ο στόχος ο διαµεσολαβητής θα πρέπει να περιλαµβάνει στη δοµή του τα απαραίτητα χαρακτηριστικά των υπό γεφύρωση τεχνολογιών. 1.5 Οργάνωση της διατριβής Η παρούσα εργασία είναι ανεπτυγµένη σε οκτώ, συνολικά, κεφάλαια: Το παρόν πρώτο κεφάλαιο αποτελεί την εισαγωγή της παρούσας διατριβής. Στο δεύτερο κεφάλαιο, µε τίτλο Αντικείµενα και τεχνολογίες ενδιαµέσων, παραθέτουµε τις τρεις βασικές τεχνολογίες ενδιαµέσων στις οποίες επικεντρώνεται η έρευνά µας. Επίσης, συζητάµε για την διαλειτουργικότητα των αντικειµένων λογισµικού και αναφερόµαστε στις προσπάθειες που έχουν γίνει για την γεφύρωση των διαφορετικών τεχνολογιών. Στο τρίτο κεφάλαιο, Εφαρµογές CORBA, Java RMI & COM/DCOM, µελετάµε και παρουσιάζουµε την µεθοδολογία και αρχιτεκτονική ανάπτυξης εφαρµογών πελάτη-εξυπηρετητή σύµφωνα µε την κάθε τεχνολογία. Η παρουσίαση αυτή είναι απαραίτητη δεδοµένου ότι η συνέχεια της εργασίας µας θα βασιστεί στον τρόπο ανάπτυξης των επιµέρους εφαρµογών. Στην ενότητα 3.2 του κεφαλαίου, παραθέτουµε την γενίκευση του στόχου που έχουµε θέσει και παρουσιάζουµε τη γενική µορφή της αρχιτεκτονικής για την υλοποίηση του στόχου και καθορίζουµε το πλαίσιο των απαιτήσεων που θα πρέπει να ικανοποιούµε. 6

Κεφάλαιο 1 : Εισαγωγή Στο τέταρτο κεφάλαιο, Σχεδίαση υλοποίησης, παραθέτουµε την µεθοδολογία που θα ακολουθήσουµε για την διασύνδεση αντικειµένων διαφορετικών τεχνολογιών. Αναφερόµαστε στον µετασχηµατισµό των εφαρµογών που βασίζονται σε διαφορετικές τεχνολογίες και καθορίζουµε τα βήµατα ανάπτυξης της νέας µετασχηµατισµένης εφαρµογής που προκύπτει. Το πέµπτο κεφάλαιο, όπως υποδηλώνει και ο τίτλος του Υλοποίηση, αποτελεί την υλοποίηση των όσων καθορίσαµε στην πορεία των κεφαλαίων τρία και τέσσερα. Στο έκτο κεφάλαιο, Αξιολόγηση, παραθέτουµε την συνεισφορά των υλοποιήσεών µας στην διαλειτουργικότητα των αντικειµένων λογισµικού και δηλώνουµε τις παραδοχές µας κατά την πορεία της εργασίας. Επίσης, προχωρούµε στην αξιολόγηση των αποτελεσµάτων βάσει των απαιτήσεων που είχαµε θέσει στο τρίτο κεφάλαιο και βάσει των προδιαγραφών απαιτήσεων από το λογισµικό. Το έβδοµο κεφάλαιο, µε τίτλο Μελλοντική εργασία, καθορίζει τα πλαίσια µέσα στα οποία θα προχωρήσει η παρούσα έρευνα. Τέλος, το όγδοο κεφάλαιο αποτελεί την σύνοψη της παρούσας διατριβής. 7

Κεφάλαιο 2 : Αντικείµενα και τεχνολογίες ενδιαµέσων 2 Αντικείµενα και τεχνολογίες ενδιαµέσων Στο κεφάλαιο αυτό παραθέτουµε τις τρεις βασικότερες τεχνολογίες ενδιαµέσων που χρησιµοποιούνται για την επικοινωνία αποµακρυσµένων αντικειµένων λογισµικού σε ένα ετερογενές υπολογιστικό περιβάλλον. Προτού προχωρήσουµε στην αναλυτική παρουσίαση των τεχνολογιών αυτών, ορίζουµε συνοπτικά, στην εισαγωγή του παρόντος κεφαλαίου, τις έννοιες αρχιτεκτονική εφαρµογών πελάτη-εξυπηρετητή, αντικείµενα λογισµικού και αντικειµενοστρεφής προγραµµατισµός και την έννοια των εξαρτηµάτων λογισµικού. Στην συνέχεια του κεφαλαίου αναφερόµαστε στην διαλειτουργικότητα των αντικειµένων, τα οποία βασίζονται σε διαφορετικές τεχνολογίες ενδιαµέσων, παραθέτοντας τα κύρια σηµεία ασυµβατότητας και τις βασικότερες προσπάθειες που έχουν πραγµατοποιηθεί για την γεφύρωση των διαφορετικών µοντέλων ενδιαµέσων. 2.1 Εισαγωγή Η σύγχρονη ανάπτυξη του λογισµικού στηρίζεται, ουσιαστικά, σε δύο πολύ βασικές τεχνολογίες, σ αυτήν του πελάτη-εξυπηρετητή (client-server) και στην τεχνολογία του αντικειµενοστρεφούς προγραµµατισµού (object-oriented programming). Η αρχιτεκτονική πελάτη-εξυπηρετητή προτάσσει την ιδέα ενός πελάτη, ο οποίος είναι το calling module ενός µεγάλου τµήµατος λογισµικού και του εξυπηρετητή ο οποίος αποτελεί το called module και ο οποίος εκθέτει κάποιες υπηρεσίες, οι οποίες µπορεί να ζητηθούν από κάποιον πελάτη [Sinha 92]. Ορισµένα από τα οφέλη που πηγάζουν από την χρήση της αρχιτεκτονικής πελάτη-εξυπηρετητή σχετίζονται µε: την δυνατότητα του εξυπηρετητή να προσφέρει τις υπηρεσίες του σε πολλούς πελάτες ταυτόχρονα, ο εξυπηρετητής µπορεί να βρίσκεται στην ίδια τοποθεσία µε τον πελάτη ή κάπου αποµακρυσµένα στο δίκτυο, οι πελάτες και οι εξυπηρετητές αποτελούν ζεύγη τα οποία αλληλεπιδρούν µε ανταλλαγές µηνυµάτων ενώ, το ιδανικό λογισµικό που βασίζεται στην αρχιτεκτονική πελάτη-εξυπηρετητή είναι ανεξάρτητο από το υλικό ή το λειτουργικό σύστηµα [Karimi 99]. Η δεύτερη βασική τεχνολογία είναι αυτή του αντικειµενοστρεφούς προγραµµατισµού η οποία είναι οργανωµένη γύρω από τα αντικείµενα (objects) παρά γύρω από δράσεις (actions). Σύµφωνα µε τον Budd [Budd 91], όλα τα αντικείµενα είναι στιγµιότυπα κάποιας κλάσης η οποία και προσδιορίζει τις µεθόδους οι οποίες µπορεί να ζητηθούν προς υλοποίηση. Σε περίπτωση που έχουµε περισσότερα από ένα στιγµιότυπα µίας κλάσης τότε τα αντικείµενα αυτά κάνουν χρήση της ίδιας µεθόδου ως απόκριση σε παρόµοια µηνύµατα. Η τεχνική του αντικειµενοστρεφούς προγραµµατισµού προώθησε µία νέα προσέγγιση στην τεχνολογία του λογισµικού κατά την οποία αξιόπιστες εφαρµογές µπορούν να κατασκευαστούν, παρά να προγραµµατιστούν [Nierstrasz et al 92]. Η ανάγκη να κατασκευάζεται λογισµικό από υπάρχοντα κώδικα και όχι από την αρχή, οδήγησε στην ανάπτυξη λογισµικού βασιζόµενου στα εξαρτήµατα 8

Κεφάλαιο 2 : Αντικείµενα και τεχνολογίες ενδιαµέσων (component-based software) [Sametinger 97, Brown et al 98, Brown 99]. Με τη χρήση λογισµικού, το οποίο βασίζεται σε εξαρτήµατα, δίνεται η δυνατότητα στην σχεδίαση και ανάπτυξη συστηµάτων από στοιχεία εφαρµογών τα οποία προέρχονται από ανεξάρτητες πηγές, διαφορετικές γλώσσες προγραµµατισµού, εργαλεία και υπολογιστικές πλατφόρµες [Adler 95a]. Παρ όλου που το όνειρο για λογισµικό βασισµένο σε εξαρτήµατα ήταν αρκετά παλιό, µόνο στις αρχές της προηγούµενης δεκαετίας κάτι τέτοιο έδειχνε να είναι εφικτό [McIlroy 69]. Τα εξαρτήµατα είναι αντικειµενοστρεφή ή τουλάχιστον χρησιµοποιούνται όπως τα αντικείµενα λογισµικού. Ο Szyperski [Szyperski 98] ορίζει ένα εξάρτηµα λογισµικού ως µία µονάδα σύνθεσης µε ρητά καθορισµένες διεπαφές και σαφές πλαίσιο εξαρτήσεων. Είναι µία µονάδα λογισµικού η οποία µπορεί να αναπτυχθεί ανεξάρτητα και να αποτελέσει κοµµάτι σύνθεσης µίας εφαρµογής από τρίτους. Παρ όλου που τα εξαρτήµατα λογισµικού άνοιξαν νέους ορίζοντες στην ανάπτυξη των εφαρµογών, η χρήση τους αναπόφευκτα δηµιούργησε και νέα προβλήµατα. Τα εξαρτήµατα θα πρέπει συµµορφώνονται προς µία υποκείµενη τεχνολογία ενδιαµέσου έτσι ώστε να µπορούν να δουλεύουν µαζί. Αυτή η εξάρτηση δηµιουργεί προβλήµατα συµβατότητας µεταξύ εξαρτηµάτων που βασίζονται σε διαφορετικές τεχνολογίες. 2.2 Μοντέλα ενδιαµέσων Η ικανότητα να κατασκευάζονται εφαρµογές χρησιµοποιώντας αντικείµενα λογισµικού από διαφορετικές µεθοδολογίες, τα οποία τρέχουν σε διαφορετικά µηχανήµατα και βασίζονται σε διαφορετικά λειτουργικά συστήµατα, δεν είναι κάτι το εύκολο. Η ανάγκη για αλληλεπίδραση (interaction) µεταξύ των αντικειµένων αυτών οδήγησε στον προσδιορισµό των µοντέλων ενδιαµέσων (middleware models) [Martin 93, Plasil et al 98]. Τα µοντέλα των Object Management Group Common Object Request Broker Architecture (OMG CORBA) [OMG 95, OMG 98, OMG 99, Vinosky 93, Vinosky 97], Microsoft Component Object Model - Distributed Component Object Model (COM/DCOM) [Microsoft 95, Microsoft 96, Microsoft 98, Wallace 99] και Sun Java Remote Method Invocation (RMI) [Sun 96a, Sun 96b, Sun 96c, Sun 98, Sutherland 98], είναι τα τρία βασικότερα για την διεκπεραίωση µιας τέτοιας επικοινωνίας. Τι είναι όµως ένας ενδιάµεσος; Γενικά µιλώντας, ένας ενδιάµεσος εξυπηρετεί την επικοινωνία µεταξύ πελάτη και εξυπηρετητή ενός συστήµατος [Lewandowski 98]. Ουσιαστικά, ένας ενδιάµεσος περιγράφει ένα σύνολο από υπηρεσίες και πρωτόκολλα τα οποία υπάρχουν κάτω από τις εφαρµογές και παρέχουν υποστήριξη προς τις εφαρµογές αυτές [Clark et al 96]. Μεταφέροντας την γενική αυτή ερµηνεία στην περίπτωση της επικοινωνίας των αντικειµένων λογισµικού, ένα µοντέλο ενδιάµεσου προσφέρει τις κατάλληλες εκείνες διεπαφές, υπηρεσίες και πρωτόκολλα έτσι ώστε να είναι δυνατή η επικοινωνία µεταξύ αυτών των αντικειµένων. Τα τρία µοντέλα, τεχνολογίες, που προαναφέραµε και µε τα οποία ασχολούµαστε στην παρούσα διατριβή, εφαρµόζονται και στις περιπτώσεις κατανεµηµένων αντικειµένων (distributed objects). Αντικειµένων, δηλαδή, τα 9

Κεφάλαιο 2 : Αντικείµενα και τεχνολογίες ενδιαµέσων οποία βρίσκονται σε περισσότερους από έναν υπολογιστές και πιθανώς διασκορπισµένα σ ένα δίκτυο. Τι απαιτείται όµως, έτσι ώστε ένα αντικείµενο λογισµικού να καταστεί κατανεµηµένο; Θεωρείστε ότι έχουµε ένα αντικείµενο σε έναν εξυπηρετητή και το οποίο κατέχει κάποιες χρήσιµες λειτουργίες τις οποίες κάποιοι πελάτες µπορεί να ζητήσουν. Το αντικείµενο εξυπηρετητής θα πρέπει να είναι διαθέσιµο δηµόσια ώστε ένας αποµακρυσµένος πελάτης να µπορεί να το προσπελάσει. Επίσης, θα πρέπει να αναµένει πιθανές κλήσεις και όταν κάποιος πελάτης θελήσει να τον προσπελάσει τότε θα πρέπει να κάνει δικτυακές κλήσεις για να συνδεθεί µε τον εξυπηρετητή και να του περάσει τις αιτήσεις για τις ζητούµενες µεθόδους µε τέτοιο τρόπο ώστε να είναι κατανοητές από τον εξυπηρετητή. Παρατηρώντας από την πλευρά του πελάτη, αυτός θα πρέπει να γνωρίζει τον τρόπο µε τον οποίο πρέπει να απευθυνθεί στο αποµακρυσµένο αντικείµενο, να του αιτηθεί τις µεθόδους και να εξάγει τα αποτελέσµατα από την απάντηση που θα λάβει. Όµως η παραπάνω διαδικασία απαιτεί αρκετό προγραµµατισµό, σε δικτυακό επίπεδο, κάτι το οποίο δεν είναι επιθυµητό από τους προγραµµατιστές. Προκειµένου να απλοποιηθεί το πρόβληµα, ο προγραµµατιστής του αντικειµένου θα µπορούσε να περικλύσει όλες τις απαιτούµενες δικτυακές κλήσεις σε ένα αντικείµενο proxy το οποίο θα εµφανίζεται στον πελάτη ως το αντικείµενο εξυπηρετητής και το οποίο θα κάνει όλες τις κλήσεις προς το αποµακρυσµένο αντικείµενο. Με τον τρόπο αυτό ο κατασκευαστής του αντικειµένου πελάτη δεν χρειάζεται να ανησυχεί για θέµατα δικτυακού προγραµµατισµού. Με τον παραπάνω τρόπο έχει ολοκληρωθεί η κατασκευή ενός κατανεµηµένου αντικειµένου το οποίο µπορεί να τοποθετηθεί οπουδήποτε σε ένα δίκτυο και προσφέρει τις υπηρεσίες του σε αποµακρυσµένους πελάτες. Τα µοντέλα µε τα οποία ασχολούµαστε είναι αυτά τα οποία παρέχουν όλους τους απαιτούµενους µηχανισµούς για την ολοκλήρωση της παραπάνω διαδικασίας. Και τα τρία µοντέλα βασίζονται πάνω στην γενική µορφή της τεχνικής Remote Procedure Call (RPC) προκειµένου να επιτευχθεί η υποκείµενη δικτυακή επικοινωνία. Η τεχνική RPC µπορεί να περιγραφεί µε τον παρακάτω απλό τρόπο [Tanenbaum et al 85]. Ένας πελάτης καταθέτει µία κλήση στο µηχάνηµα που βρίσκεται, µε την προοπτική να επικαλεσθεί µία µέθοδο που βρίσκεται σε ένα αποµακρυσµένο µηχάνηµα. Στην συνέχεια, µία διεπαφή, η οποία ονοµάζεται stub, συλλέγει την κλήση του πελάτη και την µορφοποιεί σε ένα µήνυµα που θα µεταφερθεί στο δίκτυο και το οποίο έχει µία δεδοµένη µορφή. Τώρα, στην πλευρά του εξυπηρετητή υπάρχει µία ανάλογη διεπαφή skeleton η οποία συλλέγει το µορφοποιηµένο µήνυµα, το µεταφράζει και το προωθεί στο αντικείµενο εξυπηρετητής. Εν συνεχεία και µε αντίστροφο τρόπο η απάντηση του εξυπηρετητή επιστρέφει στο αντικείµενο πελάτης. Ουσιαστικά µε την τεχνική RPC ένα πρόγραµµα µπορεί να αιτηθεί µία υπηρεσία από ένα άλλο πρόγραµµα, το οποίο βρίσκεται σε έναν αποµακρυσµένο υπολογιστή, χωρίς να χρειάζεται να εµπλέκεται µε τις δικτυακές λεπτοµέρειες. 10

Κεφάλαιο 2 : Αντικείµενα και τεχνολογίες ενδιαµέσων 2.2.1 OMG CORBA Η OMG ιδρύθηκε τον Απρίλιο του 1989 από έντεκα εταιρίες, µεταξύ των οποίων οι 3Com Corporation, American Airlines, Canon Inc., Data General, Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems και Unisys Corporation. Σκοπός τους ήταν να συζητάνε τις σκέψεις τους για το µέλλον της τεχνολογίας των αντικειµένων. Σήµερα, η οµάδα αυτή αποτελείται από περισσότερες από 800 εταιρίες και οι δραστηριότητές της έχουν επικεντρωθεί στην τεχνολογία των κατανεµηµένων αντικειµένων και στην CORBA. Η CORBA δεν αποτελεί ένα εκτελέσιµο προϊόν αλλά ένας γνώµονας που πρέπει να ακολουθείται από κάποιον ο οποίος θέλει να κατασκευάσει έναν Object Request Broker (ORB). Ο στόχος που προσπαθεί να επιτευχθεί είναι, οι εφαρµογές να µπορούν να επικοινωνούν µεταξύ τους ανεξάρτητα µε το που βρίσκονται και από ποιον έχουν κατασκευαστεί. Η OMG δηµιούργησε µία ευρύτερη αρχιτεκτονική, την Object Management Architecture (OMA) [OMG 96, Martin 93], της οποίας η CORBA αποτελεί το κοµµάτι εκείνο που είναι υπεύθυνο για την λειτουργικότητα του ORB και περιλαµβάνει διάφορες υπηρεσίες, διεπαφές και αντικείµενα εφαρµογών. Σύµφωνα µε την OMA, κάθε εξάρτηµα λογισµικού αναπαρίσταται ως αντικείµενο. Ένα αντικείµενο είναι µία αναγνωρίσιµη οντότητα που δύναται να παρέχει µία ή περισσότερες υπηρεσίες και που µπορεί, επίσης, να αιτηθεί υπηρεσίες από ένα άλλο αντικείµενο. Στο σχήµα 2.1 απεικονίζεται η αρχιτεκτονική της OMA µε τα βασικά της µέρη [Vinoski 97]. Ο ρόλος της CORBA στην OMA είναι να προσδιορίζει το πώς θα πρέπει να υλοποιείται ένας ORB. ιεπαφή Εφαρµ ογής (Application Interface) ιεπαφή Πεδίου (Domain Interface) Κοινές Υπηρεσίες (Common Facilities) Object Request Broker Υπηρεσίες Αντικειµ ένου (Object Services) Σχήµα 2.1: Η αρχιτεκτονική της OMA Τι είναι όµως ένας Request Broker (RB); Γενικά µιλώντας, ένας RB είναι ένας µηχανισµός ελέγχου ο οποίος διαµεσολαβεί στην επικοινωνία µίας εφαρµογής 11

Κεφάλαιο 2 : Αντικείµενα και τεχνολογίες ενδιαµέσων πελάτη, η οποία επιθυµεί κάποιες υπηρεσίες και µίας εφαρµογής εξυπηρετητή, η οποία είναι ικανή να παράσχει τις υπηρεσίες αυτές. Ουσιαστικά οι RBs απαλλάσσουν τον πελάτη από το βάρος να διατηρούν πληροφορίες για το που και πώς να αποκτήσουν κάποιες επιθυµητές υπηρεσίες. Μπορούµε να διακρίνουµε τρία είδη RBs [Adler 95b]: Τον forwarding broker, ο οποίος µεταβιβάζει την αίτηση του πελάτη στην σχετική εφαρµογή εξυπηρέτησης, παραλαµβάνει την απάντηση και την µεταβιβάζει πίσω στον πελάτη. Η αρχιτεκτονική των CORBA και Java RMI βασίζεται σε αυτό το µοντέλο. Τον handle-driven broker, ο οποίος στην αίτηση που καταθέτει ένας πελάτης επιστρέφει ένα πακέτο πληροφοριών µε την βοήθεια τον οποίων ο πελάτης µπορεί να δράσει µε τον εξυπηρετητή της επιθυµητής υπηρεσίας. Η αρχιτεκτονική της DCOM βασίζεται σε αυτό το µοντέλο. Τον hybrid broker, ο οποίος υποστηρίζει δυναµικά και τα δύο παραπάνω µοντέλα δίνοντας την δυνατότητα στον πελάτη να προσδιορίσει, µε την αρχική κατάθεση της αίτησής του, ποιο µοντέλο θα χρησιµοποιηθεί. Η πρώτη έκδοση της CORBA (CORBA 1.0) έγινε δεκτή τον εκέµβριο του 1990 και στις αρχές του 1991 παρουσιάστηκε η CORBA 1.1. Με την έκδοση αυτή προσδιορίστηκαν: η γλώσσα ορισµού των διεπαφών (Interface Definition Language IDL) και η διεπαφή προγραµµατισµού εφαρµογής (Applicaton Programming Interface API). Με τα παραπάνω έγινε εφικτή η επικοινωνία, µε τη χρήση συγκεκριµένων υλοποιήσεων ORB, αντικειµένων τα οποία βασίζονταν σε διαφορετικές αρχιτεκτονικές και έτρεχαν σε διαφορετικά µηχανήµατα. Η CORBA 2.0 [OMG 95] έγινε δεκτή ως πρότυπο τον εκέµβριο του 1994. Με την έκδοση αυτή έγινε εφικτή η επικοινωνία µεταξύ ORB διαφορετικής προελεύσεως, δηλαδή µεταξύ ORB διαφορετικών κατασκευαστών. Αυτό έγινε εφικτό µε την παρουσίαση του πρωτοκόλλου Internet Inter-ORB Protocol (IIOP). Κάθε κατασκευαστής ο οποίος θα ήθελε να δηµιουργήσει έναν ORB συµβατό µε το πρότυπο της CORBA 2.0 θα έπρεπε να υποστηρίζει το πρωτόκολλο αυτό. Θα πρέπει να τονίσουµε ότι το πρωτόκολλο IIOP ορίζεται για δίκτυα που στηρίζονται στο πρωτόκολλο µεταφοράς TCP/IP. Κατά καιρούς ακολούθησαν και άλλες εκδόσεις του προτύπου της CORBA, οι οποίες αποτελούσαν ενηµερώσεις των προηγουµένων και υπήρχαν και επιµέρους προσθήκες. Η τελευταία έκδοση της CORBA, η 3.0, ενισχύει τις προηγούµενες εκδόσεις µε τρία νέα χαρακτηριστικά: την ολοκλήρωση της CORBA µε την Java και το διαδίκτυο (Internet), την ποιότητα του ελέγχου των υπηρεσιών και την αρχιτεκτονική για εξαρτήµατα βασιζόµενα στην CORBA [Siegel 99]. Υπάρχουν αρκετές υλοποιήσεις των προδιαγραφών της CORBA, ορισµένες εµπορικές και άλλες ελεύθερες. Οι διαφορές που υπάρχουν µεταξύ των υλοποιήσεων αυτών αφορούν την συµµόρφωσή τους σε διαφορετικές εκδόσεις και την υποστήριξή τους στις υπηρεσίες της CORBA. 12

Κεφάλαιο 2 : Αντικείµενα και τεχνολογίες ενδιαµέσων 2.2.1.1 ORB Χρησιµοποιώντας έναν ORB, ένα αντικείµενο πελάτης µπορεί να επικαλεσθεί µία µέθοδο σ ένα αντικείµενο εξυπηρετητή το οποίο µπορεί να βρίσκεται στο ίδιο µηχάνηµα ή ακόµα και σε κάποιο άλλο µηχάνηµα στο δίκτυο (σχήµα 2.2). Ο ORB λαµβάνει την κλήση αυτή και είναι υπεύθυνος να βρει το αντικείµενο εξυπηρετητής, το οποίο µπορεί να απαντήσει στην αίτηση του πελάτη, να του περάσει τις απαιτούµενες παραµέτρους, να επικαλεσθεί την αιτούµενη µέθοδο και τέλος να επιστρέψει στον πελάτη τα αποτελέσµατα. Σε όλη αυτή την διαδικασία, ο πελάτης δεν απασχολείται µε το που βρίσκεται το αποµακρυσµένο αντικείµενο, την γλώσσα προγραµµατισµού του, το λειτουργικό του σύστηµα ή οποιαδήποτε άλλα χαρακτηριστικά του συστήµατος [Martin 93]. Πελάτης Client Αντικείµενο Εξυπηρετητής Object Implementation Αποκρίσεις Αιτήσεις ORB Σχήµα 2.2: Η διαµεσολάβηση του ORB µεταξύ πελάτη & εξυπηρετητή Ας δούµε τα κύρια στοιχεία που συνθέτουν την αρχιτεκτονική της CORBA τα οποία µπορούµε να διακρίνουµε στο σχήµα 2.3. 13

Κεφάλαιο 2 : Αντικείµενα και τεχνολογίες ενδιαµέσων Πελάτης Αναφορά Αντικειµένου Αντικείµενο Εξυπηρετητής Αποθήκη ιεπαφών Αποθήκη Υλοποίησης ιεπαφή δυναµικής επίκλησης Στατική διεπαφή IDL Stubs ιεπαφή του ORB Στατική διεπ IDL Skeleton υναµική διεπαφή Skeleton Object Adapter Πυρήνας του ORB ιεπαφή ανεξάρτητη του ORB Συγκεκριµένες διεπαφές stubs & skeletons Υπάρχει η δυνατότητα πολλαπλών Object Adapters ιεπαφή εξαρτώµενη από τον ORB Σχήµα 2.3: Η αρχιτεκτονική της CORBA 2.2.1.1.1 Στην πλευρά του πελάτη Η διεπαφή IDL stub παρέχει στον πελάτη, σε στατική µορφή, την διεπαφή του αποµακρυσµένου αντικείµενου εξυπηρετητή. Ουσιαστικά προσδιορίζει το πώς ο πελάτης µπορεί να επικαλεσθεί τις µεθόδους του εξυπηρετητή. Από την πλευρά του πελάτη η διεπαφή stub του δίνει την δυνατότητα να καταθέσει µία τοπική κλήση και λειτουργεί ως µία εικόνα του αποµακρυσµένου αντικειµένου εξυπηρετητή. Τόσο η stub, από την πλευρά του πελάτη, όσο και η διεπαφή skeleton, από την πλευρά του εξυπηρετητή, δηµιουργούνται µέσω της εφαρµογής κατάλληλου µεταφραστή επί µίας διεπαφής που έχει γραφτεί µε την χρήση της IDL, προκειµένου να προσδιοριστούν οι µέθοδοι που είναι διαθέσιµες καθώς και ο τρόπος που θα πρέπει να ζητηθούν. Επιπλέον, η stub εµπεριέχει και τον απαιτούµενο κώδικα για την µορφοποίηση (marshaling) του µηνύµατος του πελάτη. Αυτό σηµαίνει ότι κωδικοποιεί την αίτηση του πελάτη σε µία τέτοια µορφή που αυτή µπορεί να µεταφερθεί µέσα από το δίκτυο στο αποµακρυσµένο αντικείµενο. Αντίστοιχα και µε αντίστροφη ροή, αποκωδικοποιεί την απάντηση του εξυπηρετητή και την προωθεί στον πελάτη. Όλη η παραπάνω διαδικασία πραγµατοποιείται χωρίς να γίνεται αντιληπτή από τον χρήστη. Η διεπαφή δυναµικής επίκλησης (Dynamic Invocation Interface DII) δίνει τη δυνατότητα να ανακαλυφθεί µία µέθοδος που θα επιθυµούσε το αντικείµενο πελάτης όταν αυτό εκτελείται και χωρίς προηγουµένως να υπάρχει κάποια διεπαφή της µορφής IDL stub. 14