Μια τυποποιημένη περιγραφή καθιστά ευκολότερη την κατανόηση και τη χρήση. Ας πούμε ότι έχετε βρει μια υπηρεσία που λύνει τα προβλήματα που χρειάζεστε και θέλετε να τη χρησιμοποιήσετε στις λύσεις σας. Ο ευκολότερος τρόπος για να λάβετε πληροφορίες σχετικά με το σχέδιο κάποιου άλλου και τις δυνατότητές του είναι να δείτε την περιγραφή του WSDL. Τα έγγραφα WSDL μπορούν να αποτελούνται από πολλαπλές ενότητες ή να αναφέρονται σε άλλα έγγραφα ή Σχήματα XML (XSD) που περιγράφουν τους τύπους δεδομένων που χρησιμοποιούνται στην υπηρεσία Ιστού. Αρχικά, προτάθηκαν διάφορες επιλογές για τη διατήρηση μιας περιγραφής και δύο σημαντικοί παίκτες - η Microsoft και η IBM - παρουσίασαν το όραμά τους για αυτό το πρόβλημα. Ο πρώτος ανέπτυξε και πρότεινε την SDL (Service Description Language), η οποία συμπεριλήφθηκε στην πρώτη έκδοση του SOAP Toolkit της εταιρείας. Η IBM παρουσίασε το όραμά της για το πρόβλημα στο Network NASSL (Accessible Service Specification Language), το οποίο εφαρμόστηκε στο SOAP4J ως ένα σύνολο NASSL Toolkit. Οι ιδέες που προτάθηκαν στο NASSL ενέπνευσαν τη Microsoft να συνεχίσει να αναπτύσσει τη γλώσσα περιγραφής, με αποτέλεσμα τη γέννηση του SOAP Contract Language (SCL). Αυτή η λύση αποδείχθηκε πολύ αποτελεσματική, βελτιώθηκε λαμβάνοντας υπόψη τις επιθυμίες τρίτων κατασκευαστών και στις 15 Μαρτίου 2001, οι ιδέες έγιναν οι προδιαγραφές WSDL 1.1. Φυσικά, το πεδίο των υπολογιστών δεν μπορεί να ζήσει τόσα πολλά χρόνια χωρίς αλλαγές, οπότε η έκδοση 2.0 εμφανίστηκε στις 27 Μαρτίου 2006 και από τις 26 Ιουνίου 2007 έχει συμβουλευτικό χαρακτήρα.

Αναφορά εντολών Unix/Linux

Ιστορία

Το WSDL 1.0 (Σεπτέμβριος 2000) αναπτύχθηκε από την IBM, τη Microsoft και την Ariba για να περιγράψει τις υπηρεσίες Ιστού για την εργαλειοθήκη SOAP.

WSDL 1.1, που κυκλοφόρησε τον Μάρτιο του 2001. Στην πραγματικότητα, αυτό είναι ένα επίσημο WSDL 1.0. Δεν υπάρχουν θεμελιώδεις διαφορές μεταξύ αυτών των εκδόσεων.

Το WSDL 1.2 (Ιούνιος 2003) εξακολουθεί να λειτουργεί υπό το W3C. Το WSDL 1.2 δεν υποστηρίζεται από τους περισσότερους προμηθευτές SOAP.

Το WSDL 2.0 έλαβε επίσημη υποστήριξη από το W3C τον Ιούνιο του 2007. Το WSDL 1.2 μετονομάστηκε σε WSDL 2.0 επειδή είχε σημαντικές διαφορές από την προηγούμενη έκδοση.

Σχεδιασμός Υπηρεσιών Ιστού

Η χρήση του όρου Web services από τον συγγραφέα αναφέρεται αποκλειστικά στο είδος της τεχνολογίας που εστιάζει στην αλληλεπίδραση. Αυτό σημαίνει ότι αυτή η τεχνολογία είναι τυποποιημένη: τα ετερογενή συστήματα λειτουργούν μόνο εάν υπάρχουν ανοιχτά πρότυπα. Σε αυτήν την περίπτωση, το σχετικό ερώτημα είναι: οι υπηρεσίες Ιστού θα είναι η λύση στο πρόβλημά σας; Σήμερα, η λέξη «Υπηρεσίες Ιστού» δεν είναι πλέον αρκετή για να μιλήσει για την αξιοπιστία της εταιρείας που τις χρησιμοποιεί, επομένως θα ήταν καλύτερο να υπάρχουν άλλοι επιτακτικοί λόγοι για τη χρήση τους. Εάν ελέγχετε και τα δύο άκρα του καναλιού, είναι πιθανό να υπάρχουν καλύτερες τεχνολογίες. Τώρα είναι μόλις η αυγή της εποχής των ανοιχτών προτύπων για την κατανεμημένη επεξεργασία δεδομένων. Ως εκ τούτου, το κόστος υποστήριξης των υπηρεσιών Ιστού σε αυτήν την ακόμη αδιαμόρφωτη αγορά παραμένει υψηλό - αυτό σημαίνει μείωση της παραγωγικότητας, αύξηση του κόστους ανάπτυξης και επιδείνωση της ασφάλειας. Η ιδέα ότι οι υπηρεσίες Ιστού είναι «φιλικές με το τείχος προστασίας» είναι παραπλανητική. Πράγματι, τα συμβατικά τείχη προστασίας προστατεύουν τα εταιρικά περιουσιακά στοιχεία από εισβολείς που εκμεταλλεύονται τις αδυναμίες του λογισμικού εφαρμογών που δημιουργούνται ανοίγοντας θύρες στις οποίες εκτελούνται προστατευμένες υπηρεσίες. Από την άλλη πλευρά, οι υπηρεσίες Ιστού εκθέτουν λογισμικό εφαρμογών μέσω αυτών των θυρών.

Με άλλα λόγια, αποδυναμώνουν την ασφάλεια επιτρέποντας σε μη εξουσιοδοτημένα άτομα πρόσβαση σε εφαρμογές - αυτό ακριβώς που θα μπορούσε να αποτρέψει ένα τείχος προστασίας δικτύου. Επομένως, χρειάζεται μια νέα γενιά τείχη προστασίας. Υπάρχουν ήδη αρκετοί νέοι παίκτες στην αγορά που προσφέρουν τέτοια προϊόντα. Οι συμβατικοί προμηθευτές τείχους προστασίας αρχίζουν επίσης να δίνουν προσοχή σε αυτό το πρόβλημα. Αλλά αυτό είναι μόνο η αρχή, και μια τέτοια τεχνολογία δεν έχει ακόμη αποδειχθεί. Ακόμα κι αν σκοπεύετε να χρησιμοποιήσετε υπηρεσίες Ιστού, πρέπει να θυμάστε ότι δεν χρειάζεται να χρησιμοποιήσετε το SOAP. Για παράδειγμα, ο συγγραφέας αυτού του άρθρου έχει δει φόρμες να περνούν ως όρισμα αίτησης κλήσης απομακρυσμένης διαδικασίας SOAP (SOAP-RPC). Συνάντησε επίσης φόρμες που επιστράφηκαν ως μέρος μιας απόκρισης κλήσης απομακρυσμένης διαδικασίας SOAP. Δεν μπόρεσε ποτέ να βρει κάποιο πρόσθετο όφελος από τη χρήση του SOAP. Εάν τα κατανεμημένα στοιχεία μπορούν να αναπτυχθούν σε διαφορετικές γλώσσες προγραμματισμού, τότε απαιτείται μια γλώσσα προγραμματισμού ουδέτερης γλώσσας ορισμού διεπαφής (IDL) για να καθοριστεί ο τρόπος χρήσης των υπηρεσιών. Η CORBA (Common Object Request Broker Architecture), καθώς και το DCOM (Distributed Component Object Model), έχουν μια τέτοια γλώσσα. Το IDL είναι μια σύμβαση μεταξύ του εκκινητή υπηρεσίας και του παρόχου, αλλά συλλέγει μόνο τη σύνταξη. Η σημασιολογία παραμένει ασαφής: η IDL αφήνει ανοιχτό το ερώτημα του τι κάνει η υπηρεσία. Το WSDL είναι το IDL των υπηρεσιών Ιστού. Περιγράφει τον τρόπο κλήσης υπηρεσιών Web. Καθορίζει επίσης τις απαντήσεις που μπορεί να ληφθούν ή να μην ληφθούν όταν η κλήση είναι επιτυχής.

Η προδιαγραφή WSDL ρυθμίζει αυστηρά τη μορφή των μηνυμάτων, τα πρωτόκολλα που χρησιμοποιούνται και τη διεύθυνση όπου βρίσκονται οι υπηρεσίες. Δυστυχώς, ακόμη και μια σαφής και αυστηρή περιγραφή στο WSDL δεν εγγυάται υψηλή ποιότητα σχεδίασης. Όπως όλες οι γλώσσες IDL, η WSDL είναι ισχυρή στη σύνταξη και αδύναμη στη σημασιολογία. Ωστόσο, δεν πρέπει να παραμεληθούν - τελικά είναι η σημασιολογία που είναι σημαντική, ενώ η σύνταξη χρησιμοποιείται απλώς για να την αποκαλύψει.

Σχεδιασμός διεπαφής

Πριν ξεκινήσετε τη σύνταξη WSDL, πρέπει να συμφωνήσετε με τους πελάτες σας τι πρέπει να κάνει η υπηρεσία Web. Οι περιπτώσεις χρήσης πρέπει να καταγράφονται, προσδιορίζοντας με σαφήνεια τον τρόπο με τον οποίο η υπηρεσία αλληλεπιδρά με το περιβάλλον της. Ας υποθέσουμε ότι ένα πρόγραμμα πράκτορα (actor) καλεί μια υπηρεσία Ιστού για κάποιο σκοπό. Σε αυτήν την περίπτωση, πρέπει να δημιουργήσετε όχι μόνο ένα σενάριο "ηλιόλουστης ημέρας", το οποίο υλοποιεί την εργασία, αλλά ένα σενάριο "βροχερής ημέρας", όταν το αποτέλεσμα είναι αρνητικό. Ποιες εγγυήσεις μπορεί να προσφέρει το σύστημα ότι ο στόχος έχει επιτευχθεί με επιτυχία; Και πότε όχι; Πού είναι η γραμμή ευθύνης μεταξύ πελάτη και διακομιστή; Η σημασία του σαφούς καθορισμού των απαιτήσεων δεν μπορεί να υπερεκτιμηθεί. Σε αυτό το στάδιο αξίζει να σκεφτούμε τον σκοπό του έργου. Τι ακριβώς είναι; Ποια δεδομένα πρέπει να ληφθούν από τον πελάτη και τι πρέπει να παρέχει ο διακομιστής; Κάνοντας λάθος σε αυτό το βήμα μπορεί να οδηγήσει σε σημαντικό κόστος. Για παράδειγμα, εξετάστε μια υπηρεσία Web που λαμβάνει ως παραμέτρους μια λίστα εγκατεστημένων προγραμμάτων και την ποσότητα του ελεύθερου χώρου στο δίσκο. Αυτή η υπηρεσία θα πρέπει στη συνέχεια να επιστρέψει μια λίστα εφαρμογών προς ενημέρωση.

Εάν υπάρχει αρκετός χώρος, δεν υπάρχουν προβλήματα. Ωστόσο, τι γίνεται αν δεν είναι αρκετό; Πώς μπορώ να επιλέξω τα προϊόντα για τα οποία πρέπει να εγκαταστήσω νέες εκδόσεις; Υποτίθεται ο πελάτης να διαγράφει μόνος του παλιές εκδόσεις προγραμμάτων για να αφήσει χώρο για νέες; Δεν πρόκειται για εύκολες ερωτήσεις, η λύση των οποίων θα απαιτήσει την ανάπτυξη πολύπλοκων αλγορίθμων, η υλοποίηση των οποίων μπορεί να συνεπάγεται σφάλματα. Φυσικά, κανένα σύστημα δεν πρέπει να ορίζεται με αυτόν τον τρόπο. Ο διακομιστής πρέπει να παρέχει μια λίστα εφαρμογών, τις εξαρτήσεις μεταξύ τους και τις απαιτήσεις πόρων που κάνουν. Είναι ευθύνη του πελάτη να αποφασίσει ποιο πακέτο θα εγκαταστήσει. Επομένως, με την ανάθεση αυτής της εργασίας στον διακομιστή, ο πελάτης δεν θα κερδίσει τίποτα, θα αυξήσει μόνο το κόστος ανάπτυξης του τμήματος διακομιστή. Επομένως, είναι απαραίτητο να γίνει μια ανάλυση κόστους στο αρχικό στάδιο. Σε αυτήν την περίπτωση, μπορείτε να αγνοήσετε τις τεχνικές λεπτομέρειες - η υπηρεσία μπορεί να προβληθεί ως μαύρο κουτί. Αλλά δεν μπορούμε να παραμελήσουμε τις λεπτομέρειες σχετικά με την αλληλεπίδραση μεταξύ αυτής της υπηρεσίας και του περιβάλλοντός της. Το επόμενο βήμα είναι να αναλυθεί ο τρόπος με τον οποίο μπορούν να εφαρμοστούν οι περιπτώσεις χρήσης.

Θα υπάρχει μια ενιαία διεπαφή (portType στην έκδοση WSDL 1.1) που να παρέχει όλη τη λειτουργικότητα; Ή πολλαπλές διεπαφές; Κάθε διεπαφή μπορεί να προσφερθεί σε πολλαπλά τελικά σημεία, αλλά γενικά πρέπει να είναι αδιαίρετη. Δηλαδή, το τελικό σημείο πρέπει να παρέχει είτε όλη τη λειτουργικότητα είτε τίποτα. Ομοίως, η διεπαφή πρέπει να είναι σημασιολογικά συνεπής. Τα παραπάνω αποτελούν κατευθυντήρια γραμμή και θέμα κοινής λογικής, αν και τίποτα στην προδιαγραφή WSDL δεν εμποδίζει μια διαφορετική ερμηνεία. Απαιτούνται υποστηρικτικές διεπαφές; Πώς και πότε πρέπει να καλούνται; Ποια είναι η φύση αυτής της εξάρτησης; Δεν υπάρχουν ακόμη πρότυπα, μόνο συστάσεις για το πώς να χειρίζεστε «χορογραφίες υπηρεσιών», πώς να επιτρέπετε στις υπηρεσίες να υπερσυνδέονται με άλλες υπηρεσίες. Με άλλα λόγια, πρόκειται για μια ανεξερεύνητη προβληματική περιοχή.

Ο τίτλος του θέματος είναι πραγματικά μια ερώτηση, γιατί... Ο ίδιος δεν ξέρω τι είναι και για πρώτη φορά θα προσπαθήσω να το δουλέψω στο πλαίσιο αυτού του άρθρου. Το μόνο πράγμα που μπορώ να εγγυηθώ είναι ότι ο κώδικας που παρουσιάζεται παρακάτω θα λειτουργήσει, αλλά οι φράσεις μου θα είναι μόνο υποθέσεις και εικασίες για το πώς εγώ ο ίδιος καταλαβαίνω όλα αυτά. Πάμε λοιπόν...

Εισαγωγή

Πρέπει να ξεκινήσουμε με το γιατί δημιουργήθηκε η έννοια των διαδικτυακών υπηρεσιών. Μέχρι τη στιγμή που εμφανίστηκε αυτή η ιδέα στον κόσμο, υπήρχαν ήδη τεχνολογίες που επέτρεπαν στις εφαρμογές να αλληλεπιδρούν εξ αποστάσεως, όπου ένα πρόγραμμα μπορούσε να καλέσει κάποια μέθοδο σε άλλο πρόγραμμα, το οποίο θα μπορούσε να ξεκινήσει σε έναν υπολογιστή που βρίσκεται σε άλλη πόλη ή ακόμη και χώρα. Όλα αυτά συντομεύονται ως RPC (Remote Procedure Calling). Παραδείγματα περιλαμβάνουν τεχνολογίες CORBA και για Java - RMI (Remote Method Invoking). Και όλα δείχνουν να είναι καλά σε αυτούς, ειδικά στην CORBA, γιατί... Μπορείτε να εργαστείτε με αυτό σε οποιαδήποτε γλώσσα προγραμματισμού, αλλά κάτι έλειπε ακόμα. Πιστεύω ότι το μειονέκτημα του CORBA είναι ότι λειτουργεί μέσω ορισμένων δικών του πρωτοκόλλων δικτύου αντί για απλό HTTP, το οποίο θα χωράει σε οποιοδήποτε τείχος προστασίας. Η ιδέα της διαδικτυακής υπηρεσίας ήταν να δημιουργήσει ένα RPC που θα εισαγόταν σε πακέτα HTTP. Έτσι ξεκίνησε η ανάπτυξη του προτύπου. Ποιες είναι οι βασικές έννοιες αυτού του προτύπου:

1. ΣΑΠΟΥΝΙ. Πριν καλέσετε μια απομακρυσμένη διαδικασία, πρέπει να περιγράψετε αυτήν την κλήση σε ένα αρχείο XML σε μορφή SOAP. Το SOAP είναι απλώς μια από τις πολλές σημάνσεις XML που χρησιμοποιούνται σε υπηρεσίες web. Όλα όσα θέλουμε να στείλουμε κάπου μέσω HTTP μετατρέπονται πρώτα σε περιγραφή XML SOAP, στη συνέχεια γεμίζονται σε ένα πακέτο HTTP και αποστέλλονται σε άλλον υπολογιστή στο δίκτυο μέσω TCP/IP.
2. WSDL. Υπάρχει μια διαδικτυακή υπηρεσία, δηλ. ένα πρόγραμμα του οποίου οι μέθοδοι μπορούν να καλούνται εξ αποστάσεως. Αλλά το πρότυπο απαιτεί αυτό το πρόγραμμα να συνοδεύεται από μια περιγραφή που λέει ότι "ναι, έχετε δίκιο - αυτή είναι πραγματικά μια υπηρεσία web και μπορείτε να καλέσετε τέτοιες και τέτοιες μεθόδους από αυτήν." Αυτή η περιγραφή αντιπροσωπεύεται από ένα άλλο αρχείο XML, το οποίο έχει διαφορετική μορφή, δηλαδή το WSDL. Εκείνοι. Το WSDL είναι απλώς ένα αρχείο XML που περιγράφει μια υπηρεσία Ιστού και τίποτα περισσότερο.

Γιατί τόσο συνοπτικά ρωτάς; Δεν μπορείς να γίνεις πιο συγκεκριμένος; Είναι πιθανώς δυνατό, αλλά για να το κάνετε αυτό θα πρέπει να απευθυνθείτε σε βιβλία όπως το T. Mashnin, "Java Web Services". Εκεί, στις πρώτες 200 σελίδες, υπάρχει μια λεπτομερής περιγραφή κάθε ετικέτας των προτύπων SOAP και WSDL. Αξίζει να το κάνετε; Κατά τη γνώμη μου, όχι γιατί... Όλα αυτά δημιουργούνται αυτόματα στην Java και χρειάζεται μόνο να γράψετε τα περιεχόμενα των μεθόδων που υποτίθεται ότι καλούνται εξ αποστάσεως. Έτσι, ένα API όπως το JAX-RPC εμφανίστηκε στην Java. Αν κάποιος δεν ξέρει, όταν λέει ότι η Java έχει ένα τέτοιο API, σημαίνει ότι υπάρχει ένα πακέτο με ένα σύνολο κλάσεων που ενσωματώνουν την εν λόγω τεχνολογία. Το JAX-RPC εξελίχθηκε με την πάροδο του χρόνου από έκδοση σε έκδοση και τελικά έγινε JAX-WS. Το WS προφανώς σημαίνει WebService και κάποιος μπορεί να σκεφτεί ότι πρόκειται απλώς για μια μετονομασία του RPC ως δημοφιλούς λέξης στις μέρες μας. Αυτό δεν είναι αλήθεια, γιατί Τώρα οι υπηρεσίες web έχουν απομακρυνθεί από την αρχική ιδέα και σας επιτρέπουν όχι μόνο να καλείτε απομακρυσμένες μεθόδους, αλλά και να στέλνετε απλά μηνύματα εγγράφων σε μορφή SOAP. Δεν ξέρω ακόμα γιατί αυτό είναι απαραίτητο, είναι απίθανο η απάντηση εδώ να είναι "μόνο σε περίπτωση που χρειαστεί". Ο ίδιος θα ήθελα να μάθω από πιο έμπειρους συντρόφους. Και τέλος, εμφανίστηκε το JAX-RS για τις λεγόμενες υπηρεσίες RESTful web, αλλά αυτό είναι το θέμα ενός ξεχωριστού άρθρου. Η εισαγωγή μπορεί να τελειώσει εδώ, γιατί... Στη συνέχεια θα μάθουμε να δουλεύουμε με το JAX-WS.

Γενική προσέγγιση

Στις υπηρεσίες web υπάρχει πάντα ένας πελάτης και ένας διακομιστής. Ο διακομιστής είναι η υπηρεσία ιστού μας και μερικές φορές ονομάζεται τελικό σημείο (όπως, το τελικό σημείο όπου φτάνουν τα μηνύματα SOAP από τον πελάτη). Πρέπει να κάνουμε τα εξής:

1. Περιγράψτε τη διεπαφή της υπηρεσίας Ιστού μας
2. Εφαρμογή αυτής της διεπαφής
3. Εκκινήστε την υπηρεσία ιστού μας
4. Γράψτε έναν πελάτη και καλέστε εξ αποστάσεως την επιθυμητή μέθοδο υπηρεσίας web

Μπορείτε να εκκινήσετε μια υπηρεσία Ιστού με διαφορετικούς τρόπους: είτε να περιγράψετε μια κλάση με την κύρια μέθοδο και να εκκινήσετε την υπηρεσία Ιστού απευθείας ως διακομιστής, είτε να την αναπτύξετε σε έναν διακομιστή όπως ο Tomcat ή οποιοσδήποτε άλλος. Στη δεύτερη περίπτωση, εμείς οι ίδιοι δεν εκκινούμε έναν νέο διακομιστή και δεν ανοίγουμε άλλη θύρα στον υπολογιστή, αλλά απλώς πείτε στο κοντέινερ servlet Tomcat ότι «έχουμε γράψει μαθήματα διαδικτυακής υπηρεσίας εδώ, παρακαλούμε δημοσιεύστε τα ώστε όλοι όσοι επικοινωνούν μαζί σας να μπορούν χρησιμοποιήστε τη χρήση της υπηρεσίας web." Ανεξάρτητα από τη μέθοδο εκκίνησης της υπηρεσίας web, θα έχουμε τον ίδιο πελάτη.

Υπηρέτης

Ας ξεκινήσουμε το IDEA και ας δημιουργήσουμε ένα νέο έργο Δημιουργία νέου έργου. Ας υποδείξουμε το όνομα HelloWebServiceκαι πατήστε το κουμπί Επόμενος, μετά κουμπί Φινίρισμα. Σε ένα φάκελο srcας δημιουργήσουμε ένα πακέτο ru.javarush.ws. Σε αυτό το πακέτο θα δημιουργήσουμε τη διεπαφή HelloWebService: πακέτο ru. javarush. ws; // αυτοί είναι σχολιασμοί, δηλ. ένας τρόπος να επισημάνουμε τις τάξεις και τις μεθόδους μας, // σε σχέση με την τεχνολογία υπηρεσιών webεισαγωγή javax. jws. WebMethod; εισαγωγή javax. jws. WebService;εισαγωγή javax. jws. σαπούνι. SOAPBinding; // λέμε ότι η διεπαφή μας θα λειτουργεί ως υπηρεσία web@WebService // λέμε ότι η υπηρεσία Ιστού θα χρησιμοποιηθεί για την κλήση μεθόδων@SOAPBinding (στυλ = SOAPBinding. Στυλ. RPC) δημόσια διεπαφή HelloWebService ( // λέμε ότι αυτή η μέθοδος μπορεί να κληθεί από απόσταση@WebMethod δημόσια συμβολοσειρά getHelloString(Όνομα συμβολοσειράς) ; ) Σε αυτόν τον κώδικα, οι κλάσεις WebService και WebMethod είναι οι λεγόμενοι σχολιασμοί και δεν κάνουν τίποτα εκτός από την επισήμανση της διεπαφής μας και της μεθόδου της ως υπηρεσίας web. Το ίδιο ισχύει και για την κατηγορία SOAPBinding. Η μόνη διαφορά είναι ότι το SOAPBinding είναι ένας σχολιασμός με παραμέτρους. Σε αυτήν την περίπτωση, η παράμετρος στυλ χρησιμοποιείται με μια τιμή που υποδεικνύει ότι η υπηρεσία web δεν θα λειτουργεί μέσω μηνυμάτων εγγράφων, αλλά ως κλασικό RPC, π.χ. για να καλέσετε μια μέθοδο. Ας εφαρμόσουμε τη λογική διεπαφής μας και ας δημιουργήσουμε μια κλάση HelloWebServiceImpl στο πακέτο μας. Παρεμπιπτόντως, σημειώνω ότι ο τερματισμός μιας κλάσης με Impl είναι μια σύμβαση στην Java, σύμφωνα με την οποία η υλοποίηση των διεπαφών ορίζεται έτσι (Impl - από τη λέξη υλοποίηση, δηλ. υλοποίηση). Αυτό δεν είναι απαίτηση και είστε ελεύθεροι να ονομάσετε την τάξη όπως θέλετε, αλλά οι καλοί τρόποι το απαιτούν: πακέτο ru. javarush. ws; // ο ίδιος σχολιασμός όπως όταν περιγράφεται η διεπαφή,@WebService(endpointInterface= "ru.javarush.ws.HelloWebService") δημόσια κλάση HelloWebServiceImpl υλοποιεί το HelloWebService ( @Override public String getHelloString (Όνομα συμβολοσειράς) ( // απλώς επιστρέψτε τον χαιρετισμόεπιστροφή "Γεια, " + όνομα + "!" ; src) ) Ας ξεκινήσουμε την υπηρεσία ιστού μας ως ανεξάρτητος διακομιστής, π.χ. χωρίς τη συμμετοχή οποιουδήποτε διακομιστή Tomcat και εφαρμογών (αυτό είναι ένα θέμα για ξεχωριστή συζήτηση). Για να το κάνετε αυτό, στη δομή του έργου στο φάκελο Ας δημιουργήσουμε ένα πακέτο ru.javarush.endpoint και σε αυτό θα δημιουργήσουμε μια κλάση HelloWebServicePublisher με την κύρια μέθοδο: πακέτο ru. javarush. τελικό σημείο?// κλάση για τη λειτουργία ενός διακομιστή web με υπηρεσίες web εισαγωγή javax. xml. ws. Τελικό σημείο;// κατηγορία της διαδικτυακής μας υπηρεσίας εισαγωγή ru. javarush. ws. HelloWebServiceImpl; δημόσια κλάση HelloWebServicePublisher ( δημόσιο static void main (String... args) ( // εκκίνηση του διακομιστή web στη θύρα 1986// και στη διεύθυνση που καθορίζεται στο πρώτο όρισμα, // εκκίνηση της υπηρεσίας Ιστού που μεταβιβάστηκε στο δεύτερο όρισμαΤελικό σημείο. δημοσιεύω( "http://localhost:1986/wss/hello", νέο HelloWebServiceImpl () );

) ) Τώρα ας εκτελέσουμε αυτήν την κλάση κάνοντας κλικ

Shift+F10 src. Δεν θα εμφανιστεί τίποτα στην κονσόλα, αλλά ο διακομιστής εκτελείται. Μπορείτε να το επαληθεύσετε πληκτρολογώντας τη γραμμή http://localhost:1986/wss/hello?wsdl στο πρόγραμμα περιήγησής σας. Η σελίδα που ανοίγει, αφενός, αποδεικνύει ότι έχουμε έναν διακομιστή web (http://) που εκτελείται στη θύρα 1986 στον υπολογιστή μας (localhost) και, αφετέρου, δείχνει μια περιγραφή WSDL της υπηρεσίας web μας. Εάν διακόψετε την εφαρμογή, η περιγραφή δεν θα είναι διαθέσιμη, όπως και η ίδια η υπηρεσία web, επομένως δεν θα το κάνουμε αυτό, αλλά θα προχωρήσουμε στη σύνταξη του πελάτη. Πελάτης Στο φάκελο του έργουΑς δημιουργήσουμε ένα πακέτο ru.javarush.client , και σε αυτό την κλάση HelloWebServiceClient με την κύρια μέθοδο: πακέτο ru. javarush. πελάτης; // απαιτείται για να λάβετε την περιγραφή wsdl και μέσω αυτής// πρόσβαση στην ίδια την υπηρεσία web εισαγωγή java. καθαρά. URL? // Αυτή η εξαίρεση θα προκύψει κατά την εργασία με ένα αντικείμενο URLεισαγωγή java. καθαρά. MalformedURLException; // κλάσεις για ανάλυση xml με περιγραφή wsdl// και μεταβείτε στην ετικέτα υπηρεσίας σε αυτήν εισαγωγή javax. xml. χώρο ονομάτων. QName;εισαγωγή javax. xml. ws. Υπηρεσία; // διεπαφή της υπηρεσίας ιστού μας (χρειαζόμαστε περισσότερα)) ; // Εξετάζουμε τις παραμέτρους του επόμενου κατασκευαστή στην πρώτη ετικέτα της περιγραφής WSDL - ορισμοί // κοιτάξτε το 1ο όρισμα στο χαρακτηριστικό targetNamespace // κοιτάξτε το 2ο όρισμα στο χαρακτηριστικό name QName qname = νέο QName ("http://ws.site/" , "HelloWebServiceImplService" ) ; // Τώρα μπορούμε να φτάσουμε στην ετικέτα υπηρεσίας στην περιγραφή wsdl, Service service = Service. δημιουργία (url, qname) ; // και στη συνέχεια μέχρι την ετικέτα θύρας που είναι ένθετη σε αυτήν, έτσι ώστε // λάβετε έναν σύνδεσμο προς ένα αντικείμενο υπηρεσίας ιστού που είναι απομακρυσμένο από εμάς HelloWebService γεια = υπηρεσία. getPort(HelloWebService.class); // Ωραία! Τώρα μπορείτε να καλέσετε την απομακρυσμένη μέθοδοΣύστημα. έξω. println (γεια. getHelloString ("JavaRush") );

) ) Έδωσα τα μέγιστα σχόλια για τον κωδικό στην καταχώριση. Δεν έχω τίποτα να προσθέσω, οπότε ας τρέξουμε (Shift+F10). Θα πρέπει να δούμε το κείμενο στην κονσόλα: Γεια σου, JavaRush! Εάν δεν το είδατε, τότε μάλλον ξεχάσατε να ξεκινήσετε την υπηρεσία Ιστού.

Σύναψη Αυτό το θέμα παρείχε μια σύντομη εκδρομή στις υπηρεσίες Ιστού. Για άλλη μια φορά, θα πω ότι πολλά από αυτά που έγραψα είναι η εικασία μου ως προς το πώς λειτουργεί, και επομένως δεν πρέπει να με εμπιστεύεστε πολύ. Θα ήμουν ευγνώμων αν με διορθώσουν γνώστες, γιατί τότε κάτι θα μάθω.

UPD.

Σε αυτό το άρθρο θα μιλήσω για το τι είναι ένα αρχείο WSDL, γιατί χρειάζεται και πώς να εργαστείτε με αυτό.

Χάρτης άρθρου

Τι είναι το WSDL

Η WSDL είναι μια γλώσσα περιγραφής υπηρεσιών ιστού που έχει δομή XML. Ο κύριος σκοπός ενός αρχείου WSDL είναι ως διεπαφή για πρόσβαση σε λειτουργίες υπηρεσίας και επιστροφή τύπων δεδομένων. διαδρομή προς τον διακομιστή που επεξεργάζεται αιτήματα κ.λπ.

Η διαδρομή προς το αρχείο wsdl συνήθως μοιάζει με http://host/services/wsdl/gbdar-v2-2.wsdl

Υπάρχουν πολλά εργαλεία, βιβλιοθήκες που έχουν σχεδιαστεί για να διαβάζουν ένα αρχείο WSDL.

SoapUi

Ένα τέτοιο εργαλείο είναι το soapUi(). Αφού εγκαταστήσετε τη διανομή που έχει σχεδιαστεί για την πλατφόρμα σας, μπορείτε να δημιουργήσετε ένα νέο έργο χρησιμοποιώντας την εντολή File/New SoapUi project. Στο παράθυρο διαλόγου για τη δημιουργία ενός νέου έργου, αφήστε ενεργοποιημένο το πλαίσιο ελέγχου Δημιουργία δειγμάτων αιτημάτων

Στο νέο έργο, θα δημιουργηθούν αυτόματα πρότυπα αιτημάτων για την υπηρεσία, η περιγραφή των οποίων περιέχεται στο αρχείο wsdl. Στα αριστερά στο δέντρο θα δείτε μια λίστα με συναρτήσεις που περιέχονται στο αρχείο WSDL. Θα εκθέσω τη συνάρτηση Replication. Μέσα σε αυτό υπάρχει ένα αίτημα Request1, κάνοντας διπλό κλικ στο οποίο θα δούμε ένα διάλογο με ένα πρότυπο αιτήματος, αντί για τις προεπιλεγμένες παραμέτρους θα υπάρχουν ερωτηματικά. Για να εκτελεστεί σωστά η συνάρτηση, πρέπει να συμπληρώσετε όλες τις παραμέτρους που δεν επισημαίνονται με την ετικέτα Optional και, στη συνέχεια, να κάνετε κλικ στο πράσινο τρίγωνο στην επάνω αριστερή γωνία του διαλόγου.

Εάν όλες οι παράμετροι έχουν καθοριστεί σωστά, η απάντηση της υπηρεσίας στο αίτημα θα εμφανιστεί στα δεξιά.

Το SoapUi παρέχει τη δυνατότητα προβολής των παραμέτρων ενός αρχείου WSDL για να το κάνετε αυτό, πρέπει να κάνετε διπλό κλικ στο όνομα της διεπαφής (σημειωμένο με ένα πράσινο εικονίδιο στο δέντρο αρχείων WSDL, για μένα - gdbar-v2-2SOAP). Στο παράθυρο διαλόγου μπορείτε να βρείτε:

• Καρτέλα Επισκόπηση — περιγραφή των γενικών παραμέτρων WSDL, λίστα λειτουργιών και σχετικές ενέργειες διακομιστή
• Καρτέλα τελικών σημείων υπηρεσίας — διαδρομή προς τον διακομιστή και άλλες παράμετροι
• Περιεχόμενο WSDL - δέντρο πλοήγησης αρχείων
• Συμμόρφωση WS-I — εδώ μπορείτε να δημιουργήσετε μια αναφορά WS-I στη διεπαφή

Δημιουργία τεκμηρίωσης

Το SoapUi μας επιτρέπει να δημιουργήσουμε τεκμηρίωση λειτουργίας WSDL. Για να το κάνετε αυτό, κάντε δεξί κλικ στη διεπαφή και καλέστε την εντολή Δημιουργία τεκμηρίωσης.Ως αποτέλεσμα, θα λάβουμε ένα λεπτομερές εγχειρίδιο σε μορφή html.

Αυτό είναι όλο, εγγραφείτε σε νέες αναρτήσεις, αφήστε σχόλια, κάντε προτάσεις για τη βελτίωση του άρθρου.

καπέλα 23 Ιουλίου 2013 στις 01:09 μ.μ

Γράψιμο μιας εφαρμογής πελάτη-διακομιστή SOAP σε PHP

• PHP

• Φροντιστήριο

Γεια σε όλους!
Έτυχε ότι πρόσφατα άρχισα να αναπτύσσω υπηρεσίες web. Αλλά σήμερα το θέμα δεν αφορά εμένα, αλλά για το πώς μπορούμε να γράψουμε τη δική μας υπηρεσία Web XML με βάση το πρωτόκολλο SOAP 1.2.

Ελπίζω ότι αφού διαβάσετε το θέμα θα είστε σε θέση:

• γράψτε τη δική σας εφαρμογή διακομιστή μιας διαδικτυακής εφαρμογής.
• γράψτε τη δική σας εφαρμογή πελάτη μιας διαδικτυακής εφαρμογής.
• γράψτε τη δική σας περιγραφή της υπηρεσίας Ιστού (WSDL).
• αποστολή των συστοιχιών πελάτη του ίδιου τύπου δεδομένων στον διακομιστή.

Όπως ίσως μαντέψατε, όλη η μαγεία θα γίνει χρησιμοποιώντας την PHP και τις ενσωματωμένες κλάσεις SoapClient και SoapServer. Το κουνέλι μας θα είναι υπηρεσία αποστολής μηνυμάτων SMS.

1 Δήλωση προβλήματος

1.1 Όρια

Στην αρχή προτείνω να ασχοληθούμε με το αποτέλεσμα που θα πετύχουμε στο τέλος του θέματος. Όπως ανακοινώθηκε παραπάνω, θα γράψουμε μια υπηρεσία για την αποστολή μηνυμάτων SMS και πιο συγκεκριμένα, θα λαμβάνουμε μηνύματα από διαφορετικές πηγές μέσω του πρωτοκόλλου SOAP. Μετά από αυτό, θα εξετάσουμε σε ποια μορφή έρχονται στον διακομιστή. Η διαδικασία της ουράς μηνυμάτων για περαιτέρω αποστολή στον πάροχο, δυστυχώς, ξεφεύγει από το πεδίο εφαρμογής αυτής της ανάρτησης για πολλούς λόγους.

1.2 Ποια δεδομένα θα αλλάξουμε;

Ωραία, αποφασίσαμε για τα όρια! Το επόμενο βήμα που πρέπει να γίνει είναι να αποφασίσουμε ποια δεδομένα θα ανταλλάξουμε μεταξύ του διακομιστή και του πελάτη. Σε αυτό το θέμα, προτείνω να μην χωρίσετε τις τρίχες για πολύ καιρό και να απαντήσετε αμέσως στις κύριες ερωτήσεις για τον εαυτό σας:

• Ποια ελάχιστα δεδομένα πρέπει να σταλούν στον διακομιστή για να σταλεί ένα μήνυμα SMS σε έναν συνδρομητή;
• Ποια ελάχιστα δεδομένα πρέπει να αποστέλλονται από τον διακομιστή για να ικανοποιηθούν οι ανάγκες του πελάτη;

Κάτι μου λέει ότι για αυτό πρέπει να στείλεις τα εξής:

• αριθμός κινητού τηλεφώνου και
• κείμενο του μηνύματος SMS.

Κατ 'αρχήν, αυτά τα δύο χαρακτηριστικά είναι αρκετά για αποστολή, αλλά φαντάζομαι αμέσως την περίπτωση ενός SMS με ευχές γενεθλίων να έρχονται σε εσάς στις 3 η ώρα το πρωί, ή στις 4! Αυτή τη στιγμή, θα είμαι πολύ ευγνώμων σε όλους που δεν με ξέχασαν! Επομένως, θα στείλουμε επίσης στον διακομιστή και

• ημερομηνία αποστολής του μηνύματος SMS.

Το επόμενο πράγμα που θα ήθελα να στείλω στον διακομιστή είναι:

• Τύπος μηνύματος.

Αυτή η παράμετρος δεν είναι υποχρεωτική, αλλά μπορεί να μας φανεί πολύ χρήσιμη εάν χρειαστεί να πούμε γρήγορα στο αφεντικό πόσους από τους πελάτες μας έχουμε «χαροποιήσει» με τα νέα μας και επίσης να σχεδιάσουμε μερικά όμορφα στατιστικά για αυτό το θέμα.

Κι όμως, κάτι ξέχασα! Αν σκεφτούμε λίγο περισσότερο, αξίζει να σημειωθεί ότι ο πελάτης μπορεί να στείλει είτε ένα μήνυμα SMS είτε έναν αριθμό από αυτά στον διακομιστή κάθε φορά. Με άλλα λόγια, ένα πακέτο δεδομένων μπορεί να περιέχει από ένα έως άπειρα μηνύματα.

Ως αποτέλεσμα, καταλαβαίνουμε ότι για να στείλουμε ένα μήνυμα SMS χρειαζόμαστε τα ακόλουθα δεδομένα:

• αριθμός κινητού τηλεφώνου,
• κείμενο μηνύματος SMS,
• ώρα αποστολής του μηνύματος SMS στον συνδρομητή,
• τύπο μηνύματος.

Απαντήσαμε στην πρώτη ερώτηση, τώρα πρέπει να απαντήσουμε στη δεύτερη ερώτηση. Και ίσως επιτρέψω στον εαυτό μου να μπλέξω λίγο. Επομένως, από τον διακομιστή θα στείλουμε μόνο Boolean δεδομένα, η έννοια των οποίων έχει την εξής σημασία:

• TRUE – το πακέτο έφτασε με επιτυχία στον διακομιστή, πέρασε τον έλεγχο ταυτότητας και μπήκε στην ουρά για αποστολή στον πάροχο SMS
• ΛΑΘΟΣ – σε όλες τις άλλες περιπτώσεις

Αυτό ολοκληρώνει την περιγραφή της δήλωσης προβλήματος! Και τέλος, ας πάμε στο διασκεδαστικό μέρος - ας καταλάβουμε τι περίεργο θηρίο είναι αυτό το ΣΑΠΟΥΝΙ!

2 Τι είναι το SOAP;

Γενικά, αρχικά δεν σχεδίαζα να γράψω τίποτα για το τι είναι το SOAP και ήθελα να περιοριστώ σε συνδέσμους στον ιστότοπο w3.org με τις απαραίτητες προδιαγραφές, καθώς και συνδέσμους στη Wikipedia. Αλλά στο τέλος αποφάσισα να γράψω μια σύντομη σημείωση για αυτό το πρωτόκολλο.

Και θα ξεκινήσω την ιστορία μου με το γεγονός ότι αυτό το πρωτόκολλο ανταλλαγής δεδομένων ανήκει σε ένα υποσύνολο πρωτοκόλλων που βασίζονται στο λεγόμενο παράδειγμα RPC (Remote Procedure Call), ο αντίποδας του οποίου είναι το REST (Representational State Transfer). Μπορείτε να διαβάσετε περισσότερα σχετικά με αυτό στη Wikipedia, οι σύνδεσμοι προς τα άρθρα βρίσκονται στο τέλος του θέματος. Από αυτά τα άρθρα, πρέπει να κατανοήσουμε τα εξής: «Η προσέγγιση RPC επιτρέπει τη χρήση μικρού αριθμού πόρων δικτύου με μεγάλο αριθμό μεθόδων και ένα πολύπλοκο πρωτόκολλο. Με την προσέγγιση REST, ο αριθμός των μεθόδων και η πολυπλοκότητα του πρωτοκόλλου είναι αυστηρά περιορισμένοι, πράγμα που σημαίνει ότι ο αριθμός των μεμονωμένων πόρων μπορεί να είναι μεγάλος». Δηλαδή, σε σχέση με εμάς, αυτό σημαίνει ότι στην περίπτωση της προσέγγισης RPC στον ιστότοπο θα υπάρχει πάντα μία είσοδος (σύνδεσμος) στην υπηρεσία και ποια διαδικασία να καλέσουμε για την επεξεργασία των εισερχόμενων δεδομένων που μεταφέρουμε μαζί με τα δεδομένα, ενώ με την προσέγγιση REST στον ιστότοπό μας έχει πολλές εισόδους (συνδέσμους), καθεμία από τις οποίες δέχεται και επεξεργάζεται μόνο ορισμένα δεδομένα. Αν κάποιος που διαβάζει ξέρει πώς να εξηγήσει τη διαφορά σε αυτές τις προσεγγίσεις ακόμα πιο απλά, φροντίστε να γράψει στα σχόλια!

Το επόμενο πράγμα που πρέπει να γνωρίζουμε για το SOAP είναι ότι αυτό το πρωτόκολλο χρησιμοποιεί το ίδιο XML ως μεταφορά, το οποίο αφενός είναι πολύ καλό, επειδή Το οπλοστάσιό μας περιλαμβάνει αμέσως την πλήρη ισχύ μιας στοίβας τεχνολογιών που βασίζονται σε αυτήν τη γλώσσα σήμανσης, δηλαδή την XML-Schema - μια γλώσσα για την περιγραφή της δομής ενός εγγράφου XML (ευχαριστώ τη Wikipedia!), η οποία επιτρέπει την αυτόματη επικύρωση των δεδομένων που λαμβάνονται από τον διακομιστή από πελάτες.

Και έτσι, τώρα γνωρίζουμε ότι το SOAP είναι ένα πρωτόκολλο που χρησιμοποιείται για την υλοποίηση κλήσεων απομακρυσμένης διαδικασίας και χρησιμοποιεί την XML ως μεταφορά! Αν διαβάσετε το άρθρο στη Wikipedia, μπορείτε επίσης να μάθετε από εκεί ότι μπορεί να χρησιμοποιηθεί σε οποιοδήποτε πρωτόκολλο σε επίπεδο εφαρμογής, και όχι μόνο σε συνδυασμό με HTTP (δυστυχώς, σε αυτό το θέμα θα εξετάσουμε μόνο το SOAP έναντι του HTTP). Και ξέρεις τι μου αρέσει περισσότερο σε όλο αυτό; Εάν δεν υπάρχουν εικασίες, τότε θα δώσω μια υπόδειξη - SOAP!... Ακόμα δεν υπάρχουν εικασίες;... Είστε σίγουροι ότι διαβάσατε το άρθρο στη Wikipedia;... Γενικά, δεν θα σας βασανίσω περαιτέρω. Επομένως, θα πάω κατευθείαν στην απάντηση: "SOAP (από το αγγλικό πρωτόκολλο πρόσβασης απλού αντικειμένου - απλό πρωτόκολλοπρόσβαση σε αντικείμενα· μέχρι τις προδιαγραφές 1.2)". Το πιο αξιοσημείωτο σε αυτή τη γραμμή είναι με πλάγιους χαρακτήρες! Δεν ξέρω τι συμπεράσματα έβγαλες από όλα αυτά, αλλά βλέπω το εξής - αφού αυτό το πρωτόκολλο δεν μπορεί με κανέναν τρόπο να ονομαστεί "απλό" (και προφανώς ακόμη και το w3 συμφωνεί με αυτό), τότε από την έκδοση 1.2 σταμάτησε να αποκρυπτογραφείται με κάποιο τρόπο ! Και έγινε γνωστό ως SOAP, just SOAP, τελεία.

Λοιπόν, εντάξει, με συγχωρείτε, παρεκτράπηκα λίγο. Όπως έγραψα νωρίτερα, η XML χρησιμοποιείται ως μεταφορά και τα πακέτα που ταξιδεύουν μεταξύ του πελάτη και του διακομιστή ονομάζονται φάκελοι SOAP. Αν σκεφτείτε τη γενική δομή του φακέλου, θα σας φανεί πολύ οικείο, γιατί... μοιάζει με τη δομή μιας σελίδας HTML. Έχει ένα κύριο τμήμα - Περιτυλίσσω, που περιλαμβάνει ενότητες Επί κεφαλήςΚαι Σώμα, ή Σφάλμα. ΣΕ Σώμαδιαβιβάζονται δεδομένα και αποτελεί υποχρεωτικό τμήμα του φακέλου, ενώ Επί κεφαλήςείναι προαιρετική. ΣΕ Επί κεφαλήςμπορεί να μεταδοθεί εξουσιοδότηση ή οποιαδήποτε άλλα δεδομένα που δεν σχετίζονται άμεσα με τα δεδομένα εισόδου των διαδικασιών της υπηρεσίας Ιστού. Για Σφάλμαδεν υπάρχει τίποτα ιδιαίτερο να πούμε, εκτός από το ότι έρχεται στον πελάτη από τον διακομιστή σε περίπτωση σφαλμάτων.

Εδώ τελειώνει η ιστορία της κριτικής μου σχετικά με το πρωτόκολλο SOAP (θα εξετάσουμε τους ίδιους τους φακέλους και τη δομή τους με περισσότερες λεπτομέρειες όταν ο πελάτης και ο διακομιστής μας τελικά μάθουν να τα εκτελούν μεταξύ τους) και ξεκινά μια νέα - σχετικά με το συνοδευτικό SOAP που ονομάζεται WSDL(Γλώσσα περιγραφής υπηρεσιών Ιστού). Ναι, ναι, αυτό ακριβώς είναι το πράγμα που φοβίζει τους περισσότερους από εμάς να μην προσπαθήσουμε ακόμη και να εφαρμόσουμε το API μας σε αυτό το πρωτόκολλο. Ως αποτέλεσμα, συνήθως ανακαλύπτουμε εκ νέου τον τροχό μας με JSON ως μεταφορά. Τι είναι λοιπόν το WSDL; Η WSDL είναι μια γλώσσα για την περιγραφή των διαδικτυακών υπηρεσιών και την πρόσβαση σε αυτές, με βάση τη γλώσσα XML (γ) Wikipedia. Εάν αυτός ο ορισμός δεν σας καθιστά σαφές ολόκληρο το ιερό νόημα αυτής της τεχνολογίας, τότε θα προσπαθήσω να το περιγράψω με δικά μου λόγια!

Το WSDL έχει σχεδιαστεί για να επιτρέπει στους πελάτες μας να επικοινωνούν κανονικά με τον διακομιστή. Για να γίνει αυτό, το αρχείο με την επέκταση "*.wsdl" περιγράφει τις ακόλουθες πληροφορίες:

• Ποιοι χώροι ονομάτων χρησιμοποιήθηκαν;
• Ποια σχήματα δεδομένων χρησιμοποιήθηκαν;
• Τι είδους μηνύματα αναμένει η υπηρεσία web από τους πελάτες;
• Ποια δεδομένα ανήκουν σε ποιες διαδικασίες διαδικτυακής υπηρεσίας,
• Ποιες διαδικασίες περιλαμβάνει η υπηρεσία web;
• Πώς πρέπει ο πελάτης να καλεί τις διαδικασίες υπηρεσιών web,
• Σε ποια διεύθυνση πρέπει να αποστέλλονται οι κλήσεις πελατών;

Όπως μπορείτε να δείτε, αυτό το αρχείο είναι ολόκληρη η υπηρεσία web. Καθορίζοντας τη διεύθυνση του αρχείου WSDL στον πελάτη, θα γνωρίζουμε τα πάντα για οποιαδήποτε υπηρεσία web! Ως αποτέλεσμα, δεν χρειάζεται να γνωρίζουμε απολύτως τίποτα για το πού βρίσκεται η ίδια η υπηρεσία web. Το μόνο που χρειάζεται να γνωρίζετε είναι τη θέση του αρχείου WSDL! Σύντομα θα μάθουμε ότι το SOAP δεν είναι τόσο τρομακτικό όσο το λένε οι ρωσικές παροιμίες.

3 Εισαγωγή στο XML-Schema

Τώρα γνωρίζουμε πολλά για το τι είναι το SOAP, τι υπάρχει μέσα του και έχουμε μια επισκόπηση της στοίβας τεχνολογίας που το περιβάλλει. Δεδομένου ότι, πρώτα απ 'όλα, το SOAP είναι μια μέθοδος αλληλεπίδρασης μεταξύ ενός πελάτη και ενός διακομιστή και η γλώσσα σήμανσης XML χρησιμοποιείται ως μεταφορά για αυτό, σε αυτήν την ενότητα θα καταλάβουμε λίγο πώς γίνεται η αυτόματη επικύρωση δεδομένων χρησιμοποιώντας σχήματα XML.

Το κύριο καθήκον του διαγράμματος είναι να περιγράψει τη δομή των δεδομένων που πρόκειται να επεξεργαστούμε. Όλα τα δεδομένα σε σχήματα XML χωρίζονται σε απλός(κλιμακωτός) και συγκρότημα(δομές) τύπους. Οι απλοί τύποι περιλαμβάνουν τους ακόλουθους τύπους:

• γραμμή,
• αριθμός,
• δυαδική τιμή,
• ημερομηνία.

Κάτι πολύ απλό που δεν έχει προεκτάσεις μέσα. Ο αντίποδάς τους είναι πολύπλοκων σύνθετων τύπων. Το απλούστερο παράδειγμα ενός πολύπλοκου τύπου που έρχεται στο μυαλό όλων είναι τα αντικείμενα. Για παράδειγμα, ένα βιβλίο. Το βιβλίο αποτελείται από ιδιότητες: συγγραφέας, Ονομα, τιμή, Αριθμός ISBNκαι τα λοιπά. Και αυτές οι ιδιότητες, με τη σειρά τους, μπορεί να είναι είτε απλοί τύποι είτε σύνθετοι. Και το καθήκον του σχήματος XML είναι να το περιγράψει αυτό.

Προτείνω να μην πάτε μακριά και να γράψετε ένα σχήμα XML για το μήνυμα SMS μας! Ακολουθεί η xml περιγραφή του μηνύματος SMS:

71239876543 Δοκιμαστικό μήνυμα 20-07-2013 T12:00:00 12
Το διάγραμμα σύνθετου τύπου μας θα μοιάζει με αυτό:

Αυτή η καταχώρηση έχει ως εξής: Έχουμε μια μεταβλητή " μήνυμα"τύπος" Μήνυμα"και υπάρχει ένας πολύπλοκος τύπος που ονομάζεται " Μήνυμα", το οποίο αποτελείται από ένα διαδοχικό σύνολο στοιχείων" τηλέφωνο"τύπος σειρά, « κείμενο"τύπος σειρά, « ημερομηνία"τύπος ημερομηνίαΏρα, « τύπος"τύπος δεκαδικός. Αυτοί οι τύποι είναι απλοί και έχουν ήδη οριστεί στην περιγραφή του σχήματος. Συγχαρητήρια! Μόλις γράψαμε το πρώτο μας σχήμα XML!

Νομίζω ότι η έννοια των στοιχείων " στοιχείο"Και" σύνθετος τύπος"Όλα έχουν γίνει λίγο-πολύ ξεκάθαρα για εσάς, επομένως δεν θα επικεντρωθούμε πλέον σε αυτά και ας περάσουμε κατευθείαν στο στοιχείο του συνθέτη" αλληλουχία" Όταν χρησιμοποιούμε το στοιχείο συνθέτη " αλληλουχία«Σας ενημερώνουμε ότι τα στοιχεία που περιλαμβάνονται σε αυτό πρέπει πάντα να βρίσκονται με τη σειρά που καθορίζεται στο διάγραμμα και όλα είναι υποχρεωτικά. Αλλά μην απελπίζεστε! Υπάρχουν δύο ακόμη στοιχεία συνθέτη στα σχήματα XML: " επιλογή"Και" όλοι" συνθέτης" επιλογή" ανακοινώνει ότι πρέπει να υπάρχει ένα από τα στοιχεία που αναφέρονται σε αυτό και ο συνθέτης " όλοι» – οποιοσδήποτε συνδυασμός των στοιχείων που αναφέρονται.

Όπως θυμάστε, στην πρώτη ενότητα του θέματος συμφωνήσαμε ότι από ένα έως άπειρα μηνύματα SMS μπορούν να μεταδοθούν σε πακέτο. Επομένως, προτείνω να κατανοήσουμε πώς δηλώνονται τέτοια δεδομένα στο σχήμα XML. Η γενική δομή του πακέτου μπορεί να μοιάζει με αυτό:

71239876543 Δοκιμαστικό μήνυμα 1 20-07-2013 T12:00:00 12 71239876543 Δοκιμαστικό μήνυμα Ν 20-07-2013 T12:00:00 12
Το διάγραμμα για έναν τόσο σύνθετο τύπο θα μοιάζει με αυτό:

Το πρώτο μπλοκ περιέχει τη γνωστή δήλωση του μιγαδικού τύπου " Μήνυμα" Αν προσέξατε, τότε σε κάθε απλό τύπο που περιλαμβάνεται στο " Μήνυμα", προστέθηκαν νέα διευκρινιστικά χαρακτηριστικά " minΣυμβαίνει"Και" maxOccurs" Όπως μπορείτε να μαντέψετε από το όνομα, το πρώτο ( minΣυμβαίνει) υποδεικνύει ότι αυτή η ακολουθία πρέπει να περιέχει τουλάχιστον ένα στοιχείο τύπου " τηλέφωνο», « κείμενο», « ημερομηνία"Και" τύπος", ενώ το επόμενο ( maxOccurs) το χαρακτηριστικό μας δηλώνει ότι υπάρχει το πολύ ένα τέτοιο στοιχείο στην ακολουθία μας. Ως αποτέλεσμα, όταν γράφουμε τα δικά μας σχήματα για οποιαδήποτε δεδομένα, μας δίνεται η ευρύτερη επιλογή για το πώς να τα διαμορφώσουμε!

Το δεύτερο μπλοκ του διαγράμματος δηλώνει το στοιχείο " λίστα μηνυμάτων"τύπος" MessageList" Είναι σαφές ότι " MessageList"είναι ένας σύνθετος τύπος που περιέχει τουλάχιστον ένα στοιχείο" μήνυμα», αλλά ο μέγιστος αριθμός τέτοιων στοιχείων δεν είναι περιορισμένος!

4 Γράψτε το WSDL σας

Θυμάστε ότι το WSDL είναι η διαδικτυακή μας υπηρεσία; Ελπίζω να θυμάσαι! Καθώς το γράφουμε, η μικρή μας υπηρεσία ιστού θα λειτουργεί σε αυτό. Ως εκ τούτου, προτείνω να μην μπερδεύουμε.

Γενικά, για να λειτουργούν όλα σωστά για εμάς, πρέπει να μεταφέρουμε ένα αρχείο WSDL με τον σωστό τύπο MIME στον πελάτη. Για να το κάνετε αυτό, πρέπει να ρυθμίσετε τις παραμέτρους του διακομιστή ιστού σας ανάλογα, δηλαδή να ορίσετε τον τύπο MIME για αρχεία με την επέκταση "*.wsdl" στην ακόλουθη γραμμή:

Εφαρμογή/wsdl+xml
Αλλά στην πράξη, συνήθως έστελνα την κεφαλίδα HTTP μέσω PHP " κείμενο/xml»:

Header("Content-Type: text/xml; charset=utf-8");
και όλα δούλεψαν τέλεια!

Θέλω να σας προειδοποιήσω αμέσως ότι η απλή διαδικτυακή μας υπηρεσία θα έχει μια μάλλον εντυπωσιακή περιγραφή, οπότε μην ανησυχείτε, γιατί... Το μεγαλύτερο μέρος του κειμένου είναι υποχρεωτικό νερό και, αφού το γράψετε μία φορά, μπορείτε να το αντιγράφετε συνεχώς από τη μια υπηρεσία web στην άλλη!

Δεδομένου ότι το WSDL είναι XML, πρέπει να γράψετε για αυτό απευθείας στην πρώτη γραμμή. Το ριζικό στοιχείο του αρχείου πρέπει πάντα να ονομάζεται " ορισμούς»:

Συνήθως, το WSDL αποτελείται από 4-5 κύρια μπλοκ. Το πρώτο μπλοκ είναι ο ορισμός μιας διαδικτυακής υπηρεσίας ή, με άλλα λόγια, το σημείο εισόδου.

Λέει εδώ ότι έχουμε μια υπηρεσία που ονομάζεται - " SmsService" Καταρχήν, όλα τα ονόματα στο αρχείο WSDL μπορούν να αλλάξουν από εσάς σε ό,τι θέλετε, επειδή δεν παίζουν κανέναν απολύτως ρόλο.

Μετά από αυτό ανακοινώνουμε ότι στην υπηρεσία ιστού μας " SmsService"Υπάρχει ένα σημείο εισόδου ("port") που ονομάζεται " SmsServicePort" Σε αυτό το σημείο εισόδου θα αποστέλλονται όλα τα αιτήματα από τους πελάτες στον διακομιστή. Και υποδείξτε στο στοιχείο " διεύθυνση» σύνδεσμος προς το αρχείο χειριστή που θα δέχεται αιτήματα.

Αφού ορίσουμε την υπηρεσία web και καθορίσουμε το σημείο εισόδου για αυτήν, πρέπει να δεσμεύσουμε τις υποστηριζόμενες διαδικασίες σε αυτήν:

Για να γίνει αυτό, παραθέτει ποιες λειτουργίες και με ποια μορφή θα καλούνται. Εκείνοι. για λιμάνι" SmsServicePort"ένα δεσμευτικό ορίζεται κάτω από το όνομα" SmsServiceBinding", το οποίο έχει τύπο κλήσης" rpc"και το HTTP χρησιμοποιείται ως πρωτόκολλο μεταφοράς. Έτσι, υποδείξαμε εδώ ότι θα πραγματοποιήσουμε μια κλήση RPC μέσω HTTP. Μετά από αυτό περιγράφουμε ποιες διαδικασίες ( λειτουργία) υποστηρίζονται στην υπηρεσία web. Θα υποστηρίξουμε μόνο μία διαδικασία - " αποστολή SMS" Μέσω αυτής της διαδικασίας τα υπέροχα μηνύματά μας θα σταλούν στον διακομιστή! Αφού δηλωθεί η διαδικασία, είναι απαραίτητο να υποδειχθεί με ποια μορφή θα διαβιβαστούν τα δεδομένα. Σε αυτήν την περίπτωση, υποδεικνύεται ότι θα χρησιμοποιηθούν τυπικοί φάκελοι SOAP.

Μετά από αυτό, πρέπει να συνδέσουμε τη διαδικασία σε μηνύματα:

Για να γίνει αυτό, διευκρινίζουμε ότι το δέσιμο μας είναι τύπου " SmsServicePortType"και στο στοιχείο" portType«Με το όνομα του ίδιου τύπου, υποδεικνύουμε τη σύνδεση των διαδικασιών σε μηνύματα. Και έτσι, το εισερχόμενο μήνυμα (από πελάτη σε διακομιστή) θα ονομάζεται " sendSmsRequest", και εξερχόμενη (από διακομιστή σε πελάτη) " sendSmsResponse" Όπως όλα τα ονόματα στο WSDL, τα ονόματα των εισερχόμενων και εξερχόμενων μηνυμάτων είναι αυθαίρετα.

Τώρα πρέπει να περιγράψουμε τα ίδια τα μηνύματα, δηλ. εισερχόμενες και εξερχόμενες:

Για να γίνει αυτό προσθέτουμε τα στοιχεία " μήνυμα"με ονόματα" sendSmsRequest"Και" sendSmsResponse"αντίστοιχα. Σε αυτά υποδεικνύουμε ότι η είσοδος πρέπει να είναι ένας φάκελος του οποίου η δομή αντιστοιχεί στον τύπο δεδομένων " Αίτηση" Μετά από αυτό επιστρέφεται ένας φάκελος από τον διακομιστή που περιέχει τον τύπο δεδομένων - " Απάντηση».

Τώρα πρέπει να κάνουμε λίγο - να προσθέσουμε μια περιγραφή αυτών των τύπων στο αρχείο μας WSDL! Και πώς πιστεύετε ότι το WSDL περιγράφει τα εισερχόμενα και τα εξερχόμενα δεδομένα; Νομίζω ότι έχετε ήδη καταλάβει τα πάντα εδώ και πολύ καιρό και είπατε στον εαυτό σας ότι χρησιμοποιώντας σχήματα XML! Και θα έχεις απόλυτο δίκιο!

Μπορείτε να μας συγχαρείτε! Το πρώτο μας WSDL γράφτηκε! Και είμαστε ένα βήμα πιο κοντά στην επίτευξη του στόχου μας.
Στη συνέχεια, θα δούμε τι μας παρέχει η PHP για την ανάπτυξη των δικών μας κατανεμημένων εφαρμογών.

5 Ο πρώτος μας διακομιστής SOAP

Νωρίτερα έγραψα ότι για να δημιουργήσουμε έναν διακομιστή SOAP στην PHP θα χρησιμοποιήσουμε την ενσωματωμένη κλάση SoapServer. Για να γίνουν όλες οι περαιτέρω ενέργειες με τον ίδιο τρόπο όπως για μένα, θα χρειαστεί να τροποποιήσετε λίγο την PHP σας. Για να είμαστε ακόμη πιο ακριβείς, πρέπει να βεβαιωθείτε ότι έχετε εγκαταστήσει την επέκταση "php-soap". Είναι καλύτερο να διαβάσετε πώς να το εγκαταστήσετε στον διακομιστή ιστού σας στον επίσημο ιστότοπο της PHP (δείτε τη λίστα αναφορών).

Αφού εγκατασταθούν και ρυθμιστούν τα πάντα, θα χρειαστεί να δημιουργήσουμε ένα αρχείο στον ριζικό φάκελο της φιλοξενίας σας " smsservice.php» με το ακόλουθο περιεχόμενο:

setClass("SoapSmsGateWay"); //Εκκίνηση του διακομιστή $server->handle();
Ελπίζω να μην χρειάζεται να εξηγήσω τι βρίσκεται πάνω από τη γραμμή με τη συνάρτηση "ini_set". Επειδή εκεί καθορίζεται ποιες κεφαλίδες HTTP θα στείλουμε από τον διακομιστή στον πελάτη και διαμορφώνεται το περιβάλλον. Στη γραμμή με το "ini_set" απενεργοποιούμε την προσωρινή αποθήκευση του αρχείου WSDL έτσι ώστε οι αλλαγές μας σε αυτό να ισχύουν αμέσως στον πελάτη.

Τώρα ερχόμαστε στον διακομιστή! Όπως μπορείτε να δείτε, ολόκληρος ο διακομιστής SOAP παίρνει μόνο τρεις γραμμές! Στην πρώτη γραμμή, δημιουργούμε ένα νέο στιγμιότυπο του αντικειμένου SoapServer και μεταβιβάζουμε τη διεύθυνση της περιγραφής WSDL της υπηρεσίας web στον κατασκευαστή του. Τώρα ξέρουμε ότι θα βρίσκεται στη ρίζα της φιλοξενίας σε ένα αρχείο με το αυτονόητο όνομα " smsservice.wsdl.php" Στη δεύτερη γραμμή, λέμε στον διακομιστή SOAP ποια κλάση πρέπει να τραβήξει για να επεξεργαστεί το φάκελο που ελήφθη από τον πελάτη και να επιστρέψει τον φάκελο με την απόκριση. Όπως ίσως μαντέψατε, σε αυτήν την κατηγορία θα περιγραφεί η μόνη μας μέθοδος αποστολή SMS. Στην τρίτη γραμμή ξεκινάμε τον διακομιστή! Αυτό είναι όλο, ο διακομιστής μας είναι έτοιμος! Με το οποίο μας συγχαίρω όλους!

Τώρα πρέπει να δημιουργήσουμε το αρχείο WSDL. Για να το κάνετε αυτό, μπορείτε είτε απλώς να αντιγράψετε το περιεχόμενό του από την προηγούμενη ενότητα, είτε να αφεθείτε ελεύθεροι και να το κάνετε "πρότυπο" λίγο:

"; ?> /" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/" xmlns:http="http:// schemas.xmlsoap.org/wsdl/http/" name="SmsWsdl" xmlns="http://schemas.xmlsoap.org/wsdl/"> /">

/smsservice.php" />
Σε αυτό το στάδιο, θα πρέπει να είμαστε απόλυτα ικανοποιημένοι με τον διακομιστή που προκύπτει, γιατί Μπορούμε να καταγράψουμε τους φακέλους που έρχονται σε αυτό και στη συνέχεια να αναλύσουμε ήρεμα τα εισερχόμενα δεδομένα. Για να λάβουμε οτιδήποτε στον διακομιστή, χρειαζόμαστε έναν πελάτη. Πάμε λοιπόν σε αυτό!

6 πελάτης SOAP καθ' οδόν

Πρώτα από όλα, πρέπει να δημιουργήσουμε ένα αρχείο στο οποίο θα γράψουμε τον πελάτη. Ως συνήθως, θα το δημιουργήσουμε στη ρίζα του κεντρικού υπολογιστή και θα το ονομάσουμε " client.php", και μέσα θα γράψουμε τα εξής:

messageList = new MessageList(); $req->messageList->message = new Message(); $req->messageList->message->phone = "79871234567"; $req->messageList->message->text = "Δοκιμαστικό μήνυμα 1"; $req->messageList->message->date = "2013-07-21T15:00:00.26"; $req->messageList->message->type = 15; $client = new SoapClient("http://($_SERVER["HTTP_HOST"])/smsservice.wsdl.php", array("soap_version" => SOAP_1_2)); var_dump($client->sendSms($req));
Ας περιγράψουμε τα αντικείμενά μας. Όταν γράψαμε το WSDL, περιέγραφε τρεις οντότητες για τον φάκελο που εισερχόταν στον διακομιστή: Αίτηση, MessageListΚαι Μήνυμα. Ανάλογα τάξεις Αίτηση, MessageListΚαι Μήνυμαείναι αντανακλάσεις αυτών των οντοτήτων στο σενάριο PHP μας.

Αφού ορίσουμε τα αντικείμενα, πρέπει να δημιουργήσουμε ένα αντικείμενο ( $req), το οποίο θα στείλουμε στον διακομιστή. Μετά από αυτό έρχονται οι δύο πιο αγαπημένες γραμμές για εμάς! Ο πελάτης μας SOAP! Είτε το πιστεύετε είτε όχι, αυτό είναι αρκετό για να αρχίσει ο διακομιστής μας να λαμβάνει μηνύματα από τον πελάτη, καθώς και για να τα λαμβάνει και να τα επεξεργάζεται με επιτυχία ο διακομιστής μας! Στην πρώτη από αυτές, δημιουργούμε μια παρουσία της κλάσης SoapClient και περνάμε τη διεύθυνση της θέσης του αρχείου WSDL στον κατασκευαστή του και στις παραμέτρους υποδεικνύουμε ρητά ότι θα εργαστούμε χρησιμοποιώντας το πρωτόκολλο SOAP έκδοση 1.2. Στην επόμενη γραμμή καλούμε τη μέθοδο αποστολή SMSαντικείμενο $clientκαι εμφανίστε αμέσως το αποτέλεσμα στο πρόγραμμα περιήγησης.
Ας το τρέξουμε και ας δούμε τι πήραμε τελικά!

Το ακόλουθο αντικείμενο επιστράφηκε σε μένα από τον διακομιστή:

Object(stdClass) public "status" => boolean true
Και αυτό είναι υπέροχο, γιατί... Τώρα γνωρίζουμε με βεβαιότητα ότι ο διακομιστής μας λειτουργεί και όχι μόνο λειτουργεί, αλλά μπορεί επίσης να επιστρέψει ορισμένες τιμές στον πελάτη!

Τώρα ας δούμε το αρχείο καταγραφής που κρατάμε με σύνεση από την πλευρά του διακομιστή! Στο πρώτο μέρος του βλέπουμε τα ανεπεξέργαστα δεδομένα που έφτασαν στον διακομιστή:

79871234567 Δοκιμαστικό μήνυμα 1 21-07-2013 T15:00:00.26 15
Αυτός είναι ο φάκελος. Τώρα ξέρετε πώς μοιάζει! Αλλά είναι απίθανο να μας ενδιαφέρει να το κοιτάμε συνέχεια, οπότε ας απαριθμήσουμε το αντικείμενο από το αρχείο καταγραφής και ας δούμε αν όλα είναι καλά:

Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "Test message 1 " (μήκος=37) δημόσια "ημερομηνία" => συμβολοσειρά "2013-07-21T15:00:00.26" (μήκος=22) δημόσιο "τύπος" => συμβολοσειρά "15" (μήκος=2)
Όπως μπορείτε να δείτε, το αντικείμενο αποσειρώθηκε σωστά, για το οποίο θέλω να μας συγχαρώ όλους! Κάτι πιο ενδιαφέρον μας περιμένει στη συνέχεια! Δηλαδή, θα στείλουμε τον πελάτη στον διακομιστή όχι μόνο ένα μήνυμα SMS, αλλά ένα ολόκληρο πακέτο (για την ακρίβεια, τρία)!

7 Αποστολή σύνθετων αντικειμένων

Ας σκεφτούμε πώς μπορούμε να μεταφέρουμε μια ολόκληρη δέσμη μηνυμάτων στον διακομιστή σε ένα πακέτο; Πιθανώς ο ευκολότερος τρόπος θα ήταν να οργανώσετε έναν πίνακα μέσα στο στοιχείο messageList! Ας κάνουμε αυτό:

// δημιουργήστε ένα αντικείμενο για αποστολή στον διακομιστή $req = new Request(); $req->messageList = new MessageList(); $msg1 = new Message(); $msg1->phone = "79871234567"; $msg1->text = "Δοκιμαστικό μήνυμα 1"; $msg1->date = "21-07-2013T15:00:00.26"; $msg1->type = 15; $msg2 = new Message(); $msg2->phone = "79871234567"; $msg2->text = "Δοκιμαστικό μήνυμα 2"; $msg2->date = "2014-08-22T16:01:10"; $msg2->type = 16; $msg3 = new Message(); $msg3->phone = "79871234567"; $msg3->text = "Δοκιμαστικό μήνυμα 3"; $msg3->date = "2014-08-22T16:01:10"; $msg3->type = 17; $req->messageList->message = $msg1; $req->messageList->message = $msg2; $req->messageList->message = $msg3;
Τα αρχεία καταγραφής μας δείχνουν ότι το ακόλουθο πακέτο ελήφθη από τον πελάτη:

79871234567 Δοκιμαστικό μήνυμα 1 21-07-2013 T15:00:00.26 15 79871234567 Δοκιμαστικό μήνυμα 2 22-08-2014T16:01:10 16 79871234567 Δοκιμαστικό μήνυμα 3 22-08-2014T16:01:10 17
Τι ανοησίες λέτε; Και θα έχεις δίκιο από μια άποψη, γιατί... Μόλις μάθαμε ότι ένα αντικείμενο έφυγε από τον πελάτη, ήρθε στον διακομιστή μας με την ίδια ακριβώς μορφή με τη μορφή φακέλου. Είναι αλήθεια ότι τα μηνύματα SMS δεν ήταν σειριακά σε XML με τον τρόπο που χρειαζόμασταν - έπρεπε να είναι τυλιγμένα σε στοιχεία μήνυμα, όχι μέσα Struct. Τώρα ας δούμε σε ποια μορφή έρχεται ένα τέτοιο αντικείμενο στη μέθοδο αποστολή SMS:

Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "Struct" => array (size=3) 0 => object(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "Test message 1" (length=37) public "date" => string "2013-07-21T15:00:00.26" (length=22) public " type" => string "15" (length=2) 1 => object(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "Test message 2" (length= 37) public "date" => string "2014-08-22T16:01:10" (length=19) public "type" => string "16" (length=2) 2 => object(stdClass) public "phone " => string "79871234567" (length=11) public "text" => string "Test message 3" (length=37) public "date" => string "2014-08-22T16:01:10" (length= 19) δημόσιο "type" => συμβολοσειρά "17" (μήκος=2)
Τι μας δίνει αυτή η γνώση; Μόνο ότι η διαδρομή που επιλέξαμε δεν είναι σωστή και δεν λάβαμε απάντηση στην ερώτηση - "Πώς μπορούμε να έχουμε τη σωστή δομή δεδομένων στον διακομιστή;" Αλλά προτείνω να μην απελπιζόμαστε και να προσπαθήσουμε να μετατρέψουμε τον πίνακα μας στον τύπο αντικείμενο:

$req->messageList->message = (αντικείμενο)$req->messageList->message;
Σε αυτήν την περίπτωση, θα λάβουμε έναν άλλο φάκελο:

79871234567 Δοκιμαστικό μήνυμα 1 21-07-2013 T15:00:00.26 15 79871234567 Δοκιμαστικό μήνυμα 2 22-08-2014T16:01:10 16 79871234567 Δοκιμαστικό μήνυμα 3 22-08-2014T16:01:10 17
Μπήκε στη μέθοδο αποστολή SMSτο αντικείμενο έχει την ακόλουθη δομή:

Object(stdClass) public "messageList" => object(stdClass) public "message" => object(stdClass) public "BOGUS" => array (size=3) 0 => object(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "Test message 1" (length=37) public "date" => string "2013-07-21T15:00:00.26" (length=22) public " type" => string "15" (length=2) 1 => object(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "Test message 2" (length= 37) public "date" => string "2014-08-22T16:01:10" (length=19) public "type" => string "16" (length=2) 2 => object(stdClass) public "phone " => string "79871234567" (length=11) public "text" => string "Test message 3" (length=37) public "date" => string "2014-08-22T16:01:10" (length= 19) δημόσιο "type" => συμβολοσειρά "17" (μήκος=2)
Όσο για μένα, «το άθροισμα δεν αλλάζει από την αλλαγή των θέσεων των όρων» (γ). Τι ΨΕΥΔΗΣ, Τι Struct– δεν έχουμε πετύχει ακόμα τον στόχο μας! Και για να το πετύχουμε, πρέπει να βεβαιωθούμε ότι αντί για αυτά τα ακατανόητα ονόματα εμφανίζεται το μητρικό μας μήνυμα. Αλλά ο συγγραφέας δεν ξέρει ακόμα πώς να το πετύχει αυτό. Επομένως, το μόνο που μπορούμε να κάνουμε είναι να απαλλαγούμε από το επιπλέον δοχείο. Με άλλα λόγια, θα φροντίσουμε τώρα ότι αντί για μήνυμαέγινε ΨΕΥΔΗΣ! Για να το κάνετε αυτό, αλλάξτε το αντικείμενο ως εξής:

// δημιουργήστε ένα αντικείμενο για αποστολή στον διακομιστή $req = new Request(); $msg1 = new Message(); $msg1->phone = "79871234567"; $msg1->text = "Δοκιμαστικό μήνυμα 1"; $msg1->date = "21-07-2013T15:00:00.26"; $msg1->type = 15; $msg2 = new Message(); $msg2->phone = "79871234567"; $msg2->text = "Δοκιμαστικό μήνυμα 2"; $msg2->date = "2014-08-22T16:01:10"; $msg2->type = 16; $msg3 = new Message(); $msg3->phone = "79871234567"; $msg3->text = "Δοκιμαστικό μήνυμα 3"; $msg3->date = "2014-08-22T16:01:10"; $msg3->type = 17; $req->messageList = $msg1; $req->messageList = $msg2; $req->messageList = $msg3; $req->messageList = (αντικείμενο)$req->messageList;
Τι γίνεται αν σταθούμε τυχεροί και βγει το σωστό όνομα από το διάγραμμα; Για να το κάνουμε αυτό, ας δούμε τον φάκελο που έφτασε:

79871234567 Δοκιμαστικό μήνυμα 1 21-07-2013 T15:00:00.26 15 79871234567 Δοκιμαστικό μήνυμα 2 22-08-2014T16:01:10 16 79871234567 Δοκιμαστικό μήνυμα 3 22-08-2014T16:01:10 17
Ναι, δεν έγινε θαύμα! ΨΕΥΔΗΣ– Δεν θα κερδίσουμε! ήρθε στο αποστολή SMSτο αντικείμενο σε αυτή την περίπτωση θα μοιάζει με αυτό:

Object(stdClass) public "messageList" => object(stdClass) public "BOGUS" => array (size=3) 0 => object(stdClass) public "phone" => string "79871234567" (length=11) public " text" => string "Test message 1" (length=37) public "date" => string "2013-07-21T15:00:00.26" (length=22) public "type" => string "15" (length =2) 1 => αντικείμενο(stdClass) public "phone" => string "79871234567" (length=11) public "text" => string "Test message 2" (length=37) public "date" => string " 2014-08-22T16:01:10" (μήκος=19) δημόσιος "τύπος" => συμβολοσειρά "16" (μήκος=2) 2 => αντικείμενο(stdClass) δημόσιο "τηλέφωνο" => συμβολοσειρά "79871234567" (μήκος= 11) public "text" => string "Test message 3" (length=37) public "date" => string "2014-08-22T16:01:10" (length=19) public "type" => string " 17" (μήκος = 2)
Όπως λένε – «Σχεδόν»! Σε αυτό το (ελαφρώς λυπηρό) σημείωμα, προτείνω να ολοκληρώσουμε σιγά σιγά τα πράγματα και να βγάλουμε κάποια συμπεράσματα για τον εαυτό μας.

8 Συμπέρασμα

Επιτέλους φτάσαμε εδώ! Ας καταλάβουμε τι μπορείτε να κάνετε τώρα:

• Μπορείτε να γράψετε το αρχείο WSDL που είναι απαραίτητο για την υπηρεσία web σας.
• Μπορείτε εύκολα να γράψετε τον δικό σας πελάτη που μπορεί να επικοινωνεί με τον διακομιστή μέσω SOAP.
• Μπορείτε να γράψετε τον δικό σας διακομιστή που επικοινωνεί με τον έξω κόσμο μέσω SOAP.
• μπορείτε να στείλετε πίνακες του ίδιου τύπου αντικειμένων στον διακομιστή από τον πελάτη σας (με ορισμένους περιορισμούς).

Κάναμε επίσης μερικές ανακαλύψεις κατά τη διάρκεια της μικρής έρευνάς μας:

• η εγγενής κλάση SoapClient δεν σειριοποιεί σωστά τις δομές δεδομένων του ίδιου τύπου σε XML.
• κατά τη σειριοποίηση ενός πίνακα σε XML δημιουργεί ένα επιπλέον στοιχείο που ονομάζεται Struct;
• κατά τη σειριοποίηση ενός αντικειμένου σε XML, δημιουργείται ένα επιπλέον στοιχείο που ονομάζεται ΨΕΥΔΗΣ;
• ΨΕΥΔΗΣλιγότερο κακό από Structλόγω του γεγονότος ότι ο φάκελος είναι πιο συμπαγής (δεν προστίθενται επιπλέον χώροι ονομάτων στην κεφαλίδα XML του φακέλου).
• Δυστυχώς, η κλάση SoapServer δεν επικυρώνει αυτόματα τα δεδομένα φακέλου με το σχήμα XML μας (ίσως και άλλοι διακομιστές να μην το κάνουν αυτό).

WSDL (Γλώσσα περιγραφής υπηρεσιών Ιστού) η έκδοση 1.1 δημοσιεύτηκε στις 15 Μαρτίου 2001. WSDLείναι μια μορφή που βασίζεται σε XML που χρησιμοποιείται για την περιγραφή υπηρεσιών Ιστού χρησιμοποιώντας μηνύματα που περιέχουν πληροφορίες σχετικά με τον τρόπο πρόσβασης σε μια συγκεκριμένη υπηρεσία Ιστού. WSDLεπεκτάσιμο, το οποίο σας επιτρέπει να περιγράφετε τις υπηρεσίες και τα μηνύματά τους ανεξάρτητα από τις μορφές μηνυμάτων ή τα πρωτόκολλα δικτύου που χρησιμοποιούνται για τη μεταφορά, ωστόσο, το WSDL 1.1 χρησιμοποιείται συχνότερα μαζί με το SOAP 1.1, το HTTP GET/POST και το MIME. Επειδή WSDLαναπτύχθηκε από κοινού με το SOAP και στην ανάπτυξή του συμμετείχαν οι ίδιες εταιρείες Microsoft, Ariba και IBM. Αν αναλογιστούμε το έγγραφο WSDLδιαισθητικά, μπορούμε να πούμε ότι επιτρέπει απαντήστε σε 4 ερωτήσεις:

1) τι κάνεις; Η απάντηση σε αυτό το ερώτημα δίνεται με μια μορφή κατάλληλη τόσο για την ανθρώπινη αντίληψη όσο και για την αντιληπτή από τη μηχανή μορφή. Απάντηση για το άτομο στις ετικέτες:<όνομα/>, <απόδειξη με έγγραφα/>, για αυτοκίνητο -<μήνυμα/>, <Τύπος σημείου>

2) τι γλώσσα μιλάς; (ποιους τύπους χρησιμοποιείτε;) Απαντήστε στην ετικέτα:<τύπους/>

3) πώς θα επικοινωνήσω μαζί σας; (πώς θα έχει πρόσβαση ο πελάτης στην υπηρεσία web;): HTTP ή SMTP. Η απάντηση βρίσκεται στο<δεσμευτικός/>

4) Που μπορώ να σε βρω; (πού μπορώ να βρω αυτήν την υπηρεσία web ή ποια είναι η διεύθυνση URL της;). Η απάντηση είναι:<υπηρεσία/>

Δομή:

Κάθε έγγραφο WSDL μπορεί να αναλυθεί σε τρία λογικά μέρη:

1. τον καθορισμό τύπων δεδομένων - τον προσδιορισμό του τύπου των μηνυμάτων που αποστέλλονται και λαμβάνονται από την υπηρεσία XML

2. αφηρημένες πράξεις - λίστα λειτουργιών που μπορούν να εκτελεστούν με μηνύματα

3. σύνδεση υπηρεσίας - η μέθοδος με την οποία θα παραδοθεί το μήνυμα

Εγγραφα WSDLμπορεί να δημιουργηθεί χειροκίνητα, αλλά η γλώσσα είναι αυστηρά επισημοποιημένη WSDLσας επιτρέπει να αυτοματοποιήσετε τη διαδικασία γραφής WSDL-έγγραφα. Πολλά εργαλεία σύνταξης υπηρεσιών Ιστού περιέχουν βοηθητικά προγράμματα που δημιουργούν αυτόματα WSDL-αρχεία που περιγράφουν έτοιμες υπηρεσίες Web. Για παράδειγμα, το Εργαλείο συγγραφής υπηρεσιών Web Άξονας Απάτσιπεριέχει μια τάξη Java2WSDL, δημιουργία WSDL- ένα αρχείο μιας κλάσης ή διεπαφής Java που περιγράφει μια υπηρεσία Ιστού. Το πακέτο IBM WSTK, το οποίο περιλαμβάνει Αξονας, περιέχει το βοηθητικό πρόγραμμα java2wsdl, το οποίο δημιουργεί και εκτελεί ένα αντικείμενο από αυτήν την κλάση. Λειτουργεί από τη γραμμή εντολών.

Στοιχεία εγγράφου WSDL

Ας περιγράψουμε τις πιο συχνά χρησιμοποιούμενες ετικέτες WSDL:

Ετικέτα είναι η ρίζα όλων των εγγράφων WSDL. Ορίζει πολλούς χώρους ονομάτων:

1)στόχος Ο χώρος ονομάτων είναι ο χώρος ονομάτων της υπηρεσίας ιστού μας

2) xmlns – τυπικός χώρος ονομάτων εγγράφων WSDL

3)xmlns: SOAP_ENC – χώρος ονομάτων που χρησιμοποιείται για την περιγραφή της κωδικοποίησης SOAP

4) xmlns: impl και intf – ο χώρος ονομάτων της υλοποίησης και του ορισμού της διαδικτυακής μας υπηρεσίας

· Έγγραφο ορισμού υπηρεσίας Web

· Έγγραφο για την υλοποίηση μιας διαδικτυακής υπηρεσίας

Για απλότητα, κατά κανόνα, χρησιμοποιούν 1 αρχείο που περιέχει όλες τις πληροφορίες

Στοιχείο - παρέχει πληροφορίες σχετικά με τα δεδομένα που μεταφέρονται από το ένα τελικό σημείο στο άλλο.

Για να περιγράψετε μια κλήση RPC, πρέπει να δημιουργήσετε ένα μήνυμα εισόδου και ένα μήνυμα εξόδου.

Σε αυτό το στοιχείο, μπορείτε να καθορίσετε παραμέτρους μεθόδου χρησιμοποιώντας το στοιχείο

Στοιχείο περιγράφει και ορίζει τις λειτουργίες ή τις μεθόδους που υποστηρίζονται από μια υπηρεσία Ιστού

Οι λειτουργίες μπορούν να έχουν μηνύματα εισαγωγής καθώς και μηνύματα σφάλματος.

Στοιχείο - περιγράφει πώς οι λειτουργίες που καθορίζονται σε έναν τύπο θύρας θα μεταδοθούν μέσω του δικτύου. Επειδή Το στοιχείο χρησιμοποιεί έναν τύπο θύρας, πρέπει να καθορίσει έναν τύπο που ορίστηκε κάπου νωρίτερα στο έγγραφο.

Στοιχείο - υποδεικνύει πού θα βρείτε την υπηρεσία web

Στοιχείο εισαγωγή . Πολύ συχνά το στοιχείο υπηρεσίας εκχωρείται στο έγγραφο wsdl του για λόγους πρακτικότητας.

Για να επιτραπεί ο συνδυασμός πολλών εγγράφων wsdl σε ένα, χρησιμοποιείται το στοιχείο εισαγωγής. Σας επιτρέπει να συμπεριλάβετε ένα έγγραφο wsdl σε ένα άλλο.

Στοιχείο τύπους σας επιτρέπει να καθορίσετε τους τύπους δεδομένων που μεταδίδονται εάν δεν είναι τυπικοί.

Το WSDL υποστηρίζει 4 τρόπους λειτουργίας:

· μονόδρομες ή μονόδρομες λειτουργίες. Το μήνυμα αποστέλλεται στο τελικό σημείο της υπηρεσίας. Σε αυτήν την περίπτωση, η λειτουργία περιγράφεται από ένα μόνο μήνυμα εισόδου.

· Αίτημα-Απάντηση – λειτουργία αίτησης-απόκρισης. Αυτός ο τρόπος λειτουργίας είναι ο πιο συνηθισμένος. Σε αυτήν τη λειτουργία, η περιγραφή λειτουργίας περιέχει ένα μήνυμα εισόδου και εξόδου και ένα προαιρετικό μήνυμα σφάλματος.

· Λειτουργία τύπου αίτησης-απόκρισης. Σε αυτήν τη λειτουργία, ένα τελικό σημείο είναι πελάτης ενός άλλου τερματικού σημείου. Η μορφή λειτουργίας είναι παρόμοια με τη λειτουργία αίτησης-απόκρισης, αλλά τα δεδομένα εξόδου παρατίθενται πριν από τα δεδομένα εισόδου.

· Ειδοποίηση λειτουργίας. Αυτή η λειτουργία είναι μια άλλη έκδοση του πρωτόγονου μονόδρομου μετάδοσης, στην οποία το τελικό σημείο στέλνει το μήνυμα αντί να το λαμβάνει. Η λειτουργία περιέχει μόνο ένα μήνυμα εξόδου.