Στο τέλος της παρουσίασης υπηρεσιών J2EE (Java 2 Platform, Enterprise Edition) στο JavaOne του περασμένου έτους, ο αρχιτέκτονας της IBM Jim Knutson παρατήρησε ότι «κάθε υπηρεσία Web χρειάζεται ένα μέρος για να είναι μια υπηρεσία». Στη συνέχεια πρότεινε ότι το πιο ιδανικό μέρος για να είναι μια υπηρεσία Ιστού ήταν μέσα στην υποδομή J2EE. Λίγο περισσότερο από ένα χρόνο αργότερα, η τελική κυκλοφορία του J2EE 1.4 είναι επικείμενη και η πιο σημαντική υπόσχεσή της είναι να παραδώσει το όραμα των υπηρεσιών Web J2EE.
Οι δυνατότητες της υπηρεσίας Web στο J2EE 1.4 απευθύνονται τόσο στον διακομιστή όσο και στον πελάτη των υπηρεσιών Web. Οι δυνατότητες επεκτείνουν το J2EE για να επιτρέψουν στα υπάρχοντα εταιρικά στοιχεία Java από διακομιστή να γίνουν υπηρεσίες Web και να καθορίσουν τον τρόπο με τον οποίο ένα κοντέινερ πελάτη J2EE μπορεί να επικαλεστεί υπηρεσίες Web. Οι τεχνολογίες και για τους δύο στόχους υπήρχαν για λίγο και οι νέες προδιαγραφές J2EE βασίζονται σε αυτά τα υπάρχοντα API για υποστήριξη υπηρεσιών Web. Οι νέες προδιαγραφές προσθέτουν στις υπάρχουσες τεχνολογίες ένα σύνολο απαιτήσεων διαλειτουργικότητας, καθώς και ένα μοντέλο προγραμματισμού και ανάπτυξης για ενοποίηση υπηρεσιών Web.
Υπάρχουν δύο προδιαγραφές που περιγράφουν ρητά αυτά τα πρόσθετα χαρακτηριστικά: Java Specification Request 151, η ομπρέλα JSR για J2EE 1.4 και JSR 109, Υπηρεσίες Web για J2EE. Τη στιγμή αυτής της γραφής, το JSR 109 έχει φτάσει στο τελικό του στάδιο στο JCP (Java Community Process), ενώ το JSR 151 βρίσκεται στην τελευταία φάση ψηφοφορίας. Επιπλέον, το JCP τροποποίησε την τελική έκδοση του JSR 101, Java API για κλήση απομακρυσμένης διαδικασίας με βάση XML (JAX-RPC), για να υποστηρίξει τις απαιτήσεις διαλειτουργικότητας J2EE 1.4.
Οι διακομιστές εφαρμογών επιπέδου J2EE 1.3 μπορούν επίσης να εφαρμόσουν πολλές από τις δυνατότητες που καθορίζονται από αυτά τα JSR. Πράγματι, πολλοί προμηθευτές διακομιστών εφαρμογών έχουν υποστηρίξει διάφορες δυνατότητες ανάπτυξης και ανάπτυξης υπηρεσιών Web στα υπάρχοντα προϊόντα τους εδώ και αρκετό καιρό. Τα JSR 109 και 151 κωδικοποιούν ορισμένες υπάρχουσες πρακτικές και περιγράφουν νέους μηχανισμούς με την ελπίδα να δημιουργήσουν ένα καθολικό μοντέλο ολοκλήρωσης υπηρεσιών J2EE-Web. Οι διακομιστές εφαρμογών επόμενης γενιάς πιθανότατα θα ακολουθήσουν αυτό το ενοποιημένο, τυποποιημένο μοντέλο.
Μετά από μια σύντομη έρευνα για νέες δυνατότητες J2EE που σχετίζονται με την υπηρεσία Web, αυτό το άρθρο εξετάζει τα νέα μοντέλα προγραμματισμού πελάτη και διακομιστή, συμπεριλαμβανομένων νέων ρόλων ανάπτυξης και διαχείρισης υπηρεσιών J2EE που σχετίζονται με την υποστήριξη υπηρεσιών Web.
Επεκτάσεις J2EE που σχετίζονται με την υπηρεσία Ιστού
Ίσως οι πιο σημαντικές και πιο επακόλουθες προσθήκες στο J2EE είναι οι νέες απαιτήσεις διαλειτουργικότητας. Οι απαιτήσεις καθορίζουν υποστήριξη για το SOAP (Simple Object Access Protocol) 1.1 στο επίπεδο παρουσίασης J2EE για τη διευκόλυνση της ανταλλαγής μηνυμάτων XML. Τα κοντέινερ συμβατά με το J2EE 1.4 πρέπει επίσης να υποστηρίζουν το Βασικό προφίλ WS-I (Web Services Interoperability Consortium). Δεδομένου ότι η ανταλλαγή μηνυμάτων XML στο J2EE εξαρτάται από το JAX-RPC, οι προδιαγραφές JAX-RPC επιβάλλουν πλέον υποστήριξη WS-I Basic Profile.
Το αποτέλεσμα είναι ότι μια εφαρμογή που βασίζεται σε J2EE 1.4 μπορεί να κληθεί ως υπηρεσία Web, ακόμη και από εφαρμογές που δεν είναι γραμμένες στη γλώσσα προγραμματισμού Java. Ενώ αυτό είναι ένα εξελικτικό βήμα για το J2EE, δεδομένου ότι η πλατφόρμα έχει από καιρό αγκαλιάσει συστήματα που δεν βασίζονται σε Java, είναι πιθανώς ο πιο άμεσος τρόπος για να διευκολυνθεί η αλληλεπίδραση με τεχνολογίες που βασίζονται σε Windows που βασίζονται στο.
Ο πελάτης μιας υπηρεσίας που βασίζεται σε J2EE δεν χρειάζεται να γνωρίζει πώς εφαρμόζεται μια υπηρεσία. Αντίθετα, αυτός ο πελάτης μπορεί να χρησιμοποιήσει την υπηρεσία στηριζόμενος αποκλειστικά στον ορισμό της υπηρεσίας WSDL (Web Services Description Language). (Προηγούμενος JavaWorldΔιαδικτυακές υπηρεσίες Οι στήλες εξηγούν πώς να ανακαλύπτετε υπηρεσίες βάσει των ορισμών τους WSDL και πώς να δημιουργήσετε και να χρησιμοποιήσετε ορισμούς WSDL. Ανατρέξτε στην ενότητα Πόροι για συνδέσμους.) Ενώ οι προδιαγραφές J2EE δεν περιγράφουν τους ακριβείς μηχανισμούς μιας τέτοιας αλληλεπίδρασης, η αγκαλιά του J2EE 1.4 του Βασικού Προφίλ WS-I, την οποία η Microsoft ισχυρίζεται επίσης ότι ακολουθεί, πιθανότατα θα κάνει την αλληλεπίδραση J2EE-.Net κοινή .
Για να διευκολυνθεί η πρόσβαση σε ορισμούς WSDL, το J2EE 1.4 προσθέτει υποστήριξη για το πρότυπο JAXR (Java API for XML Registries). Οι βιβλιοθήκες JAXR αποτελούν πλέον ένα απαιτούμενο μέρος του προγράμματος-πελάτη εφαρμογών J2EE, του EJB (Enterprise JavaBeans) και των κοντέινερ Web (όχι όμως το κοντέινερ applet). Δεδομένου ότι το Βασικό προφίλ WS-I επιβάλλει υποστήριξη για UDDI (Καθολική περιγραφή, Ανακάλυψη και Ενσωμάτωση) 2.0, οι πελάτες J2EE, καθώς και στοιχεία και servlets EJB, μπορούν να αλληλεπιδράσουν με δημόσια μητρώα υπηρεσιών Web. ("Υπηρεσίες Ιστού Πάρτε Float με JAXR" (JavaWorld, Μάιος 2002) προσφέρει ένα σεμινάριο για το JAXR.) Το σχήμα 1 απεικονίζει τις πρόσθετες βιβλιοθήκες που σχετίζονται με την υπηρεσία Web που υποστηρίζονται από το J2EE 1.4.
Πράγματι, το J2EE θεωρεί ότι μια υπηρεσία Web είναι μια εφαρμογή μιας ή περισσότερων διεπαφών που ορίζονται από ένα έγγραφο WSDL. Οι λειτουργίες που περιγράφονται στο WSDL αντιστοιχίζονται πρώτα σε μεθόδους Java σύμφωνα με τους κανόνες χαρτογράφησης WSDL-to-Java της προδιαγραφής JAX-RPC. Μόλις οριστεί μια διασύνδεση Java που αντιστοιχεί σε ένα αρχείο WSDL, μπορείτε να εφαρμόσετε τις μεθόδους αυτής της διεπαφής με έναν από τους δύο τρόπους: ως ένα πρόγραμμα χωρίς περιόδους λειτουργίας που εκτελείται στο κοντέινερ EJB ή ως κλάση Java που εκτελείται στο κοντέινερ servlet J2EE. Τέλος, κανονίζετε το αντίστοιχο κοντέινερ να ακούει τις εισερχόμενες αιτήσεις SOAP και να αντιστοιχίζει αυτά τα αιτήματα στην αντίστοιχη υλοποίηση (EJB ή servlet). Για να επεξεργαστείτε τις εισερχόμενες προσκλήσεις SOAP, το J2EE 1.4 υποχρεώνει τον χρόνο εκτέλεσης JAX-RPC ως πρόσθετη υπηρεσία κοντέινερ J2EE.
Σύμφωνα με την αρχιτεκτονική J2EE, το κοντέινερ μιας εφαρμογής υπηρεσίας μεσολαβεί στην πρόσβαση σε μια υπηρεσία Web: εάν εκθέσετε είτε ένα στοιχείο EJB είτε ένα servlet ως υπηρεσία Web J2EE, οι πελάτες της υπηρεσίας σας μπορούν να επικαλεστούν αυτήν την υπηρεσία μόνο έμμεσα, μέσω του κοντέινερ. Αυτό επιτρέπει σε μια εφαρμογή υπηρεσίας να επωφεληθεί από την ασφάλεια του κοντέινερ, τη διαχείριση νήματος και ακόμη και τις εγγυήσεις ποιότητας υπηρεσίας. Επιπλέον, τα κοντέινερ σάς επιτρέπουν να λαμβάνετε σημαντικές αποφάσεις για υπηρεσίες Web, όπως περιορισμούς ασφαλείας, κατά το χρόνο ανάπτυξης. Τέλος, το μοντέλο με βάση κοντέινερ του J2EE καθιστά την ανάπτυξη υπηρεσίας Web φορητή: μπορείτε να αναπτύξετε μια υπηρεσία Web που βασίζεται σε Java χρησιμοποιώντας οποιοδήποτε εργαλείο J2EE και να περιμένετε ότι η υπηρεσία θα εκτελεστεί σε οποιαδήποτε άλλη συμβατή εφαρμογή κοντέινερ.
Ένας πελάτης υπηρεσίας Ιστού, από την άλλη πλευρά, δεν γνωρίζει την παρουσία ενός κοντέινερ υπηρεσίας Web. Αντ 'αυτού, ο πελάτης βλέπει ένα Λιμάνι που αντιπροσωπεύει μια παρουσία τελικού σημείου δικτύου μιας υπηρεσίας Web. Αυτό το τελικό σημείο ακολουθεί το JAX-RPC διεπαφή τελικού σημείου υπηρεσίας (SEI) μοντέλο και παρέχει μια εφαρμογή της διεπαφής της υπηρεσίας. Ένας πελάτης βλέπει κάθε υπηρεσία Web J2EE ως συνδυασμό SEI και θύρας. Ένα μεμονωμένο δοχείο J2EE μπορεί να φιλοξενήσει πολλούς τέτοιους συνδυασμούς, όπως απεικονίζει το Σχήμα 2. Κάθε συνδυασμός SEI / port είναι μια παρουσία μιας υπηρεσίας Web.
Σημειώστε ότι ο πελάτης σε αυτήν την αρχιτεκτονική μπορεί να είναι είτε ένας πελάτης J2EE, που εκτελείται εντός του κοντέινερ πελάτη J2EE, είτε ένας πελάτης εκτός J2EE. Οποιοσδήποτε πελάτης συμβατός με το βασικό προφίλ WS-I μπορεί να χρησιμοποιήσει μια υπηρεσία Web J2EE, αλλά κάθε πελάτης μπορεί να ακολουθήσει διαφορετικά μοντέλα προγραμματισμού. Η προδιαγραφή υπηρεσιών Web J2EE περιγράφει ένα μοντέλο προγραμματισμού για πελάτες που εκτελούνται εντός του κοντέινερ προγράμματος-πελάτη εφαρμογής J2EE και ένα άλλο μοντέλο - το μοντέλο προγραμματισμού διακομιστή - για υλοποιήσεις υπηρεσίας Web που εκτελούνται στα κοντέινερ EJB ή servlet.
Το μοντέλο προγραμματισμού πελάτη υπηρεσίας Web J2EE
Η ουσία του μοντέλου προγράμματος-πελάτη υπηρεσίας Web είναι ο εξορθολογισμός της χρήσης API που ορίζονται στα JSRs 67 (Java APIs για XML Messaging, JAXM), 93 (JAXR) και 101 (JAX-RPC) και να παρέχει ένα ολοκληρωμένο πλαίσιο για χρησιμοποιώντας αυτά τα API μαζί στο κοντέινερ πελάτη J2EE.
Σύμφωνα με το μοντέλο προγραμματισμού πελάτη J2EE, ένας πελάτης υπηρεσίας Web είναι απομακρυσμένος και παρέχει τοπική / απομακρυσμένη διαφάνεια. Ο πάροχος θύρας υπηρεσιών Web και το κοντέινερ στο οποίο εκτελείται η θύρα καθορίζουν τον τρόπο με τον οποίο ένας πελάτης βλέπει μια υπηρεσία Web. Ο πελάτης έχει πάντα πρόσβαση στη θύρα και δεν μεταβιβάζεται ποτέ απευθείας αναφορά στην εφαρμογή μιας υπηρεσίας Web. Ένας πελάτης υπηρεσίας J2EE Web παραμένει άγνωστος για το πώς λειτουργεί μια θύρα και πρέπει να ασχολείται μόνο με τις μεθόδους που ορίζει μια θύρα. Αυτές οι μέθοδοι αποτελούν δημόσια διεπαφή μιας υπηρεσίας Web. Επιπλέον, ένας πελάτης πρέπει να θεωρήσει την πρόσβαση σε μια θύρα υπηρεσίας Web ως ανιθαγενής στις προσκλήσεις υπηρεσίας. Όσον αφορά τον πελάτη, μια θύρα δεν έχει μια μοναδική ταυτότητα - ένας πελάτης δεν έχει κανέναν τρόπο να προσδιορίσει εάν επικοινωνεί με πανομοιότυπες θύρες σε προσκλήσεις υπηρεσίας.
Ο πελάτης αποκτά πρόσβαση σε μια θύρα βάσει της διεπαφής υπηρεσίας της θύρας. Οι υπηρεσίες Web J2EE βασίζονται στο JAX-RPC για να καθορίσουν τη σχέση μεταξύ μιας θύρας και της διεπαφής υπηρεσίας. Το JAX-RPC δημιουργεί αυτήν τη σχέση με βάση τους κανόνες επεξεργασίας WSDL. Έτσι, ο ορισμός της υπηρεσίας Web WSDL διέπει τελικά τη συμπεριφορά της θύρας. Με βάση τον ορισμό JAX-RPC, η διεπαφή υπηρεσίας μπορεί είτε να είναι μια γενική διεπαφή που υλοποιεί άμεσα το javax.xml.rpc.Service διεπαφή ή μια "δημιουργημένη υπηρεσία", που είναι ένας υποτύπος αυτής της διεπαφής. Ο τελευταίος τύπος διεπαφής είναι συγκεκριμένος για τον τύπο υπηρεσίας Web.
Στο μοντέλο προγραμματισμού J2EE, ο πελάτης λαμβάνει μια αναφορά σε μια υπηρεσία Web Υπηρεσία αντικείμενο μέσω μιας λειτουργίας αναζήτησης JNDI (Java Naming and Directory Interface). Η αναζήτηση JNDI πραγματοποιείται με λογικό όνομα ή αναφορά υπηρεσίας, για την υπηρεσία Web. Όπως συμβαίνει με όλους τους πόρους που βασίζονται στον κατάλογο, ένας πελάτης πρέπει να δηλώσει τους πόρους που χρειάζεται στον περιγραφέα ανάπτυξης του (περισσότερα για αυτό αργότερα).
Η προδιαγραφή υπηρεσιών Java Web (JSR 109) συνιστά να υπαχθούν όλες οι υπηρεσίες Web στο JNDI υπηρεσία δευτερεύον πλαίσιο. Το κοντέινερ πελάτη δεσμεύει τη διεπαφή υπηρεσίας που περιγράφεται από αυτήν την αναφορά στην ενότητα java: comp / env περιβάλλον ονομασίας περιβάλλοντος πελάτη. Με τη δήλωση αναφοράς υπηρεσίας στην περιγραφή ανάπτυξης του πελάτη, το κοντέινερ πελάτη διασφαλίζει ότι η υπηρεσία αναφοράς είναι διαθέσιμη σε πόρους που γνωρίζουν το JNDI. Το παρακάτω απόσπασμα κώδικα δείχνει τον τρόπο απόκτησης αναφοράς σε μια υπηρεσία Web που βασίζεται σε J2EE μέσω αναζήτησης JNDI:
InitialContext ctx = νέο InitialContext (); Υπηρεσία myService = (Υπηρεσία) ctx.lookup ("java: comp / env / services / MyWebService"); Ο παραπάνω κώδικας αποκτά ένα γενικό αντικείμενο υπηρεσίας: ένα αντικείμενο χωρίς συγκεκριμένο τύπο. Μια υπηρεσία που δημιουργείται JAX-RPC έχει πρόσβαση με τον ίδιο τρόπο, αυτή τη φορά μεταδίδει την υπηρεσία στον τύπο διεπαφής της συγκεκριμένης υπηρεσίας Web:
InitialContext ctx = νέο InitialContext (); MyWebService myService = (MyWebService) ctx.lookup ("java: / comp / env / services / MyWebService"); Σημειώστε ότι αυτός ο κώδικας προϋποθέτει ότι το MyWebService Η αναφορά συνδέεται με ένα αντικείμενο που εφαρμόζει το MyWebService διεπαφή. Δεδομένου ότι η δέσμευση υπηρεσίας διευκολύνεται κατά το χρόνο ανάπτυξης μιας υπηρεσίας Web, τα εργαλεία J2EE αναμένεται να διασφαλίσουν αυτήν τη συνέπεια. Όλοι οι διακομιστές εφαρμογών που συμμορφώνονται με το J2EE 1.4 πρέπει να υποστηρίζουν την αναζήτηση υπηρεσιών με βάση το JNDI.
Μόλις ένας πελάτης αποκτήσει μια υπηρεσία Web Υπηρεσία αντικείμενο, μπορεί να χρησιμοποιήσει αυτό το αντικείμενο για να ανακτήσει ένα javax.xml.rpc.Κλήση περίπτωση που εκτελεί την πραγματική επίκληση υπηρεσίας. Ο πελάτης έχει τρεις επιλογές για να αποκτήσει ένα Κλήση: μέσω ενός stub, ενός δυναμικού διακομιστή μεσολάβησης ή ενός DII (Dynamic Invocation Interface). Δεν θα συζητήσω σε αυτό το άρθρο τις διαφορές μεταξύ αυτών των μεθόδων, ανεξάρτητα από το πώς Κλήση δημιουργείται, αυτό Κλήση αναφέρεται απευθείας στη θύρα της υπηρεσίας - το μόνο αντικείμενο που πρέπει να γνωρίζει ο πελάτης κατά την επίκληση της υπηρεσίας Web. Όλα τα δοχεία συμβατά με το J2EE 1.4 πρέπει να υποστηρίζουν το Υπηρεσία μεθόδους διεπαφής, και έτσι επιτρέπει σε έναν πελάτη να αποκτήσει μια αναφορά σε ένα Κλήση αντικείμενο για μια υπηρεσία Web, και στη θύρα αυτής της υπηρεσίας, μέσω Κλήση.
Σημειώστε ότι σε αντίθεση με τη χρήση JAX-RPC εκτός J2EE, ένας πελάτης δεν πρέπει να χρησιμοποιεί το JAX-RPC Εργοστάσιο τάξη για να αποκτήσετε μια νέα υπηρεσία. Αντ 'αυτού, ο πελάτης πρέπει να αποκτήσει πρόσβαση στο Υπηρεσία από μια πηγή που βασίζεται στο JNDI, δεδομένου ότι η αναφορά σε μια υπηρεσία που ανακτήθηκε από το JNDI θα έχει όλες τις απαραίτητες ρυθμίσεις και διαμορφώσεις για την επίκληση της συγκεκριμένης παρουσίας υπηρεσίας. Από την άποψη του πελάτη, αυτή η διαφορά είναι κάπως ανάλογη με τον τρόπο με τον οποίο ένας πελάτης J2EE ανακτά ένα JDBC Πηγή δεδομένων μέσω της διεπαφής JNDI για πρόσβαση σε μια βάση δεδομένων, αντί να ρυθμίσετε χειροκίνητα ένα JDBC Σύνδεση παράδειγμα.
Με αυτό Κλήση αντικείμενο στη θέση του, ο πελάτης ακολουθεί τη σημασιολογία JAX-RPC της απομακρυσμένης διαδικασίας κλήσης. Για παράδειγμα, ο πελάτης μπορεί να χρησιμοποιήσει το επικαλούμαι() μέθοδος σε αυτό Κλήση για να αλληλεπιδράσετε με την υπηρεσία Web. (Για ένα παράδειγμα επίκλησης υπηρεσίας τύπου JAX-RPC, ανατρέξτε στην ενότητα "Μου αρέσει ο τύπος σας: Περιγράψτε και καλέστε υπηρεσίες Web με βάση τον τύπο υπηρεσίας" (JavaWorld, Σεπτέμβριος 2002).)
Το μοντέλο προγραμματισμού διακομιστή υπηρεσίας Web
Μια υπηρεσία Web που βασίζεται σε J2EE μπορεί να ακολουθεί μία από τις δύο πιθανές υλοποιήσεις: Εάν η υπηρεσία υλοποιείται ως κανονική κλάση Java, πρέπει να συμμορφώνεται με τις απαιτήσεις του κοντέινερ servlet JAX-RPC. Εναλλακτικά, εάν η υπηρεσία έχει οριστεί να εκτελείται στο κοντέινερ EJB, τότε πρέπει να ακολουθεί το μοντέλο προγραμματισμού που απαιτείται από κόκκους συνεδρίας EJB χωρίς κατάσταση Ανεξάρτητα από τη μέθοδο εφαρμογής, κάθε κοντέινερ παρέχει στην υλοποίηση της υπηρεσίας Web υποστήριξη κύκλου ζωής, διαχείριση ταυτόχρονων και υποδομή ασφαλείας.
Η κύρια ευθύνη του κοντέινερ διακομιστή J2EE είναι η χαρτογράφηση και αποστολή αιτημάτων SOAP, στην περίπτωση EJB, σε κόκκους συνεδρίας χωρίς κατάσταση, και, στην περίπτωση του servlet container, σε μεθόδους σε κλάσεις τελικού σημείου υπηρεσίας JAX-RPC. Ενώ η προδιαγραφή JAX-RPC καθορίζει ένα μοντέλο προγραμματισμού για την τελευταία επιλογή, οι υπηρεσίες Web J2EE JSR (JSR 109) περιγράφουν ένα ανάλογο μοντέλο για κόκκους συνεδρίας EJB χωρίς κατάσταση.
