Το Enterprise JavaBeans (EJB) δημιούργησε μεγάλο ενθουσιασμό από την ανακοίνωση του Enterprise JavaBeans Specification Version 1.0. Εταιρείες όπως η Oracle, η Borland, η Tandem, η Symantec, η Sybase και η Visigenic, μεταξύ άλλων, έχουν ανακοινώσει ή / και παραδώσει προϊόντα που συμμορφώνονται με τις προδιαγραφές του EJB. Αυτό το μήνα, θα ρίξουμε μια ματιά σε υψηλό επίπεδο τι ακριβώς είναι το Enterprise JavaBeans. Θα εξετάσουμε πώς διαφέρει το EJB από το αρχικό μοντέλο συστατικών JavaBeans και θα συζητήσουμε γιατί το EJB δημιούργησε ένα τόσο μεγάλο ενδιαφέρον.
Αλλά πρώτα, μια συμβουλή: δεν θα εξετάσουμε τον πηγαίο κώδικα ή τα θέματα οδηγιών για αυτόν τον μήνα. Αυτό το άρθρο δεν είναι σεμινάριο. μάλλον είναι μια αρχιτεκτονική επισκόπηση. Το EJB καλύπτει πολλές περιοχές και χωρίς να κατανοήσει πρώτα τις βασικές έννοιες, τα αποσπάσματα κώδικα και τα κόλπα προγραμματισμού δεν έχουν νόημα. Εάν υπάρχει ενδιαφέρον από την πλευρά του JavaWorldΑναγνώστες, μελλοντικά άρθρα ενδέχεται να καλύπτουν τις ιδιαιτερότητες της χρήσης του Enterprise JavaBeans API για τη δημιουργία του δικού σας Enterprise JavaBeans.
Για να καταλάβουμε γιατί το EJB είναι τόσο ελκυστικό για τους προγραμματιστές, χρειαζόμαστε κάποιο ιστορικό υπόβαθρο. Πρώτον, θα εξετάσουμε το ιστορικό των συστημάτων πελάτη / διακομιστή και την τρέχουσα κατάσταση. Στη συνέχεια, θα συζητήσουμε τα διάφορα μέρη ενός συστήματος EJB: Συστατικά EJB - που ζουν σε ένα Δοχείο EJB τρέχει μέσα σε ένα Διακομιστής EJB -- και Αντικείμενα EJB, που χρησιμοποιεί ο πελάτης ως ένα είδος "τηλεχειριστηρίου" στοιχείων EJB. Θα εξετάσουμε τους δύο τύπους EJB: συνεδρίαση και οντότητα αντικείμενα. Θα διαβάσετε επίσης Σπίτι και μακρινός διασυνδέσεις, οι οποίες δημιουργούν παρουσίες EJB και παρέχουν πρόσβαση στις επιχειρηματικές μεθόδους του EJB, αντίστοιχα. Μέχρι το τέλος του άρθρου, θα έχετε μια ιδέα για το πώς μπορούν να δημιουργηθούν επεκτάσιμοι διακομιστές χρησιμοποιώντας το Enterprise JavaBeans. Αλλά πρώτα, μια ματιά στο παρελθόν.
Ιστορικό πελάτη / διακομιστή
Αρχαία ιστορία
Στην αρχή, υπήρχε ο υπολογιστής mainframe. Και ήταν καλό. (Ή τόσο καλά όσο πήρε, ούτως ή άλλως.) Η κατάσταση της τεχνολογίας στην επεξεργασία πληροφοριών μέχρι τη δεκαετία του 1960 αποτελούσε κυρίως από μεγάλα, ακριβά μηχανήματα που χρησιμοποιούν μεγάλοι οργανισμοί για την υποστήριξη των καθημερινών επιχειρηματικών τους δραστηριοτήτων. Οι μικροϋπολογιστές και η κοινή χρήση χρόνου στη δεκαετία του 1970 αύξησαν την προσβασιμότητα της υπολογιστικής ισχύος, αλλά οι πληροφορίες και η επεξεργασία ήταν ακόμη συγκεντρωμένες σε μεμονωμένα μηχανήματα. Οι πρώτοι προσωπικοί υπολογιστές τη δεκαετία του 1980 ταίριαζαν γρήγορα το εταιρικό τοπίο με χιλιάδες μικρά νησιά πληροφοριών, όλα αναλύοντας ακούραστα αναφορές μεταβλητής ποιότητας, χάνοντας κρίσιμα δεδομένα όταν έπεσαν, και γρήγορα έγιναν ασυνεπείς μεταξύ τους.
Πελάτης / διακομιστής στη διάσωση
Η αρχιτεκτονική πελάτη / διακομιστή είναι μια από τις πιο κοινές λύσεις στο αίνιγμα του τρόπου χειρισμού της ανάγκης τόσο για κεντρικό έλεγχο δεδομένων όσο και για ευρεία προσβασιμότητα δεδομένων. Στα συστήματα πελάτη / διακομιστή, οι πληροφορίες διατηρούνται σχετικά συγκεντρωτικές (ή κατανέμονται ή / και αναπαράγονται μεταξύ κατανεμημένων διακομιστών), η οποία διευκολύνει τον έλεγχο και τη συνέπεια των δεδομένων, παρέχοντας παράλληλα πρόσβαση στα δεδομένα που χρειάζονται οι χρήστες.
Τα συστήματα διακομιστή-πελάτη αποτελούνται συνήθως από διάφορους αριθμούς βαθμίδες. Το τυπικό παλιό σύστημα mainframe ή χρονομεριστικής χρήσης, όπου το περιβάλλον εργασίας χρήστη λειτουργεί στον ίδιο υπολογιστή με τη βάση δεδομένων και τις επιχειρηματικές εφαρμογές, είναι γνωστό ως μονή βαθμίδα. Τέτοια συστήματα είναι σχετικά εύκολο στη διαχείριση και η συνοχή των δεδομένων είναι απλή επειδή τα δεδομένα αποθηκεύονται σε ένα μόνο μέρος. Δυστυχώς, τα συστήματα ενός επιπέδου έχουν περιορισμένη δυνατότητα κλιμάκωσης και είναι επιρρεπή σε κινδύνους διαθεσιμότητας (εάν ένας υπολογιστής είναι εκτός λειτουργίας, ολόκληρη η επιχείρησή σας πέφτει), ιδιαίτερα εάν εμπλέκεται η επικοινωνία.
Τα πρώτα συστήματα πελάτη / διακομιστή ήταν δύο επιπέδων, όπου η διεπαφή χρήστη έτρεχε στον πελάτη και η βάση δεδομένων έζησε στον διακομιστή. Τέτοια συστήματα είναι ακόμη κοινά. Ένας τύπος διακομιστή δύο επιπέδων με ποικιλία κήπων εκτελεί το μεγαλύτερο μέρος της επιχειρηματικής λογικής στον πελάτη, ενημερώνοντας τα κοινόχρηστα δεδομένα στέλνοντας ροές SQL στον διακομιστή. Αυτή είναι μια ευέλικτη λύση, καθώς η συνομιλία πελάτη / διακομιστή πραγματοποιείται στο επίπεδο της γλώσσας βάσης δεδομένων του διακομιστή. Σε ένα τέτοιο σύστημα, ένας κατάλληλα σχεδιασμένος πελάτης μπορεί να τροποποιηθεί ώστε να αντικατοπτρίζει νέους επιχειρηματικούς κανόνες και συνθήκες χωρίς τροποποίηση του διακομιστή, αρκεί ο διακομιστής να έχει πρόσβαση στο σχήμα βάσης δεδομένων (πίνακες, προβολές και ούτω καθεξής) που απαιτείται για την εκτέλεση των συναλλαγών. Ο διακομιστής σε ένα τέτοιο σύστημα δύο επιπέδων ονομάζεται a διακομιστής βάσης δεδομένων, όπως φαίνεται παρακάτω.
Ωστόσο, οι διακομιστές βάσης δεδομένων έχουν ορισμένες υποχρεώσεις. Συχνά το SQL για μια συγκεκριμένη επιχειρησιακή λειτουργία (για παράδειγμα, προσθήκη ενός στοιχείου σε μια παραγγελία) είναι πανομοιότυπο, με εξαίρεση τα δεδομένα που ενημερώνονται ή εισάγονται, από κλήση σε κλήση. Ένας διακομιστής βάσης δεδομένων καταλήγει να αναλύει και να αναλύει σχεδόν όμοια SQL για κάθε επιχειρησιακή λειτουργία. Για παράδειγμα, όλες οι δηλώσεις SQL για την προσθήκη ενός στοιχείου σε μια παραγγελία είναι πιθανό να είναι πολύ παρόμοιες, όπως και οι δηλώσεις SQL για την εύρεση ενός πελάτη στη βάση δεδομένων. Ο χρόνος που χρειάζεται αυτή η ανάλυση θα αφιερωθεί καλύτερα στην επεξεργασία δεδομένων. (Υπάρχουν λύσεις σε αυτό το πρόβλημα, συμπεριλαμβανομένης της SQL Parse cache και των αποθηκευμένων διαδικασιών.) Ένα άλλο πρόβλημα που προκύπτει είναι η εκτύπωση των πελατών και της βάσης δεδομένων ταυτόχρονα: όλα τα μηχανήματα πρέπει να κλείσουν για αναβαθμίσεις και οι πελάτες ή οι διακομιστές που πέφτουν πίσω τους Η έκδοση λογισμικού συνήθως δεν μπορεί να χρησιμοποιηθεί έως ότου αναβαθμιστούν.
Διακομιστές εφαρμογών
Ενα διακομιστής εφαρμογών Η αρχιτεκτονική (δείτε την επόμενη εικόνα) είναι μια δημοφιλής εναλλακτική λύση στην αρχιτεκτονική ενός διακομιστή βάσης δεδομένων επειδή επιλύει ορισμένα από τα προβλήματα που έχουν οι διακομιστές βάσης δεδομένων.
Ένα περιβάλλον διακομιστή βάσης δεδομένων εκτελεί συνήθως επιχειρηματικές μεθόδους στον πελάτη και χρησιμοποιεί τον διακομιστή ως επί το πλείστον για επιμονή και ενίσχυση της ακεραιότητας των δεδομένων. Σε έναν διακομιστή εφαρμογών, οι επιχειρηματικές μέθοδοι εκτελούνται στον διακομιστή και ο πελάτης ζητά από τον διακομιστή να εκτελέσει αυτές τις μεθόδους. Σε αυτό το σενάριο, ο πελάτης και ο διακομιστής συνήθως χρησιμοποιούν ένα πρωτόκολλο που αντιπροσωπεύει μια συνομιλία στο επίπεδο των επιχειρηματικών συναλλαγών, αντί στο επίπεδο των πινάκων και των γραμμών. Τέτοιοι διακομιστές εφαρμογών συχνά αποδίδουν καλύτερα από τους αντίστοιχους στη βάση δεδομένων τους, αλλά εξακολουθούν να υποφέρουν από προβλήματα εκδόσεων.
Τόσο η βάση δεδομένων όσο και τα συστήματα εφαρμογών μπορούν να βελτιωθούν προσθέτοντας επιπλέον επίπεδα στην αρχιτεκτονική. Το λεγόμενο τριών επιπέδων Τα συστήματα τοποθετούν ένα ενδιάμεσο στοιχείο μεταξύ του πελάτη και του διακομιστή. Ολόκληρη η βιομηχανία - το middleware - έχει ξεπεράσει την αντιμετώπιση των υποχρεώσεων των συστημάτων δύο επιπέδων. ΕΝΑ παρακολούθηση επεξεργασίας συναλλαγών, ένας τύπος μεσαίου λογισμικού, λαμβάνει ροές αιτημάτων από πολλούς πελάτες και μπορεί να εξισορροπήσει το φορτίο μεταξύ πολλών διακομιστών, να παρέχει αποτυχία όταν ένας διακομιστής αποτύχει και να διαχειριστεί συναλλαγές για λογαριασμό ενός πελάτη. Άλλοι τύποι μεσαίου λογισμικού παρέχουν μετάφραση πρωτοκόλλου επικοινωνιών, ενοποιούν αιτήματα και απαντήσεις μεταξύ πελατών και πολλαπλών ετερογενών διακομιστών (αυτό είναι ιδιαίτερα δημοφιλές κατά την αντιμετώπιση συστημάτων παλαιού τύπου στον ανασχεδιασμό επιχειρηματικών διαδικασιών) ή / και παρέχει πληροφορίες μέτρησης υπηρεσιών και κυκλοφορίας δικτύου.
Τα πολλαπλά επίπεδα παρέχουν ευελιξία και διαλειτουργικότητα που έχει οδηγήσει σε συστήματα με περισσότερα από αυτά τα τρία επίπεδα υπηρεσιών. Για παράδειγμα, n-επίπεδο Τα συστήματα είναι γενικεύσεις συστημάτων τριών επιπέδων, κάθε επίπεδο λογισμικού παρέχει διαφορετικό επίπεδο υπηρεσίας στα επίπεδα παραπάνω και κάτω από αυτό. Η προοπτική n-tier θεωρεί ότι το δίκτυο είναι μια ομάδα κατανεμημένων υπηρεσιών, και όχι απλώς τα μέσα για έναν πελάτη για πρόσβαση σε έναν μόνο διακομιστή.
Καθώς οι αντικειμενοστρεφείς γλώσσες και οι τεχνικές έχουν τεθεί σε μόδα, έτσι τα συστήματα πελατών / διακομιστών κινούνται όλο και περισσότερο προς τον αντικειμενοστραφή. Το CORBA (Common Object Request Broker Architecture) είναι μια αρχιτεκτονική που επιτρέπει την εκτέλεση αντικειμένων εντός εφαρμογών - ακόμη και αντικειμένων γραμμένων σε διαφορετικές γλώσσες - σε ξεχωριστά μηχανήματα, ανάλογα με τις ανάγκες μιας συγκεκριμένης εφαρμογής. Οι εφαρμογές που γράφτηκαν πριν από χρόνια μπορούν να συσκευαστούν ως υπηρεσίες CORBA και να συνεργαστούν με νέα συστήματα. Το Enterprise JavaBeans, το οποίο έχει σχεδιαστεί για να είναι συμβατό με το CORBA, είναι μια άλλη είσοδος στον δακτύλιο διακομιστή εφαρμογών με αντικειμενοστρεφή χρήση.
Ο σκοπός αυτού του άρθρου δεν είναι να παρέχει ένα σεμινάριο για συστήματα πελάτη / διακομιστή, αλλά ήταν απαραίτητο να παρέχεται κάποιο υπόβαθρο για τον καθορισμό του περιβάλλοντος. Τώρα ας δούμε τι έχει να προσφέρει το EJB.
Enterprise JavaBeans και επεκτάσιμοι διακομιστές εφαρμογών
Τώρα που κοιτάξαμε λίγο το ιστορικό και έχουμε κατανοήσει τι είναι οι διακομιστές εφαρμογών, ας δούμε το Enterprise JavaBeans και να δούμε τι προσφέρει σε αυτό το πλαίσιο.
Η βασική ιδέα πίσω από το Enterprise JavaBeans είναι να παρέχει ένα πλαίσιο για στοιχεία που μπορεί να "συνδέονται" σε έναν διακομιστή, επεκτείνοντας έτσι τη λειτουργικότητα αυτού του διακομιστή. Το Enterprise JavaBeans είναι παρόμοιο με το αρχικό JavaBeans μόνο στο ότι χρησιμοποιεί μερικές παρόμοιες έννοιες. Η τεχνολογία EJB δεν διέπεται από το Προδιαγραφή στοιχείων JavaBeans, αλλά από την εντελώς διαφορετική (και μαζική) Προδιαγραφή Enterprise JavaBeans (Δείτε τους πόρους για λεπτομέρειες σχετικά με αυτήν την προδιαγραφή.) Προδιαγραφές EJB καλεί τους διάφορους παίκτες στο σύστημα πελάτη / διακομιστή EJB, περιγράφει πώς το EJB συνεργάζεται με τον πελάτη και με τα υπάρχοντα συστήματα, εξηγεί τη συμβατότητα του EJB με το CORBA και καθορίζει τις ευθύνες για τα διάφορα στοιχεία του συστήματος.
Επιχείρηση JavaBeans στόχους
ο Προδιαγραφές EJB προσπαθεί να επιτύχει πολλούς στόχους ταυτόχρονα:
Το EJB έχει σχεδιαστεί για να διευκολύνει τους προγραμματιστές να δημιουργούν εφαρμογές, απελευθερώνοντάς τους από λεπτομέρειες συστήματος χαμηλού επιπέδου για τη διαχείριση συναλλαγών, νήματα, εξισορρόπηση φορτίου και ούτω καθεξής. Οι προγραμματιστές εφαρμογών μπορούν να επικεντρωθούν στην επιχειρηματική λογική και να αφήσουν τις λεπτομέρειες της διαχείρισης της επεξεργασίας δεδομένων στο πλαίσιο. Ωστόσο, για εξειδικευμένες εφαρμογές, είναι πάντοτε εφικτό να "παραμείνετε" και να προσαρμόσετε αυτές τις υπηρεσίες χαμηλότερου επιπέδου.
ο EJB Spec καθορίζει τις κύριες δομές του πλαισίου EJB και, στη συνέχεια, καθορίζει συγκεκριμένα τις συμβάσεις μεταξύ τους. Οι ευθύνες του πελάτη, του διακομιστή και των μεμονωμένων στοιχείων διευκρινίζονται ξεκάθαρα. (Θα εξετάσουμε ποιες είναι αυτές οι δομές σε μια στιγμή.) Ένας προγραμματιστής που δημιουργεί ένα στοιχείο Enterprise JavaBean έχει πολύ διαφορετικό ρόλο από κάποιον που δημιουργεί διακομιστή συμβατό με EJB και η προδιαγραφή περιγράφει τις ευθύνες του καθενός.
Το EJB στοχεύει να είναι ο τυπικός τρόπος για την κατασκευή εφαρμογών πελάτη / διακομιστή στη γλώσσα Java. Ακριβώς όπως τα αρχικά JavaBeans (ή τα στοιχεία Delphi, ή οτιδήποτε άλλο) από διαφορετικούς προμηθευτές μπορούν να συνδυαστούν για την παραγωγή ενός προσαρμοσμένου πελάτη, τα στοιχεία διακομιστή EJB από διαφορετικούς προμηθευτές μπορούν να συνδυαστούν για την παραγωγή ενός προσαρμοσμένου διακομιστή. Τα στοιχεία EJB, που είναι τάξεις Java, θα εκτελούνται φυσικά σε οποιονδήποτε διακομιστή συμβατό με EJB χωρίς επανασυγκέντρωση. Αυτό είναι ένα όφελος που δεν μπορούν να ελπίζουν να προσφέρουν λύσεις για συγκεκριμένες πλατφόρμες.
- Τέλος, το EJB είναι συμβατό με και χρησιμοποιεί άλλα Java API, μπορεί να λειτουργήσει με εφαρμογές εκτός Java και είναι συμβατό με το CORBA.
Πώς λειτουργεί ένα σύστημα πελάτη / διακομιστή EJB
Για να κατανοήσουμε πώς λειτουργεί ένα σύστημα πελάτη / διακομιστή EJB, πρέπει να κατανοήσουμε τα βασικά μέρη ενός συστήματος EJB: το στοιχείο EJB, το κοντέινερ EJB και το αντικείμενο EJB.
Το στοιχείο Enterprise JavaBeans
Ένα Enterprise JavaBean είναι ένα συστατικό, όπως ένα παραδοσιακό JavaBean. Το Enterprise JavaBeans εκτελείται εντός ενός Εμπορευματοκιβώτιο EJB, που με τη σειρά του εκτελεί μέσα σε ένα Διακομιστής EJB. Οποιοσδήποτε διακομιστής μπορεί να φιλοξενήσει ένα κοντέινερ EJB και να του παρέχει τις απαραίτητες υπηρεσίες μπορεί να είναι διακομιστής EJB. (Αυτό σημαίνει ότι πολλοί υπάρχοντες διακομιστές ενδέχεται να επεκταθούν σε διακομιστές EJB, και στην πραγματικότητα πολλοί προμηθευτές το έχουν επιτύχει ή έχουν ανακοινώσει την πρόθεσή τους.)
Ένα στοιχείο EJB είναι ο τύπος κλάσης EJB που πιθανότατα θεωρείται "Enterprise JavaBean". Είναι μια τάξη Java, γραμμένη από έναν προγραμματιστή EJB, που εφαρμόζει την επιχειρηματική λογική. Όλες οι άλλες κατηγορίες στο σύστημα EJB είτε υποστηρίζουν την πρόσβαση πελατών είτε παρέχουν υπηρεσίες (όπως επιμονή και ούτω καθεξής) σε κλάσεις συστατικών EJB.
Το κοντέινερ Enterprise JavaBeans
Το κοντέινερ EJB είναι εκεί όπου ζει το στοιχείο EJB. Το κοντέινερ EJB παρέχει υπηρεσίες όπως διαχείριση συναλλαγών και πόρων, εκδόσεις, επεκτασιμότητα, κινητικότητα, επιμονή και ασφάλεια στα στοιχεία EJB που περιέχει. Δεδομένου ότι το κοντέινερ EJB χειρίζεται όλες αυτές τις λειτουργίες, ο προγραμματιστής στοιχείων EJB μπορεί να επικεντρωθεί στους επιχειρηματικούς κανόνες και να αφήσει τον χειρισμό της βάσης δεδομένων και άλλες τέτοιες λεπτές λεπτομέρειες στο κοντέινερ. Για παράδειγμα, εάν ένα μεμονωμένο στοιχείο EJB αποφασίσει ότι η τρέχουσα συναλλαγή πρέπει να ακυρωθεί, απλώς λέει στον περιέκτη του (με τρόπο που ορίζεται από Προδιαγραφή EJB, και το κοντέινερ είναι υπεύθυνο για την εκτέλεση όλων των επαναφοράς, ή για να κάνει ό, τι είναι απαραίτητο για να ακυρώσει μια συναλλαγή που βρίσκεται σε εξέλιξη. Πολλές παρουσίες συστατικών EJB υπάρχουν συνήθως μέσα σε ένα μόνο κοντέινερ EJB.
Το αντικείμενο EJB και η απομακρυσμένη διεπαφή
Τα προγράμματα πελατών εκτελούν μεθόδους σε απομακρυσμένα EJB μέσω ενός Αντικείμενο EJB. Το αντικείμενο EJB εφαρμόζει την "απομακρυσμένη διεπαφή" του στοιχείου EJB στον διακομιστή. Η απομακρυσμένη διεπαφή αντιπροσωπεύει τις μεθόδους "επιχειρήσεων" του στοιχείου EJB. Η απομακρυσμένη διεπαφή κάνει την πραγματική, χρήσιμη εργασία ενός αντικειμένου EJB, όπως τη δημιουργία μιας φόρμας παραγγελίας ή την αναβολή ενός ασθενούς σε έναν ειδικό. Θα συζητήσουμε την απομακρυσμένη διεπαφή με περισσότερες λεπτομέρειες παρακάτω.
