9.1. Ορισµός και ιδιότητες των Υπηρεσιών Ιστού. Προαπαιτούµενη γνώση 1) Κεφάλαια 5, 6, 7 και 8 του παρόντος.

Transcript

1 Κεφάλαιο 9 ΥΠΗΡΕΣΙΕΣ ΙΣΤΟΥ Σύνοψη Το κεφάλαιο αυτό αποτελεί εισαγωγή στις Υπηρεσίες Ιστού (Web Services-WS) και τις συναφείς τεχνολογίες υποστήριξής τους. Αρχικά, γίνεται µια εισαγωγική αναφορά στις WS και στη στοίβα των πρωτοκόλλων που χρησιµοποιούν, και εξετάζονται διεξοδικά οι δυνατότητές τους και οι στόχοι τους οποίους µπορούµε να επιτύχουµε µε αυτές. Στη συνέχεια, παρουσιάζονται αναλυτικά το πρωτόκολλο Simple Object Access Protocol (SOAP), µε το οποίο ανταλλάσσονται µηνύµατα µεταξύ της WS και ενός πελάτη της, καθώς και η Web Services Description Language (WSDL), η οποία είναι η γλώσσα περιγραφής των WS. Κατόπιν, εξετάζεται η Universal Discovery Description and Integration (UDDI), η οποία είναι η υπηρεσία ανακάλυψης WS. Επίσης, γίνεται σύγκριση των WS µε τις τεχνολογίες RMI, CORBA και EJB, και δίνεται ένα εκτενές παράδειγµα του τρόπου υλοποίησης των Java WS. Επίσης, εξετάζεται µια νέα εκδοχή των WS, τα Restful Web Services, µέσα από ένα λεπτοµερές παράδειγµα υλοποίησης. Προαπαιτούµενη γνώση 1) Κεφάλαια 5, 6, 7 και 8 του παρόντος. 2) Μ. Θεµιστοκλέους και Β. Μαντζάνα (2010), Υπηρεσίες Παγκόσµιου Ιστού και υπηρεσιοστραφείς αρχιτεκτονικές, Μαρίνος Θεµιστοκλέους (Κωδικός Βιβλίου στον Εύδοξο: ). 3) S. Weerawarana, F. Curbera, F. Leymann, T. Storey και D. F. Ferguson (2008), Αρχιτεκτονική πλατφόρµας υπηρεσιών ιστού, Κλειδάριθµος (Κωδικός Βιβλίου στον Εύδοξο: 13613) Ορισµός και ιδιότητες των Υπηρεσιών Ιστού Στο χώρο του παγκόσµιου ιστού έχει προκύψει η ανάγκη για αλληλεπίδραση µεταξύ εφαρµογών που φιλοξενούνται σε αποµακρυσµένα µεταξύ τους συστήµατα. Οι εφαρµογές αυτές µπορεί να εκτελούνται σε ετερογενή συστήµατα ή/και να υλοποιούνται από διαφορετικές γλώσσες προγραµµατισµού. Οι υπάρχουσες κατανεµηµένες τεχνολογίες (π.χ. οι CORBA, RMI και DCOM) είναι πολύπλοκες και εξαρτώνται σε µεγάλο βαθµό από την υλοποίηση του εκάστοτε κατασκευαστή, ενώ παρουσιάζουν προβλήµατα ασφάλειας στην επικοινωνία µέσω του διαδικτύου, αφού απαιτούν να είναι ανοικτές, µη πρότυπες θύρες στα τείχη προστασίας (firewall).[1] Ταυτόχρονα, οι εφαρµογές πρέπει να εµφανίζουν ανοικτότητα ως προς την περιγραφή τους, την κλήση τους και την επαναχρησιµοποίησή τους. Έτσι, η Κοινοπραξία του Παγκόσµιου Ιστού (World Wide Web Consortium/W3C) όρισε ένα πρότυπο, τις Υπηρεσίες Ιστού (WS), προκειµένου να ξεπεραστούν προβλήµατα ετερογένειας, ανοικτότητας και διαλειτουργικότητας των συστηµάτων. Οι WS χρησιµοποιούν ήδη υπάρχοντα πρωτόκολλα και προδιαγραφές (HTTP, XML), µε αποτέλεσµα να µην εµφανίζουν περαιτέρω πολυπλοκότητα. Χρησιµοποιούν πρωτόκολλα κατανοητά από όλα τα συστήµατα και γλώσσες προγραµµατισµού, προσφέροντας έτσι διαλειτουργικότητα. Χάρη στη χρήση του πρωτοκόλλου HTTP, είναι ιδανικές για επικοινωνία µέσω του διαδικτύου και δεν αντιµετωπίζουν προβλήµατα µε τα τείχη προστασίας. Οι WS είναι µια τεχνολογία που επιτρέπει στις εφαρµογές να επικοινωνούν µεταξύ τους ανεξάρτητα από πλατφόρµες και γλώσσες προγραµµατισµού. Είναι διεπαφές λογισµικού, οι οποίες περιγράφουν µια συλλογή λειτουργιών που µπορεί να προσπελαστούν σε ένα δίκτυο µέσω τυποποιηµένων µηνυµάτων XML. Ένα σύνολο από WS που

2 αλληλεπιδρούν κατ αυτόν τον τρόπο ορίζει µια συγκεκριµένη υπηρεσία διαδικτυακής εφαρµογής στο πλαίσιο µιας Υπηρεσιοστρεφούς Αρχιτεκτονικής (Service Oriented Architecture/SOA).[2] Σε ένα πιο εννοιολογικό επίπεδο, µπορούµε να θεωρήσουµε τις υπηρεσίες ιστού ως µονάδες εργασίας (modules), καθεµία από τις οποίες χειρίζεται συγκεκριµένο λειτουργικό έργο. Χρησιµοποιώντας την XML για τη µεταφορά δεδοµένων, οδηγούµαστε προς χαλαρά συνδεδεµένες (loosely-coupled) εφαρµογές. Οι WS µπορούν να επανεκτιµούν, να τροποποιούν ή να χειρίζονται τύπους δεδοµένων δυναµικά κατ απαίτηση (on demand). Μετατρέπουν τις τεχνικές λειτουργίες σε προσανατολισµένες στην επιχείρηση (businessoriented) υπολογιστικές µονάδες. Επίσης, δίνουν τη δυνατότητα επαναχρησιµοποίησης του λογισµικού των εφαρµογών.[3] H στοίβα πρωτοκόλλων των WS Στην Εικόνα 9.1 δίνεται η στοίβα πρωτοκόλλων των WS. Εικόνα 9.1 Η στοίβα πρωτοκόλλων των WS. Οι WS χρησιµοποιούν το πρότυπο διαδικτυακό πρωτόκολλο HTTP, για τη µεταφορά µηνυµάτων, και την XML, για την αναπαράσταση των δεδοµένων. Για την επικοινωνία µεταξύ των εφαρµογών που τις ενθυλακώνουν, οι WS χρησιµοποιούν το πρωτόκολλο SOAP, το οποίο είναι βασισµένο στην XML, ενώ παρέχουν περιγραφή για τη διεπαφή τους, η οποία επιτρέπει τη δηµιουργία εφαρµογών πελάτη, προκειµένου αυτές να επικοινωνήσουν αποτελεσµατικά µαζί τους. Η περιγραφή παρέχεται σε ένα αρχείο XML, το οποίο ονοµάζεται Web Services Description Language (WSDL). Τέλος, καταχωρίζονται σε ευρετήρια (directories), ώστε οι δυνητικοί χρήστες τους να µπορούν να τις βρουν εύκολα. Αυτή η εύρεση υλοποιείται µε την υπηρεσία Universal Discovery Description and Integration (UDDI).[4],[5]

3 Εικόνα 9.2 Το µοντέλο λειτουργίας των WS Το µοντέλο λειτουργίας των WS αποτελείται από τρία βασικά συστατικά: Το µητρώο (registry) ή o µεσάζων (service broker), το οποίο λειτουργεί ως µια υπηρεσία αναζήτησης WS και υλοποιείται µε το UDDI. Τον πάροχο της υπηρεσίας (service provider), ο οποίος δηµοσιεύει τις υπηρεσίες του στο µητρώο. Για την ακρίβεια, δηµοσιεύει την περιγραφή των υπηρεσιών του, δηλαδή την WSDL, καθώς και την αναφορά για το πού βρίσκεται η υπηρεσία. Τον αιτούντα των υπηρεσιών (service requester) ή, αλλιώς, πελάτη, ο οποίος αναζητά υπηρεσίες στο µητρώο, λαµβάνει την περιγραφή της υπηρεσίας που τον ενδιαφέρει και, µε βάση αυτήν την περιγραφή, συνδέεται στην υπηρεσία, ώστε να στείλει αιτήσεις (µηνύµατα SOAP) στον πάροχο, ο οποίος απαντά επίσης µε µηνύµατα SOAP.[6] Oι δυνατότητες των WS Οι WS διαθέτουν µια σειρά από χαρακτηριστικά που τους δίνουν σηµαντικές λειτουργικές δυνατότητες. Συγκεκριµένα, επιτρέπουν: την αλληλεπίδραση µεταξύ υπηρεσιών σε οποιαδήποτε πλατφόρµα και ανεξαρτήτως γλώσσας, τη δηµιουργία ροών υπηρεσιών ιστού, προσοµοιώνοντας ροές εργασίας επιχειρησιακών περιβαλλόντων, µε ευέλικτη προσαρµογή στις µεταβαλλόµενες συνθήκες και ανάγκες, τη χαλαρή σύνδεση (loose-coupling) των υπηρεσιών, δηλαδή τη συνέχιση της λειτουργίας των αλληλεπιδράσεων µεταξύ των υπηρεσιών εφαρµογής σε κάθε αλλαγή που αφορά τον τρόπο σχεδιασµού και υλοποίησης ενός ή περισσότερων υπηρεσιών, την παροχή διεπαφών υπηρεσιών σε παραδοσιακές (legacy) εφαρµογές λογισµικού, προσφέροντάς τους τη δυνατότητα να λειτουργούν πλήρως µέσα στο περιβάλλον της συγκεκριµένης υπηρεσίας, την εισαγωγή άλλων συναρτήσεων διαχείρισης λειτουργιών, όπως είναι η ασφάλεια. Η τεχνολογία των WS εµπεριέχει µια οικογένεια πρωτοκόλλων και προδιαγραφών, προκειµένου να περιγράφει, να διανέµει και να αλληλεπιδρά µε υπηρεσίες. Η οικογένεια αυτή οµαδοποιείται βάσει κοινών λειτουργιών και χρήσεων σε υποοµάδες, οι οποίες:[7]

4 χειρίζονται ζητήµατα που αφορούν τα µηνύµατα, την περιγραφή των διεπαφών, τη διευθυνσιοδότηση και τη διανοµή, µε: o το SOAP, για τα ζητήµατα των µηνυµάτων, o την WSDL, για τον προσδιορισµό των διεπαφών, o την WS-Addressing, για τον προσδιορισµό του τρόπου αναγνώρισης και διευθυνσιοδότησης ενός WS σε µια κατανεµηµένη αρχιτεκτονική, και o το Web Services Invocation Framework, για τον προσδιορισµό των διεπαφών WSDL προσδιορίζουν τον τρόπο µε τον οποίο οι υπηρεσίες γνωστοποιούν τον εαυτό τους και εντοπίζουν η µία την άλλη, µε: o το UDDI, για τον εντοπισµό και την παροχή πρόσβασης σε υπηρεσίες, και o τη Web Services Inspection Language, ως εναλλακτικό µηχανισµό ασχολούνται µε την ασφάλεια των WS, µε: o τη WS-Security, για ασφαλείς επικοινωνίες παρέχουν προδιαγραφές για τις εφαρµογές, µε: o την Business Process Execution Language for Web Services (BPEL4WS), για τον καθορισµό των λειτουργιών της ροής εργασιών, και o τις WS-Transaction και WS-Coordination, οι οποίες χρησιµοποιούνται µαζί για το χειρισµό κατανεµηµένων δοσοληψιών (distributed transactional processing) ασχολούνται µε τις διεπαφές χρηστών και την αποµακρυσµένη προσπέλαση των WS, µε: o o τις WS-InteractiveApplications και τις WS-RemotePortals Το πρωτόκολλο SOAP Το SOAP είναι ένα ελαφρύ πρωτόκολλο, το οποίο προορίζεται για την ανταλλαγή δοµηµένων πληροφοριών σε ένα κατανεµηµένο περιβάλλον. Χρησιµοποιεί τεχνολογίες XML, για να καθορίσει ένα επεκτάσιµο πλαίσιο ανταλλαγής µηνυµάτων, το οποίο παρέχει µια δοµή µηνυµάτων που µπορεί να ανταλλαχθεί πάνω από ποικίλα δικτυακά πρωτόκολλα. Το πλαίσιο έχει σχεδιαστεί για να είναι ανεξάρτητο από οποιοδήποτε µοντέλο προγραµµατισµού και σηµασιολογία υλοποίησης. Καθορίζει ένα σύνολο κανόνων κωδικοποίησης για τα δεδοµένα και µια σύµβαση για την παραγωγή αποµακρυσµένων κλήσεων διαδικασίας (Remote Procedure Call/RPC). Αποτελεί τη βάση για ένα ευρύ φάσµα πρωτοκόλλων, που τρέχουν πάνω από άλλα πρωτόκολλα, όπως πάνω από το HTTP.[8]

5 Εικόνα 9.3 Επικοινωνία µέσω του πρωτοκόλλου SOAP. Ένα µήνυµα SOAP είναι βασισµένο στην XML και περιέχει τα ακόλουθα µέρη: Το Envelope, το ανώτερο στρώµα, το οποίο αντιπροσωπεύει το µήνυµα. Το Header, το στρώµα για τα προστιθέµενα δεδοµένα σε ένα µήνυµα SOAP. Το SOAP καθορίζει τις ιδιότητες, ώστε να µπορεί να προσδιορίσει ποιος θα πρέπει να ασχοληθεί µε ένα συγκεκριµένο στοιχείο και εάν η κατανόησή του είναι προαιρετική ή υποχρεωτική. Το Body, το στρώµα που περιλαµβάνει τις υποχρεωτικές πληροφορίες, οι οποίες προορίζονται για το δέκτη των µηνυµάτων. Τα µηνύµατα SOAP, τα οποία µπορεί να σταλούν χρησιµοποιώντας τα πρωτόκολλα HTTP, SMTP, TCP κτλ. Για παράδειγµα, η WS-Routing ορίζει συνδέσεις για τα µηνύµατα SOAP, µέσω των DIME, TCP και UDP.[9] Εικόνα 9.4. Δοµή µηνυµάτων στο SOAP. Επιγραµµατικά, οι χρήσεις των µηνυµάτων SOAP είναι οι εξής: Το SOAP είναι ένα πρωτόκολλο πάνω στο οποίο µπορεί να χτιστούν άλλα πρωτόκολλα, ώστε να παρέχουν υπηρεσίες που απαιτούνται από ασφαλή και αξιόπιστα περιβάλλοντα µηνυµάτων. Μπορεί να χρησιµοποιηθούν τα πρωτόκολλα WS-License και WS-Security, για να εξασφαλίσουν την ακεραιότητα και την εµπιστευτικότητα των µηνυµάτων SOAP. Το SOAP καθορίζει ένα µοντέλο για την επεξεργασία των µηνυµάτων ανά κατεύθυνση.

6 Μπορεί να συνδυαστούν πολλαπλά µηνύµατα σε µία και µόνο ανταλλαγή µηνυµάτων. Το SOAP επιτρέπει οποιονδήποτε αριθµό προτύπων ανταλλαγής µηνυµάτων (Message Exchange Patterns/MEP), όπου το ζευγάρι αίτησης/απόκρισης (request/response) είναι µόνο ένα. Άλλα παραδείγµατα περιλαµβάνουν τη ζήτηση/απόκριση (solicit/response), τις ειδοποιήσεις και τις συνοµιλίες τύπου οµοτίµων (peer-to-peer). Εικόνα 9.5 Χρήσεις του SOAP. Ένα απλό έγγραφο XML πρέπει να περιέχει τα ακόλουθα στοιχεία: Το υποχρεωτικό στοιχείο Envelope, από το οποίο να αναγνωρίζεται το έγγραφο XML ως µήνυµα SOAP. Όλα τα άλλα στοιχεία του µηνύµατος πρέπει να περιέχονται µέσα στο στοιχείο Envelope. Ένα προαιρετικό στοιχείο Header, το οποίο να περιλαµβάνει βοηθητικές πληροφορίες. Ένα υποχρεωτικό στοιχείο Body, το οποίο να περιλαµβάνει την κύρια πληροφορία του µηνύµατος. Ένα προαιρετικό στοιχείο Fault, το οποίο να περιέχεται στο Body και να παρέχει πληροφορίες για σφάλµατα κατά την επεξεργασία ενός µηνύµατος. Στον Κώδικα 9.1 δίνεται ο σκελετός ενός µηνύµατος SOAP. 1. <?xml version="1.0"?> 2. <soap:envelope 3. xmlns:soap=" /" 4. soap:encodingstyle=" > 5. <soap:header> </soap:header> 8. <soap:body> <soap:fault> </soap:fault> 13. </soap:body> 14. </soap:envelope> Κώδικας 9.1. Γενικός κώδικας ενός µηνύµατος SOAP.

7 Στον Κώδικα 9.1 παρατηρούµε τα ακόλουθα: Γραµµή 1: Καθορίζεται η έκδοση της γλώσσας XML που χρησιµοποιείται (version="1.0"). Γραµµές 2 έως 4: Ορίζεται το στοιχείο Envelope, στο οποίο αναγνωρίζεται το έγγραφο XML ως µήνυµα SOAP, καθώς και η κωδικοποίηση του εγγράφου (soap:encodingstyle). Γραµµές 5 έως 7: Ορίζεται το στοιχείο Header. Γραµµές 8 έως 13: Ορίζεται το στοιχείο Body, το οποίο εµπεριέχει το στοχείο Fault. Γραµµή 14: Κλείσιµο του µηνύµατος SOAP Τα στοιχεία Envelope και Header Το στοιχείο Envelope πρέπει να καθορίζει το χώρο ονοµάτων xmlns:soap: για να αναγνωρίζεται από τον παραλήπτη ως το στοιχείο Envelope ενός µηνύµατος SOAP. Χρησιµοποιεί την ιδιότητα soap:encodingstyle, για να υποδεικνύει τους κανόνες κωδικοποίησης που χρησιµοποιούνται. Η σύνταξή της είναι η εξής: soap:encodingstyle="uri" και, για σχήµα, χρησιµοποιείται συνήθως το Για το στοιχείο Header, ισχύουν τα εξής: Αν υπάρχει, πρέπει να είναι το πρώτο στοιχείο-παιδί του στοιχείου Envelope. Τα άµεσα παιδιά του Envelope πρέπει να ορίζονται µε κάποιον χώρο ονοµάτων (namespace qualified). Οι βασικότερες ιδιότητες του Header είναι η Actor και η MustUnderstand. Ειδικότερα: o Actor: Μερικά µέρη του µηνύµατος µπορεί να προορίζονται για κάποιον ενδιάµεσο κόµβο από τον οποίο θα περάσει το µήνυµα SOAP, και όχι για τον τελικό παραλήπτη. H ιδιότητα αυτή χρησιµοποιείται ώστε η επικεφαλίδα του µηνύµατος να απευθυνθεί σε έναν τέτοιο κόµβο. o MustUnderstand: Καθορίζει αν πρέπει ή όχι ο παραλήπτης να προχωρήσει στην επεξεργασία κάποιου στοιχείου του Header. Στον Κώδικα 9.2 δίνεται ένα παράδειγµα Envelop και Header. 1. <?xml version="1.0"?> 2. <soap:envelope 3. xmlns:soap=" 4. soap:encodingstyle=" 5. <soap:header> 6. <m:trans xmlns:m=" 7. soap:mustunderstand="1">234</m:trans> 8. </soap:header> </soap:envelope> Κώδικας 9.2. Ο κώδικας Envelop και Header του SOAP. Στον Κώδικα 9.2 παρατηρούµε τα εξής:

8 Γραµµές 1 και 2: Αρχικά, καθορίζεται η έκδοση της γλώσσας XML που χρησιµοποιείται (version="1.0") και στη συνέχεια ορίζεται το στοιχείο Envelope. Γραµµή 3: Καθορίζεται ο χώρος ονοµάτων µέσω της xmlns:soap, για να αναγνωρίζεται από τον παραλήπτη ως το στοιχείο Envelope ενός µηνύµατος SOAP. Γραµµή 4: Ορίζονται οι κανόνες κωδικοποίησης που χρησιµοποιούνται. Γραµµές 5 έως 8: Ορίζεται το στοιχείο Header και ένα στοιχείο τύπου Trans, το οποίο πρέπει ο παραλήπτης να επεξεργαστεί, αφού η τιµή της ιδιότητας mustunderstand ισούται µε 1. Γραµµές 9 έως 10: Ορίζονται πιθανές εντολές που µπορεί να υπάρχουν επιπρόσθετα. Γραµµή 11: Κλείνει το SOAP Envelope. Για το στοιχείο Body, ισχύουν τα εξής: Περιέχει το ουσιαστικό µήνυµα και απευθύνεται αποκλειστικά στον τελικό παραλήπτη, και όχι σε κάποιον ενδιάµεσο κόµβο. Τα στοιχεία που χρησιµοποιούνται στο SOAP Body βασίζονται στο έγγραφο WSDL της WS, στην οποία στέλνεται η αίτηση SOAP (και από την οποία στέλνεται η απόκριση SOAP). Στα υποστοιχεία του Body µπορεί να καθοριστεί ένας χώρος ονοµάτων (namespace), αν απαιτείται από το έγγραφο WSDL, για την αναγνώριση της υπηρεσίας. Στον Κώδικα 9.3 δίνεται ένα παράδειγµα στοιχείου Body, όπου φαίνονται η αίτηση και η απόκριση ενός µηνύµατος SOAP. Αίτηση: <soap:body> <gettermrequest> <term>price</term> </gettermrequest> </soap:body Απόκριση: <soap:body> <gettermresponse> <value>678</value> </gettermresponse> </soap:body> Κώδικας 9.3. Κώδικας body του SOAP Το στοιχείο Fault Το στοιχείο Fault περιέχει τα µηνύµατα λάθους και την κατάσταση ενός µηνύµατος SOAP. Δεν µπορεί να υπάρχουν περισσότερα του ενός στοιχεία Fault. Αποτελείται από τα εξής υποστοιχεία: <faultcode>: Κώδικας για την ανίχνευση Faults. Οι κώδικες αυτοί είναι οι ακόλουθοι: o Client: Το µήνυµα δεν είναι σωστά δοµηµένο ή είχε εσφαλµένες πληροφορίες. o Server: Υπήρχε κάποιο πρόβληµα µε τον εξυπηρετητή.

9 o VersionMismatch: Μη έγκυρος χώρος ονοµάτων για το στοιχείο Envelope. o MustUnderstand: Ένα άµεσο υποστοιχείο του στοιχείου Header, µε την ιδιότητα MustUnderstand να έχει τιµή 1, δεν έγινε κατανοητό. <faultstring>: Μια εξήγηση για το Fault, σε µορφή κατανοητή από τον άνθρωπο. <faultactor>: Πληροφορίες σχετικά µε το ποιος προκάλεσε το Fault. <detail>: Πληροφορίες σχετικά µε το Fault που είναι συγκεκριµένες για την WS και αφορούν το στοιχείο Body. Ένα παράδειγµα πλήρους αίτησης SOAP (SOAP Request) που περιέχεται σε αίτηση HTTP (HTTP Request) δίνεται στον Κώδικα 9.4. POST /InStock HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body xmlns:m=" <m:getproductprice> <m: ProductName>Jonshon</m: Product Name> </m:get Product Price> </soap:body> </soap:envelope> Κώδικας 9.4. Παράδειγµα µιας αίτησης SOAP που περιέχεται σε µια αίτηση HTTP. 9.3 H γλώσσα περιγραφής WS Ένα αρχείο WSDL είναι ένα έγγραφο XML στο οποίο περιγράφονται ένα σύνολο µηνυµάτων SOAP και ο τρόπος ανταλλαγής αυτών των µηνυµάτων. Εφόσον το WSDL είναι κώδικας XML, µπορεί να διαβαστεί και να µετατραπεί, αλλά τις περισσότερες φορές παράγεται και καταναλώνεται αυτόµατα από το λογισµικό. Ένα WSDL καθορίζει τι πρέπει να περιέχει ένα µήνυµα αίτησης και πώς θα µοιάζει το µήνυµα απόκρισης µε σαφή σηµειογραφία. Η σηµειογραφία που χρησιµοποιεί ένα αρχείο WSDL για την περιγραφή µορφών µηνύµατος βασίζεται αφενός στο πρότυπο XML Schema, δηλαδή είναι ουδέτερη των προγραµµατιστικών γλωσσών, και αφετέρου σε πρότυπα τα οποία την καθιστούν κατάλληλη για την περιγραφή διεπαφών των WS, που είναι προσπελάσιµες από ένα µεγάλο σύνολο πλατφορµών και προγραµµατιστικών γλωσσών. Η WSDL καθορίζει πού βρίσκεται διαθέσιµη η υπηρεσία και ποιο πρωτόκολλο επικοινωνίας χρησιµοποιείται για να µιλήσει στην υπηρεσία.[9] Το αρχείο WSDL καθορίζει ό,τι χρειάζεται ένα πρόγραµµα για να συνεργαστεί µε µια WS. Υπάρχουν διαθέσιµα διάφορα εργαλεία για την ανάγνωση ενός αρχείου WSDL και την παραγωγή του απαραίτητου κώδικα για την επικοινωνία µε µια WS. Υπάρχουν πολλά εργαλεία για το SOAP που επιτρέπουν την παραγωγή αρχείων WSDL από υπάρχουσες

10 διεπαφές προγραµµάτων, αλλά όµως υπάρχουν λίγα εργαλεία για την άµεση συγγραφή µιας WSDL. Έτσι, το έγγραφο WSDL είναι ένα σχήµα XML για την περιγραφή WS, ως ένα σύνολο από τελικά σηµεία, τα οποία λειτουργούν µε ανταλλαγή µηνυµάτων, που περιέχουν πληροφορίες προσανατολισµένες είτε στα έγγραφα είτε στις διαδικασίες. Ένα έγγραφο WSDL χρησιµοποιείται για να περιγράψει τι µπορεί να κάνει µια WS, πού βρίσκεται και πώς µπορεί κάποιος να το καλέσει. Τα βασικότερα στοιχεία ενός εγγράφου WSDL είναι τα εξής: <porttype>: οι λειτουργίες της WS, <message>: τα µηνύµατα που χρησιµοποιούνται από την WS, <types>: οι τύποι δεδοµένων που χρησιµοποιούνται από την WS, <binding>: τα πρωτόκολλα επικοινωνίας που χρησιµοποιούνται από την WS. Καθορίζει συνήθως τη σύναψη του HTTP µε το SOAP. Στον Κώδικα 9.5 δίνεται η δοµή ενός εγγράφου WDSL. <definitions> <types> definition of types... </types> <message> definition of a message... </message> <porttype> definition of a port... </porttype> <binding> definition of a binding... </binding> </definitions> Κώδικας 9.5. Δοµή ενός εγγράφου WSDL. Στον Κώδικα 9.6 δίνεται το παράδειγµα ενός εγγράφου WDSL. <message name="gettermrequest"> <part name="term" type="xs:string"/> </message> <message name="gettermresponse"> <part name="value" type="xs:string"/> </message> <porttype name="glossaryterms"> <operation name="getterm"> <input message="gettermrequest"/> <output message="gettermresponse"/> </operation> </porttype> Κώδικας 9.6. Παράδειγµα ενός εγγράφου WSDL. Στον Κώδικα 9.6, το στοιχείο <porttype> καθορίζει το "glossaryterms" ως το όνοµα µιας θύρας (port) και το "getterm" ως το όνοµα µιας λειτουργίας. Η λειτουργία "getterm"

11 έχει ένα µήνυµα εισόδου, το επονοµαζόµενο "gettermrequest", και ένα µήνυµα εξόδου, το επονοµαζόµενο "gettermresponse". Τα στοιχεία <message> καθορίζουν τα µέρη κάθε µηνύµατος και τους τύπους δεδοµένων µε τους οποίους σχετίζονται. Σε σύγκριση µε τον κλασικό προγραµµατισµό, η glossaryterms είναι µια βιβλιοθήκη συναρτήσεων ή µια κλάση, η getterm είναι η συνάρτηση, η gettermrequest είναι η παράµετρος της συνάρτησης και η gettermresponse είναι η τιµή που επιστρέφει η συνάρτηση To στοιχείο Binding Στο τέλος του παραδείγµατος του Κώδικα 9.6 προσθέτουµε το στοιχείο Binding, όπως φαίνεται στον Κώδικα 9.7. <binding type="glossaryterms" name="b1"> <soap:binding style="document" transport=" /> <operation> <soap:operation soapaction=" <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> Κώδικας 9.7. To στοιχείο Binding. Το στοιχείο Binding έχει δύο ιδιότητες, τη Name και την Type: H Name καθορίζει το όνοµα της σύναψης (Binding). Η Type δείχνει στη θύρα όπου θα γίνει η σύναψη. Στην περίπτωσή µας, είναι η θύρα "glossaryterms". Το στοιχείο "soap:binding" έχει δύο ιδιότητες, τη Style και την Transport: Η Style µπορεί να έχει την τιµή "rpc" ή "document". Στην περίπτωσή µας, χρησιµοποιούµε την τιµή document. Η Transport καθορίζει το πρωτόκολλο µεταφοράς των µηνυµάτων SOAP. Στην περίπτωσή µας, χρησιµοποιούµε το HTTP. Το στοιχείο Operation καθορίζει κάθε λειτουργία που εκθέτει τη θύρα. Πρέπει: να καθοριστεί η αντίστοιχη ενέργεια SOAP (SOAP action), για κάθε λειτουργία, και να καθοριστεί ο τρόπος µε τον οποίο κωδικοποιούνται η είσοδος και η έξοδος (π.χ. στο παράδειγµά µας, αναγράφεται η επιλογή "literal"). 9.4 Το πρότυπο UDDI

12 Το UDDI είναι ο «χρυσός οδηγός» των WS. Μέσω µιας τέτοιας υπηρεσίας µπορεί κάποιος να αναζητήσει εταιρείες οι οποίες προσφέρουν τις υπηρεσίες που χρειάζεται, να ενηµερωθεί για τις προσφερόµενες υπηρεσίες και να επικοινωνήσει µε κάποιον για περισσότερες πληροφορίες. Μια WS µπορεί να προσφερθεί χωρίς να καταχωρηθεί σε ένα UDDI, αλλά το τελευταίο χρειάζεται για να µπορούν να τη βρίσκουν οι πελάτες. Μια καταχώρηση καταλόγου UDDI είναι ένα αρχείο XML, το οποίο περιγράφει µια επιχείρηση και τις υπηρεσίες που αυτή προσφέρει, και περιέχει τρία µέρη: τις white pages, οι οποίες περιγράφουν την εταιρεία που προσφέρει την υπηρεσία, τις yellow pages, οι οποίες περιέχουν βιοµηχανικές κατηγορίες, και τις green pages, οι οποίες περιγράφουν τη διεπαφή της υπηρεσίας. Οι υπηρεσίες καθορίζονται µέσω ενός εγγράφου UDDI, του επονοµαζόµενου Type Model ή tmodel.[10] Συχνά, το tmodel περιέχει ένα αρχείο WSDL, το οποίο περιγράφει µια διεπαφή SOAP σε µια WS, αλλά είναι αρκετά ευέλικτο, ώστε να περιγράφει σχεδόν οποιοδήποτε είδος υπηρεσίας. Ο κατάλογος UDDI περιέχει επίσης διάφορους τρόπους αναζήτησης των υπηρεσιών που χρειάζονται για την κατασκευή µιας εφαρµογής. Μπορεί να γίνει αναζήτηση των παρόχων µιας υπηρεσίας σε καθορισµένη γεωγραφική τοποθεσία ή µιας επιχείρησης ενός συγκεκριµένου είδους. Η προδιαγραφή (specification) WS-Inspection επιτρέπει την αναζήτηση ανάµεσα σε µια συλλογή από WS που προσφέρονται σε συγκεκριµένο εξυπηρετητή, για την εύρεση της επιθυµητής. Για να έχουν νόηµα οι WS, πρέπει οι εν δυνάµει χρήστες τους να ξέρουν πού βρίσκονται ή, ισοδύναµα, να ξέρουν πού µπορούν να βρουν τις απαιτούµενες πληροφορίες, για να τις χρησιµοποιήσουν. Αν και άρχισαν ως πρότυπο για το διαδίκτυο, τα µητρώα UDDI, που ήταν δηµόσια εκτεθειµένα στο διαδίκτυο, έπαψαν πλέον να υπάρχουν, αφού κατακλύστηκαν από µη έγκυρες πληροφορίες. Σήµερα, χρησιµοποιούνται κυρίως σε ενδοδίκτυα µεγάλων οργανισµών. Το UDDI καθορίζει υπηρεσίες που υποστηρίζουν την περιγραφή και την ανακάλυψη των οργανισµών/εταιρειών που παρέχουν WS, των διαθέσιµων WS και των τεχνικών διεπαφών που πρέπει να χρησιµοποιηθούν, ώστε κάποιος χρήστης να έχει πρόσβαση σε αυτές. Ένα έγγραφο XML UDDI περιέχει τα εξής στοιχεία: BusinessEntity: Δίνει στοιχεία για τις πραγµατικές επιχειρήσεις ή τους πραγµατικούς οργανισµούς που παρέχουν οι WS (όνοµα, στοιχεία επικοινωνίας κτλ.). BusinessService: Υποστοιχείο του businessentity, που δίνει µη τεχνικές πληροφορίες για µια WS. BindingTemplate: Υποστοιχείο του businessservice, που δίνει πληροφορίες για το πώς και από πού υπάρχει πρόσβαση στην WS. Tmodel: Παρέχει τις τεχνικές προδιαγραφές της WS. Εναλλακτικά, υπάρχει τρόπος περιγραφής µε κατηγορίες σελίδων. Στην Εικόνα 9.6 φαίνεται το µοντέλο δεδοµένων (data model) UDDI, καθώς και οι κατηγορίες των Pages, µε τις αντίστοιχες λειτουργίες τους.

13 Εικόνα 9.6 Δοµή του UDDI. Στον Πίνακα 9.1 παρουσιάζονται οι βασικές λειτουργίες του UDDI.[7] Πληροφορία White Pages: Πληροφορίες όπως το όνοµα, η διεύθυνση, το τηλέφωνο και άλλα στοιχεία επικοινωνίας για µια επιχείρηση. Λειτουργίες Publish: Πώς ο προµηθευτής µιας WS καταχωρεί τον εαυτό του. Yellow Pages: Πληροφορίες που κατηγοριοποιούν επιχειρήσεις, µε βάση υπάρχοντα πρότυπα (µη ηλεκτρονικά). Find: Πώς µια εφαρµογή βρίσκει συγκεκριµένη WS. Green Pages: Τεχνικές πληροφορίες που παρέχονται από µια επιχείρηση για τις WS. Bind: Πώς µια εφαρµογή συνδέεται και αλληλεπιδρά µε µια WS, αφότου αυτή βρεθεί. Πίνακας 9.1 Λειτουργίες του UDDI. Στη συνέχεια, αναφέρεται µια σειρά συσχετίσεων των WS µε άλλες τεχνολογίες: Οι WS είναι ανεξάρτητες της γλώσσας προγραµµατισµού, µε αποτέλεσµα να µπορούν να υλοποιηθούν σε πολλές γλώσσες, όπως είναι οι Java, C#, Python και Perl. Οι περισσότερες WS βασίζονται σε προγράµµατα που τρέχουν σε περιβάλλοντα εξυπηρετητών εφαρµογών (application servers), όπως είναι τα Glassfish, WebSphere και Apache Tomcat. Οι WS συµβάλλουν στη βελτίωση της λειτουργίας του υπολογιστικού µοντέλου σε κινητά και φορητά περιβάλλοντα, καθώς παρέχουν απλούστερες και καθολικές διεπαφές. Η τεχνολογία πλέγµατος (grid) έχει υιοθετήσει τις WS ως µέρος της αρχιτεκτονικής Open Grid Services. Οι WS έχουν αναπτυχθεί και χρησιµοποιούνται ευρέως και στα περιβάλλοντα υπολογιστικής νέφους (cloud computing). Από άποψη χρηστικότητας, για τις WS, ισχύουν τα εξής:

14 Σε ένα πιο βασικό επίπεδο, µια WS µπορεί να χρησιµοποιηθεί ως µια προχωρηµένη οικογένεια πρωτοκόλλων επικοινωνίας, επιτρέποντας έτσι στις εφαρµογές να µιλούν µεταξύ τους, επιτυγχάνοντας διαλειτουργικότητα. Σε ένα άλλο επίπεδο, οι WS µπορεί να χρησιµοποιηθούν µε βάση την Υπηρεσιοστρεφή Αρχιτεκτονική (Service Oriented Architecture/SOA), η οποία επιτρέπει την επαναχρησιµοποίηση λογισµικού και τη χρήση τεχνολογιών, όπως και των κατανεµηµένων επικοινωνιών υπηρεσιών. Σε ένα υψηλότερο επίπεδο, το µοντέλο SOA και οι σχετικές του υπηρεσίες µπορεί να θεωρούνται δοµικά συστατικά, τα οποία ενδέχεται να συναθροιστούν (ολοκληρωθούν) µέσα σε µεγαλύτερες ενότητες, για τη δηµιουργία ολοκληρωµένων εφαρµογών, όπως είναι οι ροές εργασίας, µε λειτουργίες που καθορίζουν τη συµπεριφορά τους. 9.5 Σύγκριση των WS µε άλλες τεχνολογίες Οι WS δεν εξαρτώνται από πλατφόρµες και γλώσσες, µια και χρησιµοποιούν την ΧΜL. Για παράδειγµα, ο πελάτης µπορεί να είναι υλοποιηµένος σε C++, σε περιβάλλον Windows, ενώ η WS να είναι υλοποιηµένη σε Java, σε περιβάλλον Linux. Οι περισσότερες WS χρησιµοποιούν για τη µετάδοση µηνυµάτων το πρωτόκολλο ΗΤΤP. Αυτό είναι µεγάλο πλεονέκτηµα, για την κατασκευή µιας διαδικτυακής εφαρµογής, δεδοµένου ότι οι περισσότεροι διαµεσολαβητές διαδικτύου (Internet proxies) και τα τείχη προστασίας δεν ασχολούνται µε το πρωτόκολλο HTTP, σε αντίθεση µε την CORBA. Οι WS δηµιουργούν επιβάρυνση, δεδοµένου ότι η µετάδοση όλων των δεδοµένων σε XML δεν είναι, προφανώς, τόσο αποδοτική όσο είναι µε τη χρήση λύσεων δυαδικής µορφής (binary). Δηλαδή, ενώ κερδίζουµε σε µεταφερσιµότητα, χάνουµε σε απόδοση. Ωστόσο, η επιβάρυνση αυτή είναι, εν γένει, αποδεκτή στις περισσότερες περιπτώσεις. Οι WS παρουσιάζουν έλλειψη ευελιξίας, καθώς επιτρέπουν µόνο µερικές πολύ βασικές µορφές κλήσεων υπηρεσίας, ενώ, για παράδειγµα, η CORBA παρέχει στους προγραµµατιστές πολλές υποστηρικτικές υπηρεσίες, όπως είναι η επιµονή (persistency), οι ειδοποιήσεις (notifications), η διαχείριση κύκλου ζωής (lifecycle management) και οι δοσοληψίες (transactions). Εντούτοις, υπάρχουν αναπτυξιακές προσπάθειες που έχουν στόχο να κάνουν τις WS περισσότερο ευέλικτες. 9.6 Παράδειγµα µιας WS υλοποιηµένης σε Java Για την απλοποίηση της δηµιουργίας WS, χρησιµοποιούνται πλατφόρµες που αποκρύπτουν από τον προγραµµατιστή την πολυπλοκότητα του προγραµµατισµού του SOAP και του WSDL. Δηµοφιλέστερες πλατφόρµες για τη γλώσσα Java είναι οι Java API for XML WS (JAX-WS) και η Apache Axis. Στην πλευρά του εξυπηρετητή (server-side), ο προγραµµατιστής πρέπει απλώς να καθορίσει τις λειτουργίες της WS, θέτοντας σε µια κλάση Java τις µεθόδους που τις υλοποιούν. Αφού µεταγλωττιστεί η κλάση, το εργαλείο wsgen αναλαµβάνει να δηµιουργήσει το αρχείο WSDL, για να δηµοσιευθεί η υπηρεσία. Φυσικά, αν θέλει, ο προγραµµατιστής δεν χρησιµοποιεί το wsgen και δηµιουργεί το δικό του αρχείο WSDL. Τα αρχεία που υλοποιούν την WS πρέπει να πακεταριστούν σε ένα αρχείο WAR, και αυτό να φορτωθεί (upload) στον εξυπηρετητή εφαρµογών.[11] Η πλευρά του πελάτη υλοποιείται εξίσου εύκολα. Με βάση το αρχείο WSDL της υπηρεσίας, δηµιουργείται ένας διαµεσολαβητής (proxy), δηλαδή ένα τοπικό αντικείµενο, που αντιπροσωπεύει την υπηρεσία στη µεριά του καλούντος (πελάτη). Το JAX-WS µετατρέπει τις κλήσεις API σε µηνύµατα SOAP.

15 Δίνεται ένα απλό παράδειγµα µιας WS.[12],[13] Καταρχάς, πρέπει να έχουµε εγκατεστηµένα το Eclipse EE 1 και τον Tomcat Ανοίγουµε το Eclipse EE, επιλέγουµε «File New Dynamic Web Project» και κάνουµε τις απαραίτητες ρυθµίσεις, όπως στην Εικόνα 9.7, προκειµένου να δηµιουργήσουµε το project, ρυθµίζοντας και τον εξυπηρετητή εφαρµογής που θα το φιλοξενήσει. Εικόνα 9.7 Ρυθµίσεις της WS. Στη συνέχεια, επιλέγουµε «Next» και µετά «Finish». Έπειτα, πατάµε δεξί κλικ στο όνοµα του project (Java Web) και επιλέγουµε «New Class». Κάνουµε τις απαραίτητες ρυθµίσεις, όπως στην Εικόνα 9.8, και επιλέγουµε «Finish», προκειµένου να δηµιουργήσουµε την κλάση states.java στο πακέτο com.test

16 Εικόνα 9.8 Δηµιουργία µιας κλάσης Java. Ο Κώδικας 9 περιέχει το αρχείο States.java.. package com.test; public class States { public String getmsg(string state) { String statedetails = null; if (state.equals("cl")) { statedetails = "<State><name>California</name><shortname>CL</shortnam e>" + "<headq>test1</headq><language>english</language></sta te>"; } else if (state.equals("ny")) { statedetails = "<State><name>New York</name><shortname>NY</shortname>" + "<headq>test2</headq><language>french</language></stat e>"; } else { statedetails = "State not found"; } return statedetails;

17 } } Κώδικας 9.8. H κλάση States.java. Στη συνέχεια, πατάµε δεξί κλικ στο όνοµα του project, επιλέγουµε «New Web Service» και κάνουµε τις απαραίτητες ρυθµίσεις, όπως στην Εικόνα 9.9, προκειµένου να δηµιουργήσουµε µια WS βασισµένη στην κλάση com.test.states. Καθορίζεται ότι ο τύπος του πελάτη θα είναι Java Proxy, ενώ στο τέλος επιλέγουµε «Finish». Εικόνα 9.10 Δηµιουργία µιας WS. Μετά, εµφανίζεται το παράθυρο της Εικόνας 9.10, στο οποίο επιλέγουµε «Next», προκειµένου να δηµιουργηθεί το αρχείο περιγραφής της WS, δηλαδή το wsdl.

18 Εικόνα 9.10 Δηµιουργία του WSDL. Ο Κώδικας 9.9 περιέχει το αρχείο States.wsdl. <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions targetnamespace=" xmlns:apachesoap=" xmlns:impl=" xmlns:intf=" xmlns:wsdl=" xmlns:wsdlsoap=" l/soap/" xmlns:xsd=" <wsdl:porttype name="states"> </wsdl:porttype>

19 <wsdl:binding name="statessoapbinding" type="impl:states"> <wsdlsoap:binding style="document" transport=" p"/> </wsdl:binding> <wsdl:service name="statesservice"> <wsdl:port binding="impl:statessoapbinding" name="states"> <wsdlsoap:address location=" vices/states"/> </wsdl:port> </wsdl:service> </wsdl:definitions> Κώδικας 9.9. Το αρχείο States.wsdl. Μετά, εµφανίζεται η οθόνη της Εικόνας 9.11, στην οποία ρυθµίζουµε τον πελάτη δοκιµών (test client). Τέλος, επιλέγουµε «Next» και έτσι ξεκινά ο εξυπηρετητής ιστού.

20 Εικόνα 9.11 Ρυθµίσεις (µετά την επιτυχή εκκίνηση του εξυπηρετητή), για έλεγχο του διαµεσολαβητή της WS. Πατώντας δεξί κλικ στο όνοµα του project (JaxService) και επιλέγοντας «Run on Server», τρέχουµε την WS, όπως φαίνεται στην Εικόνα 9.12.

21 Εικόνα 9.12 Η σελίδα της WS. 9.7 Οι Restful WS Οι Restful WS είναι κατασκευασµένες για να δουλεύουν πιο γρήγορα και πιο αποτελεσµατικά στον παγκόσµιο ιστό. To Representational State Transfer (REST) είναι ένα στιλ καθορισµού περιορισµών, όπως η οµοιοµορφία του περιβάλλοντος διεπαφής (WS interface), το οποίο, αν εφαρµοστεί σε µια WS, επιφέρει επιθυµητές ιδιότητες, όπως επίδοση (performance), επεκτασιµότητα (scalability) και τροποποιησιµότητα (modifiability), ιδιότητες που δίνουν τη δυνατότητα στις WS να δουλεύουν βέλτιστα στον παγκόσµιο ιστό. Στο αρχιτεκτονικό στιλ REST, τα δεδοµένα και η λειτουργικότητα θεωρούνται πόροι (resources) και είναι προσβάσιµα µε τη χρήση των Uniform Resource Identifiers (URI), τα οποία δεν είναι τίποτε άλλο από υπερσύνδεσµοι του διαδικτύου. Αυτοί οι πόροι ενεργοποιούνται χρησιµοποιώντας ένα σύνολο από απλές και καλά καθορισµένες λειτουργίες.[14] Ως προγραµµατική προσέγγιση, οι Restful WS είναι µια ελαφριά εναλλακτική λύση στις WS και στο RPC. Όπως και οι WS, οι Restful WS: δεν εξαρτώνται από την πλατφόρµα, δεν εξαρτώνται από τη γλώσσα προγραµµατισµού (η C # µπορεί να επικοινωνήσει µε την Java κτλ.), βασίζονται σε πρότυπα (τρέχουν πάνω από το HTTP), µπορεί εύκολα να χρησιµοποιηθούν µε την παρουσία του τείχους προστασίας. Όπως οι WS, έτσι και οι Restful WS δεν προσφέρουν ενσωµατωµένα χαρακτηριστικά ασφαλείας, όπως κρυπτογράφηση, διαχείριση συνεδριών, εγγυήσεις ποιότητας υπηρεσιών κτλ. Ωστόσο, αυτά µπορούν να προσφερθούν µε την προσθήκη λειτουργιών πάνω σε HTTP: Για λόγους ασφαλείας, τα χαρακτηριστικά όνοµα χρήστη/κωδικός πρόσβασης χρησιµοποιούνται συχνά. Για την κρυπτογράφηση, το Restful µπορεί να χρησιµοποιηθεί πάνω από το πρωτόκολλο HTTPS (Secure Sockets).

22 Τα cookies δεν µπορεί να αποτελούν µέρος ενός καλού σχεδιασµού Restful, στον οποίο οι λειτουργίες είναι αυτόνοµες και κάθε αίτηση φέρει µαζί της όλες τις πληροφορίες (κατάσταση) που χρειάζεται ο εξυπηρετητής για να την ολοκληρώσει. Το αρχιτεκτονικό στιλ Rest υποστηρίζει την αρχιτεκτονική πελάτη-εξυπηρετητή και είναι σχεδιασµένο να χρησιµοποιεί ένα πρωτόκολλο επικοινωνίας που δεν κρατά την κατάστασή του (stateless), όπως το HTTP, το οποίο είναι και το σύνηθες. Στο Rest, οι πελάτες και οι εξυπηρετητές ανταλλάσσουν αναπαραστάσεις πόρων (resource representation), χρησιµοποιώντας ένα προτυποποιηµένο περιβάλλον διεπαφής και πρωτoκόλλου. Οι εφαρµογές που βασίζονται στις υπηρεσίες Rest ή Restful είναι απλές, ελαφριές και γρήγορες, χάρη στις εξής ιδιότητες: Ταυτοποίηση πόρων µέσω URI: Μια υπηρεσία ιστού Restful εκθέτει ένα σύνολο πόρων, οι οποίοι καθορίζουν τους στόχους αλληλεπίδρασης µε τους πελάτες της. Οι πόροι ταυτοποιούνται από τα URI, τα οποία παρέχουν έναν καθολικό χώρο διευθυνσιοδότησης, για εύρεση πόρων και υπηρεσιών. Οµοιόµορφο περιβάλλον διεπαφής: Οι πόροι ελέγχονται χρησιµοποιώντας τέσσερις λειτουργίες: τη δηµιουργία (PUT), την ανάγνωση (GET), την ενηµέρωση (POST) και τη διαγραφή (DELETE) ενός πόρου. Η PUT δηµιουργεί έναν νέο πόρο, ο οποίος µπορεί να διαγραφεί µε την DELETE. Η GET ανακτά την τρέχουσα κατάσταση ενός πόρου σε µερική αναπαράσταση, ενώ η POST µεταφέρει σε έναν πόρο µια νέα κατάσταση. Αυτοπεριγραφικά µηνύµατα: Οι πόροι υφίστανται αποσύζευξη (decoupling) από την αναπαράστασή τους, έτσι ώστε το περιεχόµενό τους να είναι προσβάσιµο από µια ποικιλία µορφότυπων (formats), όπως από HTML, XML, απλό κείµενο, PDF, JPEG και JSON. Τα µεταδεδοµένα (metadata) για τους πόρους είναι διαθέσιµα και µπορεί να χρησιµοποιηθούν, προκειµένου, για παράδειγµα, να ελέγχουν την κρυφή µνήµη (caching), να ανιχνεύουν λάθη µετάδοσης, να ρυθµίζουν το κατάλληλο µορφότυπο αναπαράστασης των δεδοµένων και να εκτελούν αυθεντικοποίηση και έλεγχο πρόσβασης. Αλληλεπιδράσεις stateful µέσω υπερσυνδέσµων: Κάθε αλληλεπίδραση µε έναν πόρο είναι stateless. Αυτό σηµαίνει ότι τα µηνύµατα αιτήσεων είναι ανεξάρτητα. Οι αλληλεπιδράσεις stateful βασίζονται στην ιδέα της µεταφοράς κατάστασης. Υπάρχουν αρκετές τεχνικές για την ανταλλαγή κατάστασης, όπως η επανεγγραφή του URI (URI rewriting), τα cookies και η απόκρυψη από πεδία φορµών. Η κατάσταση µπορεί να ενσωµατωθεί σε µηνύµατα απόκρισης, ώστε αυτά να δείχνουν σε έγκυρες µελλοντικές καταστάσεις της αλληλεπίδρασης Παράδειγµα Restful WS Για το παράδειγµα που παρουσιάζεται, απαιτείται η ύπαρξη του NetBeans IDE. Ανοίγουµε το NetBeans IDE και επιλέγουµε «File New Project Java Web Web Application».[15] Έπειτα, επιλέγουµε «Next» και δίνουµε στο project το όνοµα «HelloRestful». Έτσι, ελέγχουµε ότι ο εξυπερετητής (Server) είναι ο GlassFish. Τέλος, επιλέγουµε «Finish». Στη συνέχεια, πατάµε δεξί κλικ στο «Project New Other Web Services Restful Web Services from Patterns». Επιλέγουµε «Simple Root Resource» και µετά «Next». Στο πεδίο «Resource Package Name» επιλέγουµε «Restful». Στο πεδίο «Path» δίνουµε το όνοµα «HelloRest». Στο πεδίο «Class Name» δίνουµε το όνοµα «HelloRestful». Ως «MIME Type» επιλέγουµε «text/hmtl» και, τέλος, επιλέγουµε «Finish». Στο αρχείο HelloRestful.java που δηµιουργείται έχουµε τον Κώδικα package Restful; import javax.ws.rs.core.context; import javax.ws.rs.core.uriinfo;

23 import javax.ws.rs.pathparam; import javax.ws.rs.produces; import javax.ws.rs.consumes; import javax.ws.rs.get; import javax.ws.rs.path; import public class HelloRestful private UriInfo context; /** Δηµιουργεί ένα νέο στιγµιότυπο της υπηρεσίας HelloRestful. */ public HelloRestful() { } /**Ανακτά την αναπαράσταση ενός στιγµιότυπου της υπηρεσίας ένα στιγµιότυπο του public String gethtml() { return "<html lang=\"en\"><body><h1>hello Class from Restful WS!</body></h1></html>"; } /** Μέθοδος PUT, για ενηµέρωση ή δηµιουργία ενός στιγµιότυπου της υπηρεσίας HelloRestful. *Αναπαράσταση περιεχοµένου για το WS. *Επιστροφή µιας απόκρισης HTTP µε το περιεχόµενο του ενηµερωµένου ή δηµιουργηµένου public void puthtml(string content) { } } Κώδικας To αρχείο HelloRestful.java. Για να επαληθεύσουµε τη λειτουργία της Restful WS, πατάµε δεξί κλικ στο «Project» και επιλέγουµε «Test Restful Web Services». Στην Εικόνα 9.13 φαίνεται η σελίδα που εµφανίζεται.

24 Εικόνα 9.13 Η σελίδα για τη δοκιµή της Restful WS. Επιλέγουµε «HelloRest» στην µπάρα πλοήγησης, στα αριστερά της σελίδας, και εµφανίζεται η σελίδα της Εικόνας Εικόνα 9.14 Η δεύτερη σελίδα για τη δοκιµή της Restful WS. Τέλος, επιλέγουµε «Test», για την επαλήθευση της λειτουργίας. Έτσι, εµφανίζεται η σελίδα που φαίνεται στην Εικόνα 9.15.

25 Εικόνα 9.15 Το αποτέλεσµα της εκτέλεσης της Restful WS. Στην ιστοσελίδα του Κεφαλαίου 9 του παρόντος συγγράµµατος, στον Ελληνικό Συσσωρευτή Ακαδηµαϊκών Ηλεκτρονικών Βιβλίων ( υπάρχει διαθέσιµο το βίντεο µε τίτλο video9.1_webservices, στο οποίο εξηγείται η τεχνολογία των Web Services και δίνονται σχετικά παραδείγµατα. Βιβλιογραφικές αναφορές [1] «Web Services Activity», διαθέσιµο στο (πρόσβαση: ). [2] W. Iverson (2004), Real World Web Services, O Reilly. [3] J. Snell, D. Tidwell και P. Kulchenko (2001), Programming Web Services with SOAP, O Reilly. [4] E. Newcomer (2002), Understanding Web Services: XML, WSDL, SOAP, and UDDI, Addison Wesley. [5] D. Hunter, K. Cagle, C. Dix κ.ά. (2001), Beginning XML, David Wrox Press. [6] E. Cerami (2002), Web Services Essentials: Distributed Applications with XML- RPC, SOAP, UDDI & WSDL, O Reilly. [7] S. Graham, S. Simeonov, D. Davis κ.ά. (2004), Building Web Services with Java: Making Sense of XML, SOAP, WSDL, and UDDI, Sams Publishing. [8] F. Curbera, M. Dufler κ.ά. (2002), «Unraveling the Web Services Web: An Introduction to SOAP, WSDL, and UDDI», IEEE Internet Computing, τόµ. 6, τχ. 2, σ

26 [9] S. Weerawarana, F. Curbera κ.ά. (2005), Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More, Prentice Hall PTR. [10] «D. Carlson: Modeling the UDDI schema with UML», διαθέσιµο στο (πρόσβαση: ). [11] R. Englander (2002), Java and Soap, O Reilly. [12] «Building Web Services with JAX-WS», διαθέσιµο στο (πρόσβαση: ). [13] «How to Create JAX-WS Web Services Using Eclipse», διαθέσιµο στο (πρόσβαση: ). [14] «What Are RESTful Web Services?», διαθέσιµο στο (πρόσβαση: ). [15] «Java Restful Web Services Simple Example», διαθέσιµο στο (πρόσβαση: ). Κριτήρια αξιολόγησης Ερώτηση 1 Ποιο από τα παρακάτω δεν αποτελεί πρόβληµα των κατανεµηµένων συστηµάτων; Α) Οι διαφορετικές εφαρµογές βρίσκονται σε διαφορετικές πλατφόρµες και είναι γραµµένες σε διαφορετικές γλώσσες. Β) Η υπολογιστική ισχύς αυξάνεται. Γ) Οι εφαρµογές πρέπει να αλληλεπιδρούν. Δ) Οι ήδη υπάρχουσες κατανεµηµένες τεχνολογίες είναι πολύ περίπλοκες. Ερώτηση 2 Ποιο από τα παρακάτω δεν ισχύει για τις WS; Α) Χρησιµοποιούν το πρωτόκολλο HTTP. Β) Χρησιµοποιούν το πρωτόκολλο SOAP. Γ) Χρησιµοποιούν την XML, για την αναπαράσταση δεδοµένων. Δ) Δεν χρησιµοποιούν το UDDI. Ερώτηση 3 Ποιο από τα παρακάτω πρωτόκολλα δεν βρίσκεται στη στοίβα πρωτοκόλλων των WS; Α) Το UDP. Β) Το UDDI. Γ) Το WSDL. Δ) Το HTTP. Ερώτηση 4 Από ποια συστατικά αποτελείται το µοντέλο των WS; Α) Μητρώο. Β) Συστάδα υπολογιστών. Γ) Εξυπηρετητή. Δ) Πάροχο. Ε) Αιτούντα. Ζ) Καταχωρητή. Ερώτηση 5

27 Τι αφορά ένα στοιχείο WSDL τύπου <porttype>; Α) Τα µηνύµατα που χρησιµοποιούνται από τις WS. Β) Τους τύπους δεδοµένων που χρησιµοποιούνται από τις WS. Γ) Τις λειτουργίες των WS. Δ) Τα πρωτόκολλα επικοινωνίας που χρησιµοποιούνται από τις WS. Ερώτηση 6 Ποιο από τα παρακάτω δεν ισχύει για το στοιχείο Binding; Α) Έχει δύο ιδιότητες. Β) Η ιδιότητα Transport καθορίζει το πρωτόκολλο µεταφοράς. Γ) Έχει τρεις ιδιότητες. Δ) Η ιδιότητα Style παίρνει δύο τιµές. Ερώτηση 7 Ποιο από τα παρακάτω δεν ισχύει για το SOAP; Α) Καθορίζει τον τρόπο µε τον οποίο πρέπει να επεξεργαστούν τα µηνύµατα. Β) Δεν καθορίζει τη δοµή των µηνυµάτων. Γ) Καθορίζει το πρωτόκολλο ανταλλαγής µηνυµάτων XML. Δ) Καθορίζει τη δοµή του µηνύµατος HTTP. Ερώτηση 8 Ένα έγγραφο XML δεν είναι υποχρεωτικό να διαθέτει το στοιχείο Envelope. Α) Σωστό. Β) Λάθος. Ερώτηση 9 Ποιο από τα παρακάτω δεν ισχύει για το στοιχείο Envelope; Α) Δεν έχει καµία σχέση µε το W3C. Β) Χρησιµοποιεί την ιδιότητα soap:encodingstyle. Γ) Η σύνταξη του είναι soap:encodingstyle="uri". Δ) Πρέπει να καθορίζει το χώρο ονοµάτων xmlns:soap. Ερώτηση 10 Ποιο από τα παρακάτω ισχύει για το στοιχείο Header; Α) Δεν είναι απαραίτητο να υπάρχει namespace. Β) Έχει τρεις βασικές ιδιότητες. Γ) Έχει τέσσερις βασικές ιδιότητες. Δ) Αν υπάρχει, πρέπει να είναι το πρώτο στοιχείο-παιδί του στοιχείου Envelope. Ερώτηση 11 Τ ο στοιχείο Body αναφέρεται σε κάποιον ενδιάµεσο κόµβο. Α) Σωστό. Β) Λάθος. Ερώτηση 12 Ποιο από τα παρακάτω δεν είναι υποστοιχείο του στοιχείου Fault; Α) Το Client. Β) Το Disqualify. Γ) Το Server. Δ) Το VersionMismatch. Ερώτηση 13 Το στοιχείο Faultactor περιέχει πληροφορίες σχετικά µε το ποιος προκάλεσε το σφάλµα. Α) Σωστό. Β) Λάθος.

28 Ερώτηση 14 Ποιο από τα παρακάτω δεν ισχύει για το UDDI; Α) Ξεκίνησε ως πρότυπο για το διαδίκτυο. Β) Καθορίζει υπηρεσίες που υποστηρίζουν την περιγραφή και την ανακάλυψη των οργανισµών/εταιρειών οι οποίες παρέχουν WS. Γ) Χρησιµοποιείται κυρίως σε ενδοδίκτυα µεγάλων οργανισµών. Δ) Τα µητρώα UDDI χρησιµοποιούνται ακόµη στο διαδίκτυο. Ερώτηση 15 Ποιες από τις παρακάτω σελίδες του UDDI δεν υπάρχουν; Α) Οι White Pages. Β) Οι Green Pages. Γ) Οι Red Pages. Δ) Οι Yellow Pages. Ερώτηση 16 Οι Restful WS χρησιµοποιούν πρωτόκολλο επικοινωνίας χωρίς καταστάσεις. Α) Σωστό. Β) Λάθος. Κεφάλαιο 9 1. Β 2. Δ 3. Α 4. Α, Δ και Ε 5. Γ 6. Γ 7. Β 8. Β 9. Α 10. Δ 11. Β 12. Β 13. Α 14. Δ 15. Γ 16. Α