Προγραμματισμός

RMI πάνω από το IIOP

Τι είναι το RMI πάνω από το IIOP;

Το RMI over IIOP (RMI-IIOP εφεξής), που αναπτύχθηκε από κοινού από την IBM και την Sun, είναι μια νέα έκδοση του RMI (Remote Method Invocation) για το IIOP (Internet Inter-ORB Protocol) που συνδυάζει τις εύκολες δυνατότητες προγραμματισμού του RMI με τη διαλειτουργικότητα της CORBA. Αυτή η νέα έκδοση του RMI κυκλοφόρησε επίσημα τον Ιούνιο και διατέθηκε ελεύθερα από τον ιστότοπο της Sun (ανατρέξτε στην ενότητα Πόροι παρακάτω για πληροφορίες σχετικά με το πού μπορείτε να το κατεβάσετε). Η εφαρμογή αναφοράς Sun εκτελείται σε Windows 9x / NT και Solaris. Είναι μια τυπική επέκταση που υποστηρίζει τόσο το JDK 1.1.6 όσο και την πλατφόρμα Java 2.

Η RMI και η CORBA έχουν αναπτυχθεί ανεξάρτητα ως μοντέλα προγραμματισμού κατανεμημένων αντικειμένων. Το RMI, ένα θεμέλιο των τεχνολογιών EJB και Jini, εισήχθη ως μοντέλο προγραμματισμού που βασίζεται σε Java, εύκολο στη χρήση για κατανεμημένα αντικείμενα. Το CORBA (το Common Object Request Broker Architecture), που ορίζεται από το OMG (Object Management Group), είναι ένα πολύ γνωστό μοντέλο προγραμματισμού κατανεμημένων αντικειμένων που υποστηρίζει διάφορες γλώσσες. Το πρωτόκολλο IIOP συνδέει προϊόντα CORBA από διαφορετικούς προμηθευτές, εξασφαλίζοντας διαλειτουργικότητα μεταξύ τους. Το RMI-IIOP είναι, κατά μία έννοια, ένας γάμος της RMI και της CORBA.

Για τους σκοπούς αυτού του άρθρου, υποθέτουμε ότι είστε ήδη εξοικειωμένοι με τα βασικά στοιχεία της CORBA. Εάν χρειάζεστε περαιτέρω βοήθεια για να φτάσετε στην ταχύτητα, υπάρχει ένας χρήσιμος σύνδεσμος στην ενότητα Πόροι παρακάτω.

Πριν από το RMI-IIOP

Δείτε το σχήμα 1 παρακάτω. Το διάστημα πάνω από την κεντρική οριζόντια γραμμή αντιπροσωπεύει τον αρχικό τομέα του RMI. η κάτω περιοχή αντιπροσωπεύει τον κόσμο των CORBA και IIOP. Αυτοί οι δύο ξεχωριστοί κόσμοι, που έχουν αναπτυχθεί ανεξάρτητα, δεν ήταν ιστορικά ικανοί να επικοινωνούν μεταξύ τους. Για παράδειγμα, το εγγενές πρωτόκολλο του RMI, το JRMP (Java Remote Method Protocol), δεν μπορεί να συνδεθεί με άλλα πρωτόκολλα.

Εάν η μόνη γλώσσα προγραμματισμού που χρειάζεστε σε ένα νέο έργο είναι η Java, η χρήση RMI και JRMP - ένας συνδυασμός που αναφέρεται ως RMI (JRMP) για το υπόλοιπο αυτού του άρθρου - παραδοσιακά ήταν η καλύτερη επιλογή. Σε αντίθεση με το CORBA, το οποίο απαιτεί τη χρήση της μάλλον περίπλοκης γλώσσας ορισμού διεπαφής (IDL), το RMI (JRMP) προσφέρει εύκολο προγραμματισμό για τους λάτρεις της Java. Το CORBA, από την άλλη πλευρά, επιτρέπει τον προγραμματισμό κατανεμημένων αντικειμένων σε διαφορετικές πλατφόρμες και διαφορετικές γλώσσες προγραμματισμού. Οι προγραμματιστές χρειάζονται προγραμματισμό κατανεμημένων αντικειμένων όχι μόνο για νέα έργα, αλλά και για χρήση πόρων λογισμικού παλαιού τύπου. Φυσικά, το λογισμικό παλαιού τύπου προγραμματίζεται στις περισσότερες περιπτώσεις σε άλλες γλώσσες εκτός από την Java. Σε τέτοιες περιπτώσεις, οι προγραμματιστές χρειάζονται CORBA και όχι RMI (JRMP).

Έτσι έχουμε το κεντρικό μας δίλημμα: το RMI (JRMP) έχει το πλεονέκτημα του εύκολου προγραμματισμού, ενώ το CORBA παρέχει διαλειτουργικότητα μεταξύ πολλών γλωσσών προγραμματισμού σε διάφορες πλατφόρμες. Δυστυχώς, ωστόσο, δεν υπήρχε παραδοσιακά τρόπος να χρησιμοποιηθούν και οι δύο αυτές εξαιρετικές τεχνολογίες. Αυτό φαίνεται από το διάγραμμα στο Σχήμα 2, στο οποίο ένας κύκλος σημαίνει μια κατάσταση στην οποία ένας πελάτης μπορεί να καλέσει έναν διακομιστή και ένα X σημαίνει μια περίπτωση στην οποία αυτό δεν είναι δυνατό

Το καλύτερο και των δύο κόσμων

Κάποτε ήταν δύσκολο να επιλέξετε μεταξύ RMI (JRMP) και CORBA κατά την έναρξη ενός νέου έργου. Εάν επιλέξατε RMI (JRMP), έχετε εύκολο προγραμματισμό, αλλά χάσατε τη διαλειτουργικότητα σε πολλές γλώσσες. Εάν επιλέξατε CORBA, έχετε διαλειτουργικότητα, αλλά αντιμετωπίσατε μια πιο τρομακτική εργασία προγραμματισμού. Τόσο οι χρήστες RMI (JRMP) όσο και οι χρήστες CORBA, κουρασμένοι από τη λήψη αυτής της απόφασης, έχουν πει με μία φωνή: "Παρακαλώ συνδέστε τα δύο."

Στο σχήμα 3 παρακάτω, το επάνω τμήμα αντιπροσωπεύει το μοντέλο RMI (JRMP), το μεσαίο τμήμα το μοντέλο RMI-IIOP και το κάτω τμήμα το μοντέλο CORBA. Ένα βέλος αντιπροσωπεύει μια κατάσταση στην οποία ένας πελάτης μπορεί να καλέσει έναν διακομιστή. Το RMI-IIOP ανήκει στον κόσμο IIOP κάτω από την οριζόντια γραμμή. Αυτό που μπορεί να φαίνεται περίεργο είναι τα διαγώνια βέλη που διασχίζουν τα σύνορα μεταξύ του κόσμου JRMP και του κόσμου IIOP, πράγμα που σημαίνει ότι ένας πελάτης RMI (JRMP) μπορεί να καλέσει διακομιστή RMI-IIOP και το αντίστροφο. Είναι φυσικό για τους αναγνώστες να πιστεύουν ότι αυτά τα διαγώνια βέλη είναι λανθασμένα - τελικά, διαφορετικά πρωτόκολλα δεν μπορούν ποτέ να μιλούν μεταξύ τους, σωστά; Ωστόσο, αυτά τα βέλη είναι στην πραγματικότητα στο σωστό μέρος. Το RMI-IIOP υποστηρίζει και τα δύο JRMP και Πρωτόκολλα IIOP.

Ένα δυαδικό διακομιστή (δηλ. Ένα αρχείο κλάσης) που δημιουργήθηκε χρησιμοποιώντας API RMI-IIOP μπορεί να εξαχθεί ως JRMP ή IIOP. Δεν χρειάζεται να ξαναγράψετε τον πηγαίο κώδικα Java ή να τον μεταγλωττίσετε ξανά όταν αλλάζετε από JRMP σε IIOP ή αντίστροφα. Χρειάζεστε μόνο αλλαγές παραμέτρων, όπως ιδιότητες συστήματος Java κατά την εκτέλεση. Εναλλακτικά, μπορείτε να προσδιορίσετε το πρωτόκολλο που χρησιμοποιείται καθορίζοντάς τον στον πηγαίο κώδικα Java. Η ίδια ευελιξία ισχύει και για τον κωδικό πελάτη RMI-IIOP.

Διπλή εξαγωγή

Υπάρχει ένα ακόμη σημαντικό γεγονός που πρέπει να θυμάστε όταν αποφασίζετε μεταξύ των πρωτοκόλλων JRMP και IIOP. Όταν εξάγετε ένα αντικείμενο RMI-IIOP στον διακομιστή σας, δεν χρειάζεται απαραίτητα να επιλέξετε μεταξύ JRMP και IIOP. Εάν χρειάζεστε ένα αντικείμενο διακομιστή για να υποστηρίξετε τους πελάτες JRMP και IIOP, μπορείτε να εξαγάγετε το αντικείμενο RMI-IIOP τόσο σε JRMP όσο και σε IIOP ταυτόχρονα. Στην ορολογία RMI-IIOP, αυτό ονομάζεται διπλή εξαγωγή.

Τα διαγώνια βέλη στο Σχήμα 3 είναι δυνατά, επειδή τα API RMI-IIOP υποστηρίζουν πρωτόκολλα JRMP και IIOP. Αυτό σημαίνει ότι, χωρίς να ξαναγράψετε τον πηγαίο κώδικα ενός αντικειμένου RMI (JRMP), μπορεί να κληθεί από έναν νέο πελάτη RMI-IIOP. Ομοίως, χωρίς να ξαναγράψετε τον πηγαίο κώδικα ενός προγράμματος-πελάτη RMI (JRMP), μπορείτε να αντικαταστήσετε ένα αντικείμενο διακομιστή RMI (JRMP) με ένα νέο αντικείμενο RMI-IIOP που μπορεί επίσης να καλέσει ένας πελάτης CORBA. Έτσι, το RMI-IIOP διατηρεί την υπάρχουσα επένδυση σε δυαδικά αρχεία RMI (JRMP), επειδή το RMI-IIOP μπορεί να επικοινωνήσει μαζί τους χωρίς καμία αλλαγή πηγαίου κώδικα ή ανασύνθεση.

Αυτή η διαλειτουργικότητα με το RMI (JRMP) ήταν μία από τις αρχές σχεδιασμού του RMI-IIOP. Οι σχεδιαστές RMI-IIOP απέφυγαν τον πειρασμό να εκτοπίσουν το CORBA και το RMI με ένα τρίτο μοντέλο προγραμματισμού, καθώς αυτό θα προκαλούσε σύγχυση στους προγραμματιστές κατανεμημένων αντικειμένων και θα έκανε ακόμη πιο δύσκολη τη μετανάστευση από το RMI (JRMP).

Διαλειτουργικότητα με την CORBA

Κοιτάξτε ξανά το Σχήμα 3. Η ενότητα κάτω από την οριζόντια γραμμή είναι ο κόσμος IIOP, όπου ένας πελάτης RMI-IIOP καλεί έναν διακομιστή CORBA και ένας πελάτης CORBA καλεί έναν διακομιστή RMI-IIOP. Από ένα Πελάτης RMI-IIOP, εννοούμε ένα πρόγραμμα πελάτη που γράφτηκε από έναν προγραμματιστή RMI που δεν γνωρίζει τίποτα για το CORBA ή το IDL. Ομοίως, α Πελάτης CORBA είναι ένα πρόγραμμα πελάτη που γράφτηκε από έναν προγραμματιστή CORBA αγνοώντας το RMI. Ο διαχωρισμός της διεπαφής από την εφαρμογή είναι μια καθιερωμένη τεχνική που επιτρέπει στους προγραμματιστές να έχουν πρόσβαση σε διαφορετικούς πόρους χωρίς να χρειάζεται να γνωρίζουν πώς εφαρμόζονται αυτοί οι πόροι. Εάν ακολουθηθεί αυτή η τεχνική, οι χρήστες τόσο του RMI-IIOP όσο και του CORBA μπορούν να χρησιμοποιήσουν τις υπηρεσίες του άλλου πρωτοκόλλου, εάν μπορούν να έχουν πρόσβαση στη διεπαφή του. Ένα αρχείο διεπαφής RMI Java είναι η διεπαφή για χρήστες RMI-IIOP, ενώ το IDL είναι η διεπαφή για χρήστες CORBA. Η διαλειτουργικότητα μεταξύ RMI-IIOP και CORBA στο Σχήμα 3 επιτυγχάνεται παρέχοντας σε κάθε χρήστη την αναμενόμενη διεπαφή του, διατηρώντας παράλληλα την πραγματική εφαρμογή κρυφή.

Η τελευταία λεπτομέρεια που πρέπει να εξηγηθεί στο Σχήμα 3 είναι το διακεκομμένο βέλος που δείχνει έναν πελάτη RMI-IIOP που καλεί διακομιστή CORBA. Γιατί είναι διακεκομμένο μόνο αυτό το βέλος; Ένας πελάτης RMI-IIOP δεν μπορεί απαραίτητα να έχει πρόσβαση σε όλα τα υπάρχοντα αντικείμενα CORBA. Η σημασιολογία των αντικειμένων CORBA που ορίζονται στο IDL είναι ένα υπερσύνολο αυτών των αντικειμένων RMI-IIOP, γι 'αυτό το IDL ενός υπάρχοντος αντικειμένου CORBA δεν μπορεί πάντα να αντιστοιχιστεί σε μια διεπαφή Java RMI-IIOP. Μόνο όταν η σημασιολογία ενός συγκεκριμένου αντικειμένου CORBA συμβαίνει να αντιστοιχεί με εκείνες του RMI-IIOP, ένας πελάτης RMI-IIOP μπορεί να καλέσει ένα αντικείμενο CORBA. Το διακεκομμένο βέλος υποδεικνύει μια σύνδεση που είναι μερικές φορές - αλλά όχι πάντα - δυνατή.

Ωστόσο, η ασυμβατότητα εδώ δεν πρέπει να υπερεκτιμάται. Οι περιορισμοί που υποδεικνύονται από το διακεκομμένο βέλος ισχύουν μόνο όταν αντιμετωπίζετε υπάρχοντα αντικείμενα CORBA. Ας υποθέσουμε ότι σχεδιάζετε ένα ολοκαίνουργιο κατανεμημένο αντικείμενο με διεπαφή Java RMI-IIOP. Σε αυτήν την περίπτωση, μπορείτε να δημιουργήσετε αυτόματα το αντίστοιχο IDL με το rmic εργαλείο. Από αυτό το αρχείο IDL, μπορείτε να το εφαρμόσετε ως αντικείμενο CORBA - για παράδειγμα, στο C ++. Αυτό το αντικείμενο C ++ είναι ένα καθαρό αντικείμενο CORBA που μπορεί να κληθεί από έναν πελάτη CORBA και μπορεί επίσης να κληθεί από έναν πελάτη RMI-IIOP χωρίς περιορισμούς. Για τον πελάτη RMI-IIOP, αυτό το αντικείμενο C + + CORBA εμφανίζεται ως καθαρό αντικείμενο RMI-IIOP επειδή ορίζεται από μια διεπαφή Java RMI-IIOP. Εν ολίγοις, η διαφορά μεταξύ ενός αντικειμένου CORBA και ενός αντικειμένου RMI-IIOP είναι μόνο θέμα εφαρμογής. Ομοίως, εάν ένα αντικείμενο υλοποιηθεί σε RMI-IIOP, το αντικείμενο εμφανίζεται ως αντικείμενο CORBA σε έναν πελάτη CORBA επειδή ένας πελάτης CORBA έχει πρόσβαση σε αυτό μέσω του IDL του.

Το σχήμα 4 παρακάτω δείχνει τη μήτρα που συνοψίζει τα βέλη στο σχήμα 3. Ο διακεκομμένος κύκλος σημαίνει το ίδιο πράγμα με το διακεκομμένο βέλος στο σχήμα 3. Το σχήμα 4 δείχνει ότι, εάν εφαρμόσετε τον διακομιστή σας σε RMI-IIOP, έχετε την ευρύτερη επιλογή πελάτες. Ομοίως, εάν εφαρμόσετε τον πελάτη σας στο RMI-IIOP, μπορείτε να μιλήσετε με τη μεγαλύτερη γκάμα διακομιστών, αν και υπάρχουν ορισμένοι περιορισμοί στην περίπτωση υπαρχόντων αντικειμένων CORBA, όπως υποδεικνύεται από τον διακεκομμένο κύκλο.

Πολιτική σχεδιασμού RMI-IIOP

Υπήρχαν δύο σημαντικές προϋποθέσεις που διαμόρφωσαν το σχεδιασμό του πρωτοκόλλου RMI-IIOP: η σημασιολογία RMI έπρεπε να μείνει όσο το δυνατόν πιο άθικτη και το CORBA έπρεπε να βελτιωθεί, ώστε η σημασιολογία RMI να μπορεί να εφαρμοστεί χρησιμοποιώντας την υποδομή CORBA. Αυτό ήταν πιο εύκολο να ειπωθεί παρά να γίνει. Εάν εισήχθη ένα τρίτο μοντέλο προγραμματισμού, θα προκαλούσε σύγχυση στους προγραμματιστές. Για να δημιουργηθεί ένας ευτυχισμένος γάμος με την RMI και την CORBA, ήταν απαραίτητο να επιτευχθεί συμβιβασμός μεταξύ των διαφορετικών υποβάθρων αυτών των γαμήλιων συντρόφων - εάν και οι δύο σύντροφοι απέρριπταν οποιοδήποτε συμβιβασμό, ο γάμος δεν θα είχε κανένα σημείο. Ευτυχώς, η κοινότητα CORBA το αναγνώρισε αυτό και αποδέχτηκε ορισμένες αλλαγές, ώστε το RMI-IIOP να γίνει πραγματικότητα.

Οι δύο σημαντικές αλλαγές που έγιναν αποδεκτές από την CORBA ήταν οι Αντικείμενα ανά τιμή και το Αντιστοίχιση Java-IDL Προδιαγραφές. Ο πρώτος, ήδη διαθέσιμος σε χρήστες RMI με τη μορφή σειριοποίησης αντικειμένων Java, είναι μια προδιαγραφή CORBA που έχει σκοπό να κάνει άλλες γλώσσες να εφαρμόσουν παρόμοια ικανότητα. Το τελευταίο είναι η χαρτογράφηση που χρησιμοποιείται για τη μετατροπή των διεπαφών RMI Java σε ορισμούς CORBA IDL και δεν πρέπει να συγχέεται με την αντιστοίχιση IDL-to-Java που έχει ήδη οριστεί στο CORBA 2.2. (Δείτε πόρους για συνδέσμους προς αυτές τις δύο νέες προδιαγραφές CORBA.)

Η OMG έχει ήδη αποδεχτεί επίσημα και τις δύο προδιαγραφές για το CORBA 2.3, αλλά οι υλοποιήσεις της CORBA θα πρέπει να καλύψουν αυτήν τη νέα έκδοση προτού ο νέος γάμος των CORBA και RMI που περιγράφεται εδώ να γίνει μια ευρεία πραγματικότητα. Για παράδειγμα, ένας μεταγλωττιστής IDL-to-Java που συμμορφώνεται με το CORBA 2.3 είναι διαθέσιμος από τη Sun για χρήση σε συνδυασμό με το RMI-IIOP ORB (αντικείμενο μεσίτης αντικειμένων), αλλά αυτή τη στιγμή είναι μια έκδοση πρώιμης πρόσβασης κατάλληλη μόνο για την εξερεύνηση της διαλειτουργικότητας του CORBA και RMI-IIOP, και όχι για χρήση στην παραγωγή. Επιπλέον, ο μεταγλωττιστής IDL-to-Java που διανέμεται από τη Sun για χρήση με το Java IDL ORB στην Java 1.2 δεν συμμορφώνεται με το CORBA 2.3, επομένως δεν μπορεί να χρησιμοποιηθεί για τον έλεγχο της διαλειτουργικότητας με το RMI-IIOP. Αυτή η κατάσταση θα επιλυθεί τους επόμενους μήνες καθώς οι προμηθευτές CORBA εισάγουν νέες εκδόσεις των προϊόντων τους που υποστηρίζουν το CORBA 2.3. Για παράδειγμα, η επόμενη έκδοση της Java 2 Platform, Standard Edition θα περιλαμβάνει τόσο το RMI-IIOP όσο και έναν μεταγλωττιστή IDL-to-Java ποιότητας παραγωγής που υποστηρίζει το CORBA 2.3.

Διαδικασία ανάπτυξης

Το σχήμα 5 παρακάτω δείχνει τις διαδικασίες ανάπτυξης τόσο για διακομιστές RMI-IIOP όσο και για πελάτες. Θα παρατηρήσετε ότι είναι σχεδόν τα ίδια με αυτά του RMI (JRMP). Όπως και στο RMI (JRMP), ο ορισμός ενός κατανεμημένου αντικειμένου είναι η διεπαφή RMI Java (MyObject.java στο σχήμα 5). Η διαφορά είναι το -Iiop παράμετρος του rmic μεταγλωττιστής. Αυτή η επιλογή χρησιμοποιείται για να γίνει rmic δημιουργήστε τα stubs και γραβάτα που υποστηρίζουν το πρωτόκολλο IIOP. ΧΩΡΙΣ αυτο -Iiop επιλογή, rmic δημιουργεί ένα στέλεχος και ένα σκελετό για το πρωτόκολλο JRMP. Αν και η διαδικασία ανάπτυξης για το RMI-IIOP πλησιάζει εκείνη του RMI (JRMP), το περιβάλλον χρόνου εκτέλεσης είναι διαφορετικό, καθώς η επικοινωνία γίνεται μέσω ενός ORB συμβατό με CORBA 2.3, χρησιμοποιώντας IIOP για επικοινωνία μεταξύ διακομιστών και πελατών.

Εάν σκέφτεστε να μετατρέψετε τον κώδικα RMI (JRMP) σε RMI-IIOP, θα πρέπει να γνωρίζετε ότι υπάρχουν κάποιες διαφορές εφαρμογής κατά την εκτέλεση του IIOP. Η κατανεμημένη συλλογή απορριμμάτων δεν υποστηρίζεται από το CORBA, το οποίο χρησιμοποιεί ρητή καταστροφή και μόνιμες αναφορές αντικειμένων με διαφανή παθητικοποίηση και ενεργοποίηση. Το μητρώο RMI αντικαθίσταται από το JNDI με το CosNaming ή πάροχο υπηρεσιών LDAP και η ενεργοποίηση RMI αντικαθίσταται από τον φορητό προσαρμογέα αντικειμένων. Οι απομακρυσμένες αναφορές αντικειμένων πρέπει να υποβιβαστούν χρησιμοποιώντας προγραμματισμό στενός() αντί για μια άμεση μετάδοση γλώσσας Java. Άλλες σημασιολογικές RMI, όπως η σειριοποίηση αντικειμένων, υποστηρίζονται πλήρως μέσω του IIOP.

Διαδικασία διαλειτουργικότητας CORBA

Το Σχήμα 6 δείχνει τον τρόπο επίτευξης διαλειτουργικότητας μεταξύ RMI-IIOP και CORBA. Για να απλοποιήσουμε τη συζήτησή μας, ας εξετάσουμε δύο πτυχές αυτής της διαλειτουργικότητας: έναν πελάτη CORBA που χρησιμοποιεί ένα αντικείμενο RMI-IIOP, που απεικονίζεται στην αριστερή ενότητα του Σχήματος 6 και έναν πελάτη RMI-IIOP που χρησιμοποιεί ένα αντικείμενο CORBA, που απεικονίζεται στην πιο δεξιά ενότητα. Στο κέντρο του σχήματος βρίσκονται εκείνες οι κοινές διαδικασίες που επιτρέπουν τη λειτουργία και των δύο μορφών διαλειτουργικότητας.

$config[zx-auto] not found$config[zx-overlay] not found