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

Transcript

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

2

3 Πίνακας περιεχοµένων Πίνακας περιεχοµένων... iii Σχήµατα...v Πίνακες...vi 1 Αντικείµενα και τεχνολογίες ενδιαµέσων Εισαγωγή Μοντέλα ενδιαµέσων OMG CORBA ORB Στην πλευρά του πελάτη Στην πλευρά του εξυπηρετητή Αναφορές προς αντικείµενα Μοντέλο επικοινωνίας Γλώσσα ορισµού διεπαφών Μέθοδος στατικής επίκλησης Μέθοδος δυναµικής επίκλησης ιεπαφή δυναµικής επίκλησης ιεπαφή δυναµικού skeleton Object Adapter Microsoft COM/DCOM ιεπαφές Μοντέλο επικοινωνίας Γλώσσα ορισµού διεπαφών της Microsoft υαδικό πρότυπο και απεικονίσεις προς διαφορετικές γλώσσες Λειτουργία της COM/DCOM Sun Java RMI Λειτουργία του συστήµατος Java RMI Μοντέλο επικοινωνίας ιαλειτουργικότητα αντικειµένων Ασυµβατότητα αντικειµένων λογισµικού ιαφορετικές προσεγγίσεις και υλοποιήσεις των διεπαφών ιαφορετικές µέθοδοι αναφοράς σε αντικείµενα και φύλαξης αυτών Χρήση διαφορετικών πρωτοκόλλων Γεφυρώνοντας το χάσµα Γεφύρωση µεταξύ CORBA-COM/DCOM Γεφύρωση µεταξύ CORBA-Java RMI Γεφύρωση µεταξύ COM/DCOM-Java RMI Σύνοψη Εφαρµογές CORBA, Java RMI & COM/DCOM Εισαγωγή Κατασκευή εφαρµογών πελάτη-εξυπηρετητή µε χρήση των CORBA, Java RMI και COM/DCOM Κατασκευή εφαρµογής πελάτη-εξυπηρετητή µε CORBA Κατασκευή της διεπαφής Μετάφραση της διεπαφής Κατασκευή του εξυπηρετητή iii

4 Μετάφραση του εξυπηρετητή Κατασκευή του πελάτη Μετάφραση του πελάτη Εκτέλεση της εφαρµογής Κατασκευή εφαρµογής πελάτη-εξυπηρετητή µε Java RMI Κατασκευή της διεπαφής Κατασκευή του εξυπηρετητή Κατασκευή του πελάτη Εκτέλεση της εφαρµογής Κατασκευή εφαρµογής πελάτη-εξυπηρετητή µε COM/DCOM Κατασκευή της διεπαφής Εξαγωγή της βιβλιοθήκης τύπων Κατασκευή κλάσης υλοποίησης Καταχώρηση της κλάσης υλοποίησης Κατασκευή του πελάτη Εκτέλεση της εφαρµογής Μοντέλο συνένωσης Java/COM Ανάπτυξη εξυπηρετητή COM µε την χρήση της Java Κατασκευή πελάτη COM µε την χρήση της Java Χρήση εξαρτήµατος COM ως Java Γενίκευση Σύνοψη...70 Βιβλιογραφικές αναφορές & πηγές...71 ηµοσιευµένα άρθρα - Παρουσιάσεις...71 Τεχνικά δελτία - Προδιαγραφές...75 Βιβλία...78 Πίνακας Ακρώνυµων...79 iv

5 Σχήµατα Σχήµα 1.1: Η αρχιτεκτονική της OMA...11 Σχήµα 1.2: Η διαµεσολάβηση του ORB µεταξύ πελάτη & εξυπηρετητή...13 Σχήµα 1.3: Η αρχιτεκτονική της CORBA...14 Σχήµα 1.4: ράση πελάτη-εξυπηρετητή µέσω COM/DCOM...22 Σχήµα 1.5: Επικοινωνία πελάτη-εξυπηρετητή µέσω διεπαφής...23 Σχήµα 1.6: Αρχιτεκτονική συστήµατος Java RMI...28 Σχήµα 1.7: ροµολόγηση αιτήσεων-αποκρίσεων στο σύστηµα Java RMI...28 Σχήµα 2.1: Ανάπτυξη εφαρµογής CORBA...42 Σχήµα 2.2: Τα παραγόµενα αρχεία από την διεπαφή SumInt µέσω του µεταφραστή jidl...45 Σχήµα 2.3: Ανάπτυξη εφαρµογής Java RMI...51 Σχήµα 2.4: Ανάπτυξη εφαρµογής COM/DCOM...59 Σχήµα 2.5: Μοντέλο συνένωσης Java/COM...66 Σχήµα 2.6: Χρήση εξαρτήµατος COM ως Java...69 v

6 Πίνακες Πίνακας 1.1: Απεικονίσεις βασικών τύπων CORBA IDL/Java [Orfali et al 98]...17 Πίνακας 1.2: Απεικονίσεις κατασκ. τύπων CORBA IDL/Java [Orfali et al 98]18 Πίνακας 1.3: Απεικονίσεις βασικών τύπων Microsoft IDL/Java [Orfali et al 98]...25 Πίνακας 1.4: Βασικές διαφορές µεταξύ CORBA/DCOM/RMI...34 Πίνακας 2.1: Επεκτάσεις αρχείων τα οποία δύναται να εµπεριέχουν βιβλιοθήκες τύπων...62 vi

7 vii

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

9 Κεφάλαιο 1 : Αντικείµενα και τεχνολογίες ενδιαµέσων (component-based software) [Sametinger 97, Brown et al 98, Brown 99]. Με τη χρήση λογισµικού, το οποίο βασίζεται σε εξαρτήµατα, δίνεται η δυνατότητα στην σχεδίαση και ανάπτυξη συστηµάτων από στοιχεία εφαρµογών τα οποία προέρχονται από ανεξάρτητες πηγές, διαφορετικές γλώσσες προγραµµατισµού, εργαλεία και υπολογιστικές πλατφόρµες [Adler 95a]. Παρ όλου που το όνειρο για λογισµικό βασισµένο σε εξαρτήµατα ήταν αρκετά παλιό, µόνο στις αρχές της προηγούµενης δεκαετίας κάτι τέτοιο έδειχνε να είναι εφικτό [McIlroy 69]. Τα εξαρτήµατα είναι αντικειµενοστρεφή ή τουλάχιστον χρησιµοποιούνται όπως τα αντικείµενα λογισµικού. Ο Szyperski [Szyperski 98] ορίζει ένα εξάρτηµα λογισµικού ως µία µονάδα σύνθεσης µε ρητά καθορισµένες διεπαφές και σαφές πλαίσιο εξαρτήσεων. Είναι µία µονάδα λογισµικού η οποία µπορεί να αναπτυχθεί ανεξάρτητα και να αποτελέσει κοµµάτι σύνθεσης µίας εφαρµογής από τρίτους. Παρ όλου που τα εξαρτήµατα λογισµικού άνοιξαν νέους ορίζοντες στην ανάπτυξη των εφαρµογών, η χρήση τους αναπόφευκτα δηµιούργησε και νέα προβλήµατα. Τα εξαρτήµατα θα πρέπει συµµορφώνονται προς µία υποκείµενη τεχνολογία ενδιαµέσου έτσι ώστε να µπορούν να δουλεύουν µαζί. Αυτή η εξάρτηση δηµιουργεί προβλήµατα συµβατότητας µεταξύ εξαρτηµάτων που βασίζονται σε διαφορετικές τεχνολογίες. 1.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

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

11 Κεφάλαιο 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) Σχήµα 1.1: Η αρχιτεκτονική της OMA Τι είναι όµως ένας Request Broker (RB); Γενικά µιλώντας, ένας RB είναι ένας µηχανισµός ελέγχου ο οποίος διαµεσολαβεί στην επικοινωνία µίας εφαρµογής 11

12 Κεφάλαιο 1 : Αντικείµενα και τεχνολογίες ενδιαµέσων πελάτη, η οποία επιθυµεί κάποιες υπηρεσίες και µίας εφαρµογής εξυπηρετητή, η οποία είναι ικανή να παράσχει τις υπηρεσίες αυτές. Ουσιαστικά οι 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] έγινε δεκτή ως πρότυπο τον εκέµβριο του Με την έκδοση αυτή έγινε εφικτή η επικοινωνία µεταξύ 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

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

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

15 Κεφάλαιο 1 : Αντικείµενα και τεχνολογίες ενδιαµέσων Η αποθήκη διεπαφών (Interface Repository IR) δίνει τη δυνατότητα να αποκτηθούν περιγραφές των διεπαφών των αντικείµενων εξυπηρετητών που έχουν καταχωρηθεί. Μέσω των περιγραφών αυτών ανακτώνται πληροφορίες για τις µεθόδους που υποστηρίζονται από τους εξυπηρετητές καθώς και οι παράµετροι που αυτές οι µέθοδοι απαιτούν. Η IR αποτελεί µία βάση δεδοµένων η οποία είναι διαθέσιµη κατά τον χρόνο εκτέλεσης. Η διεπαφή του ORB (ORB Interface) αποτελείται από ορισµένες διεπαφές APIs (Application Programming Interfaces) τοπικών υπηρεσιών, που προσφέρονται από τον ORB, και οι οποίες µπορεί να ενδιαφέρουν µία εφαρµογή. Για παράδειγµα η CORBA παρέχει APIs προκειµένου να µετατραπεί µία αναφορά προς αντικείµενο (object reference) σε αλφαριθµητικό (string) και αντιστρόφως, κάτι το οποίο είναι ιδιαίτερα χρήσιµο όταν θέλουµε, για παράδειγµα, να αποθηκεύσουµε τέτοιου είδους αναφορές Στην πλευρά του εξυπηρετητή Η διεπαφή server skeleton παρέχει στατικές διεπαφές προς τις µεθόδους οι οποίες µπορεί να ζητηθούν, εξ αποστάσεως, σε ένα αντικείµενο εξυπηρετητής. Η διεπαφή αυτή συµπεριφέρεται ως µία εικόνα του πελάτη στην πλευρά του εξυπηρετητή. Αντίστοιχα µε την διεπαφή stub του πελάτη και αυτή η διεπαφή δηµιουργείται µέσω του IDL µεταφραστή. Η διεπαφή Dynamic Skeleton Interface (DSI) παρέχει έναν µηχανισµό µέσω του οποίου διαχειρίζονται, κατά τον χρόνο εκτέλεσης της εφαρµογής, αιτήσεις προς αντικείµενα εξυπηρετητές τα οποία δεν έχουν τις αντίστοιχες διεπαφές skeleton. Η διεπαφή DSI παρατηρεί τις παραµέτρους των εισερχοµένων µηνυµάτων και ψάχνει να βρει σε ποιο εξυπηρετητή αναφέρονται. Η διεπαφή DSI είναι η αντίστοιχη DII διεπαφή του πελάτη από την πλευρά του εξυπηρετητή. Ο object adapter βρίσκεται πάνω από τις υπηρεσίες επικοινωνίας που παρέχει ο ORB και δέχεται τις εισερχόµενες κλήσεις εκ µέρους του εξυπηρετητή. Η αποθήκη υλοποίησης (Implementation Repository) αποτελεί την πηγή απ όπου, κατά τον χρόνο εκτέλεσης, παρέχονται πληροφορίες για τα αντικείµενα εξυπηρετητές, τα οποία έχουν ενεργοποιηθεί και τις ταυτότητές τους. Όπως και στην πλευρά του πελάτη έτσι και εδώ υπάρχει η διεπαφή του ORB (ORB Interface) η οποία λειτουργεί όµοια µε την αντίστοιχή της στην πλευρά του πελάτη Αναφορές προς αντικείµενα Όταν ένα αντικείµενο πελάτης θέλει να αιτηθεί µία µέθοδο, που υλοποιείται από ένα άλλο αντικείµενο, το πρώτο που θα πρέπει να αποκτήσει είναι µία αναφορά προς το αντικείµενο αυτό. Ο ORB έχει ως σκοπό να υπηρετήσει τέτοιου είδους αιτήσεις, για αναφορές προς αντικείµενα, έτσι ώστε να βοηθήσει να πραγµατοποιηθεί η επικοινωνία πελάτη και εξυπηρετητή. Σε µία κατανεµηµένη εφαρµογή υπάρχουν δύο πιθανότητες προκειµένου να φτάσουµε το αντικείµενο εξυπηρετητής που βρίσκεται σε κάποια άλλη διεργασία, η µία είναι µε πέρασµα µέσω αναφοράς (passing by reference) και η άλλη είναι µε πέρασµα µέσω αξίας (passing by value). Στην πρώτη περίπτωση το αντικείµενο 15

16 Κεφάλαιο 1 : Αντικείµενα και τεχνολογίες ενδιαµέσων πελάτης στέλνει µόνο την αναφορά του προς το αποµακρυσµένο αντικείµενο. Στην δεύτερη περίπτωση το αντικείµενο περνάει, κατά κάποιο τρόπο, στην αποµακρυσµένη διεργασία. Ουσιαστικά αυτό που συµβαίνει είναι ότι µέσω του περάσµατος αυτού υπάρχει η δυνατότητα να δηµιουργηθεί στιγµιότυπο του αντικειµένου στην αποµακρυσµένη διεργασία. Σε καµία περίπτωση όµως δεν δύναται να µεταβληθεί η κατάσταση του αντικειµένου. Προκειµένου ένα αντικείµενο να περάσει µέσα από ένα δίκτυο by value, θα πρέπει να υποστεί µία τέτοια µορφοποίηση (serialization) έτσι ώστε να είναι δυνατή αυτή η µεταφορά και η εν συνεχεία κατασκευή στιγµιότυπου στην αποµακρυσµένη διεργασία. Συνήθως είναι ευθύνη του προγραµµατιστή να γράψει τον κώδικα µέσω του οποίου γίνεται αυτή η µορφοποίηση και από-µορφοποίηση του αντικειµένου αλλά υπάρχουν και περιπτώσεις όπου γλώσσες προγραµµατισµού, όπως η Java, έχουν έµφυτη αυτή τη δυνατότητα Μοντέλο επικοινωνίας Οι προδιαγραφές που καθορίζονται µε την CORBA είναι ανεξάρτητες από το δικτυακό πρωτόκολλο που χρησιµοποιείται. Το πρότυπο της CORBA προσδιορίζει το General Inter-ORB Protocol (GIOP) το οποίο, σε υψηλότερο επίπεδο, προσδιορίζει έναν γνώµονα για την επικοινωνία µεταξύ διαφορετικών CORBA ORBs και εξαρτηµάτων. Επιπλέον, µέσω του προτύπου της CORBA καθορίζονται και άλλα πρωτόκολλα τα οποία ουσιαστικά αποτελούν εξιδανικεύσεις του GIOP µε πρωτόκολλα επικοινωνίας του επιπέδου µεταφοράς (transport layer). Υπάρχουν, για παράδειγµα, εκδόσεις του GIOP τα οποία στηρίζονται στο TCP/IP και στο Distributed Computing Environment (DCE), της Open Software Foundation (OSF), όπως τo Internet Inter-ORB Protocol (IIOP) και το DCE Environment-Specific Inter-ORB Protocol (DCE ESIOP) αντίστοιχα. Στις προδιαγραφές της έκδοσης 2.0 της CORBA απαιτείται να υλοποιείται, τουλάχιστον, το IIOP πρωτόκολλο προκειµένου ένας ORB να είναι συµβατός µε το πρότυπο της CORBA 2.0 [OMG 95]. Οι εφαρµογές της CORBA είναι ανεπτυγµένες πάνω από ένα πρωτόκολλο το οποίο βασίζεται στο GIOP, όπως για παράδειγµα το IIOP, το οποίο µε τη σειρά του βρίσκεται πάνω από το πρωτόκολλο µεταφοράς του δικτύου είτε αυτό είναι το TCP/IP, το DCE ή οποιοδήποτε άλλο. Βέβαια το πρότυπο της CORBA παρέχει τις κατάλληλες προδιαγραφές προκειµένου να υπάρχει σύνδεση CORBA-εφαρµογών οι οποίες µπορεί να στηρίζονται πάνω σε διαφορετικές υλοποιήσεις πρωτοκόλλων Γλώσσα ορισµού διεπαφών Η IDL είναι η γλώσσα η οποία χρησιµοποιείται για να οριστεί η διεπαφή µεταξύ διαφορετικών εξαρτηµάτων. Θα πρέπει να διευκρινιστεί ότι δεν αποτελεί γλώσσα προγραµµατισµού, χρησιµοποιείται µόνο για προσδιορισµό. Ο προσδιορισµός µέσω της IDL είναι απαραίτητος προκειµένου να υπάρχει η βεβαιότητα της σωστής ανταλλαγής δεδοµένων µεταξύ διαφορετικών γλωσσών προγραµµατισµού. Η OMG έχει ορίσει απεικονίσεις της IDL προς διάφορες γλώσσες προγραµµατισµού: C, C++, Smalltalk, Cobol, Ada, Java. Τύποι CORBA IDL Τύποι Java 16

17 Κεφάλαιο 1 : Αντικείµενα και τεχνολογίες ενδιαµέσων Τύποι CORBA IDL Boolean Char Wchar Octet String wstring Short unsigned short Long unsigned long long long unsigned long long Float double Fixed Τύποι Java boolean char char byte java.lang.string java.lang.string short short Int Int long long float double java.math.bigdecimal Πίνακας 1.1: Απεικονίσεις βασικών τύπων CORBA IDL/Java [Orfali et al 98] Τα βασικά στοιχεία της CORBA IDL είναι τα εξής: Το module το οποίο παρέχει έναν τρόπο οµαδοποίησης ενός συνόλου διεπαφών µίας κλάσης. Η διεπαφή (interface) ορίζει ένα σύνολο λειτουργιών που ένας πελάτης µπορεί να ζητήσει από ένα αντικείµενο εξυπηρετητή. Ως διεπαφή µπορεί να νοηθεί µία κλάση η οποία ορίζει κάποιες λειτουργίες χωρίς όµως να παρέχει υλοποίηση. Μία διεπαφή η οποία βασίζεται στην CORBA IDL µπορεί να προέλθει από µία άλλη ή περισσότερες διεπαφές. Αυτό δηλώνει την υποστήριξη της IDL στην πολλαπλή κληρονοµικότητα των διεπαφών. Μία λειτουργία (operation) δηλώνει αυτό το κάτι το οποίο µπορεί να ζητηθεί από έναν πελάτη. Μέσω της IDL προσδιορίζονται οι παράµετροι της µεθόδου καθώς και τα αποτελέσµατα που επιστρέφονται. Μία παράµετρος χαρακτηρίζεται από µία κατάσταση η οποία δηλώνει ότι είτε η αξία της µπορεί να περάσει από τον πελάτη στον εξυπηρετητή, οπότε και χαρακτηρίζεται in, είτε από τον εξυπηρετητή στον πελάτη, οπότε και χαρακτηρίζεται ως out, είτε µπορούν να συµβαίνουν και τα δύο παραπάνω όπότε και χαρακτηρίζεται ως both. Όλες οι παράµετροι έχουν έναν τύπο µέσω του οποίου δηλώνεται η µορφή των τιµών τους. 17

18 Κεφάλαιο 1 : Αντικείµενα και τεχνολογίες ενδιαµέσων Οι τύποι δεδοµένων (data types) χρησιµοποιούνται προκειµένου να προσδιορισθούν οι µορφές που µπορούν να έχουν οι παράµετροι, οι µεταβλητές ή οι επιστρεφόµενες τιµές. Οι τύποι αυτοί των δεδοµένων αποτελούν αντικείµενα της CORBA για τα οποία υπάρχουν απεικονίσεις βάσει των οποίων µπορούν να χρησιµοποιηθούν από διάφορες γλώσσες προγραµµατισµού, σε διάφορα λειτουργικά συστήµατα και σε διάφορους ORBs. Στην CORBA υπάρχουν δύο είδη τύπων δεδοµένων: οι βασικοί (basic) και οι κατασκευασµένοι (constructed). Στους βασικούς τύπους διακρίνουµε τους: short, long, double, char, boolean. Κατασκευασµένοι τύποι είναι οι: string, struct, array. Για π.χ. ο IDL τύπος long είναι ένας ακέραιος αριθµός 32-bits ο οποίος αντιστοιχεί στον αντίστοιχο int της γλώσσας προγραµµατισµού Java ή στον τύπο long της C++. Τύποι CORBA IDL Interface Sequence Array Struct Enum Union Typedef - Any Τύποι Java interface array array κλάση Java µε το όνοµα της struct κλάση Java µε το όνοµα της struct κλάση Java µε το όνοµα της struct org.omg.corba.any Πίνακας 1.2: Απεικονίσεις κατασκ. τύπων CORBA IDL/Java [Orfali et al 98] Μέθοδος στατικής επίκλησης Η µέθοδος στατικής επίκλησης (static method invocation) δηλώνει την δυνατότητα να χρησιµοποιούνται διεπαφές stub και skeleton, οι οποίες έχουν δηµιουργηθεί µέσω του IDL µεταφραστή (compiler), για την διενέργεια κλήσεων µεθόδων, σε αντίθεση µε την δυνατότητα που υπάρχει να παρέχεται αυτή η λειτουργικότητα δυναµικά κατά το χρόνο εκτέλεσης. Τα βήµατα που χρησιµοποιούνται προκειµένου να δηµιουργηθούν όλα τα βασικά στοιχεία από την πλευρά του εξυπηρετητή είναι: 1. Καθορίζουµε τις απαραίτητες κλάσεις µέσω της IDL. Ουσιαστικά καθορίζουµε τις διεπαφές του εξυπηρετητή µε την χρήση της IDL. Μέσω αυτών ένα αντικείµενο εξυπηρετητής κοινοποιεί στους πελάτες ποιες λειτουργίες είναι διαθέσιµες και πως µπορούν να τις ζητήσουν. 2. Εφαρµόζουµε τον κατάλληλο IDL µεταφραστή σε σχέση µε την γλώσσα προγραµµατισµού στην οποία θέλουµε να εργαστούµε. 3. Γράφουµε τον κώδικα υλοποίησης των µεθόδων. 18

19 Κεφάλαιο 1 : Αντικείµενα και τεχνολογίες ενδιαµέσων 4. Εφαρµόζουµε τον µεταφραστή της γλώσσας προγραµµατισµού που χρησιµοποιούµε στα παραπάνω παραγόµενα αρχεία. 5. ηµιουργούµε στιγµιότυπα των αντικειµένων εξυπηρετητών. 6. Πραγµατοποιείται η καταχώρηση των ενεργοποιηµένων αντικειµένων στην αποθήκη υλοποίησης. Εκεί ο object adapter καταγράφει πληροφορίες για αναφορές αντικειµένων, στιγµιότυπα αντικειµένων καθώς επίσης και ποιες κλάσεις υπάρχουν σε συγκεκριµένους εξυπηρετητές. Τις πληροφορίες αυτές τις χρησιµοποιεί ο ORB προκειµένου να εντοπίζει τα αντικείµενα Μέθοδος δυναµικής επίκλησης Μέσω της µεθόδου δυναµικής επίκλησης (dynamic method invocation) γίνεται εφικτή η επικοινωνία αντικειµένου πελάτη µε αποµακρυσµένο αντικείµενο σε περιπτώσεις που δεν είναι δυνατή η χρήση στατικών διεπαφών τύπου stub και skeleton. Αντί αυτών, απαιτείται η χρήση δυναµικών διεπαφών προκειµένου να είναι εφικτή η επικοινωνία του πελάτη και του εξυπηρετητή µε τον ORB ιεπαφή δυναµικής επίκλησης Είναι δυνατό να αναπτυχθεί ένα αντικείµενο πελάτης, χωρίς τη χρήση διεπαφών stub από την πλευρά του, χρησιµοποιώντας διεπαφή δυναµικής επίκλησης DII. Με τον τρόπο αυτό δίνεται η δυνατότητα στον πελάτη να αιτηθεί µέθοδο κάποιου αντικειµένου εξυπηρετητή το οποίο ήταν άγνωστο όταν προγραµµατιζόταν το αντικείµενο πελάτης. Ένας πελάτης ο οποίος χρησιµοποιεί στατική επίκληση δηλώνει εξαρχής τον τύπο του αντικειµένου που προτίθεται να επικαλεσθεί κάτι το οποίο δεν γίνεται στην περίπτωση της δυναµικής επίκλησης. Το πλεονέκτηµα της δυναµικής επίκλησης είναι η ευελιξία που δίνεται στον πελάτη να επικαλεσθεί οποιοδήποτε αντικείµενο εξυπηρετητή. Τα µειονεκτήµατα που συναντάµε µε την δυναµική επίκληση είναι: ο δύσκολος προγραµµατισµός, δεδοµένου ότι η απουσία των stub πρέπει να καλυφθεί µε εισαγωγή επιπλέον κώδικα στον πελάτη µέσω του οποίου θα γίνεται η προώθηση της κλήση και η µορφοποίησή της προς τον ORB. Επιπλέον οι επικλήσεις είναι πιο αργές, διότι κατά τον χρόνο εκτέλεσης πραγµατοποιούνται επιπρόσθετες εργασίες αναζήτησης. Η χρήση διεπαφής δυναµικής επίκλησης, από την πλευρά του πελάτη, είναι ανεξάρτητη από τη χρήση αντίστοιχης δυναµικής ή στατικής διεπαφής στο περιβάλλον του εξυπηρετητή ιεπαφή δυναµικού skeleton Όπως έχουµε αναφέρει, η διεπαφή DSI παρέχει έναν µηχανισµό µέσω του οποίου διαχειρίζονται, κατά τον χρόνο εκτέλεσης της εφαρµογής, αιτήσεις προς αντικείµενα εξυπηρετητές τα οποία δεν έχουν τις αντίστοιχες στατικές διεπαφές skeleton. Όπως και στην περίπτωση της διεπαφής δυναµικής επίκλησης του πελάτη, έτσι και εδώ απαιτείται µεγαλύτερη προσπάθεια στον προγραµµατισµό προκειµένου να καλυφθεί η έλλειψη στατικού skeleton. 19

20 Κεφάλαιο 1 : Αντικείµενα και τεχνολογίες ενδιαµέσων Object Adapter Προκειµένου να έχουµε πρόσβαση σε κάποιο αντικείµενο εξυπηρετητή χρειαζόµαστε ένα µηχανισµό που να το καταχωρεί, να δηµιουργεί στιγµιότυπα, να τους δίνει ταυτότητα και να επικαλείται τις µεθόδους όταν οι πελάτες το αιτηθούν. Ο object adapter είναι υπεύθυνος ακριβώς γι αυτές τις εργασίες. Είναι ο κύριος µηχανισµός για ένα αντικείµενο εξυπηρετητής προκειµένου να έχει επικοινωνία µε τον ORB. Η CORBA προσδιορίζει έναν βασικό object adapter (Basic Object Adapter BOA) και απαιτεί να είναι διαθέσιµος σε κάθε ORB. Ο BOA παρέχει ένα ελάχιστο σύνολο λειτουργικότητας, βάσει αυτών που προαναφέραµε, και αυτό έχει ως συνέπεια να µπορούν να προστεθούν στον object adapter, ανάλογα µε τις υποκειµενικές ανάγκες, και άλλες λειτουργίες προκειµένου να υποστηρίζονται πιο πολύπλοκες απαιτήσεις. Η διαδικασία αυτή όµως δηµιουργεί προβλήµατα συµβατότητας στις υλοποιήσεις εξυπηρετητών µεταξύ διαφορετικών ORB. Στην CORBA 2.2, [OMG 98], προσδιορίστηκε ένας νέος object adapter, ο Portable Object Adapter (POA) ο οποίος υποστηρίζει περισσότερες λειτουργίες προκειµένου να εκπληρώνει περισσότερες απαιτήσεις Microsoft COM/DCOM Η αρχιτεκτονική Component Object Model (COM) [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-αντικείµενα. Όταν µία εφαρµογή αποτελείται από διάφορα αντικείµενα λογισµικού τότε κάποιος τρίτος θα µπορούσε να 20

21 Κεφάλαιο 1 : Αντικείµενα και τεχνολογίες ενδιαµέσων χρησιµοποιήσει µόνο αυτά που επιθυµεί. Μία άλλη δυνατότητα είναι η επαναχρησιµοποίηση των αντικειµένων για το χτίσιµο µίας νέας εφαρµογής. Το πρόβληµα µε τα COM-αντικείµενα είναι ότι αυτά πρέπει να βρίσκονται στο ίδιο µηχάνηµα. Για την επίλυση του προβλήµατος η Microsoft επέκτεινε το COM µοντέλο σε µορφή κατανεµηµένου µοντέλου (Distributed COM DCOM) [Microsoft 98] βάσει του οποίου επιτρέπεται σε αντικείµενα να βρίσκονται σε διαφορετικά µηχανήµατα και να µπορούν να επικοινωνούν µεταξύ τους. Το επόµενο βήµα της Microsoft ήταν η παρουσίαση της ActiveX προδιαγραφής για την ανάπτυξη DCOM-αντικειµένων και χρήση αυτών µέσα από το διαδίκτυο. Αντίστοιχα µε την περίπτωση της CORBA, η τελευταία έκδοση της COM, η COM+ [Eddon 99], εµπλουτίζει την προηγούµενη µε νέα χαρακτηριστικά και υπηρεσίες: just-in-time activation, object pooling, load balancing, in-memory databases, κ.α.. Όπως προαναφέραµε, η διαφορά ανάµεσα στην COM και στην DCOM είναι ουσιαστικά και εν συντοµία, ότι η δεύτερη επιτρέπει στα αντικείµενα να βρίσκονται σε διαφορετικά και αποµακρυσµένα µηχανήµατα. Το γεγονός αυτό, από πλευράς προγραµµατισµού, δεν συνεπάγεται ότι υπάρχει διαφορά στην ανάπτυξη του κώδικα. Η επιπλέον εργασία που απαιτείται αφορά στην καταχώρηση των αντικειµένων στα αποµακρυσµένα µηχανήµατα και η διαµόρφωση των εξουσιοδοτήσεων προσπέλασης προτού εκτελεστεί η εφαρµογή. 21

22 Κεφάλαιο 1 : Αντικείµενα και τεχνολογίες ενδιαµέσων ιεργασία Πελάτη Εφαρµογή Πελάτης Εσωτερικό (inprocess) Αντικείµενο Εσωτερικός Εξυπηρετητής ιεργασία Τοπικού Εξυπηρετητή Stub Τοπικό Αντικείµενο Τοπική διεπαφή Proxy RPC COM Τοπικός Εξυπηρετητής COM Τοπική διεπαφή Proxy Αποµακρυσµένο Μηχάνηµα ιεργασία Αποµακρυσµένου Εξυπηρετητή RPC Stub Αποµακρυσµένο Αντικείµενο COM Αποµακρυσµένος Εξυπηρετητής Σχήµα 1.4: ράση πελάτη-εξυπηρετητή µέσω COM/DCOM Στο σχήµα 2.4 απεικονίζεται ένα αντικείµενο πελάτης σε µία διεργασία να προσπελαύνει ένα αντικείµενο εξυπηρετητή σε µία άλλη διεργασία. Θα πρέπει να τονίσουµε ότι η ορολογία που χρησιµοποιείται από την COM/DCOM, για να ορίσει τα διάφορα µέρη της αρχιτεκτονικής, δεν είναι ακριβώς η ίδια µε την αντίστοιχη της CORBA. Η διεπαφή που καλείται stub στην CORBA, στην COM/DCOM καλείται proxy ενώ η αντίστοιχη skeleton της CORBA καλείται stub στην COM/DCOM. Όταν ο πελάτης ενεργοποιεί ένα αντικείµενο εξυπηρετητή, η COM/DCOM εγκαθιστά την proxy στην διεύθυνση του πελάτη και το stub στην διευθυνση του εξυπηρετητή. Η proxy επικοινωνεί µε την stub και µορφοποιεί τις κλήσεις του πελάτη µέσα στο δίκτυο. Οι κλήσεις του πελάτη προς τις αιτούµενες µεθόδους υλοποιούνται βασιζόµενες στο πρωτόκολλο του µηχανισµού RPC. Στα Windows NT [Microsoft 96] το πρωτόκολλο που χρησιµοποιείται συνήθως είναι το User Datagram Protocol (UDP). Ουσιαστικά µε την τεχνική RPC ένα πρόγραµµα µπορεί να αιτηθεί µία υπηρεσία από ένα άλλο πρόγραµµα, το οποίο βρίσκεται σε έναν αποµακρυσµένο υπολογιστή, χωρίς να χρειάζεται να εµπλέκεται µε τις δικτυακές λεπτοµέρειες ιεπαφές Στις εφαρµογές που βασίζονται στην COM/DCOM, η αλληλεπίδραση πραγµατοποιείται µέσω των διεπαφών. Η διεπαφή είναι µία συλλογή από 22

23 Κεφάλαιο 1 : Αντικείµενα και τεχνολογίες ενδιαµέσων µεθόδους τις οποίες υποστηρίζει το αντικείµενο εξυπηρετητής και οι οποίες µπορούν να ζητηθούν από έναν πελάτη. Κάθε διεπαφή έχει την δικιά της ταυτότητα Global Unique Identifier (GUID) η οποία είναι ένας ακέραιος αριθµός 128-bit για τον οποίο η αρχιτεκτονική εγγυάται ότι είναι µοναδικός µε αποτέλεσµα να µην υπάρχει πιθανότητα διαφορετικών διεπαφών µε την ίδια ταυτότητα. Οι διεπαφές στην COM/DCOM δεν µπαίνουν σε σειρά εκδόσεως. Όταν πραγµατοποιούνται αλλαγές σε µία διεπαφή, είτε προσθέτοντας, είτε αφαιρώντας, είτε αλλάζοντας κάποια στοιχεία σε µία λειτουργία, τότε αυτή θεωρείται µία εντελώς νέα διεπαφή και της αντιστοιχίζεται µία νέα ταυτότητα GUID. Τα αντικείµενα µπορούν να υλοποιούν περισσότερες από µία διεπαφές. Ένα άλλο όφελος είναι ότι µπορούµε να ορίσουµε µία νέα διεπαφή, ή να επεκτείνουµε µία υπάρχουσα, χωρίς να απαιτείται να κάνουµε αλλαγές στην εφαρµογή η οποία µπορεί να συνεχίσει να υποστηρίζει και την παλαιά διεπαφή. Όταν ένας πελάτης έχει πρόσβαση σ ένα αντικείµενο, αυτό σηµαίνει ότι ο πελάτης έχει έναν δείκτη, ο οποίος καλείται δείκτης διεπαφής (interface pointer), µέσω του οποίου µπορεί να προσπελάσει τις λειτουργίες που ορίζονται στην διεπαφή. Στην COM/DCOM ένας πελάτης µπορεί να έχει πρόσβαση µόνο στις λειτουργίες που καθορίζονται σε µία διεπαφή και για την οποία έχει τον απαραίτητο δείκτη και σε καµία περίπτωση δεν µπορεί να έχει πρόσβαση σε εσωτερικές πληροφορίες του αντικείµενου µέσω του δείκτη αυτού (σχήµα 2.5). Εφαρµογή Πελάτης είκτης ιεπαφής ιεπαφή Αντικειµένου Αντικείµενο Σχήµα 1.5: Επικοινωνία πελάτη-εξυπηρετητή µέσω διεπαφής Υπάρχει µία διεπαφή η οποία απαιτεί ιδιαίτερη προσοχή και αυτή είναι η IUnknown. Αυτή είναι µία βασική διεπαφή την οποία θα πρέπει να υποστηρίζουν όλα τα αντικείµενα εξυπηρετητές της COM/DCOM τεχνολογίας. Όταν ένας πελάτης αποκτήσει πρόσβαση σ ένα αντικείµενο εξυπηρετητή τότε θα λάβει, το λιγότερο, έναν δείκτη για την συγκεκριµένη διεπαφή µέσω της οποίας µπορεί να ελέγξει τον κύκλο ζωής του εξυπηρετητή και να επικαλεσθεί µία µέθοδο την QueryInterface. Η συγκεκριµένη µέθοδος είναι µία βασική λειτουργία της COM/DCOM τεχνολογίας µέσω της οποίας ο πελάτης προσδιορίζει τις διεπαφές που υποστηρίζονται από ένα αντικείµενο εξυπηρετητή. Εάν το αντικείµενο εξυπηρετητής υποστηρίζει την επιθυµητή διεπαφή τότε επιστρέφει έναν δείκτη γι αυτήν. Σε αντίθετη περίπτωση επιστρέφει το κενό (null). 23

24 Κεφάλαιο 1 : Αντικείµενα και τεχνολογίες ενδιαµέσων Μοντέλο επικοινωνίας Το πρωτόκολλο που χρησιµοποιείται από την DCOM για την αποµακρυσµένη επικοινωνία βασίζεται πάνω στον µηχανισµό DCE RPC. Η Open Software Foundation (OSF) όρισε το περιβάλλον κατανεµηµένου προγραµµατισµού (Distributed Computing Environment DCE). To DCE παρέχει ένα σύνολο από υπηρεσίες όπως υπηρεσίες ασφάλειας (security), καταλόγου (directory services) και κλήσεις αποµακρυσµένων διαδικασιών (Remote Procedure Calls RPC). Μέσω του µηχανισµού DCE RPC ορίζεται ένα API για κλήσεις αποµακρυσµένων συναρτήσεων από έναν πελάτη σ έναν εξυπηρετητή που βρίσκονται σε διαφορετικά µηχανήµατα. Ο προγραµµατιστής µπορεί να καθορίσει τις συναρτήσεις που θα κληθούν µέσω του µηχανισµού RPC, µέσω της γλώσσας ορισµού διεπαφών IDL, που καθορίζεται από το DCE. Η IDL της Microsoft, για τον ορισµό των COM/DCOM διεπαφών, βασίζεται στην DCE IDL. Παρ όλου που ο µηχανισµός DCE RPC δεν υποστηρίζει από µόνος του αντικείµενα λογισµικού, µπορεί να χρησιµοποιηθεί ως υποκείµενος µηχανισµός για κατανεµηµένα αντικείµενα. Στα Windows και στο Solaris η τεχνολογία DCOM βασίζεται στο Microsoft RPC που αποτελεί µία συµβατή υλοποίηση του DCE RPC Γλώσσα ορισµού διεπαφών της Microsoft εν θα πρέπει να συγχέουµε την γλώσσα ορισµού διεπαφών της Microsoft (Microsoft Interface Definition Language MIDL) µε την αντίστοιχη IDL της CORBA, η οποία αποτελεί µία εντελώς διαφορετική γλώσσα. Οι διεπαφές των αντικείµενων εξυπηρετητών καθορίζονται µέσω της MIDL η οποία δεν αποτελεί κοµµάτι της αρχιτεκτονικής COM/DCOM αλλά ένα εργαλείο για τον καθορισµό των διεπαφών. Παρ όλου που δεν είναι απαραίτητη η χρήση της MIDL για τον ορισµό των διεπαφών, η δηµιουργία του απαραίτητου κώδικα χωρίς την χρήση της αποτελεί ένα δύσκολο έργο. Η MIDL αποτελεί επέκταση της DCE IDL, η οποία µε την σειρά της βασίζεται στην γλώσσα προγραµµατισµού C. Τύποι Microsoft IDL Boolean Char Double Int int64 Float Long Short Unsigned char wchar_t Τύποι Java Boolean Char Double Int Long Float Int short byte short 24

25 Κεφάλαιο 1 : Αντικείµενα και τεχνολογίες ενδιαµέσων Τύποι Microsoft IDL BSTR CURRENCY DΑΤΕ SCODE/HRESULΤ VARIANT IDispatch Iunkown SAFEARRAY Void LPSTR Τύποι Java java.lang.string long double Int com.ms.com.variant java.lang.object com.ms.com.iunkown com.ms.com.safearray void iava.lang.string Πίνακας 1.3: Απεικονίσεις βασικών τύπων Microsoft IDL/Java [Orfali et al 98] Παράλληλα µε την MIDL υπάρχει και µία δεύτερη γλώσσα προσδιορισµού των διεπαφών, η Object Description Language (ODL). Σε αντίθεση µε την MIDL, η οποία πηγάζει ουσιαστικά από την γλώσσα προγραµµατισµού C, η ODL είναι πιο ανεξάρτητη και εισάγει µία πιο γενική σύνταξη για την περιγραφή των εξαρτηµάτων [Orfali et al 98]. εδοµένων των δύο αυτών γλωσσών προσδιορισµού, υπάρχουν αντίστοιχα και δύο εργαλεία µετάφρασης των πηγαίων αρχείων MIDL και ODL και αυτά είναι τα midl και mktyplib υαδικό πρότυπο και απεικονίσεις προς διαφορετικές γλώσσες Η DCOM επικοινωνία βασίζεται σ ένα δυαδικό πρότυπο το οποίο ορίζει το πώς θα πρέπει να παρουσιάζονται οι διεπαφές. Αυτό σηµαίνει ότι τα αντικείµενα µπορούν να υλοποιούνται σε οποιαδήποτε γλώσσα προγραµµατισµού αρκεί αυτή να παρέχει την δυνατότητα υποστήριξης δεικτών προς τις λειτουργίες που ορίζονται σε µία διεπαφή. Για παράδειγµα, τόσο η C++ όσο και η Java ή η Visual Basic είναι ιδανικές γλώσσες για COM/DCOM προγραµµατισµό. Η ανεξαρτησία ως προς τις γλώσσες προγραµµατισµού επιτυγχάνεται δίνοντας τη δυνατότητα στα αντικείµενα εξυπηρετητές να παρέχουν βιβλιοθήκες τύπων (type libraries) δεδοµένου ότι οι περισσότερες γλώσσες µπορούν να προσπελάσουν αυτές τις βιβλιοθήκες και τα αντικείµενα που περιγράφουν. Οι βιβλιοθήκες δηµιουργούνται από τον µεταφραστή της MIDL και αποθηκεύονται σε αρχείο µε επέκταση.tlb ή εµπεριέχονται σ ένα εκτελέσιµο αρχείο,.exe, ή σε αρχείο της µορφής.dll. Μία βιβλιοθήκη µπορεί να θεωρηθεί ως µία δυαδική έκδοση, MIDL αρχείου, το οποίο περιγράφει όλες τις διεπαφές που υποστηρίζονται από ένα αντικείµενο, όλες τις µεθόδους και τις παραµέτρους των µεθόδων αυτών. Θα πρέπει να τονιστεί ότι δεδοµένου η τεχνολογία COM/DCOM βασίζεται σε µία δυαδική φόρµα, τα αντικείµενα που αναπτύσσονται βάσει αυτής δεν είναι ανεξάρτητα της πλατφόρµας πάνω στην οποία χρησιµοποιούνται. Είτε θα 25

26 Κεφάλαιο 1 : Αντικείµενα και τεχνολογίες ενδιαµέσων πρέπει να επαναχρησιµοποιηθεί κάποιος µεταφραστής για συγκεκριµένη πλατφόρµα, είτε θα πρέπει να χρησιµοποιηθεί κάποιος µεταφραστής από την δυαδική µορφή. Η χρησιµοποίηση της δυαδικής φόρµας µπορεί να έχει ως πλεονέκτηµα την ταχύτερη εκτέλεση αλλά δηµιουργεί, ταυτόχρονα, και εξάρτηση αναφορικά µε την πλατφόρµα που χρησιµοποιείται Λειτουργία της COM/DCOM Προκειµένου να πραγµατοποιηθεί επικοινωνία µεταξύ αντικειµένου πελάτη και αντικειµένου εξυπηρετητή, απαιτούνται πέντε βασικά βήµατα: 1. Ο πελάτης καλεί αρχικά την µέθοδο CoCreateInstance(CLSID) όπου η παράµετρος CLSID αποτελεί την ταυτότητα της κλάσης (Class Identification) του αντικειµένου εξυπηρετητή το οποίο υποστηρίζει την διεπαφή την οποία επιθυµεί ο πελάτης. 2. Εν συνεχεία, η COM/DCOM συνεργάζεται µε τη διεργασία Service Control Manager (SCM) και προσδιορίζει εάν το πρόγραµµα εξυπηρετητής είναι ενεργοποιηµένο και µπορεί να συνδεθεί µ αυτό. 3. Εάν το πρόγραµµα εξυπηρετητής είναι ενεργοποιηµένο, τότε ο πελάτης λαµβάνει έναν δείκτη προς την επιθυµητή διεπαφή από το αντικείµενο εξυπηρετητής. 4. Εάν δεν υπάρχει στιγµιότυπο της ζητούµενης κλάσης τότε ένας νέος εξυπηρετητής ενεργοποιείται και ένα στιγµιότυπο του αντικειµένου εξυπηρετητή δηµιουργείται. 5. Ο πελάτης λαµβάνει τον επιθυµητό δείκτη από το αντικείµενο εξυπηρετητής. Η SCM αποτελεί µία διεργασία σκοπός της οποίας είναι να εντοπίσει τις υλοποιήσεις ή τα στιγµιότυπα της επιθυµητής κλάσης. Προκειµένου να το επιτύχει, η διεργασία αναζητά µέσα στην καταχώρηση του συστήµατος (system registry) όπου όλες οι CLSIDs βρίσκονται αποθηκευµένες, είτε αφορούν τοπικά είτε αποµακρυσµένα αντικείµενα. Από τη στιγµή που ο πελάτης συνδεθεί µ ένα COM αντικείµενο αυτό σηµαίνει ότι έχει έναν δείκτη διεπαφής και µ αυτόν µπορεί ν αποκτήσει κι άλλους δείκτες διεπαφών του αντικειµένου αυτού. Όταν ο πελάτης επικαλεσθεί κάποιες µεθόδους τότε η COM/DCOM είναι υπεύθυνη για την µεταφορά όλων των απαραίτητων παραµέτρων από την διεργασία του πελάτη στην διεργασία του εξυπηρετητή. Η µεταφορά αυτή υλοποιείται µε την χρήση του µηχανισµού DCE RPC ο οποίος έχει αρκετά ενδιαφέροντα χαρακτηριστικά όπως ότι λειτουργεί οµοιόµορφα είτε µεταξύ διεργασιών στο ίδιο µηχάνηµα είτε µεταξύ διεργασιών σε διαφορετικά µηχανήµατα σ ένα δίκτυο. Επίσης έχει την δυνατότητα να χειριστεί κλήσεις διεργασιών και µεταξύ µηχανηµάτων µε διαφορετικές αρχιτεκτονικές υλικού και διαφορετικά λειτουργικά συστήµατα. 26

27 Κεφάλαιο 1 : Αντικείµενα και τεχνολογίες ενδιαµέσων Sun Java RMI Η Java Remote Method Invocation (RMI) [Sun 98] αποτελεί άλλο ένα µοντέλο αντικειµενοστρεφούς σχεδιασµού µε σκοπό να προάγει την διαλειτουργικότητα µεταξύ Java αντικειµένων σε ένα κατανεµηµένο περιβάλλον µε ετερογενή (heterogeneous) µηχανήµατα. Αναπτύχθηκε από την Sun και συµπεριλήφθηκε στην έκδοση 1.1 του εργαλείου ανάπτυξης της Java (Java Development Kit). Η RMI αποτελεί ένα µηχανισµό που επιτρέπει τις κλήσεις µεταξύ αντικειµένων σε διαφορετικά εικονικά µηχανήµατα Java. Από τη στιγµή που αποκτηθεί µία αναφορά σε ένα αποµακρυσµένο αντικείµενο τότε αυτό µπορεί να χρησιµοποιηθεί σαν να ήταν τοπικό αντικείµενο. Η RMI εκτελεί όλες τις απαραίτητες λειτουργίες που αφορούν το αποµακρυσµένο αντικείµενο µε διαφανή τρόπο, ώστε να µην γίνονται αντιληπτές από τον προγραµµατιστή, κάνοντας έτσι την ανάπτυξη κατανεµηµένων Java εφαρµογών ιδιαίτερα εύκολη υπόθεση. Η λειτουργική δοµή του µοντέλου ακολουθεί την κλασική δοµή της αρχιτεκτονικής πελάτη-εξυπηρετητή όπου ένας πελάτης επιθυµεί κάποιες λειτουργίες ενός αντικειµένου, καταθέτει την αίτησή του προς τον εξυπηρετητή και συλλέγει τις αποκρίσεις. Μία βασική διαφορά από τα άλλα δύο µοντέλα είναι ότι οποιοσδήποτε πελάτης είναι ένας Java πελάτης και οποιοδήποτε αντικείµενο εξυπηρετητής είναι ένα Java και µόνο Java αντικείµενο. Για τον λόγο αυτό το µοντέλο, το οποίο είναι αποκλειστικά Java-κεντρικό, µπορεί να εκµεταλλευτεί το οµοιογενές περιβάλλον της γλώσσας προγραµµατισµού Java χωρίς την ανάγκη ύπαρξης κάποιας ιδιαίτερης γλώσσας ορισµού των διεπαφών και γενικότερα χωρίς τα προβλήµατα που πηγάζουν από την επικοινωνία πολύ-γλωσσικών αντικειµένων. Η αρχιτεκτονική ενός συστήµατος Java RMI ακολουθεί την δοµή των επιπέδων, όπως φαίνεται και στο σχήµα 2.6. Υπάρχουν τρία επίπεδα: το επίπεδο των διεπαφών stub / skeleton (Stub/Skeleton Layer - SSL), το επίπεδο αποµακρυσµένης αναφοράς (Remote Reference Layer - RRL), το επίπεδο µεταφοράς (Transport Layer - TL). Θα πρέπει να προσθέσουµε ότι υπάρχει άλλο ένα επίπεδο, το επίπεδο εφαρµογής (Application Layer), το οποίο δεν αποτελεί ένα καθαρό τµήµα ενός συστήµατος RMI και βρίσκεται πάνω από τα τρία προαναφερθέντα. 27