Επισκόπηση
Ο προγραμματισμός βασισμένος σε στοιχεία έχει γίνει πιο δημοφιλής από ποτέ. Σήμερα δεν υπάρχει σχεδόν καμία εφαρμογή που να μην περιλαμβάνει την αξιοποίηση συστατικών σε κάποια μορφή, συνήθως από διαφορετικούς προμηθευτές. Καθώς οι εφαρμογές έχουν γίνει πιο περίπλοκες, έχει αυξηθεί και η ανάγκη αξιοποίησης συστατικών που διανέμονται σε απομακρυσμένες μηχανές.
Ένα παράδειγμα εφαρμογής βασισμένης σε συστατικά στοιχεία είναι μια ολοκληρωμένη λύση ηλεκτρονικού εμπορίου. Μια εφαρμογή ηλεκτρονικού εμπορίου που φιλοξενείται σε ένα συγκρότημα διακομιστών (Web farm) πρέπει να υποβάλλει παραγγελίες σε μια εφαρμογή διαχείρισης επιχειρησιακών πόρων (ERP) στο παρασκήνιο. Σε πολλές περιπτώσεις, η εφαρμογή ERP φιλοξενείται σε διαφορετικό υλικό και ενδέχεται να λειτουργεί σε διαφορετικό λειτουργικό σύστημα.
Το Microsoft Distributed Component Object Model (DCOM), μια υποδομή κατανεμημένων αντικειμένων που επιτρέπει σε μια εφαρμογή να καλεί στοιχεία του Component Object Model (COM) που είναι εγκατεστημένα σε άλλον διακομιστή, έχει μεταφερθεί σε διάφορες πλατφόρμες εκτός των Windows. Ωστόσο, το DCOM δεν έχει γίνει ποτέ ευρέως αποδεκτό σε αυτές τις πλατφόρμες, οπότε σπάνια χρησιμοποιείται για τη διευκόλυνση της επικοινωνίας μεταξύ υπολογιστών με Windows και υπολογιστών που δεν λειτουργούν με Windows. Οι προμηθευτές λογισμικού ERP συχνά δημιουργούν στοιχεία για την πλατφόρμα Windows που επικοινωνούν με το σύστημα back-end μέσω ενός ιδιόκτητου πρωτοκόλλου.
Ορισμένες υπηρεσίες στις οποίες βασίζεται μια εφαρμογή ηλεκτρονικού εμπορίου ενδέχεται να μην βρίσκονται καθόλου εντός του κέντρου δεδομένων. Για παράδειγμα, εάν η εφαρμογή ηλεκτρονικού εμπορίου δέχεται πληρωμές με πιστωτική κάρτα για προϊόντα που αγοράζει ο πελάτης, πρέπει να αξιοποιήσει τις υπηρεσίες της εμπορικής τράπεζας για την επεξεργασία των στοιχείων της πιστωτικής κάρτας του πελάτη. Ωστόσο, για όλους τους πρακτικούς σκοπούς, το DCOM και οι σχετικές τεχνολογίες, όπως το CORBA και το Java RMI, περιορίζονται σε εφαρμογές και στοιχεία που είναι εγκατεστημένα εντός του εταιρικού κέντρου δεδομένων. Δύο βασικοί λόγοι για αυτό είναι ότι, εξ ορισμού, αυτές οι τεχνολογίες χρησιμοποιούν ιδιόκτητα πρωτόκολλα και ότι τα πρωτόκολλα αυτά είναι εγγενώς προσανατολισμένα στη σύνδεση.
Οι πελάτες που επικοινωνούν με τον διακομιστή μέσω του Διαδικτύου αντιμετωπίζουν πολυάριθμα πιθανά εμπόδια στην επικοινωνία τους με τον διακομιστή. Διαχειριστές δικτύων σε όλο τον κόσμο, με έμφαση στην ασφάλεια, έχουν εγκαταστήσει εταιρικούς δρομολογητές και τείχη προστασίας για να αποκλείουν πρακτικά κάθε είδους επικοινωνία μέσω του Διαδικτύου. Συχνά χρειάζεται μια ανωτέρα βία για να πείσει κανείς έναν διαχειριστή δικτύου να ανοίξει θύρες πέρα από το απολύτως απαραίτητο ελάχιστο.
Αν είστε αρκετά τυχεροί ώστε να πείσετε έναν διαχειριστή δικτύου να ανοίξει τις κατάλληλες θύρες για την υποστήριξη της υπηρεσίας σας, είναι πιθανό οι πελάτες σας να μην είναι εξίσου τυχεροί. Ως αποτέλεσμα, τα ιδιόκτητα πρωτόκολλα, όπως αυτά που χρησιμοποιούνται από τα DCOM, CORBA και Java RMI, δεν είναι πρακτικά για εφαρμογές στο Διαδίκτυο.
Το άλλο πρόβλημα, όπως είπα, με αυτές τις τεχνολογίες είναι ότι είναι εγγενώς προσανατολισμένες στη σύνδεση και, ως εκ τούτου, δεν μπορούν να διαχειριστούν ομαλά τις διακοπές του δικτύου. Επειδή το Διαδίκτυο δεν βρίσκεται υπό τον άμεσο έλεγχό σας, δεν μπορείτε να κάνετε υποθέσεις σχετικά με την ποιότητα ή την αξιοπιστία της σύνδεσης. Εάν συμβεί διακοπή του δικτύου, η επόμενη κλήση που θα πραγματοποιήσει ο πελάτης προς τον διακομιστή ενδέχεται να αποτύχει.
Ο προσανατολισμός προς τις συνδέσεις που χαρακτηρίζει αυτές τις τεχνολογίες καθιστά επίσης δύσκολη τη δημιουργία των υποδομών με εξισορρόπηση φορτίου που απαιτούνται για την επίτευξη υψηλής επεκτασιμότητας. Μόλις διακοπεί η σύνδεση μεταξύ του πελάτη και του διακομιστή, δεν είναι δυνατό να δρομολογηθεί απλά το επόμενο αίτημα σε έναν άλλο διακομιστή.
Οι προγραμματιστές έχουν προσπαθήσει να ξεπεράσουν αυτούς τους περιορισμούς αξιοποιώντας ένα μοντέλο που ονομάζεται χωρίς υπηκοότητα προγραμματισμός, αλλά η επιτυχία τους ήταν περιορισμένη, καθώς οι τεχνολογίες αυτές είναι αρκετά βαριές και καθιστούν δαπανηρή την επανασύνδεση με ένα απομακρυσμένο αντικείμενο.
Επειδή η επεξεργασία της πιστωτικής κάρτας ενός πελάτη πραγματοποιείται από έναν απομακρυσμένο διακομιστή στο Διαδίκτυο, το DCOM δεν αποτελεί την ιδανική λύση για τη διευκόλυνση της επικοινωνίας μεταξύ του πελάτη του ηλεκτρονικού εμπορίου και του διακομιστή επεξεργασίας πιστωτικών καρτών. Όπως και σε μια λύση ERP, συχνά εγκαθίσταται ένα στοιχείο τρίτου μέρους εντός του κέντρου δεδομένων του πελάτη (στην περίπτωση αυτή, από τον πάροχο της λύσης επεξεργασίας πιστωτικών καρτών). Το στοιχείο αυτό λειτουργεί ουσιαστικά ως διακομιστής μεσολάβησης (proxy) που διευκολύνει την επικοινωνία μεταξύ του λογισμικού ηλεκτρονικού εμπορίου και της τράπεζας του εμπόρου μέσω ενός ιδιόκτητου πρωτοκόλλου.
Παρατηρείτε κάποιο μοτίβο εδώ; Λόγω των περιορισμών των υφιστάμενων τεχνολογιών όσον αφορά τη διευκόλυνση της επικοινωνίας μεταξύ συστημάτων υπολογιστών, οι προμηθευτές λογισμικού συχνά καταφεύγουν στη δημιουργία της δικής τους υποδομής. Αυτό σημαίνει ότι πόροι που θα μπορούσαν να είχαν χρησιμοποιηθεί για την προσθήκη βελτιωμένων λειτουργιών στο σύστημα ERP ή στο σύστημα επεξεργασίας πιστωτικών καρτών έχουν, αντίθετα, αφιερωθεί στη δημιουργία ιδιόκτητων δικτυακών πρωτοκόλλων.
Σε μια προσπάθεια να υποστηρίξει καλύτερα τέτοια σενάρια στο Διαδίκτυο, η Microsoft υιοθέτησε αρχικά τη στρατηγική της ενίσχυσης των υφιστάμενων τεχνολογιών της, συμπεριλαμβανομένων των COM Internet Services (CIS), οι οποίες επιτρέπουν τη δημιουργία σύνδεσης DCOM μεταξύ του πελάτη και του απομακρυσμένου στοιχείου μέσω της θύρας 80. Για διάφορους λόγους, οι CIS δεν έγιναν ευρέως αποδεκτές.
Έγινε σαφές ότι χρειαζόταν μια νέα προσέγγιση. Έτσι, η Microsoft αποφάσισε να αντιμετωπίσει το πρόβλημα ξεκινώντας από τη βάση. Ας δούμε μερικές από τις απαιτήσεις που έπρεπε να πληροί η λύση για να είναι επιτυχής.
- Διαλειτουργικότητα Η υπηρεσία απομακρυσμένης πρόσβασης πρέπει να μπορεί να χρησιμοποιείται από πελάτες σε άλλες πλατφόρμες.
- Ευχρηστία στο Διαδίκτυο Η λύση θα πρέπει να λειτουργεί ικανοποιητικά για την υποστήριξη πελατών που έχουν πρόσβαση στην απομακρυσμένη υπηρεσία μέσω του Διαδικτύου.
- Διεπαφές με ισχυρό τύπο Δεν πρέπει να υπάρχει καμία αμφιβολία σχετικά με τον τύπο των δεδομένων που αποστέλλονται προς και λαμβάνονται από μια απομακρυσμένη υπηρεσία. Επιπλέον, οι τύποι δεδομένων που ορίζονται από την απομακρυσμένη υπηρεσία θα πρέπει να αντιστοιχούν σε ικανοποιητικό βαθμό στους τύπους δεδομένων που ορίζονται από τις περισσότερες διαδικαστικές γλώσσες προγραμματισμού.
- Δυνατότητα αξιοποίησης των υφιστάμενων προτύπων του Διαδικτύου Η υλοποίηση της υπηρεσίας εξ αποστάσεως θα πρέπει να αξιοποιεί όσο το δυνατόν περισσότερο τα υπάρχοντα πρότυπα του Διαδικτύου και να αποφεύγει την επανεφεύρεση λύσεων για προβλήματα που έχουν ήδη επιλυθεί. Μια λύση που βασίζεται σε ευρέως αποδεκτά πρότυπα του Διαδικτύου μπορεί να αξιοποιήσει τα υπάρχοντα εργαλεία και προϊόντα που έχουν δημιουργηθεί για την εν λόγω τεχνολογία.
- Υποστήριξη για οποιαδήποτε γλώσσα Η λύση δεν πρέπει να είναι στενά συνδεδεμένη με μια συγκεκριμένη γλώσσα προγραμματισμού. Το Java RMI, για παράδειγμα, είναι στενά συνδεδεμένο με τη γλώσσα Java. Θα ήταν δύσκολο να κληθεί μια λειτουργία σε ένα απομακρυσμένο αντικείμενο Java από Visual Basic ή Perl. Ένας πελάτης θα πρέπει να μπορεί να υλοποιήσει μια νέα υπηρεσία Web ή να χρησιμοποιήσει μια υπάρχουσα υπηρεσία Web, ανεξάρτητα από τη γλώσσα προγραμματισμού στην οποία έχει γραφτεί ο πελάτης.
- Υποστήριξη για οποιαδήποτε υποδομή κατανεμημένων στοιχείων Η λύση δεν πρέπει να είναι στενά συνδεδεμένη με μια συγκεκριμένη υποδομή στοιχείων. Στην πραγματικότητα, δεν θα πρέπει να απαιτείται από εσάς να αγοράσετε, να εγκαταστήσετε ή να συντηρήσετε μια υποδομή κατανεμημένων αντικειμένων μόνο και μόνο για να δημιουργήσετε μια νέα απομακρυσμένη υπηρεσία ή να χρησιμοποιήσετε μια υπάρχουσα υπηρεσία. Τα υποκείμενα πρωτόκολλα θα πρέπει να διευκολύνουν ένα βασικό επίπεδο επικοινωνίας μεταξύ υπαρχουσών υποδομών κατανεμημένων αντικειμένων, όπως το DCOM και το CORBA.
Λαμβάνοντας υπόψη τον τίτλο αυτού του βιβλίου, δεν πρέπει να προκαλεί έκπληξη το γεγονός ότι η λύση που δημιούργησε η Microsoft είναι γνωστή ως Υπηρεσίες διαδικτύου. Μια υπηρεσία Web παρέχει μια διεπαφή για την εκτέλεση μιας συγκεκριμένης δραστηριότητας για λογαριασμό του πελάτη. Ο πελάτης μπορεί να έχει πρόσβαση στην υπηρεσία Web μέσω της χρήσης προτύπων του Διαδικτύου.
Βασικά στοιχεία των διαδικτυακών υπηρεσιών
Το παρακάτω διάγραμμα παρουσιάζει τα βασικά δομικά στοιχεία που απαιτούνται για τη διευκόλυνση της απομακρυσμένης επικοινωνίας μεταξύ δύο εφαρμογών.
Ας εξετάσουμε τον σκοπό καθενός από αυτά τα δομικά στοιχεία. Επειδή πολλοί αναγνώστες είναι εξοικειωμένοι με το DCOM, θα αναφερθώ επίσης στο αντίστοιχο στοιχείο του DCOM για κάθε δομικό στοιχείο.
- Ανακάλυψη Η εφαρμογή-πελάτης που χρειάζεται πρόσβαση στις λειτουργίες που παρέχει μια υπηρεσία Web πρέπει να μπορεί να προσδιορίσει τη θέση της απομακρυσμένης υπηρεσίας. Αυτό επιτυγχάνεται μέσω μιας διαδικασίας που γενικά ονομάζεται ανακάλυψη. Η ανίχνευση μπορεί να διευκολυνθεί τόσο μέσω ενός κεντρικού καταλόγου όσο και με πιο ad hoc μεθόδους. Στο DCOM, ο Διαχειριστής Ελέγχου Υπηρεσιών (SCM) παρέχει υπηρεσίες ανίχνευσης.
- Περιγραφή Μόλις προσδιοριστεί το τελικό σημείο μιας συγκεκριμένης υπηρεσίας Web, ο πελάτης χρειάζεται επαρκείς πληροφορίες για να αλληλεπιδράσει σωστά μαζί της. Η περιγραφή μιας υπηρεσίας Web περιλαμβάνει δομημένα μεταδεδομένα σχετικά με τη διεπαφή που προορίζεται να χρησιμοποιηθεί από μια εφαρμογή-πελάτη, καθώς και γραπτή τεκμηρίωση σχετικά με την υπηρεσία Web, συμπεριλαμβανομένων παραδειγμάτων χρήσης. Ένα στοιχείο DCOM εκθέτει δομημένα μεταδεδομένα σχετικά με τις διεπαφές του μέσω μιας βιβλιοθήκης τύπων (typelib). Τα μεταδεδομένα που περιέχονται στη βιβλιοθήκη τύπων ενός στοιχείου αποθηκεύονται σε μια ιδιόκτητη δυαδική μορφή και η πρόσβαση σε αυτά πραγματοποιείται μέσω μιας ιδιόκτητης διεπαφής προγραμματισμού εφαρμογών (API).
- Μορφή μηνύματος Για την ανταλλαγή δεδομένων, ένας πελάτης και ένας διακομιστής πρέπει να συμφωνήσουν σε έναν κοινό τρόπο κωδικοποίησης και μορφοποίησης των μηνυμάτων. Ένας τυποποιημένος τρόπος κωδικοποίησης των δεδομένων διασφαλίζει ότι τα δεδομένα που κωδικοποιούνται από τον πελάτη θα ερμηνευθούν σωστά από τον διακομιστή. Στο DCOM, τα μηνύματα που αποστέλλονται μεταξύ ενός πελάτη και ενός διακομιστή μορφοποιούνται σύμφωνα με το πρωτόκολλο DCOM Object RPC (ORPC).
Χωρίς έναν τυποποιημένο τρόπο μορφοποίησης των μηνυμάτων, η ανάπτυξη ενός συνόλου εργαλείων που θα απαλλάσσει τον προγραμματιστή από τα υποκείμενα πρωτόκολλα είναι σχεδόν αδύνατη. Η δημιουργία ενός επιπέδου αφαίρεσης μεταξύ του προγραμματιστή και των υποκείμενων πρωτοκόλλων επιτρέπει στον προγραμματιστή να επικεντρωθεί περισσότερο στο συγκεκριμένο επιχειρηματικό πρόβλημα και λιγότερο στην υποδομή που απαιτείται για την υλοποίηση της λύσης.
- Κωδικοποίηση Τα δεδομένα που μεταδίδονται μεταξύ του πελάτη και του διακομιστή πρέπει να κωδικοποιηθούν στο σώμα του μηνύματος. Το DCOM χρησιμοποιεί ένα σύστημα δυαδικής κωδικοποίησης για τη σειριοποίηση των δεδομένων που περιέχονται στις παραμέτρους που ανταλλάσσονται μεταξύ του πελάτη και του διακομιστή.
- Μεταφορές Μόλις το μήνυμα διαμορφωθεί και τα δεδομένα μετατραπούν σε σειριακή μορφή στο σώμα του μηνύματος, το μήνυμα πρέπει να μεταφερθεί μεταξύ του πελάτη και του διακομιστή μέσω κάποιου πρωτοκόλλου μεταφοράς. Το DCOM υποστηρίζει μια σειρά ιδιόκτητων πρωτοκόλλων που συνδέονται με διάφορα πρωτόκολλα δικτύου, όπως τα TCP, SPX, NetBEUI και NetBIOS μέσω IPX.
Αποφάσεις σχετικά με τον σχεδιασμό διαδικτυακών υπηρεσιών
Ας συζητήσουμε μερικές από τις σχεδιαστικές επιλογές που κρύβονται πίσω από αυτά τα δομικά στοιχεία των διαδικτυακών υπηρεσιών.
Επιλογή πρωτοκόλλων μεταφοράς
Το πρώτο βήμα ήταν να καθοριστεί ο τρόπος με τον οποίο ο πελάτης και ο διακομιστής θα επικοινωνούσαν μεταξύ τους. Ο πελάτης και ο διακομιστής μπορούν να βρίσκονται στο ίδιο τοπικό δίκτυο (LAN), αλλά ο πελάτης ενδέχεται να επικοινωνεί με τον διακομιστή μέσω του Διαδικτύου. Ως εκ τούτου, το πρωτόκολλο μεταφοράς πρέπει να είναι εξίσου κατάλληλο τόσο για περιβάλλοντα LAN όσο και για το Διαδίκτυο.
Όπως ανέφερα νωρίτερα, τεχνολογίες όπως το DCOM, το CORBA και το Java RMI δεν είναι κατάλληλες για την υποστήριξη της επικοινωνίας μεταξύ του πελάτη και του διακομιστή μέσω του Διαδικτύου. Πρωτόκολλα όπως το Hypertext Transfer Protocol (HTTP) και το Simple Mail Transfer Protocol (SMTP) είναι δοκιμασμένα πρωτόκολλα του Διαδικτύου. Το HTTP ορίζει ένα μοντέλο ανταλλαγής μηνυμάτων τύπου αίτησης/απόκρισης για την υποβολή ενός αιτήματος και τη λήψη της αντίστοιχης απόκρισης. Το SMTP ορίζει ένα πρωτόκολλο ανταλλαγής μηνυμάτων με δυνατότητα δρομολόγησης για ασύγχρονη επικοινωνία. Ας εξετάσουμε γιατί τα πρωτόκολλα HTTP και SMTP είναι κατάλληλα για το Διαδίκτυο.
Οι διαδικτυακές εφαρμογές που βασίζονται στο HTTP είναι εκ φύσεως χωρίς κατάσταση. Δεν βασίζονται σε μια συνεχή σύνδεση μεταξύ του πελάτη και του διακομιστή. Αυτό καθιστά το HTTP ένα ιδανικό πρωτόκολλο για διαμορφώσεις υψηλής διαθεσιμότητας, όπως τα τείχη προστασίας. Εάν ο διακομιστής που διεκπεραίωσε το αρχικό αίτημα του πελάτη καταστεί μη διαθέσιμος, τα επόμενα αιτήματα μπορούν να δρομολογηθούν αυτόματα σε έναν άλλο διακομιστή, χωρίς ο πελάτης να το αντιληφθεί ή να το προσέξει.
Σχεδόν όλες οι εταιρείες διαθέτουν υποδομή που υποστηρίζει το πρωτόκολλο SMTP. Το SMTP είναι ιδιαίτερα κατάλληλο για ασύγχρονη επικοινωνία. Σε περίπτωση διακοπής της υπηρεσίας, η υποδομή ηλεκτρονικού ταχυδρομείου χειρίζεται αυτόματα τις επαναληπτικές προσπάθειες. Σε αντίθεση με το HTTP, μπορείτε να προωθήσετε μηνύματα SMTP σε έναν τοπικό διακομιστή αλληλογραφίας, ο οποίος θα επιχειρήσει να παραδώσει το μήνυμα εκ μέρους σας.
Το άλλο σημαντικό πλεονέκτημα τόσο του HTTP όσο και του SMTP είναι η ευρεία διάδοσή τους. Οι εργαζόμενοι έχουν συνηθίσει να βασίζονται τόσο στο ηλεκτρονικό ταχυδρομείο όσο και στους περιηγητές ιστού τους, ενώ οι διαχειριστές δικτύων αισθάνονται μεγάλη άνεση στην υποστήριξη αυτών των υπηρεσιών. Τεχνολογίες όπως η μετάφραση διευθύνσεων δικτύου (NAT) και οι διακομιστές μεσολάβησης (proxy) παρέχουν τη δυνατότητα πρόσβασης στο Διαδίκτυο μέσω HTTP από εταιρικά τοπικά δίκτυα (LAN) που, διαφορετικά, θα ήταν απομονωμένα. Οι διαχειριστές συχνά διαθέτουν έναν διακομιστή SMTP που βρίσκεται εντός του τείχους προστασίας. Τα μηνύματα που αποστέλλονται σε αυτόν τον διακομιστή στη συνέχεια δρομολογούνται προς τον τελικό προορισμό τους μέσω του Διαδικτύου.
Στην περίπτωση του λογισμικού επεξεργασίας συναλλαγών με πιστωτικές κάρτες, απαιτείται άμεση απάντηση από την τράπεζα του εμπόρου, προκειμένου να καθοριστεί αν η παραγγελία πρέπει να υποβληθεί στο σύστημα ERP. Το πρωτόκολλο HTTP, με το μοντέλο μηνυμάτων αιτήματος/απάντησης που διαθέτει, είναι ιδιαίτερα κατάλληλο για αυτό το σκοπό.
Τα περισσότερα πακέτα λογισμικού ERP δεν έχουν τη δυνατότητα να διαχειριστούν μεγάλους όγκους παραγγελιών που ενδέχεται να προέρχονται από την εφαρμογή ηλεκτρονικού εμπορίου. Επιπλέον, δεν είναι απαραίτητο οι παραγγελίες να υποβάλλονται στο σύστημα ERP σε πραγματικό χρόνο. Ως εκ τούτου, μπορεί να αξιοποιηθεί το πρωτόκολλο SMTP για την τοποθέτηση των παραγγελιών σε ουρά, ώστε να μπορούν να υποβληθούν σε επεξεργασία διαδοχικά από το σύστημα ERP.
Εάν το σύστημα ERP υποστηρίζει κατανεμημένες συναλλαγές, μια άλλη επιλογή είναι η αξιοποίηση του Microsoft Message Queue Server (MSMQ). Εφόσον η εφαρμογή ηλεκτρονικού εμπορίου και το σύστημα ERP βρίσκονται στο ίδιο τοπικό δίκτυο (LAN), η συνδεσιμότητα μέσω πρωτοκόλλων εκτός Διαδικτύου δεν αποτελεί σημαντικό πρόβλημα. Το πλεονέκτημα του MSMQ έναντι του SMTP είναι ότι τα μηνύματα μπορούν να τοποθετούνται και να αφαιρούνται από την ουρά στο πλαίσιο μιας συναλλαγής. Εάν αποτύχει η προσπάθεια επεξεργασίας ενός μηνύματος που έχει αφαιρεθεί από την ουρά, το μήνυμα θα επανατοποθετηθεί αυτόματα στην ουρά όταν η συναλλαγή διακοπεί.
Επιλογή συστήματος κωδικοποίησης
Τα πρωτόκολλα HTTP και SMTP παρέχουν έναν τρόπο αποστολής δεδομένων μεταξύ του πελάτη και του διακομιστή. Ωστόσο, κανένα από τα δύο δεν καθορίζει τον τρόπο κωδικοποίησης των δεδομένων που περιέχονται στο σώμα του μηνύματος. Η Microsoft χρειαζόταν έναν τυποποιημένο, ανεξάρτητο από πλατφόρμα τρόπο κωδικοποίησης των δεδομένων που ανταλλάσσονται μεταξύ του πελάτη και του διακομιστή.
Επειδή ο στόχος ήταν η αξιοποίηση πρωτοκόλλων που βασίζονται στο Διαδίκτυο, η Extensible Markup Language (XML) ήταν η φυσική επιλογή. Η XML προσφέρει πολλά πλεονεκτήματα, όπως υποστήριξη σε όλες τις πλατφόρμες, ένα κοινό σύστημα τύπων και υποστήριξη για σύνολα χαρακτήρων που αποτελούν βιομηχανικά πρότυπα.
Τα συστήματα δυαδικής κωδικοποίησης, όπως αυτά που χρησιμοποιούνται από τα DCOM, CORBA και Java RMI, πρέπει να αντιμετωπίζουν ζητήματα συμβατότητας μεταξύ διαφορετικών πλατφορμών υλικού. Για παράδειγμα, οι διαφορετικές πλατφόρμες υλικού έχουν διαφορετική εσωτερική δυαδική αναπαράσταση των αριθμών πολλαπλών byte. Οι πλατφόρμες της Intel ταξινομούν τα byte ενός αριθμού πολλαπλών byte σύμφωνα με τη σύμβαση «little endian», ενώ πολλοί επεξεργαστές RISC ταξινομούν τα byte ενός αριθμού πολλαπλών byte σύμφωνα με τη σύμβαση «big endian».
Το XML αποφεύγει τα προβλήματα της δυαδικής κωδικοποίησης, καθώς χρησιμοποιεί ένα σύστημα κωδικοποίησης βασισμένο σε κείμενο που αξιοποιεί τυποποιημένα σύνολα χαρακτήρων. Επίσης, ορισμένα πρωτόκολλα μεταφοράς, όπως το SMTP, μπορούν να περιέχουν μόνο μηνύματα βασισμένα σε κείμενο.
Οι δυαδικές μέθοδοι κωδικοποίησης, όπως αυτές που χρησιμοποιούνται από τα DCOM και CORBA, είναι δυσκίνητες και απαιτούν μια υποστηρικτική υποδομή για να απαλλάξουν τον προγραμματιστή από τις λεπτομέρειες. Το XML είναι πολύ πιο ελαφρύ και ευκολότερο στη διαχείριση, καθώς μπορεί να δημιουργηθεί και να χρησιμοποιηθεί με τη βοήθεια τυπικών τεχνικών ανάλυσης κειμένου.
Επιπλέον, διατίθενται διάφοροι αναλυτές XML που απλοποιούν ακόμη περισσότερο τη δημιουργία και τη χρήση εγγράφων XML σε σχεδόν κάθε σύγχρονη πλατφόρμα. Το XML είναι ελαφρύ και διαθέτει εξαιρετική υποστήριξη από εργαλεία, οπότε η κωδικοποίηση XML προσφέρει απίστευτη εμβέλεια, καθώς σχεδόν οποιοσδήποτε πελάτης σε οποιαδήποτε πλατφόρμα μπορεί να επικοινωνήσει με την υπηρεσία Web σας.
Επιλογή κανόνων μορφοποίησης
Συχνά είναι απαραίτητο να συμπεριληφθούν πρόσθετα μεταδεδομένα στο κύριο σώμα του μηνύματος. Για παράδειγμα, ίσως θελήσετε να συμπεριλάβετε πληροφορίες σχετικά με τον τύπο των υπηρεσιών που πρέπει να παρέχει μια διαδικτυακή υπηρεσία προκειμένου να ικανοποιήσει το αίτημά σας, όπως η συμμετοχή σε μια συναλλαγή ή πληροφορίες δρομολόγησης. Η XML δεν παρέχει κανένα μηχανισμό για τη διάκριση του κύριου σώματος του μηνύματος από τα συναφή δεδομένα του.
Τα πρωτόκολλα μεταφοράς, όπως το HTTP, παρέχουν έναν επεκτάσιμο μηχανισμό για τα δεδομένα κεφαλίδας, αλλά ορισμένα δεδομένα που σχετίζονται με το μήνυμα ενδέχεται να μην είναι ειδικά για το πρωτόκολλο μεταφοράς. Για παράδειγμα, ο πελάτης μπορεί να στείλει ένα μήνυμα που πρέπει να δρομολογηθεί σε πολλαπλούς προορισμούς, ενδεχομένως μέσω διαφορετικών πρωτοκόλλων μεταφοράς. Εάν οι πληροφορίες δρομολόγησης τοποθετούνταν σε μια κεφαλίδα HTTP, θα έπρεπε να μεταφραστούν πριν αποσταλούν στον επόμενο ενδιάμεσο μέσω ενός άλλου πρωτοκόλλου μεταφοράς, όπως το SMTP. Επειδή οι πληροφορίες δρομολόγησης αφορούν συγκεκριμένα το μήνυμα και όχι το πρωτόκολλο μεταφοράς, θα πρέπει να αποτελούν μέρος του μηνύματος.
Το Simple Object Access Protocol (SOAP) παρέχει έναν τρόπο, ανεξάρτητο από το πρωτόκολλο, για τη σύνδεση των πληροφοριών της κεφαλίδας με το κύριο σώμα του μηνύματος. Κάθε μήνυμα SOAP πρέπει να ορίζει έναν φάκελο. Ο φάκελος διαθέτει ένα κύριο σώμα που περιέχει το ωφέλιμο φορτίο του μηνύματος και μια κεφαλίδα που μπορεί να περιέχει μεταδεδομένα που σχετίζονται με το μήνυμα.
Το SOAP δεν επιβάλλει περιορισμούς στον τρόπο μορφοποίησης του σώματος του μηνύματος. Αυτό αποτελεί πιθανό πρόβλημα, καθώς χωρίς έναν συνεπή τρόπο κωδικοποίησης των δεδομένων, είναι δύσκολο να αναπτυχθεί ένα σύνολο εργαλείων που να σας απαλλάσσει από τα υποκείμενα πρωτόκολλα. Ίσως χρειαστεί να αφιερώσετε αρκετό χρόνο για να εξοικειωθείτε με τη διεπαφή της υπηρεσίας Web, αντί να επιλύσετε το συγκεκριμένο επιχειρηματικό πρόβλημα.
Αυτό που χρειαζόταν ήταν ένας τυποποιημένος τρόπος μορφοποίησης ενός μηνύματος απομακρυσμένης κλήσης διαδικασίας (RPC) και κωδικοποίησης της λίστας των παραμέτρων του. Αυτό ακριβώς παρέχει το Κεφάλαιο 7 της προδιαγραφής SOAP. Περιγράφει μια τυποποιημένη σύμβαση ονοματολογίας και έναν τυποποιημένο τρόπο κωδικοποίησης για μηνύματα που αφορούν διαδικασίες.
Επειδή το SOAP παρέχει μια τυποποιημένη μορφή για τη μετατροπή των δεδομένων σε μήνυμα XML, πλατφόρμες όπως το ASP.NET και το Remoting μπορούν να αναλάβουν για εσάς τις λεπτομέρειες.
Επιλογή μηχανισμών περιγραφής
Το SOAP παρέχει έναν τυποποιημένο τρόπο μορφοποίησης των μηνυμάτων που ανταλλάσσονται μεταξύ της υπηρεσίας Web και του πελάτη. Ωστόσο, ο πελάτης χρειάζεται πρόσθετες πληροφορίες για να σειριοποιήσει σωστά το αίτημα και να ερμηνεύσει την απάντηση. Το XML Schema παρέχει ένα μέσο για τη δημιουργία σχημάτων που μπορούν να χρησιμοποιηθούν για την περιγραφή του περιεχομένου ενός μηνύματος.
Το XML Schema παρέχει ένα βασικό σύνολο ενσωματωμένων τύπων δεδομένων που μπορούν να χρησιμοποιηθούν για την περιγραφή του περιεχομένου ενός μηνύματος. Μπορείτε επίσης να δημιουργήσετε τους δικούς σας τύπους δεδομένων. Για παράδειγμα, η εμπορική τράπεζα μπορεί να δημιουργήσει έναν σύνθετο τύπο δεδομένων για να περιγράψει το περιεχόμενο και τη δομή του σώματος ενός μηνύματος που χρησιμοποιείται για την υποβολή αιτήματος πληρωμής με πιστωτική κάρτα.
Ένα σχήμα περιέχει ένα σύνολο ορισμών τύπων δεδομένων και στοιχείων. Μια υπηρεσία Web χρησιμοποιεί το σχήμα όχι μόνο για να καθορίσει τον τύπο των δεδομένων που αναμένεται να περιλαμβάνονται σε ένα μήνυμα, αλλά και για να επαληθεύει την εγκυρότητα των εισερχόμενων και εξερχόμενων μηνυμάτων.
Ωστόσο, ένα σχήμα από μόνο του δεν παρέχει επαρκείς πληροφορίες για την αποτελεσματική περιγραφή μιας υπηρεσίας Web. Το σχήμα δεν περιγράφει τα πρότυπα μηνυμάτων μεταξύ του πελάτη και του διακομιστή. Για παράδειγμα, ένας πελάτης πρέπει να γνωρίζει αν θα λάβει απάντηση όταν υποβάλλεται μια παραγγελία στο σύστημα ERP. Ένας πελάτης πρέπει επίσης να γνωρίζει μέσω ποίου πρωτοκόλλου μεταφοράς η υπηρεσία Web αναμένει να λάβει αιτήματα. Τέλος, ο πελάτης πρέπει να γνωρίζει τη διεύθυνση στην οποία είναι προσβάσιμη η υπηρεσία Web.
Αυτές οι πληροφορίες παρέχονται μέσω ενός εγγράφου Web Services Description Language (WSDL). Το WSDL είναι ένα έγγραφο XML που περιγράφει αναλυτικά μια συγκεκριμένη διαδικτυακή υπηρεσία. Εργαλεία όπως το ASP.NET WSDL.exe και το Remoting SOAPSUDS.exe μπορούν να επεξεργαστούν το WSDL και να δημιουργήσουν αυτόματα διαμεσολαβητές για τον προγραμματιστή.
Όπως συμβαίνει με κάθε στοιχείο που χρησιμοποιείται για την ανάπτυξη λογισμικού, έτσι και μια διαδικτυακή υπηρεσία θα πρέπει να συνοδεύεται από γραπτή τεκμηρίωση για τους προγραμματιστές που αναπτύσσουν εφαρμογές με βάση τη συγκεκριμένη διαδικτυακή υπηρεσία. Η τεκμηρίωση θα πρέπει να περιγράφει τη λειτουργία της διαδικτυακής υπηρεσίας, τις διεπαφές που διαθέτει, καθώς και μερικά παραδείγματα χρήσης της. Η καλή τεκμηρίωση είναι ιδιαίτερα σημαντική όταν η διαδικτυακή υπηρεσία διατίθεται σε πελάτες μέσω του Διαδικτύου.
Επιλογή μηχανισμών ανακάλυψης
Αφού αναπτύξετε και τεκμηριώσετε μια διαδικτυακή υπηρεσία, πώς μπορούν οι πιθανοί πελάτες να την εντοπίσουν; Αν η διαδικτυακή υπηρεσία έχει σχεδιαστεί για να χρησιμοποιείται από ένα μέλος της ομάδας ανάπτυξης σας, η προσέγγισή σας μπορεί να είναι αρκετά ανεπίσημη, όπως για παράδειγμα να μοιραστείτε τη διεύθυνση URL του εγγράφου WSDL με έναν συνάδελφό σας που κάθεται μερικά γραφεία πιο πέρα. Όταν όμως οι πιθανοί πελάτες βρίσκονται στο Διαδίκτυο, η αποτελεσματική προώθηση της υπηρεσίας Web σας είναι μια εντελώς διαφορετική ιστορία.
Αυτό που χρειάζεται είναι ένας κοινός τρόπος για την προβολή των διαδικτυακών υπηρεσιών. Το Universal Description, Discovery, and Integration (UDDI) παρέχει ακριβώς έναν τέτοιο μηχανισμό. Το UDDI είναι μια κεντρική υπηρεσία καταλόγου που αποτελεί βιομηχανικό πρότυπο και μπορεί να χρησιμοποιηθεί για την προβολή και τον εντοπισμό υπηρεσιών Web. Το UDDI επιτρέπει στους χρήστες να αναζητούν υπηρεσίες Web χρησιμοποιώντας μια σειρά κριτηρίων αναζήτησης, όπως το όνομα της εταιρείας, την κατηγορία και τον τύπο της υπηρεσίας Web.
Οι διαδικτυακές υπηρεσίες μπορούν επίσης να προβάλλονται μέσω του DISCO, μιας ιδιόκτητης μορφής εγγράφου XML που ορίστηκε από τη Microsoft και επιτρέπει στους ιστότοπους να προβάλλουν τις υπηρεσίες που διαθέτουν. Το DISCO ορίζει ένα απλό πρωτόκολλο που διευκολύνει την εύρεση πόρων με τη μορφή υπερσυνδέσμων. Ο κύριος χρήστης του DISCO είναι το Microsoft Visual Studio.NET. Ένας προγραμματιστής μπορεί να στοχεύσει έναν συγκεκριμένο διακομιστή ιστού και να περιηγηθεί στις διάφορες υπηρεσίες ιστού που διαθέτει ο διακομιστής.
Τι λείπει από τις διαδικτυακές υπηρεσίες;
Ίσως έχετε παρατηρήσει ότι ορισμένα βασικά στοιχεία μιας υποδομής κατανεμημένων στοιχείων δεν ορίζονται από τις υπηρεσίες Web. Δύο από τις πιο εμφανείς παραλείψεις είναι ένα σαφώς καθορισμένο API για τη δημιουργία και τη χρήση υπηρεσιών Web, καθώς και ένα σύνολο υπηρεσιών στοιχείων, όπως η υποστήριξη κατανεμημένων συναλλαγών. Ας εξετάσουμε καθένα από αυτά τα στοιχεία που λείπουν.
- API ειδικά για διαδικτυακές υπηρεσίες Οι περισσότερες υποδομές κατανεμημένων στοιχείων ορίζουν ένα API για την εκτέλεση εργασιών όπως η αρχικοποίηση του περιβάλλοντος εκτέλεσης, η δημιουργία μιας παρουσίας ενός στοιχείου και η απεικόνιση των μεταδεδομένων που χρησιμοποιούνται για την περιγραφή του στοιχείου. Επειδή οι περισσότερες γλώσσες προγραμματισμού υψηλού επιπέδου παρέχουν κάποιο βαθμό διαλειτουργικότητας με τη C, το API συνήθως διατίθεται ως ένα επίπεδο σύνολο υπογραφών μεθόδων της C. Το RMI φτάνει στο σημείο να συνδέει στενά το API του με μία και μόνο γλώσσα υψηλού επιπέδου, τη Java.
Σε μια προσπάθεια να διασφαλίσει ότι οι διαδικτυακές υπηρεσίες είναι ανεξάρτητες από τη γλώσσα προγραμματισμού, η Microsoft άφησε στους μεμονωμένους προμηθευτές λογισμικού την ευχέρεια να συνδέσουν την υποστήριξη των διαδικτυακών υπηρεσιών με μια συγκεκριμένη πλατφόρμα. Θα αναφερθώ σε δύο υλοποιήσεις διαδικτυακών υπηρεσιών για την πλατφόρμα .NET, το ASP.NET και το Remoting, σε επόμενο κεφάλαιο του βιβλίου.
- Υπηρεσίες συστατικών στοιχείων Η πλατφόρμα υπηρεσιών Ιστού δεν παρέχει πολλές από τις υπηρεσίες που συνήθως συναντώνται σε υποδομές κατανεμημένων στοιχείων, όπως η διαχείριση του κύκλου ζωής απομακρυσμένων αντικειμένων, η συγκέντρωση αντικειμένων και η υποστήριξη κατανεμημένων συναλλαγών. Η υλοποίηση αυτών των υπηρεσιών επαφίεται στην υποδομή κατανεμημένων στοιχείων.
Ορισμένες υπηρεσίες, όπως η υποστήριξη κατανεμημένων συναλλαγών, μπορούν να εισαχθούν αργότερα, καθώς η τεχνολογία ωριμάζει. Άλλες, όπως η συγκέντρωση αντικειμένων και, ενδεχομένως, η διαχείριση του κύκλου ζωής των αντικειμένων, μπορούν να θεωρηθούν λεπτομέρειες υλοποίησης της πλατφόρμας. Για παράδειγμα, το Remoting ορίζει επεκτάσεις για την παροχή υποστήριξης στη διαχείριση του κύκλου ζωής των αντικειμένων, ενώ το Microsoft Component Services παρέχει υποστήριξη για τη συγκέντρωση αντικειμένων.
Περίληψη
Ο προγραμματισμός με βάση τα στοιχεία έχει αποδειχθεί ότι αποτελεί μεγάλο πλεονέκτημα για την παραγωγικότητα των προγραμματιστών, αλλά ορισμένες υπηρεσίες δεν μπορούν να ενσωματωθούν σε ένα στοιχείο που βρίσκεται στο κέντρο δεδομένων του πελάτη. Οι παλαιότερες τεχνολογίες, όπως το DCOM, το CORBA και το Java RMI, δεν είναι κατάλληλες για να επιτρέπουν στους πελάτες να έχουν πρόσβαση σε υπηρεσίες μέσω του Διαδικτύου, οπότε η Microsoft θεώρησε απαραίτητο να ξεκινήσει από το μηδέν και να δημιουργήσει έναν τρόπο πρόσβασης σε απομακρυσμένες υπηρεσίες που θα αποτελεί βιομηχανικό πρότυπο.
Υπηρεσίες διαδικτύου είναι ένας γενικός όρος που περιγράφει ένα σύνολο πρωτοκόλλων και υπηρεσιών που αποτελούν βιομηχανικό πρότυπο και χρησιμοποιούνται για τη διευκόλυνση ενός βασικού επιπέδου διαλειτουργικότητας μεταξύ εφαρμογών. Η υποστήριξη που έχουν λάβει οι διαδικτυακές υπηρεσίες από τον κλάδο είναι άνευ προηγουμένου. Ποτέ στο παρελθόν δεν είχαν κινητοποιηθεί τόσες πολλές κορυφαίες εταιρείες τεχνολογίας για να υποστηρίξουν ένα πρότυπο που διευκολύνει τη διαλειτουργικότητα μεταξύ εφαρμογών, ανεξάρτητα από την πλατφόρμα στην οποία εκτελούνται.
Ένας από τους παράγοντες που συμβάλλουν στην επιτυχία των διαδικτυακών υπηρεσιών είναι το γεγονός ότι βασίζονται σε υπάρχοντα πρότυπα του Διαδικτύου, όπως το XML και το HTTP. Ως αποτέλεσμα, οποιοδήποτε σύστημα είναι σε θέση να αναλύει κείμενο και να επικοινωνεί μέσω ενός τυποποιημένου πρωτοκόλλου μεταφοράς δεδομένων του Διαδικτύου μπορεί να επικοινωνήσει με μια διαδικτυακή υπηρεσία. Οι εταιρείες μπορούν επίσης να αξιοποιήσουν τις επενδύσεις που έχουν ήδη πραγματοποιήσει σε αυτές τις τεχνολογίες.