Πανεπιστήμιο Πελοποννήσου Τμήμα Επιστήμης & Τεχνολογίας Υπολογιστών Ακαδημαϊκό έτος 2008-2009 Πτυχιακή εργασία Βελτιστοποίηση της εκτέλεσης σύνθετων υπηρεσιών διαδικτύου μέσω παροχέτευσης ενδιαμέσων αποτελεσμάτων Optimizing Composite Web Service Execution through Intermediate Result Streamlining Ομάδα εργασίας Επιβλέπων καθηγητής Καρκαλάκος Ιωάννης cst04030@uop.gr Βασιλάκης Κωνσταντίνος costas@uop.gr Γιαννόπουλος Ευστράτιος cst04031@uop.gr
Περιεχόμενα Περιεχόμενα... - 2 - Ευρετήριο σχημάτων... - 5 - Ευρετήριο πινάκων... - 5 - Ευρετήριο γραφημάτων... - 5-1 Σκοπός εργασίας... - 6-2 Summary... - 9-3 Αρχιτεκτονική βασισμένη σε υπηρεσίες... - 11-3.1 Τι είναι η αρχιτεκτονική βασισμένη σε υπηρεσίες;... - 11-3.2 Διαφορές μοντέλου υπηρεσιών διαδικτύου και ανθρωποκεντρικού μοντέλου υπηρεσιών... - 11-3.3 Αρχιτεκτονική και δομικά στοιχεία των υπηρεσιών διαδικτύου... - 12-3.4 Διαφορές μοντέλου υπηρεσιών διαδικτύου και υπόλοιπων κατανεμημένων τεχνολογιών... - 13-3.5 Βασικές τεχνολογίες υπηρεσιών διαδικτύου... - 14-3.5.1 Ανταλλαγή δεδομένων... - 14-3.5.2 Πρωτόκολλο επικοινωνίας... - 14-3.5.3 Γλώσσα περιγραφής παρεχόμενων υπηρεσιών... - 14-3.5.4 Καταχώρηση και ανάκτηση πληροφοριών υπηρεσίας... - 14-3.6 Βήματα ανάπτυξης και χρήσης εφαρμογής διαδικτύου... - 14-3.7 Εφαρμογές των υπηρεσιών διαδικτύου... - 15-3.8 Θέματα ασφαλείας... - 15-4 XML... - 17-4.1 Τι είναι XML;... - 17-4.2 Μεγάλη εξάπλωση της XML.... - 17-4.3 Το συντακτικό της XML... - 17-4.3.1 Στοιχεία ή ετικέτες... - 18-4.3.2 Ιδιότητες... - 18-4.4 XML Schema... - 18-4.4.1 Συντακτικό του XML SCHEMA...- 19-5 WSDL... - 21-5.1 Συντακτικό της WSDL... - 21-6 UDDI... - 23-7 SOAP... - 24-7.1 Τι είναι το SOAP... - 24-7.2 Συντακτικό του SOAP... - 24-7.2.1 Soap envelope... - 25-7.2.2 Soap Header... - 25 - - 2 -
7.2.3 Soap Fault... - 26-7.3 SOAP μέσω HTTP... - 27-7.4 Ασυμβατότητες SOAP... - 28-8 Άλλα πρωτόκολλα υπηρεσιών διαδικτύου... - 29-8.1 Εισαγωγή... - 29-8.2 EDI... - 29-8.3 XML-RPC... - 29-8.4 Επικοινωνούντα αντικείμενα...- 29-8.4.1 RMI... - 29-8.4.2 COM και DCOM... - 30-8.4.3 CORBA... - 30-9 Υλοποίηση... - 31-9.1 Εισαγωγή... - 31-9.2 Ανάλυση κώδικα... - 32-9.2.1 Επικοινωνία μέσω μηνυμάτων XML... - 32-9.2.2 Streamliner... - 34-9.2.2.1 Γενικά... - 34-9.2.2.2 Υλοποίηση... - 34-9.2.3 Aggregator... - 37-9.2.3.1 Γενικά... - 37-9.2.3.2 Υλοποίηση... - 37-10 Μέτρηση επιδόσεων... - 39-10.1 Εισαγωγή... - 39-10.2 Μετρήσεις... - 39-11 Επίλογος... - 43-12 Βιβλιογραφία... - 45-13 Παράρτημα κώδικα... - 47-13.1 Πακέτο streamliner... - 47-13.1.1 Αρχείο CompletedVariable.java... - 47-13.1.2 Αρχείο OperationId.java... - 47-13.1.3 Αρχείο OutputVariable.java... - 48-13.1.4 Αρχείο PendingVariable.java... - 49-13.1.5 Αρχείο Request.java... - 49-13.1.6 Αρχείο Requests.java... - 52-13.1.7 Αρχείο UnknownIncomingVariable.java... - 56-13.1.8 Αρχείο Optimize.java... - 57-13.1.9 Αρχείο Service.java... - 58-13.1.10 Αρχείο Parser.java... - 62-13.1.11 Αρχείο parsedmessage2send.java... - 69-13.2 Πακέτο aggregator... - 69-13.2.1 Αρχείο PendingReturns... - 70-13.2.2 Αρχείο Service.java... - 71-13.2.3 Αρχείο XMLParser.java... - 74 - - 3 -
13.2.4 Αρχείο sendmessage.java... - 80-13.3 Δοκιμαστική υπηρεσία... - 81-13.4 Δοκιμαστικός κώδικας χωρίς βελτιστοποίηση... - 82-13.5 Δοκιμαστικός κώδικας με βελτιστοποίηση... - 83 - - 4 -
Ευρετήριο σχημάτων Σχήμα 1 Σύνθεση υπηρεσιών... - 6 - Σχήμα 2 Βελτιστοποιημένη σύνθεση υπηρεσιών... - 7 - Schema 1 Web Service Synthesis... - 9 - Schema 2 Optimized web service synthesis... - 10 - Σχήμα 3 Ρόλοι οντοτήτων και ανταλλαγές μηνυμάτων στα πλαίσια του SOA... - 13 - Σχήμα 4 Δομή ενός μηνύματος SOAP... - 25 - Σχήμα 5 Παράδειγμα f=(x+y)*(z-k)... - 32 - Ευρετήριο πινάκων Πίνακας 1 - Αποτελέσματα εκτέλεσης διαδικασίας μη βελτιστοποιημένης περίπτωσης... - 40 - Πίνακας 2 - Αποτελέσματα εκτέλεσης διαδικασίας βελτιστοποιημένης περίπτωσης... - 40 - Πίνακας 3 - Σύγκριση αποτελεσμάτων... - 41 - Ευρετήριο γραφημάτων Γράφημα 1 - Σύγκριση χρόνου εκτέλεσης των δύο περιπτώσεων... - 41 - Γράφημα 2 Οφέλη χρήσης της βελτιστοποιημένης περίπτωσης... - 42 - - 5 -
1 Σκοπός εργασίας Ο σκοπός της εργασίας αυτής είναι να δημιουργηθεί ένας μηχανισμός που θα επιτρέπει την πιο αποτελεσματική εκτέλεση μιας σύνθεσης υπηρεσιών. Ως σύνθεση υπηρεσιών μπορούμε να θεωρήσουμε την διαδοχική κλήση υπηρεσιών S 1, S 2,, S n, όπου τα αποτελέσματα που επιστρέφονται από την υπηρεσία S i χρησιμοποιούνται ως παράμετροι για την υπηρεσία S j (1 i < j n). Στο σχήμα 1 απεικονίζεται μία σύνθεση υπηρεσιών, όπου ο χρήστης υπηρεσιών επιθυμεί το αποτέλεσμα της υπηρεσίας 3, η οποία απαιτεί ως είσοδο το αποτέλεσμα της υπηρεσίας 2 κ.ο.κ. Έτσι ο χρήστης των υπηρεσιών θα πρέπει να καλέσει πρώτα την υπηρεσία 1 και να συλλέξει το αποτέλεσμά της, το οποίο κατόπιν θα παραδώσει στην υπηρεσία 2 ως είσοδο κ.ο.κ. μέχρι να συλλεχθεί το αποτέλεσμα της υπηρεσίας 3. Αυτή η μέθοδος σχεδιασμού υπηρεσιών διαδικτύου ακολουθείται από τους περισσότερους παροχείς υπηρεσιών μέχρι σήμερα. Υπηρεσία 1 Υπηρεσία 2 Υπηρεσία 3 6 2 4 1 Αποτέλεσμα 1 Αποτέλεσμα 2 Τελικό αποτέλεσμα Αρχικά δεδομένα 3 5 Χρήστης υπηρεσιών Σχήμα 1 Σύνθεση υπηρεσιών Το αποτέλεσμα αυτό είναι ικανοποιητικό σαν τελική τιμή γιατί είναι αυτό που ζητούσαμε, αλλά η μέθοδος που ακολουθήθηκε δεν είναι καθόλου αποδοτική από δύο απόψεις : Από τη πλευρά του χρήστη ο οποίος αν δεν έχει τη τοπική εφαρμογή (δεν υπάρχει ή δεν του παρέχεται) θα πρέπει, για να συλλέξει το τελικό αποτέλεσμα, να συντονίσει τις κλήσεις ανάμεσα στις υπηρεσίες διαδικτύου. Θα πρέπει χρησιμοποιώντας ένα εργαλείο (π.χ. φυλλομετρητής ιστού) να στείλει τα αρχικά δεδομένα προς επεξεργασία στην Υπηρεσία 1, από εκεί να περιμένει (γιατί μπορεί να χρειάζεται και κάποιο χρόνο επεξεργασίας) για να πάρει το αποτέλεσμα 1 και να το δώσει στην υπηρεσία 2. Αυτή η διαδικασία θα πρέπει να γίνει για όλες τις υπηρεσίες, και είναι η πιο απλή περίπτωση καθώς σε μια πιο σύνθετη διαδικασία θα μπορούσαμε να έχουμε και επιστροφή σε προηγούμενη υπηρεσία. Από την άποψη του χρόνου, καθώς αυτή η διαδικασία εκτελεί πολλά ενδιάμεσα βήματα με την τοπική εφαρμογή χρήστη. Ξέρουμε ότι αυτά τα βήματα είναι χρονοβόρα καθώς εμπλέκονται οι χρόνοι αποστολής και λήψης των δεδομένων μέσω του δικτύου. Η πρότασή μας για βελτιστοποίηση της παραπάνω διαδικασίας, είναι να δημιουργηθεί ένα ενδιάμεσο λογισμικό ώστε να αναλαμβάνει την επικοινωνία μεταξύ των υπηρεσιών, και έτσι να ανταλλάσσουν μεταξύ τους τα δεδομένα που χρειάζονται για να συνθέσουν το τελικό αποτέλεσμα, όπως φαίνεται στο σχήμα 2. - 6 -
Υπηρεσία 1 Υπηρεσία 2 Υπηρεσία 3 Κλήση υπηρεσίας Αποτέλεσμα υπηρεσίας Streamliner 1 Ενδιάμεσο αποτέλεσμα Κλήση υπηρεσίας Αποτέλεσμα υπηρεσίας Streamliner 2 Ενδιάμεσο αποτέλεσμα Κλήση υπηρεσίας Αποτέλεσμα υπηρεσίας Streamliner 3 Κλήση streamliner με πληροφορίες για την παράδοση των αποτελεσμάτων Κλήση streamliner με πληροφορίες για την παραλαβή παραμέτρων και παράδοση των αποτελεσμάτων Κλήση streamliner με πληροφορίες για την παραλαβή παραμέτρων και παράδοση των αποτελεσμάτων Τελικό αποτέλεσμα Aggregator Αρχικά δεδομένα για κάθε υπηρεσία Τελικό αποτέλεσμα Τοπική εφαρμογή - Χρήστης Σχήμα 2 Βελτιστοποιημένη σύνθεση υπηρεσιών Η παραπάνω πρόταση δίνει το ίδιο αποτέλεσμα σαν τελική τιμή αποτελέσματος, αλλά βελτιώνει σε πολύ σημαντικό βαθμό τις ακόλουθες «προβληματικές» απόψεις: Στη βελτιστοποιημένη περίπτωση, ο χρήστης το μόνο που έχει να κάνει για να πάρει το τελικό αποτέλεσμα είναι να δώσει τα αρχικά δεδομένα στον aggregator, για να παραχθεί το τελικό αποτέλεσμα. Ο aggregator αναλαμβάνει να δώσει τις πληροφορίες και τα δεδομένα της εκτέλεσης στους streamliner. Αυτές οι πληροφορίες είναι η αλληλουχία των υπηρεσιών που πρέπει να εκτελεστούν. Από την άποψη του χρόνου, αυτό γίνεται κατά πολύ γρηγορότερα έχουμε και μείωση του χρόνου μεταφοράς των δεδομένων, καθώς αποφεύγεται η επιστροφή των ενδιάμεσων αποτελεσμάτων στον χρήστη, η οποία έχει ως μοναδικό σκοπό να του επιτρέψει να τα παραδώσει στις επόμενες υπηρεσίες που θα κληθούν. Λαμβάνοντας παράλληλα υπόψη ότι η επικοινωνία χρήστη-υπηρεσιών γίνεται συνήθως από πιο αργά κανάλια σε σχέση με την επικοινωνία aggregator-υπηρεσιών, τα οφέλη είναι σημαντικότερα. Tέλος, βελτίωση υπάρχει και σε ένα θέμα που σχετίζεται με την ασφάλεια. Στα παραπάνω σχήματα, αν ο πάροχος της υπηρεσίας 2 εμπιστεύεται τον πάροχο της υπηρεσίας 1 αλλά όχι και τον τελικό χρήστη υπηρεσιών, τότε αν δεν υπάρχει η μεσολάβηση του streamliner θα πρέπει να ληφθούν πρόσθετα μέτρα για να εξασφαλιστεί ότι ο τελικός χρήστης δεν θα αλλοιώσει, παραποιήσει ή πλαστογραφήσει τα - 7 -
ενδιάμεσα αποτελέσματα, ενώ στην εκδοχή με χρήση του aggregator και παροχέτευσης των ενδιάμεσων αποτελεσμάτων, τέτοιο ζήτημα δεν υφίσταται. - 8 -
2 Summary The purpose of this project is to create a mechanism that allows a more effective execution of a web service composition. The term web service composition refers to call the consecutive call of services S 1, S 2,, S n, where the results returned from the web service S i, are used as parameters for the web service S j (1 i < j n). In Figure 1 we represent the execution of a web service composition, where the user desires the result of service 3, which requires as input the result of service 2, etc. So, the user has to call firstly web service 1 and collect its result, then has to pass the result to service 2 as input and so on, until collecting the result of service 3. This web service design method is used by most web services providers. Service 1 Service 2 Service 3 2 4 Result 2 6 Final result 1 Result 1 Initial data 3 5 Web service user Figure 3 Web Service Synthesis This arrangement is satisfying in respect of the final value obtained since it is the one that the user has asked forbut the method that used is not efficient from two reasons: From the user point of view, that if s/he has not a locally executed application available (is does not exist or is not provided), s/he has to orchastrate the calls to web services. The user should employ an appropriate tool (e.g. browser), and send the initial data to service 1, wait for the result (because service 1 may need some time for processing and return the result) and pass it to service 2. This process has to be done for all services, and it is the simplest case of web service composition. Regarding the process execution time, this process makes a lot of intermediate steps requiring the intervenstion of the local application (user). These steps are time consuming, and the time required to sending and receiving intermediate results may be too large, because of user upload and download rate. Our solution for the optimization of this process is to create a middleware, whose purpose is to orchestrate the web services comprising a composite service, and arrange for transferring the intermediate results as appropriate. This approach is depicted in Figure 2. - 9 -
Service 1 Service 2 Service 3 Service result Service result Service result Service call Streamliner 1 Intermediate result Service call Streamliner 2 Intermediate result Service call Streamliner 3 Streamliner call with information about the process Streamliner call with information about the process Streamliner call with information about the process Final result Aggregator Initial data for service invocation Final result Local application - User Figure 4 Optimized execution of a web service composition This solution concludes to the same result with the previous one regarding the final value, but considerably improves the following aspects: In optimized case, user has only to present the initial data to the aggregator and wait to receive the final result. The aggregator undertakes the task of passing all information and data about the process to streamliners and collects and passes the result back to user. Execution time is improved, because less intermediare result transfers are performed. This case avoids unnecessary intermediate results to user, which the only purpose of these is to pass them to next services. Intermediate results are transferred directly from the producer to the consumer. Finally, there is improvement to security. If the provider of service 2 trusts the provider of service 1 but not the final user, in the non streamliner-mediated approach provider 2 would have to employ additional security mechanisms (e.g. digital signatures) to ensure that the intermediate results are not forged or modified by the user; when direct transfer is employed, the introduction of such mechanisms is not required. - 10 -
3 Αρχιτεκτονική βασισμένη σε υπηρεσίες 3.1 Τι είναι η αρχιτεκτονική βασισμένη σε υπηρεσίες; Η αρχιτεκτονική βασισμένη στις υπηρεσίες είναι μια τεχνολογία σχεδιασμού λογισμικού, η οποία επιτρέπει στις εφαρμογές να επικοινωνούν μεταξύ τους ανεξαρτήτως λειτουργικού συστήματος και γλώσσας προγραμματισμού. Η κυρίαρχη τάση αναφορικά με τον τρόπο επικοινωνίας χρησιμοποιεί το πρωτόκολλο HTTP για τη μεταφορά των μηνυμάτων, ενώ τα ίδια τα μηνύματα δομούνται με χρήση της γλώσσας περιγραφής XML. Η αρχιτεκτονική βασισμένη στις υπηρεσίες αποτελεί έναν μηχανισμό για την επικοινωνία πολλών ξεχωριστών κομματιών λογισμικού. Κάθε κομμάτι από αυτά μπορεί να έχει σχεδιαστεί από διαφορετικούς οργανισμούς με διαφορετικά εργαλεία ανάπτυξης λογισμικού, και κάθε κομμάτι λογισμικού μπορεί να κληθεί από διαφορετικές εφαρμογές. Αυτή η σύνδεση μεταξύ διαφόρων μονάδων λογισμικού γίνεται μέσω κάποιων προτύπων, τα οποία επιτρέπουν στους προγραμματιστές να χρησιμοποιούν τις εφαρμογές χωρίς να νοιάζονται για το πως είναι υλοποιημένες. Βάσει των ανωτέρω, η αρχιτεκτονική βασισμένη σε υπηρεσίες ή SOA (Service Oriented Architecture), όπως θα αναφέρεται σε όλο το έγγραφο, δημιουργεί εφαρμογές οι οποίες πληρούν τις παρακάτω προϋποθέσεις [2]: Είναι διαθέσιμες από το διαδίκτυο (internet) ή οποιοδήποτε ενδοδίκτυο (intranet) χρησιμοποιείται (για παράδειγμα η υπηρεσία που χρησιμοποιεί μια επιχείρηση και είναι διαθέσιμη στο τοπικό της δίκτυο) Χρησιμοποιεί ένα πρωτυποποιημένο σύστημα επικοινωνίας βασισμένο σε XML Είναι ανεξάρτητες από οποιοδήποτε λειτουργικό σύστημα ή γλώσσα προγραμματισμού Είναι αυτοπεριγραφόμενες από μια κοινή γραμματική XML Είναι δυνατόν να εντοπιστούν μέσω κάποιου μηχανισμού αναζήτησης 3.2 Διαφορές μοντέλου υπηρεσιών διαδικτύου και ανθρωποκεντρικού μοντέλου υπηρεσιών Αρχικά, ας περιγράψουμε το ανθρωποκεντρικό μοντέλο υπηρεσιών, το οποίο έχει καταλάβει το μεγαλύτερο ποσοστό των υπηρεσιών στο διαδίκτυο. Το ανθρωποκεντρικό μοντέλο υπηρεσιών στηρίζεται στο ότι ο άνθρωπος-χρήστης είναι η κεντρική οντότητα της υπηρεσίας. Για να γίνει πιο κατανοητό ας δώσουμε ένα παράδειγμα : Έστω η υπηρεσία ηλεκτρονικής αγοράς κάποιων προϊόντων που υπάρχει στο διαδίκτυο. Με την ανθρωποκεντρική προσέγγιση έχουμε την εξής διαδικασία: ο χρήστης της υπηρεσίας αυτής έχει παραγγείλει το προϊόν του και μετά από κάποιο χρονικό διάστημα θέλει να ενημερωθεί για την πρόοδο της παραγγελίας του. Για να το κάνει αυτό χρησιμοποιεί ένα πρόγραμμα πλοήγησης (browser), συνδέεται στην υπηρεσία στο διαδίκτυο, εισάγει τον κωδικό της παραγγελίας και μέσα από την υπηρεσία τού εμφανίζεται στην οθόνη η εξέλιξη της παραγγελίας του. Προφανώς στη θεώρηση SOA, δεν αγνοείται ο άνθρωπος κατά τον σχεδιασμό της εφαρμογής (εξάλλου τα πάντα γίνονται για διευκόλυνση του ανθρώπου) απλά δεν είναι αυτός που απαραίτητα ξεκινά την εκτέλεση της υπηρεσίας, ενώ παράλληλα η κεντρική οντότητα στον σχεδιασμό είναι η υπηρεσία. Για παράδειγμα, χρησιμοποιούμε μια υπηρεσία η οποία παρακολουθεί από μόνη της την εξέλιξη της παραγγελίας μας, για να γίνει αυτό θα πρέπει η διαδικτυακή υπηρεσία να χρησιμοποιεί τη γλώσσα XML ώστε να μπορεί να γίνει σωστά η επικοινωνία με την εφαρμογή μας. Η εφαρμογή αυτή ζητά δεδομένα από την υπηρεσία διαδικτύου και τα δίνει στις ενδιαφερόμενες τοπικές εφαρμογές (για παράδειγμα ιστορικό κίνησης, ειδοποίηση εξέλιξης παραγγελίας - 11 -
κ.λπ.). Μέσω των εφαρμογών αυτών μπορεί πλέον ο χρήστης να λάβει την πληροφορία για την εξέλιξη της παραγγελίας του (μοντέλο άντλησης pull) ή ακόμα και να υπάρχει τοπική εφαρμογή όπου θα τον ενημέρωνε με γραπτό μήνυμα στο κινητό του για πιθανή εξέλιξη της παραγγελίας (μοντέλο ώθησης push). 3.3 Αρχιτεκτονική και δομικά στοιχεία των υπηρεσιών διαδικτύου Σε αυτό το κεφάλαιο θα περιγράψουμε πώς λειτουργούν οι υπηρεσίες διαδικτύου, καθώς και από ποια επί μέρους τμήματα αποτελούνται. Για να καταλάβουμε καλύτερα τι είναι υπηρεσία διαδικτύου θα δώσουμε ένα παράδειγμα μιας τυπικής υπηρεσίας διαδικτύου, και μετά πάνω σ αυτό το παράδειγμα θα αναλύσουμε ποια είναι τα δομικά στοιχεία της συγκεκριμένης υπηρεσίας. Ένα παράδειγμα υπηρεσίας διαδικτύου είναι ένας εξυπηρέτης ενημέρωσης τοπικών καιρικών φαινομένων. Έστω ότι θέλουμε να μάθουμε τι καιρό έχει σε ένα μέρος της Ελλάδας, και υποθέτουμε ότι στο συγκεκριμένο μέρος υπάρχει αυτή η κατάλληλη υποδομή για την παροχή της πληροφορίας (δηλαδή υπάρχει υπολογιστής-εξυπηρέτης όπου δίνει την πληροφορία αυτή). Για να μάθουμε τον καιρό της περιοχής που μας ενδιαφέρει, θα ακολουθήσουμε την εξής διαδικασία: χρησιμοποιώντας ένα περιηγητή ιστού θα προσπελάσουμε μια ιστοσελίδα (γνωστή για εμάς, ας την ονομάσουμε «πληροφοριοδότη»), η οποία διαθέτει πληροφορίες για τις διευθύνσεις και τον τρόπο σύνδεσης όλων των εφαρμογών ενημέρωσης καιρικών φαινομένων για όλες τις περιοχές της Ελλάδας, που υποστηρίζουν τη συγκεκριμένη υπηρεσία. Από τον «πληροφοριοδότη» θα αναζητήσουμε τη περιοχή που μας ενδιαφέρει. Μετά έχοντας τη διεύθυνση της εφαρμογής και τον τρόπο σύνδεσης σε αυτήν, θα την προσπελάσουμε υποβάλλοντας μία αίτηση για ενημέρωση καιρού. Η τοπική υπηρεσία θα μας απαντήσει με τα τοπικά καιρικά φαινόμενα. Στις υπηρεσίες διαδικτύου οι όροι SOAP, UDDI και WSDL είναι αυτοί που περιγράφουν τα δομικά στοιχεία της αρχιτεκτονικής, όπως έχουν επικρατήσει στην τρέχουσα πρακτική 1. Από το παραπάνω παράδειγμα θα αναγνωρίσουμε τα δομικά στοιχεία της υπηρεσίας. Το SOAP στη συγκεκριμένη περίπτωση είναι ο τρόπος με τον οποίο θα κωδικοποιήσουμε την πληροφορία για να επικοινωνήσουμε με την εφαρμογή τοπικού καιρού (αυτό που μας επιστρέφει ο πληροφοριοδότης). Το UDDI είναι ο πληροφοριοδότης της περίπτωσης μας (η ιστοσελίδα που φυλάσσει πληροφορίες για όλες τις εφαρμογές των διαφόρων περιοχών). Και τέλος η WSDL είναι ο τρόπος με τον οποίο οι διαφορετικές υπηρεσίες περιγράφονται στο UDDI (πληροφοριοδότης), δηλ. σε ποια διεύθυνση μπορούμε να τις προσπελάσουμε, ποια δεδομένα εισόδου χρειάζονται και σε ποια μορφή, τι αποτελέσματα δίνουν κ.ο.κ.. Το ανωτέρω μοντέλο απεικονίζεται στο σχήμα 3. 1 Οι προδιαγραφές του SOA προβλέπουν και εναλλακτικές μεθόδους, π.χ. χρήση SMTP αντί για HTTP, REST (Representational State Transfer) αντί των SOAP/WSDL κ.λπ. Στο υπόλοιπο του παρόντος θα ακολουθήσουμε την κυρίαρχη τάση. - 12 -
5, Αποδοχή αίτησης και χρήση υπηρεσίας Πάροχος υπηρεσιών (τοπική εφαρμογή καιρού) 1, Δημοσίευση 4, Αίτηση για δέσμευση υπηρεσίας Πελάτης Κατάλογος υπηρεσιών UDDI 2, Αναζήτηση 3, Αποστολή πληροφοριών Πάροχος υπηρεσιών Πελάτης Πάροχος υπηρεσιών Πελάτης Σχήμα 5 Ρόλοι οντοτήτων και ανταλλαγές μηνυμάτων στα πλαίσια του SOA Σύμφωνα με τα παραπάνω μπορούμε να πούμε ότι μια καλώς ορισμένη αρχιτεκτονική υπηρεσιών διαδικτύου έχει τα παρακάτω χαρακτηριστικά : Ένα προτυποποιημένο τρόπο για επικοινωνία Ένα μηχανισμό για ανταλλαγή δεδομένων Μία περιγραφική γλώσσα ώστε να περιγράφει τις υπηρεσίες που προσφέρονται Ένα μηχανισμό για την καταχώρηση και ανάκτηση των πληροφοριών σχετικά με τις υπηρεσίες. 3.4 Διαφορές μοντέλου υπηρεσιών διαδικτύου και υπόλοιπων κατανεμημένων τεχνολογιών Εκτός από τη SOA έχουν αναπτυχθεί και άλλες κατανεμημένες αρχιτεκτονικές, όπως είναι το RPC και το RMI, υπάρχουν ωστόσο διαφορές μεταξύ του SOA και των άλλων προσεγγίσεων. Ο κύριος λόγος που κάνει τη SOA διαφορετική από τις υπόλοιπες τεχνολογίες είναι ο τρόπος με τον οποίο επικοινωνούν μεταξύ τους. Οι παλαιότερες τεχνολογίες χρησιμοποιούν ένα πρωτόκολλο επικοινωνίας το οποίο είναι αποκλειστικά υλοποιημένο για το συγκεκριμένο εργαλείο προγραμματισμού και επιτρέπει να γίνουν σε αυτό, από καθόλου έως ελάχιστες αλλαγές. Η SOA, από την άλλη πλευρά, χρησιμοποιεί την XML. Η XML είναι μια ευρέως διαδεδομένη γλώσσα για τη μορφοποίηση και την ανταλλαγή, δεδομένων όποτε είναι πολύ πιο εύκολο να επικοινωνήσουν διαφορετικές μονάδες λογισμικού μεταξύ τους. Ακόμη, η υιοθέτηση του HTTP για τη μεταφορά των μηνυμάτων διευκολύνει τη ζωή των προγραμματιστών, οι οποίοι δεν έχουν να ασχολούνται με τα firewall και τις υπόλοιπες ρυθμίσεις δικτύου, μπορεί να χρησιμοποιηθεί η διαμόρφωση που επιτρέπει τη χρήση του HTTP. Όποτε με τη SOA οι προγραμματιστές όταν θέλουν να χρησιμοποιήσουν κάποια υπηρεσία διαδικτύου υλοποιημένη από κάποιον άλλο φορέα, δεν χρειάζεται να σκεφτούν με πιο εργαλείο και πως είναι υλοποιημένη η - 13 -
συγκεκριμένη εφαρμογή. Το μόνο που έχουν να κάνουν είναι να διαμορφώσουν το κατάλληλο μήνυμα XML και να το αποστείλουν (συνήθως μέσω HTTP) για να πάρουν το αποτέλεσμα, χωρίς να έχουν κάποια ουσιαστική γνώση για το πώς έγινε η επεξεργασία για να παραχθεί αυτό το αποτέλεσμα. Συγκεντρωτικά μπορούμε να πούμε ότι οι υπηρεσίες διαδικτύου που είναι σχεδιασμένες με την αρχιτεκτονική SOA διαφέρουν από τις υπόλοιπες κατανεμημένες τεχνολογίες στους παρακάτω τομείς : Τα δεδομένα είναι μορφοποιημένα με συγκεκριμένο τρόπο (XML) ώστε να είναι δυνατή η επεξεργασία και η κατανόησή τους, ανεξάρτητα από το λειτουργικό σύστημα και τη γλώσσα προγραμματισμού όπου παραλαμβάνονται. Τα δεδομένα μεταφέρονται χρησιμοποιώντας προτυποποιημένα πρωτόκολλα επικοινωνίας (HTTP), τα οποία είναι κοινώς αποδεκτά, συνεπώς είναι διαθέσιμα παντού, ενώ παράλληλα μπορούν να αξιοποιηθούν άμεσα μηχανισμοί ασφάλειας που έχουν αναπτυχθεί για τα πρωτόκολλα αυτά. Η παρεχόμενη υπηρεσία είναι καλά καθορισμένη από ένα γνωστό και αποδεκτό μηχανισμό (WSDL) Οι υπηρεσίες βρίσκονται εύκολα μέσω ενός καλώς καθορισμένου πρότυπου (UDDI). 3.5 Βασικές τεχνολογίες υπηρεσιών διαδικτύου Ας δούμε τώρα τις βασικές τεχνολογίες που προτείνει η αρχιτεκτονική SOA. 3.5.1 Ανταλλαγή δεδομένων XML (Extended Markup Language), περιγραφική γλώσσα με καλά καθορισμένη σύνταξη και σημασιολογία, καθώς και ενσωματωμένο μηχανισμό για την ανταλλαγή δεδομένων μέσω διαφορετικών εφαρμογών. 3.5.2 Πρωτόκολλο επικοινωνίας SOAP (Simple Object Access Protocol), είναι ένα ελαφρύ πρωτόκολλο φτιαγμένο για την ανταλλαγή δομημένων πληροφοριών, με χρήση της XML. Έχει σχεδιαστεί ώστε να είναι ανεξάρτητο γλώσσας προγραμματισμού. 3.5.3 Γλώσσα περιγραφής παρεχόμενων υπηρεσιών WSDL (Web Services Description Language), βασίζεται στην XML και χρησιμοποιεί ένα σύνολο ετικετών για να περιγράψει μια υπηρεσία. Το καλό του συγκεκριμένου σημείου είναι ότι οι πελάτες μαθαίνουν πληροφορίες σχετικά με την υπηρεσία πριν επικοινωνήσουν μαζί της. 3.5.4 Καταχώρηση και ανάκτηση πληροφοριών υπηρεσίας UDDI (Universal Description Discovery and Integration), είναι ο κατάλογος που περιέχει όλες τις πληροφορίες που χρειαζόμαστε για να επικοινωνήσουμε με μια υπηρεσία διαδικτύου. Ο πάροχος της υπηρεσίας καταχωρεί εδώ την υπηρεσία του, και ο πελάτης αναζητά υπηρεσίες μέσω αυτού του καταλόγου. 3.6 Βήματα ανάπτυξης και χρήσης εφαρμογής διαδικτύου Από τη πλευρά του παρόχου υπηρεσιών : 1. Καθορισμός της παρεχόμενης υπηρεσίας 2. Υλοποίηση της υπηρεσίας σε κάποια γλώσσα προγραμματισμού 3. Εγκατάσταση της εφαρμογής παροχής υπηρεσιών - 14 -
4. Δημοσίευση της υπηρεσίας σε ένα κατάλογο υπηρεσιών 5. Αναμονή εξυπηρέτησης αιτήσεων Από τη πλευρά του χρήστη της υπηρεσίας : 1. Προσδιορισμός της ζητούμενης υπηρεσίας 2. Εντοπισμός κάποιας υπηρεσίας μέσω ενός καταλόγου υπηρεσιών 3. Αποστολή αίτησης παροχής υπηρεσίας στην υπηρεσία 4. Λήψη απάντησης από την υπηρεσία 3.7 Εφαρμογές των υπηρεσιών διαδικτύου Οι υπηρεσίες διαδικτύου άρχισαν να γίνονται γνωστές ως μικρές πηγές πληροφοριών, όπως είναι η παρουσίαση των τιμών των μετοχών ή της πρόγνωσης του καιρού. Τέτοιου τύπου πληροφορίες μπορούμε να βρούμε παντού στο διαδίκτυο. Γιατί όμως να τις ενσωματώσουμε σε υπηρεσίες; Οι υπηρεσίες διαδικτύου μας δίνουν έναν πιο δυναμικό και πιο οργανωμένο τρόπο παρουσίασης και παροχής των πληροφοριών. Κάθε μια από αυτές τις υπηρεσίες μπορεί να κληθεί από εμάς ώστε να μας επιστρέψει τα αποτελέσματά της, έτσι εμείς μπορούμε να την ενσωματώσουμε σε μια δική μας εφαρμογή. Αυτό μπορεί να κάνει τις εφαρμογές που τις χρησιμοποιούν πιο λειτουργικές και πιο εύκολα συντηρήσιμες, αλλά και τις πληροφορίες που υπάρχουν στο διαδίκτυο πιο χρήσιμες, για παράδειγμα: Θέλουμε να φτιάξουμε μια εφαρμογή που θα ενημερώνει τους χρήστες της για τον καιρό. Αυτή η εφαρμογή έχει ως κύριο χαρακτηριστικό της την συχνή ανανέωση των πληροφοριών της, όποτε θα πρέπει να βρούμε κάπου αυτές τις πληροφορίες. Στο διαδίκτυο υπάρχουν πολλές ιστοσελίδες που μας δίνουν τον καιρό, αλλά αν αυτές οι πληροφορίες επιστρέφονται με μορφή μιας ιστοσελίδας (έγγραφο HTML) είναι δύσκολο να μπορέσουμε να τις ενσωματώσουμε στην εφαρμογή μας. Και ακόμα και αν ενσωματωθούν, μέσω ανάλυσης της ιστοσελίδας και εξαγωγής των πληροφοριών, η εφαρμογή που θα φτιάξουμε θα είναι πολύ πιθανό να πάψει να λειτουργεί σωστά αν αλλάξει έστω και λίγο η ιστοσελίδα. Αν όμως οι πληροφορίες της συγκεκριμένης ιστοσελίδας καθίσταντο διαθέσιμες μέσω μιας υπηρεσίας, εμείς δεν θα είχαμε να κάνουμε τίποτα παραπάνω από το να την καλέσουμε. Με τη χρήση των υπηρεσιών διαδικτύου κάνουμε πιο χρήσιμες τις πληροφορίες που υπάρχουν στο διαδίκτυο για τους προγραμματιστές που θέλουν να τις χρησιμοποιήσουν, οι οποίοι πλέον μπορούν να τις χρησιμοποιήσουν έτσι ώστε να φτιάξουν εφαρμογές που παλαιοτέρα θα ήταν πολύ δύσκολο ως αδύνατο να φτιάξουν - για παράδειγμα μια εφαρμογή η όποια θα μας ειδοποιεί πότε η τηλεόραση έχει ταινίες που μας αρέσουν. 3.8 Θέματα ασφαλείας Η ασφάλεια ένα σημαντικό κομμάτι μιας υπηρεσίας διαδικτύου, σε κάποιες δε περιπτώσεις είναι πιο σημαντικό ακόμα και από την ίδια τη λειτουργία της υπηρεσίας. Η SOA δεν ενσωματώνει κανένα μηχανισμό ασφαλείας, κωδικοποίησης ή αυθεντικοποίησης. Τι μπορούμε να κάνουμε λοιπόν για να έχουμε ασφαλείς υπηρεσίες; Τα πρώτα χρόνια χρήσης της XML δεν υπήρχε κάποια μέθοδος ασφαλείας - ο μόνος τρόπος να εισαχθεί κάποια μορφής ασφάλεια ήταν να χρησιμοποιηθεί το πρωτόκολλο SSL. Επειδή στη γενική περίπτωση στο μοντέλο SOA η κλήση των υπηρεσιών γίνεται μέσω του πρωτοκόλλου HTTP, αντί για το απλό HTTP θα μπορούσε να χρησιμοποιηθεί το πρωτόκολλο HTTPS. Αυτή η μέθοδος είναι αρκετά αμφισβητήσιμη καθώς, όταν η επικοινωνία γίνεται με SSL, κάθε πακέτο κωδικοποιείται και στέλνεται ξεχωριστά, συνεπώς όταν έχουμε αποστολή πολλαπλών ανεξάρτητων πακέτων η επικοινωνία γίνεται ευάλωτη σε κρυπταναλυτικές επιθέσεις για την εύρεση - 15 -
του κλειδιού. Λύση σε αυτό το πρόβλημα θα μπορούσε να αποτελεί η μοντελοποίηση της υπηρεσίας έτσι ώστε να είναι απαραίτητη η αποστολή μίας μόνο αίτησης και μίας μόνο απάντησης, κάτι που είναι ωστόσο πρακτικά αδύνατο. Τα επόμενα χρόνια όμως άρχισαν να αναπτύσσονται μηχανισμοί ασφαλείας, όπου ενσωματώνονται στην XML. Χαρακτηριστικά που υπάρχουν αυτή τη στιγμή είναι[5][6] : XML Signature XML Encryption Message authentication διακρίβωση της ταυτότητας του αποστολέα και μέτρα ενάντια σε αποστολή πακέτων από μη εξουσιοδοτημένους χρήστες Message integrity ενάντια στην ακεραιότητα του πακέτου Message confidentiality ενάντια στη παρακολούθηση και υποκλοπή μηνυμάτων Message freshness ενάντια στις επανεκπομπές - 16 -
4 XML 4.1 Τι είναι XML; Μιλήσαμε παραπάνω για την XML και ότι χρησιμοποιείται ως εργαλείο για την υλοποίηση μιας SOA αρχιτεκτονικής, τι είναι λοιπόν η XML; Η XML (Extensible Markup Language) λοιπόν είναι μια γλώσσα αναπαράστασης δεδομένων, η όποια είναι ανεξάρτητη από το λειτουργικό και το υλικό της εκάστοτε υπολογιστικής πλατφόρμας. Για την αναπαράσταση των δεδομένων χρησιμοποιεί απλό κείμενο το οποίο περικλείεται από ετικέτες με τις οποίες παρέχεται δομή και σημασιολογία στα δεδομένα. Η XML είναι επεκτάσιμη, με την έννοια ότι μπορούν να χρησιμοποιηθούν οποιεσδήποτε ετικέτες για την περιγραφή των δεδομένων, έτσι ώστε να περιγράφονται αυτά πλήρως, χωρίς να υπάρχει καμία ανάγκη αλλαγής της ίδιας της XML, αρκεί βεβαία να τηρούμε το συντακτικό της XML για την αναπαράσταση των δεδομένων μας. 4.2 Μεγάλη εξάπλωση της XML. Η XML είναι μια πολύ διαδεδομένη γλώσσα και αυτό λόγω της ανεξαρτησίας της και της δυνατότητας επέκτασής της. Έχουν αναπτυχθεί πάρα πολλά εργαλεία σχετικά με την XML, και σ αυτά περιλαμβάνονται επεξεργαστές XML και αναγνώστες (εκτελεστές) XML. Όλα αυτά τα εργαλεία καλύπτουν σχεδόν όλα τα λειτουργικά συστήματα και τις γλώσσες προγραμματισμού. Ενδεικτικές γλώσσες προγραμματισμού που διαθέτουν εργαλεία επεξεργασίας και εκτέλεσης XML και είναι οι πιο διαδεδομένες σ αυτό το τομέα είναι οι Java, Perl, Python, C#, C, C++, και Ruby. Υπάρχουν δυο διαφορετικοί τρόποι σχεδιασμού επικοινωνίας δυο συστημάτων XML (XML Messaging): XML-RPC. Είναι η πιο απλή μέθοδος επικοινωνίας XML, χρησιμοποιεί XML για να υλοποιήσει κλήσεις απομακρυσμένων διαδικασιών (RPC). Τα αιτήματα στέλνονται μέσω μεθόδων HTTP POST,ενώ οι απαντήσεις XML ενσωματώνονται στην απάντηση HTTP. SOAP. Το SOAP είναι ένα πρωτόκολλο βασισμένο σε XML και χρησιμοποιείται για πολλές εφαρμογές επικοινωνίας μεταξύ υπολογιστών, η βασική χρήση του SOAP είναι να καλούνται μέθοδοι αντικειμένων μέσω HTTP. Τα δυο πρωτόκολλα σαν βασική σχεδίαση επικοινωνίας είναι παρόμοια. Ο κύριος λόγος της εξάπλωσης αυτής, βέβαια είναι η ανάγκη για μια κοινή γλώσσα ανταλλαγής δεδομένων. Αφού ως τότε ο καθένας έφτιαχνε ένα δικό του πρότυπο επικοινωνίας, όμως με αυτή την προσέγγιση η ανταλλαγή δεδομένων μεταξύ διαφορετικών προγραμμάτων ήταν αδύνατη. 4.3 Το συντακτικό της XML Η XML μοιάζει πολύ με την HTML (γλώσσα σχεδιασμού ιστοσελίδων), αφού και οι δυο έχουν παρόμοιο τρόπο σύνταξης για τις ετικέτες τους (περικλείονται με <> </> ). Η XML είναι ωστόσο πολύ πιο αυστηρή, καθώς αν. π.χ. ένα πεδίο στην HTML δεν κλείνει μπορεί το γεγονός αυτό μπορεί να αγνοηθεί, ενώ αντίθετα σε ένα κείμενο XML μία τέτοια παράλειψη οδηγεί σε σφάλμα και σταματά την επεξεργασία του κειμένου. Η βαθύτερη αιτία για αυτή τη διαφορά είναι ότι αν και φαινομενικά η XML μοιάζει με τη HTML, η τελευταία φτιάχτηκε για να υποστηρίζει την παρουσίαση των δεδομένων και όχι για την περιγραφή τους. Αυτό φαίνεται και από το παρακάτω παράδειγμα εγγράφου XML: <bookstore> <book category="children"> <title>harry Potter</title> <author>j K. Rowling</author> - 17 -
<year>2005</year> <price>29.99</price> </book> <book category="web"> <title>learning XML</title> <author>erik T. Ray</author> <year>2003</year> <price>39.95</price> </book> </bookstore> Ένα έγγραφο XML αποτελείται από στοιχεία και ιδιότητες. Ο τρόπος που οργανώνονται τα δεδομένα στην XML είναι δενδροειδής. Οπότε κάθε αρχείο θα πρέπει να περιέχει ένα στοιχείο-πάτερα το οποίο μπορεί να έχει οσαδήποτε παιδιά 2, και τα παιδιά με τη σειρά τους μπορεί να έχουν οσαδήποτε παιδιά. Έτσι στο τέλος θα σχηματιστεί ένα δένδρο το οποίο θα έχει τα απαραίτητα δεδομένα. 4.3.1 Στοιχεία ή ετικέτες Τα στοιχεία της XML μπορεί να περιέχουν δεδομένα, όπως είναι το <title> που περιέχει το Harry Potter. Η ακόμα μπορεί να περιέχουν και ιδιότητες που αφορούν τα συγκεκριμένα στοιχειά, όπως είναι το <book category="children">. Βεβαία τα στοιχεία πρέπει να υπάκουνε σε κάποιους κανόνες οι οποίοι είναι : Κάθε έγγραφο θα πρέπει να έχει ακριβώς ένα αρχικό στοιχείο-γονέα που θα έχει τον ρόλο της ρίζας Σε αντίθεση με την HTML όλα τα στοιχεία θα πρέπει να έχουν και ετικέτα κλεισίματος Στα στοιχεία παίζει ρόλο το αν είναι γραμμένα με πεζά η με κεφαλαία (case sensitive) Κάθε ετικέτα που ανοίγει θα πρέπει να κλείνει και με τη σωστή σειρά για παράδειγμα <book><title> XML </title> </book> και όχι <book><title> XML </book></title>. 4.3.2 Ιδιότητες Οι ιδιότητες χρησιμοποιούνται για να μας δώσουν περισσότερες πληροφορίες για τα δεδομένα τα οποία περιέχονται σε μία ετικέτα, όπως φαίνεται και στο υπόδειγμα <book category="children">, όπου η ιδιότητα ουσιαστικά μας λέει ότι το βιβλίο που υπάρχει στα δεδομένα προορίζεται για παιδιά. Βεβαία ποτέ δεν πρέπει να τα δεδομένα να περιέχονται στης ιδιότητες, αφού ο κύριος σκοπός των ιδιοτήτων είναι να περιγράψουν τα δεδομένα, που περιέχουν τα στοιχεία. 4.4 XML Schema Παραπάνω μιλήσαμε για το συντακτικό το οποίο πρέπει να τηρείται σε ένα έγγραφο XML, όμως πως μπορούμε να ελέγξουμε αν το συντακτικό είναι όντως σωστό; Σε κάθε έγγραφο XML αντιστοιχεί ένα έγγραφο τύπου XML schema. Το XML schema δεν είναι τίποτα παραπάνω από ένα έγγραφο το οποίο περιέχει τις απαραίτητες πληροφορίες, έτσι ώστε να μπορούμε να ελέγξουμε τη δομή και τη σειρά των στοιχείων και των δεδομένων ενός αρχείου XML. Ένα XML schema έχει ως κύρια χαρακτηριστικά του : 2 Στα σχήματα XML υπάρχει τρόπος να καθοριστεί το ποια παιδιά είναι έγκυρα, πόσες φορές μπορούν να επαναλαμβάνονται, μοναδικότητα τιμών κ.λπ. - 18 -
Τη δυνατότητα χρήσης βασικών τύπων δεδομένων όπως ακέραιος, χαρακτήρας, κ.ά. Τη δυνατότητα καθορισμού δικών μας τύπων δεδομένων για στοιχεία, οι όποιοι μπορούν να περιέχουν και άλλα στοιχεία. Με αυτόν τον τρόπο μπορούμε να φτιάξουμε και σύνθετους τύπους δεδομένων οι όποιοι υποστηρίζονται πλέον από τις περισσότερες βάσεις δεδομένων. Ακολουθεί ένα αντικειμενοστραφές πρότυπο, και έτσι μπορεί να χρησιμοποιηθεί εύκολα από τις αντικειμενοστραφείς γλώσσες προγραμματισμού. Μας δίνει τη δυνατότητα να ορίσουμε νέους τύπους δεδομένων με την χρήση άλλων τύπων όπως ακριβώς γίνεται και στις αντικειμενοστραφείς γλώσσες προγραμματισμού με την κληρονομικότητα. Επικυρώνει τη σειρά την όποια θα εμφανίζονται τα στοιχεία στους σύνθετους τύπους δεδομένων Μπορεί να ορίσει περιορισμούς στις τιμές των δεδομένων. Αυτό επιτυγχάνεται με διάφορους τρόπους όπως για παράδειγμα, τον καθορισμό της μεγίστης και της ελάχιστης τιμής των δεδομένων. Χρησιμοποιεί namespaces έτσι ώστε κάθε τύπος δεδομένων να είναι καθορισμένος μοναδικά. Αυτό είναι χρήσιμο για να αποφεύγονται προβλήματα που προκύπτουν όταν σε ένα έγγραφο χρησιμοποιούνται πολλαπλά σχήματα και τα σχήματα αυτά ορίζουν κάποια στοιχεία με το ίδιο όνομα. Με τη χρήση των namespaces κάθε στοιχείο καθορίζεται μοναδικά ώστε να αποφεύγονται οι συγκρούσεις από κοινά ονόματα. 4.4.1 Συντακτικό του XML SCHEMA Όπως προαναφέραμε, η χρήση του XML schema είναι για να ελέγχεται αν ένα έγγραφο XML είναι έγκυρο. Όμως πως συντάσσεται ένα XML schema; Η σύνταξη του ακολουθεί αυτή της γλώσσας XML, έχοντας κάποιες δεσμευμένες ετικέτες με συγκεκριμένη σημασιολογία. Για να αναλύσουμε την σύνταξη του θα χρησιμοποιήσουμε ένα παράδειγμα: Αρχείο XML: <card XMLns ="http://businesscard.org"> <name>john Doe</name> <title>ceo, Widget Inc.</title> <email>john.doe@widget.com</email> <phone>(202) 456-1414</phone> </card> Αντίστοιχο XML schema: 1 <schema XMLns ="http://www.w3.org/2001/xmlschema" XMLns:b="http://businesscard.org" targetnamespace="http://businesscard.org"> 2 <element name="card" type="b:card_type"/> 3 <element name="name" type="string"/> 4 <element name="title" type="string"/> 5 <element name="email" type="string"/> 6 <element name="phone" type="string"/> 7 <complextype name="card_type"> 8 <sequence> 9 <element ref="b:name"/> 10 <element ref="b:title"/> 11 <element ref="b:email"/> 12 <element ref="b:phone" minoccurs="0"/> 13 </sequence> 14 </complextype> 15 </schema> - 19 -
Όταν φτιάχνουμε ένα XML schema θα πρέπει να ορίσουμε και τα namespaces στα οποία αναφέρεται. Αυτό γίνεται στην πρώτη γραμμή του παραδείγματος με την χρήση του XMLns. Όμως σε αυτόν τον κώδικα υπάρχουν δυο namespaces το XMLns και το XMLns:b, όταν το XMLns δεν ακολουθείται από κάποιο «ταμπελάκι» (:b) σημαίνει ότι αυτό είναι το προκαθορισμένο namespace, και όλες οι μεταβλητές χωρίς «ταμπελάκι» ανήκουν σε αυτό. Όμως όταν έχουμε «ταμπελάκι» πρέπει να το παραθέσουμε μπροστά από μεταβλητή για να το αναγνωρίσει π.χ. b:card_type. Τέλος το targetnamespace μας καθορίζει το namespace που θα ανήκουν οι νέοι τύποι. Από τη γραμμή 2 έως και την 6 δηλώνουμε τα ονόματα των στοιχείων τα οποία θα χρησιμοποιήσουμε, καθώς και τους τύπους τους. Οι τύποι μπορεί να είναι απλοί π.χ. <element name="name" type="string"/> αλλά μπορεί να είναι και σύνθετοι τους οποίους θα ορίσουμε εμείς <element name="card" type="b:card_type"/>. Στη συνεχεία ορίζουμε τον σύνθετο τύπο τον οποίο δηλώσαμε στην γραμμή 2. Εδώ παραθέτουμε τα στοιχεία που ανήκουν στον τύπο. Με αυτόν τον τρόπο ορίζουμε τον τύπο των στοιχείων που θα περιέχει καθώς και τη σειρά τους. Βεβαία μπορούμε να ορίσουμε και περιορισμούς για τα δεδομένα ενός συγκεκριμένου στοιχείου ή κανόνες πληθικότητας. Για παράδειγμα, στη γραμμή 12 ορίζουμε ότι το συγκεκριμένο στοιχείο είναι προαιρετικό (μπορεί να δίνεται ή όχι). - 20 -
5 WSDL H WSDL μας επιτρέπει να περιγράψουμε το πώς θα είναι τα μηνύματα που θα χρειαστούμε για να επικοινωνήσουμε με μια υπηρεσία, τα σφάλματα που μπορούν να προκύψουν κατά την κλήση της υπηρεσίας καθώς και τη διεύθυνση στην οποία μπορούμε να την καλέσουμε. Οπότε ένα έγγραφο WSDL είναι απαραίτητο σε όσους θέλουν να επικοινωνήσουν με την υπηρεσία, αφού τους λέει την δομή την οποία πρέπει να έχει το μήνυμα τους, αλλά και τους τύπους των στοιχείων που θα περιέχει το μήνυμα, καθώς και τη διεύθυνση για πρόσβαση σ αυτή. Τα έγγραφα WSDL ακολουθούν το πρότυπο της XML και αυτό κάνει την WSDL ανεξάρτητη από τις γλώσσες προγραμματισμού. Το γεγονός αυτό κάνει την WSDL αρκετά καλή για την περιγραφή υπηρεσιών, στις οποίες η ανεξαρτησία είναι απαραίτητη. Η WSDL χρησιμοποιείται για να περιγράψει την δομή των αιτήσεων και των απαντήσεων αλλά πως ακριβώς; Αυτό το κάνει περιγράφοντας τι μπορεί να κάνει ένα web service, πού βρίσκεται και πώς να το καλέσει κανείς. Όποτε ένα έγγραφο WSDL περιέχει : Την περιγραφή των τύπων δεδομένων που περιέχονται στις αιτήσεις. Την περιγραφή των ίδιων των δεδομένων που θα περιέχονται στα μηνύματα. Τον τρόπο με τον όποιο μπορούμε να καλέσουμε μια υπηρεσία. Την περιγραφή της θέσης της συγκεκριμένης υπηρεσίας. Το πρωτόκολλο που χρησιμοποιεί η υπηρεσία. 5.1 Συντακτικό της WSDL Για να αναλύσουμε την σύνταξη της WSDL θα χρησιμοποιήσουμε ένα παράδειγμα για μια υπηρεσία που της δίνουμε το όνομα μας και μας λέει hello : 1 <?XML version="1.0" encoding="utf-8"?> 2 <definitions name="helloservice" targetnamespace="http://www.ecerami.com/wsdl/helloservice.wsdl" XMLns ="http://schemas.xmlsoap.org/wsdl/" XMLns:soap="http://schemas.XMLsoap.org/wsdl/soap/" XMLns:tns="http://www.ecerami.com/wsdl/HelloService.wsdl" XMLns:xsd="http://www.w3.org/2001/XMLSchema"> 3 <message name="sayhellorequest"> 4 <part name="firstname" type="xsd:string"/> 5 </message> 6 <message name="sayhelloresponse"> 7 <part name="greeting" type="xsd:string"/> 8 </message> 9 <porttype name="hello_porttype"> 10 <operation name="sayhello"> 11 <input message="tns:sayhellorequest"/> 12 <output message="tns:sayhelloresponse"/> 13 </operation> 14 </porttype> 15 <binding name="hello_binding" type="tns:hello_porttype"> 16 <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> 17 <operation name="sayhello"> 18 <soap:operation soapaction="sayhello"/> 19 <input> 20 <soap:body encodingstyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:examples:helloservice" use="encoded"/> - 21 -
21 </input> 22 <output> 23 <soap:body 24 encodingstyle="http://schemas.xmlsoap.org/soap/encoding/" 25 namespace="urn:examples:helloservice" 26 use="encoded"/> 27 </output> 28 </operation> 29 </binding> 30 <service name="hello_service"> 31 <documentation>wsdl File for HelloService</documentation> 32 <port binding="tns:hello_binding" name="hello_port"> 33 <soap:address location="http://localhost:8080/soap/servlet/rpcrouter"/> 34 </port> 35 </service> 36 </definitions> Απ ότι βλέπουμε η σύνταξη της WSDL ακολουθεί το πρότυπο της XML, ενώ έχει και κάποια κοινά στοιχεία με το XML schema. Παρατηρώντας τη δεύτερη γραμμή βλέπουμε ότι υπάρχουν ορισμοί για τα namespaces, η σημασία και η χρήση τους είναι ακριβώς ίδια με αυτή του XML schema η οποία αναλύθηκε παραπάνω. Στις γραμμές τρία έως και οχτώ δίνονται οι ορισμοί και οι τύποι των στοιχείων, τα οποία θα περιέχονται στις αιτήσεις και τις απαντήσεις. Στη συνέχεια (γραμμές εννέα έως και δεκατέσσερα) έχουμε την περιγραφή της υπηρεσίας sayhello. Εδώ περιγράφονται η μορφή της αίτησης και της απάντησης. Μια υπηρεσία βέβαια δεν είναι αναγκαστικό να έχει αίτηση και απάντηση αλλά μπορεί να περιέχει ένα από τα δύο π.χ. μία υπηρεσία καταγραφής μηνύματος σε ημερολόγιο μπορεί έχει μόνο την αίτηση που περιέχει το μήνυμα προς καταγραφή. Οι υπηρεσίες αυτές λέγονται μονόδρομες. Μετά την περιγραφή της υπηρεσίας (γραμμές δεκαπέντε έως και εικοσιένα), έχουμε τους ορισμούς των πρωτοκόλλων τα οποία θα χρησιμοποιούν για την επικοινωνία με την υπηρεσία. Εκτός από αυτό ορίζονται και οι περιοχές ονομάτων (namespaces) που θα χρησιμοποιήσει η συγκεκριμένη υπηρεσία. Οι περιοχές ονομάτων χρησιμοποιούνται για να επιλύονται εύκολα περιπτώσεις όπου διαφορετικές υπηρεσίες χρησιμοποιούν τον ίδιο προσδιοριστή για να αναφερθούν σε διαφορετικούς τύπους αντικειμένων. Στο τέλος του παραδείγματος έχουμε την περιγραφή της θέσης της υπηρεσίας και του τρόπου με τον όποιο μπορούμε να την καλέσουμε. - 22 -
6 UDDI Tο UDDI (Universal Description Discovery and Integration) είναι ένας τρόπος που παρέχεται για να είναι δυνατός ο εντοπισμός των υπηρεσιών. Το UDDI περιλαμβάνει τεχνικά χαρακτηριστικά για τη δημιουργία ενός κατανεμημένου καταλόγου με τις επιχειρήσεις και τις υπηρεσίες. Τα δεδομένα ανταλλάσσονται σε XML. Το UDDI περιέχει API (εγχειρίδια χρήσης και πληροφορίες) για το πώς μπορεί να αναζητηθούν και να προστεθούν υπηρεσίες. Τα δεδομένα είναι διαθέσιμα σε οποιονδήποτε θέλει να πραγματοποιήσει αναζητήσεις και επίσης είναι δυνατόν να προστεθούν υπηρεσίες στη λίστα διαθέσιμων υπηρεσιών (εδώ ακολουθείται κάποια πολιτική για το ποιος έχει δικαίωμα, για παράδειγμα είναι εργαζόμενος). Τα δεδομένα που υποστηρίζει μια υπηρεσία UDDI είναι τριών ειδών : White pages: Αυτή η κατηγορία περιλαμβάνει γενικές πληροφορίες για την εταιρεία, για παράδειγμα, όνομα, διεύθυνση, και κάποια περιγραφή. Yellow pages: Αυτή η κατηγορία περιλαμβάνει κατηγοριοποίηση της εταιρείας σε σχέση με το είδος της υπηρεσίας που προσφέρει, ή το είδος της εταιρείας. Green pages: Αυτή η κατηγορία είναι αυτή που δίνει στον υποψήφιο χρήστη της υπηρεσίας πληροφορίες για το πώς θα χρησιμοποιήσει την υπηρεσία, πως θα συνδεθεί μαζί της και σε ποια διεύθυνση βρίσκεται. - 23 -
7 SOAP 7.1 Τι είναι το SOAP Το SOAP είναι ένα πρωτόκολλο με το οποίο, μπορούν οι υπηρεσίες διαδικτύου να ανταλλάξουν πληροφορίες μεταξύ τους. Χρησιμοποιείται το πρότυπο της XML για την ανταλλαγή μηνυμάτων μεταξύ των υπηρεσιών. Ένα άλλο χαρακτηριστικό του SOAP είναι τα πρωτόκολλα τα οποία χρησιμοποιεί για την επικοινωνία του, αυτά είναι τα γνωστά σε όλους μας HTTP και SMTP. Η χρήση κοινά χρησιμοποιούμενων πρωτοκόλλων για την επικοινωνία του SOAP, και όχι η δημιουργία ενός νέου ειδικευόμενου πρωτοκόλλου, κάνει το SOAP ένα πρωτόκολλο ανταλλαγής πληροφοριών το οποίο είναι ανεξάρτητο από την εφαρμογή και το υλικό της υπολογιστικής πλατφόρμας. Η ανεξαρτησία αυτή είναι ένα από τα κύρια ζητούμενα όταν μιλάμε για υπηρεσίες διαδικτύου. Από την άλλη το SOAP είναι ένα ιδιαίτερα λιτό και απλό πρωτόκολλο, αφού προσφέρει μόνο τα βασικά συστατικά για την ανταλλαγή των πληροφοριών, παραλείποντας πολλά χαρακτηριστικά όπως είναι η ασφάλεια και η αξιοπιστία. Αυτό όμως φαίνεται να μην αποτελεί πρόβλημα καθώς μας δίνει τη δυνατότητα να το επεκτείνουμε προσθέτοντας εμείς τις δυνατότητες που χρειαζόμαστε. Συγκεντρωτικά το SOAP είναι : Ένα ελαφρύ πρωτόκολλο για την ανταλλαγή πληροφοριών μεταξύ των υπηρεσιών διαδικτύου. Ένας τρόπος επικοινωνίας, ανεξάρτητος από την υλοποίηση αφού χρησιμοποιεί την XML για την ανταλλαγή των πληροφοριών. Ανεξάρτητο από την γλώσσα προγραμματισμού. Επεκτάσιμο. Χρησιμοποιεί κοινά πρωτόκολλα για την επικοινωνία του (HTTP, SMTP). 7.2 Συντακτικό του SOAP Κάθε μήνυμα SOAP είτε έρχεται από τον εξυπηρετούμενο, είτε από τον εξυπηρέτη, είναι ένα έγγραφο XML το οποίο περιέχει τα παρακάτω στοιχεία Ένα στοιχείο <Εnvelope> το οποίο μας υποδεικνύει ότι το συγκεκριμένο έγγραφο XML είναι ένα μήνυμα SOAP. Ένα προαιρετικό στοιχείο <Header> το οποίο περιέχει πρόσθετες πληροφορίες που αφορούν το μήνυμα. Ένα υποχρεωτικό πεδίο <Body> που περιλαμβάνει της πληροφορίες του μηνύματος. Ένα προαιρετικό στοιχείο <Fault> που περιλαμβάνει τα σφάλματα του προκληθήκαν κατά την επεξεργασία του μηνύματος. Κάθε ένα από τα παραπάνω πεδία έχει χαρακτηριστικά που θα περιγραφούν στα παρακάτω υποκεφάλαια. Πρώτα όμως ας δούμε την μορφή την όποια θα πρέπει να έχουν τα μηνύματα του SOAP: <?XML version="1.0"?> <soap:envelope XMLns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingstyle="http://www.w3.org/2001/12/soap-encoding"> <soap:header>...... </soap:header> <soap:body>... - 24 -
... <soap:fault>...... </soap:fault> </soap:body> </soap:envelope> Σχήμα 6 Δομή ενός μηνύματος SOAP 7.2.1 Soap envelope Κάθε μήνυμα SOAP πρέπει να έχει αυτό το πεδίο εντός του οποίου περιέχονται όλα τα υπόλοιπα πεδία του μηνύματος. Από ό,τι βλέπουμε τόσο στο ανωτέρω παράδειγμα όσο και στο σχήμα 4, το envelope περιλαμβάνει: Ένα ή παραπάνω namespaces, όπου σίγουρα θα πρέπει να περιέχεται το namespace της έκδοσης SOAP που χρησιμοποιούμε (XMLns:soap=http://www.w3.org/2001/12/soap-envelope). Το απαραίτητο στοιχείο body Το προαιρετικό στοιχείο header 7.2.2 Soap Header Το προαιρετικό αυτό πεδίο κεφαλίδας χρησιμοποιείται για να δώσει επιπλέον δυνατότητες στην εφαρμογή που θα χρησιμοποιήσει το SOAP, για παράδειγμα θα μπορούσε να χρησιμοποιηθεί για μια εφαρμογή που χρειάζεται επιπρόσθετες λειτουργίες όπως ασφάλεια, κρυπτογράφηση και αλλά (πρέπει να αναφερθεί ότι οι περισσότερες εφαρμογές SOAP δεν χρησιμοποιούν αυτή τη κεφαλίδα, ωστόσο όσο πληθαίνουν οι ανάγκες των εφαρμογών αυτό το πεδίο θα προσφέρει πολύ λειτουργικότητα). Το πρωτόκολλο υποστηρίζει τα εξής πεδία μέσα στη κεφαλίδα : Tο πεδίο actor attribute, το οποίο χρησιμοποιείται από το χρήστη για να ορίσει αν θέλει να «προωθήσει» το μήνυμα αυτό ώστε να γίνει κάποια εργασία εκεί και το αποτέλεσμα να δοθεί σε κάποια άλλη υπηρεσία. Επίσης, χρησιμοποιώντας αυτό το πεδίο μπορούμε να ορίσουμε και το παραλήπτη του αποτελέσματος. Το πεδίο MustUnderstand attribute. Το πεδίο αυτό ορίζει αν η κεφαλίδα είναι υποχρεωτικό να αναγνωστεί και να κατανοηθεί πλήρως. Αν το πεδίο έχει τιμή true τότε ο εξυπηρετητής πρέπει να αναλύσει και να καταλάβει το header για να απαντήσει, αλλιώς να επιστρέψει αρνητική απάντηση. - 25 -
Ένα header αποτελείται από: Καμία έως οσεσδήποτε ιδιότητες. Κανένα έως οσαδήποτε στοιχεία-παιδιά που έχουν ακριβώς τον ίδιο τρόπο σύνταξης με το header Ένα παράδειγμα επικεφαλίδας: <SOAP-ENV:Header> <ns1:paymentaccount XMLns:ns1="urn:ecerami" SOAP-ENV: mustunderstand="true"> orsenigo473 </ns1:paymentaccount > </SOAP-ENV:Header> 7.2.3 Soap Fault Αυτό το προαιρετικό στοιχείο χρησιμοποιείτε για να μας ενημερώσει για τα σφάλματα που συνέβησαν κατά την επεξεργασία του μηνύματος. Σε περίπτωση λάθους, στο σώμα του μηνύματος εμφανίζεται ένα στοιχείο <fault>, το οποίο θα έχει πληροφορίες για το λάθος το οποίο συνέβη. Ένα fault αποτελείται από: Ένα στοιχείο που αναφέρει τον κωδικό του σφάλματος <faultcode>. Ένα στοιχείο το οποίο θα περιέχει το κείμενο της αναφοράς του σφάλματος <faultstring>. Ένα προαιρετικό στοιχείο, το οποίο θα λέει ποιος προκάλεσε το λάθος που συνέβη <faultactor>. Ένα προαιρετικό στοιχείο, που έχει μια πιο λεπτομερή αναφορά για το λάθος το οποίο συνέβη <detail>. Κάποιοι τυποποιημένοι κωδικοί που αφορούν τα σφάλματα είναι : Το VersionMismatch που σημαίνει ότι το namespace του envelope είναι λάθος. Δηλαδή ότι χρησιμοποιούμε λάθος έκδοση namespace για το SOAP. Το MustUnderstand που σημαίνει ότι υπάρχει header ο οποίος πρέπει να τύχει επεξεργασίας, αλλά η υπηρεσία δεν μπόρεσε να τον επεξεργαστεί. Το Client που σημαίνει ότι το μήνυμα ήταν λάθος διαμορφωμένο ή περιείχε λάθος πληροφορίες. Το Server που σημαίνει ότι δεν μπόρεσε να γίνει η επεξεργασία γιατί υπήρχε πρόβλημα με την υπηρεσία και όχι με τις πληροφορίες που περιείχε το μήνυμα. Για παράδειγμα, δίνεται μια απάντηση λάθους σε ένα πελάτη που ζήτησε να εκτελεστεί η μέθοδος ValidateCreditCard,, η οποία δεν είναι διαθέσιμη στον server. <?XML version='1.0' encoding='utf-8'?> <SOAP-ENV:Envelope XMLns:SOAP-ENV="http://schemas.XMLsoap.org/soap/envelope/" XMLns:xsi="http://www.w3.org/1999/XMLSchema-instance" XMLns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode xsi:type="xsd:string"> SOAP-ENV:Client </faultcode> <faultstring xsi:type="xsd:string"> Failed to locate method (ValidateCreditCard) in class (examplescreditcard) at /usr/local/activeperl-5.6/lib/ site_perl/5.6.0/soap/lite.pm line 1555. </faultstring> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> - 26 -
7.3 SOAP μέσω HTTP Το SOAP (θεωρητικά) είναι ανεξάρτητο πρωτοκόλλου μεταφοράς και μπορεί να μεταφερθεί μέσω SMTP, FTP, IBM s, MQSeries, ή Microsoft Message Queuing (MSMQ). Ωστόσο οι προδιαγραφές και η προγραμματιστική διασύνδεση (API) που δίνει το SOAP είναι μόνο για το HTTP. Όπως είναι λογικό, οι αιτήσεις του SOAP στέλνονται σαν αιτήματα HTTP, και επιστρέφονται πίσω σαν περιεχόμενο της απάντησης HTTP. Οι αιτήσεις SOAP μπορούν να σταλούν μέσω HTTP GET και HTTP POST, ωστόσο το API του SOAP δίνει πληροφορίες μόνο για το HTTP POST: το HTTP POST είναι προτεινόμενο διότι κάποιοι server έχουν περιορισμούς στο μέγιστο πλήθος χαρακτήρων σε αιτήσεις HTTP GET. Όταν στέλνουμε αιτήσεις HTTP πρέπει να τις μετατρέψουμε σε text/xml. Επίσης, οι εξυπηρετούμενοι πρέπει να περιλαμβάνουν στην αίτηση HTTP μία επικεφαλίδα SOAPAction που δίνει πληροφορίες για το URI στο οποίο τελικά γίνεται η πρόσβαση της υπηρεσίας διαδικτύου. Η επικεφαλίδα αυτή είναι χρήσιμη καθώς δίνει τη δυνατότητα σε firewalls να εξάγουν πληροφορίες για το συγκεκριμένο μήνυμα χωρίς να χρειάζεται να αναλύσουν τη δομή XML του πακέτου. Παρόλο που οι προδιαγραφές του SOAP λένε ότι ο εξυπηρετούμενος είναι αυτός που διαμορφώνει την αίτηση HTTP και άρα ορίζει τις επικεφαλίδες-, κάθε server διατηρεί τη δυνατότητα να απαιτεί την ύπαρξη συγκεκριμένων επικεφαλίδων για να αποδεχτεί μία αίτηση, και να την απορρίπτει αν οι επικεφαλίδες δεν υπάρχουν οι δεν έχουν τις κατάλληλες τιμές. Έστω και αν ο server δεν απαιτεί κάποια επικεφαλίδα πρέπει να δώσουμε το πεδίο αυτό σαν κενή συμβολοσειρά. Παρακάτω δίνεται ένα παράδειγμα για το πώς μπορούμε να στείλουμε μια αίτηση στην υπηρεσία μετάφρασης Babelfish Translation που δίνεται από την XMethods : POST /perl/soaplite.cgi HTTP/1.0 Host: services.xmethods.com Content-Type: text/xml; charset=utf-8 Content-Length: 538 SOAPAction: "urn:xmethodsbabelfish#babelfish" <?XML version='1.0' encoding='utf-8'?> <SOAP-ENV:Envelope XMLns:SOAP-ENV="http://schemas.XMLsoap.org/soap/envelope/" XMLns:xsi="http://www.w3.org/1999/XMLSchema-instance" XMLns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:babelfish XMLns:ns1="urn:xmethodsBabelFish" SOAP-ENV:encodingStyle="http://schemas.XMLsoap.org/soap/encoding/"> <translationmode xsi:type="xsd:string">en_fr</translationmode> <sourcedata xsi:type="xsd:string">hello, world!</sourcedata> </ns1:babelfish> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Ζητάμε από το server services.xmethods.com να καλέσει την συνάρτηση BabelFish με παραμέτρους ένα string με όνομα translationmode και περιεχόμενα «en_fr» (κωδικοποίηση της πράξης μετάφρασης «από αγγλικά σε γαλλικά») και άλλο ένα string με όνομα sourcedata και περιεχόμενα «Hello World». Να σημειωθεί ότι το URI που ζητούν οι XMethods για αυτή την υπηρεσία είναι SOAPAction: "urn:xmethodsbabelfish#babelfish" όπου συμπληρώνεται πιο πάνω. Και η απάντηση που θα έρθει από το server της XMethods είναι : HTTP/1.1 200 OK Date: Sat, 09 Jun 2001 15:01:55 GMT Server: Apache/1.3.14 (Unix) tomcat/1.0 PHP/4.0.1pl2 SOAPServer: SOAP::Lite/Perl/0.50 Cache-Control: s-maxage=60, proxy-revalidate Content-Length: 539-27 -